github-workflow

issueの実装前に（必読）

コードを書く前に、issue全体を読んでください — 本文とコメント両方：

gh issue view <N>            # title + body + acceptance criteria
gh issue view <N> --comments # full comment thread

設計上の決定、オプション選択、構造上の明確化はしばしばコメントに記載されており、本文には含まれていません。本文のみを読んだ実装者は、間違ったオプションを実装する可能性があります。

サブエージェントに委譲する場合： 両方の出力をそのまま渡します。言い換えたり、要約したり、issueを自分のプロンプトに「翻訳」しないでください。issue本文は委譲プロンプトそのものです。説明が必要だと感じる場合は、issueが不十分に指定されているということです — issueにコメントを追加して明確にしてから、委譲します。

受け入れ基準が抽象的な場合（例：「関数Aを関数Bと一貫させる」と言われても、どの構造的プロパティを一致させるかが指定されていない）： 実装しないでください。issueにコメントを追加して、必要な具体的な構造変更を説明してください — 2つの関数をdiffで比較し、正確な相違点を特定し、どの行が一致する必要があるかを述べてから、進めます。

PRを作成する前に（必須ゲート）

このチェックリストを実行してください — gh pr createの前に、例外なく毎回。

ステップ1：@architect-reviewerを実行

@architect-reviewerを以下のものとともに呼び出します：

• 変更されたコードに関連する設計ドキュメントセクション（docs/で仕様、ADR、設計ドキュメントを検索してください — 存在しない場合、PRボディにその旨を記載してください）
• 変更されたファイル（git diff origin/main --name-only）
• 修正するissueがある場合、その issue（gh issue view <N> — 完全な本文を渡してください）

@architect-reviewerは要件ごとにCONFORMANT / PARTIAL / MISSING / DEADの適合性テーブルを生成します。

ステップ2：見つかった項目に対応する

見つかった項目	対応
すべてCONFORMANT	ステップ3に進む
PARTIAL がある	ギャップを修正し、@architect-reviewerを再実行
MISSING がある	PRを開く前に修正してください — 例外なし
DEAD がある	PRを開く前に、broken producer→consumerチェーンを修正

解決されていないMISSINGまたはDEADの見つかった項目でPRを開かないでください。設計が要求する項目に対して「後のフォローアップで修正します」はありません。

ステップ3：適合性テーブルをPRボディに貼り付ける

PRボディには、@architect-reviewer適合性テーブルを必ず含める必要があります。これがないPRボディはゲートがスキップされたことを示唆します。

## 設計適合性

| # | 要件 | 出典 | ステータス | 根拠 |
|---|---|---|---|---|
| 1 | ... | ADR-0003, §2 | CONFORMANT | src/pipeline.py:142 |
...

@architect-reviewerによるレビュー — すべての要件がCONFORMANT。

リポジトリに設計ドキュメントがない場合、次のように記載してください：設計ドキュメントが見つかりません — 適合性レビューは適用できません。

ステップ4：PRを開く

gh pr create --fill

スタックされたPRおよび複数のスタック全体での並行作業の場合、stacked-prsスキルをロードします。

---

gh CLIレシピ

# Issues
gh issue create -t "Title" -b "Body" -l bug
gh issue list --state open --label "priority:high"
gh issue close 42 -c "Fixed in #45"
gh issue edit 42 --add-label "in-progress"

# PRs
gh pr create --fill                     # From current branch, auto-fill
gh pr list --state open --author @me
gh pr checks 45                         # CI status
gh pr review 45 --approve
gh pr merge 45 --squash --delete-branch # For non-stacked PRs only

# CI/CD
gh run list --workflow=ci.yml
gh run view <id> --log-failed
gh run rerun <id> --failed
gh workflow run release.yml -f force=minor

# Searching
gh search code "pattern" --repo owner/repo
gh search issues "label:bug is:open" --repo owner/repo

Issue規律

issue作成の完全なガイダンス — テンプレート、削除規律、設計ドキュメント参照、テスト要件、エピックサイジング — については、issue-writingスキルをロードしてください。

issueなしで作業を先延ばしにしない

レビュアーが「こともできますが...」や「...を検討することもできます」と言い、それがスコープ外の場合：

1. すぐにissueを作成します：gh issue create -t "Follow-up: ..." -b "From PR #N"
2. PRコメントにリンクします
3. 進めます

Issue トリアージラベル

• bug、enhancement、documentation
• priority:high、priority:low
• good-first-issue オンボーディング用

PRレビュー処理

• 再度レビューをリクエストする前に、すべてのコメントに対応してください。
• 異議がある場合は、推理を説明してください — 無視しないでください。
• 問題を同じPRで修正してください。フォローアップに先延ばしにしないでください（本当にスコープ外の場合を除き）。
• git diff origin/mainで自己レビューしてから、毎回プッシュしてください。

コミットメッセージフォーマット

type(scope): description

[optional body]

[optional footer: BREAKING CHANGE, Refs #issue]

型：feat、fix、docs、refactor、test、chore、ci、perf