$npx -y skills add testdouble/han --skill project-documentationCreates and maintains project documentation for features, systems, and components. Use when documenting how a feature, system, or component works — including writing, updating, or organizing docs. Does not scan or detect the project's technology stack — use project-discovery for
| 1 | ## Project Context |
| 2 | |
| 3 | - CLAUDE.md exists: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` |
| 4 | - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` |
| 5 | |
| 6 | # Project Documentation |
| 7 | |
| 8 | **Readability.** As you write the documentation, load and apply the readability rule at [`../../references/readability-rule.md`](../../references/readability-rule.md). The output is a committed file, so the standard applies at generation time. Hold a named audience above the default: a technically-literate reader who needs to understand the feature's behavior before reading or modifying its code. Scope that frame per section so the technical specifics the reader needs are not simplified away. |
| 9 | |
| 10 | ## Step 1: Evaluate and Gather Context |
| 11 | |
| 12 | **Guard check:** If the request is about an **architectural decision**, suggest `architectural-decision-record` instead. If it's about a **coding convention**, suggest `coding-standard` instead. Proceed only after confirming this is project documentation. |
| 13 | |
| 14 | **Docs directory:** Resolve project config: read CLAUDE.md's `## Project Discovery` section for docs directory and language; fall back to project-discovery.md; fall back to Glob default (`docs/`). Use the found docs directory with Glob to enumerate existing `.md` files. If no docs directory was found, create `docs/`. The found language informs code fence language identifiers in Step 3. |
| 15 | |
| 16 | **Resolve target files:** Derive the filename in kebab-case: `docs/{feature-name}.md`. Use Glob to check if the file already exists (`docs/{feature-name}*.md`). If it exists, use `AskUserQuestion` to ask: update the existing document, or create with a different name? If not, it will be created. |
| 17 | |
| 18 | **Topic context:** Use the arguments and conversation context to understand the topic and scope. If unclear, use `AskUserQuestion` to clarify. |
| 19 | |
| 20 | **Flag content audit need:** Determine whether the Content Audit (Step 6) will be needed. It is needed when updating an existing doc, migrating content from CLAUDE.md, or restructuring content from any other source. It is not needed only when creating documentation for a feature with no prior documentation of any kind. |
| 21 | |
| 22 | ## Step 2: Explore the Codebase |
| 23 | |
| 24 | Launch 2-3 `han-core:codebase-explorer` agents in parallel with the feature name, scope, and any known file paths. Include the docs directory from Step 1 so agents can discover existing documentation. Each agent should explore from a different angle (e.g., entry points and core logic; data models and configuration; tests and existing docs). |
| 25 | |
| 26 | After all agents complete, merge their findings into a unified **discovery summary** — a numbered list (D1, D2, D3, ...) that combines all items, deduplicates files found by multiple agents, and resolves any conflicting findings. |
| 27 | |
| 28 | ## Step 3: Write the Documentation |
| 29 | |
| 30 | Use the template at [template.md](./references/template.md) as the structural guide. The template's HTML comments explain when to include each section and what to cover. |
| 31 | |
| 32 | **Readability.** Draft into the template so the structure carries the rule at [`../../references/readability-rule.md`](../../references/readability-rule.md): main point first, descriptive headings, one idea per paragraph with the first sentence carrying it, numbered lists for steps and bullets for non-sequential items, and progressive disclosure that reveals the core before the detail. |
| 33 | |
| 34 | **File location:** `docs/{feature-name}.md` (in the directory determined in Step 1) |
| 35 | |
| 36 | **Writing rules:** |
| 37 | |
| 38 | Lead with behavior. These rules make the doc an overview first and a reference second: |
| 39 | 1. **Lead with behavior.** Write the Summary, How It Works, and Primary Flows in plain language before any reference section. Describe what the feature does and what happens when it runs, in functional terms. Name files and types only where it aids understanding. |
| 40 | 2. **Summary is prose plus bullets.** Open the Summary with a 2-4 sentence plain-language paragraph for a reader who has not seen the code, then the scannab |