planwerk

Resolves the open questions that block an issue from being implemented — the decisions a planning session raised and could not make for itself — and records the answers in the issue body, where the next planning session reads them. Use when a plan reported NEEDS_CONTEXT, or when an issue carries unresolved decisions an implementer would have to guess at.

Surveys the checkout you are in for dead code and duplicated code, and files the verified findings as a Meta Issue — evidence-backed findings grouped into compact cleanup phases sized one pull request each, ready for /planwerk:meta to split into Sub Issues. Use when a codebase has accumulated unused or copy-pasted code and the author wants a verifiable cleanup plan rather than an ad-hoc deletion pass. It plans the cleanup; it never deletes code itself.

Works through the decisions a Meta Issue deferred when it was split — a block of open items, each carrying an unverified recommendation, that its Sub Issues already assume are settled. Verifies each one against the repository and whatever the item itself names as its source, puts the genuine judgment calls to the author, and records the outcomes in the Meta Issue and every Sub Issue whose body assumed one. Use when a Meta Issue carries a decisions or spike section with items nobody has confirmed yet, or when a Sub Issue exists solely to verify and record them.

Turns a rough, one-line feature idea into a filed GitHub issue at draft depth. Use when the user wants to capture an idea, file an issue, or write up a ticket. It describes the idea; it does not plan the implementation.

Expands a high-level GitHub issue into a deeply detailed engineering plan grounded in the actual repository, with the open decisions resolved by its author. Use when an issue needs a plan before it can be implemented, or when the user asks to elaborate, deepen, or flesh out an issue.

Repairs a pull request whose CI checks are red, fixing the cause the logs point at rather than the check that reports it. Use when a pull request's checks are failing and the repair needs a human — to settle whether the code is wrong or the test is, to approve reaching outside the failure surface, or to refuse a placebo fix for a flake.

Rewrites existing prose to remove the patterns that mark it as AI-generated (inflated significance, AI vocabulary, forced triads, em dashes, filler) while preserving every fact and the document's meaning. Use when documentation, a README, code comments, or an issue body reads machine-written, or before publishing generated documentation. It edits form only; it never adds, drops, or invents facts.

Implements a prepared GitHub issue end to end in the checkout you are sitting in — a short plan built in plan mode and approved by you, an implementation that satisfies every Acceptance Criterion, and one complete pull request behind an explicit yes, without the unattended pipeline's simplify, review, and verification passes. Use when the change is small enough that a full `planwerk-agent implement` run costs more than it catches — a bug fix, a contained feature — and you are present to approve the plan and read the diff.

Decomposes a Meta Issue into the fewest self-contained Sub Issues, filed with native GitHub sub-issue links and blocked-by dependencies. Use when an issue frames a larger body of work as several work packages and the user wants it decomposed.

Re-checks a prepared GitHub issue against what has actually landed since it was written, correcting the parts that went stale. For a Sub Issue, that includes its scope against the Meta Issue and against what the closed siblings really delivered. Use before implementing an issue that has been sitting, or when the user asks to revisit, re-check, or re-scope one.