@@ -57,10 +57,14 @@ It enforces evidence-based research, reuse over reinvention, and human-in-the-lo
5757| ------| -----------------|
5858| ` set_coding_task ` | Creates/updates task metadata; classifies task_size; returns next-step workflow guidance |
5959| ` get_current_coding_task ` | Recovers the latest task_id and metadata to resume work safely |
60- | ` judge_coding_plan ` | Validates plan/design; requires library selection and internal reuse maps; flags risks |
61- | ` judge_code_change ` | Reviews unified Git diffs for correctness, reuse, security, and code quality |
62- | ` judge_testing_implementation ` | Validates tests using real runner output and optional coverage |
63- | ` judge_coding_task_completion ` | Final gate ensuring plan, code, and tests approvals before completion |
60+ | ` get_user_feedback ` | ** MANDATORY FIRST STEP** : Elicits requirements, technical decisions, and repository analysis |
61+ | ` create_implementation_plan ` | LLM creates detailed implementation plan with research and best practices |
62+ | ` update_plan_with_llm_feedback ` | Refines plans based on LLM technical validation feedback |
63+ | ` get_user_approve_requirement ` | ** MANDATORY** : Gets user approval for implementation plans |
64+ | ` judge_coding_plan ` | LLM validates plan/design; requires library selection and internal reuse maps; flags risks |
65+ | ` judge_code_change ` | LLM reviews code for correctness, reuse, security, and code quality |
66+ | ` judge_testing_implementation ` | LLM validates tests using real runner output and coverage reports |
67+ | ` judge_coding_task_completion ` | Final LLM gate ensuring plan, code, and tests approvals before completion |
6468| ` raise_missing_requirements ` | Elicits missing details and decisions to unblock progress |
6569| ` raise_obstacle ` | Engages the user on trade‑offs, constraints, and enforced changes |
6670
@@ -70,24 +74,30 @@ MCP as a Judge implements a sophisticated collaborative workflow that ensures hi
7074
7175## 🔄 Enhanced Collaborative Workflow
7276
73- ### ** Phase 1: 🧠 Enhanced Brainstorming**
77+ ### ** Phase 1: 🧠 Requirements Brainstorming**
7478```
75- 📋 get_enhanced_user_feedback
79+ 📋 get_user_feedback
7680├── Requirements gathering + clarifications
77- ├── Documentation & reference requests
78- ├── Success criteria definition
79- ├── Environment & deployment context
80- └── Testing strategy preferences
81+ ├── Technical decision areas (framework, database, etc.)
82+ ├── Repository analysis for language/framework decisions
83+ ├── Specific questions to clarify gaps
84+ └── Suggested options with pros/cons
8185```
8286
83- ### ** Phase 2: 📋 Comprehensive Plan Creation**
87+ ### ** Phase 2: 📋 Plan Creation & Refinement **
8488```
8589🔬 create_implementation_plan
8690├── Technical research & analysis
8791├── Architecture & design patterns
88- ├── Test strategy & coverage requirements
89- ├── Implementation scope & milestones
90- └── Risk assessment & mitigation
92+ ├── Implementation scope & approach
93+ ├── Language-specific best practices
94+ └── Risk assessment & considerations
95+
96+ 🔧 update_plan_with_llm_feedback (if needed)
97+ ├── LLM identifies technical issues
98+ ├── Creates improved plan version
99+ ├── Addresses technical concerns
100+ └── Maintains user requirements
91101```
92102
93103### ** Phase 3: 🔄 Dual Approval Loop**
@@ -104,49 +114,45 @@ MCP as a Judge implements a sophisticated collaborative workflow that ensures hi
104114 └── ❌ Rejected → Back to Brainstorming
105115```
106116
107- ### ** Phase 4: 🚀 Enhanced Implementation**
117+ ### ** Phase 4: 🚀 Implementation & Validation **
108118```
109119🧹 Clean History (delete brainstorming records)
110120 ↓
111- 🏗️ judge_code_change (Architecture + Security Review )
121+ 🏗️ judge_code_change (Code Review & Validation )
112122 ├── LLM validates: Code structure & patterns
113123 ├── LLM checks: Security best practices
114- └── LLM ensures: Requirements compliance
124+ ├── LLM ensures: Requirements compliance
125+ ├── LLM reviews: Architecture decisions
126+ └── LLM verifies: Best practice adherence
115127 ↓
116- 👤 User Code Review (Optional validation step)
117- ├── User validates: Business logic correctness
118- └── User approves: Implementation approach
119- ↓
120- 🧪 judge_testing_implementation (Tests + Coverage)
128+ 🧪 judge_testing_implementation (Test Validation)
121129 ├── LLM validates: Test completeness & quality
122- ├── LLM checks: Coverage requirements met
123- └── LLM ensures: Edge cases covered
124- ↓
125- 📚 Documentation Review (Optional documentation check)
126- ├── LLM validates: Documentation completeness
127- ├── LLM checks: Code comments & clarity
128- └── LLM ensures: Usage examples provided
130+ ├── LLM checks: Test execution results
131+ ├── LLM ensures: Coverage requirements met
132+ ├── LLM reviews: Test types implemented
133+ └── LLM verifies: Edge cases covered
129134 ↓
130- ✅ judge_coding_task_completion (Final quality gate )
135+ ✅ judge_coding_task_completion (Final Quality Gate )
131136 ├── LLM validates: All requirements implemented
132- ├── LLM checks: Best practices followed
137+ ├── LLM checks: All approvals obtained
133138 ├── LLM ensures: Production readiness
139+ ├── LLM verifies: Best practices followed
134140 └── LLM confirms: Task completion criteria met
135141 ↓
136142🎉 Task Complete
137143```
138144
139- ### ** 🔑 Key Quality Enhancements**
140- - ** 📋 Comprehensive Requirements** : Documentation, success criteria, environment context
141- - ** 🧪 Test-First Planning** : Test strategy integrated from planning phase
142- - ** 🔄 Iterative Refinement** : Multiple approval loops ensure quality
143- - ** 👤 User Involvement** : Optional code review for critical changes
144- - ** 🤖 LLM Quality Gates** : Continuous validation of requirements, best practices, and completeness
145- - ** 📚 Documentation Focus** : Optional documentation validation with LLM review
146- - ** 🛡️ Multi-Layer Validation** : Architecture, security, testing, and completion gates
145+ ### ** 🔑 Key Quality Features**
146+ - ** 📋 Structured Requirements** : Systematic gathering with technical decision support
147+ - ** 🔄 Dual Approval Process** : Both user and LLM must approve plans before implementation
148+ - ** 🤖 LLM Quality Gates** : Continuous validation at every implementation step
149+ - ** 🛡️ Multi-Layer Validation** : Plan validation, code review, testing, and completion gates
147150- ** ✅ Requirements Traceability** : LLM ensures all original requirements are implemented
148- - ** 🏆 Best Practice Enforcement** : LLM validates coding standards and patterns
149- - ** 🔍 Comprehensive Coverage** : LLM checks edge cases, error handling, and production readiness
151+ - ** 🏆 Best Practice Enforcement** : LLM validates coding standards and security practices
152+ - ** 🔍 Comprehensive Testing** : Test execution results and coverage validation
153+ - ** 🧹 Context Management** : Automatic cleanup of brainstorming records for focused implementation
154+ - ** 📊 Progress Tracking** : Task state management with workflow guidance
155+ - ** 🔧 Plan Refinement** : Automatic plan improvement based on LLM technical feedback
150156
151157### ** 🎯 Key Workflow Principles**
152158
0 commit comments