maxsimcli 5.0.6 → 5.1.0

package/dist/assets/templates/skills/sdd/SKILL.md

@@ -1,91 +0,0 @@
----
-name: sdd
-description: >-
-  Spec-driven development with fresh-agent-per-task execution. Prevents context
-  rot by isolating each task in a clean context window with its spec. Use when
-  executing multi-task plans, orchestrating agent work, or when context
-  accumulation degrades quality.
----
-
-# Spec-Driven Development (SDD)
-
-Execute tasks sequentially, each in a fresh agent with clean context. Verify every task before moving to the next.
-
-## Why SDD
-
-Context rot is the primary failure mode for multi-task execution. As an agent processes more tasks, earlier context competes with later instructions. Quality degrades predictably after 3-5 tasks in a single context window. SDD solves this by giving each task a fresh context with only its specification.
-
-## The SDD Process
-
-### 1. LOAD -- Read the Plan
-
-- Read the plan file (PLAN.md) to get the ordered task list
-- For each task: description, acceptance criteria, relevant files
-- Confirm task order respects dependencies
-
-### 2. DISPATCH -- Spawn Fresh Agent Per Task
-
-For each task in order:
-
-1. Assemble minimal task context:
-   - Task description and acceptance criteria from the plan
-   - Only the files relevant to this specific task
-   - Results from previous tasks (commit hashes, created files) -- NOT the full previous context
-2. Spawn a fresh agent with this minimal context
-3. The agent implements the task, runs verification, and commits
-
-### 3. REVIEW -- Two-Stage Quality Gate
-
-After each task completes:
-
-**Stage 1: Spec Compliance** -- Does the implementation match the task spec? Are all acceptance criteria met? Were only specified files modified?
-
-**Stage 2: Code Quality** -- Are there bugs, edge cases, or error handling gaps? Is the code consistent with codebase conventions? Do all tests pass?
-
-Verdict: PASS or FAIL with specific issues per stage.
-
-### 4. FIX -- Address Review Failures
-
-If either review stage fails:
-
-1. Spawn a NEW fresh agent with original task spec + review feedback + current file state
-2. Fix agent addresses ONLY the review issues -- no new features
-3. Re-run both review stages
-4. If 3 fix attempts fail: STOP and escalate
-
-### 5. ADVANCE -- Move to Next Task
-
-Only after both review stages pass:
-
-- Record task as complete with commit hash
-- Pass minimal summary (not full context) to the next task
-
-## Context Management
-
-Each agent receives ONLY what it needs:
-
-| Context Item | Included? |
-|---|---|
-| Task description + acceptance criteria | Always |
-| Files relevant to this task | Always |
-| Previous task commit hashes | Always |
-| Previous task full diff | Never |
-| Previous task agent conversation | Never |
-| Full codebase | Never -- only specified files |
-
-The point of SDD is fresh context. Loading the previous agent's full context defeats the purpose.
-
-## When to Use SDD
-
-- **Good fit:** Multi-task plans (3+ tasks), sequential work where each task builds on the previous, implementations where quality degrades over time
-- **Poor fit:** Single-task work, highly interactive tasks requiring user feedback, tasks that share significant overlapping context
-
-## Common Pitfalls
-
-| Pitfall | Why It Matters |
-|---|---|
-| Skipping review for simple tasks | Simple tasks still have bugs. Review catches what the implementer missed. |
-| Passing full context forward | Full context causes the exact rot SDD is designed to prevent. |
-| Deferring fixes to the next task | The next task's agent does not know about the bug. Fix it now. |
-
-See also: `/verification-before-completion` for the evidence-based verification methodology used within each SDD task.

package/dist/assets/templates/skills/tool-priority-guide/SKILL.md

@@ -1,80 +0,0 @@
----
-name: tool-priority-guide
-description: >-
-  Tool selection guide for Claude Code operations. Maps common tasks to preferred
-  tools, explaining when to use Read over cat, Grep over rg, Glob over find,
-  Write over echo, and Edit over sed. Use when deciding which tool to use for
-  file operations, search, content modification, or web content retrieval.
-user-invocable: false
----
-
-# Tool Priority Guide
-
-Use dedicated Claude Code tools over Bash equivalents. Dedicated tools provide better permissions handling, output formatting, and user experience.
-
-## File Reading
-
-| Task | Use | Not |
-|------|-----|-----|
-| Read file contents | **Read tool** | `cat`, `head`, `tail` via Bash |
-| Read specific lines | **Read tool** (with offset/limit) | `sed -n 'X,Yp'` via Bash |
-| Read images | **Read tool** (multimodal) | Not possible via Bash |
-| Read PDFs | **Read tool** (with pages param) | `pdftotext` via Bash |
-
-**Why Read:** Handles permissions, large files, binary formats. Returns line-numbered output.
-
-## File Writing
-
-| Task | Use | Not |
-|------|-----|-----|
-| Create new file | **Write tool** | `echo > file`, `cat <<EOF` via Bash |
-| Rewrite entire file | **Write tool** (after Read) | `cat > file` via Bash |
-| Modify part of file | **Edit tool** | `sed`, `awk` via Bash |
-| Rename string across file | **Edit tool** (replace_all) | `sed -i 's/old/new/g'` via Bash |
-
-**Why Write/Edit:** Atomic operations, preserves encoding, provides diff view for review.
-
-## Searching
-
-| Task | Use | Not |
-|------|-----|-----|
-| Search file contents | **Grep tool** | `grep`, `rg` via Bash |
-| Find files by pattern | **Glob tool** | `find`, `ls -R` via Bash |
-| Search with context | **Grep tool** (-A, -B, -C params) | `grep -C N` via Bash |
-| Count matches | **Grep tool** (output_mode: count) | `grep -c` via Bash |
-
-**Why Grep/Glob:** Optimized permissions, structured output, result limiting.
-
-## Web Content
-
-| Task | Use | Not |
-|------|-----|-----|
-| Fetch documentation | **WebFetch tool** | `curl` via Bash |
-| Read API responses | **WebFetch tool** | `curl | jq` via Bash |
-| Download files | **Bash** (`curl -O`) | WebFetch (not for binary downloads) |
-
-**Why WebFetch:** Handles authentication, follows redirects, parses HTML.
-
-## When Bash IS the Right Tool
-
-| Task | Why Bash |
-|------|---------|
-| Run build/test commands | `npm test`, `npm run build` -- no dedicated tool |
-| Git operations | `git status`, `git commit` -- no dedicated tool |
-| Install dependencies | `npm install` -- no dedicated tool |
-| Check file existence | `test -f path` -- lightweight, often part of larger commands |
-| Run project CLI tools | Project-specific commands -- no dedicated tool |
-| Chained operations | Multiple sequential commands with `&&` |
-
-## Quick Reference
-
-```
-Read file    --> Read tool
-Write file   --> Write tool (new) or Edit tool (modify)
-Search code  --> Grep tool
-Find files   --> Glob tool
-Fetch URL    --> WebFetch tool
-Run commands --> Bash tool
-```
-
-The general principle: if a dedicated tool exists for the operation, use it. Fall back to Bash only when no dedicated tool covers the task.

package/dist/assets/templates/skills/verification-before-completion/SKILL.md

@@ -1,71 +0,0 @@
----
-name: verification-before-completion
-description: >-
-  Requires running verification commands and reading actual output before
-  completion claims. Covers the 5-step verification process and evidence block
-  format. Use when claiming work is done, tests pass, builds succeed, or bugs
-  are fixed.
----
-
-# Verification Before Completion
-
-Evidence before claims, always. No exceptions.
-
-## The 5-Step Process
-
-Before claiming any status or marking a task done:
-
-1. **IDENTIFY** -- What command proves this claim?
-2. **RUN** -- Execute the command fresh in this turn (not a previous run)
-3. **READ** -- Read the full output, check the exit code, count failures
-4. **VERIFY** -- Does the output actually confirm the claim? If NO: state the actual status with evidence. If YES: proceed.
-5. **CLAIM** -- Only now may you assert completion
-
-### Evidence Block Format
-
-When claiming task completion, build completion, or test passage, produce:
-
-```
-CLAIM: [what you are claiming]
-EVIDENCE: [exact command run in this turn]
-OUTPUT: [relevant excerpt of actual output]
-VERDICT: PASS | FAIL
-```
-
-This format is required for task completion claims in MAXSIM plan execution.
-
-## What Counts as Verification
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| "Tests pass" | Test command output showing 0 failures | Previous run, "should pass", partial run |
-| "Build succeeds" | Build command with exit code 0 | Linter passing, "logs look clean" |
-| "Bug is fixed" | Original failing test now passes | "Code changed, assumed fixed" |
-| "Task is complete" | All done criteria checked with evidence | "I implemented everything in the plan" |
-| "No regressions" | Full test suite passing | "I only changed one file" |
-
-## Common Pitfalls
-
-| Excuse | Why It Fails |
-|--------|-------------|
-| "Should work now" | "Should" is not evidence. Run the command. |
-| "I'm confident in the logic" | Confidence is not evidence. Run it. |
-| "The linter passed" | Linter passing does not mean tests pass or build succeeds. |
-| "I only changed one line" | One line can break everything. Verify. |
-| "The subagent reported success" | Trust test output and VCS diffs, not agent reports. |
-
-Stop if you catch yourself using "should", "probably", or "looks good" about unverified work, or expressing satisfaction before running verification.
-
-## Verification Checklist
-
-Before marking any work as complete:
-
-- [ ] Identified the verification command for every claim
-- [ ] Ran each verification command fresh in this turn
-- [ ] Read the full output (not just the summary line)
-- [ ] Checked exit codes (0 = success, non-zero = failure)
-- [ ] Evidence supports every completion claim
-- [ ] No "should", "probably", or "seems to" in your completion statement
-- [ ] Evidence block produced for the task completion claim
-
-See also: `/verification-gates` for the full gate framework with retry logic and escalation protocol.

package/dist/assets/templates/skills/verification-gates/SKILL.md

@@ -1,169 +0,0 @@
----
-name: verification-gates
-description: >-
-  Hard gate framework for evidence-based verification. Defines four gate types
-  (input validation, pre-action, completion, quality), retry logic with feedback,
-  anti-rationalization enforcement, and escalation protocol. Use when implementing
-  verification checkpoints, completion gates, or quality checks.
-user-invocable: false
----
-
-# Verification Gates
-
-Evidence before claims, always. No exceptions.
-
-## Gate Types
-
-### 1. Input Validation Gate
-
-**When:** Before starting any work.
-**Purpose:** Verify all required inputs exist (files, env vars, CLI args, state).
-
-**Evidence required:**
-- File existence checks (`test -f path`)
-- Environment variable checks
-- State file readability
-
-**On failure:** Return structured error immediately. Do NOT attempt partial work.
-
-```
-AGENT RESULT: INPUT VALIDATION FAILED
-Missing: [list of missing inputs]
-Expected from: [source -- orchestrator, user, prior agent]
-```
-
-### 2. Pre-Action Gate
-
-**When:** Before destructive actions (file writes, git commits, PRs, deployments).
-**Purpose:** Verify intent and impact before irreversible changes.
-
-**Evidence required:**
-- State what will be changed
-- Confirm target files/branches are correct
-- Verify no unintended side effects (e.g., `git status` before commit)
-
-**On failure:** Abort the action. Report what was wrong and what would have happened.
-
-### 3. Completion Gate
-
-**When:** Before claiming any task, plan, or phase is done.
-**Purpose:** Verify all done criteria are met with fresh tool output.
-
-**HARD GATE -- No completion claims without fresh verification evidence.**
-
-Do NOT pass this gate by arguing it's "close enough", "minor issue", or "will fix later".
-Either evidence passes or it fails. No middle ground.
-Partial success is failure. "Good enough" is not enough.
-
-If you have not run the verification command in THIS turn, you cannot claim it passes.
-
-**Evidence required:**
-- Run every verification command from the task's verify block
-- Check every item in the done criteria list
-- Produce an evidence block for each claim
-
-### 4. Quality Gate
-
-**When:** After implementation, before marking work as shippable.
-**Purpose:** Verify code quality standards are met.
-
-**Evidence required:**
-- Test suite output (all passing, zero failures)
-- Build output (exit code 0)
-- Lint output (zero errors -- warnings acceptable if project allows)
-
-**On failure:** Fix quality issues before proceeding. Do not defer quality failures.
-
-## Anti-Rationalization
-
-FORBIDDEN PHRASES -- if you catch yourself using these, STOP. You are rationalizing:
-
-- "should work"
-- "probably passes"
-- "I'm confident that..."
-- "based on my analysis..."
-- "the logic suggests..."
-- "it's reasonable to assume..."
-
-These phrases replace evidence with reasoning. The gate requires tool output, not arguments.
-
-Additional forbidden rationalizations:
-- "It's close enough" -- close is not done
-- "Minor issue, will fix later" -- later is never
-- "The logic is correct so it must pass" -- run it and find out
-- "I already verified this in a previous step" -- previous steps are stale; verify now
-
-## Evidence Standard
-
-Any tool output qualifies as evidence: test output, build results, git diff, file reads, linter output, command exit codes.
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| "Tests pass" | Test command output showing 0 failures | Previous run, "should pass" |
-| "Build succeeds" | Build command with exit code 0 | Linter passing only |
-| "Bug is fixed" | Original failing test now passes | "Code changed, assumed fixed" |
-| "Task complete" | All done criteria checked with evidence | "I implemented everything" |
-| "No regressions" | Full test suite passing | "I only changed one file" |
-| "File created" | `test -f path` or Read tool output | "I wrote it with Write tool" |
-
-## Evidence Block Format
-
-```
-CLAIM: [what you are claiming]
-EVIDENCE: [exact command run in THIS turn]
-OUTPUT: [relevant excerpt of actual output]
-VERDICT: PASS | FAIL
-```
-
-Produce one evidence block per claim. Group related claims if verified by the same command.
-
-## Retry Protocol
-
-Maximum 2 retries (3 total attempts) per gate.
-
-**Retry feedback loop:**
-1. Gate fails -- capture: what failed, expected result, actual result
-2. Analyze the failure output (do not guess; read the error)
-3. Fix the identified issue
-4. Re-run the verification command
-5. Produce a new evidence block
-
-Each retry MUST include in its evidence block:
-- Attempt number (1/3, 2/3, 3/3)
-- What changed since last attempt
-- Fresh verification output
-
-**After 3rd failure -- escalation:**
-
-Return full failure context to orchestrator:
-
-```markdown
-## GATE FAILURE -- ESCALATION
-
-**Gate:** [gate type]
-**Attempts:** 3/3
-**Final evidence:**
-CLAIM: [claim]
-EVIDENCE: [command]
-OUTPUT: [output]
-VERDICT: FAIL
-
-**History:**
-- Attempt 1: [what failed, what was tried]
-- Attempt 2: [what failed, what was tried]
-- Attempt 3: [what failed -- escalating]
-
-**Recommended action:** [what the orchestrator or user should do]
-```
-
-## Audit Trail
-
-Log every gate attempt to GitHub Issues as a comment on the active phase issue:
-
-- Gate name and type
-- Attempt number
-- Evidence provided (abbreviated)
-- PASS or FAIL result
-- Timestamp
-
-This creates an auditable record of all verification activity for debugging and improvement.