plan
Plan mode for Hermes — inspect context, write a markdown plan into the active workspace's `.hermes/plans/` directory, and do not execute the work.
Best use case
plan is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Plan mode for Hermes — inspect context, write a markdown plan into the active workspace's `.hermes/plans/` directory, and do not execute the work.
Teams using plan should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/plan/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How plan Compares
| Feature / Agent | plan | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Plan mode for Hermes — inspect context, write a markdown plan into the active workspace's `.hermes/plans/` directory, and do not execute the work.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Plan Mode Use this skill when the user wants a plan instead of execution. ## Workspace-hub routing note This is a generic local planning skill. Do NOT use it as the primary planning route for GitHub issue work in workspace-hub style repos. For GitHub issue planning there, prefer `issue-planning-mode`, which writes to `docs/plans/`, performs adversarial review, updates GitHub labels/comments, and enforces the approval gate. ## Core behavior For this turn, you are planning only. - Do not implement code. - Do not edit project files except the plan markdown file. - Do not run mutating terminal commands, commit, push, or perform external actions. - You may inspect the repo or other context with read-only commands/tools when needed. - Your deliverable is a markdown plan saved inside the active workspace under `.hermes/plans/`. ## Output requirements Write a markdown plan that is concrete and actionable. Include, when relevant: - Goal - Current context / assumptions - Proposed approach - Step-by-step plan - Files likely to change - Tests / validation - Risks, tradeoffs, and open questions If the task is code-related, include exact file paths, likely test targets, and verification steps. ## Save location Save the plan with `write_file` under: - `.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md` Treat that as relative to the active working directory / backend workspace. Hermes file tools are backend-aware, so using this relative path keeps the plan with the workspace on local, docker, ssh, modal, and daytona backends. If the runtime provides a specific target path, use that exact path. If not, create a sensible timestamped filename yourself under `.hermes/plans/`. ## Interaction style - If the request is clear enough, write the plan directly. - If no explicit instruction accompanies `/plan`, infer the task from the current conversation context. - If it is genuinely underspecified, ask a brief clarifying question instead of guessing. - After saving the plan, reply briefly with what you planned and the saved path.
Related Skills
plan-review-prompt-refresh-after-plan-edits
Refresh reviewer prompt files from the latest on-disk plan before every adversarial re-review. Prevents Codex/Gemini from critiquing stale plan text after local edits.
workspace-hub-overnight-plan-monitor
Monitor and reconcile workspace-hub overnight planning or implementation batches, including process status, result artifacts, issue/commit verification, and controlled failed-lane recovery.
plan-gated-issue-execution-wave
Execute a multi-issue architecture/planning wave in a plan-gated repo, then safely transition approved issues into implementation with file-based Codex prompts, local approval markers, subprocess monitoring, and cleanup handling for sandbox/hook edge cases.
mixed-ops-vs-repo-fix-plan-boundary
Plan mixed operational-vs-repo remediation issues by proving live-state classification first, then only proposing code changes for confirmed repo-owned failure paths.
wave-based-parallel-plan-execution
Orchestrate phase execution by discovering dependencies, grouping into waves, spawning subagents, and collecting results with optional wave filtering
plan-gated-issue-validation-workflow
Systematic validation pattern for plan-approved GitHub issues with pre-existing deliverables
plan-gated-issue-implementation
Workflow for executing pre-approved GitHub issues with mandatory validation checkpoints
external-drive-ingest-planning
Plan safe external-drive ingests into repo-aligned storage such as /mnt/ace: read-only mounts, manifests, staged rsync, dedupe-merge gates, GitHub issue traceability, and governance/execution split.
user-approved-plan-state-sync
Reconcile GitHub and local repo state when a plan has been user-approved, including direct approval messages that require creating the local marker and moving the issue to status:plan-approved.
ten-agent-pre-plan-review-wave
Launch and verify a 10-agent planning-only wave that moves open GitHub issues into status:plan-review using one isolated worktree per issue, wave-specific continuation cron, and post-run artifact-reconciliation checks.
static-site-build-artifact-plan-review
Plan-review pattern for static-site fixes where the deployed artifact is generated from source files (e.g. sitemap/robots/static assets). Prevents review churn by separating durable regression checks from one-time migration verification and by validating built output, not just source files.
split-plan-governance-vs-substance
When repeated adversarial plan reviews keep returning MAJOR findings about validator mechanics, evidence bookkeeping, or governance traceability rather than the core product or mission decision, stop tightening the monolithic plan and split it into a content/decision packet and a tooling/enforcement packet.