[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4P9PYK4P2EH7Y5VTZX9SY":3,"skill-same:01M6C4P9PYK4P2EH7Y5VTZX9SY":112},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":72,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":6,"ownerHtmlUrl":77,"ownerBlogUrl":78,"ownerDescription":79,"updatedAt":80,"install":81,"resources":93},"01M6C4P9PYK4P2EH7Y5VTZX9SY","harness-plan",null,"HAR: Research-backed, team-validated task planning, Plans.md management, progress sync. Trigger: create a plan, add tasks, update Plans.md, mark complete, check progress. Do NOT load for: implementation, review, release.","Chachamaru127\u002Fclaude-code-harness","Chachamaru127","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F96473544?v=4","01M6C4N084DDDEK9SJPGFG9H9M","Chachamaru","01M6C4N0CCNFST9P8C7EJNVH42",3205,"MIT","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"harness plan","plan","harness","2026","review","websearch","co","progress","maintain","read","check","Bash","team","ci","product","task planning","release","planning","update","create","core","tasks","workflow","research","spec","2026-11-10 10:12:30",false,"---\nname: harness-plan\ndescription: \"HAR: Research-backed, team-validated task planning, Plans.md management, progress sync. Trigger: create a plan, add tasks, update Plans.md, mark complete, check progress. Do NOT load for: implementation, review, release.\"\ndescription-en: \"HAR: Research-backed, team-validated task planning, Plans.md management, progress sync. Trigger: create a plan, add tasks, update Plans.md, mark complete, check progress. Do NOT load for: implementation, review, release.\"\ndescription-ja: \"HAR:調査・採点・記憶確認・TeamAgent\u002Fサブエージェント検証つきのタスク計画、Plans.md管理、進捗同期を担当。計画作って、タスク追加、Plans.md更新、完了マーク、進捗確認で起動。実装・レビュー・リリースには使わない。\"\nkind: workflow\npurpose: \"Maintain co-required planning output for the spec.md product contract and Plans.md task contract\"\ntrigger: \"create a plan, add tasks, update Plans.md, check progress\"\nshape: workflow\nrole: generator\npair: harness-sync\nowner: harness-core\nsince: \"2026-05-05\"\nallowed-tools: [\"Read\", \"Write\", \"Edit\", \"Bash\", \"Grep\", \"Glob\", \"WebSearch\", \"Task\"]\nargument-hint: \"[create|add|update|sync|sync --no-retro|--ci]\"\nuser-invocable: true\neffort: medium\n---\n\n# Harness Plan\n\nHarness の統合プランニングスキル。\n以下の3つの旧スキルを統合:\n\n- `planning` (plan-with-agent) — アイデア → Plans.md への落とし込み\n- `plans-management` — タスク状態管理・マーカー更新\n- `sync-status` — Plans.md と実装の同期確認\n\n## Quick Reference\n\n| ユーザー入力 | サブコマンド | 動作 |\n|------------|------------|------|\n| \"計画を作って\" \u002F `\u002Fharness-plan create` | `create` | Spec delta \u002F skip reason → Plans.md task 生成 |\n| \"タスクを追加して\" \u002F `\u002Fharness-plan add` | `add` | Plans.md に新タスク追加 |\n| \"完了にして\" \u002F `\u002Fharness-plan update` | `update` | タスクマーカーを cc:完了 に変更 |\n| \"今どこ？\" \u002F `\u002Fharness-plan sync` | `sync` | 実装とPlans.mdを照合・同期 |\n| `\u002Fharness-sync` | `sync` | 進捗確認（独立 sync surface と同等） |\n| `\u002Fharness-plan create` | `create` | spec.md \u002F Plans.md 二正本の計画作成 |\n| `\u002Fharness-plan list` | `list` | `plans\u002Fmanifest.json` の named Plans を一覧 |\n| `\u002Fharness-plan switch \u003Cname>` | `switch` | active plan を `.claude\u002Fstate\u002Factive-plan.json` に保存 |\n\n## スコープ既定: 今進められる全作業（operator 裁定 2026-07-24）\n\n計画依頼（`create` \u002F 引数なし起動 \u002F 「計画して」）の既定解釈は **「現時点で着手可能なすべての作業」**。\n\n- ユーザーが範囲を明示しない限り、依頼文脈に入る open item（残 phase、未処理 follow-up、既知の改善点、依頼文で言及された問題すべて）を洗い出して計画に含める。勝手に最小サブセットへ絞らない\n- 件数が多い場合も絞り込みではなく、全量を Required \u002F Recommended \u002F Optional \u002F Reject に分類して提示する。除外は Reject として理由を明示する（黙って落とさない）\n- 「一部だけ先に」が妥当と判断する場合は、絞った計画ではなく、全量計画の中の実行順序（Phase 分割 \u002F Depends）として表現する\n\nこの既定は計画候補の洗い出し範囲であり、実装や保護操作の承認ではない。評価・比較だけの依頼は評価を返し、採用済みの変更と提案を区別する。\ntask には目的と理由、担当範囲、検証可能な DoD、利用する証拠、原依頼や適用される承認の参照を残す。実装手順は契約上必要な制約以外を固定しない。\n\n## Literal companion commands（CC 2.1.108+）\n\n- `\u002Frecap`: 久しぶりに戻った時に要約を取り直してから `sync` へ入る\n- `\u002Fundo`: `\u002Frewind` の別名。直前の plan 更新を即座に戻したい時にそのまま使う\n\n## サブコマンド詳細\n\n### 標準の計画品質契約\n\nSee [references\u002Fplanning-quality.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplanning-quality.md)\n\n`harness-plan` は、spec.md product contract and Plans.md task contract の co-required planning output を作る planning surface である。\nprecedence は `spec.md > sub-spec > Plans.md` のまま維持する。\nPlans.md は task ledger、root `spec.md` は product contract であり、上下関係は崩さない。\n渡された情報をそのまま Plans.md に落とさない。\n計画作成や大きな task 追加では、最新情報・既存仕様・記憶・TeamAgent \u002F サブエージェントによる複数視点の議論を確認し、\nこのプロダクトに取り入れるべき要素だけを task contract に変換する。\n`\u002Fharness-plan create` は `Spec delta` または `Spec skip reason` と `Plans.md` task 生成をセットで返す。\n出力には必ず `Spec delta` または `Spec skip reason` を含める。\n`Spec delta` \u002F `Spec skip reason` は Harness が生成し、consumer は承認・修正だけ行う。\n\n**Non-trivial planning gate**:\n\n単発・軽微タスクでない planning は、TeamAgent またはサブエージェント前提で扱う。\nここでの non-trivial は、複数 task \u002F 複数 file \u002F 複数 session \u002F product behavior \u002F API \u002F data model \u002F 権限 \u002F 課金 \u002F 外部連携 \u002F 配布面 \u002F セキュリティに影響する依頼を指す。\nTask tool が使える場合は Product \u002F Architecture \u002F Security \u002F QA \u002F Skeptic の独立視点を走らせる。\n使えない場合は `サブエージェント未使用` と明示し、同じ観点を単独で分けて評価する。\n各担当には独立して答えられる問い、読む範囲、必要な根拠を渡す。利用可能な同時実行上限を守り、親も仕様照合や統合を進める。関連する追加調査は同じ担当に返す。\n\nnon-trivial planning の出力には、次の検証を必ず含める。\n\n- `team_validation_mode`: `not_required_lightweight` \u002F `native` \u002F `subagent` \u002F `manual-pass` \u002F `unavailable`\n- `spec.md` \u002F sub-spec \u002F `Plans.md` の整合性\n- harness-mem \u002F harness-recall \u002F repo memory による車輪の再発明防止確認\n- プロダクト目的から外れていないか\n- セキュリティ、権限、秘密情報、サプライチェーンに問題がないか\n- lint \u002F formatter baseline があるか。source code changes を含む plan で未設定なら、実装 task の前に setup task を置く\n- ちゃんと動く計画か。つまり test \u002F smoke \u002F CI \u002F review \u002F release gate が task DoD に落ちているか\n\n軽量 task は `team_validation_mode: not_required_lightweight` でよい。\nnon-trivial planning は `native` \u002F `subagent` \u002F `manual-pass` のいずれかを使う。\n`unavailable` のまま Required にしてはいけない。\nProduct \u002F Architecture \u002F Security \u002F QA \u002F Skeptic は検証 perspective であり、agent_type 名ではない。\n利用可能な TeamAgent \u002F Task サブエージェントに perspective として依頼し、任意 agent spawn を要求しない。\nSecurity gate は秘密情報の実読取を要求しない。\n`.env` や secret の read が必要になる場合は Risk Gate として止め、許可された既存 guard \u002F evidence で確認する。\n\n**適用する場面**:\n\n- `create` で新しい計画を作る\n- `add` で product behavior \u002F API \u002F 権限 \u002F 課金 \u002F 外部連携 \u002F 配布面に影響する task を足す\n- ユーザーが外部プロダクト、競合、仕様案、改善案、比較材料を渡した\n- 既存仕様や過去判断との衝突リスクがある\n\n**軽く扱ってよい場面**:\n\n- marker 更新だけの `update`\n- status 照合だけの `sync`\n- typo、format、README\u002FCHANGELOG のみ\n- 既存 spec とテストで正解が固定されている狭い変更\n\n**品質フロー**:\n1. 入力情報を分解し、評価対象・採点軸・不確かな事実を明示する\n2. 最新情報を取得する。外部事実は WebSearch \u002F 公式ドキュメント \u002F 一次情報を優先し、重要点は複数ソースでクロスチェックする\n3. 既存仕様・root `spec.md`・Plans.md・README・docs・CLAUDE.md・関連 skill を確認する\n4. harness-mem \u002F harness-recall \u002F `.claude\u002Fagent-memory\u002F` \u002F `.claude\u002Fstate\u002F` など、利用可能な記憶面を project-scoped で確認する\n5. non-trivial planning では TeamAgent \u002F Task サブエージェントを使い、Product \u002F Architecture \u002F Security \u002F QA \u002F Skeptic など異なる視点で独立レビューする\n6. source code changes を含む plan では lint \u002F formatter baseline を確認し、未設定なら setup task を先行させる\n7. 中立的な採点レビューを出し、Required \u002F Recommended \u002F Optional \u002F Reject に分類する\n8. `$easy` 形式で、提案内容・理由・どうなるのかを報告する\n9. 採用する案だけを root `spec.md` \u002F Plans.md \u002F test task へ落とし込む\n\n### Lane Taxonomy + Stage Gate\n\nFast \u002F Gate \u002F Release は **新 skill ではなく Plans metadata** として扱う。Plans.md の 5 column テンプレート（Task \u002F 内容 \u002F DoD \u002F Depends \u002F Status）は変更せず、\nlane（`[lane:fast]` \u002F `[lane:gate]` \u002F `[lane:release]`）・stage（検証→計画→TDD実装→レビュー→PR closeout の 5 段階）・unknown data contract（`not_observed != absent`、確認できない事実は `unknown` と明示）を\n**内容（Content）または DoD の先頭**に埋め込む。タグ一覧・worked example・stage 別 DoD 例は\n[references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md) を参照。\n\n### create — 計画作成\n\nSee [references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md)\n\nアイデア・要件をヒアリングし、実行可能な Plans.md を生成する。\n\n**フロー**:\n1. 会話コンテキスト確認（直前の議論から抽出 or 新規ヒアリング）\n2. 既存の依頼・仕様・読み取り調査で不足を補い、結論を変える未決事項だけ聞く（max 3問）。軽微な仮定は明示して計画を進める\n3. **計画品質チェック**（最新情報、既存仕様、記憶、TeamAgent \u002F サブエージェント複数視点レビュー、採点）\n4. 技術調査（WebSearch）\n5. 機能リスト抽出\n6. **spec.md \u002F Plans.md 二正本チェック**（Spec delta または Spec skip reason + Plans.md task）\n7. 優先度マトリクス（Required \u002F Recommended \u002F Optional \u002F Reject）\n8. TDD 採用判断（テスト設計）\n9. Plans.md 生成（`cc:TODO` マーカー付き）\n10. **事前確認セクション生成**（plan-time pre-approval）\n11. 次のアクション案内\n\n### create — 事前確認セクション（plan-time pre-approval）\n\n`create` で計画を確定する時は、Plans.md task を出したあと、承認前に **事前確認セクション**を必ず生成する。\n目的は、常設 allowlist で何でも許可するのではなく、作業スコープごとに「発生しそうな stop \u002F ask」を plan 承認時に 1 回だけ前倒しで確認すること。\n\n抽出対象:\n\n- 各 task の対象ファイル、関連 path、想定変更範囲\n- DoD に書いた検証コマンド、PR closeout コマンド、外部 API \u002F CLI 呼び出し\n- `secret-read path`（`.env*`, `secrets\u002F**`, `*.pem`, `*.key`, `.ssh\u002F**`, `.aws\u002F**`, `credentials` など）\n- 外部送信（`git push`, `gh pr create`, `gh api`, `curl` \u002F API call, release \u002F publish \u002F deploy）\n- 破壊的操作（`rm -rf`, migration destructive step, force push, production apply）\n\n固定 format:\n\n```text\n## 事前確認\n- 事項: \u003Csecret-read \u002F external-send \u002F destructive の具体操作>\n  理由: \u003CDoD または task 実行上必要な理由を 1 行>\n  scope: Phase \u003Cphase> \u002F Task \u003Ctask>\n```\n\n出力ルール:\n\n- 1 行の `理由` は secret 値を含めない。path \u002F コマンド名 \u002F 対象サービスまでに留める。\n- plan 承認時に、事前確認セクションの全事項を一括提示し、ユーザーから承認 \u002F 否認を得る。\n- 承認結果は `.claude\u002Fstate\u002Fplan-preapprovals.json` に `plan-preapproval.v2` として記録する。schema は `templates\u002Fschemas\u002Fplan-preapproval.v2.json`。v1 は既存記録の読み取り互換に限る。\n- 記録は `事項 + 理由 1 行 + scope (phase\u002Ftask)` を維持する。`operations` には `secret-read` \u002F `external-send` \u002F `destructive` を列挙する。`paths` \u002F `commands` \u002F `targets` には対象を列挙する。`decision`、`approved_at`、RFC3339 の `expires_at` を入れる。\n- `max_uses` は必要な再試行回数を含む上限を設定する。省略時は 10 回。`uses` は新規承認時に 0 とする。\n- 確認は plan 承認時の 1 回のみ。`harness-work` \u002F `breezing` 実行中、宣言済み事項だけを理由に `AskUserQuestion` を出してはいけない。\n- 記録に無い未計画の secret-read \u002F 外部送信 \u002F 破壊的操作は、従来どおり runtime floor \u002F ask で停止する。安全網を狭めない。\n- secret-read の承認は secret 値の表示許可ではない。必要最小の path を宣言し、work 開始時に project config の `runtimefloor.secretAllow` へ per-run 反映するための入力として扱う。\n\n### spec.md \u002F Plans.md 二正本チェック（デフォルト）\n\nPlans.md は「やるべきこと」の task contract、root `spec.md` は「何が正しいか」の product contract として扱う。\nco-required planning output は両方の出力を必須にするという意味であり、precedence は `spec.md > sub-spec > Plans.md` のまま維持する。\n実装がぶれる可能性がある時は、Plans.md 生成前に root `spec.md` を更新する。\n`create` と product-impacting `add` は毎回 root `spec.md` を読む。\n\n優先する保存先:\n\n1. root `spec.md`\n2. consumer repo に root `spec.md` がない時だけ、既存の project spec \u002F architecture \u002F product compass\n3. consumer repo に root `spec.md` がない時だけ、`docs\u002Fspec\u002F00-project-spec.md`\n4. 既存規約がある repo では、その規約に沿った spec path\n\n作成\u002F更新が必要な条件:\n\n- ユーザーに見える振る舞い、API、データモデル、権限、課金、外部連携を決める task\n- 複数の実装方針があり、選び方で product behavior が変わる task\n- 過去または今回の会話で「仕様が曖昧で実装がぶれた」兆候がある task\n- Plans.md には作業内容があるが、project としての正解条件が安定文書にない task\n\n不要な条件:\n\n- typo、format、dependency bump、README\u002FCHANGELOG のみ\n- 動作変更なしの狭い refactor\n- 既存 spec とテストで正解が十分に固定されている修正\n\n出力契約:\n\n- `Spec delta`: product contract を更新する時に、対象 spec path と変更点を書く\n- `Spec skip reason`: product contract を更新しない時に、理由を書く\n- `Spec delta` \u002F `Spec skip reason` は Harness が生成し、consumer は承認・修正だけ行う\n- docs-only \u002F mechanical task でも `Spec skip reason` を task context \u002F sprint contract に残す\n- missing search result、unavailable memory、未読ファイルを absent と断定しない。`not_observed != absent`\n- ユーザーに spec を一から書かせない。agent が既存 spec と入力から最小 delta を作り、曖昧な時だけ判断分岐を出す\n\n参照:\n\n- `docs\u002Fplans\u002Fspec-ssot.md`\n\n### create 完了時のセッション起動案内（必須）\n\n`create` が終わったら、説明だけで終わらせず、**新しいセッションの起動コマンド** と\n**起動後にそのまま入れる最初の指示プロンプト** をセットで案内する。\n\n優先順位は次の通り:\n\n1. 未完了タスクが 1 件だけ、または最初の 1 件だけ始めるのが自然\n   - 起動コマンド: `claude`\n   - 最初の入力: `\u002Fharness-work \u003Ctask番号>`\n2. 依存の薄いタスクが複数あり、まとめて進めるのが自然\n   - 起動コマンド: `claude`\n   - 最初の入力: `\u002Fbreezing all`\n   - 代替: `\u002Fharness-work all`\n3. 長時間実行や再入が前提\n   - 起動コマンド: `ENABLE_PROMPT_CACHING_1H=1 claude`\n   - 最初の入力: `\u002Fharness-loop all`\n   - 代替: `\u002Fbreezing all`\n\n最低でも次の 3 行を含める:\n\n- `新しいセッションの起動コマンド:`\n- `起動後の最初の入力:`\n- `向いている場面:`\n\n例:\n\n```text\n新しいセッションの起動コマンド: claude\n起動後の最初の入力: \u002Fbreezing all\n向いている場面: Phase 1 の task が複数あり、まとめて進めるほうが自然なため\n```\n\n長時間系を勧める場合は、Claude Code セッション起動コマンドも併記する:\n\n```text\n新しいセッションの起動コマンド: ENABLE_PROMPT_CACHING_1H=1 claude\n起動後の最初の入力: \u002Fharness-loop all\n向いている場面: 5 分を超える待機や resume をまたぐ長時間タスクのため\n```\n\n補足:\n\n- `scripts\u002Fclaude-longrun.sh` はこのリポジトリの開発補助スクリプトで、plugin install 後の consumer 環境には配布されない\n- そのため、consumer 向け案内では常に `ENABLE_PROMPT_CACHING_1H=1 claude` の 1 行コマンドを優先する\n- リポジトリ開発中だけ同等のラッパーを使いたい場合、`bash scripts\u002Fclaude-longrun.sh` はローカル checkout 上では利用してよい\n\n**CI モード** (`--ci`):\nヒアリングなし。既存の Plans.md をそのまま利用してタスク分解のみ行う。\n\n### add — タスク追加\n\nPlans.md に新しいタスクを追加する。\nproduct-impacting な追加では、上の「spec.md \u002F Plans.md 二正本チェック」に従い `Spec delta` または `Spec skip reason` も出力する。\n\n```\n\u002Fharness-plan add タスク名: 詳細説明 [--phase フェーズ番号]\n```\n\nタスクは `cc:TODO` マーカーで追加される。\n\n### update — マーカー更新\n\nタスクのステータスマーカーを変更する。\n`完了` は DoD、必須チェック、必要な review の証拠を確認してから付ける。コミットや自己申告だけでは判定しない。\n\n```\n\u002Fharness-plan update [タスク名|タスク番号] [WIP|完了|blocked]\n```\n\nマーカー対応表:\n\n| コマンド | マーカー |\n|---------|---------|\n| `WIP` | `cc:WIP` |\n| `完了` \u002F `done` | `cc:完了` |\n| `blocked` | `blocked` |\n| `TODO` | `cc:TODO` |\n\n### sync — 進捗同期\n\n実装状況と Plans.md を照合し、差分を検出・更新する（Plans.md 現状取得 → フォーマット検出 → git 状況取得 → agent trace 分析 → 差分検出 → マーカー修正提案 → 次アクション提示）。\n`cc:完了` タスクが 1 件以上あれば、見積もり精度・ブロック原因・スコープ変動を分析するレトロスペクティブをデフォルト ON で実行する（`sync --no-retro` でスキップ）。\n状況確認だけなら読み取りと報告で終える。同期更新を明示依頼された場合は証拠に一致する更新を進め、永続 memory 記録はその記録を明示依頼された場合だけ行う。\nStep 0-6 の完全版・harness-mem への記録手順は [references\u002Fsync.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsync.md) を参照。\n\n### team mode \u002F issue bridge\n\nPlans.md は正本のまま維持し、GitHub Issue 連携は opt-in の team mode だけで使う。\n\n- solo 開発では bridge を使わない\n- team mode は tracking issue を 1 つ作り、その配下に task ごとの sub-issue payload を dry-run で生成する\n- `scripts\u002Fplans-issue-bridge.sh` は実際に GitHub を更新せず、常に dry-run の payload を返す\n- Plans.md への変更はこの bridge では行わない\n\n参照:\n\n- `docs\u002Fplans\u002Fteam-mode.md`\n\n### named Plans\n\n複数の Plans.md を使う場合は `plans\u002Fmanifest.json` を正本にして、名前で選択する（1 run では 1 つの named plan だけを使う。long-running \u002F CI \u002F issue bridge では active pointer に頼らず `--plan \u003Cname>` を渡す。manifest path は project root 相対のみ）。\n\n```bash\nscripts\u002Fplan-registry.sh list\nscripts\u002Fplan-registry.sh switch roadmap\nscripts\u002Fplans-issue-bridge.sh --plan roadmap --format markdown\nnode scripts\u002Fgenerate-sprint-contract.js --plan roadmap 9.1.1\n```\n\n参照: `docs\u002Fplans\u002Fnamed-plans.md`\n\n## Plans.md フォーマット規約\n\n### フォーマット\n\n5 カラム（Task \u002F 内容 \u002F DoD \u002F Depends \u002F Status）の Markdown table。DoD は Yes\u002FNo 判定できる検証可能な 1 行（「いい感じ」「ちゃんと動く」は禁止）。\nDepends は `-`（依存なし）\u002F タスク番号 \u002F カンマ区切り複数 \u002F フェーズ依存のいずれか。生成テンプレート全文（Purpose 行含む）は\n[references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md) を参照。\n\n### DoD \u002F acceptance_criteria の採点設計\n\nDoD や `acceptance_criteria` を書くときは、「アルバイトの人がチェックリストで○×を付けられるか」で判定する。\n機械○×の床（テスト・字数・exit code）\u002F LLM 観点採点（構成・訴求のチェックリスト）\u002F 本質 doc 参照（spec.md・decisions.md の該当条項）の\n3 層に翻訳する規律、および曖昧形容詞（良い\u002Fちゃんとした\u002Fわかりやすい 等）を検出したときの翻訳手順は\n[references\u002Fcriteria-design.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcriteria-design.md) を参照。\n\n### TDD tags\n\nPlans.md の task には、TDD 判定を明示するタグを内容または DoD に書ける。\n\n| タグ | 意味 | `tdd_required` 推論 |\n|------|------|--------------------|\n| `[tdd:required]` | この task は先に失敗テストを書く必要がある | `true` |\n| `[tdd:skip:\u003Creason>]` | この task は理由つきで TDD を省略する | `false`, `skip_tdd_reason=\u003Creason>` |\n\n`\u003Creason>` は空にしない。\n例: `[tdd:skip:docs-only]`、`[tdd:skip:no-test-framework-detected]`。\n\nタグがない場合の `tdd_required` は次の順で推論する。\n\n1. Plans.md tag: `[tdd:required]` \u002F `[tdd:skip:\u003Creason>]`\n2. files: `src\u002F`, `app\u002F`, `cmd\u002F`, `lib\u002F`, `pkg\u002F`, `internal\u002F`, `go\u002F` など source 実装を含むなら required\n3. TDD 推論: docs-only や test framework なしなら skip reason を付けて not required\n\n### optional briefs \u002F manifest\n\n`harness-plan create` は、必要なときだけ brief を付ける。\n\n- project spec SSOT は project 全体の正解条件を固定する文書で、必要時だけ作る\n- UI を含むタスクでは `design brief`\n- API を含むタスクでは `contract brief`\n- brief は「何を作るか」を短く固定する補助資料で、Plans.md や spec SSOT を置き換えない\n- skill frontmatter の一覧は `scripts\u002Fgenerate-skill-manifest.sh` で machine-readable JSON にできる\n\n参照:\n\n- `docs\u002Fplans\u002Fbriefs-manifest.md`\n- `docs\u002Fplans\u002Fspec-ssot.md`\n\n### マーカー一覧\n\n| マーカー | 意味 |\n|---------|------|\n| `pm:依頼中` | PM から依頼済み |\n| `cc:TODO` | 未着手 |\n| `cc:WIP` | 作業中 |\n| `cc:完了` | Worker 作業完了 |\n| `pm:確認済` | PM レビュー完了 |\n| `blocked` | ブロック中（理由を必ず記載） |\n\n### 計画確定後の導線（非エンジニア向け計画概要）\n\nPlans.md への task append が完了したら、非エンジニアの発注者が計画を判断できるよう\n`harness-plan-brief` を提案する。これは理解・選択肢・リスク・合格条件を 1 枚の HTML に\nまとめた「計画概要」画面で、専門知識なしで読める。実装に入る前の合意形成に使う。\n\n## 関連スキル\n\n- `harness-sync` — 実装と Plans.md を同期する\n- `harness-work` — 計画したタスクを実装する\n- `harness-plan-brief` — 計画概要 HTML（非エンジニア向け、計画確定時に提案）\n- `harness-review` — 実装のレビュー\n- `harness-setup` — プロジェクト初期化\n","# Harness Plan\n\nHarness の統合プランニングスキル。\n以下の3つの旧スキルを統合:\n\n- `planning` (plan-with-agent) — アイデア → Plans.md への落とし込み\n- `plans-management` — タスク状態管理・マーカー更新\n- `sync-status` — Plans.md と実装の同期確認\n\n## Quick Reference\n\n| ユーザー入力 | サブコマンド | 動作 |\n|------------|------------|------|\n| \"計画を作って\" \u002F `\u002Fharness-plan create` | `create` | Spec delta \u002F skip reason → Plans.md task 生成 |\n| \"タスクを追加して\" \u002F `\u002Fharness-plan add` | `add` | Plans.md に新タスク追加 |\n| \"完了にして\" \u002F `\u002Fharness-plan update` | `update` | タスクマーカーを cc:完了 に変更 |\n| \"今どこ？\" \u002F `\u002Fharness-plan sync` | `sync` | 実装とPlans.mdを照合・同期 |\n| `\u002Fharness-sync` | `sync` | 進捗確認（独立 sync surface と同等） |\n| `\u002Fharness-plan create` | `create` | spec.md \u002F Plans.md 二正本の計画作成 |\n| `\u002Fharness-plan list` | `list` | `plans\u002Fmanifest.json` の named Plans を一覧 |\n| `\u002Fharness-plan switch \u003Cname>` | `switch` | active plan を `.claude\u002Fstate\u002Factive-plan.json` に保存 |\n\n## スコープ既定: 今進められる全作業（operator 裁定 2026-07-24）\n\n計画依頼（`create` \u002F 引数なし起動 \u002F 「計画して」）の既定解釈は **「現時点で着手可能なすべての作業」**。\n\n- ユーザーが範囲を明示しない限り、依頼文脈に入る open item（残 phase、未処理 follow-up、既知の改善点、依頼文で言及された問題すべて）を洗い出して計画に含める。勝手に最小サブセットへ絞らない\n- 件数が多い場合も絞り込みではなく、全量を Required \u002F Recommended \u002F Optional \u002F Reject に分類して提示する。除外は Reject として理由を明示する（黙って落とさない）\n- 「一部だけ先に」が妥当と判断する場合は、絞った計画ではなく、全量計画の中の実行順序（Phase 分割 \u002F Depends）として表現する\n\nこの既定は計画候補の洗い出し範囲であり、実装や保護操作の承認ではない。評価・比較だけの依頼は評価を返し、採用済みの変更と提案を区別する。\ntask には目的と理由、担当範囲、検証可能な DoD、利用する証拠、原依頼や適用される承認の参照を残す。実装手順は契約上必要な制約以外を固定しない。\n\n## Literal companion commands（CC 2.1.108+）\n\n- `\u002Frecap`: 久しぶりに戻った時に要約を取り直してから `sync` へ入る\n- `\u002Fundo`: `\u002Frewind` の別名。直前の plan 更新を即座に戻したい時にそのまま使う\n\n## サブコマンド詳細\n\n### 標準の計画品質契約\n\nSee [references\u002Fplanning-quality.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fplanning-quality.md)\n\n`harness-plan` は、spec.md product contract and Plans.md task contract の co-required planning output を作る planning surface である。\nprecedence は `spec.md > sub-spec > Plans.md` のまま維持する。\nPlans.md は task ledger、root `spec.md` は product contract であり、上下関係は崩さない。\n渡された情報をそのまま Plans.md に落とさない。\n計画作成や大きな task 追加では、最新情報・既存仕様・記憶・TeamAgent \u002F サブエージェントによる複数視点の議論を確認し、\nこのプロダクトに取り入れるべき要素だけを task contract に変換する。\n`\u002Fharness-plan create` は `Spec delta` または `Spec skip reason` と `Plans.md` task 生成をセットで返す。\n出力には必ず `Spec delta` または `Spec skip reason` を含める。\n`Spec delta` \u002F `Spec skip reason` は Harness が生成し、consumer は承認・修正だけ行う。\n\n**Non-trivial planning gate**:\n\n単発・軽微タスクでない planning は、TeamAgent またはサブエージェント前提で扱う。\nここでの non-trivial は、複数 task \u002F 複数 file \u002F 複数 session \u002F product behavior \u002F API \u002F data model \u002F 権限 \u002F 課金 \u002F 外部連携 \u002F 配布面 \u002F セキュリティに影響する依頼を指す。\nTask tool が使える場合は Product \u002F Architecture \u002F Security \u002F QA \u002F Skeptic の独立視点を走らせる。\n使えない場合は `サブエージェント未使用` と明示し、同じ観点を単独で分けて評価する。\n各担当には独立して答えられる問い、読む範囲、必要な根拠を渡す。利用可能な同時実行上限を守り、親も仕様照合や統合を進める。関連する追加調査は同じ担当に返す。\n\nnon-trivial planning の出力には、次の検証を必ず含める。\n\n- `team_validation_mode`: `not_required_lightweight` \u002F `native` \u002F `subagent` \u002F `manual-pass` \u002F `unavailable`\n- `spec.md` \u002F sub-spec \u002F `Plans.md` の整合性\n- harness-mem \u002F harness-recall \u002F repo memory による車輪の再発明防止確認\n- プロダクト目的から外れていないか\n- セキュリティ、権限、秘密情報、サプライチェーンに問題がないか\n- lint \u002F formatter baseline があるか。source code changes を含む plan で未設定なら、実装 task の前に setup task を置く\n- ちゃんと動く計画か。つまり test \u002F smoke \u002F CI \u002F review \u002F release gate が task DoD に落ちているか\n\n軽量 task は `team_validation_mode: not_required_lightweight` でよい。\nnon-trivial planning は `native` \u002F `subagent` \u002F `manual-pass` のいずれかを使う。\n`unavailable` のまま Required にしてはいけない。\nProduct \u002F Architecture \u002F Security \u002F QA \u002F Skeptic は検証 perspective であり、agent_type 名ではない。\n利用可能な TeamAgent \u002F Task サブエージェントに perspective として依頼し、任意 agent spawn を要求しない。\nSecurity gate は秘密情報の実読取を要求しない。\n`.env` や secret の read が必要になる場合は Risk Gate として止め、許可された既存 guard \u002F evidence で確認する。\n\n**適用する場面**:\n\n- `create` で新しい計画を作る\n- `add` で product behavior \u002F API \u002F 権限 \u002F 課金 \u002F 外部連携 \u002F 配布面に影響する task を足す\n- ユーザーが外部プロダクト、競合、仕様案、改善案、比較材料を渡した\n- 既存仕様や過去判断との衝突リスクがある\n\n**軽く扱ってよい場面**:\n\n- marker 更新だけの `update`\n- status 照合だけの `sync`\n- typo、format、README\u002FCHANGELOG のみ\n- 既存 spec とテストで正解が固定されている狭い変更\n\n**品質フロー**:\n1. 入力情報を分解し、評価対象・採点軸・不確かな事実を明示する\n2. 最新情報を取得する。外部事実は WebSearch \u002F 公式ドキュメント \u002F 一次情報を優先し、重要点は複数ソースでクロスチェックする\n3. 既存仕様・root `spec.md`・Plans.md・README・docs・CLAUDE.md・関連 skill を確認する\n4. harness-mem \u002F harness-recall \u002F `.claude\u002Fagent-memory\u002F` \u002F `.claude\u002Fstate\u002F` など、利用可能な記憶面を project-scoped で確認する\n5. non-trivial planning では TeamAgent \u002F Task サブエージェントを使い、Product \u002F Architecture \u002F Security \u002F QA \u002F Skeptic など異なる視点で独立レビューする\n6. source code changes を含む plan では lint \u002F formatter baseline を確認し、未設定なら setup task を先行させる\n7. 中立的な採点レビューを出し、Required \u002F Recommended \u002F Optional \u002F Reject に分類する\n8. `$easy` 形式で、提案内容・理由・どうなるのかを報告する\n9. 採用する案だけを root `spec.md` \u002F Plans.md \u002F test task へ落とし込む\n\n### Lane Taxonomy + Stage Gate\n\nFast \u002F Gate \u002F Release は **新 skill ではなく Plans metadata** として扱う。Plans.md の 5 column テンプレート（Task \u002F 内容 \u002F DoD \u002F Depends \u002F Status）は変更せず、\nlane（`[lane:fast]` \u002F `[lane:gate]` \u002F `[lane:release]`）・stage（検証→計画→TDD実装→レビュー→PR closeout の 5 段階）・unknown data contract（`not_observed != absent`、確認できない事実は `unknown` と明示）を\n**内容（Content）または DoD の先頭**に埋め込む。タグ一覧・worked example・stage 別 DoD 例は\n[references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md) を参照。\n\n### create — 計画作成\n\nSee [references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md)\n\nアイデア・要件をヒアリングし、実行可能な Plans.md を生成する。\n\n**フロー**:\n1. 会話コンテキスト確認（直前の議論から抽出 or 新規ヒアリング）\n2. 既存の依頼・仕様・読み取り調査で不足を補い、結論を変える未決事項だけ聞く（max 3問）。軽微な仮定は明示して計画を進める\n3. **計画品質チェック**（最新情報、既存仕様、記憶、TeamAgent \u002F サブエージェント複数視点レビュー、採点）\n4. 技術調査（WebSearch）\n5. 機能リスト抽出\n6. **spec.md \u002F Plans.md 二正本チェック**（Spec delta または Spec skip reason + Plans.md task）\n7. 優先度マトリクス（Required \u002F Recommended \u002F Optional \u002F Reject）\n8. TDD 採用判断（テスト設計）\n9. Plans.md 生成（`cc:TODO` マーカー付き）\n10. **事前確認セクション生成**（plan-time pre-approval）\n11. 次のアクション案内\n\n### create — 事前確認セクション（plan-time pre-approval）\n\n`create` で計画を確定する時は、Plans.md task を出したあと、承認前に **事前確認セクション**を必ず生成する。\n目的は、常設 allowlist で何でも許可するのではなく、作業スコープごとに「発生しそうな stop \u002F ask」を plan 承認時に 1 回だけ前倒しで確認すること。\n\n抽出対象:\n\n- 各 task の対象ファイル、関連 path、想定変更範囲\n- DoD に書いた検証コマンド、PR closeout コマンド、外部 API \u002F CLI 呼び出し\n- `secret-read path`（`.env*`, `secrets\u002F**`, `*.pem`, `*.key`, `.ssh\u002F**`, `.aws\u002F**`, `credentials` など）\n- 外部送信（`git push`, `gh pr create`, `gh api`, `curl` \u002F API call, release \u002F publish \u002F deploy）\n- 破壊的操作（`rm -rf`, migration destructive step, force push, production apply）\n\n固定 format:\n\n```text\n## 事前確認\n- 事項: \u003Csecret-read \u002F external-send \u002F destructive の具体操作>\n  理由: \u003CDoD または task 実行上必要な理由を 1 行>\n  scope: Phase \u003Cphase> \u002F Task \u003Ctask>\n```\n\n出力ルール:\n\n- 1 行の `理由` は secret 値を含めない。path \u002F コマンド名 \u002F 対象サービスまでに留める。\n- plan 承認時に、事前確認セクションの全事項を一括提示し、ユーザーから承認 \u002F 否認を得る。\n- 承認結果は `.claude\u002Fstate\u002Fplan-preapprovals.json` に `plan-preapproval.v2` として記録する。schema は `templates\u002Fschemas\u002Fplan-preapproval.v2.json`。v1 は既存記録の読み取り互換に限る。\n- 記録は `事項 + 理由 1 行 + scope (phase\u002Ftask)` を維持する。`operations` には `secret-read` \u002F `external-send` \u002F `destructive` を列挙する。`paths` \u002F `commands` \u002F `targets` には対象を列挙する。`decision`、`approved_at`、RFC3339 の `expires_at` を入れる。\n- `max_uses` は必要な再試行回数を含む上限を設定する。省略時は 10 回。`uses` は新規承認時に 0 とする。\n- 確認は plan 承認時の 1 回のみ。`harness-work` \u002F `breezing` 実行中、宣言済み事項だけを理由に `AskUserQuestion` を出してはいけない。\n- 記録に無い未計画の secret-read \u002F 外部送信 \u002F 破壊的操作は、従来どおり runtime floor \u002F ask で停止する。安全網を狭めない。\n- secret-read の承認は secret 値の表示許可ではない。必要最小の path を宣言し、work 開始時に project config の `runtimefloor.secretAllow` へ per-run 反映するための入力として扱う。\n\n### spec.md \u002F Plans.md 二正本チェック（デフォルト）\n\nPlans.md は「やるべきこと」の task contract、root `spec.md` は「何が正しいか」の product contract として扱う。\nco-required planning output は両方の出力を必須にするという意味であり、precedence は `spec.md > sub-spec > Plans.md` のまま維持する。\n実装がぶれる可能性がある時は、Plans.md 生成前に root `spec.md` を更新する。\n`create` と product-impacting `add` は毎回 root `spec.md` を読む。\n\n優先する保存先:\n\n1. root `spec.md`\n2. consumer repo に root `spec.md` がない時だけ、既存の project spec \u002F architecture \u002F product compass\n3. consumer repo に root `spec.md` がない時だけ、`docs\u002Fspec\u002F00-project-spec.md`\n4. 既存規約がある repo では、その規約に沿った spec path\n\n作成\u002F更新が必要な条件:\n\n- ユーザーに見える振る舞い、API、データモデル、権限、課金、外部連携を決める task\n- 複数の実装方針があり、選び方で product behavior が変わる task\n- 過去または今回の会話で「仕様が曖昧で実装がぶれた」兆候がある task\n- Plans.md には作業内容があるが、project としての正解条件が安定文書にない task\n\n不要な条件:\n\n- typo、format、dependency bump、README\u002FCHANGELOG のみ\n- 動作変更なしの狭い refactor\n- 既存 spec とテストで正解が十分に固定されている修正\n\n出力契約:\n\n- `Spec delta`: product contract を更新する時に、対象 spec path と変更点を書く\n- `Spec skip reason`: product contract を更新しない時に、理由を書く\n- `Spec delta` \u002F `Spec skip reason` は Harness が生成し、consumer は承認・修正だけ行う\n- docs-only \u002F mechanical task でも `Spec skip reason` を task context \u002F sprint contract に残す\n- missing search result、unavailable memory、未読ファイルを absent と断定しない。`not_observed != absent`\n- ユーザーに spec を一から書かせない。agent が既存 spec と入力から最小 delta を作り、曖昧な時だけ判断分岐を出す\n\n参照:\n\n- `docs\u002Fplans\u002Fspec-ssot.md`\n\n### create 完了時のセッション起動案内（必須）\n\n`create` が終わったら、説明だけで終わらせず、**新しいセッションの起動コマンド** と\n**起動後にそのまま入れる最初の指示プロンプト** をセットで案内する。\n\n優先順位は次の通り:\n\n1. 未完了タスクが 1 件だけ、または最初の 1 件だけ始めるのが自然\n   - 起動コマンド: `claude`\n   - 最初の入力: `\u002Fharness-work \u003Ctask番号>`\n2. 依存の薄いタスクが複数あり、まとめて進めるのが自然\n   - 起動コマンド: `claude`\n   - 最初の入力: `\u002Fbreezing all`\n   - 代替: `\u002Fharness-work all`\n3. 長時間実行や再入が前提\n   - 起動コマンド: `ENABLE_PROMPT_CACHING_1H=1 claude`\n   - 最初の入力: `\u002Fharness-loop all`\n   - 代替: `\u002Fbreezing all`\n\n最低でも次の 3 行を含める:\n\n- `新しいセッションの起動コマンド:`\n- `起動後の最初の入力:`\n- `向いている場面:`\n\n例:\n\n```text\n新しいセッションの起動コマンド: claude\n起動後の最初の入力: \u002Fbreezing all\n向いている場面: Phase 1 の task が複数あり、まとめて進めるほうが自然なため\n```\n\n長時間系を勧める場合は、Claude Code セッション起動コマンドも併記する:\n\n```text\n新しいセッションの起動コマンド: ENABLE_PROMPT_CACHING_1H=1 claude\n起動後の最初の入力: \u002Fharness-loop all\n向いている場面: 5 分を超える待機や resume をまたぐ長時間タスクのため\n```\n\n補足:\n\n- `scripts\u002Fclaude-longrun.sh` はこのリポジトリの開発補助スクリプトで、plugin install 後の consumer 環境には配布されない\n- そのため、consumer 向け案内では常に `ENABLE_PROMPT_CACHING_1H=1 claude` の 1 行コマンドを優先する\n- リポジトリ開発中だけ同等のラッパーを使いたい場合、`bash scripts\u002Fclaude-longrun.sh` はローカル checkout 上では利用してよい\n\n**CI モード** (`--ci`):\nヒアリングなし。既存の Plans.md をそのまま利用してタスク分解のみ行う。\n\n### add — タスク追加\n\nPlans.md に新しいタスクを追加する。\nproduct-impacting な追加では、上の「spec.md \u002F Plans.md 二正本チェック」に従い `Spec delta` または `Spec skip reason` も出力する。\n\n```\n\u002Fharness-plan add タスク名: 詳細説明 [--phase フェーズ番号]\n```\n\nタスクは `cc:TODO` マーカーで追加される。\n\n### update — マーカー更新\n\nタスクのステータスマーカーを変更する。\n`完了` は DoD、必須チェック、必要な review の証拠を確認してから付ける。コミットや自己申告だけでは判定しない。\n\n```\n\u002Fharness-plan update [タスク名|タスク番号] [WIP|完了|blocked]\n```\n\nマーカー対応表:\n\n| コマンド | マーカー |\n|---------|---------|\n| `WIP` | `cc:WIP` |\n| `完了` \u002F `done` | `cc:完了` |\n| `blocked` | `blocked` |\n| `TODO` | `cc:TODO` |\n\n### sync — 進捗同期\n\n実装状況と Plans.md を照合し、差分を検出・更新する（Plans.md 現状取得 → フォーマット検出 → git 状況取得 → agent trace 分析 → 差分検出 → マーカー修正提案 → 次アクション提示）。\n`cc:完了` タスクが 1 件以上あれば、見積もり精度・ブロック原因・スコープ変動を分析するレトロスペクティブをデフォルト ON で実行する（`sync --no-retro` でスキップ）。\n状況確認だけなら読み取りと報告で終える。同期更新を明示依頼された場合は証拠に一致する更新を進め、永続 memory 記録はその記録を明示依頼された場合だけ行う。\nStep 0-6 の完全版・harness-mem への記録手順は [references\u002Fsync.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsync.md) を参照。\n\n### team mode \u002F issue bridge\n\nPlans.md は正本のまま維持し、GitHub Issue 連携は opt-in の team mode だけで使う。\n\n- solo 開発では bridge を使わない\n- team mode は tracking issue を 1 つ作り、その配下に task ごとの sub-issue payload を dry-run で生成する\n- `scripts\u002Fplans-issue-bridge.sh` は実際に GitHub を更新せず、常に dry-run の payload を返す\n- Plans.md への変更はこの bridge では行わない\n\n参照:\n\n- `docs\u002Fplans\u002Fteam-mode.md`\n\n### named Plans\n\n複数の Plans.md を使う場合は `plans\u002Fmanifest.json` を正本にして、名前で選択する（1 run では 1 つの named plan だけを使う。long-running \u002F CI \u002F issue bridge では active pointer に頼らず `--plan \u003Cname>` を渡す。manifest path は project root 相対のみ）。\n\n```bash\nscripts\u002Fplan-registry.sh list\nscripts\u002Fplan-registry.sh switch roadmap\nscripts\u002Fplans-issue-bridge.sh --plan roadmap --format markdown\nnode scripts\u002Fgenerate-sprint-contract.js --plan roadmap 9.1.1\n```\n\n参照: `docs\u002Fplans\u002Fnamed-plans.md`\n\n## Plans.md フォーマット規約\n\n### フォーマット\n\n5 カラム（Task \u002F 内容 \u002F DoD \u002F Depends \u002F Status）の Markdown table。DoD は Yes\u002FNo 判定できる検証可能な 1 行（「いい感じ」「ちゃんと動く」は禁止）。\nDepends は `-`（依存なし）\u002F タスク番号 \u002F カンマ区切り複数 \u002F フェーズ依存のいずれか。生成テンプレート全文（Purpose 行含む）は\n[references\u002Fcreate.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcreate.md) を参照。\n\n### DoD \u002F acceptance_criteria の採点設計\n\nDoD や `acceptance_criteria` を書くときは、「アルバイトの人がチェックリストで○×を付けられるか」で判定する。\n機械○×の床（テスト・字数・exit code）\u002F LLM 観点採点（構成・訴求のチェックリスト）\u002F 本質 doc 参照（spec.md・decisions.md の該当条項）の\n3 層に翻訳する規律、および曖昧形容詞（良い\u002Fちゃんとした\u002Fわかりやすい 等）を検出したときの翻訳手順は\n[references\u002Fcriteria-design.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fcriteria-design.md) を参照。\n\n### TDD tags\n\nPlans.md の task には、TDD 判定を明示するタグを内容または DoD に書ける。\n\n| タグ | 意味 | `tdd_required` 推論 |\n|------|------|--------------------|\n| `[tdd:required]` | この task は先に失敗テストを書く必要がある | `true` |\n| `[tdd:skip:\u003Creason>]` | この task は理由つきで TDD を省略する | `false`, `skip_tdd_reason=\u003Creason>` |\n\n`\u003Creason>` は空にしない。\n例: `[tdd:skip:docs-only]`、`[tdd:skip:no-test-framework-detected]`。\n\nタグがない場合の `tdd_required` は次の順で推論する。\n\n1. Plans.md tag: `[tdd:required]` \u002F `[tdd:skip:\u003Creason>]`\n2. files: `src\u002F`, `app\u002F`, `cmd\u002F`, `lib\u002F`, `pkg\u002F`, `internal\u002F`, `go\u002F` など source 実装を含むなら required\n3. TDD 推論: docs-only や test framework なしなら skip reason を付けて not required\n\n### optional briefs \u002F manifest\n\n`harness-plan create` は、必要なときだけ brief を付ける。\n\n- project spec SSOT は project 全体の正解条件を固定する文書で、必要時だけ作る\n- UI を含むタスクでは `design brief`\n- API を含むタスクでは `contract brief`\n- brief は「何を作るか」を短く固定する補助資料で、Plans.md や spec SSOT を置き換えない\n- skill frontmatter の一覧は `scripts\u002Fgenerate-skill-manifest.sh` で machine-readable JSON にできる\n\n参照:\n\n- `docs\u002Fplans\u002Fbriefs-manifest.md`\n- `docs\u002Fplans\u002Fspec-ssot.md`\n\n### マーカー一覧\n\n| マーカー | 意味 |\n|---------|------|\n| `pm:依頼中` | PM から依頼済み |\n| `cc:TODO` | 未着手 |\n| `cc:WIP` | 作業中 |\n| `cc:完了` | Worker 作業完了 |\n| `pm:確認済` | PM レビュー完了 |\n| `blocked` | ブロック中（理由を必ず記載） |\n\n### 計画確定後の導線（非エンジニア向け計画概要）\n\nPlans.md への task append が完了したら、非エンジニアの発注者が計画を判断できるよう\n`harness-plan-brief` を提案する。これは理解・選択肢・リスク・合格条件を 1 枚の HTML に\nまとめた「計画概要」画面で、専門知識なしで読める。実装に入る前の合意形成に使う。\n\n## 関連スキル\n\n- `harness-sync` — 実装と Plans.md を同期する\n- `harness-work` — 計画したタスクを実装する\n- `harness-plan-brief` — 計画概要 HTML（非エンジニア向け、計画確定時に提案）\n- `harness-review` — 実装のレビュー\n- `harness-setup` — プロジェクト初期化\n",{"kind":46,"name":5,"pair":54,"role":55,"owner":56,"shape":46,"since":57,"effort":58,"purpose":59,"trigger":60,"description":7,"allowed-tools":61,"argument-hint":69,"description-en":7,"description-ja":70,"user-invocable":71},"harness-sync","generator","harness-core","2026-05-05","medium","Maintain co-required planning output for the spec.md product contract and Plans.md task contract","create a plan, add tasks, update Plans.md, check progress",[62,63,64,35,65,66,67,68],"Read","Write","Edit","Grep","Glob","WebSearch","Task","[create|add|update|sync|sync --no-retro|--ci]","HAR:調査・採点・記憶確認・TeamAgent\u002Fサブエージェント検証つきのタスク計画、Plans.md管理、進捗同期を担当。計画作って、タスク追加、Plans.md更新、完了マーク、進捗確認で起動。実装・レビュー・リリースには使わない。",true,"main","c2304c325d4432f51d632e0586d886767b0f41ea","codex\u002F.codex\u002Fskills\u002Fharness-plan",304,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness","https:\u002F\u002Fgithub.com\u002FChachamaru127","https:\u002F\u002Fcanai.jp\u002F","Going all-in on the AI business from April 2025\r\nOSS release: 3k Stars\r\nAI adoption starting with \"I want\"\r\nAX Support | Tokenomics | AISDR |","2026-11-11 17:18:34",{"source":8,"skillName":5,"commands":82,"prompt":92,"zipAvailable":71},[83,86,89],{"tool":84,"command":85},"npx","npx skills add Chachamaru127\u002Fclaude-code-harness --skill harness-plan",{"tool":87,"command":88},"bunx","bunx skills add Chachamaru127\u002Fclaude-code-harness --skill harness-plan",{"tool":90,"command":91},"pnpm","pnpm dlx skills add Chachamaru127\u002Fclaude-code-harness --skill harness-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002FSKILL.md",[94,100,104,108],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fcreate.md","REFERENCE","参考文档",22635,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002Freferences\u002Fcreate.md",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fcriteria-design.md",5030,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002Freferences\u002Fcriteria-design.md",{"path":105,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fplanning-quality.md",15877,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002Freferences\u002Fplanning-quality.md",{"path":109,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fsync.md",6623,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fcodex\u002F.codex\u002Fskills\u002Fharness-plan\u002Freferences\u002Fsync.md",[113,129,137,155,184,209],{"skillNo":114,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":121,"publishedAt":49},"01M6C4VZCJB9EN3KZXGNARAF6P","escape-skill","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fzz-review-escape\u002FSKILL.md",[118],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[122,123,124,125,126,127,128],"escape skill","escape","Tools","false","true","path","quoted",{"skillNo":130,"name":131,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":49},"01M6C4VYAJW332S5R2MM3RNE0G","zz-review-empty","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fzz-review-empty\u002FSKILL.md",[],[28,135,136,125,126],"zz review empty","empty",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":49},"01M6C4VWW4GNAZ2680GY04S3EW","session-send","This skill should be used when the user asks to notify other session, requests a session handoff, says tell other agent, or needs a cross-session message.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fsession-send\u002FSKILL.md",[143],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},[145,146,147,148,149,35,150,151,152,153,154],"session","session send","send","handoff","session handoff","user","message","notify","requests","when",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":49},"01M6C4VSMYH6XQGR087HQ9Y7HT","memory","Manage SSOT, memory, and cross-tool memory search. Guardian of decisions.md and patterns.md. Use when user mentions memory, SSOT, decisions.md, patterns.md, merging, migration, SSOT promotion, sync memory, save learnings, memory search, harness-mem, past decisions, or record this. Do NOT load for: implementation work, reviews, ad-hoc notes, or in-session logging.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fmemory\u002FSKILL.md",[161],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},[157,163,164,165,26,166,167,168,35,169,170,171,172,33,173,174,150,145,175,176,177,178,179,180,181,126,182,183,154],"MCP","sync","notes","search","memory search","guardian","migrate","tool","work","decisions","write","edit","use","migration","manage","do","learnings","promotion","reviews","load","for",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":49},"01M6C4VQ3507BV9XRX4BDSES6J","maintenance","File cleanup and archiving. Tidies up bloated Plans.md, session-log.md, old logs, and state files. Trigger: \u002Fmaintenance, cleanup, archive, organize, split session-log. Do NOT load for: implementation, review, release, new feature development.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fmaintenance\u002FSKILL.md",[],[186,28,191,192,193,40,194,195,196,35,197,198,33,173,174,199,145,200,201,202,178,203,204,205,206,207,126,182,183,208],"development","cleanup","run","state","file","logs","archive","grep","new feature","up","log","files","feature","plans","trigger","整理","split","new",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":227,"publishedAt":49},"01M6C4VK473YJ872RNMBYK7P4R","japanese-writing-drafter","Detect when the operator corrects the agent's Japanese phrasing mid-conversation (rewrites a sentence, calls out a style problem, says 'this wording is bad, say it like X instead') and draft a pending writing-rule proposal into ~\u002F.claude\u002Fwriting-lint\u002Fproposals.jsonl for later human review. This skill is the ONLY writer of proposals.jsonl — it never edits rules.jsonl and never sets status to anything but pending. Promotion to rules.jsonl only happens via the human-run scripts\u002Fwriting-rule-approve.sh. Use when user mentions writing-rule proposal, 表現を直して, 文体を直して, その言い方はNG, writing lint 提案, 指摘をルール化して. Do NOT load for: approving or rejecting proposals (use scripts\u002Fwriting-rule-approve.sh), listing pending proposals (use scripts\u002Fwriting-rule-list.sh), or scanning text against the existing dictionary (the writinglint engine \u002F PostToolUse hook does that).","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fjapanese-writing-drafter\u002FSKILL.md",[215,218,221,222],{"categoryNo":216,"categoryName":217,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":219,"categoryName":220,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":223,"categoryName":224,"taxonomyType":225,"taxonomyTypeDesc":226},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[228,229,230,28,231,193,232,233,35,234,235,236,237,33,238,239,175,240,241,242,243,244,245,246,247,248,249,250,251,252,154,253],"writing","japanese writing drafter","japanese","status","lint","operator","提案","text","engine","Rules","list","proposals","never","only","scanning","say","human review","later","conversation","writer","human","scripts","problem","proposal","jsonl","listing"]