mindforge-cc 10.0.3 → 10.7.0

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

@@ -68,6 +68,18 @@ git diff --staged  # or git diff main...HEAD
   - 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)
@@ -82,4 +94,4 @@ git diff --staged  # or git diff main...HEAD
 
 ### After verification passes
 - Log verification result in AUDIT with per-phase timing
-- Report: "All 6 verification gates passed. Safe to proceed."
+- Report: "All 6 verification gates passed (+ Phase 6.5 advisory). Safe to proceed."

package/.mindforge/skills/vibe-security/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: vibe-security
+version: 1.0.0
+min_mindforge_version: 10.0.5
+status: stable
+triggers: vibe check security, quick security, rapid security, security intuition, fast security scan, security gut check, security quick look, attack surface quick, security sanity check, owasp quick, header check, security baseline
+compose: security-review
+---
+
+# Skill — Vibe Security (Fast-Path Security Assessment)
+
+## When this skill activates
+
+When a rapid security assessment is needed (2-5 minutes) rather than a full
+threat model (15-30 minutes). Use for quick sanity checks during development,
+pre-commit security sweeps, or when something "feels off" about the security
+posture. Covers the 7 most common vulnerability domains with actionable checks.
+
+Core principle: **Speed over exhaustiveness** — catch the 80% of issues in 20%
+of the time. Flag anything that needs deeper investigation for the full
+security-review skill.
+
+## Mandatory actions when this skill is active
+
+### Before assessment begins
+
+1. **Scope the check:**
+   - What changed? (diff-based: only assess modified/new code)
+   - What domain? (web app, API, CLI, library, infrastructure)
+   - What data sensitivity? (public, internal, PII, financial, health)
+   - Time budget: strictly 2-5 minutes (set a mental timer)
+
+2. **Identify the attack surface:**
+   - Entry points: HTTP endpoints, CLI args, file inputs, env vars
+   - Data flows: user input → processing → storage → output
+   - Trust boundaries: client/server, service/service, internal/external
+
+### During assessment
+
+**Domain 1 — Access Control:**
+- [ ] IDs are UUIDs, not sequential integers (prevents enumeration)
+- [ ] Ownership verified at the data layer, not just the route layer
+- [ ] Multi-tenant: org/team membership checked on every data access
+- [ ] Admin endpoints have explicit role checks (not just "is authenticated")
+- [ ] No horizontal privilege escalation (user A accessing user B's data)
+
+**Domain 2 — XSS (Cross-Site Scripting):**
+- [ ] Output encoding applied per context:
+  - HTML body: HTML entity encoding
+  - HTML attributes: attribute encoding
+  - JavaScript: JS string encoding
+  - URLs: percent encoding
+  - CSS: CSS encoding
+- [ ] Content Security Policy (CSP) header present and restrictive
+- [ ] DOMPurify or equivalent used for any user-generated HTML rendering
+- [ ] No raw HTML injection patterns (e.g., innerHTML assignment from user input)
+- [ ] React/framework auto-escaping not bypassed without sanitization
+
+**Domain 3 — CSRF (Cross-Site Request Forgery):**
+- [ ] CSRF tokens present on state-changing requests
+- [ ] Tokens are session-tied and regenerated on login
+- [ ] SameSite cookie attribute set (Lax minimum, Strict preferred)
+- [ ] Double-submit cookie pattern as backup for API endpoints
+- [ ] GET requests never perform state changes
+
+**Domain 4 — SSRF (Server-Side Request Forgery):**
+- [ ] URL allowlist validation (not blocklist — blocklists are bypassable)
+- [ ] DNS rebinding prevention (resolve DNS, validate IP, THEN connect)
+- [ ] Cloud metadata endpoint blocked: `169.254.169.254`, `fd00:ec2::254`
+- [ ] Internal network ranges blocked: `10.x`, `172.16-31.x`, `192.168.x`
+- [ ] IP bypass vectors checked (see catalog below)
+
+**Domain 5 — SQL Injection:**
+- [ ] All queries use parameterized statements (never string concatenation)
+- [ ] ORM usage verified as safe (no raw query building from user input)
+- [ ] Database user has least-privilege permissions (no DROP, no schema changes)
+- [ ] Dynamic column/table names validated against allowlist (not user-controlled)
+
+**Domain 6 — File Upload:**
+- [ ] File type validated by magic bytes (not just extension)
+- [ ] Files stored outside the webroot (not directly accessible via URL)
+- [ ] Filename sanitized (stripped of path separators, null bytes, special chars)
+- [ ] File size limits enforced server-side (not just client-side)
+- [ ] Image files re-encoded to strip embedded scripts/metadata
+
+**Domain 7 — Path Traversal:**
+- [ ] Paths canonicalized before use (`path.resolve`, `realpath`)
+- [ ] Resolved path validated against base directory (must be child of allowed dir)
+- [ ] No user input used directly in filesystem paths
+- [ ] Null byte injection prevented (relevant for older runtimes)
+- [ ] Symlink following restricted or validated
+
+**IP Bypass Catalog (for SSRF testing):**
+```
+127.0.0.1 variants:
+- Decimal:     2130706433
+- Octal:       017700000001
+- Hex:         0x7f000001
+- IPv6:        ::1
+- IPv6 mapped: ::ffff:127.0.0.1
+- Short:       127.1
+- Zero:        0.0.0.0
+
+Cloud metadata:
+- AWS:         169.254.169.254, fd00:ec2::254
+- GCP:         metadata.google.internal
+- Azure:       169.254.169.254 (header: Metadata: true)
+```
+
+**Security Headers Baseline:**
+```
+Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
+Content-Security-Policy: default-src 'self'; script-src 'self'
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: camera=(), microphone=(), geolocation=()
+```
+
+- [ ] All 6 headers present in HTTP responses
+- [ ] CSP does not include `unsafe-inline` or `unsafe-eval` without justification
+
+### After assessment
+
+1. **Generate VIBE-SECURITY-CHECK.md:**
+   ```markdown
+   ## Vibe Security Check — [date]
+   **Scope:** [what was assessed]
+   **Time spent:** [X minutes]
+   **Risk level:** LOW / MEDIUM / HIGH / CRITICAL
+
+   ### Findings
+   | # | Domain | Finding | Severity | Remediation |
+   |---|--------|---------|----------|-------------|
+   | 1 | ...    | ...     | ...      | ...         |
+
+   ### Headers Status
+   [present/missing for each of 6 headers]
+
+   ### Needs Deeper Review
+   [list anything that requires full security-review skill]
+   ```
+
+2. **Severity classification:**
+   - CRITICAL: Exploitable now, leads to data breach or auth bypass
+   - HIGH: Exploitable with moderate effort, significant impact
+   - MEDIUM: Requires specific conditions, limited impact
+   - LOW: Defense-in-depth improvement, not directly exploitable
+
+3. **Escalation rules:**
+   - Any CRITICAL finding: STOP all other work, fix immediately
+   - 2+ HIGH findings: escalate to full `security-review` skill
+   - MEDIUM/LOW: add to backlog, fix in next sprint
+
+## Self-check before task completion
+
+Before marking a vibe security check done:
+
+- [ ] Did I check all 7 domains (access control, XSS, CSRF, SSRF, SQLi, upload, path traversal)?
+- [ ] Did I verify security headers (all 6 present and correctly configured)?
+- [ ] Did I check for IP bypass vulnerabilities in any SSRF-adjacent code?
+- [ ] Did I stay within the 5-minute time budget?
+- [ ] Did I generate VIBE-SECURITY-CHECK.md with findings and severity?
+- [ ] Did I escalate CRITICAL findings immediately?
+- [ ] Did I flag items needing deeper review for the full security-review skill?