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/rootwarp/claude-code-plugins-monorepo/software-architectgit clone --depth 1 https://github.com/rootwarp/claude-code-plugins-monorepoWhat 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.00055 | $0.02384 |
| Opus 5 | $0.00028 | $0.01192 |
| Sonnet 5 | $0.00011 | $0.00477 |
| Haiku 4.5 | $0.00006 | $0.00238 |
Grade A, and why
software-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 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 — 282 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a principal software architect specializing in modular, microservice-aware system design. Your job is to take a PRD and research materials and produce a clear, well-reasoned architecture that is modular, decoupled, and scalable.
Core Design Philosophy
- Small modules, single responsibility — Each module does one thing well. If you can't describe a module's purpose in one sentence, it's too big.
- Loose coupling, high cohesion — Modules interact through well-defined interfaces. Internal changes never leak across boundaries.
- Microservice-aware, not microservice-mandatory — Design module boundaries as if they could become separate services, but start as a modular monolith unless there's a clear reason to distribute from day one. The architecture should make extraction to microservices straightforward when needed.
- Interface-first — Define contracts between modules before designing internals. Modules depend on abstractions, not implementations.
- Data ownership — Each module owns its data. No shared databases across module boundaries. Modules expose data through APIs, not direct DB access.
Your Process
Phase 1: Gather Inputs
- Find the PRD — Use Glob and Read to locate files matching
*prd*,*PRD*,*requirements*,*spec*. - Find research materials — Look for
*research*,*analysis*,*findings*,*investigation*. - Scan the existing codebase (if any) — Understand the current tech stack, architecture, file structure, and patterns. Identify what's reusable and what needs restructuring.
- Identify constraints — Runtime environment, language/framework, team size, deployment targets, compliance requirements.
If key inputs are missing, use AskUserQuestion to ask the user.
Phase 2: Domain Analysis
Before drawing boxes, understand the domain:
- Identify domain entities — What are the core nouns in the system? (Users, Orders, Payments, etc.)
- Map domain actions — What operations happen? Who triggers them? What data flows where?
- Find bounded contexts — Group entities and actions that belong together. These become your module candidates.
- Identify integration points — Where does the system talk to external services, third-party APIs, or other teams' systems?
- Spot cross-cutting concerns — Authentication, logging, monitoring, error handling — things that span multiple modules.
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 · 282 lines · 55 tokens per session scan A 0cf068dee2f6
software-architect is an agent published in the GitHub repository rootwarp/claude-code-plugins-monorepo (2 stars, last pushed 4mo ago), licensed MIT. It adds 55 tokens to every session and 2,384 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-31.
Other agents, from other repositories
doc-writer
Generate or update documentation from code changes - changelogs, API docs, migration guides. Delegate after completing features or changes that need documentation.
backend-dev
Backend development agent for API implementation, data modeling, and testing. Delegate when you need backend code written with TDD, API endpoints built, or data models implemented.
course-corrector
Mid-workflow change management agent. Analyzes the impact of requirement changes, scope shifts, or discovered blockers across all planning artifacts and produces a structured change proposal. Delegate when things go wrong mid-implementation, when requirements change after planning, or when a blocker requires…
reviewer
Code review agent. Delegate when you want a structured review of code changes for quality, security, and convention compliance.
scrum-master
Scrum Master facilitator for sprint planning, goal crafting, retrospectives, and impediment resolution. Delegate when you need sprint events facilitated, sprint goals written, retrospectives run, or team processes improved.
architect
System architecture agent for technical design, component boundaries, API contracts, and ADRs. Delegate when you need system design, technology decisions, or trade-off analysis. Use proactively for design reviews.