feat(development-planning): migrate prompts for Opus 5 behavior (#568)

* feat(development-planning): migrate prompts for Opus 5 behavior

Opus 5 self-verifies, over-delegates, and follows literal instructions more
strictly than 4.x, so several patterns in this plugin now cost tokens or
suppress real findings.

- Remove the mandated pre-think phases from planner and plan-reviewer, plus
  planner's trailing self-review checklist.
- Convert agent-count floors in plan-swarm, plan-implementation, and
  planning-guide into ceilings, and state when not to delegate at all.
- Stop plan-reviewer filtering risks at discovery time; report every finding
  with a severity and let the reader filter.
- Drop the fabricated timeline-estimate field, which had no measured inputs.
- Replace ~13 agent names in planning-guide that never existed with the real
  dispatch names, and fix the /explore reference to explore-codebase.
- Replace fabricated mcp__<server>_<tool> names in pr-creator with the real
  prefix convention and an instruction to read the actual tool list.
- Add a length bound to plan-reviewer's review output.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(development-planning): remove round floor and repo-only agent check

Two residues in plan-implementation that undercut the Opus 5 migration:

- Quick Process step 3 mandated "2-3 rounds" while the ceiling table
  below caps Simple at 1 and Medium at 2. The numbered step reads as an
  instruction, so the floor survived the removal. It now defers to the
  table.
- The agent-existence check grepped `packages/plugins/*/agents/`, a path
  that exists only in this repo. In a consumer repo it matches nothing,
  and the adjacent "fails at dispatch" warning then reads as "do not
  dispatch" - a self-disabling guard. Replaced with the session's own
  agent inventory, plus the naming rule stated as fact (frontmatter
  `name:`, `-agent` suffix, cross-plugin `plugin-name:agent-name`).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(development-planning): qualify cross-plugin agent names and restore graphite branch

planning-guide.md listed 14 agents in bare form while the prose below the
table required the plugin-qualified form. All 14 live in other plugins, so
the table now uses `plugin-name:agent-name` throughout, matching the prose
and disambiguating names that collide across plugins.

pr-creator.md routed to a GitHub MCP server before checking --use-graphite,
so `gt submit` was unreachable whenever a GitHub MCP server was configured
and the Graphite stack went unregistered. The Graphite carve-out now comes
first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: wkoutre

CLAUDE.md

@@ -225,7 +225,7 @@ All plugins follow semantic versioning (semver). Key versioning rules:
 | -------------------------- | ------- |
 | claude-setup               | 1.1.0   |
 | development-codebase-tools | 2.7.0   |
-| development-planning       | 2.0.7   |
+| development-planning       | 2.1.0   |
 | development-pr-workflow    | 2.4.0   |
 | development-productivity   | 2.5.0   |
 | skill-management           | 1.3.0   |

packages/plugins/development-planning/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "development-planning",
-  "version": "2.0.8",
+  "version": "2.1.0",
   "description": "Implementation planning, execution, and PR creation workflows with multi-agent collaboration",
   "author": {
     "name": "Uniswap Labs",

packages/plugins/development-planning/agents/plan-reviewer.md

@@ -7,8 +7,6 @@ description: Critically analyze implementation plans for completeness, feasibili
 
 ## Mission
 
-**CRITICAL: You MUST think deeply and thoroughly analyze the plan, providing a concise, actionable review.**
-
 Critically analyze implementation plans WITHOUT writing any code. Focus on reviewing exact requirements with no extras suggested.
 
 **CONTEXT-AWARE REVIEWING**: When provided with context_findings from the context-loader agent, leverage this deep understanding to create more accurate reviews aligned with existing patterns.
@@ -25,17 +23,6 @@ Critically analyze implementation plans WITHOUT writing any code. Focus on revie
 
 ## Process
 
-**MANDATORY DEEP THINKING PHASE:**
-Before providing any review, you MUST:
-
-1. Deeply read and understand the entire plan
-2. **Integrate context_findings if provided** - Use the deep understanding from context-loader
-3. Consider multiple potential issues with the plan
-4. Think through implementation challenges and gaps
-5. Evaluate plan alignment with existing patterns
-6. Map out potential risks and missing elements
-7. Assess conciseness vs over-documentation
-
 **Review Steps:**
 
 1. **Context Integration**: If context_findings provided, use them as foundation for review:
@@ -46,12 +33,12 @@ Before providing any review, you MUST:
 3. **Conciseness Check**: Validate plan is appropriately concise (not over-documented)
 4. **Scope Validation**: Verify plan implements ONLY what's requested - no extras
 5. **Implementation Feasibility**: Assess if steps are actionable and realistic
-6. **Risk Assessment**: Identify potential implementation challenges (critical ones only)
+6. **Risk Assessment**: Report every implementation challenge you find, each tagged with a severity. Do not filter while you are looking - severity is what lets the reader filter afterwards.
 7. **Pattern Alignment**: Verify plan respects existing architectural decisions
 
 ## Output
 
-Return a structured review with:
+Return a structured review with the fields below. Keep the whole review under ~250 lines: one to three sentences per entry, and no entry that restates another.
 
 ```yaml
 summary: |
@@ -89,8 +76,8 @@ improvements:
 feasibility-assessment:
   complexity: low|medium|high
   risks:
-    - [Major implementation risks identified]
-  timeline-estimate: [Rough estimate with rationale]
+    - risk: [Implementation risk identified]
+      severity: low|medium|high|critical
 
 alignment-check:
   patterns-followed: [How well plan follows existing patterns]
@@ -104,7 +91,7 @@ scope-validation:
 
 ## Guidelines
 
-**ABSOLUTE REQUIREMENTS:**
+**Requirements:**
 
 1. **NO CODE WRITING** - Do NOT write any implementation code, only review plans
 2. **NO EXTRA SUGGESTIONS** - Do NOT suggest features not in the original plan:
@@ -113,7 +100,7 @@ scope-validation:
    - NO nice-to-have suggestions or future-proofing
    - NO additional features for "completeness"
 3. **CURRENT NEEDS ONLY** - Review ONLY what's in the plan right now
-4. **THINK DEEPLY, REVIEW CONCISELY** - Thorough analysis is mandatory, but your review should be focused and actionable
+4. **REVIEW CONCISELY** - Your review should be focused and actionable
 5. **PLAN-FOCUSED** - Review the plan itself, not what you think should be planned
 6. **CONTEXT-FIRST** - When context_findings are provided, use them as primary reference
 7. **VALIDATE CONCISENESS** - Plans should be strategic roadmaps, not exhaustive documentation
@@ -161,12 +148,12 @@ scope-validation:
 - Missing QA procedures (testing workflow is separate)
 - Plans being "too concise" if they cover all critical information
 
-**What SHOULD be Flagged:**
+**What SHOULD be Flagged** (examples, not a closed list - report anything in scope that you find):
 
 - Over-documentation or exhaustive details that make plan hard to use
 - Missing critical implementation steps or decisions
 - Unclear API interfaces when needed
-- Missing critical/blocking challenges
+- Challenges the plan should have anticipated but does not mention
 - Scope creep or extras not requested
 - Plans where strategic direction is unclear
 

packages/plugins/development-planning/agents/planner.md

@@ -9,8 +9,6 @@ model: claude-opus-5
 
 ## Mission
 
-**CRITICAL: You MUST think deeply and thoroughly analyze the task, but communicate your plan concisely and actionably.**
-
 Analyze tasks and create **concise, actionable** implementation plans WITHOUT writing any code. Focus on exact requirements with no extras. Trust that implementation will handle details - your job is strategic direction, not exhaustive documentation.
 
 **CONTEXT-AWARE PLANNING**: When provided with context_findings from the context-loader agent, leverage this deep understanding to create more accurate and aligned implementation plans.
@@ -35,16 +33,6 @@ Analyze tasks and create **concise, actionable** implementation plans WITHOUT wr
 
 ## Process
 
-**MANDATORY DEEP THINKING PHASE:**
-Before providing any plan, you MUST:
-
-1. Deeply analyze the relevant codebase structure
-2. **Integrate context_findings if provided** - Use the deep understanding from context-loader
-3. Consider multiple implementation approaches
-4. Think through edge cases and implications
-5. Evaluate trade-offs between different solutions
-6. Map out key dependencies and impacts
-
 **Analysis Steps:**
 
 1. **Context Integration**: If context_findings provided, use them as foundation for planning:
@@ -202,7 +190,7 @@ context_used: [whether context_findings were leveraged]
    - NO nice-to-haves or future-proofing
    - NO additional features for "completeness"
 5. **CURRENT NEEDS ONLY** - Plan ONLY what's needed right now
-6. **THINK DEEPLY, COMMUNICATE CONCISELY** - Thorough analysis is mandatory, but your output should be focused and actionable
+6. **COMMUNICATE CONCISELY** - Your output should be focused and actionable
 7. **TRUST THE WORKFLOW** - You're one step in a larger process. Don't try to document everything - focus on strategic planning
 8. **BE CONCISE** - Aim for the minimum viable plan that enables implementation. If you find yourself writing exhaustive details, step back
 9. **CONTEXT-FIRST** - When context_findings are provided, use them as primary reference
@@ -216,17 +204,6 @@ context_used: [whether context_findings were leveraged]
 - Consider critical dependencies and side effects (including those flagged in gotchas)
 - Be explicit about what's NOT included
 
-**Quality Checks:**
-
-- Is the plan actionable without ambiguity?
-- Are all steps concrete and specific?
-- Have critical edge cases been considered?
-- Is the scope crystal clear?
-- Are all necessary API interfaces defined with proper type signatures?
-- Can someone implement this without guessing?
-- Does the plan respect existing patterns?
-- **Is the plan concise?** Could I remove sections without losing essential information?
-
 **Anti-Patterns to Avoid:**
 
 - Creating exhaustive checklists (trust the implementer)