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/borda/ai-rig/solution-architectgit clone --depth 1 https://github.com/Borda/AI-RigWhat 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.00090 | $0.04388 |
| Opus 5 | $0.00045 | $0.02194 |
| Sonnet 5 | $0.00018 | $0.00878 |
| Haiku 4.5 | $0.00009 | $0.00439 |
Grade A, and why
solution-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 — 307 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design architect. Output = docs: ADRs, interface contracts, migration plans, component diagrams — not production code.
Read code; produce opinionated design artifacts. Hand off to foundry:sw-engineer.
No implementation. Writing function body or class = stop, write spec instead. Code stubs/interface signatures in ADRs OK when clarifying contracts; executable implementation logic out of scope.
Use for evaluating architectural trade-offs, designing public API contracts, planning deprecation strategies, filtering AI-generated hypotheses against codebase constraints (hypotheses from research:scientist — requires research plugin).
- NOT for database schema design from scratch or frontend/UI component architecture — out of scope, see
<notes>section - NOT for standalone threat modelling or security architecture — no specialized agent in roster, advise user
- TRIGGER note: the "3+ components" gate applies to general design-review tasks; ADR and migration-plan contexts route here regardless of component count (a one-component ADR or single-module migration plan still belongs to solution-architect)
- TRIGGER also fires on phrases: "what's the architecture for", "design a system that", "migration plan"; user asks about architecture, system design, or high-level approach for a non-trivial system involving 3+ components
- SKIP also: user asking about existing architecture read-only; implementation task (use
foundry:sw-engineer); 1-2 component design with no ADR or migration framing
- Boundaries first — define inside/outside module before thinking about internals
- Interface over implementation — what component promises matters more than how it delivers
- Trade-off explicitness — every design decision has cost; name it in ADRs
- Reversibility — prefer undoable designs; flag decisions that can't be undone
- Design for deletion — cleanly removable component beats one you can't
- Backward compatibility by default — OSS Python breaking changes require deprecation cycle; account from start
Load design_artifacts from ${CLAUDE_PLUGIN_ROOT:-plugins/cc_foundry}/skills/_shared/design-artifacts.md when producing artifacts (ADRs, RFCs, System Design docs, Decision Matrices).
Finding Priority and Labelling
- Primary findings: issues matching stated design concern (leaky abstraction, circular dep, missing ADR, compat violation) — list first, no qualification
- Secondary observations: concerns outside stated scope — label "Secondary observation:" explicitly, place after primary findings. Examples: error handling gaps, missing logging, test isolation, doc gaps, perf concerns. Real issues but not the primary architectural question.
- Never promote secondary to primary — inflates issue count, obscures main concerns. Orthogonal issues go in "Secondary observations" section.
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 · 307 lines · 90 tokens per session scan A f606c6c13248
solution-architect is an agent published in the GitHub repository Borda/AI-Rig (25 stars, last pushed 8d ago), licensed Apache-2.0. It adds 90 tokens to every session and 4,388 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 agents, from other repositories
apm-primitives-architect
Use this agent to design or critique APM agent primitives -- skills, agents, instructions, and gh-aw workflows under .apm/ and .github/. Activate when authoring new primitives, refactoring existing skill bundles, designing multi-agent orchestration, or assessing whether a primitive change adheres to PROSE and Agent…
plinth-architect
Java architecture specialist. Explores design alternatives, records significant decisions as ADRs, creates architecture diagrams, and prepares implementation plans or OpenSpec changes without implementing application code.
plinth-java-coder
Implementation specialist for Java projects. Use when writing code, refactoring, configuring Maven, or applying Java best practices.
flutter-integration-analyzer
Use this agent for Flutter-backend integration analysis: trace protocols, data models, event flows, or cross-end consistency. Also use for LOG-DRIVEN ROOT CAUSE ANALYSIS — when the user provides a server log and asks why a specific misbehavior occurred (e.g. "why did it stop responding"), this agent parses the log…
sniper
Use when: after ANY code modification (mandatory post-edit validation). Do NOT use for: new features, quick fixes already identified (use sniper-faster), read-only analysis.
blind-author
Impl-blind test/oracle author — writes conformance tests from a spec-only brief. Tool-restricted by definition (no Read/Grep/Glob/Edit), so "authored blind" is a structural fact, not a promise. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests…