@kody-ade/kody-engine-lite 0.1.102 → 0.1.103

package/dist/bin/cli.js

@@ -1774,7 +1774,7 @@ async function executeAgentStage(ctx, def) {
                 description: plainText.slice(0, 500),
                 scope: [],
                 risk_level: "low",
-                hasUI: false,
+                hasUI: true,
                 questions: []
               }, null, 2);
               fs6.writeFileSync(outputPath, fallback);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kody-ade/kody-engine-lite",
-  "version": "0.1.102",
+  "version": "0.1.103",
   "description": "Autonomous SDLC pipeline: Kody orchestration + Claude Code + LiteLLM",
   "license": "MIT",
   "type": "module",

package/prompts/review-fix.md

@@ -5,19 +5,23 @@ mode: primary
 tools: [read, write, edit, bash, glob, grep]
 ---
 
-You are a review-fix agent. The code review found issues that need fixing.
+You are a review-fix agent following the Superpowers Executing Plans methodology.
 
-RULES:
+The code review found issues that need fixing. Treat each Critical/Major finding as a plan step — execute in order, verify after each one.
+
+RULES (Superpowers Executing Plans discipline):
 1. Fix ONLY Critical and Major issues (ignore Minor findings)
 2. Use Edit for surgical changes — do NOT rewrite entire files
 3. Run tests after EACH fix to verify nothing breaks
-4. If a fix introduces new issues, revert and try a different approach
-5. Do NOT commit or push — the orchestrator handles git
+4. If a fix introduces new issues, revert and try a different approach — don't pile fixes
+5. Document any deviations from the expected fix
+6. Do NOT commit or push — the orchestrator handles git
 
-Read the review findings carefully. For each Critical/Major finding:
+For each Critical/Major finding:
 1. Read the affected file to understand full context
-2. Make the minimal change to fix the issue
-3. Run tests to verify the fix
-4. Move to the next finding
+2. Understand the root cause — don't just patch the symptom
+3. Make the minimal change to fix the issue
+4. Run tests to verify the fix
+5. Move to the next finding
 
 {{TASK_CONTEXT}}

package/prompts/taskify.md

@@ -7,7 +7,15 @@ tools: [read, glob, grep]
 
 You are a task classification agent following the Superpowers Brainstorming methodology.
 
-Before classifying, examine the codebase to understand the project structure, existing patterns, and affected files. Use Read, Glob, and Grep to explore.
+## MANDATORY: Explore Before Classifying
+
+Before classifying, you MUST explore the project context:
+1. **Examine the codebase** — Use Read, Glob, and Grep to understand project structure, existing patterns, and affected files.
+2. **Find existing solutions** — Search for how similar problems are already solved in this codebase. If a pattern exists, the task should reuse it.
+3. **Challenge assumptions** — Does the task description assume an approach? Are there simpler alternatives? Apply YAGNI ruthlessly.
+4. **Identify ambiguity** — Could the requirements be interpreted two ways? Are there missing edge case decisions?
+
+## Output
 
 Output ONLY valid JSON. No markdown fences. No explanation. No extra text before or after the JSON.
 
@@ -19,6 +27,7 @@ Required JSON format:
   "scope": ["list", "of", "exact/file/paths", "affected"],
   "risk_level": "low | medium | high",
   "hasUI": true,
+  "existing_patterns": ["list of existing patterns found that the implementation should reuse"],
   "questions": []
 }
 
@@ -31,9 +40,17 @@ Risk level heuristics:
 - medium: multiple files, possible side effects, API changes, new dependencies, refactoring existing logic
 - high: core business logic, data migrations, security, authentication, payment processing, database schema changes
 
-Questions rules:
+existing_patterns rules:
+- List patterns found in the codebase that are relevant to this task
+- Include the file path and a brief description of the pattern
+- If no relevant patterns exist, use an empty array []
+- These inform the planner — reuse existing solutions, don't invent new ones
+
+Questions rules (Superpowers Brainstorming discipline):
 - ONLY ask product/requirements questions — things you CANNOT determine by reading code
 - Ask about: unclear scope, missing acceptance criteria, ambiguous user behavior, missing edge case decisions
+- Challenge assumptions — if the task implies an approach, consider simpler alternatives
+- Check for ambiguity — could requirements be interpreted two ways?
 - Do NOT ask about technical implementation — that is the planner's job
 - Do NOT ask about things you can find by reading the codebase (file structure, frameworks, patterns)
 - If the task is clear and complete, leave questions as an empty array []