5809fe3249
- Replace scattered .prettierignore files with a single root config - Add scripts/ci.js to orchestrate lint, format, typecheck, commitlint, and build - Simplify ci.yml to use ci.js and npm ci - Apply prettier formatting to docs, locales, and HTML files
105 lines
5.0 KiB
Markdown
105 lines
5.0 KiB
Markdown
---
|
|
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'
|
|
---
|
|
|
|
# Pre-Implementation Discussion
|
|
|
|
Facilitate a structured, collaborative discussion to evaluate a proposed change **before any implementation begins**.
|
|
|
|
## Golden Rule
|
|
|
|
**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.
|
|
|
|
## Interaction Style
|
|
|
|
- **Concise during discussion.** Each intermediate response should be short and focused on the current question. Do NOT repeat the full plan in every response.
|
|
- **Complete when finalizing.** Once the plan is mature and the user asks for it, present a single comprehensive (but terse) summary for final review.
|
|
- **Ask, don't assume.** When uncertain about project context, constraints, or preferences — ask. The user prefers collaborative discussion over receiving a pre-baked answer.
|
|
- **Challenge the premise.** Question whether the proposed change is the right one. Suggest simpler alternatives if they exist.
|
|
- **Match the user's language.** Reply in the same language the user writes in.
|
|
|
|
## Procedure
|
|
|
|
### 1. Understand the Current State
|
|
|
|
Before forming any opinion:
|
|
|
|
- **Read the relevant source files** — configs, code, docs that relate to the change
|
|
- **Understand the project structure** — what's published vs private, what environments things target, existing constraints
|
|
- **Map the impact surface** — which files, packages, or systems would be affected
|
|
- **Estimate implementation cost** — how many files to touch, how much config to rewrite, what could break
|
|
|
|
Do NOT skip this step. Do NOT rely on assumptions about what "most projects" do.
|
|
|
|
### 2. Research Thoroughly
|
|
|
|
- **Consult official sources** — docs, changelogs, migration guides, GitHub issues
|
|
- **Verify every claim with evidence.** Don't say "X supports Y" without a source. If unsure, say so.
|
|
- **Search in parallel** to save time — batch independent queries
|
|
|
|
Common pitfalls:
|
|
|
|
- Assuming compatibility without checking actual version constraints
|
|
- Confusing roadmap/aspirations with actual released state
|
|
- Missing transitive constraints (a dependency of a dependency)
|
|
|
|
### 3. Present Findings (Concise)
|
|
|
|
Share a **brief** assessment. Tables work well for comparisons. Highlight **blockers** and **unknowns** prominently — don't bury them in paragraphs.
|
|
|
|
### 4. Identify Key Decisions
|
|
|
|
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:
|
|
|
|
- What are the options? (2-3 max)
|
|
- What does each option cost or give up?
|
|
- What's your lean and why? (one sentence)
|
|
|
|
### 5. Iterate
|
|
|
|
The user will ask follow-up questions, raise concerns, or challenge assumptions. For each round:
|
|
|
|
- **Research if needed** — don't answer from instinct when facts are available
|
|
- **Answer only what was asked** — don't re-present the entire plan
|
|
- **Update your mental model** based on user feedback
|
|
|
|
Common mistakes in this phase:
|
|
|
|
- Repeating the full plan after every small clarification
|
|
- Answering a narrow question with a broad redesign
|
|
- Treating user questions as confirmation to proceed
|
|
|
|
### 6. Finalize the Plan
|
|
|
|
When the user signals the discussion is converging, present the **complete plan once**:
|
|
|
|
- **What changes** — concrete list of actions (table or bullet points)
|
|
- **Impact surface** — what files/systems are affected, estimated effort
|
|
- **What does NOT change** — explicitly state scope boundaries
|
|
- **Risks or open items** — anything that needs testing or further verification
|
|
|
|
Keep it terse. Tables over paragraphs. No explanations the user already heard during discussion.
|
|
|
|
### 7. Wait for Confirmation
|
|
|
|
After presenting the final plan, **stop and wait**. The user will either:
|
|
|
|
- Confirm → then (and only then) proceed to implementation
|
|
- Ask more questions → go back to step 5
|
|
- Modify scope → update the plan and re-present
|
|
|
|
## Anti-Patterns
|
|
|
|
| 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 |
|