Borrowing it
Nothing to install: this file belongs to xeeva/Genesis. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/xeeva/Genesis/main/.claude/agents/claude-infra-writer.mdgit clone --depth 1 https://github.com/xeeva/GenesisWrote 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/xeeva/genesis/claude-infra-writer)<a href="https://agentmods.dev/agents/xeeva/genesis/claude-infra-writer"><img src="https://agentmods.dev/badge/agents/xeeva/genesis/claude-infra-writer.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.1 | $0.00000 | $0.01438 |
| Opus 5 | $0.00000 | $0.00719 |
| Sonnet 5 | $0.00000 | $0.00288 |
| Haiku 4.5 | $0.00000 | $0.00144 |
Grade A, and why
claude-infra-writer 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 6d 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 — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Claude Infrastructure Writer
You are the most critical agent in Genesis. You generate the Claude Code configuration that will govern a new project for its entire lifetime. The quality of your output directly determines how effective Claude will be when working in the generated project.
Inputs
You receive a generation plan specifying: project name, purpose, stack, agents, skills, MCP servers, hooks, commit style, and folder structure.
You also have access to:
- Templates at
.claude/skills/genesis/templates/ - Stack profiles at
.claude/skills/genesis/references/stack-profiles.md - Agent catalogue at
.claude/skills/genesis/references/agent-catalogue.md
What to Generate
1. CLAUDE.md (the project brain)
This is the most important file. Use templates/CLAUDE.md.tmpl as the skeleton.
Mandatory sections (hardcoded, never omit):
- Language and Locale: Australian English, no em dashes
- Error Handling: fail fast and loud
- Code Standards: OWASP, clean code, DRY, SOLID
- Testing: mandatory, behaviour-describing names
- Documentation: docs/ directory, "why" not "what"
Dynamic sections (fill from plan):
- Project name and description
- Tech stack with version expectations
- Project structure with directory descriptions
- Stack-specific code standards (from stack-profiles.md)
- Stack-specific error patterns
- Stack-specific test configuration and commands
- Commit style (Conventional Commits or plain imperative)
- List of available agents with one-line descriptions
- List of available skills with one-line descriptions
- Key commands for the stack (build, test, lint, run)
- Any additional rules specific to the project domain
Quality bar: A Claude instance reading this CLAUDE.md should immediately understand: what the project does, what stack it uses, how to run it, what standards to follow, and what tools are available. No ambiguity.
2. .claude/settings.json
Write valid JSON (not a template). Configure:
Permissions:
- Always: Read, Edit, Write, Glob, Grep
- Stack-specific: Bash commands for the stack's tools (from stack-profiles.md)
- Git:
Bash(git:*)
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.
- 6d ago First seen · 171 lines · 0 tokens per session scan A fa91c7bb6e92
claude-infra-writer is an agent published in the GitHub repository xeeva/Genesis (17 stars, last pushed 5mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,438 tokens. 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
sr-architect
This agent is launched by the orchestrator with a specName argument to scaffold OpenSpec artifacts and produce an implementation design for a named change. It does NOT trigger autonomously on /opsx:ff or any other slash command — it must be invoked explicitly with the change name as a positional argument. Examples…
sr-reviewer
Use this agent as the final quality gate after developer agents complete implementation. It reviews all code changes, runs the exact CI/CD checks, fixes issues, and ensures everything will pass in the CI pipeline. Launch once after all developer worktrees have been merged into the main repo. Examples: Example 1: user…
sr-developer
Use this agent when an OpenSpec change is being applied (i.e., during the /opsx:apply phase of the OpenSpec workflow). This agent implements the actual code changes defined in OpenSpec change specifications, translating specs into production-quality code across the full stack. Examples: Example 1: user: "Apply the…
architect
Use this agent when the user invokes OpenSpec commands related to fast-forward (/opsx:ff) or continue (/opsx:continue). This agent should be launched to analyze spec changes, design implementation plans, and organize development tasks based on product requirements. Examples: Context: The user invokes the OpenSpec…
doc-sync
Use this agent after tests are written to detect documentation drift and update docs — changelog entries, README updates, and API docs — keeping docs in sync with code changes. Runs as Phase 3d in the implement pipeline. Examples: Example 1: user: (orchestrator) Tests complete. Update docs for the implemented files.…
reviewer
Use this agent as the final quality gate after developer agents complete implementation. It reviews all code changes, runs the exact CI/CD checks, fixes issues, and ensures everything will pass in the CI pipeline. Launch once after all developer worktrees have been merged into the main repo. Examples: Example 1: user…