Menü
Create implementation plans in two phases: clarify requirements first, then produce a concrete step-by-step plan without writing code. Trigger: explicit.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Apply Tau-specific canonical-contract, ownership-boundary, protocol-alignment, and regression patterns during deslop cleanup. Use only alongside the deslop skill in the Tau repository. Trigger: explicit.
Clean up, canonicalize, and tighten a specified target (often a branch of PR work from a junior or AI agent, but also a package, the current changes, or any other bounded slice), refactoring freely within the target when that raises overall quality. Trigger: explicit.
Split large diffs or change sets into natural review chunks, then guide the user through focused diff_review sessions. Trigger: explicit.
Conduct rigorous code review for git changes and return prioritized, actionable findings in a strict verdict/findings format. Trigger: explicit.
| name | plan |
| description | Create implementation plans in two phases: clarify requirements first, then produce a concrete step-by-step plan without writing code. Trigger: explicit. |
Produce implementation plans, not implementations. Explore, ask questions, and document a clear path forward, then stop.
This task has two phases with a hard boundary between them:
You must complete Phase 1 before starting Phase 2. You must stop after Phase 2. Do not write code. Do not begin implementing.
Read the request below. Explore the codebase to answer your own questions when the code can provide clarity. Only ask the user about things you cannot determine from the code itself.
If the request is unambiguous (or becomes clear after exploring the code), summarize your understanding in two to three sentences and ask the user to confirm.
If you must ask questions, keep them minimal, and focus only on decisions that genuinely require user input. Number questions from 1 to n.
Do not guess at requirements. Do not fill gaps with assumptions. But do use the codebase to reduce what you need to ask.
Once the user confirms your understanding, explore the codebase and produce a plan with exactly these sections:
One paragraph: what is being built and why.
The context a developer would need: relevant existing behavior, constraints, edge cases, and dependencies.
Numbered steps describing what to change and where. Each step should be concrete enough that a developer could execute it without re-reading the original request. Reference specific files, functions, or patterns when you know them.
A list of files and code sections involved, with a one-line note on each file's role. If you found none, say so.
Write the plan as a standalone document, not as a conversation. Use imperative voice ("Add a validation check to...") or neutral third person ("The handler should validate..."). Avoid first person ("I will add..."). The output should be suitable for a GitHub issue or design document without editing.
End your response after the plan. Do not offer to implement it. Do not write code unless the user explicitly asks in a follow-up message.
