mindforge-cc 11.8.2 → 11.9.0

package/.mindforge/skills/research-paper-writing/templates/README.md

@@ -0,0 +1,251 @@
+# LaTeX Templates for ML/AI Conferences
+
+This directory contains official LaTeX templates for major machine learning and AI conferences.
+
+---
+
+## Compiling LaTeX to PDF
+
+### Option 1: VS Code with LaTeX Workshop (Recommended)
+
+**Setup:**
+1. Install [TeX Live](https://www.tug.org/texlive/) (full distribution recommended)
+   - macOS: `brew install --cask mactex`
+   - Ubuntu: `sudo apt install texlive-full`
+   - Windows: Download from [tug.org/texlive](https://www.tug.org/texlive/)
+
+2. Install VS Code extension: **LaTeX Workshop** by James Yu
+   - Open VS Code → Extensions (Cmd/Ctrl+Shift+X) → Search "LaTeX Workshop" → Install
+
+**Usage:**
+- Open any `.tex` file in VS Code
+- Save the file (Cmd/Ctrl+S) → Auto-compiles to PDF
+- Click the green play button or use `Cmd/Ctrl+Alt+B` to build
+- View PDF: Click "View LaTeX PDF" icon or `Cmd/Ctrl+Alt+V`
+- Side-by-side view: `Cmd/Ctrl+Alt+V` then drag tab
+
+**Settings** (add to VS Code `settings.json`):
+```json
+{
+  "latex-workshop.latex.autoBuild.run": "onSave",
+  "latex-workshop.view.pdf.viewer": "tab",
+  "latex-workshop.latex.recipes": [
+    {
+      "name": "pdflatex → bibtex → pdflatex × 2",
+      "tools": ["pdflatex", "bibtex", "pdflatex", "pdflatex"]
+    }
+  ]
+}
+```
+
+### Option 2: Command Line
+
+```bash
+# Basic compilation
+pdflatex main.tex
+
+# With bibliography (full workflow)
+pdflatex main.tex
+bibtex main
+pdflatex main.tex
+pdflatex main.tex
+
+# Using latexmk (handles dependencies automatically)
+latexmk -pdf main.tex
+
+# Continuous compilation (watches for changes)
+latexmk -pdf -pvc main.tex
+```
+
+### Option 3: Overleaf (Online)
+
+1. Go to [overleaf.com](https://www.overleaf.com)
+2. New Project → Upload Project → Upload the template folder as ZIP
+3. Edit online with real-time PDF preview
+4. No local installation needed
+
+### Option 4: Other IDEs
+
+| IDE | Extension/Plugin | Notes |
+|-----|------------------|-------|
+| **Cursor** | LaTeX Workshop | Same as VS Code |
+| **Sublime Text** | LaTeXTools | Popular, well-maintained |
+| **Vim/Neovim** | VimTeX | Powerful, keyboard-driven |
+| **Emacs** | AUCTeX | Comprehensive LaTeX environment |
+| **TeXstudio** | Built-in | Dedicated LaTeX IDE |
+| **Texmaker** | Built-in | Cross-platform LaTeX editor |
+
+### Troubleshooting Compilation
+
+**"File not found" errors:**
+```bash
+# Ensure you're in the template directory
+cd templates/icml2026
+pdflatex example_paper.tex
+```
+
+**Bibliography not appearing:**
+```bash
+# Run bibtex after first pdflatex
+pdflatex main.tex
+bibtex main        # Uses main.aux to find citations
+pdflatex main.tex  # Incorporates bibliography
+pdflatex main.tex  # Resolves references
+```
+
+**Missing packages:**
+```bash
+# TeX Live package manager
+tlmgr install <package-name>
+
+# Or install full distribution to avoid this
+```
+
+---
+
+## Available Templates
+
+| Conference | Directory | Year | Source |
+|------------|-----------|------|--------|
+| ICML | `icml2026/` | 2026 | [Official ICML](https://icml.cc/Conferences/2026/AuthorInstructions) |
+| ICLR | `iclr2026/` | 2026 | [Official GitHub](https://github.com/ICLR/Master-Template) |
+| NeurIPS | `neurips2025/` | 2025 | Community template |
+| ACL | `acl/` | 2025+ | [Official ACL](https://github.com/acl-org/acl-style-files) |
+| AAAI | `aaai2026/` | 2026 | [AAAI Author Kit](https://aaai.org/authorkit26/) |
+| COLM | `colm2025/` | 2025 | [Official COLM](https://github.com/COLM-org/Template) |
+
+## Usage
+
+### ICML 2026
+
+```latex
+\documentclass{article}
+\usepackage{icml2026}  % For submission
+% \usepackage[accepted]{icml2026}  % For camera-ready
+
+\begin{document}
+% Your paper content
+\end{document}
+```
+
+Key files:
+- `icml2026.sty` - Style file
+- `icml2026.bst` - Bibliography style
+- `example_paper.tex` - Example document
+
+### ICLR 2026
+
+```latex
+\documentclass{article}
+\usepackage[submission]{iclr2026_conference}  % For submission
+% \usepackage[final]{iclr2026_conference}  % For camera-ready
+
+\begin{document}
+% Your paper content
+\end{document}
+```
+
+Key files:
+- `iclr2026_conference.sty` - Style file
+- `iclr2026_conference.bst` - Bibliography style
+- `iclr2026_conference.tex` - Example document
+
+### ACL Venues (ACL, EMNLP, NAACL)
+
+```latex
+\documentclass[11pt]{article}
+\usepackage[review]{acl}  % For review
+% \usepackage{acl}  % For camera-ready
+
+\begin{document}
+% Your paper content
+\end{document}
+```
+
+Key files:
+- `acl.sty` - Style file
+- `acl_natbib.bst` - Bibliography style
+- `acl_latex.tex` - Example document
+
+### AAAI 2026
+
+```latex
+\documentclass[letterpaper]{article}
+\usepackage[submission]{aaai2026}  % For submission
+% \usepackage{aaai2026}  % For camera-ready
+
+\begin{document}
+% Your paper content
+\end{document}
+```
+
+Key files:
+- `aaai2026.sty` - Style file
+- `aaai2026.bst` - Bibliography style
+
+### COLM 2025
+
+```latex
+\documentclass{article}
+\usepackage[submission]{colm2025_conference}  % For submission
+% \usepackage[final]{colm2025_conference}  % For camera-ready
+
+\begin{document}
+% Your paper content
+\end{document}
+```
+
+Key files:
+- `colm2025_conference.sty` - Style file
+- `colm2025_conference.bst` - Bibliography style
+
+## Page Limits Summary
+
+| Conference | Submission | Camera-Ready | Notes |
+|------------|-----------|--------------|-------|
+| ICML 2026 | 8 pages | 9 pages | +unlimited refs/appendix |
+| ICLR 2026 | 9 pages | 10 pages | +unlimited refs/appendix |
+| NeurIPS 2025 | 9 pages | 9 pages | +checklist outside limit |
+| ACL 2025 | 8 pages (long) | varies | +unlimited refs/appendix |
+| AAAI 2026 | 7 pages | 8 pages | +unlimited refs/appendix |
+| COLM 2025 | 9 pages | 10 pages | +unlimited refs/appendix |
+
+## Common Issues
+
+### Compilation Errors
+
+1. **Missing packages**: Install full TeX distribution (TeX Live Full or MikTeX)
+2. **Bibliography errors**: Use the provided `.bst` file with `\bibliographystyle{}`
+3. **Font warnings**: Install `cm-super` or use `\usepackage{lmodern}`
+
+### Anonymization
+
+For submission, ensure:
+- No author names in `\author{}`
+- No acknowledgments section
+- No grant numbers
+- Use anonymous repositories
+- Cite own work in third person
+
+### Common LaTeX Packages
+
+```latex
+% Recommended packages (check compatibility with venue style)
+\usepackage{amsmath,amsthm,amssymb}  % Math
+\usepackage{graphicx}                 % Figures
+\usepackage{booktabs}                 % Tables
+\usepackage{hyperref}                 % Links
+\usepackage{algorithm,algorithmic}    % Algorithms
+\usepackage{natbib}                   % Citations
+```
+
+## Updating Templates
+
+Templates are updated annually. Check official sources before each submission:
+
+- ICML: https://icml.cc/
+- ICLR: https://iclr.cc/
+- NeurIPS: https://neurips.cc/
+- ACL: https://github.com/acl-org/acl-style-files
+- AAAI: https://aaai.org/
+- COLM: https://colmweb.org/

package/.mindforge/skills/scrapling/SKILL.md

@@ -19,7 +19,7 @@ triggers: scrape website, web scraping, extract web content, scrape page, web pa
 - Scraping JS-rendered pages that need a real browser
 - Bypassing Cloudflare Turnstile or bot detection
 - Crawling multiple pages with a spider
-- When the built-in `web_extract` tool does not return the data you need
+- When the built-in `WebFetch` tool does not return the data you need
 
 ## Installation
 

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

@@ -3,7 +3,7 @@ name: security-review
 version: 1.0.0
 min_mindforge_version: 0.1.0
 status: stable
-triggers: auth, authentication, authorisation, authorization, login, logout, password, token, JWT, session, cookie, OAuth, payment, billing, stripe, PII, GDPR, personal data, upload, file upload, credentials, API key, secret, env, environment variable, encryption, hashing, bcrypt, argon2
+triggers: auth, authentication, authorisation, authorization, login, logout, password, token, JWT, session, secure cookie, OAuth, payment, billing, stripe, data protection audit, privacy compliance, sensitive data, upload, file upload, credentials, API key, secret, env, environment variable, encryption, hashing, bcrypt, argon2
 ---
 
 # Skill — Security Review

package/.mindforge/skills/sherlock/SKILL.md

@@ -71,7 +71,7 @@ sherlock --print-found --no-color "<username>" --timeout 90
 
 ### 4. Execute Search
 
-Run via the `terminal` tool. The command typically takes 30-120 seconds depending on network conditions and site count.
+Run via the `Bash` tool. The command typically takes 30-120 seconds depending on network conditions and site count.
 
 **Example terminal call:**
 ```json

package/.mindforge/skills/simplify-code/SKILL.md

@@ -71,15 +71,13 @@ before proceeding.
 
 ### Phase 2 — Launch three reviewers in parallel
 
-Use `delegate_task` **batch mode** — pass all three tasks in one `tasks`
-array so they run concurrently. Three is the right fan-out for this pattern;
-it's well within the `delegation.max_concurrent_children` budget on any
-default install.
+Make three separate `Agent` tool calls **in the same response** so they run
+concurrently. Three is the right fan-out for this pattern.
 
 Give **every** reviewer the **complete diff** (not fragments — cross-file
 issues hide in the gaps) plus the absolute repo path so they can search the
-wider codebase. Each reviewer gets `terminal`, `file`, and `search`
-toolsets (so they can `git`, `read_file`, and `search_files`/grep).
+wider codebase. Each reviewer gets `Bash` (for `git`), `Read`, and `Grep`
+so they can inspect the full diff and the wider codebase.
 
 Tell each reviewer to:
 - Search the existing codebase for evidence (don't reason from the diff alone).
@@ -134,7 +132,7 @@ Wait for all three to return (batch mode returns them together).
    Don't apply a perf "fix" that hurts clarity unless the path is genuinely
    hot. When two suggestions are mutually exclusive and both defensible, pick
    the one that touches less code and note the alternative.
-4. **Apply** the surviving fixes directly with `patch` / `write_file` — unless
+4. **Apply** the surviving fixes directly with `Edit` / `Write` — unless
    the user asked for a dry run, in which case present the list and ask first.
 5. **Verify** you didn't break anything: run the project's targeted tests for
    the touched files (not the full suite), and re-run any linter/type check the

package/.mindforge/skills/spike/SKILL.md

@@ -74,11 +74,11 @@ Spikes are not research-free — you research enough to pick the right approach,
 
 Use available tools for the research step:
 
-- `web_search("python websocket streaming libraries 2025")` — find candidates
-- `web_extract(urls=["https://websockets.readthedocs.io/..."])` — read the actual docs (returns markdown)
-- `terminal("pip show websockets | grep Version")` — check what's installed in the project's venv
+- `WebSearch("python websocket streaming libraries 2025")` — find candidates
+- `WebFetch(urls=["https://websockets.readthedocs.io/..."])` — read the actual docs (returns markdown)
+- `Bash("pip show websockets | grep Version")` — check what's installed in the project's venv
 
-For libraries without docs pages, clone and read their `README.md` / `examples/` via `read_file`. Context7 MCP (if the user has it configured) is also a good source — `mcp_*_resolve-library-id` then `mcp_*_query-docs`.
+For libraries without docs pages, clone and read their `README.md` / `examples/` via `Read`. WebFetch MCP (if the user has it configured) is also a good source — `mcp_*_resolve-library-id` then `mcp_*_query-docs`.
 
 ### 4. Build
 
@@ -111,20 +111,18 @@ spikes/
 **Building one spike** — a typical tool sequence:
 
 ```
-terminal("mkdir -p spikes/001-websocket-streaming")
-write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
-write_file("spikes/001-websocket-streaming/main.py", "...")
-terminal("cd spikes/001-websocket-streaming && python3 main.py")
+Bash("mkdir -p spikes/001-websocket-streaming")
+Write("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
+Write("spikes/001-websocket-streaming/main.py", "...")
+Bash("cd spikes/001-websocket-streaming && python3 main.py")
 # Observe output, iterate.
 ```
 
-**Parallel comparison spikes (002a / 002b) — delegate.** When two approaches can run in parallel and both need real engineering (not 10-line prototypes), fan out with `delegate_task`:
+**Parallel comparison spikes (002a / 002b) — delegate.** When two approaches can run in parallel and both need real engineering (not 10-line prototypes), fan out with two `Agent` tool calls in the same response:
 
 ```
-delegate_task(tasks=[
-    {"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
-    {"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
-])
+Agent(prompt="Build 002a-pdf-parse-pdfjs: ...")
+Agent(prompt="Build 002b-pdf-parse-camelot: ...")
 ```
 
 Each subagent returns its own verdict; you write the head-to-head.

package/.mindforge/skills/subagent-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: subagent-driven-development
-description: "Execute plans via delegate_task subagents (2-stage review)."
+description: "Execute plans via Agent subagents (2-stage review)."
 version: 1.1.0
 status: stable
 min_mindforge_version: 11.5.1
@@ -37,7 +37,7 @@ Read the plan file. Extract ALL tasks with their full text and context upfront.
 
 ```python
 # Read the plan
-read_file("docs/plans/feature-plan.md")
+Read("docs/plans/feature-plan.md")
 
 # Create todo list with all tasks
 todo([
@@ -55,10 +55,10 @@ For EACH task in the plan:
 
 #### Step 1: Dispatch Implementer Subagent
 
-Use `delegate_task` with complete context:
+Use `Agent` with complete context:
 
 ```python
-delegate_task(
+Agent(
     goal="Implement Task 1: Create User model with email and password_hash fields",
     context="""
     TASK FROM PLAN:
@@ -81,7 +81,6 @@ delegate_task(
     - Tests use pytest, run from project root
     - bcrypt already in requirements.txt
     """,
-    toolsets=['terminal', 'file']
 )
 ```
 
@@ -90,7 +89,7 @@ delegate_task(
 After the implementer completes, verify against the original spec:
 
 ```python
-delegate_task(
+Agent(
     goal="Review if implementation matches the spec from the plan",
     context="""
     ORIGINAL TASK SPEC:
@@ -108,7 +107,6 @@ delegate_task(
 
     OUTPUT: PASS or list of specific spec gaps to fix.
     """,
-    toolsets=['file']
 )
 ```
 
@@ -119,7 +117,7 @@ delegate_task(
 After spec compliance passes:
 
 ```python
-delegate_task(
+Agent(
     goal="Review code quality for Task 1 implementation",
     context="""
     FILES TO REVIEW:
@@ -140,7 +138,6 @@ delegate_task(
     - Minor Issues: [optional]
     - Verdict: APPROVED or REQUEST_CHANGES
     """,
-    toolsets=['file']
 )
 ```
 
@@ -157,7 +154,7 @@ todo([{"id": "task-1", "content": "Create User model with email field", "status"
 After ALL tasks are complete, dispatch a final integration reviewer:
 
 ```python
-delegate_task(
+Agent(
     goal="Review the entire implementation for consistency and integration issues",
     context="""
     All tasks from the plan are complete. Review the full implementation:
@@ -166,7 +163,6 @@ delegate_task(
     - All tests passing?
     - Ready for merge?
     """,
-    toolsets=['terminal', 'file']
 )
 ```
 

package/.mindforge/skills/subagent-driven-development/references/context-budget-discipline.md

@@ -0,0 +1,53 @@
+# Context Budget Discipline
+
+Practical rules for keeping orchestrator context lean when spawning subagents or reading large artifacts. Use these whenever you're running a multi-step agent loop that will consume significant context — plan execution, subagent orchestration, review pipelines, multi-file refactors.
+
+Adapted from the GSD (Get Shit Done) project's context-budget reference — MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done)).
+
+## Universal rules
+
+Every workflow that spawns agents or reads significant content must follow these:
+
+1. **Never read agent definition files.** `delegate_task` auto-loads them — you reading them too just doubles the cost.
+2. **Never inline large files into subagent prompts.** Tell the agent to read the file from disk with `read_file` instead. The subagent gets full content; your context stays lean.
+3. **Read depth scales with context window.** See the table below.
+4. **Delegate heavy work to subagents.** The orchestrator routes; it doesn't execute.
+5. **Proactively warn** the user when you've consumed significant context ("Context is getting heavy — consider checkpointing progress before we continue").
+
+## Read depth by context window
+
+Check the model's actual context window (not "it's Claude so 200K"). Some Sonnet deployments are 1M, some are 200K. If you don't know, assume the smaller one — err toward leanness.
+
+| Context window | Subagent output reading | Summary files | Verification files | Plans for other phases |
+|----------------|-------------------------|---------------|--------------------|-----------------------|
+| < 500k (e.g. 200k) | Frontmatter only | Frontmatter only | Frontmatter only | Current phase only |
+| >= 500k (1M models) | Full body permitted | Full body permitted | Full body permitted | Current phase only |
+
+"Frontmatter only" means: read enough to see the final status/verdict/conclusion. If the subagent wrote a 3000-line debug log, read the summary section it produced, not the log.
+
+## Four-tier degradation model
+
+Monitor your context usage and shift behavior as you climb the tiers. The point is to notice *before* you hit the wall, not when responses start truncating.
+
+| Tier | Usage | Behavior |
+|------|-------|----------|
+| **PEAK** | 0 – 30% | Full operations. Read bodies, spawn multiple agents in parallel, inline results freely. |
+| **GOOD** | 30 – 50% | Normal operations. Prefer frontmatter reads. Delegate aggressively. |
+| **DEGRADING** | 50 – 70% | Economize. Frontmatter-only reads, minimal inlining, **warn the user** about budget. |
+| **POOR** | 70%+ | Emergency mode. **Checkpoint progress immediately.** No new reads unless critical. Finish the current task and stop cleanly. |
+
+## Early warning signs (before panic thresholds fire)
+
+Quality degrades *gradually* before hard limits hit. Watch for these:
+
+- **Silent partial completion.** Subagent claims done but implementation is incomplete. Self-checks catch file existence, not semantic completeness. Always verify subagent output against the plan's must-haves, not just "did a file appear?"
+- **Increasing vagueness.** Agent starts using phrases like "appropriate handling" or "standard patterns" instead of specific code. This is context pressure showing up before budget warnings fire.
+- **Skipped protocol steps.** Agent omits steps it would normally follow. If success criteria has 8 items and the report covers 5, suspect context pressure, not "the agent decided 5 was enough."
+
+When these signs appear, checkpoint the work and either reset context or hand off to a fresh subagent.
+
+## Fundamental limitation
+
+When you orchestrate, you cannot verify semantic correctness of subagent output — only structural completeness ("did the file appear?", "does the test pass?"). Semantic verification requires either running the code yourself or delegating a review pass to another fresh subagent.
+
+**Mitigation:** in every task you delegate, include explicit "must-have" truths the subagent must confirm in its response (e.g., "confirm your test actually tests X, not just that X was imported"). The subagent re-asserting concrete facts is evidence; vague summaries are not.

package/.mindforge/skills/subagent-driven-development/references/gates-taxonomy.md

@@ -0,0 +1,93 @@
+# Gates Taxonomy
+
+Canonical gate types for validation checkpoints across any workflow that spawns subagents, runs review loops, or has human-approval pauses. Every validation checkpoint maps to one of these four types — naming them explicitly makes the workflow legible and prevents "what happens when this check fails?" confusion.
+
+Adapted from the GSD (Get Shit Done) project's gates reference — MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done)).
+
+## The four gate types
+
+### 1. Pre-flight gate
+
+**Purpose:** Validates preconditions before starting an operation.
+
+**Behavior:** Blocks entry if conditions unmet. No partial work created — bail before anything changes.
+
+**Recovery:** Fix the missing precondition, then retry.
+
+**Examples:**
+- Implementation phase checks that the plan file exists before it starts writing code.
+- Delegated subagent checks that required env vars are set before making API calls.
+- Commit checks that tests passed before pushing.
+
+### 2. Revision gate
+
+**Purpose:** Evaluates output quality and routes to revision if insufficient.
+
+**Behavior:** Loops back to the producer with specific feedback. Bounded by an iteration cap (typically 3).
+
+**Recovery:** Producer addresses feedback; checker re-evaluates. The loop escalates early if issue count does not decrease between consecutive iterations (stall detection). After max iterations, escalates to the user unconditionally — never loop forever.
+
+**Examples:**
+- Plan reviewer reads a draft plan, returns specific issues, planner revises, reviewer re-reads (max 3 cycles).
+- Code reviewer checks subagent-produced code against must-haves; dispatches fixes back to the implementer if any must-have failed.
+- Test coverage checker validates new tests exercise the new paths; if not, sends back to author.
+
+### 3. Escalation gate
+
+**Purpose:** Surfaces unresolvable issues to the human for a decision.
+
+**Behavior:** Pauses workflow, presents options, waits for human input. Never guesses, never picks a default.
+
+**Recovery:** Human chooses action; workflow resumes on the selected path.
+
+**Examples:**
+- Revision loop exhausted after 3 iterations.
+- Merge conflict during automated worktree cleanup.
+- Ambiguous requirement — two reasonable interpretations and the choice changes the approach.
+- Subagent reports "the plan says X but the codebase actually does Y" — human decides which is right.
+
+### 4. Abort gate
+
+**Purpose:** Terminates the operation to prevent damage or waste.
+
+**Behavior:** Stops immediately, preserves state (checkpoint current progress), reports the specific reason.
+
+**Recovery:** Human investigates root cause, fixes, restarts from checkpoint.
+
+**Examples:**
+- Context window critically low during execution (POOR tier, >70%) — abort cleanly rather than produce truncated output.
+- Critical dependency unavailable mid-run (network down, API key revoked).
+- Unrecoverable filesystem state (disk full, permissions lost).
+- Safety invariant violated (agent attempted an irreversible destructive action outside approved scope).
+
+## How to use this in a skill
+
+When you write an orchestration skill that has validation checkpoints, **name each checkpoint by its gate type explicitly** and answer three questions:
+
+1. **What condition triggers this gate?** (e.g., "plan file missing", "issue count didn't decrease", "context >70%")
+2. **What happens when it fails?** (block / loop back / ask human / abort)
+3. **Who resumes, and from where?** (fix precondition + retry, revise + re-check, human decision, restart from checkpoint)
+
+Answering these three up front means your skill never hits "what do we do now?" at runtime.
+
+## Example — a review loop with all four gate types
+
+```
+[Pre-flight] plan.md exists and is non-empty?   → no: bail, ask user to write a plan first
+                ↓ yes
+[Execute]  subagent implements task
+                ↓
+[Revision] reviewer checks against must-haves  → fail: loop back to subagent (max 3)
+                ↓ pass
+[Pre-flight] tests pass?                       → no: bail, report failing tests
+                ↓ yes
+[Commit]
+                ↓
+(on revision loop exhaustion)
+[Escalation] "3 review cycles failed to converge on issue X — pick: force-merge, rewrite task, abandon"
+                ↓ user picks
+(on any tier-POOR context pressure during loop)
+[Abort] "context at 73%, checkpointing and stopping"
+```
+
+The vocabulary is small on purpose. Every gate in every workflow should fit one of these four. If you find yourself inventing a fifth, it's probably a revision gate with extra branching, or an escalation gate in disguise.

package/.mindforge/skills/systematic-debugging/SKILL.md

@@ -64,7 +64,7 @@ You MUST complete each phase before proceeding to the next.
 - Read stack traces completely
 - Note line numbers, file paths, error codes
 
-**Action:** Use `read_file` on the relevant source files. Use `search_files` to find the error string in the codebase.
+**Action:** Use `Read` on the relevant source files. Use `Grep` to find the error string in the codebase.
 
 ### 2. Reproduce Consistently
 
@@ -73,7 +73,7 @@ You MUST complete each phase before proceeding to the next.
 - Does it happen every time?
 - If not reproducible → gather more data, don't guess
 
-**Action:** Use the `terminal` tool to run the failing test or trigger the bug:
+**Action:** Use the `Bash` tool to run the failing test or trigger the bug:
 
 ```bash
 # Run specific failing test
@@ -127,14 +127,14 @@ THEN investigate that specific component.
 - Keep tracing upstream until you find the source
 - Fix at the source, not at the symptom
 
-**Action:** Use `search_files` to trace references:
+**Action:** Use `Grep` to trace references:
 
 ```python
 # Find where the function is called
-search_files("function_name(", path="src/", file_glob="*.py")
+Grep("function_name(", path="src/", file_glob="*.py")
 
 # Find where the variable is set
-search_files("variable_name\\s*=", path="src/", file_glob="*.py")
+Grep("variable_name\\s*=", path="src/", file_glob="*.py")
 ```
 
 ### Phase 1 Completion Checklist
@@ -159,10 +159,10 @@ search_files("variable_name\\s*=", path="src/", file_glob="*.py")
 - Locate similar working code in the same codebase
 - What works that's similar to what's broken?
 
-**Action:** Use `search_files` to find comparable patterns:
+**Action:** Use `Grep` to find comparable patterns:
 
 ```python
-search_files("similar_pattern", path="src/", file_glob="*.py")
+Grep("similar_pattern", path="src/", file_glob="*.py")
 ```
 
 ### 2. Compare Against References
@@ -317,17 +317,17 @@ If you catch yourself thinking:
 
 Use these available tools during Phase 1:
 
-- **`search_files`** — Find error strings, trace function calls, locate patterns
-- **`read_file`** — Read source code with line numbers for precise analysis
-- **`terminal`** — Run tests, check git history, reproduce bugs
-- **`web_search`/`web_extract`** — Research error messages, library docs
+- **`Grep`** — Find error strings, trace function calls, locate patterns
+- **`Read`** — Read source code with line numbers for precise analysis
+- **`Bash`** — Run tests, check git history, reproduce bugs
+- **`WebSearch`/`WebFetch`** — Research error messages, library docs
 
-### With delegate_task
+### With Agent
 
 For complex multi-component debugging, dispatch investigation subagents:
 
 ```python
-delegate_task(
+Agent(
     goal="Investigate why [specific test/behavior] fails",
     context="""
     Follow systematic-debugging skill:
@@ -340,7 +340,6 @@ delegate_task(
     File: [path to failing code]
     Test command: [exact command]
     """,
-    toolsets=['terminal', 'file']
 )
 ```