메뉴
Generate QA phase documents (test plan, non-functional requirement tests, Gherkin scenarios) in the teams/ directory. Phase 3 of the /start-teams-doc workflow. Requires Design phase approval. Use when creating test plans, test scenarios, Gherkin .feature files.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Collect user's implicit knowledge (business context, technical constraints, past failures, hidden assumptions) through interactive dialogue and save as _interview-notes.yaml before executing feature documentation skills. Use when running /interview command or automatically before any start-teams-doc phase. Generic design allows use with skills beyond teams-docs.
Unified entry point for generating feature documentation in the teams/ directory. Automatically detects the current phase (Discovery, Design, QA, Operations) and delegates to the appropriate skill. Use when creating new feature docs, continuing existing feature docs, or when user says /start-teams-doc.
Generate Design phase documents (non-functional requirements, domain modeling, ADR, specifications) in the teams/ directory. Phase 2 of the /start-teams-doc workflow. Requires Discovery phase approval. Use when creating design documents, ADRs, ER diagrams, or non-functional requirements.
Generate Discovery phase documents (PRD and user stories) in the teams/ directory. Phase 1 of the /start-teams-doc workflow. Use when creating PRDs, user stories, or requirements definitions under teams/.
Generate Operations phase documents (SLO/SLA definitions, performance test records, operational runbooks) in the teams/ directory. Phase 4 of the /start-teams-doc workflow. Requires QA phase approval. Use when defining SLO/SLA, creating runbooks, or documenting operational procedures.
SOC 직업 분류 기준
| name | teams-docs-qa |
| description | Generate QA phase documents (test plan, non-functional requirement tests, Gherkin scenarios) in the teams/ directory. Phase 3 of the /start-teams-doc workflow. Requires Design phase approval. Use when creating test plans, test scenarios, Gherkin .feature files. |
/teams-docs-qa コマンドが呼ばれたとき/start-teams-doc の第3フェーズ（qa フェーズ）として呼ばれたとき/start-teams-doc から以下が引き渡される:
docs_root: ドキュメントルートパス（sdd-docs または .）team, project, feature, feature_id, goal, scope_in, scope_outconstraints{docs_root}/teams/{team}/{project}/{feature}/_approval-status.yaml を読み込むdesign.status != approved の場合は停止して Design フェーズの承認を促すqa.status == changes_requested の場合は修正モードで実行qa.status == in_review の場合はドキュメント生成をスキップし、構造バリデーションのみ再実行して承認確認メッセージに直接進む{docs_root}/teams/{team}/{project}/{feature}/qa/
├── テスト計画書.md
├── 非機能要件のテスト.md
└── ユーザーストーリー/
└── {シナリオタイトル}.feature
{シナリオタイトル}.feature（日本語可）TC-{feature_id}-NNN 形式でファイル先頭に記入# Related: US-{feature_id}-NNN を各ファイルに記入Then には具体的な期待値を記載する（「〇〇が表示される」「ステータスが 200 になる」など）テスト計画書.md 末尾の Matrix に US→TC の対応を記入する。
references/quality-checklist.md の全項目を確認する。 未テスト US が残っている場合は承認不可。
バリデーションスクリプトを実行して自動チェックを行う:
python <this_skill_dir>/scripts/validate.py <feature_dir>
<this_skill_dir>は、この SKILL.md が配置されているディレクトリの実際のパスに解決すること。
エラーが出た場合は修正してから承認確認を行う。
品質ゲート通過後、承認確認メッセージを表示する前に _approval-status.yaml の qa.status を in_review に更新する。
これにより、ユーザーが承認確認中にセッションを中断しても、次回再開時にドキュメント生成をスキップできる。
✅ [qa] フェーズの品質ゲートを通過しました。
承認しますか？
1. Approve & Continue（_approval-status.yaml を更新して完了）
2. Request Changes（修正点を確認して停止）
3. Pause Review（レビューを中断して後で再開）
承認時: _approval-status.yaml の qa.status を approved、approved_at を本日付で更新する。
修正要求時: _approval-status.yaml の qa.status を changes_requested に更新し、ユーザーが指摘した修正点の一覧を表示して停止する。
レビュー中断時: status は in_review のまま維持。以下を表示して停止する:
⏸️ [qa] フェーズのレビューを中断しました。
`/start-teams-doc` で再開できます。
| ファイル | 必須 |
|---|---|
qa/テスト計画書.md | ✅ |
qa/非機能要件のテスト.md | ✅ |
qa/ユーザーストーリー/{タイトル}.feature | ✅（US 数分） |
サブモジュールモード（docs_root = sdd-docs）の場合、ワークスペースルートにメインリポジトリのソースコードが存在する。以下を積極的に参照してドキュメントの精度を高めること:
Feature:, Scenario:, Given, When, Then）のスペルと半角コロン・半角スペースを確認する。Scenario Outline: の場合は Examples: テーブルも必須。.feature ファイルを qa/ユーザーストーリー/ に作成し、# Related: US-{feature_id}-NNN を記載する。