mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/threat-modeling/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: threat-modeling
+version: 1.0.0
+min_mindforge_version: 10.0.3
+status: stable
+triggers: threat model, STRIDE, attack tree, DREAD, threat surface, trust boundary, attack vector, data flow diagram, DFD, adversary, threat assessment
+compose:
+  - security-review
+---
+
+# Skill — Threat Modeling
+
+## When this skill activates
+When analyzing security threats to a system, component, or feature. When
+constructing attack trees, identifying trust boundaries, or scoring risks
+using structured methodologies.
+
+## Mandatory actions when this skill is active
+
+### Before threat modeling
+1. Switch to `threat-modeler` persona.
+2. Identify the **scope** — what system/component are we modeling?
+3. Gather the system's **data flow** — how does data move through it?
+4. Identify all **trust boundaries** — where does trust level change?
+
+### STRIDE Methodology
+
+Apply STRIDE to each trust boundary crossing:
+
+| Threat | Question | Example |
+|--------|----------|---------|
+| **S**poofing | Can an attacker pretend to be someone else? | Forged auth tokens, session hijacking |
+| **T**ampering | Can data be modified in transit or at rest? | Man-in-the-middle, DB manipulation |
+| **R**epudiation | Can actions be denied without proof? | Missing audit logs, unsigned transactions |
+| **I**nformation Disclosure | Can sensitive data leak? | Error messages with stack traces, verbose APIs |
+| **D**enial of Service | Can the system be overwhelmed? | Unbounded queries, missing rate limits |
+| **E**levation of Privilege | Can a user gain unauthorized access? | Missing authz checks, IDOR, path traversal |
+
+### DREAD Scoring
+
+Score each identified threat (1-10 for each dimension):
+
+| Dimension | 1 (Low) | 5 (Medium) | 10 (High) |
+|-----------|---------|------------|-----------|
+| **D**amage | Minor inconvenience | Data loss for some users | Full system compromise |
+| **R**eproducibility | Requires rare conditions | Requires specific setup | Anyone can reproduce |
+| **E**xploitability | Requires deep expertise | Requires some skill | Script kiddie level |
+| **A**ffected Users | Single user | Subset of users | All users |
+| **D**iscoverability | Hidden, requires source | Findable with effort | Obvious, publicly known |
+
+**Risk Score** = (D + R + E + A + D) / 5
+- Score 1-3: Low risk (monitor)
+- Score 4-6: Medium risk (mitigate within sprint)
+- Score 7-10: High/Critical risk (mitigate IMMEDIATELY)
+
+### Attack Tree Construction
+
+For high-scoring threats, build an attack tree:
+```
+[Goal: Unauthorized admin access]
+├── [OR] Steal admin credentials
+│   ├── [AND] Phish admin user
+│   │   ├── Send convincing email
+│   │   └── Capture credentials on fake page
+│   └── [AND] Exploit password reset
+│       ├── Enumerate valid emails
+│       └── Intercept reset token
+└── [OR] Escalate from regular user
+    ├── [AND] Exploit IDOR
+    │   ├── Find predictable resource IDs
+    │   └── Access admin endpoints directly
+    └── [AND] Exploit role assignment bug
+```
+
+### Output Format
+
+Write to `.planning/THREAT-MODEL-[component]-[timestamp].md`:
+```markdown
+# Threat Model: [Component]
+Date: [timestamp]
+Scope: [what was analyzed]
+
+## Data Flow Diagram
+[ASCII or description of data flow with trust boundaries marked]
+
+## Trust Boundaries
+1. [boundary]: [what crosses it]
+
+## Identified Threats
+| # | Category | Threat | DREAD Score | Mitigation | Status |
+|---|----------|--------|-------------|-----------|--------|
+
+## Attack Trees (for High/Critical threats)
+[Trees for any threat scoring 7+]
+
+## Recommendations
+[Prioritized list of mitigations]
+```
+
+### After threat modeling
+- Review all High/Critical findings with security-reviewer persona
+- Create action items for each unmitigated threat
+- Log threat model in AUDIT with finding counts by severity
+
+## Self-check before task completion
+- [ ] Did I apply STRIDE to ALL trust boundary crossings (not just obvious ones)?
+- [ ] Did I score every identified threat with DREAD?
+- [ ] Did I build attack trees for all threats scoring 7+?
+- [ ] Did I write the threat model to .planning/THREAT-MODEL-[component].md?

package/.mindforge/skills/tool-design/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: tool-design
+version: 1.0.0
+min_mindforge_version: 10.0.7
+status: stable
+triggers: tool design, ai tool interface, tool input schema, tool output contract, idempotent tool design, tool batching strategy, tool composition pattern, tool discovery mechanism, tool error semantics, function calling design, zod schema design, json schema tool
+---
+
+# Tool Design
+
+## When this skill activates
+
+This skill activates when designing tools (functions, APIs, MCP servers) that AI agents will invoke. It covers input schema design, output contracts, idempotency, error handling, batching, composition, and discoverability. Use this skill whenever building interfaces between AI models and executable capabilities.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Identify the consumer** — Determine which AI model(s) will use this tool. Different models have different tool-calling behaviors and schema support.
+2. **Define the capability boundary** — One tool should do one thing well. If describing the tool requires "and" twice, split it into multiple tools.
+3. **Survey existing tools** — Check if an existing tool already covers this capability. Duplicate tools confuse AI selection.
+4. **Assess side effects** — Classify the tool as read-only (safe to retry) or write (requires idempotency). This drives the entire error handling strategy.
+
+### During
+
+#### Tool Anatomy
+
+Every tool must define these components:
+
+```typescript
+{
+  name: string,          // verb_noun format: "search_files", "create_user"
+  description: string,   // 1-2 sentences: what it does, when to use it, when NOT to use it
+  inputSchema: Schema,   // Typed, validated, documented
+  outputSchema: Schema,  // Typed, consistent across success/error
+  sideEffects: boolean,  // Does it change state?
+  idempotent: boolean    // Safe to call twice with same input?
+}
+```
+
+- **Name** — Use `verb_noun` format. Be specific: `search_codebase` not `search`. The model uses the name for selection.
+- **Description** — This is the most important field for AI tool selection. Include: what it does, when to use it, when NOT to use it, and what it returns.
+- **Negative guidance** — Tell the model when NOT to use the tool: "Do not use this for file reads; use read_file instead." Prevents misuse.
+
+#### Schema Design
+
+**TypeScript (Zod):**
+```typescript
+const inputSchema = z.object({
+  query: z.string().min(1).describe("Search query, supports regex"),
+  maxResults: z.number().int().min(1).max(100).default(10).describe("Max results to return"),
+  filePattern: z.string().optional().describe("Glob pattern to filter files, e.g. '*.ts'")
+});
+```
+
+**Schema principles:**
+- Every field has a `description`. The AI reads descriptions to understand how to populate fields.
+- Use constrained types: `min`, `max`, `enum`, `pattern`. Tighter schemas = fewer invalid calls.
+- Required fields first, optional fields with sensible defaults after.
+- Prefer flat schemas over deeply nested objects. AI models handle flat structures more reliably.
+- Use `enum` for fixed option sets. Never rely on the AI guessing valid values from a description alone.
+
+#### Output Contract
+
+```typescript
+// Success
+{ success: true, data: T, metadata: { duration_ms: number, cached: boolean } }
+
+// Error
+{ success: false, error: { code: string, message: string, retryable: boolean, context: object } }
+```
+
+- **Consistent shape** — Success and error responses must share a common discriminator field (`success`). The AI parses both paths.
+- **Typed error codes** — Use machine-readable codes: `FILE_NOT_FOUND`, `PERMISSION_DENIED`, `RATE_LIMITED`. Not just human messages.
+- **Retryable flag** — Tell the AI whether retrying might work. This drives agent retry logic.
+- **Context in errors** — Include what was attempted and why it failed: `{ attempted: "read /foo/bar.ts", reason: "file does not exist" }`.
+
+#### Idempotency
+
+- **Read operations** — Inherently idempotent. Safe to retry without side effects.
+- **Write operations** — Require explicit idempotency design. Two approaches:
+  - **Idempotency key** — Client provides a unique key. Server deduplicates. Same key = same result.
+  - **Natural idempotency** — "set X to Y" is idempotent; "increment X" is not.
+- **Implementation** — Store idempotency keys with TTL (24hr). Return cached result for duplicates. Critical because AI agents retry on network errors — non-idempotent tools create duplicates.
+
+#### Error Semantics
+
+| Error Category | Retryable | Agent Action |
+|---------------|-----------|--------------|
+| Validation error (bad input) | No | Fix input, call again |
+| Not found | No | Report to user or try alternative |
+| Permission denied | No | Escalate, request auth |
+| Rate limited | Yes | Wait and retry with backoff |
+| Timeout | Yes | Retry with longer timeout |
+| Internal error | Maybe | Retry once, then escalate |
+| Conflict (optimistic lock) | Yes | Re-read state, retry |
+
+- **Never return bare strings for errors.** Always return typed error objects.
+- **Include remediation hints** — If the error is fixable, tell the AI how: `"hint": "File path must be absolute. Received relative path."`.
+
+#### Batching Strategy
+
+- **When to batch** — Multiple independent calls that could be combined (e.g., reading 5 files in one call).
+- **Batch input** — Accept arrays: `{ files: ["a.ts", "b.ts", "c.ts"] }` instead of 3 separate calls.
+- **Partial success** — Report per-item results. Never all-or-nothing for batches.
+- **Size limits** — Max 20 items per batch. Unbounded batches cause timeouts.
+- **When NOT to batch** — Items with dependencies on each other's results require sequential calls.
+
+#### Composition (Tools Calling Tools)
+
+- **Max 2-depth** — Tool A can call Tool B, but B should not call C. Deep composition is impossible to debug.
+- **Composition contracts** — Inner tools must have strict schemas. Outer tool validates intermediate results.
+- **Transparency** — Document when tools call other tools internally.
+- **Failure isolation** — Inner tool failures must be handled gracefully, not propagated raw.
+
+#### Discovery Mechanism
+
+- **Tool registry** — Catalog all tools with name, description, capability tags. Group by domain (file, search, git).
+- **Descriptions for AI** — Optimize for AI selection ("when to use"), not human documentation.
+- **Dynamic registration** — Tools added/removed at runtime must update the AI's available tool list.
+
+### After
+
+1. **Test with AI** — Verify the model selects correctly, provides valid inputs, and handles outputs properly.
+2. **Test edge cases** — Invalid, empty, and max-size inputs. Verify error responses are informative.
+3. **Measure latency** — Target <5 seconds for interactive use. Document selection criteria vs alternatives.
+
+## Self-check before task completion
+
+- [ ] Tool name follows verb_noun convention and is distinct from existing tools
+- [ ] Description includes what, when to use, and when NOT to use
+- [ ] Input schema has descriptions on every field with appropriate constraints
+- [ ] Output contract is consistent (success/error discriminator, typed error codes)
+- [ ] Write operations are idempotent (idempotency key or natural idempotency)
+- [ ] Errors include retryable flag and remediation hints
+- [ ] Batch operations support partial success/failure reporting
+- [ ] Composition depth does not exceed 2 levels
+- [ ] Tool tested with an AI model for correct selection and invocation

package/.mindforge/skills/typescript-advanced/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: typescript-advanced
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: typescript advanced, generics pattern, conditional type, discriminated union, mapped type, template literal type, type inference pattern, utility type, type guard, type narrowing, branded type, variance annotation
+---
+
+# Skill — TypeScript Advanced Type Patterns
+
+## When this skill activates
+Any task involving advanced TypeScript type system features: generics design,
+conditional types, discriminated unions, mapped types, template literal types,
+branded types, variance annotations, or complex type inference patterns.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify the type-level problem being solved. Ask: "What invalid states should
+   the type system make impossible?"
+2. Check the project's `tsconfig.json` for `strict: true`. If not enabled, flag it
+   as a prerequisite for advanced type patterns to work correctly.
+3. Determine if the pattern needs to be exported for consumers (public API types
+   require more careful design than internal utility types).
+
+### During implementation
+
+#### Generics
+- Always add constraints to generic parameters: `<T extends BaseType>` not bare `<T>`.
+- Provide defaults when there is a sensible one: `<T extends Record<string, unknown> = Record<string, unknown>>`.
+- Place inference sites at the position where TypeScript can infer the type from usage:
+  ```typescript
+  // Good: T is inferred from the argument
+  function wrap<T>(value: T): Wrapper<T>
+  // Bad: T cannot be inferred, caller must specify
+  function wrap<T>(): Wrapper<T>
+  ```
+- Avoid "generic soup" (3+ type parameters). If needed, use a config object type:
+  ```typescript
+  type Config<TInput, TOutput, TError> = { ... }
+  function process<C extends Config<any, any, any>>(config: C): ...
+  ```
+
+#### Conditional Types
+- Use `infer` keyword to extract types from structures:
+  ```typescript
+  type UnwrapPromise<T> = T extends Promise<infer U> ? U : T;
+  type ReturnOf<T> = T extends (...args: any[]) => infer R ? R : never;
+  ```
+- Understand distributive behavior: `T extends U ? X : Y` distributes over unions
+  when T is a naked type parameter. Wrap in `[T] extends [U]` to prevent distribution.
+- Nest conditional types sparingly (max 3 levels). Extract intermediate types for clarity:
+  ```typescript
+  // Instead of deeply nested conditionals
+  type Step1<T> = T extends Array<infer U> ? U : T;
+  type Step2<T> = Step1<T> extends object ? keyof Step1<T> : never;
+  ```
+
+#### Discriminated Unions
+- Every variant MUST have a literal-typed discriminant field (typically `type` or `kind`):
+  ```typescript
+  type Shape =
+    | { kind: "circle"; radius: number }
+    | { kind: "rectangle"; width: number; height: number }
+    | { kind: "triangle"; base: number; height: number };
+  ```
+- Implement exhaustive handling with `never` checks:
+  ```typescript
+  function assertNever(x: never): never {
+    throw new Error(`Unexpected: ${JSON.stringify(x)}`);
+  }
+  function area(shape: Shape): number {
+    switch (shape.kind) {
+      case "circle": return Math.PI * shape.radius ** 2;
+      case "rectangle": return shape.width * shape.height;
+      case "triangle": return 0.5 * shape.base * shape.height;
+      default: return assertNever(shape);
+    }
+  }
+  ```
+- Adding a new variant to the union automatically causes compile errors at every
+  switch/if that is missing the new case. This is the primary value.
+
+#### Mapped Types
+- Use key remapping (`as`) for transforming keys:
+  ```typescript
+  type Getters<T> = {
+    [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
+  };
+  ```
+- Use modifiers (`readonly`, `?`, `-readonly`, `-?`) deliberately:
+  ```typescript
+  type Mutable<T> = { -readonly [K in keyof T]: T[K] };
+  type Required<T> = { [K in keyof T]-?: T[K] };
+  ```
+- Filter keys using `as` with `never`:
+  ```typescript
+  type OnlyStrings<T> = {
+    [K in keyof T as T[K] extends string ? K : never]: T[K];
+  };
+  ```
+
+#### Template Literal Types
+- Use for string manipulation at the type level:
+  ```typescript
+  type EventName<T extends string> = `on${Capitalize<T>}`;
+  type Route = `/${string}` | `/${string}/${string}`;
+  ```
+- Combine with mapped types for powerful API typing:
+  ```typescript
+  type CSSProperties = {
+    [K in keyof CSSStyleDeclaration as K extends string
+      ? `--${K}` | K
+      : never]: string;
+  };
+  ```
+- Use intrinsic string types: `Uppercase`, `Lowercase`, `Capitalize`, `Uncapitalize`.
+
+#### Branded / Opaque Types
+- Use for domain safety (preventing accidental misuse of primitive types):
+  ```typescript
+  declare const brand: unique symbol;
+  type Brand<T, B> = T & { readonly [brand]: B };
+
+  type UserId = Brand<string, "UserId">;
+  type OrderId = Brand<string, "OrderId">;
+
+  // Now these are incompatible even though both are strings
+  function getUser(id: UserId): User { ... }
+  const orderId = "abc" as OrderId;
+  getUser(orderId); // Compile error!
+  ```
+- Provide constructor functions that validate at runtime:
+  ```typescript
+  function createUserId(raw: string): UserId {
+    if (!raw.startsWith("usr_")) throw new Error("Invalid UserId format");
+    return raw as UserId;
+  }
+  ```
+
+#### Variance Annotations
+- Use `in` (contravariant) and `out` (covariant) on generic type parameters
+  for explicit variance when the compiler cannot infer it:
+  ```typescript
+  type Consumer<in T> = (value: T) => void;
+  type Producer<out T> = () => T;
+  type Transformer<in I, out O> = (input: I) => O;
+  ```
+- Benefits: faster type checking, earlier error detection, documents intent.
+- Only needed on interface/type alias declarations, not on function signatures.
+
+#### The `satisfies` Operator
+- Use `satisfies` to validate a value matches a type without widening:
+  ```typescript
+  const palette = {
+    red: [255, 0, 0],
+    green: "#00ff00",
+  } satisfies Record<string, string | number[]>;
+  // palette.red is still number[] (not string | number[])
+  ```
+- Prefer `satisfies` over `as const` + type annotation when you need both
+  type checking AND narrow inference.
+
+#### Type Guards and Narrowing
+- Prefer `is` return type for custom type guards:
+  ```typescript
+  function isCircle(shape: Shape): shape is { kind: "circle"; radius: number } {
+    return shape.kind === "circle";
+  }
+  ```
+- Use `asserts` for assertion functions that throw:
+  ```typescript
+  function assertDefined<T>(val: T | undefined): asserts val is T {
+    if (val === undefined) throw new Error("Expected defined value");
+  }
+  ```
+- Prefer `in` operator narrowing for object type checks over `typeof` for complex objects.
+
+### After implementation
+1. Verify `npx tsc --noEmit` passes with zero errors.
+2. Hover over inferred types in the IDE to confirm they resolve to expected shapes.
+3. Write at least one "negative test" — a `// @ts-expect-error` comment proving the
+   type correctly rejects invalid usage.
+4. Check that type computation does not cause noticeable IDE lag (overly recursive
+   types can crash the language server).
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] All generic type parameters have constraints (no bare `<T>` without `extends`).
+- [ ] Discriminated unions have exhaustive switch/if with `never` fallback.
+- [ ] No `any` types introduced (use `unknown` and narrow).
+- [ ] Branded types have runtime validation constructors.
+- [ ] Conditional types are no more than 3 levels deep.
+- [ ] `@ts-expect-error` negative tests prove the types reject invalid input.
+- [ ] `tsc --noEmit` passes cleanly.
+- [ ] IDE responsiveness is acceptable (no type computation lag).

package/.mindforge/skills/using-git-worktrees/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: using-git-worktrees
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: git worktree, worktree create, parallel workspace, isolated branch, worktree management, worktree cleanup, worktree per feature, multiple checkouts, worktree workflow, parallel git, worktree list, concurrent branches
+---
+
+# Skill — Using Git Worktrees
+
+## When this skill activates
+
+When working with multiple branches simultaneously, needing isolated working
+directories for parallel development, or managing worktree lifecycle operations.
+Worktrees allow multiple working trees attached to the same repository, sharing a
+single `.git` directory. This eliminates stashing, context-switching overhead, and
+the risk of uncommitted changes bleeding across tasks.
+
+Use this skill when you need to:
+- Work on a feature while reviewing another branch
+- Test different branches simultaneously without cloning
+- Maintain a clean main checkout while developing in parallel
+- Set up dmux-style parallel pane workflows with filesystem isolation
+
+## Mandatory actions when this skill is active
+
+### Before creating worktrees
+
+1. **Understand the model:**
+   - A worktree is a separate working directory linked to the same `.git` store
+   - All worktrees share the same refs, remotes, and object database
+   - Changes committed in any worktree are immediately visible to all others
+   - The "main" worktree is the original clone; "linked" worktrees are additions
+
+2. **Pre-flight checks:**
+   - Verify the target branch does not already have a worktree checked out
+     (git does NOT allow the same branch in two worktrees simultaneously)
+   - Ensure the parent directory for new worktrees exists
+   - Confirm submodule state if the repo uses submodules (they require manual init)
+   - Check available disk space — each worktree is a full working copy
+
+3. **Naming convention (mandatory):**
+   - Store worktrees in a sibling `.worktrees/` directory:
+     ```
+     project/              # main worktree
+     project/.worktrees/
+       feat-auth/          # linked worktree for auth feature
+       fix-payments/       # linked worktree for payments bug
+       review-pr-42/       # linked worktree for PR review
+     ```
+   - Name pattern: `[type]-[short-description]` matching branch suffix
+   - Never nest worktrees inside the main worktree directory
+
+### During worktree usage
+
+**Core commands:**
+
+| Operation | Command |
+|-----------|---------|
+| Create from existing branch | `git worktree add ../.worktrees/[name] [branch]` |
+| Create with new branch | `git worktree add -b feat/[name] ../.worktrees/[name]` |
+| List all worktrees | `git worktree list` |
+| Show worktree details | `git worktree list --verbose` |
+| Remove a worktree | `git worktree remove ../.worktrees/[name]` |
+| Force remove (dirty) | `git worktree remove --force ../.worktrees/[name]` |
+| Clean stale entries | `git worktree prune` |
+| Lock (prevent prune) | `git worktree lock ../.worktrees/[name]` |
+| Unlock | `git worktree unlock ../.worktrees/[name]` |
+
+**Workflow patterns:**
+
+1. **Feature + Review parallel:**
+   ```bash
+   # Continue working on your feature
+   git worktree add -b feat/new-api ../.worktrees/feat-new-api
+   # Simultaneously review a colleague's PR
+   git worktree add ../.worktrees/review-pr-42 origin/feat/their-branch
+   ```
+
+2. **Test across branches:**
+   ```bash
+   git worktree add ../.worktrees/test-main main
+   git worktree add ../.worktrees/test-release release/2.0
+   # Run test suites in each directory independently
+   ```
+
+3. **Integration with dmux-workflows:**
+   - One tmux pane per worktree
+   - Each pane cd's into its worktree directory
+   - Each agent instance operates with full filesystem isolation
+   - Merge happens sequentially after all panes complete
+
+**Gotchas and constraints:**
+- Cannot checkout the same branch in two worktrees — git enforces this
+- Submodules are NOT automatically initialized in linked worktrees; run
+  `git submodule update --init` in each new worktree if needed
+- `.gitignore`'d build artifacts are per-worktree (each has its own node_modules,
+  build output, etc.)
+- IDE settings (`.vscode/`, `.idea/`) are per-worktree — configure each separately
+- Hooks in `.git/hooks/` are shared across all worktrees
+- `git stash` is shared — stashes from one worktree are visible in all
+
+### After worktree usage
+
+1. **Cleanup protocol (mandatory after merge):**
+   ```bash
+   # Verify the branch is fully merged
+   git branch --merged main | grep [branch-name]
+   # Remove the worktree
+   git worktree remove ../.worktrees/[name]
+   # Delete the branch if no longer needed
+   git branch -d [branch-name]
+   # Prune any stale worktree references
+   git worktree prune
+   ```
+
+2. **Never leave stale worktrees:**
+   - Stale worktrees consume disk space and pollute `git worktree list`
+   - After every merge or abandoned branch: remove the corresponding worktree
+   - Run `git worktree prune` weekly as maintenance hygiene
+   - Use `git worktree list` to audit — if a worktree's branch no longer exists
+     on remote, it is likely stale
+
+3. **Post-cleanup verification:**
+   - `git worktree list` shows only the main worktree (or active ones)
+   - No orphaned directories remain in `.worktrees/`
+   - `git branch -v` shows no dangling local branches from removed worktrees
+
+## Self-check before task completion
+
+Before marking a worktree-related task done:
+
+- [ ] Did I use the `.worktrees/` sibling directory convention?
+- [ ] Did I verify the target branch was not already checked out elsewhere?
+- [ ] Did I handle submodule initialization if applicable?
+- [ ] Did I clean up worktrees after their purpose was fulfilled?
+- [ ] Did I run `git worktree prune` to remove stale references?
+- [ ] Did I delete merged branches that no longer need worktrees?
+- [ ] Did I verify `git worktree list` shows a clean state?

package/.mindforge/skills/verification-loop/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: verification-loop
+version: 1.0.0
+min_mindforge_version: 10.0.3
+status: stable
+triggers: verification, quality gate, build check, type check, full verification, security scan, diff review, pre-merge, CI gate, green build, ship check, verify all
+compose:
+  - security-review
+---
+
+# Skill — Verification Loop (6-Phase Quality Gate)
+
+## When this skill activates
+Before shipping, merging, or marking any implementation task as complete.
+Provides a systematic 6-phase verification pipeline that catches issues
+at the cheapest point to fix them.
+
+## Mandatory actions when this skill is active
+
+### The 6 Phases (sequential, fail-fast)
+
+**Phase 1 — Build**
+```bash
+npm run build  # or equivalent for project
+```
+- Must produce zero errors
+- Warnings are acceptable but logged
+- If build fails: fix before proceeding (no skipping)
+
+**Phase 2 — Type Check**
+```bash
+npx tsc --noEmit  # or equivalent
+```
+- All type errors must be resolved
+- No `@ts-ignore` without documented reason
+- Generic `any` types flagged as warnings
+
+**Phase 3 — Lint**
+```bash
+npm run lint
+```
+- All lint errors must be resolved
+- Auto-fixable issues: fix immediately (`--fix`)
+- Non-auto-fixable: resolve manually before proceeding
+
+**Phase 4 — Test**
+```bash
+npm test
+```
+- All tests must pass (zero failures)
+- No skipped tests without documented reason
+- If new code was added: verify test coverage exists
+- Coverage threshold: per project config (default 80%)
+
+**Phase 5 — Security Scan**
+- Check for hardcoded secrets (grep for API keys, passwords, tokens)
+- Check for new dependencies with known vulnerabilities
+- Verify no dangerous code execution patterns (dynamic code evaluation, innerHTML, SQL concatenation) introduced
+- Run security-review skill checklist on the diff
+
+**Phase 6 — Diff Review**
+```bash
+git diff --staged  # or git diff main...HEAD
+```
+- Review every changed line for:
+  - Accidental debug code (console.log, debugger, TODO)
+  - Unintended file changes (lock files, configs)
+  - Sensitive data exposure
+  - Logic errors visible in the diff
+
+**Phase 6.5 — De-Slop Scan (Informational)**
+- Run de-sloppify skill in dry-run scan mode on the current diff
+- Report findings count per category:
+  - Debug code (console.log, debugger, print statements)
+  - Test slop (skipped tests, test-only exports)
+  - Commented code blocks (3+ consecutive commented lines)
+  - Naming inconsistencies (mixed camelCase/snake_case)
+  - TODO hacks (shipped workarounds disguised as TODOs)
+- This phase is **INFORMATIONAL ONLY** — it does NOT block shipping
+- If findings > 0: append summary to verification output as advisory
+- Rationale: awareness of residual slop before shipping, without blocking velocity
+
+### Execution Rules
+- Phases execute in ORDER (1→2→3→4→5→6)
+- Each phase must PASS before the next begins (fail-fast)
+- On failure: report which phase failed, what the error is, suggest fix
+- After fixing: restart from the FAILED phase (not from Phase 1)
+- All 6 phases passing = "green" verification = safe to ship
+
+### Integration
+- `/mindforge:verify-loop` invokes this full pipeline
+- `/mindforge:ship` MUST run verify-loop before proceeding
+- Autonomous mode runs verify-loop after every task (Phase 4+5+6 minimum)
+
+### After verification passes
+- Log verification result in AUDIT with per-phase timing
+- Report: "All 6 verification gates passed (+ Phase 6.5 advisory). Safe to proceed."