agentleFS
automagik-devautomagik-dev/genie/skills/docs/SKILL.md

docs

Skill351 starsChanged 7 months agoApache-2.0View on GitHub

Audit documentation and developer experience against the live product — drift, onboarding, error messages — and write or fix docs when asked.

165 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use import-memory, perf and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • amirbironSkill

    import-memory

    Import a memory export from another AI assistant into Claude's memory — conversationally, additively, and with the content treated as data.

    Also in 3 projects that use this

  • MicrosoftSkill

    perf

    Speed and memory performance rules for Rust crates, the Node addon, webui-framework, and webui-delivery.

    Also in 4 projects that use this

  • diego-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 3 projects that use this

  • JkudjoSkill

    incident

    Production incident response — structured triage, hypothesis tree, safe remediation, incident record

    Also in 4 projects that use this

  • mbwsimsSkill

    impact

    This skill should be used when the user asks to "check the impact", "what will break if I change this", "blast radius", "impact analysis", "what depends on this", "who imports this", "is it safe to change this", mentions "/impact", or wants to understand the consequences of modifying a specific file or function before making changes.

    Also in 3 projects that use this

  • AnthropicSkill

    debug

    Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.

    Also in 19 projects that use this

The file

Files
SKILL.md

Docs

Assess by default; write only when the request asks. Documentation is judged by use: a page that cannot be followed is worse than none. The live interface (the real --help output, routes, exports) is the truth; every README table, guide, and agent-context file is a claim to check against it.

The assessment half is a saved workflow, not a procedure this skill performs inline. Its single source of truth is .claude/workflows/docs-audit.js in the genie repository's canonical workflow catalog (see .claude/workflows/README.md there); this skill is its front door. On a runtime that runs saved workflows, run the script at <repository root>/.claude/workflows/docs-audit.js when that file exists, otherwise ~/.claude/workflows/docs-audit.js (delivered by genie install / genie update); give the runtime that explicit script path, never a bare name — both scopes now carry these names and the order a name resolves in is undocumented. Pass {focus?, surfaces?, quorum?, model?, timestamp?} — every key optional, and with no surfaces list the audit runs the full four-surface roster of the table below. The workflow probes read-only: it asks nothing, writes nothing, and moves no file. Relay the returned report unchanged, and list notConvened (agents that returned nothing) beside the unread (paths no auditor could read) and unprobed (documented claims no auditor could probe read-only) lists rather than filling any of the three gaps yourself.

When to use

  • Modules, APIs, or workflows are undocumented, or docs describe removed behavior.
  • Code changed in ways the docs describe, or a wish deliverable includes documentation.
  • Someone wants the contributor experience audited: onboarding, drift, error messages.

Surfaces

The four keys are the audit's shard roster: surfaces narrows it, never grows it, and a key it drops is named as a gap.

SurfaceKeyWhere
READMEreadmeREADME.md, */README.md
Agent instructionsagent-instructionsAGENTS.md (governing), CLAUDE.md + .claude/rules/*.md (Claude overlays; keep current)
Reference and architecturedocs-architecturedocs/, ARCHITECTURE.md, inline JSDoc/TSDoc
Runtime DXruntime-dx--help text, error messages, onboarding path in README/CONTRIBUTING

The workflow resolves where docs live before judging them — in-repo, a submodule behind a symlink, or a separate site — and stamps that route into every auditor, so a fix never says "edit here" when the docs live elsewhere. Internal pages deliberately excluded from a public site are design, not gaps.

The contributor test

This stays here, with you, and never reaches the workflow. When onboarding is in scope, follow the written path verbatim as a fresh reader: from clone to the first passing check, one serial walk, logging every divergence. It installs and builds, so it is never parallelised and never delegated to a shard. Hold the repo to its own stated bar, and freeze what you learned into focus before the call rather than asking the workflow to re-derive it.

Write

When asked, fill gaps in the project's existing style through its documented docs workflow, whatever that repository states it to be — in the genie repository, for instance, the vendored docs submodule flow its agent-instructions file records: edit under docs/, commit and push inside the submodule, open the pull request against the docs remote, then bump the superproject pointer once it merges. Never document features that do not exist; every referenced path, API, and behavior must be verified real. Write to the reader's decision boundary: what they need to decide, do, observe, and verify. Keep internal mechanism out of operator pages unless it changes a decision, a safety boundary, or a troubleshooting step.

Without a workflow surface

On a runtime with no workflow surface, dispatch the same four stages by hand and carry no roster the script does not. Locate: one read-only agent resolves the docs home, its other true names, the public/internal split and the fix workflow, each claim carrying the read-only command that proved it. Audit: one auditor per row of the Surfaces table, each carrying several checks over its whole surface and quoting both the documented claim and the live behaviour. Consolidate: one judge sees every responding auditor at once, collapses one root drift restated on three surfaces into a single row, settles severity conflicts, and ranks by which blocker a reader hits first. Render: draw the table, the docs-home routing line, the duplicate list and the unread/unprobed lists yourself. An auditor that returns nothing is reported, never inferred.

Report

Lead with the verdict: did the contributor test pass, what is the worst drift. Then the ranked table with evidence (both sides of each drift, the exact stumble step, the quoted error message) and concrete fixes routed through the real workflow. Say what was verified current and what was skipped. Report only what was checked or written in this session.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.