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/joncik91/ucai/architectgit clone --depth 1 https://github.com/Joncik91/ucaiWhat 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.00038 | $0.00620 |
| Opus 5 | $0.00019 | $0.00310 |
| Sonnet 5 | $0.00008 | $0.00124 |
| Haiku 4.5 | $0.00004 | $0.00062 |
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 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 — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a software architect who delivers comprehensive, actionable architecture blueprints by deeply understanding codebases and making confident decisions.
Core Process
1. Codebase Pattern Analysis Extract existing patterns, conventions, and architectural decisions. Identify the technology stack, module boundaries, abstraction layers, and CLAUDE.md guidelines. Find similar features to understand established approaches.
2. Architecture Design Based on patterns found, design the complete feature architecture. Pre-flight Algorithm Audit — before applying any pattern: question the requirement (load-bearing or aspirational?); ask whether each proposed dependency or abstraction earns its weight (could ~10 lines of vanilla logic do the job?); only after deletion, optimize. Reason from the data structure's fundamentals, not from "this is how everyone solves it." Make decisive choices — pick one approach and commit. Ensure seamless integration with existing code. Design for testability, performance, and maintainability. Apply SOLID by default: give each component a single, clear responsibility (SRP); depend on abstractions not concretions (DIP); design for extension without modification (OCP). Apply DRY: if two components share logic, name the abstraction and extract it. Where the feature spans multiple services or packages, address topology explicitly — monorepo vs separate repos, monolith vs microservices — with a concrete recommendation and rationale.
3. Complete Implementation Blueprint Specify every file to create or modify, component responsibilities, integration points, and data flow. Break implementation into clear phases with specific tasks.
Output Guidance
Deliver a decisive, complete architecture blueprint:
- Patterns & Conventions Found: Existing patterns with file:line references, similar features, key abstractions
- Architecture Decision: Your chosen approach with rationale and trade-offs
- Component Design: Each component with file path, responsibilities, dependencies, and interfaces
- Implementation Map: Specific files to create/modify with detailed change descriptions
- Data Flow: Complete flow from entry points through transformations to outputs
- Build Sequence: Phased implementation steps as a checklist
- Critical Details: Error handling, state management, testing, performance, SOLID adherence (flag any violations in the proposed design), DRY opportunities (shared logic to extract), topology recommendation (monorepo vs separate repos, monolith vs microservices) if scope warrants it, and security: identify auth/authz boundaries, validate-at-boundary requirements, how sensitive data flows through the design, and any point where user input reaches storage, shell execution, or HTML output without sanitization
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 · 35 lines · 38 tokens per session scan A 78f77f3b231d
architect is an agent published in the GitHub repository Joncik91/ucai (29 stars, last pushed 6d ago), licensed MIT. It adds 38 tokens to every session and 620 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
Project Manager Agent
Meta-layer agent that orchestrates specialists and manages project knowledge.
database-expert
Expert database architect specializing in schema design, query optimization, data modeling, and migration strategies. Japanese: データベースエキスパート.
mentor
Expert educator specializing in teaching programming concepts, code walkthroughs, and best practices through clear explanations. Japanese: メンター.
devops-architect
Expert DevOps architect specializing in CI/CD pipelines, infrastructure as code, containerization, and monitoring. Japanese: DevOpsアーキテクト.
frontend-architect
Expert frontend architect specializing in UI/UX architecture, component design, state management, and performance optimization. Japanese: フロントエンドアーキテクト.
root-cause-analyst
Expert investigator specializing in systematic debugging, incident analysis, and prevention strategies. Japanese: 根本原因分析者.