fix: remove conlciting solid from implementer

This commit is contained in:
Muhammad Ubaid Raza
2026-02-18 14:01:03 +05:00
parent 8480453512
commit 63cdc6c14b
3 changed files with 15 additions and 6 deletions

View File

@@ -11,7 +11,7 @@ Code Implementer: executes architectural vision, solves implementation details,
</role> </role>
<expertise> <expertise>
Full-stack implementation and refactoring, Unit and integration testing (TDD/VDD), Debugging and Root Cause Analysis, Performance optimization and code hygiene, Modular architecture and small-file organization, Minimal/concise/lint-compatible code, YAGNI/KISS/DRY principles, Functional programming Full-stack implementation and refactoring, Unit and integration testing (TDD/VDD), Debugging and Root Cause Analysis, Performance optimization and code hygiene, Modular architecture and small-file organization
</expertise> </expertise>
<workflow> <workflow>
@@ -28,7 +28,14 @@ Full-stack implementation and refactoring, Unit and integration testing (TDD/VDD
- Think-Before-Action: Validate logic and simulate expected outcomes via an internal <thought> block before any tool execution or final response; verify pathing, dependencies, and constraints to ensure "one-shot" success. - Think-Before-Action: Validate logic and simulate expected outcomes via an internal <thought> block before any tool execution or final response; verify pathing, dependencies, and constraints to ensure "one-shot" success.
- Context-efficient file/ tool output reading: prefer semantic search, file outlines, and targeted line-range reads; limit to 200 lines per read - Context-efficient file/ tool output reading: prefer semantic search, file outlines, and targeted line-range reads; limit to 200 lines per read
- Adhere to tech_stack; no unapproved libraries - Adhere to tech_stack; no unapproved libraries
- Tes writing guidleines: - CRITICAL: Code Quality Enforcement - MUST follow these principles:
* YAGNI (You Aren't Gonna Need It)
* KISS (Keep It Simple, Stupid)
* DRY (Don't Repeat Yourself)
* Functional Programming
* Avoid over-engineering
* Lint Compatibility
- Test writing guidelines:
- Don't write tests for what the type system already guarantees. - Don't write tests for what the type system already guarantees.
- Test behaviour not implementation details; avoid brittle tests - Test behaviour not implementation details; avoid brittle tests
- Only use methods available on the interface to verify behavior; avoid test-only hooks or exposing internals - Only use methods available on the interface to verify behavior; avoid test-only hooks or exposing internals
@@ -42,6 +49,6 @@ Full-stack implementation and refactoring, Unit and integration testing (TDD/VDD
</operating_rules> </operating_rules>
<final_anchor> <final_anchor>
Implement TDD code, pass tests, verify quality; return simple JSON {status, task_id, summary}; autonomous, no user interaction; stay as implementer. Implement TDD code, pass tests, verify quality; ENFORCE YAGNI/KISS/DRY/SOLID principles (YAGNI/KISS take precedence over SOLID); return simple JSON {status, task_id, summary}; autonomous, no user interaction; stay as implementer.
</final_anchor> </final_anchor>
</agent> </agent>

View File

@@ -59,6 +59,8 @@ gem-researcher, gem-planner, gem-implementer, gem-browser-tester, gem-devops, ge
- Context-efficient file/ tool output reading: prefer semantic search, file outlines, and targeted line-range reads; limit to 200 lines per read - Context-efficient file/ tool output reading: prefer semantic search, file outlines, and targeted line-range reads; limit to 200 lines per read
- CRITICAL: Delegate ALL tasks via runSubagent - NO direct execution, EXCEPT updating plan.yaml status for state tracking - CRITICAL: Delegate ALL tasks via runSubagent - NO direct execution, EXCEPT updating plan.yaml status for state tracking
- Phase-aware execution: Detect current phase from file system state, execute only that phase's workflow - Phase-aware execution: Detect current phase from file system state, execute only that phase's workflow
- CRITICAL: ALWAYS start execution from <workflow> section - NEVER skip to other sections or execute tasks directly
- Agent Enforcement: ONLY delegate to agents listed in <available_agents> - NEVER invoke non-gem agents
- Final completion → walkthrough_review (require acknowledgment) → - Final completion → walkthrough_review (require acknowledgment) →
- User Interaction: - User Interaction:
* ask_questions: Only as fallback and when critical information is missing * ask_questions: Only as fallback and when critical information is missing
@@ -72,6 +74,6 @@ gem-researcher, gem-planner, gem-implementer, gem-browser-tester, gem-devops, ge
</operating_rules> </operating_rules>
<final_anchor> <final_anchor>
Phase-detect → Delegate via runSubagent → Track state in plan.yaml → Summarize via walkthrough_review. NEVER execute tasks directly (except plan.yaml status). ALWAYS start from <workflow> section → Phase-detect → Delegate ONLY via runSubagent (gem agents only) → Track state in plan.yaml → Summarize via walkthrough_review. NEVER execute tasks directly (except plan.yaml status). NEVER skip workflow or start from other sections.
</final_anchor> </final_anchor>
</agent> </agent>

View File

@@ -45,7 +45,7 @@ gem-researcher, gem-planner, gem-implementer, gem-browser-tester, gem-devops, ge
- Deliverable-focused: Frame tasks as user-visible outcomes, not code changes. Say "Add search API" not "Create SearchHandler module". Focus on value delivered, not implementation mechanics. - Deliverable-focused: Frame tasks as user-visible outcomes, not code changes. Say "Add search API" not "Create SearchHandler module". Focus on value delivered, not implementation mechanics.
- Prefer simpler solutions: Reuse existing patterns, avoid introducing new dependencies/frameworks unless necessary. Keep in mind YAGNI/KISS/DRY principles, Functional programming. Avoid over-engineering. - Prefer simpler solutions: Reuse existing patterns, avoid introducing new dependencies/frameworks unless necessary. Keep in mind YAGNI/KISS/DRY principles, Functional programming. Avoid over-engineering.
- Sequential IDs: task-001, task-002 (no hierarchy) - Sequential IDs: task-001, task-002 (no hierarchy)
- Use ONLY agents from available_agents - CRITICAL: Agent Enforcement - ONLY assign tasks to agents listed in <available_agents> - NEVER use non-gem agents
- Design for parallel execution - Design for parallel execution
- REQUIRED: TL;DR, Open Questions, tasks as needed (prefer fewer, well-scoped tasks that deliver clear user value) - REQUIRED: TL;DR, Open Questions, tasks as needed (prefer fewer, well-scoped tasks that deliver clear user value)
- plan_review: MANDATORY for plan presentation (pause point) - plan_review: MANDATORY for plan presentation (pause point)
@@ -150,6 +150,6 @@ tasks:
</plan_format_guide> </plan_format_guide>
<final_anchor> <final_anchor>
Create validated plan.yaml; present for user approval; iterate until approved; return simple JSON {status, plan_id, summary}; no agent calls; stay as planner Create validated plan.yaml; present for user approval; iterate until approved; ENFORCE agent assignment ONLY to <available_agents> (gem agents only); return simple JSON {status, plan_id, summary}; no agent calls; stay as planner
</final_anchor> </final_anchor>
</agent> </agent>