feat(skills): add writing-docs skill for public-facing documentation#9
Merged
Conversation
Built via the writing-skills RED-GREEN-REFACTOR loop. Baseline subagents
defaulted to ASCII diagrams ("avoids a Mermaid dependency") and asserted a
reader could follow the docs rather than testing it. The skill teaches one
principle — a doc is answers to a reader's questions, proven by a fresh-reader
test, not by re-reading your own draft — plus device selection (Mermaid, never
hand-drawn ASCII) and an OSS-grade quality bar. Scope is public-facing docs;
docstrings, release notes, and specs are deferred to their owning skills.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…points Public-facing docs describe settled behavior, so they are written at the same point end-to-end coverage is: the single-PR checkpoint in developing-a-feature and the pre-integration-PR step in reviewing-feature-progress. Per-change docstrings stay with testing-a-feature; this is feature-level reader-facing docs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… shape The approved spec's SKILL.md shape lists Anti-patterns before the Red flags table, and sibling skills carry both. The lean-down dropped it; restore it grounded in the observed baseline failures (self-judged docs, ASCII diagrams) plus the scope-duplication boundary, which no Red flags row covers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…riting A new first loop step makes the agent establish where a project's docs actually live (README vs a docs/ tree or generated site vs a wiki) and at what level, before drafting. Baseline placement was good only when the surface map was handed over; nothing required the agent to build it, so a bare "document this" defaulted to the README. Verified: given only a raw file listing, the agent now infers the docs-site tier and routes depth there with a README pointer. Adds the matching anti-pattern and red-flag row. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a new writing-docs skill that ensures public-facing documentation (README, guides, tutorials, API reference) is written to an OSS-grade bar via a fresh-reader RED→GREEN→REFACTOR loop, and wires it into the structural-completeness checkpoints of both single-PR and multi-PR feature flows.
Changes:
- Adds
skills/writing-docs/SKILL.mddefining the doc-surface discovery step, reader-persona test loop, Mermaid-only diagram rule, quality bar, and out-of-scope handoffs. - Wires
**REQUIRED SUB-SKILL:** feature-dev-workflow:writing-docsnext totesting-end-to-endindeveloping-a-feature(Step 5) andreviewing-feature-progress(Step 6). - Lists the skill in the README skills table and the
templates/project-CLAUDE.mdflow map.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| skills/writing-docs/SKILL.md | New skill content with frontmatter, loop, device/depth selection, quality bar, anti-patterns, and red flags. |
| skills/developing-a-feature/SKILL.md | Adds docs handoff in Step 5 single-PR checkpoint between e2e and verification. |
| skills/reviewing-feature-progress/SKILL.md | Adds docs handoff in the multi-PR checkpoint between e2e and verification. |
| README.md | Adds writing-docs row to skills table. |
| templates/project-CLAUDE.md | Adds writing-docs row to the flow map table. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds a
writing-docsskill that makes the agent reliably write and update public-facing documentation — README, usage guides, tutorials, public API/reference — to a consistent, OSS-grade bar, and wires it into the existing feature-development flow so docs aren't forgotten. It fills a real gap: the plugin already covers docstrings (testing-a-feature), release notes (drafting-a-release), and specs/ADRs (planning-a-feature), but the durable prose a consumer actually reads had no home and no quality discipline.The skill teaches one principle — a doc is a set of answers to a reader's questions, proven by a fresh-reader test rather than by re-reading your own draft — and was itself built with the
writing-skillsRED→GREEN→REFACTOR loop against real subagent baselines.Changes
skills/writing-docs/SKILL.md: locate-the-doc-surfaces-first step, a fresh-reader RED→GREEN→REFACTOR loop, device/depth selection (Mermaid for diagrams, never hand-drawn ASCII), an OSS-grade quality bar, scope handoffs, and Anti-patterns + Red-flags tables.**REQUIRED SUB-SKILL:** feature-dev-workflow:writing-docsin besidetesting-end-to-endat structural completion in both paths:developing-a-feature(single-PR) andreviewing-feature-progress(multi-PR).templates/project-CLAUDE.mdflow map.Challenges
The first RED baseline was contaminated: subagents run inside this repo inherited its skill ecosystem and behaved well, hiding the natural failures. Re-running isolated baselines surfaced the real ones — agents default to ASCII diagrams ("avoids a Mermaid dependency") and assert a reader could follow the docs instead of testing it. The skill targets exactly those, and is deliberately leaner than the original design where the evidence didn't justify counters (forgetting and fluff weren't natural failures, so forgetting is handled by the wiring, not prose). A late addition — a step requiring the agent to establish where docs live before writing — came from review feedback and was verified to make the agent infer a docs-site tier from a bare file listing and route depth there.
Testing
Built and verified entirely through subagent scenarios, per
writing-skills. RED: documented baseline failures across two scenarios (a feature wrap-up and a from-scratch README), run both contaminated and isolated. GREEN: re-ran the same scenarios with the skill present and confirmed both failures fixed — agents now name reader personas, run an explicit reader test, and decline ASCII in favor of Mermaid. A diagram-warranting scenario confirmed the agent produces a realmermaidblock; a multi-surface scenario confirmed the new surface-location step routes depth to a docs site with only a README pointer. A fresh reviewer agent checked the diff against the contributor rules and the design; its one valid finding (a dropped section) was fixed. Mechanical checks: no stack/product leakage (only the justified Mermaid/GitHub mention),description:is trigger-only, control-flow markers consistent across every flow-listing file.