@heyai-rules/pilo-masterkit 1.2.2 → 2.2.0

package/.agent/workflows/santa-loop.md

@@ -0,0 +1,175 @@
+---
+description: Adversarial dual-review convergence loop — two independent model reviewers must both approve before code ships.
+---
+
+# Santa Loop
+
+Adversarial dual-review convergence loop using the santa-method skill. Two independent reviewers — different models, no shared context — must both return NICE before code ships.
+
+## Purpose
+
+Run two independent reviewers (Claude Opus + an external model) against the current task output. Both must return NICE before the code is pushed. If either returns NAUGHTY, fix all flagged issues, commit, and re-run fresh reviewers — up to 3 rounds.
+
+## Usage
+
+```
+/santa-loop [file-or-glob | description]
+```
+
+## Workflow
+
+### Step 1: Identify What to Review
+
+Determine the scope from `$ARGUMENTS` or fall back to uncommitted changes:
+
+```bash
+git diff --name-only HEAD
+```
+
+Read all changed files to build the full review context. If `$ARGUMENTS` specifies a path, file, or description, use that as the scope instead.
+
+### Step 2: Build the Rubric
+
+Construct a rubric appropriate to the file types under review. Every criterion must have an objective PASS/FAIL condition. Include at minimum:
+
+| Criterion | Pass Condition |
+|-----------|---------------|
+| Correctness | Logic is sound, no bugs, handles edge cases |
+| Security | No secrets, injection, XSS, or OWASP Top 10 issues |
+| Error handling | Errors handled explicitly, no silent swallowing |
+| Completeness | All requirements addressed, no missing cases |
+| Internal consistency | No contradictions between files or sections |
+| No regressions | Changes don't break existing behavior |
+
+Add domain-specific criteria based on file types (e.g., type safety for TS, memory safety for Rust, migration safety for SQL).
+
+### Step 3: Dual Independent Review
+
+Launch two reviewers **in parallel** using the Agent tool (both in a single message for concurrent execution). Both must complete before proceeding to the verdict gate.
+
+Each reviewer evaluates every rubric criterion as PASS or FAIL, then returns structured JSON:
+
+```json
+{
+  "verdict": "PASS" | "FAIL",
+  "checks": [
+    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
+  ],
+  "critical_issues": ["..."],
+  "suggestions": ["..."]
+}
+```
+
+The verdict gate (Step 4) maps these to NICE/NAUGHTY: both PASS → NICE, either FAIL → NAUGHTY.
+
+#### Reviewer A: Claude Agent (always runs)
+
+Launch an Agent (subagent_type: `code-reviewer`, model: `opus`) with the full rubric + all files under review. The prompt must include:
+- The complete rubric
+- All file contents under review
+- "You are an independent quality reviewer. You have NOT seen any other review. Your job is to find problems, not to approve."
+- Return the structured JSON verdict above
+
+#### Reviewer B: External Model (Claude fallback only if no external CLI installed)
+
+First, detect which CLIs are available:
+```bash
+command -v codex >/dev/null 2>&1 && echo "codex" || true
+command -v gemini >/dev/null 2>&1 && echo "gemini" || true
+```
+
+Build the reviewer prompt (identical rubric + instructions as Reviewer A) and write it to a unique temp file:
+```bash
+PROMPT_FILE=$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt)
+cat > "$PROMPT_FILE" << 'EOF'
+... full rubric + file contents + reviewer instructions ...
+EOF
+```
+
+Use the first available CLI:
+
+**Codex CLI** (if installed)
+```bash
+codex exec --sandbox read-only -m gpt-5.4 -C "$(pwd)" - < "$PROMPT_FILE"
+rm -f "$PROMPT_FILE"
+```
+
+**Gemini CLI** (if installed and codex is not)
+```bash
+gemini -p "$(cat "$PROMPT_FILE")" -m gemini-2.5-pro
+rm -f "$PROMPT_FILE"
+```
+
+**Claude Agent fallback** (only if neither `codex` nor `gemini` is installed)
+Launch a second Claude Agent (subagent_type: `code-reviewer`, model: `opus`). Log a warning that both reviewers share the same model family — true model diversity was not achieved but context isolation is still enforced.
+
+In all cases, the reviewer must return the same structured JSON verdict as Reviewer A.
+
+### Step 4: Verdict Gate
+
+- **Both PASS** → **NICE** — proceed to Step 6 (push)
+- **Either FAIL** → **NAUGHTY** — merge all critical issues from both reviewers, deduplicate, proceed to Step 5
+
+### Step 5: Fix Cycle (NAUGHTY path)
+
+1. Display all critical issues from both reviewers
+2. Fix every flagged issue — change only what was flagged, no drive-by refactors
+3. Commit all fixes in a single commit:
+   ```
+   fix: address santa-loop review findings (round N)
+   ```
+4. Re-run Step 3 with **fresh reviewers** (no memory of previous rounds)
+5. Repeat until both return PASS
+
+**Maximum 3 iterations.** If still NAUGHTY after 3 rounds, stop and present remaining issues:
+
+```
+SANTA LOOP ESCALATION (exceeded 3 iterations)
+
+Remaining issues after 3 rounds:
+- [list all unresolved critical issues from both reviewers]
+
+Manual review required before proceeding.
+```
+
+Do NOT push.
+
+### Step 6: Push (NICE path)
+
+When both reviewers return PASS:
+
+```bash
+git push -u origin HEAD
+```
+
+### Step 7: Final Report
+
+Print the output report (see Output section below).
+
+## Output
+
+```
+SANTA VERDICT: [NICE / NAUGHTY (escalated)]
+
+Reviewer A (Claude Opus):   [PASS/FAIL]
+Reviewer B ([model used]):  [PASS/FAIL]
+
+Agreement:
+  Both flagged:      [issues caught by both]
+  Reviewer A only:   [issues only A caught]
+  Reviewer B only:   [issues only B caught]
+
+Iterations: [N]/3
+Result:     [PUSHED / ESCALATED TO USER]
+```
+
+## Notes
+
+- Reviewer A (Claude Opus) always runs — guarantees at least one strong reviewer regardless of tooling.
+- Model diversity is the goal for Reviewer B. GPT-5.4 or Gemini 2.5 Pro gives true independence — different training data, different biases, different blind spots. The Claude-only fallback still provides value via context isolation but loses model diversity.
+- Strongest available models are used: Opus for Reviewer A, GPT-5.4 or Gemini 2.5 Pro for Reviewer B.
+- External reviewers run with `--sandbox read-only` (Codex) to prevent repo mutation during review.
+- Fresh reviewers each round prevents anchoring bias from prior findings.
+- The rubric is the most important input. Tighten it if reviewers rubber-stamp or flag subjective style issues.
+- Commits happen on NAUGHTY rounds so fixes are preserved even if the loop is interrupted.
+- Push only happens after NICE — never mid-loop.

package/.agent/workflows/save-session.md

@@ -130,10 +130,10 @@ If nothing is queued: "No specific untried approaches identified."
 
 | File              | Status         | Notes                      |
 | ----------------- | -------------- | -------------------------- |
-| `path/to/file.ts` | ✅ Complete    | [what it does]             |
-| `path/to/file.ts` | 🔄 In Progress | [what's done, what's left] |
-| `path/to/file.ts` | ❌ Broken      | [what's wrong]             |
-| `path/to/file.ts` | 🗒️ Not Started | [planned but not touched]  |
+| `path/to/file.ts` | PASS: Complete    | [what it does]             |
+| `path/to/file.ts` |  In Progress | [what's done, what's left] |
+| `path/to/file.ts` | FAIL: Broken      | [what's wrong]             |
+| `path/to/file.ts` |  Not Started | [planned but not touched]  |
 
 If no files were touched: "No files modified this session."
 
@@ -235,11 +235,11 @@ refreshes without exposing the token to JavaScript.
 
 | File                             | Status         | Notes                                           |
 | -------------------------------- | -------------- | ----------------------------------------------- |
-| `app/api/auth/register/route.ts` | ✅ Complete    | Works, tested                                   |
-| `app/api/auth/login/route.ts`    | 🔄 In Progress | Token generates but not setting cookie yet      |
-| `lib/auth.ts`                    | ✅ Complete    | JWT helpers, all tested                         |
-| `middleware.ts`                  | 🗒️ Not Started | Route protection, needs cookie read logic first |
-| `app/login/page.tsx`             | 🗒️ Not Started | UI not started                                  |
+| `app/api/auth/register/route.ts` | PASS: Complete    | Works, tested                                   |
+| `app/api/auth/login/route.ts`    |  In Progress | Token generates but not setting cookie yet      |
+| `lib/auth.ts`                    | PASS: Complete    | JWT helpers, all tested                         |
+| `middleware.ts`                  |  Not Started | Route protection, needs cookie read logic first |
+| `app/login/page.tsx`             |  Not Started | UI not started                                  |
 
 ---
 

package/.agent/workflows/status.md

@@ -1,86 +1,86 @@
----
-description: Display agent and project status. Progress tracking and status board.
----
-
-# /status - Show Status
-
-$ARGUMENTS
-
----
-
-## Task
-
-Show current project and agent status.
-
-### What It Shows
-
-1. **Project Info**
-   - Project name and path
-   - Tech stack
-   - Current features
-
-2. **Agent Status Board**
-   - Which agents are running
-   - Which tasks are completed
-   - Pending work
-
-3. **File Statistics**
-   - Files created count
-   - Files modified count
-
-4. **Preview Status**
-   - Is server running
-   - URL
-   - Health check
-
----
-
-## Example Output
-
-```
-=== Project Status ===
-
-📁 Project: my-ecommerce
-📂 Path: C:/projects/my-ecommerce
-🏷️ Type: nextjs-ecommerce
-📊 Status: active
-
-🔧 Tech Stack:
-   Framework: next.js
-   Database: postgresql
-   Auth: clerk
-   Payment: stripe
-
-✅ Features (5):
-   • product-listing
-   • cart
-   • checkout
-   • user-auth
-   • order-history
-
-⏳ Pending (2):
-   • admin-panel
-   • email-notifications
-
-📄 Files: 73 created, 12 modified
-
-=== Agent Status ===
-
-✅ database-architect → Completed
-✅ backend-specialist → Completed
-🔄 frontend-specialist → Dashboard components (60%)
-⏳ test-engineer → Waiting
-
-=== Preview ===
-
-🌐 URL: http://localhost:3000
-💚 Health: OK
-```
-
----
-
-## Technical
-
-Status uses these scripts:
-- `python .agent/scripts/session_manager.py status`
-- `python .agent/scripts/auto_preview.py status`
+---
+description: Display agent and project status. Progress tracking and status board.
+---
+
+# /status - Show Status
+
+$ARGUMENTS
+
+---
+
+## Task
+
+Show current project and agent status.
+
+### What It Shows
+
+1. **Project Info**
+   - Project name and path
+   - Tech stack
+   - Current features
+
+2. **Agent Status Board**
+   - Which agents are running
+   - Which tasks are completed
+   - Pending work
+
+3. **File Statistics**
+   - Files created count
+   - Files modified count
+
+4. **Preview Status**
+   - Is server running
+   - URL
+   - Health check
+
+---
+
+## Example Output
+
+```
+=== Project Status ===
+
+📁 Project: my-ecommerce
+📂 Path: C:/projects/my-ecommerce
+🏷️ Type: nextjs-ecommerce
+📊 Status: active
+
+🔧 Tech Stack:
+   Framework: next.js
+   Database: postgresql
+   Auth: clerk
+   Payment: stripe
+
+✅ Features (5):
+   • product-listing
+   • cart
+   • checkout
+   • user-auth
+   • order-history
+
+⏳ Pending (2):
+   • admin-panel
+   • email-notifications
+
+📄 Files: 73 created, 12 modified
+
+=== Agent Status ===
+
+✅ database-architect → Completed
+✅ backend-specialist → Completed
+🔄 frontend-specialist → Dashboard components (60%)
+⏳ test-engineer → Waiting
+
+=== Preview ===
+
+🌐 URL: http://localhost:3000
+💚 Health: OK
+```
+
+---
+
+## Technical
+
+Status uses these scripts:
+- `python .agent/scripts/session_manager.py status`
+- `python .agent/scripts/auto_preview.py status`

package/.agent/workflows/tdd.md

@@ -1,123 +1,26 @@
 ---
-description: Enforce test-driven development workflow. Scaffold interfaces, generate tests FIRST, then implement minimal code to pass. Ensure 80%+ coverage.
+description: Legacy slash-entry shim for the tdd-workflow skill. Prefer the skill directly.
 ---
 
-# TDD Command
+# TDD Command (Legacy Shim)
 
-This command invokes the **tdd-guide** agent to enforce test-driven development methodology.
+Use this only if you still invoke `/tdd`. The maintained workflow lives in `skills/tdd-workflow/SKILL.md`.
 
-## What This Command Does
+## Canonical Surface
 
-1. **Scaffold Interfaces** - Define types/interfaces first
-2. **Generate Tests First** - Write failing tests (RED)
-3. **Implement Minimal Code** - Write just enough to pass (GREEN)
-4. **Refactor** - Improve code while keeping tests green (REFACTOR)
-5. **Verify Coverage** - Ensure 80%+ test coverage
+- Prefer the `tdd-workflow` skill directly.
+- Keep this file only as a compatibility entry point.
 
-## When to Use
+## Arguments
 
-Use `/tdd` when:
-- Implementing new features
-- Adding new functions/components
-- Fixing bugs (write test that reproduces bug first)
-- Refactoring existing code
-- Building critical business logic
+`$ARGUMENTS`
 
-## How It Works
+## Delegation
 
-The tdd-guide agent will:
-
-1. **Define interfaces** for inputs/outputs
-2. **Write tests that will FAIL** (because code doesn't exist yet)
-3. **Run tests** and verify they fail for the right reason
-4. **Write minimal implementation** to make tests pass
-5. **Run tests** and verify they pass
-6. **Refactor** code while keeping tests green
-7. **Check coverage** and add more tests if below 80%
-
-## TDD Cycle
-
-```
-RED → GREEN → REFACTOR → REPEAT
-
-RED:      Write a failing test
-GREEN:    Write minimal code to pass
-REFACTOR: Improve code, keep tests passing
-REPEAT:   Next feature/scenario
-```
-
-## Example Usage
-
-```
-User: /tdd I need a function to calculate market liquidity score
-
-Agent (tdd-guide):
-# TDD Session: Market Liquidity Score Calculator
-
-## Step 1: Define Interface (SCAFFOLD)
-
-```typescript
-// lib/liquidity.ts
-export interface MarketData {
-  totalVolume: number
-  bidAskSpread: number
-  activeTraders: number
-  lastTradeTime: Date
-}
-
-export function calculateLiquidityScore(market: MarketData): number {
-  // TODO: Implementation
-  throw new Error('Not implemented')
-}
-```
-
-## Step 2: Write Failing Test (RED)
-
-```typescript
-// lib/liquidity.test.ts
-import { calculateLiquidityScore } from './liquidity'
-
-describe('calculateLiquidityScore', () => {
-  it('should return high score for liquid market', () => {
-    const market = {
-      totalVolume: 100000,
-      bidAskSpread: 0.01,
-      activeTraders: 500,
-      lastTradeTime: new Date()
-    }
-
-    const score = calculateLiquidityScore(market)
-
-    expect(score).toBeGreaterThan(80)
-    expect(score).toBeLessThanOrEqual(100)
-  })
-
-  it('should return low score for illiquid market', () => {
-    const market = {
-      totalVolume: 100,
-      bidAskSpread: 0.5,
-      activeTraders: 2,
-      lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago
-    }
-
-    const score = calculateLiquidityScore(market)
-
-    expect(score).toBeLessThan(30)
-    expect(score).toBeGreaterThanOrEqual(0)
-  })
-
-  it('should handle edge case: zero volume', () => {
-    const market = {
-      totalVolume: 0,
-      bidAskSpread: 0,
-      activeTraders: 0,
-      lastTradeTime: new Date()
-    }
-
-    const score = calculateLiquidityScore(market)
-
-    expect(score).toBe(0)
-  })
+Apply the `tdd-workflow` skill.
+- Stay strict on RED -> GREEN -> REFACTOR.
+- Keep tests first, coverage explicit, and checkpoint evidence clear.
+- Use the skill as the maintained TDD body instead of duplicating the playbook here.
 })
 ```
 
@@ -133,7 +36,7 @@ FAIL lib/liquidity.test.ts
 1 test failed, 0 passed
 ```
 
-✅ Tests fail as expected. Ready to implement.
+PASS: Tests fail as expected. Ready to implement.
 
 ## Step 4: Implement Minimal Code (GREEN)
 
@@ -179,7 +82,7 @@ PASS lib/liquidity.test.ts
 3 tests passed
 ```
 
-✅ All tests passing!
+PASS: All tests passing!
 
 ## Step 6: Refactor (IMPROVE)
 
@@ -236,7 +139,7 @@ PASS lib/liquidity.test.ts
 3 tests passed
 ```
 
-✅ Refactoring complete, tests still passing!
+PASS: Refactoring complete, tests still passing!
 
 ## Step 8: Check Coverage
 
@@ -247,29 +150,29 @@ File           | % Stmts | % Branch | % Funcs | % Lines
 ---------------|---------|----------|---------|--------
 liquidity.ts   |   100   |   100    |   100   |   100
 
-Coverage: 100% ✅ (Target: 80%)
+Coverage: 100% PASS: (Target: 80%)
 ```
 
-✅ TDD session complete!
+PASS: TDD session complete!
 ```
 
 ## TDD Best Practices
 
 **DO:**
-- ✅ Write the test FIRST, before any implementation
-- ✅ Run tests and verify they FAIL before implementing
-- ✅ Write minimal code to make tests pass
-- ✅ Refactor only after tests are green
-- ✅ Add edge cases and error scenarios
-- ✅ Aim for 80%+ coverage (100% for critical code)
+- PASS: Write the test FIRST, before any implementation
+- PASS: Run tests and verify they FAIL before implementing
+- PASS: Write minimal code to make tests pass
+- PASS: Refactor only after tests are green
+- PASS: Add edge cases and error scenarios
+- PASS: Aim for 80%+ coverage (100% for critical code)
 
 **DON'T:**
-- ❌ Write implementation before tests
-- ❌ Skip running tests after each change
-- ❌ Write too much code at once
-- ❌ Ignore failing tests
-- ❌ Test implementation details (test behavior)
-- ❌ Mock everything (prefer integration tests)
+- FAIL: Write implementation before tests
+- FAIL: Skip running tests after each change
+- FAIL: Write too much code at once
+- FAIL: Ignore failing tests
+- FAIL: Test implementation details (test behavior)
+- FAIL: Mock everything (prefer integration tests)
 
 ## Test Types to Include
 

package/.agent/workflows/test-coverage.md

@@ -57,7 +57,7 @@ File                   Before  After
 src/services/auth.ts   45%     88%
 src/utils/validation.ts 32%    82%
 ──────────────────────────────
-Overall:               67%     84%  ✅
+Overall:               67%     84%  PASS:
 ```
 
 ## Focus Areas