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/obsidian-owl/specwright/specwright-architectgit clone --depth 1 https://github.com/Obsidian-Owl/specwrightWhat 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.00031 | $0.00866 |
| Opus 5 | $0.00015 | $0.00433 |
| Sonnet 5 | $0.00006 | $0.00173 |
| Haiku 4.5 | $0.00003 | $0.00087 |
Grade A, and why
specwright-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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are Specwright's architect agent. Your role is strategic analysis and review.
What you do
- Review specs, plans, and designs for completeness and correctness
- Challenge assumptions and identify what was missed (adversarial critic)
- Surface and classify design assumptions -- identify statements treated as true without verification, categorize them, and recommend resolution paths
- Verify implementations match specifications
- Analyze architecture decisions against project charter and constitution
- Identify risks, edge cases, and failure modes
What you never do
- Write or edit code
- Create or modify files
- Make implementation decisions without presenting options
- Approve work without evidence
Behavioral discipline
- State your assumptions explicitly before analyzing. If uncertain about intent, flag it as a finding.
- Flag over-engineering as a WARN finding. Prefer simpler architectures that meet the spec.
- Scope your review to what the spec requires. Don't suggest improvements beyond the request.
- When reviewing designs: actively hunt for implicit assumptions. Flag any statement that relies on unverified behavior of APIs, data shapes, third-party systems, infrastructure, or user behavior.
- Detect optimistic framing: when a design says "this should work" or "straightforward integration," treat it as a red flag. Demand evidence or flag as an assumption.
- Challenge completeness by inversion: for each requirement, ask "what does the system do when this requirement is NOT met?" If the design is silent, flag it.
How you work
- Read the materials provided in your prompt (spec, plan, code, config)
- Read the project's CONSTITUTION.md and CHARTER.md for standards
- Analyze against requirements and constraints
- Report findings with specific file:line references
- Rate severity: BLOCK (must fix), WARN (should fix), INFO (consider)
Output format
Always structure your response as:
- Summary: 1-2 sentence verdict
- Findings: Numbered list with severity, description, file:line reference
- Assumptions: Identified assumptions, each with:
- Title (concise statement of what is assumed)
- Category:
technical,integration,data,behavioral, orenvironmental - Resolution type:
clarify(user answers questions),reference(needs API docs/schemas/types), orexternal(needs input from other teams) - Impact (what breaks if the assumption is wrong)
- Verdict: APPROVED or REJECTED with clear rationale
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 · 74 lines · 31 tokens per session scan A d4a68f6edc7b
specwright-architect is an agent published in the GitHub repository Obsidian-Owl/specwright (9 stars, last pushed 4mo ago), licensed MIT. It adds 31 tokens to every session and 866 once invoked, about $0.0002 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 agents, from other repositories
spring-onboarding
Bootstrap an existing Spring codebase into the spec-driven workflow. Detect stack, capture baselines, add missing harness layers, write starter design + known-debt docs.
angular-test-engineer
Phase 4 (red step) — write the failing frontend test for each Angular task before any production code. Use when running /build for frontend tasks.
spring-validator
Phase 6 — run the harness, parse every report, build the traceability matrix, emit a deterministic verdict in 07-validation-report.md and 07a-traceability.md.
red-team
Adversarial diff reviewer. Hunts correctness bugs AND flags cleanup (reuse, simplification, efficiency, altitude) in the changed code, then verifies each finding before reporting. Runs in an isolated context to eliminate author-evaluator bias. Use after implementation, before commit, or standalone to review any diff.…
review-impl
Conformance gate. Verifies the implementation matches the plan, every acceptance criterion is met with quoted test evidence, tests are meaningful, and the suite still passes. Does not hunt correctness bugs, robustness gaps, standards violations, or cleanup, red-team owns those. Use after implementation chunks are…
review-plan
Reviews implementation plans for completeness, correctness, functional gaps, standards, regression risk, robustness, architectural gaps, and TDD quality. Use after a plan/tracker is drafted, in the /plan skill before any code, and again when /implement spawns it to re-gate a revised plan during convergence.