executing-plans

Files (3)

• SKILL.md
• task-done · scripts/
• task-start · scripts/

SKILL.md (first lines)

# Executing Plans

**Placeholder resolution:** `<KEY>` placeholders in this file (such as `<BASE_BRANCH>`) resolve from the `Herdrpowers Configuration` section of the repository's `CLAUDE.md` / `AGENTS.md`. If that section is missing, initialize it with the pack's init workflow (`/herdrpowers:init` on Claude Code plugin installs; `commands/init.md` otherwise).

Execute the plan yourself, task by task, in this session: no implementer
pane per task, no reviewer per task. One fresh-session review of the whole
branch at the end.

**Why inline:** Pane-driven development pays for a fresh implementer and
fresh reviewers on every task, each re-reading the codebase from zero.
Inline execution pays for one session (yours) plus one review at the end.
What it gives up is a fresh session per task and a second pair of eyes per
task. This skill keeps what those two things bought, by other means: the
brief is the spec, the ledger is your memory, TDD is the per-task gate, and
the final review is the second pair of eyes.

**Inline overrides the work routes, never the review gate.** Every task,
test, and fix in this plan runs here, whatever `complex-coding`,
`simple-coding`, `test-authoring`, `review-fixes`, or `chores` resolve to in
the merged configuration (`.herdrpowers/config.yaml` over
`orchestration/roles.yaml`) — that is what inline means. The final review
still resolves from `assignments.final-branch-review`.

**Core principle:** The plan already did the thinking. Execute it exactly,
prove each step with a test you watched fail and then pass, and leave a
record that survives your own forgetting.

**Narration:** between tool calls, narrate at most one short line — the
ledger and the tool results carry the record.

**Continuous execution:** Do not pause to check in with your human partner
between tasks. Inline execution exists to spend less, not to ask "should I
continue?" after every task. Execute all tasks from the plan without
stopping.

**Rulings, not stalls.** Conflicts, ambiguities, plan defects — decide them.
The spec is the binding authority, the plan is its argument, and your
judgment settles what neither answers. Record every decision in the ledger
as `Ruling: <what you decided> — <why> — <what it costs if wrong>`, and keep
going. Deviating from the plan without a ledgered ruling is a decision made
in secret.

Four things stop you, and only these: an irreversible or destructive
operation; a security-sensitive action; a side effect outside this worktree
that norms say you ask about first (a merge, a push to a shared branch, a
publish); and a plan so broken that every path forward is a guess. For
those, stop and ask.

**A ruling never rewrites the run's terms.** It resolves what the spec and
the plan left open — it does not re-enable a gate the repository disabled,
disable one it enabled, widen `delegation.pane_scope`, or touch
`.herdrpowers/config.yaml`. Those are the user's declaration, resolved once
at start.

## When to Use

- You have a plan from writing-plans and your human partner chose inline
  execution at the handoff.
- No herdr sibling pane can take the work: `HERDR_ENV` is unset, or no
  idle agent pane exists inside `delegation.pane_scope`. Never fabricate a
  delegation; run the plan here.
- Tasks are mostly independent — the same precondition as
  pane-driven-development.

A fully specified plan makes inline execution transcription plus testing:
it runs well on a mid-tier session model, and the one place a fresh session
earns its cost is the final review, which this skill sends out separately.
Tell your human partner so when they choose inline.

Prefer pane-driven-development when your human partner wants a review gate
on every task, or when the plan is long enough that its later tasks would
run on a compacted context. Inline execution over a long plan still works —
the ledger is what makes it recoverable — but the last tasks get the least
of you.

**Inside a workflow** (`/execute`, `/full_cycle`, and the rest, degrading to
inline), run Setup and the Task Loop here, then return to the workflow: its
documentation, verification, and final-review steps follow in its own
order. When its final-review step comes, run it as this skill's Final
Review describes, and put Finish's lists in the workflow's final report.

## The Process

```dot
digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="Per Task";
        "task-start: brief + BASE; read the brief" [shape=box];
        "Work the steps in order: TDD, run every verification, read every output" [shape=box];
        "Step output matches plan's Expected?" [shape=diamond];
        "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" [shape=box];
        "Commit as the plan's commit steps say" [shape=box];
        "Completion contract met?" [shape=diamond];
        "task-done: run tests, ledger the result; mark todo complete" [shape=box];
    }

    "Setup: worktree, workspace + ledger, read plan + spec, pre-flight scan" [shape=box];
    "More tasks remain?" [shape=diamond];
    "Final whole-branch review (final-branch-review gate)" [shape=box];
    "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger" [shape=box];
    "Final review clean: delete this plan's workspace" [shape=box];
    "Use finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Setup: worktree, workspace + ledger, read plan + spec, pre-flight scan" -> "task-start: brief + BASE; read the brief";
    "task-start: brief + BASE; read the brief" -> "Work the steps in order: TDD, run every verification, read every output";
    "Work the steps in order: TDD, run every verification, read every output" -> "Step output matches plan's Expected?";
    "Step output matches plan's Expected?" -> "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" [label="no"];
    "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" -> "Work the steps in order: TDD, run every verification, read every output";
    "Step output matches plan's Expected?" -> "Commit as the plan's commit steps say" [label="yes, last step"];
    "Commit as the plan's commit steps say" -> "Completion contract met?";
    "Completion contract met?" -> "Work the steps in order: TDD, run every verification, read every output" [label="no - finish the task"];
    "Completion contract met?" -> "task-done: run tests, ledger the result; mark todo complete" [label="yes"];
    "task-done: run tests, ledger the result; mark todo complete" -> "More tasks remain?";
    "More tasks remain?" -> "task-start: brief + BASE; read the brief" [label="yes"];
    "More tasks remain?" -> "Final whole-branch review (final-branch-review gate)" [label="no"];
    "Final whole-branch review (final-branch-review gate)" -> "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger";
    "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger" -> "Final review clean: delete this plan's workspace";

From transparent-pegasus/herdrpowers, MIT.

More from transparent-pegasus/herdrpowers