القائمة
新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
docs/architecture/harness.md の invariant を機械的に検証するスキル。引数なしで `--staged --fail-on=error` (PR 直前用)、`full` で全件スキャン、`why <RULE_ID>` で invariant の意図を harness.md から引いて表示。コミット直前 / Stop hook から呼ばれる前提。
PR の主目的から外れた発見・改善・技術的負債を「フォローアップ」として記録、列挙、解消管理するスキル。スコープクリープを防ぎ、scope 外の課題を別 PR で確実に処理する仕組み。引数なしで起動すると未処理一覧、`add <title>` で追加、`resolve <id> <pr-url>` で解消記録、`list-pr-body` で PR 本文に貼る markdown を出力。
| name | feature |
| description | 新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。 |
このスキルは新機能開発を以下のフローで強制実行する。各フェーズを順番に進め、スキップは禁止。
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 に仕様書へのリンクと受け入れ基準を記載する。
以下の 5 つのエージェントを Agent ツールで同時に起動 する（単一メッセージで全 Agent を呼び出す）。
仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-pm-review.md に成果物を出力仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-design.md に成果物を出力仕様書と Issue を読み込み、以下を担当する（TDD 必須）。
仕様書と Issue を読み込み、以下を担当する。
仕様書と Issue を読み込み、以下を担当する。
docs/specs/[機能名]-user-feedback.md に成果物を出力全エージェントの成果物を統合して以下を行う。
nr lint && nr typecheck && nr test && nr build