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 skills add martineserios/thebrana --skill docsgit clone --depth 1 https://github.com/martineserios/thebranaWrote 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/skills/martineserios/thebrana/docs)<a href="https://agentmods.dev/skills/martineserios/thebrana/docs"><img src="https://agentmods.dev/badge/skills/martineserios/thebrana/docs/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/skills/martineserios/thebrana/docs"><img src="https://agentmods.dev/badge/skills/martineserios/thebrana/docs.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.00027 | $0.02421 |
| Opus 5.5 | $0.00011 | $0.00968 |
| Sonnet 5.5 | $0.00005 | $0.00484 |
| Haiku 4.5 | $0.00003 | $0.00242 |
Grade A, and why
docs 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.
How it starts
The opening of the file, as written. The whole thing — 279 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Living Documentation
Generate and update project documentation from build context. Works standalone or as a building block invoked by other skills (CLOSE, reconcile).
When to use
- After building a feature — generate tech doc + user guide
- After
/brana:buildCLOSE step — invoked automatically viaall - Manually — update philosophy, regenerate stale docs, or fill doc gaps
- From other skills — any skill can invoke
/brana:docsfor its doc needs
Subcommands
/brana:docs tech [task-id] — generate/update tech doc for a feature
/brana:docs guide [task-id] — generate/update user guide for a feature
/brana:docs overview — update philosophy.md with latest patterns
/brana:docs all [task-id] — run tech + guide + shared doc updates + overview
/brana:docs tech
Generate or update a technical architecture doc for a feature.
Input sources
Gather context from (in priority order):
- Task metadata (if task-id provided):
backlog_get(task_id: "{task-id}")(MCP) orbrana backlog get {task-id}— subject, description, context, strategy, tags - Git diff:
git diff main...HEAD --stat— what files changed - Feature spec: check
docs/architecture/features/for existing spec matching the task slug - Design decisions: from task context field and any ADRs created during the build
Output
Write to docs/architecture/features/{feature-slug}.md with these sections:
| Section | Contents |
|---|---|
## Goal |
What the feature does and the problem it solves |
## Design Decisions |
Choices made and why, linking any ADRs |
## Code Flow |
Entry points and the path through the code |
## Testing |
What is covered, and how to run it |
Steps
- Gather input sources (parallel where possible)
- If a tech doc already exists for this feature:
- Read it
- Show diff preview of proposed changes
- Ask: "Update existing doc?" via AskUserQuestion — options: "Show diff preview (Recommended)", "Apply changes directly"
- If no doc exists:
- Fill template from gathered context
- Write the file
- Report: "Tech doc written:
docs/architecture/features/{slug}.md"
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 · 279 lines · 27 tokens per session scan A 813c303357eb
docs is a skill published in the GitHub repository martineserios/thebrana (3 stars, last pushed 4d ago), licensed MIT. It adds 27 tokens to every session and 2,421 once invoked, about $0.0001 per session on Opus 5.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-09-03.
Other skills, from other repositories
document-writer
Write or update technical documentation grounded in the real codebase. Use when the user asks for README, API docs, architecture guides, user guides, CONTRIBUTING docs, migration notes, or JSDoc/code comments, or wants technical docs rewritten into natural Chinese with correct terminology. Not for general prose…
reviewer
Validate proposals before implementation and generate ADR/PR documentation. Forces structured review of plans, architecture decisions, and code changes before executing. Use when making significant changes, starting new features, refactoring, or when uncertainty exists. Triggers on: review this, validate, does this…
help
Use when asked what the capstone plugin can do - prints the usage block.
start
Use when the user says just "capstone" with nothing else, or asks to start or continue the capstone pipeline - runs the greenfield chain one stage at a time, detecting completed stages and resuming at the first incomplete one. A stage word as the argument (mockup, logic, uiux, architecture, standards, stack, build)…
feature
Use when the user wants one feature taken from idea to working code - "add a feature", "build X end to end", "take X from idea to shipped" - runs the feature chain groom → plan → implement consecutively, detecting the feature's stage and resuming at the first incomplete one. For the whole-product greenfield pipeline…
review
Use when asked for an opinionated review of the codebase - architecture/backend findings, UI findings against the project's own design docs, or both - severity-ranked with evidence, written to docs/capstone/review.md. Bare "review" does both sides; "review backend" or "review frontend" does one. "review retro…