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 skills/marcusrbrown/systematic/generating-project-docsnpx skills add marcusrbrown/systematic --skill generating-project-docsgit clone --depth 1 https://github.com/marcusrbrown/systematicWhat 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.00035 | $0.02391 |
| Opus 5 | $0.00017 | $0.01196 |
| Sonnet 5 | $0.00007 | $0.00478 |
| Haiku 4.5 | $0.00003 | $0.00239 |
Grade A, and why
generating-project-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 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 — 173 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Generating Project Documentation
Overview
This plugin's documentation describes a live system whose surface (skills, agents, config schema, CLI) keeps changing. Generated docs go stale fast.
Core principle: Derive every fact from the live repository. Preserve the existing document's evolved structure. Never regress to a generic template.
If you cannot point at a file or command that justifies a sentence, do not write it.
When to Use
- Refreshing
README.mdafter new skills, agents, or features land - Fixing documentation drift (counts, structure, CLI output, runtime claims)
- Updating
ARCHITECTURE.mdorSTRUCTURE.mdwhen the codebase layout changes - Adding or refreshing a scoped section (e.g. only the "Quick Install" block)
When NOT to Use
- Writing planning docs (
docs/plans/,docs/brainstorms/) — those follow their own templates - Authoring skill or agent files — those have their own format rules
Arguments
$ARGUMENTS
- Empty or
readme— UpdateREADME.md(default) architecture— UpdateARCHITECTURE.mdstructure— UpdateSTRUCTURE.mdall— Update all three docs<section-name>— Update only that named section within the target doc (e.g.skills,agents,cli)
For scoped updates: read the current document, locate the section by heading, replace only that section's content. Preserve surrounding structure exactly.
Pre-Generation Inventory
Before writing anything, gather these from the live repo:
| Source | What to extract |
|---|---|
package.json |
name, version, description, scripts, repository URL |
bun src/cli.ts list skills 2>/dev/null |
exact skill count and names |
bun src/cli.ts list agents 2>/dev/null |
exact agent count, names, categories |
bun src/cli.ts list commands 2>/dev/null |
command inventory |
find skills -name SKILL.md -exec head -6 {} \; -exec echo --- \; |
skill frontmatter (name, description) |
find agents -maxdepth 2 -name '*.md' -exec head -4 {} \; -exec echo --- \; |
agent frontmatter (name, description), category from path |
| Current target doc | existing structure, badges, nav links, voice |
git log --oneline -15 |
recent change context |
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 · 173 lines · 35 tokens per session scan A 26c216d07df1
generating-project-docs is a skill published in the GitHub repository marcusrbrown/systematic (24 stars, last pushed 3d ago), licensed MIT. It adds 35 tokens to every session and 2,391 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 skills, from other repositories
plan-protocol
Guidelines for creating and managing implementation plans with citations.
plan-review
Criteria for reviewing implementation plans against quality standards.
code-review
Comprehensive code review methodology with severity classification and confidence thresholds.
code-philosophy
Internal logic and data flow philosophy (The 5 Laws of Elegant Defense). Understand deeply to ensure code guides data naturally and prevents errors.
frontend-philosophy
Visual & UI philosophy (The 5 Pillars of Intentional UI). Understand deeply to avoid "AI slop" and create distinctive, memorable interfaces.
opencode-ensemble
Use when coordinating multiple coding agents, delegating independent software work, managing OpenCode Ensemble teams, choosing teammate roles or models, reviewing teammate output, or deciding whether parallel execution is appropriate.