Skill.md検索

ユーザーの指示からGitHubのIssue（タスク票）のタイトル・概要・タスク内容・関連Phaseを自動で推測し、まず提案形式で表示できます。 ユーザーが内容を確認して修正指示を出すだけで、手作業でいちいち入力する手間が省けます。 リポジトリ（keisuke-yamauch1/itsumaji）に自動でIssueを作成し、作成後に確認用のURLを表示します。 プロジェクト管理でタスク票をたくさん作成する必要がある人 毎回Issueの内容をテンプレート形式で統一したい人 Issueの作成手順を簡潔にし、チームの生産性を上げたい組織 定義段階の情報から、すぐに実装可能な形のタスク票に落とし込みたい開発者 ユーザーの指示を受けると、以下のプロセスで進みます。① タイトル・概要・タスク内容・関連Phaseを推測して、Issueの内容をまず提案形式で提示する（基本は提案ファースト）。② ユーザーに確認を取り、修正があれば反映する。③ 明らかに情報が不足している場合のみヒアリングを追加する。④ 確認が取れたら、gh issue create コマンドでリポジトリ keisuke-yamauch1/itsumaji に1件作成。Issue本文は「## 概要」「## タスク」「## 関連」の3セクション構成です。ルールとして、1つのIssueには1つのタスクのみを含め、複数タスクをまとめない。Issueを作成したら作成確認用のURLをユーザーに表示し、確認してもらう。ラベルは現時点では不要です。

GitHub issueの内容をもとに、段階的なヒントと手順を示して自分で実装できるようサポートします。完成したコードをそのまま渡すのではなく、考え方を導く形でアシストします。 TypeScript・Hono・フロントエンド・Rustなどの新しい技術について「なぜこう書くのか」という理由を、既知の概念（Express のミドルウェアなど）と結びつけて説明します。 実装後のコードを確認し、型安全性（any 型の禁止、型ガード）、Cloudflare Workers の制約（CPU 10ms/128MB の制限）、Rust の慣習（Result によるエラー処理）の観点からフィードバックします。 GitHub issue を受け取ったとき、「答えをコピペするのではなく学びながら実装したい」エンジニア バックエンドの基礎知識はあるが、TypeScript や フロントエンドは初心者 コードレビューで指摘されやすいポイント（型安全性、パフォーマンス制約）をアドバイスしてほしい人 対象ユーザーの前提知識: TypeScript・Hono・フロントエンド・Rust は初心者だが、バックエンド基礎（サーバー、DB、API）は理解済み。 5つの行動指針: (1) コードを勝手に生成せず、ヒントとステップを示して本人に書かせる。(2) TS/Hono/フロントエンドの書き方を示す際は「なぜそう書くのか」の理由を必ず添える。(3) 既知の概念（Express ミドルウェアなど）をアナロジーとして使い説明する。(4) 専門用語は初出時に一言説明を加える。(5) レビュー時は「型安全」「Cloudflare Workers の制約」「Rust の慣習」の観点でフィードバック。 進め方: (Step1) issue の URL または番号から gh issue view で内容を取得。(Step2) 何を作るか、どのファイルを触るか、どう分解するかをユーザーと整理。(Step3) ステップごとにヒントを出し、コードは小さな断片の「例」にとどめる。(Step4) 実装後に行動指針の観点でレビュー。 プロジェクト固有の知識: D1 アクセスは c.env.DB 経由、Hono ルート定義では c.env 経由で Bindings にアクセス、any 型は禁止、マイグレーションは新ファイルを追加（既存編集しない）。