Menu
新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。「○○を作って」「○○機能を追加して」など新機能・機能拡張の実装依頼を受けたら、直接実装を始めずに必ず最初に使う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Issue、ADR、設計メモ、実装計画、PR diff、指定 path に対し、書かれていない前提、producer / consumer の未接続、実運用だけで露出する failure path をコードと設定の証拠付きで探索する review-only スキル。実装前、設計レビュー、PR 前に未知や blocker を確認するときに使う。
プロジェクトを Bun + Hono（バックエンド）+ Vite + React（フロントエンド）+ Biome でスキャフォールドする初期化スキル。テンプレートを clone した直後の初回セットアップ時に、ユーザーが明示的に実行する。
docs/architecture/harness.md の invariant を機械的に検証するスキル。引数なしで `--staged --fail-on=error` (PR 直前用)、`full` で全件スキャン、`why <RULE_ID>` で invariant の意図を harness.md から引いて表示。コミット直前・Stop hook・PR 作成前ゲート・invariant 違反の調査に使う。
PR の主目的から外れた発見・改善・技術的負債を「フォローアップ」として記録、列挙、解消管理するスキル。スコープクリープを防ぎ、scope 外の課題を別 PR で確実に処理する仕組み。引数なしで起動すると未処理一覧、`add <title>` で追加、`resolve <id> <pr-url>` で解消記録、`list-pr-body` で PR 本文に貼る markdown を出力。作業中に scope 外の改善点・技術的負債・バグを見つけたら必ず使う。
.claude 配下のスキル・フック・設定をサプライチェーン成果物として監査するスキル。harness のスキル invariant (frontmatter 検証 / 隠し指示検出 / 危険実行パターン) の全件スキャンと、機械検査で拾えない「宣言と実態の乖離」のレビューチェックリストを実行する。スキルの新規追加・更新時、サードパーティスキルの導入前、定期監査に使う。
Based on SOC occupation classification
| name | feature |
| description | 新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。「○○を作って」「○○機能を追加して」など新機能・機能拡張の実装依頼を受けたら、直接実装を始めずに必ず最初に使う。 |
| argument-hint | [機能の概要] |
このスキルは新機能開発を以下のフローで強制実行する。各フェーズを順番に進め、スキップは禁止。
AskUserQuestion ツールを使って以下を必ず確認する。質問は一度にまとめて行うのではなく、回答を受けて深掘りする。
必須確認項目:
ヒアリングで曖昧な点が残る場合は追加質問を行う。ユーザーが「それで進めて」と言うまでヒアリングを続ける。
ヒアリング結果を元に docs/specs/[YYYY-MM-DD]-[機能名].md を作成する。
# [機能名] 仕様書
## 概要
[1-2 文で機能を説明]
## ユーザーストーリー
- [ペルソナ] として [目的] のために [機能] を使いたい
## 受け入れ基準
- [ ] [具体的な条件 1]
- [ ] [具体的な条件 2]
## 非機能要件
- パフォーマンス:
- セキュリティ:
- アクセシビリティ:
## 技術設計
- データモデル:
- API エンドポイント:
- UI コンポーネント:
## スコープ外
- [今回実装しないもの]
仕様書を作成したらユーザーに確認を求める。承認を得てからフェーズ 3 に進む。
仕様書を元に以下の Issue を gh issue create で作成する。
| Issue | ラベル | 担当ロール |
|---|---|---|
| [機能名] - 要件・受け入れ基準 | requirements | Product Manager |
| [機能名] - UI/UX 設計 | design | Designer |
| [機能名] - バックエンド実装 | backend | Developer |
| [機能名] - フロントエンド実装 | frontend | Developer |
| [機能名] - テスト計画・実装 | testing | QA |
各 Issue に仕様書へのリンクと受け入れ基準を記載する。
実装前に設計を決める。docs/design/[YYYY-MM-DD]-[機能名].md に次を残し、ユーザー承認を得てからフェーズ 4 に進む。最初に動いた構造をそのまま採用しない。
品質の正本は docs/architecture/quality-bar.md。MVP は完了条件ではない。
以下の 5 つのエージェントを Agent ツールで同時に起動 する（単一メッセージで全 Agent を呼び出す）。
仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-pm-review.md に成果物を出力仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-design.md に成果物を出力仕様書・Issue・設計ドキュメントを読み込み、以下を担当する（TDD 必須）。
docs/architecture/quality-bar.md の Definition of Done を満たす。MVP・仮実装・型エスケープで止めない。bun scripts/architecture-harness.ts --staged --fail-on=error）を通す。仕様書と Issue を読み込み、以下を担当する。
仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-user-feedback.md に成果物を出力全エージェントの成果物を統合して以下を行う。
docs/architecture/quality-bar.md の Definition of Done が全て満たされているか確認make before-commit → nr typecheck && nr test:coverage && nr build（カバレッジ 100%）