gen-plan
Gen-Plan
Contract
- Scope: operate in the repo root only; manage files named
plan-N.mdwhereNis an integer. - Output location is fixed: write
plan-N.mdto the current repo root directory only. - Never write
plan.md,PLAN.md, or any non-plan-N.mdfilename. - Never write outside the repo root. Prohibited examples include
~/Downloads,$HOME, absolute paths, or sibling directories. - If any instruction or path suggests writing outside the repo root, stop and ask for clarification.
- Define
Nas the maximum numeric suffix among files matchingplan-(\d+).md(ignore non-matching filenames, including legacyplan-N-E.md/plan-N-R.md). - If any matching file has
N > 5: do nothing; reply exactly: "Plan is ready." - If
plan-5.mdexists (case-insensitive): do nothing; reply exactly: "Plan is ready." - If no matching
plan-(\d+).mdexists: run the clarification flow, then createplan-1.md. - Otherwise: create
plan-(N+1).md. Source plan markdown:plan-N.md. - When loading plan markdown from a source file, insert the full contents of
plan-N.mdat the<INCLUDE CONTENTS OF PLAN FILE>placeholder in the plan template. - Never overwrite an existing target file; stop and report the conflict.
- Ask questions only when unresolved judgment calls block the next iteration.
Clarification flow (when needed)
- Research first; ask only judgment-call questions.
- Use the
CLARIFICATION EXPERT: HUMAN INPUT REQUIREDblock with numbered questions. - After questions are answered, determined if another round of questions is needed; if so continue asking questions until there are no more then write the next plan file.
Iterate on the plan
Purpose: Use the prompt below as an internal instruction to produce plan-(N+1).md from plan-N.md.
Output rules:
- The plan file must contain the response to the prompt, not the prompt itself.
- Do not include the prompt text, blockquote markers, or nested quotes in the plan file.
- The output must be normal Markdown (no leading
>on every line). - When inserting the source plan, include it verbatim with no extra quoting, indentation, or code fences.
Prompt template (verbatim, internal only — never write this into the plan file)
Carefully review this entire plan for me and come up with your best revisions in terms of better architecture, new features, changed features, etc. to make it better, more robust/reliable, more performant, more compelling/useful, etc.
For each proposed change, give me your detailed analysis and rationale/justification for why it would make the project better along with the git-diff style changes relative to the original markdown plan shown below:
More from tkersey/dotfiles
grill-me
>
99complexity-mitigator
Mitigate incidental complexity in existing code when control flow is tangled, nesting is deep, names are hard to parse, or reasoning requires cross-file hops. Use when a review stalls on readability, you need an analysis-first refactor plan before edits, or you want essential-vs-incidental verdicts, dominant-risk triage, ranked simplification steps, one visibility artifact, and a TRACE assessment. Do not use for greenfield requirements discovery, architecture selection, or delivery planning.
59creative-problem-solver
Lateral-thinking playbook that always returns a five-tier strategy portfolio (Quick Win through Moonshot). Use when you need options, alternatives, or trade-offs; when progress is stalled or failing repeatedly; or when you ask to think creatively, reframe constraints, and choose a strategic path before execution.
59mesh
Use `$mesh` for homogeneous leaf-batch execution over `spawn_agents_on_csv`: once planning has shaped repeated independent units, prefer one substantive row per unit with structured results and explicit concurrency.
47web-browser
Use when tasks need real-browser web automation in Chrome/Chromium via CDP: open or navigate URLs, click/type/select in forms, run page JS, wait for selectors, scrape structured content, capture screenshots, validate UI flows, or run measured web-browser latency checks (`bench:eval`, `bench:all`) for perf regressions.
43invariant-ace
Turn 'should never happen' into 'cannot happen' by defining owned inductive invariants and enforcing them at parse/construct/API/DB/lock/txn boundaries with a verification signal. Use when prompts mention invariants, impossible states, validation sprawl, cache/index drift, idempotency/versioning, retries/duplicates/out-of-order events, race/linearization bugs, loop correctness, or hardening another implementation workflow with invariant checks first.
31