// Conduct a thorough pre-implementation discussion before making significant changes. Use when the user wants to discuss, plan, or evaluate a change before implementing it — especially when they say words like 'discuss', 'evaluate', 'plan', or 'let's talk about'.
Create a branch, commit existing local changes, push them, and open a pull request. Use when submitting current work as a PR.
Clean up local git branches and remotes accumulated from PR reviews. Use when the user asks to clean branches, remove stale remotes, or tidy up the local git state.
Update docs/CHANGELOG.md from git history, GitHub releases, and code diffs. Use when: writing release notes, syncing the latest changelog entry, summarizing a new tag, or keeping changelog wording concise and consistent.
| name | pre-impl-discussion |
| description | Conduct a thorough pre-implementation discussion before making significant changes. Use when the user wants to discuss, plan, or evaluate a change before implementing it — especially when they say words like 'discuss', 'evaluate', 'plan', or 'let's talk about'. |
| argument-hint | Describe the change to evaluate |
Facilitate a structured, collaborative discussion to evaluate a proposed change before any implementation begins.
Do NOT implement anything until the user explicitly confirms the final plan and says to proceed. Not even "let me try on a branch" — that's implementation. The user will tell you when discussion is over.
Before forming any opinion:
Do NOT skip this step. Do NOT rely on assumptions about what "most projects" do.
Common pitfalls:
Share a brief assessment. Tables work well for comparisons. Highlight blockers and unknowns prominently — don't bury them in paragraphs.
Surface the decisions the user needs to make. Present them as clear choices with trade-offs, not as a recommendation monologue.
For each decision point:
The user will ask follow-up questions, raise concerns, or challenge assumptions. For each round:
Common mistakes in this phase:
When the user signals the discussion is converging, present the complete plan once:
Keep it terse. Tables over paragraphs. No explanations the user already heard during discussion.
After presenting the final plan, stop and wait. The user will either:
| Don't | Do Instead |
|---|---|
| Start implementation "to test" without confirmation | Present findings and wait |
| Repeat the full plan in every response | Answer the specific question asked |
| Say "X should work" without checking | Say "I need to verify X" and research it |
| Assume project structure or constraints | Read the actual files |
| Present one recommendation as the only option | Present 2-3 options with trade-offs |
| Write long paragraphs explaining trade-offs | Use tables and bullet points |
