Produce a detailed, step-by-step implementation plan broken into small unambiguous tasks that a smaller/cheaper model could execute without guessing. Use whenever the user invokes /pe-blueprint, typically right after /pe-understand has been confirmed. Intended to run on a large, capable model — this step does the…
Split an approved plan into separate, self-contained .md files (one per task or logical group), organized in a folder, so each file can be handed to /pe-implement independently — possibly in a different session or by a different model. Use when the user invokes /pe-decompose-plan. Optional step — only needed for…
Explain code that was just implemented in plain terms, so the user understands what was built and why without reading every line themselves. Use when the user invokes /pe-explain, typically right after /pe-implement.
Execute a plan or task file, writing code directly with no discussion, no rationale, no restating the task. Use when the user invokes /pe-implement, typically pointing at a plan.md or a specific task .md file from /pe-decompose-plan. Designed to run on a small/cheap model — go straight to the code.
Review an already-produced plan for gaps, wrong ordering, missing edge cases, or tasks that are too vague for a small model to execute. Use when the user invokes /pe-review-plan, right after /pe-blueprint in the same conversation. Do not re-explore the codebase from scratch — build on the plan already in context.
Reformulate what the user is asking for before any planning happens, to catch misunderstands early. Use whenever the user invokes /pe-understand, or before starting /pe-blueprint on a non-trivial feature, bug fix, or refactor request. Do NOT use for trivial one-line requests.
★not rated 2 15d agoA65 tokens
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: