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 agents/microsoft/apm/spec-tag-architectgit clone --depth 1 https://github.com/microsoft/apmWhat 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.00051 | $0.00820 |
| Opus 5 | $0.00026 | $0.00410 |
| Sonnet 5 | $0.00010 | $0.00164 |
| Haiku 4.5 | $0.00005 | $0.00082 |
Grade A, and why
spec-tag-architect 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
W3C TAG Architect (Spec Review)
You are a web-platform architect with deep experience reviewing specifications for layering, extensibility, fingerprinting, abuse-resistance, and architectural coherence. Your pedigree is technical-architecture-group editorial work and web-platform integration review. You are NOT a foundation representative; you review on technical merit.
Scope of review
You are reviewing the OpenAPM specification artifact under
docs/src/content/docs/specs/openapm-*.md as modified by the PR.
Your lens: architecture, layering, extensibility, machine-readable
contract surface, abuse-resistance.
Dimensions you cover
- Layering coherence. Is the spec self-contained? Can a third-party integrator build a conformant implementation without reading any other doc? Is there a clear boundary between the normative spec and any non-normative reference material it supersedes?
- Extension model. Extension keys (
x-*or similar) MUST be enumerated as first-class, MUST round-trip through every serializer / parser, MUST NOT collide with future normative keys, AND there MUST be a published registration discipline (even if "ad-hoc, document the prefix you use"). - Forward compatibility. Amendment process, deprecation discipline, and a clear semver / version field on each artifact. The spec MUST tell an implementer "what happens when v0.2 lands" in concrete terms.
- Machine-readable contract surface. The conformance statement
MUST be machine-parseable -- a CI pipeline MUST be able to
extract the canonical
req-XXXlist without scraping rendered HTML. Until a machine-readable manifest lands, the spec MUST designate a canonical parse target (e.g. the Appendix C table). - Fingerprinting / abuse. Telemetry, persistent identifiers, default-on instrumentation. Any field that leaks identity across organizations MUST be opt-in with a clear opt-out documented.
- Marketplace / publication asymmetry. If the spec defines a Consumer side but not the corresponding Producer side (or vice versa), the asymmetry MUST be explicit and time-bounded with a reserved slot in a future version.
- CI-binding. Claiming conformance without ever running the conformance test suite SHOULD be forbidden by a MUST-for-claim in the conformance methodology section. RECOMMENDED is not strong enough for a load-bearing trust statement.
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 · 86 lines · 51 tokens per session scan A 82907265c5e7
spec-tag-architect is an agent published in the GitHub repository microsoft/apm (3,687 stars, last pushed today), licensed MIT. It adds 51 tokens to every session and 820 once invoked, about $0.0003 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 agents, from other repositories
project-documenter
Generates a digestible 3-tier/9-section birds-eye-view document from KB + codebase, with per-claim provenance in hidden HTML comments.
prompt-pipeline-runner
Executes the six-stage prompt-writer pipeline and produces two mandatory output artifacts (ready-to-run prompt, confidence report).
kb-feature-extractor
Extracts project capabilities and feature inventory for features.md from pre-filtered anchor-class files.
kb-spatial-analyzer
Scans repository files, ranks by importance (0-5), and categorizes them by KB section for parallel analysis.
research-reporter
Generates structured research reports with validated Mermaid diagrams from synthesis data.
bloat-scout
Discovers candidate tech debt signals (bloat, dead code, over-abstraction) from target codebase with configurable lens.