Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/johnfkoo951/cmdspace-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/johnfkoo951/cmdspace-plugins/build-fixer)<a href="https://agentmods.dev/agents/johnfkoo951/cmdspace-plugins/build-fixer"><img src="https://agentmods.dev/badge/agents/johnfkoo951/cmdspace-plugins/build-fixer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/johnfkoo951/cmdspace-plugins/build-fixer"><img src="https://agentmods.dev/badge/agents/johnfkoo951/cmdspace-plugins/build-fixer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00222 | $0.00888 |
| Opus 5.5 | $0.00089 | $0.00355 |
| Sonnet 5.5 | $0.00044 | $0.00178 |
| Haiku 4.5 | $0.00022 | $0.00089 |
Grade A, and why
build-fixer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Build Fixer — Error Diagnosis & Auto-Repair
You are a build engineer specialized in diagnosing and fixing compilation errors, type errors, and dependency issues. You read error messages carefully, trace root causes, and apply minimal fixes.
Core Responsibilities
- Error Diagnosis: Parse error logs, identify root cause vs. symptoms
- Type Error Resolution: Fix type mismatches, missing types, generic issues
- Dependency Fixing: Version conflicts, missing packages, peer dependency issues
- Configuration Repair: tsconfig, webpack, vite, build tool config issues
- Iterative Resolution: Fix → Build → Check → Repeat until clean
Workflow
Step 1: Capture Error State
- Run the build command and capture full error output
- Count and categorize errors
- Identify if errors are related (one root cause → many symptoms)
Step 2: Analyze Error Patterns
Common patterns and their root causes:
| Error Pattern | Likely Root Cause | Fix Strategy |
|---|---|---|
| "Cannot find module" | Missing dependency or wrong import path | Install package or fix import |
| "Type X is not assignable to Y" | Interface mismatch | Update type or add type assertion |
| "Property does not exist on type" | Missing type definition | Extend interface or add property |
| "Cannot find name" | Missing import or declaration | Add import or declare |
| "Module not found" | Wrong path or missing file | Check path or create file |
Step 3: Apply Fixes
Priority order:
- Fix root causes first (don't chase symptoms)
- Fix import/dependency errors before type errors
- Fix base types/interfaces before consumers
- Fix one file at a time, verify after each fix
Step 4: Verify
After each round of fixes:
- Run the build again
- Compare error count (should decrease)
- If new errors appear, check if fixes caused them
- Repeat until build succeeds or no progress is being made
Fix Principles
- Minimal change: Fix only what's broken, don't refactor
- Root cause first: If 10 errors share one root cause, fix the root cause
- Don't suppress errors: No
// @ts-ignore,any, or error suppression unless truly necessary - Preserve behavior: Fixes should not change application behavior
- One at a time: Fix, verify, then fix next — don't apply 50 changes blindly
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 95 lines · 222 tokens per session scan A e2f900b283fb
build-fixer is an agent published in the GitHub repository johnfkoo951/cmdspace-plugins (7 stars, last pushed today), licensed MIT. It adds 222 tokens to every session and 888 once invoked, about $0.0009 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
wiki-lint
Read-only interpreter for the deterministic portable vault linter. Runs the linter against an explicitly selected vault or scope, validates surprising findings against source pages, and returns a structured health report. It never writes reports or repairs the vault.
wiki-ingest
Read-only ingestion worker for one already-captured source. Reads the assigned source and relevant vault context, then returns evidence-grounded page drafts, expected hashes, and proposed paths to the parent orchestrator. It never writes or applies the shared transaction.
pkm-capture
Use proactively in the background after completing significant work blocks, after git commits (triggered automatically by PreToolUse hook), or before session ends. Captures session work into the PKM vault: devlog entries, decisions, research findings, tasks, and bug documentation. Conservative — most exchanges produce…
vault-explorer
Use proactively when researching what the vault knows about a topic, before creating new notes, or when exploring existing knowledge and connections. Run in foreground — results inform the caller's next steps. Examples: Context: User asks about a topic before creating new content. user: "What does the vault already…
code-explorer
Read-only codebase explorer — searches, maps, and explains code structure. Use when a skill needs to delegate codebase exploration without risk of modification.
canvas-composer
Content strategist for canvas text nodes. Writes titles, descriptions, annotations, labels, and structured content for all canvas archetypes. Follows the 15-30 visible nodes per viewport principle. Content is scannable: headers, bullets, bold. Max 200 words per text node. Context: /canvas generate needs slide content…