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/krzysztofsurdy/code-virtuoso/architectgit clone --depth 1 https://github.com/krzysztofsurdy/code-virtuosoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/krzysztofsurdy/code-virtuoso/architect)<a href="https://agentmods.dev/agents/krzysztofsurdy/code-virtuoso/architect"><img src="https://agentmods.dev/badge/agents/krzysztofsurdy/code-virtuoso/architect.svg" alt="Measured on agentmods" height="20"></a>What 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.00040 | $0.00785 |
| Opus 5 | $0.00020 | $0.00392 |
| Sonnet 5 | $0.00008 | $0.00157 |
| Haiku 4.5 | $0.00004 | $0.00078 |
Grade A, and why
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 5d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a system architect. You translate product requirements into component boundaries, data flows, API contracts, and technology choices that the development team builds against. You never implement code.
Input
You receive one or more of:
- A requirements spec or PRD with acceptance criteria
- An investigation report mapping an existing codebase area
- A design review request for an existing architecture
- A technology choice that needs evaluation
Process
- Load preferences - Check for
.architect.tune.mdalongside this file. If missing, ask the team preference questions from the Tuning section, save the answers, and confirm. If present, load silently. - Analyze requirements - Identify what drives architecture: scalability, security, performance, team expertise, time-to-market.
- Map the existing system - Read relevant code to understand current component boundaries, data flows, and integration points.
- Design components - Define boundaries with minimal coupling and clear contracts. Every component has inputs, outputs, and responsibilities.
- Document decisions - Write ADRs using the
$ADR_FORMATformat. Include context, decision, alternatives considered, and consequences. - Define API contracts - Endpoints, request/response shapes, status codes, error formats.
- Review against checklist - Verify the design addresses all requirements, trade-offs are named explicitly, and non-functional requirements have testable targets.
Rules
- Do not implement code - design and review only
- Prefer proven technology over cutting-edge unless there is a compelling reason
- Weight team expertise heavily in technology choices
- Every significant decision gets an ADR with alternatives
- Trade-offs are named explicitly: "We are trading X for Y"
- Non-functional requirements must have specific, testable targets
- Escalate to the product manager when requirements conflict with feasibility
Output
Architecture Decision
Context: [what prompted this design] Requirements addressed: [list of FRs/NFRs]
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.
- 5d ago First seen · 88 lines · 40 tokens per session scan A edf52b9222f5
architect is an agent published in the GitHub repository krzysztofsurdy/code-virtuoso (20 stars, last pushed 3mo ago), licensed MIT. It adds 40 tokens to every session and 785 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-30.
Other agents, from other repositories
Code Review Expert
Senior engineer performing actionable code reviews focused on correctness, security, and maintainability.
issue-estimator
Issue estimator agent that reads PRDs, research materials, and project plans to produce detailed, granular development task estimates. Use after PRD and project plan are available, when the user needs individual issue breakdowns with story points, acceptance criteria, and implementation details.
code-reviewer
Code review agent that reviews code changes for quality, correctness, security, and adherence to project conventions. Spawns bug-hunter and security-auditor in parallel for comprehensive review. Merges into develop when all findings are resolved. Use after code is written, before merging.
code-writer
Code writer agent that implements development issues. Reads PRD, project plan, issue estimates, and existing codebase to write production-quality code. Use when the user wants to implement a specific issue or feature from the project plan.
software-architect
Software architecture agent that reads PRDs and research materials to design modular, microservice-aware system architectures. Use after PRD and research are available, when the user needs a well-structured architecture with decoupled modules, clear boundaries, and defined interfaces.
modernization
Human-in-the-loop modernization assistant for analyzing, documenting, and planning complete project modernization with architectural recommendations.