菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/whyzsm/tiny-agents --skill harness-plan命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Single-Agent T-MAX Java backend architecture and engineering rule package. Use when Codex must design, implement, review, or diagnose T-MAX backend services involving Java 8, Spring Boot, Kylin, MyBatis XML, TiDB/MySQL, Apollo/Nacos, Feign, AnePageHelper, ResponseResult/DataGridResult, UEP export, Redis, RabbitMQ, or Maven multi-module repositories. Routes one Agent through repository intake, architecture decisions, API/data contracts, implementation diagnosis, quality/security review, and bounded evidence loops while keeping builds, tests, live calls, commits, and pushes as separate authority boundaries.
Create polished consulting-style single-file HTML research reports from messy business notes, screenshots, metrics, and iterative user feedback. Use this skill whenever the user asks for a 咨询风/艾瑞咨询风/研究报告/汇报报告/HTML报告, wants business or AI landing-practice material turned into a management-facing report, asks to add charts/diagrams, or asks to update report metrics and keep the whole HTML report consistent.
Audit HarmonyOS applications for AppGallery/AGC release readiness, including Huawei UX/HMI controls, system-feature integrations, and performance gates for multi-input interaction, latency, frame rate, content display, memory, and CPU. Use when users ask for 鸿蒙上架自检、应用市场审核、AGC发布前检查、控件/系统特性/人机交互/签名/隐私/权限/截图/性能核对或 release 包门禁, especially for Stage-model projects with module.json5, build-profile.json5, hvigorw, and local-first data constraints.
基于 SOC 职业分类
正在显示 SKILL.md
| 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 の統合プランニングスキル。 以下の3つの旧スキルを統合:
planning (plan-with-agent) — アイデア → Plans.md への落とし込みplans-management — タスク状態管理・マーカー更新sync-status — Plans.md と実装の同期確認| ユーザー入力 | サブコマンド | 動作 |
|---|---|---|
"計画を作って" / /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 に保存 |
/recap: 久しぶりに戻った時に要約を取り直してから sync へ入る/undo: /rewind の別名。直前の plan 更新を即座に戻したい時にそのまま使うSee 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 に変換する。
は または と task 生成をセットで返す。
出力には必ず または を含める。
/ は Harness が生成し、consumer は承認・修正だけ行う。
/harness-plan createSpec deltaSpec skip reasonPlans.mdSpec deltaSpec skip reasonSpec deltaSpec skip reasonNon-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 / unavailablespec.md / sub-spec / Plans.md の整合性軽量 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 を足す軽く扱ってよい場面:
updatesync品質フロー:
spec.md・Plans.md・README・docs・CLAUDE.md・関連 skill を確認する.claude/agent-memory/ / .claude/state/ など、利用可能な記憶面を project-scoped で確認する$easy 形式で、提案内容・理由・どうなるのかを報告するspec.md / Plans.md / test task へ落とし込むアイデア・要件をヒアリングし、実行可能な Plans.md を生成する。
フロー:
cc:TODO マーカー付き）Plans.md は「やるべきこと」の task contract、root spec.md は「何が正しいか」の product contract として扱う。
co-required planning output は両方の出力を必須にするという意味であり、precedence は spec.md > sub-spec > Plans.md のまま維持する。
実装がぶれる可能性がある時は、Plans.md 生成前に root spec.md を更新する。
create と product-impacting add は毎回 root spec.md を読む。
優先する保存先:
spec.mdspec.md がない時だけ、既存の project spec / architecture / product compassspec.md がない時だけ、docs/spec/00-project-spec.md作成/更新が必要な条件:
不要な条件:
出力契約:
Spec delta: product contract を更新する時に、対象 spec path と変更点を書くSpec skip reason: product contract を更新しない時に、理由を書くSpec delta / Spec skip reason は Harness が生成し、consumer は承認・修正だけ行うSpec skip reason を task context / sprint contract に残すnot_observed != absent参照:
docs/plans/spec-ssot.mdcreate が終わったら、説明だけで終わらせず、新しいセッションの起動コマンド と
起動後にそのまま入れる最初の指示プロンプト をセットで案内する。
優先順位は次の通り:
claude/harness-work <task番号>claude/breezing all/harness-work allENABLE_PROMPT_CACHING_1H=1 claude/harness-loop all/breezing all最低でも次の 3 行を含める:
新しいセッションの起動コマンド:起動後の最初の入力:向いている場面:例:
新しいセッションの起動コマンド: claude
起動後の最初の入力: /breezing all
向いている場面: Phase 1 の task が複数あり、まとめて進めるほうが自然なため
長時間系を勧める場合は、Claude Code セッション起動コマンドも併記する:
新しいセッションの起動コマンド: ENABLE_PROMPT_CACHING_1H=1 claude
起動後の最初の入力: /harness-loop all
向いている場面: 5 分を超える待機や resume をまたぐ長時間タスクのため
補足:
scripts/claude-longrun.sh はこのリポジトリの開発補助スクリプトで、plugin install 後の consumer 環境には配布されないENABLE_PROMPT_CACHING_1H=1 claude の 1 行コマンドを優先するbash scripts/claude-longrun.sh はローカル checkout 上では利用してよいCI モード (--ci):
ヒアリングなし。既存の Plans.md をそのまま利用してタスク分解のみ行う。
Plans.md に新しいタスクを追加する。
product-impacting な追加では、上の「spec.md / Plans.md 二正本チェック」に従い Spec delta または Spec skip reason も出力する。
/harness-plan add タスク名: 詳細説明 [--phase フェーズ番号]
タスクは cc:TODO マーカーで追加される。
タスクのステータスマーカーを変更する。
/harness-plan update [タスク名|タスク番号] [WIP|完了|blocked]
マーカー対応表:
| コマンド | マーカー |
|---|---|
WIP | cc:WIP |
完了 / done | cc:完了 |
blocked | blocked |
TODO | cc:TODO |
実装状況と Plans.md を照合し、差分を検出・更新する。
フロー:
.claude/state/agent-trace.jsonl）レトロスペクティブ（デフォルト ON）:
cc:完了 タスクが 1 件以上あれば自動的に振り返りを実行する。
見積もり精度、ブロック原因パターン、スコープ変動を分析し、学びを記録。
sync --no-retro で明示的にスキップ可能。
Plans.md は正本のまま維持し、GitHub Issue 連携は opt-in の team mode だけで使う。
scripts/plans-issue-bridge.sh は実際に GitHub を更新せず、常に dry-run の payload を返す参照:
docs/plans/team-mode.md複数の Plans.md を使う場合は plans/manifest.json を正本にして、名前で選択する。
scripts/plan-registry.sh list
scripts/plan-registry.sh switch roadmap
scripts/plans-issue-bridge.sh --plan roadmap --format markdown
node scripts/generate-sprint-contract.js --plan roadmap 9.1.1
運用ルール:
--plan <name> を渡す..、repo 外 symlink は拒否される参照:
docs/plans/named-plans.md# [プロジェクト名] Plans.md
作成日: YYYY-MM-DD
---
## Phase N: フェーズ名
| Task | 内容 | DoD | Depends | Status |
|------|------|-----|---------|--------|
| N.1 | 説明 | テスト通過 | - | cc:TODO |
| N.2 | 説明 | lint エラー 0 | N.1 | cc:WIP |
| N.3 | 説明 | マイグレーション実行可能 | N.1, N.2 | cc:完了 |
DoD（Definition of Done）: 検証可能な完了条件を 1 行で記述。「いい感じ」「ちゃんと動く」は禁止。Yes/No で判定できる形にする。
Depends: タスク間の依存関係。-（依存なし）、タスク番号（N.1）、カンマ区切り（N.1, N.2）、フェーズ依存（Phase N）。
Plans.md の task には、TDD 判定を明示するタグを内容または DoD に書ける。
| タグ | 意味 | tdd_required 推論 |
|---|---|---|
[tdd:required] | この task は先に失敗テストを書く必要がある | true |
[tdd:skip:<reason>] | この task は理由つきで TDD を省略する | false, skip_tdd_reason=<reason> |
<reason> は空にしない。
例: [tdd:skip:docs-only]、[tdd:skip:no-test-framework-detected]。
タグがない場合の tdd_required は次の順で推論する。
[tdd:required] / [tdd:skip:<reason>]src/, app/, cmd/, lib/, pkg/, internal/, go/ など source 実装を含むなら requiredharness-plan create は、必要なときだけ brief を付ける。
design briefcontract briefscripts/generate-skill-manifest.sh で machine-readable JSON にできる参照:
docs/plans/briefs-manifest.mddocs/plans/spec-ssot.md| マーカー | 意味 |
|---|---|
pm:依頼中 | PM から依頼済み |
cc:TODO | 未着手 |
cc:WIP | 作業中 |
cc:完了 | Worker 作業完了 |
pm:確認済 | PM レビュー完了 |
blocked | ブロック中（理由を必ず記載） |
harness-sync — 実装と Plans.md を同期するharness-work — 計画したタスクを実装するharness-review — 実装のレビューharness-setup — プロジェクト初期化