/harness-plan

name: harness-plan
description: "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."
description-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."
description-ja: "HAR:調査・採点・記憶確認・TeamAgent/サブエージェント検証つきのタスク計画、Plans.md管理、進捗同期を担当。計画作って、タスク追加、Plans.md更新、完了マーク、進捗確認で起動。実装・レビュー・リリースには使わない。"
kind: workflow
purpose: "Maintain co-required planning output for the spec.md product contract and Plans.md task contract"
trigger: "create a plan, add tasks, update Plans.md, check progress"
shape: workflow
role: generator
pair: harness-sync
owner: harness-core
since: "2026-05-05"
allowed-tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob", "WebSearch", "Task"]
argument-hint: "[create|add|update|sync|sync --no-retro|--ci]"
user-invocable: true
effort: medium

Harness Plan

Harness の統合プランニングスキル。 以下の3つの旧スキルを統合:

• `planning` (plan-with-agent) — アイデア → Plans.md への落とし込み
• `plans-management` — タスク状態管理・マーカー更新
• `sync-status` — Plans.md と実装の同期確認

Quick Reference

| ユーザー入力 | サブコマンド | 動作 | |------------|------------|------| | "計画を作って" / `/harness-plan create` | `create` | Spec delta / skip reason → Plans.md task 生成 | | "タスクを追加して" / `/harness-plan add` | `add` | Plans.md に新タスク追加 | | "完了にして" / `/harness-plan update` | `update` | タスクマーカーを cc:完了 に変更 | | "今どこ？" / `/harness-plan sync` | `sync` | 実装とPlans.mdを照合・同期 | | `/harness-sync` | `sync` | 進捗確認（独立 sync surface と同等） | | `/harness-plan create` | `create` | spec.md / Plans.md 二正本の計画作成 | | `/harness-plan list` | `list` | `plans/manifest.json` の named Plans を一覧 | | `/harness-plan switch <name>` | `switch` | active plan を `.claude/state/active-plan.json` に保存 |

スコープ既定: 今進められる全作業（operator 裁定 2026-07-24）

計画依頼（`create` / 引数なし起動 / 「計画して」）の既定解釈は **「現時点で着手可能なすべての作業」**。

• ユーザーが範囲を明示しない限り、依頼文脈に入る open item（残 phase、未処理 follow-up、既知の改善点、依頼文で言及された問題すべて）を洗い出して計画に含める。勝手に最小サブセットへ絞らない
• 件数が多い場合も絞り込みではなく、全量を Required / Recommended / Optional / Reject に分類して提示する。除外は Reject として理由を明示する（黙って落とさない）
• 「一部だけ先に」が妥当と判断する場合は、絞った計画ではなく、全量計画の中の実行順序（Phase 分割 / Depends）として表現する

この既定は計画候補の洗い出し範囲であり、実装や保護操作の承認ではない。評価・比較だけの依頼は評価を返し、採用済みの変更と提案を区別する。 task には目的と理由、担当範囲、検証可能な DoD、利用する証拠、原依頼や適用される承認の参照を残す。実装手順は契約上必要な制約以外を固定しない。

Literal companion commands（CC 2.1.108+）

• `/recap`: 久しぶりに戻った時に要約を取り直してから `sync` へ入る
• `/undo`: `/rewind` の別名。直前の plan 更新を即座に戻したい時にそのまま使う

サブコマンド詳細

標準の計画品質契約

See [references/planning-quality.md](${CLAUDE_SKILL_DIR}/references/planning-quality.md)

`harness-plan` は、spec.md product contract and Plans.md task contract の co-required planning output を作る planning surface である。 precedence は `spec.md > sub-spec > Plans.md` のまま維持する。 Plans.md は task ledger、root `spec.md` は product contract であり、上下関係は崩さない。 渡された情報をそのまま Plans.md に落とさない。 計画作成や大きな task 追加では、最新情報・既存仕様・記憶・TeamAgent / サブエージェントによる複数視点の議論を確認し、 このプロダクトに取り入れるべき要素だけを task contract に変換する。 `/harness-plan create` は `Spec delta` または `Spec skip reason` と `Plans.md` task 生成をセットで返す。 出力には必ず `Spec delta` または `Spec skip reason` を含める。 `Spec delta` / `Spec skip reason` は Harness が生成し、consumer は承認・修正だけ行う。

**Non-trivial planning gate**:

単発・軽微タスクでない planning は、TeamAgent またはサブエージェント前提で扱う。 ここでの non-trivial は、複数 task / 複数 file / 複数 session / product behavior / API / data model / 権限 / 課金 / 外部連携 / 配布面 / セキュリティに影響する依頼を指す。 Task tool が使える場合は Product / Architecture / Security / QA / Skeptic の独立視点を走らせる。 使えない場合は `サブエージェント未使用` と明示し、同じ観点を単独で分けて評価する。 各担当には独立して答えられる問い、読む範囲、必要な根拠を渡す。利用可能な同時実行上限を守り、親も仕様照合や統合を進める。関連する追加調査は同じ担当に返す。

non-trivial planning の出力には、次の検証を必ず含める。

• `team_validation_mode`: `not_required_lightweight` / `native` / `subagent` / `manual-pass` / `unavailable`
• `spec.md` / sub-spec / `Plans.md` の整合性
• harness-mem / harness-recall / repo memory による車輪の再発明防止確認
• プロダクト目的から外れていないか
• セキュリティ、権限、秘密情報、サプライチェーンに問題がないか
• lint / formatter baseline があるか。source code changes を含む plan で未設定なら、実装 task の前に setup task を置く
• ちゃんと動く計画か。つまり test / smoke / CI / review / release gate が task DoD に落ちているか

軽量 task は `team_validation_mode: not_required_lightweight` でよい。 non-trivial planning は `native` / `subagent` / `manual-pass` のいずれかを使う。 `unavailable` のまま Required にしてはいけない。 Product / Architecture / Security / QA / Skeptic は検証 perspective であり、agent_type 名ではない。 利用可能な TeamAgent / Task サブエージェントに perspective として依頼し、任意 agent spawn を要求しない。 Security gate は秘密情報の実読取を要求しない。 `.env` や secret の read が必要になる場合は Risk Gate として止め、許可された既存 guard / evidence で確認する。

**適用する場面**:

• `create` で新しい計画を作る
• `add` で product behavior / API / 権限 / 課金 / 外部連携 / 配布面に影響する task を足す
• ユーザーが外部プロダクト、競合、仕様案、改善案、比較材料を渡した
• 既存仕様や過去判断との衝突リスクがある

**軽く扱ってよい場面**:

• marker 更新だけの `update`
• status 照合だけの `sync`
• typo、format、README/CHANGELOG のみ
• 既存 spec とテストで正解が固定されている狭い変更

**品質フロー**: 1. 入力情報を分解し、評価対象・採点軸・不確かな事実を明示する 2. 最新情報を取得する。外部事実は WebSearch / 公式ドキュメント / 一次情報を優先し、重要点は複数ソースでクロスチェックする 3. 既存仕様・root `spec.md`・Plans.md・README・docs・CLAUDE.md・関連 skill を確認する 4. harness-mem / harness-recall / `.claude/agent-memory/` / `.claude/state/` など、利用可能な記憶面を project-scoped で確認する 5. non-trivial planning では TeamAgent / Task サブエージェントを使い、Product / Architecture / Security / QA / Skeptic など異なる視点で独立レビューする 6. source code changes を含む plan では lint / formatter baseline を確認し、未設定なら setup task を先行させる 7. 中立的な採点レビューを出し、Required / Recommended / Optional / Reject に分類する 8. `$easy` 形式で、提案内容・理由・どうなるのかを報告する 9. 採用する案だけを root `spec.md` / Plans.md / test task へ落とし込む

Lane Taxonomy + Stage Gate

Fast / Gate / Release は **新 skill ではなく Plans metadata** として扱う。Plans.md の 5 column テンプレート（Task / 内容 / DoD / Depends / Status）は変更せず、 lane（`[lane:fast]` / `[lane:gate]` / `[lane:release]`）・stage（検証→計画→TDD実装→レビュー→PR closeout の 5 段階）・unknown data contract（`not_observed != absent`、確認できない事実は `unknown` と明示）を **内