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.
npx agentmods add skills/lab2a/metalworks/validatenpx skills add Lab2A/metalworks --skill validategit clone --depth 1 https://github.com/Lab2A/metalworksWhat 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 | $0.00145 | $0.00919 |
| Opus 5 | $0.00072 | $0.00460 |
| Sonnet 5 | $0.00029 | $0.00184 |
| Haiku 4.5 | $0.00015 | $0.00092 |
Grade A, and why
validate 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 2d 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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Preamble (run first)
Before any other tool, run the preflight MCP tool (or metalworks preflight on
the CLI). If it reports setup issues or that an update is available, surface that
to the user in one line and help them resolve it (install the missing extra/key,
or pip install -U metalworks) before continuing. Skip only if the user has
already passed preflight this session.
Read the reference; never reverse-engineer the source. The moment you need to know how
metalworks behaves — provider/model resolution, which source/reader runs, config precedence,
an error you hit, or the async run loop — STOP and read docs/operating-metalworks.md
(bundled with this plugin) before opening any file under src/. It is the source of truth;
do not derive behavior from source. (Full docs: https://metalworks.lab2a.ai/docs.) For a
long-running run, poll status with the Monitor tool or a bounded loop — never a blind sleep.
You are running a founder through the whole discovery loop, and they make the call at each gate. You drive the stages by calling the discrete tools; the human is the decision callback. The loop ends on GO (advance to building), NO-GO (kill it honestly), or when you've circled the space without a new fork to try (exhausted — say so).
The loop
Repeat until GO, NO-GO, or exhausted (cap ~4 rounds):
-
Ideate. Call
ideate_from_ideawith the current idea (first round: the user's idea; later rounds: the pivot target from the previous assessment). Reflect the sharpened hypothesis back. -
Demand. Run a demand report on the sketch's brief (the
/demand-reportflow). This is the slow step — say so. -
Landscape. Call
landscape_from_report— competitors + existing solutions + the do-nothing cost. -
Assess. Call
assess_from_report(it runs landscape then the verdict). Present the GO/PIVOT/NO-GO honestly, with the gap (demand strength vs. saturation) and the evidence. -
The human decides. Show the computed recommendation, then ask the user via AskUserQuestion: GO, PIVOT, or NO-GO. They have context the corpus doesn't.
- GO → stop. Hand off to positioning / build.
- PIVOT → take the assessment's
pivot_target(the under-served fork) as the next idea and loop. Never re-propose a fork you've already killed — track what's been ruled out. - NO-GO → stop. Say plainly why; that's a real answer.
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.
- 2d ago First seen · 60 lines · 145 tokens per session scan A 07393f2b93a9
validate is a skill published in the GitHub repository Lab2A/metalworks (6 stars, last pushed 2mo ago), licensed MIT. It adds 145 tokens to every session and 919 once invoked, about $0.0007 per session on Opus 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 skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…