create-plan: v1.2.1 — change default save path to ~/workspace/plans/ (was ~/workspace/<current-workspace>/plans/)
This commit is contained in:
Hermes Agent
@@ -1,21 +1,23 @@
|
||||
---
|
||||
name: create-plan
|
||||
description: "Multi-agent plan-build pipeline: brief → research → assembly → Claude evidence-diff → URL re-verify → reconcile. Triggered by 'create plan for X', 'plan this', 'draft a plan for', 'build a plan for'."
|
||||
version: 1.1.1
|
||||
description: "Multi-agent plan-build pipeline: brief → research → assembly → self-review → multi-model peer validation (Claude + general + dev) → URL re-verify → reconcile. Triggered by 'create plan for X', 'plan this', 'draft a plan for', 'build a plan for'."
|
||||
version: 1.2.1
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
platforms: [linux]
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [planning, plan, create-plan, orchestration, multi-agent, delegation]
|
||||
related_skills: [ask-hermes, ask-claude, deep-research, writing-plans, subagent-driven-development]
|
||||
related_skills: [ask-hermes, ask-claude, deep-research, writing-plans, subagent-driven-development, hermes-config-bulk-update]
|
||||
---
|
||||
|
||||
# create-plan — Multi-Agent Plan-Build Pipeline (Dispatcher)
|
||||
|
||||
## 1. Overview
|
||||
|
||||
The `create-plan` skill is a thin dispatcher that orchestrates a 7-phase plan-build pipeline (Phase 0 through Phase 6). The dispatcher runs Phase 0 — an interactive brief with the operator — then spawns a peer `ask-hermes` **curator** session that owns Phases 1 through 6 end-to-end. The curator dispatches `deep-research` for current evidence, runs assembly itself using `writing-plans` methodology, dispatches `ask-claude` for the adversarial evidence-diff, performs URL re-verification of the plan's specific cited claims, and reconciles the final plan.
|
||||
The `create-plan` skill is a thin dispatcher that orchestrates a multi-phase plan-build pipeline (Phase 0 through Phase 6, with optional Phase 4b/4c peer rounds). The dispatcher runs Phase 0 — an interactive brief with the operator — then spawns a peer `ask-hermes` **curator** session that owns Phases 1 through 6 end-to-end. The curator dispatches `deep-research` for current evidence, runs assembly itself using `writing-plans` methodology, dispatches `ask-claude` for the first adversarial pass, dispatches `ask-hermes` (general profile) and optionally `ask-dev` (dev profile) for additional cross-model peer validation, performs URL re-verification of the plan's specific cited claims, and reconciles the final plan.
|
||||
|
||||
**Why multi-model peer validation (Phases 4a/4b/4c):** Different models have different blind spots. Claude Opus on 10.0.0.28 catches structural issues and evidence-diff gaps. A peer on the general profile (minimax-m3 by default) catches implementation-level issues and applies the same "would the agent actually follow this?" check. A peer on the dev profile (deepseek-v4-pro) catches issues neither of the other two saw. The dev profile is intentionally a different model for this reason. In the operator's actual practice (4-round validation, July 2026), the dev peer caught a persistent-side-effect issue on a `hermes config set` call that neither Claude nor the general peer flagged — and was also wrong about a config-schema claim that a 5-second live test disproved. Both directions of value are real. See `references/multi-model-peer-validation.md` for the full pattern.
|
||||
|
||||
**Output files:** `<topic>_plan.md` (actionable, validated) and `<topic>_research.md` (evidence, with appended re-verify log). The 600-turn ceiling is a safety net, not a budget — the curator is allowed to take as long as it needs. Correctness > speed. The user resumes the **curator** (not the dispatcher) to iterate, add constraints, or request re-validation. Per `ask-hermes` Turn Budget section (and §5.3 below), the create-plan curator always uses `--max-turns 600 --yolo`; the default 20 is not appropriate for evidence-based plan builds.
|
||||
|
||||
@@ -73,8 +75,8 @@ The `create-plan` skill is a thin dispatcher that orchestrates a 7-phase plan-bu
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 4: Adversarial validation [curator →] │
|
||||
│ - curator dispatches ask-claude (Opus) │
|
||||
│ Phase 4a: Adversarial validation (Claude) [curator →] │
|
||||
│ - curator dispatches ask-claude (Opus on 10.0.0.28) │
|
||||
│ - curator extracts the structured-claims/citations section │
|
||||
│ of <topic>_research.md (~10KB cap) and inlines BOTH the │
|
||||
│ full <topic>_plan.md AND the extracted claims │
|
||||
@@ -85,6 +87,28 @@ The `create-plan` skill is a thin dispatcher that orchestrates a 7-phase plan-bu
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 4b: Peer validation (general model) [curator →] │
|
||||
│ - curator dispatches ask-hermes (general profile) for an │
|
||||
│ independent validation from a different model │
|
||||
│ - general peer reads the plan + researches live, can verify │
|
||||
│ things Claude structurally cannot (paths exist, config │
|
||||
│ accepted, distribution patterns) │
|
||||
│ - Output: validation report from general peer │
|
||||
│ - Default: 1 round. Skip only if Phase 4a found zero findings │
|
||||
│ AND the plan is short (<100 lines). │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 4c: Peer validation (dev model, optional) [curator →] │
|
||||
│ - curator dispatches ask-dev (dev profile) for a third-model │
|
||||
│ blindspot check │
|
||||
│ - dev peer is a different model (deepseek-v4-pro vs. │
|
||||
│ minimax-m3) and catches different issues than the first two │
|
||||
│ - Only run if Phase 4a or 4b found release-blockers. │
|
||||
│ - Output: validation report from dev peer │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 5: URL re-verification [curator] │
|
||||
│ - curator re-fetches URLs backing the SPECIFIC version │
|
||||
│ numbers, commands, and setup steps the PLAN cites │
|
||||
@@ -96,8 +120,10 @@ The `create-plan` skill is a thin dispatcher that orchestrates a 7-phase plan-bu
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase 6: Final reconcile [curator] │
|
||||
│ - curator reads Claude's report + re-verify log │
|
||||
│ - applies agreed changes, ignores disagreements │
|
||||
│ - curator reads ALL validation reports (4a, 4b, 4c if run) │
|
||||
│ + re-verify log │
|
||||
│ - applies agreed changes from each, runs disagreement scan │
|
||||
│ on each │
|
||||
│ - Output: <topic>_plan.md final │
|
||||
│ - reports: curator_session_id for resume │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
@@ -181,7 +207,7 @@ The dispatcher surfaces up to **10** clarifying questions in **priority order**.
|
||||
```
|
||||
=== FROZEN BRIEF BEGIN ===
|
||||
Topic: <topic from operator>
|
||||
Target save dir: ~/workspace/<current-workspace>/plans/
|
||||
Target save dir: ~/workspace/plans/
|
||||
|
||||
Q1 (Scope): <operator's answer or "you decide">
|
||||
Q2 (Constraints): <operator's answer or "you decide">
|
||||
@@ -260,7 +286,7 @@ session_id: <id>
|
||||
=== CREATE-PLAN DISPATCH COMPLETE ===
|
||||
curator_session_id: <id from line 1>
|
||||
frozen_brief_topic: <the topic string>
|
||||
target_save_dir: ~/workspace/<current-workspace>/plans/
|
||||
target_save_dir: ~/workspace/plans/
|
||||
mode_flags: <none | --no-research | etc.>
|
||||
|
||||
The curator now owns Phases 1–6 (research → assemble → self-review → Claude evidence-diff → URL re-verify → reconcile).
|
||||
@@ -298,7 +324,8 @@ The curator prompt embeds the two dispatch-template references inline; the dispa
|
||||
- **Resume the curator for:** continuing the brief, adding sections, requesting re-validation, asking the curator to expand a phase.
|
||||
- **Never resume across topics.** Same plan = resume, different plan = fresh curator session.
|
||||
- **deep-research sessions are NOT resumed by the curator.** Curator captures the `<topic>_research.md` output and moves on; the research session expires naturally.
|
||||
- **ask-claude sessions are NOT resumed.** Claude is one-shot for the validation pass. Re-validation = fresh Claude session.
|
||||
- **ask-claude sessions are NOT resumed.** Claude is one-shot for the evidence-diff pass. Re-validation = fresh Claude session.
|
||||
- **ask-hermes and ask-dev peer sessions (Phase 4b/4c) are NOT resumed either.** Each is a one-shot validation round. Re-validation = fresh peer session, possibly on a different profile.
|
||||
- **Dispatcher is one-shot.** The dispatcher does NOT poll. Operator resumes the curator for follow-up.
|
||||
|
||||
**Pre-build check — verify line-1 capture (per `~/workspace/general/plan_skill_plan.md` §7, pitfall #10):**
|
||||
@@ -309,7 +336,7 @@ Before declaring the skill buildable, the dispatcher must empirically confirm th
|
||||
|
||||
- **`<topic>_plan.md`** — the actionable plan. Pinned filename. Date in frontmatter, not filename. Single writer: the curator.
|
||||
- **`<topic>_research.md`** — the research evidence. Pinned filename. Curator is the **sole writer**. Phase 5 re-verify log is appended in-place.
|
||||
- **Default save location:** `~/workspace/<current-workspace>/plans/`. Override with explicit path in the brief.
|
||||
- **Default save location:** `~/workspace/plans/`. Override with explicit path in the brief.
|
||||
- **Phase 5 validation log:** appended to `<topic>_research.md` (not a separate file). Contains: re-fetched URL, what was confirmed, any version/command drift found.
|
||||
|
||||
**Same-topic clobber guard (per `~/workspace/general/plan_skill_plan.md` §7.5):** The curator checks for an existing `<topic>_plan.md` in the target dir. If found, the curator renames the existing file to `<topic>_plan.<timestamp>.bak.md` and saves the new plan to the canonical `<topic>_plan.md`. The operator can recover the prior version from the .bak.md file. Prevents silent clobber under `--yolo`.
|
||||
@@ -329,6 +356,9 @@ Before declaring the skill buildable, the dispatcher must empirically confirm th
|
||||
11. **Phase 4 (Claude evidence-diff) only sees the structured-claims extract, not the full research.md.** The curator's self-review (Phase 3) is the safety net for findings that fall outside the extract.
|
||||
12. **Tool names in Phase 5 must match the actual tool registry.** The curator framing prompt's Phase 5.2 references `web_extract` and `mcp__playwright__browser_navigate` (double underscore). If these change in a future Hermes version, the curator will error out on URL re-verification. Verify tool names against the current tool registry before shipping a skill update.
|
||||
13. **The turn-ceiling save must be proactive, not reactive.** The curator cannot "stop and write at turn 600" — the session terminates at the ceiling. The curator framing prompt instructs proactive save at ~590. If the turn budget changes, update both the ceiling value and the proactive-save threshold.
|
||||
14. **When a plan creates a new skill, verify the real distribution pattern before proposing it.** Hermes skills ship as **real per-profile file copies, not symlinks.** Each profile has its own `~/.hermes/profiles/<p>/skills/<category>/<skill>/SKILL.md` (separate inodes). The dispatcher MUST verify this empirically (`stat -c %i` on an existing shared skill like `searxng-smart-search` across profiles) before writing a plan that says "symlink the new skill to all profiles" — the assumption is wrong and the plan will produce a broken distribution. Reference: `hermes-config-bulk-update/references/skill-replication-across-profiles.md`. Plan template: "write the SKILL.md once to a canonical source, then `cp` to each target profile's `skills/<category>/<skill>/` directory."
|
||||
15. **Live `hermes config set` is authoritative; web-searched config docs are not.** When validating whether a Hermes config value, flag, or schema is valid, ALWAYS demand a live test (e.g., `hermes -p <profile> config set <key> <value>` and check exit code + output) rather than relying on web-searched documentation. The mintlify / hermes-agent.nousresearch.com docs can be stale, refer to a different schema, or omit valid values. Real example (July 2026): a peer agent claimed `reasoning_effort: max` was not a valid value based on web docs, but `hermes config set agent.reasoning_effort max` accepted it with exit 0 — `max` is in fact the current value of both the general and research profile configs. **Rule:** if a peer or Claude asserts "X is invalid config" without showing a live test output, push back and demand the test. Five seconds of `hermes config set` beats five minutes of arguing about docs.
|
||||
16. **Multi-model peer validation is the operator's de facto practice; do not skip Phase 4b/4c reflexively.** For non-trivial plans (anything crossing 3+ files, architectural changes, anything that touches operator-standing rules), Phase 4a (Claude) alone has repeatedly missed things the general peer and dev peer caught. Default: run 4a + 4b for every non-trivial plan. Run 4c only if 4a or 4b found release-blockers. The cost is ~2-5 minutes per extra round; the leverage is real (cross-model blindspots are NOT a theoretical concern). See `references/multi-model-peer-validation.md`.
|
||||
|
||||
## 9. Verification Checklist (from plan §7, verbatim)
|
||||
|
||||
@@ -359,7 +389,9 @@ Before declaring the skill buildable, the dispatcher must empirically confirm th
|
||||
- `references/curator-framing-prompt.md` — the actual prompt the dispatcher sends to the curator (Phases 1-6)
|
||||
- `references/deep-research-dispatch-template.md` — the Phase 1 research dispatch template
|
||||
- `references/ask-claude-validation-template.md` — the Phase 4 evidence-diff prompt template
|
||||
- `references/multi-model-peer-validation.md` — the Phase 4a/4b/4c multi-model peer validation pattern (why and when)
|
||||
- `writing-plans` skill — Phase 2 methodology
|
||||
- `subagent-driven-development` skill — for executing the plan after delivery
|
||||
- `ask-hermes` / `ask-claude` / `deep-research` skills — peer dispatch patterns
|
||||
- `references/multi-round-validation-pattern.md` (in subagent-driven-development) — for the multi-round validation protocol used in plan-build
|
||||
- `hermes-config-bulk-update/references/skill-replication-across-profiles.md` — when a plan creates a new skill, the real per-profile distribution pattern (real file copies, not symlinks)
|
||||
|
||||
Reference in New Issue
Block a user