@soleri/forge 5.14.0 → 5.14.2

package/dist/skills/skills/verification-before-completion.md

@@ -1,182 +0,0 @@
----
-name: verification-before-completion
-description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
----
-
-<!-- Adapted from superpowers (MIT License) -->
-
-# Verification Before Completion
-
-## Overview
-
-Claiming work is complete without verification is dishonesty, not efficiency.
-
-**Core principle:** Evidence before claims, always.
-
-**Violating the letter of this rule is violating the spirit of this rule.**
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-If you haven't run the verification command in this message, you cannot claim it passes.
-
-## The Gate Function
-
-```
-BEFORE claiming any status or expressing satisfaction:
-
-1. IDENTIFY: What command proves this claim?
-2. RUN: Execute the FULL command (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Does output confirm the claim?
-   - If NO: State actual status with evidence
-   - If YES: State claim WITH evidence
-5. AGENT CHECK: Run system diagnostics
-6. ONLY THEN: Make the claim
-
-Skip any step = lying, not verifying
-```
-
-## Agent System Checks
-
-After passing all verification commands, run system diagnostics:
-
-### Health Check
-
-```
-YOUR_AGENT_core op:admin_health
-```
-
-Catches issues tests might miss — vault corruption, stale caches, configuration drift.
-
-### Full Diagnostic
-
-```
-YOUR_AGENT_core op:admin_diagnostic
-```
-
-Comprehensive system check — module status, database integrity, cache health, configuration validity.
-
-### Vault Analytics
-
-```
-YOUR_AGENT_core op:admin_vault_analytics
-```
-
-Verify knowledge quality metrics — are capture rates healthy? Any degradation?
-
-If any check reports problems, address them before claiming completion.
-
-## Common Failures
-
-| Claim                 | Requires                        | Not Sufficient                 |
-| --------------------- | ------------------------------- | ------------------------------ |
-| Tests pass            | Test command output: 0 failures | Previous run, "should pass"    |
-| Linter clean          | Linter output: 0 errors         | Partial check, extrapolation   |
-| Build succeeds        | Build command: exit 0           | Linter passing, logs look good |
-| Bug fixed             | Test original symptom: passes   | Code changed, assumed fixed    |
-| Regression test works | Red-green cycle verified        | Test passes once               |
-| Agent completed       | VCS diff shows changes          | Agent reports "success"        |
-| Requirements met      | Line-by-line checklist          | Tests passing                  |
-| Agent healthy         | `admin_diagnostic` clean        | "No errors in logs"            |
-
-## Red Flags - STOP
-
-- Using "should", "probably", "seems to"
-- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
-- About to commit/push/PR without verification
-- Trusting agent success reports
-- Relying on partial verification
-- Thinking "just this once"
-- Tired and wanting work over
-- ANY wording implying success without having run verification
-
-## Rationalization Prevention
-
-| Excuse                                  | Reality                |
-| --------------------------------------- | ---------------------- |
-| "Should work now"                       | RUN the verification   |
-| "I'm confident"                         | Confidence ≠ evidence  |
-| "Just this once"                        | No exceptions          |
-| "Linter passed"                         | Linter ≠ compiler      |
-| "Agent said success"                    | Verify independently   |
-| "I'm tired"                             | Exhaustion ≠ excuse    |
-| "Partial check is enough"               | Partial proves nothing |
-| "Different words so rule doesn't apply" | Spirit over letter     |
-
-## Key Patterns
-
-**Tests:**
-
-```
-[Run test command] [See: 34/34 pass] "All tests pass"
-NOT: "Should pass now" / "Looks correct"
-```
-
-**Regression tests (TDD Red-Green):**
-
-```
-Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
-NOT: "I've written a regression test" (without red-green verification)
-```
-
-**Build:**
-
-```
-[Run build] [See: exit 0] "Build passes"
-NOT: "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-
-```
-Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
-NOT: "Tests pass, phase complete"
-```
-
-**Agent delegation:**
-
-```
-Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
-NOT: Trust agent report
-```
-
-## After Verification — Capture Session
-
-Once work is verified complete, capture a session summary so context persists:
-
-```
-YOUR_AGENT_core op:session_capture
-  params: {
-    summary: "<what was accomplished, files modified, key decisions>"
-  }
-```
-
-This ensures the next session has context about what was verified and completed.
-
-## When To Apply
-
-**ALWAYS before:**
-
-- ANY variation of success/completion claims
-- ANY expression of satisfaction
-- ANY positive statement about work state
-- Committing, PR creation, task completion
-- Moving to next task
-- Delegating to agents
-
-## The Bottom Line
-
-Run the command. Read the output. THEN claim the result. This is non-negotiable.
-
-## Agent Tools Reference
-
-| Op                      | When to Use                         |
-| ----------------------- | ----------------------------------- |
-| `admin_health`          | Quick system health check           |
-| `admin_diagnostic`      | Comprehensive system diagnostic     |
-| `admin_vault_analytics` | Knowledge quality metrics           |
-| `session_capture`       | Persist verified completion context |

package/dist/skills/skills/writing-plans.md

@@ -1,215 +0,0 @@
----
-name: writing-plans
-description: Use when you have a spec or requirements for a multi-step task, before touching code
----
-
-<!-- Adapted from superpowers (MIT License) -->
-
-# Writing Plans
-
-## Overview
-
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
-
-Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
-
-**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
-
-**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
-
-## Before Writing — Search First, Plan Second
-
-**Never write a plan from scratch.** Always search for existing knowledge first.
-
-### 1. Vault First
-
-Check the vault for relevant implementation patterns:
-
-```
-YOUR_AGENT_core op:search_intelligent
-  params: { query: "<feature being planned>" }
-```
-
-Look for:
-
-- **Implementation patterns** — proven approaches for similar features
-- **Anti-patterns** — approaches that failed and should be avoided
-- **Testing patterns** — how similar features were tested
-
-Also check brain strengths for what's worked:
-
-```
-YOUR_AGENT_core op:brain_strengths
-```
-
-Browse related knowledge domains for additional context:
-
-```
-YOUR_AGENT_core op:vault_domains
-YOUR_AGENT_core op:vault_tags
-```
-
-### 2. Web Search Second
-
-If the vault doesn't have implementation guidance, search the web:
-
-- **Libraries and tools** — is there a package that does this already?
-- **Reference implementations** — how did other projects solve this?
-- **API documentation** — official docs for libraries you'll use
-- **Known issues** — pitfalls others ran into
-
-### 3. Then Write the Plan
-
-Incorporate vault insights and web findings into the plan. Reference specific vault entries and documentation links when they inform a step. A plan informed by existing knowledge is dramatically better than one written from first principles.
-
-## Create a Tracked Plan
-
-Use the agent's planning system to create a tracked, resumable plan:
-
-```
-YOUR_AGENT_core op:create_plan
-  params: {
-    objective: "<one-sentence goal>",
-    scope: { included: [...], excluded: [...] },
-    steps: [
-      { title: "Step 1 title", description: "details" },
-      ...
-    ]
-  }
-```
-
-This makes the plan persistent across sessions — if context compacts or sessions change, the plan survives.
-
-## Grade the Plan
-
-After drafting, grade the plan for quality before presenting to the user:
-
-```
-YOUR_AGENT_core op:plan_grade
-  params: { planId: "<id from create_plan>" }
-```
-
-If the grade is below target, auto-improve:
-
-```
-YOUR_AGENT_core op:plan_auto_improve
-  params: { planId: "<id>" }
-```
-
-This iterates on the plan — filling gaps, adding missing test steps, clarifying ambiguous instructions. Repeat until the grade meets the target:
-
-```
-YOUR_AGENT_core op:plan_meets_grade
-  params: { planId: "<id>", targetGrade: "A" }
-```
-
-### Iterate on Drafts
-
-For complex plans, iterate before finalizing:
-
-```
-YOUR_AGENT_core op:plan_iterate
-  params: { planId: "<id>", feedback: "<what needs improvement>" }
-```
-
-This creates a new version of the plan incorporating the feedback, preserving version history.
-
-## Split into Tasks
-
-Once the plan is approved, split it into trackable tasks:
-
-```
-YOUR_AGENT_core op:plan_split
-  params: { planId: "<id>" }
-```
-
-This generates individual tasks from the plan steps, ready for execution tracking.
-
-## Bite-Sized Task Granularity
-
-**Each step is one action (2-5 minutes):**
-
-- "Write the failing test" - step
-- "Run it to make sure it fails" - step
-- "Implement the minimal code to make the test pass" - step
-- "Run the tests and make sure they pass" - step
-- "Commit" - step
-
-## Plan Document Header
-
-**Every plan MUST start with this header:**
-
-```markdown
-# [Feature Name] Implementation Plan
-
-> **For Claude:** REQUIRED SUB-SKILL: Use executing-plans to implement this plan task-by-task.
-
-**Goal:** [One sentence describing what this builds]
-
-**Architecture:** [2-3 sentences about approach]
-
-**Tech Stack:** [Key technologies/libraries]
-
----
-```
-
-## Task Structure
-
-Each task uses this format:
-
-- Files: Create / Modify / Test paths
-- Step 1: Write the failing test (with code)
-- Step 2: Run test to verify it fails (with expected output)
-- Step 3: Write minimal implementation (with code)
-- Step 4: Run test to verify it passes (with expected output)
-- Step 5: Commit (with exact git commands)
-
-## Remember
-
-- Exact file paths always
-- Complete code in plan (not "add validation")
-- Exact commands with expected output
-- DRY, YAGNI, TDD, frequent commits
-
-## After Plan Approval
-
-Once the user approves the plan, register it for tracking:
-
-```
-YOUR_AGENT_core op:approve_plan
-  params: { planId: "<id from create_plan>" }
-```
-
-Check plan stats for an overview:
-
-```
-YOUR_AGENT_core op:plan_stats
-```
-
-## Execution Handoff
-
-After saving the plan, offer execution choice:
-
-"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:
-
-**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration
-
-**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints
-
-Which approach?"
-
-## Agent Tools Reference
-
-| Op                             | When to Use                            |
-| ------------------------------ | -------------------------------------- |
-| `search_intelligent`           | Find relevant patterns before planning |
-| `brain_strengths`              | Check proven approaches                |
-| `vault_domains` / `vault_tags` | Browse knowledge landscape             |
-| `create_plan`                  | Create tracked, persistent plan        |
-| `plan_grade`                   | Grade plan quality                     |
-| `plan_auto_improve`            | Auto-fix plan weaknesses               |
-| `plan_meets_grade`             | Verify grade target reached            |
-| `plan_iterate`                 | Iterate on draft with feedback         |
-| `plan_split`                   | Split plan into trackable tasks        |
-| `approve_plan`                 | Lock in approved plan                  |
-| `plan_stats`                   | Overview of plan metrics               |

package/dist/templates/brain.d.ts

@@ -1,6 +0,0 @@
-/**
- * Generates the brain.ts source file for a new agent.
- * The Brain provides a local, zero-dependency intelligence layer:
- * TF-IDF scoring, auto-tagging, duplicate detection, and search feedback.
- */
-export declare function generateBrain(): string;