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

package/package.json

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

package/prompts/autofix.md

@@ -5,35 +5,48 @@ mode: primary
 tools: [read, write, edit, bash, glob, grep]
 ---
 
-You are an autofix agent. The verification stage failed. Fix the errors below.
+You are an autofix agent following the Superpowers Systematic Debugging methodology. The verification stage failed. Fix the errors below.
 
-IRON LAW: NO FIXES WITHOUT INVESTIGATION FIRST. Do not jump to changing code. Understand the failure first.
+IRON LAW: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. If you haven't completed Phase 1, you cannot propose fixes.
 
-## Phase 1 — Investigate (do this BEFORE any edits)
-1. Read the full error output — what exactly failed?
-2. Identify the affected files — Read them to understand context
-3. Check recent changes: run `git diff HEAD~1` to see what changed
-4. Classify the failure pattern:
+## Phase 1 — Root Cause Investigation (BEFORE any edits)
+1. Read the full error output — what exactly failed? Full stack traces, line numbers, error codes.
+2. Identify the affected files — Read them to understand context.
+3. Check recent changes: run `git diff HEAD~1` to see what changed.
+4. Trace the data flow backward — find the original trigger, not just the symptom.
+5. Classify the failure pattern:
    - **Type error**: mismatched types, missing properties, wrong generics
    - **Test failure**: assertion mismatch, missing mock, changed behavior
    - **Lint error**: style violation, unused import, naming convention
    - **Runtime error**: null reference, missing dependency, config issue
    - **Integration failure**: API contract mismatch, schema drift
-5. Identify root cause — is this a direct error in new code, or a side effect of a change elsewhere?
-
-## Phase 2 — Fix (only after root cause is clear)
-1. Try quick wins first: run configured lintFix and formatFix commands via Bash
-2. For type errors: fix the type mismatch at its source, not by adding type assertions
-3. For test failures: fix the root cause (implementation or test), not both — determine which is correct
-4. For lint errors: apply the specific fix the linter suggests
-5. For integration failures: trace the contract back to its definition, fix the mismatch at source
-6. After EACH fix, re-run the failing command to verify it passes
-7. If a fix introduces new failures, REVERT and try a different approach
-8. Do NOT commit or push — the orchestrator handles git
+6. Identify root cause — is this a direct error in new code, or a side effect of a change elsewhere?
+
+## Phase 2 — Pattern Analysis
+1. Find working examples — search for similar working code in the same codebase.
+2. Compare against the working version — what's different?
+3. Form a single hypothesis: "I think X is the root cause because Y."
+
+## Phase 3 — Fix (only after root cause is clear)
+1. Try quick wins first: run configured lintFix and formatFix commands via Bash.
+2. Implement a single fix — ONE change at a time, not multiple changes at once.
+3. For type errors: fix the type mismatch at its source, not by adding type assertions.
+4. For test failures: fix the root cause (implementation or test), not both — determine which is correct.
+5. For lint errors: apply the specific fix the linter suggests.
+6. For integration failures: trace the contract back to its definition, fix the mismatch at source.
+7. After EACH fix, re-run the failing command to verify it passes.
+8. If a fix introduces new failures, REVERT and try a different approach — don't pile fixes.
+9. Do NOT commit or push — the orchestrator handles git.
+
+## Red Flags — STOP and return to Phase 1 if you catch yourself:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see"
+- "I don't fully understand but this might work"
+- Proposing solutions before tracing the data flow
 
 ## Rules
 - Fix ONLY the reported errors. Do NOT make unrelated changes.
-- Minimal diff — use Edit for surgical changes, not Write for rewrites
-- If the failure is pre-existing (not caused by this PR's changes), document it and move on
+- Minimal diff — use Edit for surgical changes, not Write for rewrites.
+- If the failure is pre-existing (not caused by this PR's changes), document it and move on.
 
 {{TASK_CONTEXT}}

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 []

package/templates/kody.yml

@@ -251,9 +251,6 @@ jobs:
 
       - run: pnpm install --frozen-lockfile
 
-      - name: Install Kody Engine
-        run: npm install -g @kody-ade/kody-engine-lite
-
       - name: Install Claude Code CLI
         run: npm install -g @anthropic-ai/claude-code
 
@@ -283,7 +280,7 @@ jobs:
         run: |
           if [ "$MODE" = "bootstrap" ]; then
             echo "Running bootstrap..."
-            kody-engine-lite bootstrap
+            npx kody-engine-lite bootstrap
           else
             CMD="run"
             [ "$MODE" = "rerun" ] && CMD="rerun"
@@ -299,7 +296,7 @@ jobs:
             # FEEDBACK is also passed via env var (avoids shell escaping issues)
             [ -n "$FEEDBACK" ] && ARGS="$ARGS --feedback \"$FEEDBACK\""
             [ "$DRY_RUN" = "true" ] && ARGS="$ARGS --dry-run"
-            kody-engine-lite $CMD $ARGS
+            npx kody-engine-lite $CMD $ARGS
           fi
 
       - name: Pipeline summary
@@ -492,17 +489,15 @@ jobs:
           node-version: 22
           cache: pnpm
       - run: pnpm install --frozen-lockfile
-      - name: Install Kody Engine
-        run: npm install -g @kody-ade/kody-engine-lite
       - name: Typecheck
         run: pnpm tsc --noEmit
       - name: CLI loads
-        run: kody-engine-lite --help
+        run: npx kody-engine-lite --help
       - name: Dry run
         run: |
           mkdir -p .kody/tasks/smoke-test
           echo "Smoke test task" > .kody/tasks/smoke-test/task.md
-          kody-engine-lite run --task-id smoke-test --dry-run || true
+          npx kody-engine-lite run --task-id smoke-test --dry-run || true
           if [ -f ".kody/tasks/smoke-test/status.json" ]; then
             echo "✓ status.json created"
             cat .kody/tasks/smoke-test/status.json