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/friedbotstudio/baseline/spec-syncnpx skills add friedbotstudio/baseline --skill spec-syncgit clone --depth 1 https://github.com/friedbotstudio/baselineWhat 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.00094 | $0.00802 |
| Opus 5 | $0.00047 | $0.00401 |
| Sonnet 5 | $0.00019 | $0.00160 |
| Haiku 4.5 | $0.00009 | $0.00080 |
Grade A, and why
spec-sync 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 yesterday.
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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
spec-sync — derive the central system spec, then have a human curate it
A project adopting the baseline has no spec archive to migrate from. Measured on this repository, 68% of governed files appear in no spec at all — and a project that never ran the spec phase has none. So the corpus is rebuilt from code, not imported.
What the machine does and what the human does is the whole design:
| Step | Owner |
|---|---|
| Scan the governed surface, cluster by directory, propose a concept map | machine |
| Confirm or edit that map | human, always |
| Materialize elements, derive edges, stamp digests, report coverage gaps | machine |
Prereq
project.json → memory.architecture_map.enabled is true and
memory.architecture_map.governed_surface declares this project's roots. An absent
surface is a named error, never a default — a fallback would model the consumer's
.claude/ and report total coverage over a surface that is not theirs.
Steps
-
Check the flag.
node .claude/skills/workspace/cli.mjs flags # gates on memory.architecture_map.enabled — read the `architecture_map:` linefalse→ stop and tell the user to enable it (and declare a governed surface) first. -
Propose the map.
node .claude/skills/workspace/cli.mjs sync --json # wraps workspace/sync.mjs -> proposeMap (propose half only; runSync is not exposed)The proposal is a starting point, not an inference to trust. Directory clustering is deliberately plain because a human edits it next.
-
Have the human confirm it — always. Present the proposed concepts via
AskUserQuestion: which clusters are real concepts, which should merge, which should split, what each is called. Concept membership is authored; this step has no skip and no--yes. An unattended run that inferred membership would undo the rule every prior decision in this lineage protects. -
Materialize what was confirmed.
runSyncwrites the confirmed concepts, derives one element per anchor, stamps digests, and returns coverage gaps. It refuses outright when no confirmation callback is supplied, and writes nothing before confirmation returns — a refused sync leaves the corpus byte-identical.
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.
- yesterday First seen · 73 lines · 94 tokens per session scan A 0ff4d4762b58
spec-sync is a skill published in the GitHub repository friedbotstudio/baseline (11 stars, last pushed 5d ago), licensed Apache-2.0. It adds 94 tokens to every session and 802 once invoked, about $0.0005 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-30.
Other skills, from other repositories
dev-standards
Enforces development workflows, quality gates, coding standards, and release processes for the deterministic-agent-control-protocol project. Use when implementing features, fixing bugs, refactoring architecture, adding integrations, updating policies, writing tests, updating documentation, or preparing releases.
code-review-with-lsp
Code review with LSP-powered code intelligence. Uses MCP tools (diagnostics, hover, references, definition, symbols) for semantic code understanding, not just text grep.
i18n-check
国际化完整性检查。检查翻译 key 是否缺失、硬编码文本、locale 文件一致性。.
vue-best-practices
Vue 2/3 代码规范检查。包括组件命名、Props 校验、Composition API 规范等。.
python-review
Python 遗留代码审查：bare except、SQL 注入、反序列化、密钥、调试输出.
rust-review
Rust 服务审查：panic、SQL 注入、密钥、错误吞没、遗留标记.