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 dougstanford/living-manual --skill ticketgit clone --depth 1 https://github.com/dougstanford/living-manualWrote 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/dougstanford/living-manual/ticket)<a href="https://agentmods.dev/skills/dougstanford/living-manual/ticket"><img src="https://agentmods.dev/badge/skills/dougstanford/living-manual/ticket/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/dougstanford/living-manual/ticket"><img src="https://agentmods.dev/badge/skills/dougstanford/living-manual/ticket.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.00094 | $0.01548 |
| Opus 5 | $0.00047 | $0.00774 |
| Sonnet 5 | $0.00019 | $0.00310 |
| Haiku 4.5 | $0.00009 | $0.00155 |
Grade A, and why
ticket 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 12d 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Note → ticket
Input: a <submission> block pasted from the manual's "Make a note"
modal (source, section, target, type, summary, details, and optionally
relates-to / roadmap fields), or a free-form report. One ticket per
submission unless it clearly contains independent requests.
Config: .living-manual.json at repo root supplies tickets_dir,
manual_path, and tracker. Prose follows the plugin's
reference/writing-style.md. $LM below is the plugin root; this
file lives at $LM/skills/ticket/SKILL.md.
Targets
target: current behavior→ a ticket against the shipped app.target: roadmapped work→ a plan-revision ticket. Ground in the named roadmap source and planned-state text, write stories, requirements, and criteria as deltas to the plan, and surface any conflict with the plan's intent as an open question. Never write it as a change to today's implementation.
Enforce the routing for free-form reports too: a complaint about behavior that a planned item already replaces becomes a plan-revision ticket against that item, stated in the summary.
Procedure
-
Ground first. Read the named manual section, the code behind it, and the project's planning docs. Every claim about current behavior must be verifiable in code or docs.
-
Classify honestly. Designed-but-frustrating behavior is feedback naming the governing decision, not a bug. Reclassify a mislabeled submission and say so in the ticket.
-
Check for collisions: existing tickets in
tickets_dir, planned items, roadmap docs. Duplicate of a queued ticket → treat as an addition (below) and tell the user. Covered by planned work → scope the ticket to the delta only. -
Number it:
sh $LM/scripts/next-ticket.sh <tickets_dir>. -
Write
<tickets_dir>/TICKET-NNNN-<slug>.md:--- id: TICKET-NNNN title: <one line> type: idea | feedback | bug target: current | roadmap:<item-id> status: ready | needs-answers (later: shipped | declined) section: <manual section + anchor> created: <YYYY-MM-DD> issue: <tracker ref, when synced: ABC-123 or owner/name#42> --- ## Summary ## Origin (submission verbatim, fenced) ## Current behavior (or "Planned behavior" for roadmap tickets; with file refs) ## User stories (As a / I want / so that; every FR traces to one) ## Functional requirements (FR-1...; each testable and unambiguous) ## Acceptance criteria (Given/When/Then; together they cover every FR) ## Open questions (required when status is needs-answers) ## References
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.
- 12d ago First seen · 130 lines · 94 tokens per session scan A d1312142a82b
ticket is a skill published in the GitHub repository dougstanford/living-manual (3 stars, last pushed 1mo ago), licensed MIT. It adds 94 tokens to every session and 1,548 once invoked, about $0.0005 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-31.
Other skills, from other repositories
plan
Research the codebase and create an implementation plan following Propose/Justify/Recommend. Use this before any feature, fix, or refactor.
multi-perspective-review
Multi-perspective collaborative review of plans or documents. Ten expert viewpoints deliberate in 3 rounds to reach consensus.
review
Run a full code review on current changes or specified files. Runs ruff lint, review-code agent, and security scan in sequence.
plan-task
Structured task planning using Work files. Use for any new feature, bug fix, or project that needs a task breakdown before implementation.
journey-simulation
Use when caller wants to observe how a stranger encounters a flow, artifact, or sandbox — triggers like "simulate a user journey", "test our onboarding / checkout / signup", "will my ICP convert", "how does a cold reader experience this README", "first-time user test", "cognitive walkthrough", or any request to…
brainstorming
Design and spec before any planning or code. MUST USE before new features, creative work, or any implementation. Explores requirements, proposes approaches, gets design approval, then chains to plan-task.