plan-workflow

An experimental command that creates a software implementation plan through an automated workflow. You provide a goal and judging criteria, then review the proposed plan at the end.

In plain words
What is it for?
Use it to explore approaches, design and compare architectures, assess a preferred solution against a rubric, and produce an implementation plan.
Why use it?
It reduces the need to guide every planning step while keeping final approval with you.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/restarter/lets-workflow/plan-workflow
Clone the repo
git clone --depth 1 https://github.com/restarter/lets-workflow
Per session 38 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 3,499 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00038 $0.03499
Opus 5 $0.00019 $0.01750
Sonnet 5 $0.00008 $0.00700
Haiku 4.5 $0.00004 $0.00350

Measured yesterday against content hash a999f4973691, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

plan-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/lets/commands/plan-workflow.md · 125 lines

How it starts

The opening of the file, as written. The whole thing — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Autonomous Plan (PREVIEW workflow)

PREVIEW / experimental. Shipped standalone so the autonomous-planning Dynamic Workflow can be dogfooded across projects and gather edits before it's folded into native /lets:plan --workflow (tracked in lets-jsw00). The reusable artifact is skills/plan-workflow/plan.workflow.js; this command is a thin dispatcher. The interactive native /lets:plan is untouched. Expect rough edges - report them.

Autonomous whole-command planning: you give a GOAL + a RUBRIC up front; the workflow explores, proposes approaches, architects each, judges them against your rubric, evaluates the winner, and writes a plan - all off-context. You approve the plan at the end. Steer-by-rubric + approve-at-end, not gate-each-step.

IMPORTANT: Deferred tools (e.g. AskUserQuestion) must be loaded and called as specified.

Step 0: Resolve & claim (spawn entry)

If the argument is an explicit task id - a single token matching the ACTIVE tracker's id shape per the detect-task convention (beads: <prefix>-<alphanum>[.N]; a numeric-id tracker: a pure-numeric id; do NOT hardcode the beads regex on a non-beads project) - rather than a free-text goal - as the autonomous pipeline launches it (/lets:plan-workflow <id> into a fresh worktree) - resolve-and-claim per the detect-task convention: treat the id as authoritative and, if the tracker's show reports <id> not in_progress, Skill(skill: "lets:take-task", args: "<id>") to claim it (the spawn-time entry claim is AUTO-MODE-exempt - see detect-task/SKILL.md). Then derive the GOAL from the task title + description for Step 1. A free-text goal argument skips this step (no claim).

Pipeline-state marker (spawn-claimed runs only)

When Step 0 spawn-claimed a task (the autonomous pipeline launched this), record the phase in a per-task marker so N parallel worktrees don't collide and the gate-notify can tell autonomous from interactive. Per-task filename (NOT a shared pipeline-state.lets/ is a symlink across worktrees): .lets/cache/pipeline-state-<task-id>, line <task-id>|<phase>|<iso>, phase ∈ planning | gate-clarify | gate-approve | executing | blocked | done. Helper:

Read the full file on GitHub · 125 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 125 lines · 38 tokens per session scan A a999f4973691

Subscribe to this mod's changes

plan-workflow is a command published in the GitHub repository restarter/lets-workflow (17 stars, last pushed 9d ago), licensed MIT. It adds 38 tokens to every session and 3,499 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.