@su-record/vibe 2.8.51 → 2.8.53

package/skills/exec-plan/agents/estimator.md

@@ -1,43 +1,43 @@
----
-name: plan-estimator
-role: Estimates complexity and duration for each task and suggests parallelization strategy
-tools: [Read, Glob]
----
-
-# Plan Estimator
-
-## Role
-Assigns complexity and effort estimates to each task based on task type, scope, and codebase context. Uses the dependency graph to compute the estimated critical path duration and suggest an optimal parallel execution wave plan that minimizes total clock time.
-
-## Responsibilities
-- Assign effort estimates per task: trivial (< 15 min), minor (15-30 min), moderate (30-60 min), major (> 60 min)
-- Check existing codebase for similar implementations to calibrate estimates
-- Compute total sequential estimate and parallel estimate using the DAG waves
-- Group tasks into execution waves: Wave 1 (no deps), Wave 2 (deps only on Wave 1), etc.
-- Identify tasks suitable for sub-agent delegation vs. tasks requiring orchestrator attention
-- Flag tasks with high uncertainty that need a spike/research step first
-
-## Input
-Task list JSON from `plan-decomposer` and dependency graph from `plan-dependency-mapper`.
-
-## Output
-Estimated plan with waves:
-```json
-{
-  "totalSequentialEstimate": "4h 30m",
-  "totalParallelEstimate": "2h 15m",
-  "waves": [
-    { "wave": 1, "tasks": ["T1"], "estimate": "30m", "note": "Foundation — must complete before anything else" },
-    { "wave": 2, "tasks": ["T2", "T3"], "estimate": "45m", "note": "Parallel — independent of each other" },
-    { "wave": 3, "tasks": ["T4", "T5"], "estimate": "60m", "note": "Integration — requires wave 2 output" }
-  ],
-  "highUncertaintyTasks": ["T6 — no existing auth pattern to reference, consider spike first"]
-}
-```
-
-## Communication
-- Reports estimated plan to: `plan-validator`
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Complexity signals: new file creation = minor baseline; modifying existing file = trivial baseline + proportional to change scope; schema changes with migrations = moderate; cross-cutting changes (multiple files) = major. Parallelization is only safe when tasks have no shared file writes. Always add 20% buffer to estimates for integration and debugging time.
+---
+name: plan-estimator
+role: Estimates complexity and duration for each task and suggests parallelization strategy
+tools: [Read, Glob]
+---
+
+# Plan Estimator
+
+## Role
+Assigns complexity and effort estimates to each task based on task type, scope, and codebase context. Uses the dependency graph to compute the estimated critical path duration and suggest an optimal parallel execution wave plan that minimizes total clock time.
+
+## Responsibilities
+- Assign effort estimates per task: trivial (< 15 min), minor (15-30 min), moderate (30-60 min), major (> 60 min)
+- Check existing codebase for similar implementations to calibrate estimates
+- Compute total sequential estimate and parallel estimate using the DAG waves
+- Group tasks into execution waves: Wave 1 (no deps), Wave 2 (deps only on Wave 1), etc.
+- Identify tasks suitable for sub-agent delegation vs. tasks requiring orchestrator attention
+- Flag tasks with high uncertainty that need a spike/research step first
+
+## Input
+Task list JSON from `plan-decomposer` and dependency graph from `plan-dependency-mapper`.
+
+## Output
+Estimated plan with waves:
+```json
+{
+  "totalSequentialEstimate": "4h 30m",
+  "totalParallelEstimate": "2h 15m",
+  "waves": [
+    { "wave": 1, "tasks": ["T1"], "estimate": "30m", "note": "Foundation — must complete before anything else" },
+    { "wave": 2, "tasks": ["T2", "T3"], "estimate": "45m", "note": "Parallel — independent of each other" },
+    { "wave": 3, "tasks": ["T4", "T5"], "estimate": "60m", "note": "Integration — requires wave 2 output" }
+  ],
+  "highUncertaintyTasks": ["T6 — no existing auth pattern to reference, consider spike first"]
+}
+```
+
+## Communication
+- Reports estimated plan to: `plan-validator`
+- Receives instructions from: exec-plan orchestrator (SKILL.md)
+
+## Domain Knowledge
+Complexity signals: new file creation = minor baseline; modifying existing file = trivial baseline + proportional to change scope; schema changes with migrations = moderate; cross-cutting changes (multiple files) = major. Parallelization is only safe when tasks have no shared file writes. Always add 20% buffer to estimates for integration and debugging time.

package/skills/exec-plan/agents/validator.md

@@ -1,55 +1,55 @@
----
-name: plan-validator
-role: Validates the execution plan for completeness against the original SPEC acceptance criteria
-tools: [Read]
----
-
-# Plan Validator
-
-## Role
-Cross-checks the final execution plan against the original SPEC to verify that every acceptance criterion is covered by at least one task. Flags gaps, redundancies, and coverage ambiguities before implementation begins. Acts as the last gate before the plan is handed to the user for approval.
-
-## Responsibilities
-- Map each SPEC acceptance criterion to one or more tasks in the plan
-- Flag criteria with no corresponding task (coverage gap)
-- Flag tasks with no traceable SPEC criterion (scope creep risk)
-- Verify that every feature task has a corresponding test task
-- Check that error cases and edge cases mentioned in the SPEC are covered
-- Confirm the wave plan has no dependency violations (no task requires output from a later wave)
-
-## Input
-- Original SPEC document path
-- Estimated plan with waves from `plan-estimator`
-- Task list from `plan-decomposer`
-
-## Output
-Validation report:
-```markdown
-## Plan Validation Report
-
-### Coverage Matrix
-| SPEC Criterion | Covered By | Status |
-|----------------|------------|--------|
-| User can register with email | T1, T3, T7 | Covered |
-| Password must be hashed | T2 | Covered |
-| Rate limiting on login | — | **MISSING** |
-
-### Issues Found
-- **GAP**: SPEC section 2.3 "rate limiting" has no corresponding task — add before implementing
-- **SCOPE CREEP**: T9 "add analytics tracking" has no SPEC criterion — remove or add to SPEC
-
-### Test Coverage
-- 8/10 feature tasks have corresponding test tasks (T5, T8 missing tests)
-
-### Wave Integrity
-- All wave dependencies valid: no forward-reference violations detected
-
-**Verdict**: Plan requires 2 fixes before execution.
-```
-
-## Communication
-- Reports validation result to: orchestrator / user
-- Receives instructions from: exec-plan orchestrator (SKILL.md)
-
-## Domain Knowledge
-Traceability matrix: every acceptance criterion must map to at least one implementation task AND one test task. Gap detection: scan SPEC for action verbs (can, must, should, will) and verify each has a task. Wave integrity check: for each task in wave N, verify all its dependencies are in waves < N. A plan is valid when gaps = 0, all feature tasks have tests, and wave integrity passes.
+---
+name: plan-validator
+role: Validates the execution plan for completeness against the original SPEC acceptance criteria
+tools: [Read]
+---
+
+# Plan Validator
+
+## Role
+Cross-checks the final execution plan against the original SPEC to verify that every acceptance criterion is covered by at least one task. Flags gaps, redundancies, and coverage ambiguities before implementation begins. Acts as the last gate before the plan is handed to the user for approval.
+
+## Responsibilities
+- Map each SPEC acceptance criterion to one or more tasks in the plan
+- Flag criteria with no corresponding task (coverage gap)
+- Flag tasks with no traceable SPEC criterion (scope creep risk)
+- Verify that every feature task has a corresponding test task
+- Check that error cases and edge cases mentioned in the SPEC are covered
+- Confirm the wave plan has no dependency violations (no task requires output from a later wave)
+
+## Input
+- Original SPEC document path
+- Estimated plan with waves from `plan-estimator`
+- Task list from `plan-decomposer`
+
+## Output
+Validation report:
+```markdown
+## Plan Validation Report
+
+### Coverage Matrix
+| SPEC Criterion | Covered By | Status |
+|----------------|------------|--------|
+| User can register with email | T1, T3, T7 | Covered |
+| Password must be hashed | T2 | Covered |
+| Rate limiting on login | — | **MISSING** |
+
+### Issues Found
+- **GAP**: SPEC section 2.3 "rate limiting" has no corresponding task — add before implementing
+- **SCOPE CREEP**: T9 "add analytics tracking" has no SPEC criterion — remove or add to SPEC
+
+### Test Coverage
+- 8/10 feature tasks have corresponding test tasks (T5, T8 missing tests)
+
+### Wave Integrity
+- All wave dependencies valid: no forward-reference violations detected
+
+**Verdict**: Plan requires 2 fixes before execution.
+```
+
+## Communication
+- Reports validation result to: orchestrator / user
+- Receives instructions from: exec-plan orchestrator (SKILL.md)
+
+## Domain Knowledge
+Traceability matrix: every acceptance criterion must map to at least one implementation task AND one test task. Gap detection: scan SPEC for action verbs (can, must, should, will) and verify each has a task. Wave integrity check: for each task in wave N, verify all its dependencies are in waves < N. A plan is valid when gaps = 0, all feature tasks have tests, and wave integrity passes.

package/skills/exec-plan/orchestrator.md

@@ -1,70 +1,70 @@
----
-name: exec-plan-orchestrator
-type: orchestrator
-agents: [decomposer, dependency-mapper, estimator, validator]
----
-
-# Exec-Plan Orchestrator
-
-## Workflow
-
-### Phase 1: Decompose
-- **Agent**: decomposer
-- **Input**: SPEC document (phases, requirements, acceptance criteria)
-- **Output**: Flat task list `[{taskId, title, phase, files[], description}]`
-- **Parallel**: no — sequential read of SPEC structure
-
-### Phase 2: Map Dependencies
-- **Agent**: dependency-mapper
-- **Input**: Task list from Phase 1
-- **Output**: DAG as adjacency list `{taskId: [dependsOn[]]}` + critical path
-- **Parallel**: no — requires complete task list to resolve cross-task deps
-
-### Phase 3: Estimate
-- **Agent**: estimator
-- **Input**: Task list + DAG from Phases 1–2
-- **Output**: Per-task complexity score, parallelization opportunities, estimated effort tiers (S/M/L)
-- **Parallel**: yes — each task scored independently
-
-### Phase 4: Validate
-- **Agent**: validator
-- **Input**: Task list + SPEC requirements + acceptance criteria
-- **Output**: Coverage report — uncovered requirements flagged, missing tasks identified
-- **Parallel**: no — cross-references full SPEC against task list
-
-### Phase 5: Output Plan
-- **Agent**: orchestrator (self)
-- **Input**: All outputs from Phases 1–4
-- **Output**: Execution plan with DAG visualization, effort summary, parallelization batches
-- **Parallel**: no
-
-## DAG (Dependency Graph)
-
-```mermaid
-graph TD
-    A[Phase 1: Decomposer] --> B[Phase 2: Dependency-Mapper]
-    A --> D[Phase 4: Validator]
-    B --> C[Phase 3: Estimator\nparallel per task]
-    C --> E[Phase 5: Output Plan]
-    D --> E
-```
-
-## Error Handling
-
-| Phase | Failure Mode | Strategy |
-|-------|-------------|----------|
-| Phase 1 | SPEC missing or malformed | Escalate — cannot proceed without SPEC |
-| Phase 1 | SPEC has no phases defined | Treat entire SPEC as single phase, continue |
-| Phase 2 | Circular dependency detected | Flag cycle, escalate to user for resolution |
-| Phase 2 | Isolated task (no deps, no dependents) | Include as standalone, note in plan |
-| Phase 3 | Estimator cannot classify complexity | Default to M (medium), flag for manual review |
-| Phase 4 | Uncovered requirements found | Add placeholder tasks, mark as `needs-spec-clarification` |
-| Phase 5 | DAG too large to render (>20 nodes) | Render phase-level DAG only, link to task list |
-
-## Scalability Modes
-
-| Mode | When | Agents Used |
-|------|------|-------------|
-| Full | Normal operation | decomposer + dependency-mapper + estimator + validator |
-| Reduced | Small SPEC (<5 tasks) | decomposer + dependency-mapper only |
-| Single | Quick task list | decomposer only — flat list without DAG or estimates |
+---
+name: exec-plan-orchestrator
+type: orchestrator
+agents: [decomposer, dependency-mapper, estimator, validator]
+---
+
+# Exec-Plan Orchestrator
+
+## Workflow
+
+### Phase 1: Decompose
+- **Agent**: decomposer
+- **Input**: SPEC document (phases, requirements, acceptance criteria)
+- **Output**: Flat task list `[{taskId, title, phase, files[], description}]`
+- **Parallel**: no — sequential read of SPEC structure
+
+### Phase 2: Map Dependencies
+- **Agent**: dependency-mapper
+- **Input**: Task list from Phase 1
+- **Output**: DAG as adjacency list `{taskId: [dependsOn[]]}` + critical path
+- **Parallel**: no — requires complete task list to resolve cross-task deps
+
+### Phase 3: Estimate
+- **Agent**: estimator
+- **Input**: Task list + DAG from Phases 1–2
+- **Output**: Per-task complexity score, parallelization opportunities, estimated effort tiers (S/M/L)
+- **Parallel**: yes — each task scored independently
+
+### Phase 4: Validate
+- **Agent**: validator
+- **Input**: Task list + SPEC requirements + acceptance criteria
+- **Output**: Coverage report — uncovered requirements flagged, missing tasks identified
+- **Parallel**: no — cross-references full SPEC against task list
+
+### Phase 5: Output Plan
+- **Agent**: orchestrator (self)
+- **Input**: All outputs from Phases 1–4
+- **Output**: Execution plan with DAG visualization, effort summary, parallelization batches
+- **Parallel**: no
+
+## DAG (Dependency Graph)
+
+```mermaid
+graph TD
+    A[Phase 1: Decomposer] --> B[Phase 2: Dependency-Mapper]
+    A --> D[Phase 4: Validator]
+    B --> C[Phase 3: Estimator\nparallel per task]
+    C --> E[Phase 5: Output Plan]
+    D --> E
+```
+
+## Error Handling
+
+| Phase | Failure Mode | Strategy |
+|-------|-------------|----------|
+| Phase 1 | SPEC missing or malformed | Escalate — cannot proceed without SPEC |
+| Phase 1 | SPEC has no phases defined | Treat entire SPEC as single phase, continue |
+| Phase 2 | Circular dependency detected | Flag cycle, escalate to user for resolution |
+| Phase 2 | Isolated task (no deps, no dependents) | Include as standalone, note in plan |
+| Phase 3 | Estimator cannot classify complexity | Default to M (medium), flag for manual review |
+| Phase 4 | Uncovered requirements found | Add placeholder tasks, mark as `needs-spec-clarification` |
+| Phase 5 | DAG too large to render (>20 nodes) | Render phase-level DAG only, link to task list |
+
+## Scalability Modes
+
+| Mode | When | Agents Used |
+|------|------|-------------|
+| Full | Normal operation | decomposer + dependency-mapper + estimator + validator |
+| Reduced | Small SPEC (<5 tasks) | decomposer + dependency-mapper only |
+| Single | Quick task list | decomposer only — flat list without DAG or estimates |

package/skills/exec-plan/rubrics/complexity-scoring.md

@@ -1,75 +1,75 @@
-# Complexity Scoring Rubric
-
-Use this rubric to decide whether a task needs an ExecPlan and how to decompose it.
-
-## Scoring Dimensions
-
-Score each dimension 1–3. Total determines the approach.
-
-### Dimension 1: File Scope
-
-| Score | Criteria |
-|-------|----------|
-| 1 | 1–2 files touched |
-| 2 | 3–5 files touched |
-| 3 | 6+ files, or new module created |
-
-### Dimension 2: Dependency Depth
-
-| Score | Criteria |
-|-------|----------|
-| 1 | No external deps; isolated change |
-| 2 | 1–2 existing modules depended on |
-| 3 | Cross-layer dependencies; DB schema; API contract changes |
-
-### Dimension 3: Ambiguity
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Requirement is explicit; no design decisions needed |
-| 2 | 1–2 decision points that need resolution before coding |
-| 3 | Architecture-level decisions; unknown patterns; research needed |
-
-### Dimension 4: Test Surface
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Existing test file; trivial assertion additions |
-| 2 | New test file needed; mocking required |
-| 3 | Integration tests; DB fixtures; snapshot regeneration |
-
-### Dimension 5: Session Risk
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Fits in one session; easy to resume |
-| 2 | May span sessions; partial state is safe |
-| 3 | Long-running; partial state is dangerous; handoff required |
-
----
-
-## Decision Matrix
-
-| Total Score | Approach |
-|-------------|----------|
-| 5–7 | Plan Mode (in-head plan, no file needed) |
-| 8–10 | Light ExecPlan (phases only, no inline patterns) |
-| 11–13 | Full ExecPlan (all fields, inline patterns, phase gates) |
-| 14–15 | ExecPlan + parallel research before starting |
-
----
-
-## Decomposition Rules
-
-When total ≥ 11, decompose into phases:
-
-1. **One phase = one deployable unit** — each phase leaves the codebase in a working state
-2. **Max 3 scenarios per phase** — more means the phase is too large; split it
-3. **Phase gate before next phase** — build + tests must pass at each boundary
-4. **No implicit dependencies between phases** — phase 2 must not assume phase 1 code style; document patterns inline
-
-## Anti-patterns
-
-- Scoring 1 on all dimensions then creating an ExecPlan → overhead without benefit
-- Scoring 3 on ambiguity without resolving decisions first → plan will fail
-- Skipping phase gates to go faster → regressions compound
+# Complexity Scoring Rubric
+
+Use this rubric to decide whether a task needs an ExecPlan and how to decompose it.
+
+## Scoring Dimensions
+
+Score each dimension 1–3. Total determines the approach.
+
+### Dimension 1: File Scope
+
+| Score | Criteria |
+|-------|----------|
+| 1 | 1–2 files touched |
+| 2 | 3–5 files touched |
+| 3 | 6+ files, or new module created |
+
+### Dimension 2: Dependency Depth
+
+| Score | Criteria |
+|-------|----------|
+| 1 | No external deps; isolated change |
+| 2 | 1–2 existing modules depended on |
+| 3 | Cross-layer dependencies; DB schema; API contract changes |
+
+### Dimension 3: Ambiguity
+
+| Score | Criteria |
+|-------|----------|
+| 1 | Requirement is explicit; no design decisions needed |
+| 2 | 1–2 decision points that need resolution before coding |
+| 3 | Architecture-level decisions; unknown patterns; research needed |
+
+### Dimension 4: Test Surface
+
+| Score | Criteria |
+|-------|----------|
+| 1 | Existing test file; trivial assertion additions |
+| 2 | New test file needed; mocking required |
+| 3 | Integration tests; DB fixtures; snapshot regeneration |
+
+### Dimension 5: Session Risk
+
+| Score | Criteria |
+|-------|----------|
+| 1 | Fits in one session; easy to resume |
+| 2 | May span sessions; partial state is safe |
+| 3 | Long-running; partial state is dangerous; handoff required |
+
+---
+
+## Decision Matrix
+
+| Total Score | Approach |
+|-------------|----------|
+| 5–7 | Plan Mode (in-head plan, no file needed) |
+| 8–10 | Light ExecPlan (phases only, no inline patterns) |
+| 11–13 | Full ExecPlan (all fields, inline patterns, phase gates) |
+| 14–15 | ExecPlan + parallel research before starting |
+
+---
+
+## Decomposition Rules
+
+When total ≥ 11, decompose into phases:
+
+1. **One phase = one deployable unit** — each phase leaves the codebase in a working state
+2. **Max 3 scenarios per phase** — more means the phase is too large; split it
+3. **Phase gate before next phase** — build + tests must pass at each boundary
+4. **No implicit dependencies between phases** — phase 2 must not assume phase 1 code style; document patterns inline
+
+## Anti-patterns
+
+- Scoring 1 on all dimensions then creating an ExecPlan → overhead without benefit
+- Scoring 3 on ambiguity without resolving decisions first → plan will fail
+- Skipping phase gates to go faster → regressions compound