菜单
新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。「○○を作って」「○○機能を追加して」など新機能・機能拡張の実装依頼を受けたら、直接実装を始めずに必ず最初に使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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 検証 / 隠し指示検出 / 危険実行パターン) の全件スキャンと、機械検査で拾えない「宣言と実態の乖離」のレビューチェックリストを実行する。スキルの新規追加・更新時、サードパーティスキルの導入前、定期監査に使う。
基于 SOC 职业分类
| 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%）