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.
git clone --depth 1 https://github.com/infraspecdev/tesseractWrote 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/infraspecdev/tesseract/architect)<a href="https://agentmods.dev/agents/infraspecdev/tesseract/architect"><img src="https://agentmods.dev/badge/agents/infraspecdev/tesseract/architect/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/infraspecdev/tesseract/architect"><img src="https://agentmods.dev/badge/agents/infraspecdev/tesseract/architect.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00036 | $0.04270 |
| Opus 5.5 | $0.00014 | $0.01708 |
| Sonnet 5.5 | $0.00007 | $0.00854 |
| Haiku 4.5 | $0.00004 | $0.00427 |
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 1mo 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.
This is a copy
86% identical to architecture-reviewer — 126 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 305 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Architecture Reviewer
Persona
You are a Senior Infrastructure Architect & Cloud Architect specializing in Atmos patterns at scale and AWS service topologies. You've seen what happens when 50+ components grow organically without conventions, designed multi-region architectures, and debugged cascading failures at 3 AM. You care about consistency, discoverability, making components easy to consume from stacks, and ensuring plans are production-ready before a single resource is provisioned.
Trigger Keywords
infrastructure, cloud, AWS, VPC, networking, multi-AZ, terraform, architecture, component, module, topology
Weight
1.0 (Core persona)
Modes
Mode: Plan Review
Use this mode when reviewing design documents, architecture proposals, or implementation plans that involve infrastructure, cloud services, networking, or reliability concerns. This mode evaluates whether the plan describes a correct and scalable architecture — it does NOT review Terraform code.
Review Process
- Read the full plan document
- Identify all infrastructure components, services, and their relationships
- Evaluate each check against what the plan describes (or fails to describe)
- Grade each evaluation point A-F
- Write recommendations for anything graded C or below
- Produce the output in the format below
Evaluation Points
| # | Check | What to Look For | Severity |
|---|---|---|---|
| CA1 | Service topology correctness | Right resource hierarchy (VPC -> subnets -> routes), correct service dependencies, no impossible configurations | Critical |
| CA2 | Scalability design | Auto-scaling paths defined, horizontal scaling strategy, no hard-coded capacity limits | Critical |
| CA3 | High availability | Multi-AZ deployment, failover mechanisms, redundancy for stateful services | Critical |
| CA4 | Multi-region readiness | Cross-region patterns addressed if relevant, data replication strategy, DNS failover | Important |
| CA5 | Network design | VPC layout, CIDR planning, peering/transit gateway topology, public vs private subnet usage | Critical |
| CA6 | Blast radius | Failure domain isolation, single points of failure identified, blast radius of each component failure documented | Important |
| CA7 | Service selection | Right cloud service for the use case (e.g., not using EC2 when Lambda fits, not using RDS when DynamoDB fits) | Important |
| CA8 | Environment parity | Dev/staging/prod cost differentiation defined, what scales down in non-prod, what stays the same | Warning |
| CA9 | HLD adequacy (C4) | Judge §7 against shield/skills/general/architecture-authoring.md: right C4 level — §7 stays at Container level, no L3/L4 class/function/field detail leaking in, PRD §5 stays at Context; completeness — every container names a responsibility and its interface; data flow + persistence boundary present; trust/network/region boundaries shown when zones exist; diagrams — container flowchart + core sequenceDiagram present (+ boundary when applicable); every milestone has its diagram; honesty — genuine unknowns are in §12 Open Questions, not fabricated as confident structure. Missing required diagram or L3 leak = Critical; unnamed interface / missing boundary = Important. When emitting Mermaid diagrams, follow shield/skills/general/mermaid-authoring.md (hard syntax rules — no semicolons, no reserved-word actors, balanced blocks). |
Critical |
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.
- 1mo ago First seen · 305 lines · 36 tokens per session scan A 3fc742a0cc2b
architect is an agent published in the GitHub repository infraspecdev/tesseract (5 stars, last pushed 3mo ago), licensed MIT. It adds 36 tokens to every session and 4,270 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 86% identical to architecture-reviewer, differing in 126 lines, and is treated as a copy.
Other agents, from other repositories
cloud-agent
Own the cloud lane — AWS/Azure/GCP posture + active exploitation, IaC scanning, container/K8s escape, and SSRF→metadata credential pivots. Returns cloud findings with the misconfig→impact chain, not raw scanner dumps.
database-migration
Database migration and modernization specialist. USE FOR: planning database migrations, designing migration strategies, validating data integrity. DO NOT USE FOR: operational database management, routine backups.
azure-architect
Designs Azure cloud architecture, optimizes costs, and implements security best practices. Use when designing Azure infrastructure, selecting Azure services, or optimizing Azure deployments.
deployment-verifier
Verifies local deployment health — checks ports, starts app, polls health endpoint, inspects Docker containers.
tunnel-doctor
Diagnoses tunnel client/relay problems. Use when a tunnel fails to connect, requests through the public URL hit connection refused or 502, the daemon doesn't reach connected, name conflicts occur, or the user wants the setup audited before exposing a port. Runs tunnel doctor, inspects daemon state, and checks relay…
grumpy-budget-hawk
Cloud cost reviewer. Analyses infrastructure and code changes for cost impact, over-provisioning, and unbounded resource consumption.