mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-16 01:02:13 +08:00
v1.35.0.0 feat: add /document-generate skill + enhance /document-release with Diataxis coverage map (#1477)
* feat(document-release): add Diataxis coverage map, diagram drift detection, and docs debt tracking Inspired by @doodlestein's documentation-website skill. Three key ideas incorporated: 1. Step 1.5: Coverage Map (Blast-Radius Analysis) — before editing any docs, scan the diff for new public surface and assess documentation coverage across Diataxis quadrants (reference/how-to/tutorial/explanation). Flags gaps without auto-generating content. 2. Architecture diagram drift detection — extracts entity names from ASCII/Mermaid diagrams and cross-references against the diff to catch stale diagrams. 3. Enhanced CHANGELOG sell test — Diataxis rubric scoring (0-3) replaces the subjective 'would a user want this?' check. 4. Documentation Debt section in PR body — surfaces coverage gaps and diagram drift as actionable items for future work. All changes are audit-only: the skill flags what's missing, never auto-generates missing documentation pages. Stays in its lane as a post-ship updater. Co-Authored-By: Hermes Agent <agent@nousresearch.com> * feat(document-generate): add Diataxis documentation generation skill New /document-generate skill, the companion to /document-release. While /document-release audits and fixes existing docs post-ship, /document-generate writes missing documentation from scratch using the Diataxis framework. Inspired by doodlestein documentation-website-for-software-project skill. Co-Authored-By: Hermes Agent <agent@nousresearch.com> * chore(docs): regenerate gstack/llms.txt with /document-generate entry CI's check-freshness step ran gen:skill-docs and found llms.txt stale — the index wasn't regenerated when /document-generate was added in the preceding commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(docs): regen document-generate/SKILL.md after merging main Main brought in the Non-ASCII characters directive in the AskUserQuestion Format resolver (scripts/resolvers/preamble/generate-ask-user-format.ts). Regenerating document-generate/SKILL.md propagates the new section into the generated output. check-freshness should now pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(CLAUDE.md): add workflow for fork PRs from garrytan-agents Fork PRs from non-collaborators don't get base-repo secrets passed to their CI workflows, so eval/E2E jobs fail with empty-env auth. New section: when checking out a PR from garrytan-agents, push the branch to garrytan/gstack and re-target the PR from there. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: sync project docs for v1.35.0.0 + bump VERSION - README.md: add /document-generate to skills table (Technical Writer category) + install-command skill lists - CLAUDE.md: add document-generate/ to project structure tree - SKILL.md.tmpl + regenerated SKILL.md: add /document-generate routing line ("write docs from scratch") - VERSION: 1.34.0.0 → 1.35.0.0 (MINOR: new skill + enhancement) CHANGELOG entry deferred to /ship. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: bump version and changelog (v1.35.0.0) CHANGELOG entry for the document-generate skill + document-release Diataxis enhancements. package.json synced to VERSION (drift repair after merging main which had bumped pkg to 1.34.2.0). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: generate /document-generate Diataxis docs (tutorial + how-to + explanation) Fills the documentation debt items flagged by /document-release in PR #1477: critical-gap tutorial coverage and common-gap explanation coverage for the new /document-generate skill. Quadrants: tutorial, how-to, explanation (reference already covered by document-generate/SKILL.md). - docs/tutorial-document-generate.md (1009 words): newcomer 90-second flow - docs/howto-document-a-shipped-feature.md (770 words): post-ship audit + fill workflow - docs/explanation-diataxis-in-gstack.md (1106 words): why Diataxis, trade-offs, alternatives - README.md: links the three docs from the /document-generate skills-table row All cross-links verified — every Related section points at an existing file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Hermes Agent <agent@nousresearch.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
79
docs/explanation-diataxis-in-gstack.md
Normal file
79
docs/explanation-diataxis-in-gstack.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Why gstack uses Diataxis for documentation
|
||||
|
||||
The two doc skills in gstack — `/document-release` and `/document-generate` — both speak Diataxis. New entities get scored across four quadrants. Coverage gaps surface in PR bodies tagged by quadrant. This doc explains why that vocabulary is load-bearing, and why a simpler "just write markdown" approach falls down at the scale gstack operates at.
|
||||
|
||||
## The problem
|
||||
|
||||
Documentation rot is the easiest kind of rot to ignore. Code stops compiling and you notice immediately. A test fails and CI screams. Docs go stale silently — the README still parses, the install command still copy-pastes — and the only signal is a confused user weeks later filing an issue or quietly walking away.
|
||||
|
||||
gstack has more than 45 skills. Every one is a SKILL.md plus a `.tmpl` template plus, ideally, a getting-started tutorial somewhere and an explanation of why it works the way it does. Multiply that by however many gstack users have similar surface-area in their own projects and the maintenance load is real.
|
||||
|
||||
The naive failure mode is "every team writes docs in their own format." One project has a Wiki. Another has nested README files. A third has reference-only API docs and no tutorials. A fourth has tutorials that no longer compile. You can't write tooling that audits across all of those because there's no shared vocabulary for what good coverage means.
|
||||
|
||||
The second failure mode is more subtle: even when a team is disciplined, they tend to write the kind of doc that matches their current state of mind. Engineers in build mode write reference. Engineers in launch mode write tutorials. Engineers in maintenance mode write troubleshooting how-tos. No one wakes up and says "today I'll write the explanation doc for why we chose this architecture" — so explanation rot accumulates fastest.
|
||||
|
||||
## The approach
|
||||
|
||||
Diataxis (Daniele Procida, originally at Divio, now adopted across CPython, Django, NumPy, FastAPI, GitHub docs, and many others) splits documentation into four quadrants based on **reader intent**:
|
||||
|
||||
```
|
||||
THEORETICAL PRACTICAL
|
||||
(understanding) (doing)
|
||||
|
||||
STUDY +-----------------------------+----------------------------+
|
||||
(learning) | | |
|
||||
| EXPLANATION | TUTORIAL |
|
||||
| "Why does X exist?" | "Walk me through X |
|
||||
| | for the first time" |
|
||||
| discusses code | teaches code |
|
||||
| | |
|
||||
+-----------------------------+----------------------------+
|
||||
|
||||
WORK +-----------------------------+----------------------------+
|
||||
(using) | | |
|
||||
| REFERENCE | HOW-TO |
|
||||
| "What is the exact | "How do I accomplish Y |
|
||||
| signature of Y?" | using X?" |
|
||||
| | |
|
||||
| describes code | uses code |
|
||||
| | |
|
||||
+-----------------------------+----------------------------+
|
||||
```
|
||||
|
||||
A reader in tutorial mode is learning by doing. They want a guided path with guaranteed success. A reader in how-to mode already knows the basics and wants the recipe for a specific task. A reader in reference mode wants accurate, complete, fact-table coverage of the API. A reader in explanation mode wants to understand a design decision.
|
||||
|
||||
The same person reads a project from each of these modes at different times. The same paragraph cannot serve all four — tutorials need handholding that would slow down a reference reader; reference needs completeness that would overwhelm a tutorial reader.
|
||||
|
||||
## Why this matters as a coverage lens
|
||||
|
||||
A coverage map written in Diataxis terms gives you a deterministic answer to "did docs get updated?" — not "is there a README" but "is there a tutorial for this new skill, a how-to for the common task, a reference for the API, and an explanation for the non-obvious design choice?"
|
||||
|
||||
`/document-release` Step 1.5 walks the diff, extracts new public surface (skills, CLI flags, config options, API endpoints), and scores each entity across the four quadrants. Items with zero coverage become **critical gaps**. Items with only reference coverage (the most common failure mode in gstack's own history) become **common gaps**. Both land in the PR body where reviewers see them.
|
||||
|
||||
`/document-generate` writes docs in the four quadrants intentionally. It refuses to mix them: a tutorial does not get a "Configuration" section, a reference doc does not get a "What you'll build" paragraph. The skill's 9 steps go reference → explanation → how-to → tutorial because that ordering matches the dependency: reference fixes the vocabulary, explanation justifies the design, how-tos build on both, tutorials are the last and hardest.
|
||||
|
||||
## Trade-offs
|
||||
|
||||
**Diataxis adds vocabulary that readers must learn.** A user who's never heard of "reference vs explanation" might find the labels strange at first. The mitigation is that Diataxis labels are self-explanatory once you've seen them once, and the labels never appear in the docs themselves — they appear in the coverage map and PR body, where reviewers see them, not end users.
|
||||
|
||||
**Four files instead of one.** A small skill might have one `docs/SKILL.md` file that mixes all four modes. Diataxis splits that into four. The mitigation: AI generation makes the four-file structure cheap, the cross-linking between quadrants is mechanical (every reference doc links to its how-to, every how-to links to its reference, etc.), and the gains in audit-ability are substantial — `/document-release` can score coverage automatically.
|
||||
|
||||
**Diataxis is not the only good framework.** "Every page is page one" (Mark Baker), the four kinds of docs in the *Write the Docs* community, the Google developer documentation style guide — all have different cuts. gstack picked Diataxis because it has the strongest external adoption (CPython, Django, NumPy, FastAPI, etc.), which means downstream users have the highest chance of having seen the vocabulary before, and the quadrant labels translate cleanly to coverage-map signals.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
**"Just write README sections."** Tried implicitly across gstack's history. Failure mode: tutorials accumulated in README until READMEs were 800+ lines and nobody read them past line 50. Diataxis splits them into dedicated files, each discoverable from README's table of contents.
|
||||
|
||||
**Custom in-house taxonomy.** Tempting because it could be tailored. Rejected because every team would invent their own vocabulary and `/document-release` would lose its cross-project audit power. Diataxis is the lingua franca.
|
||||
|
||||
**Auto-generated reference only.** Tried via tools like JSDoc / TypeDoc / Sphinx for many projects. Reference docs without explanation become impenetrable for newcomers; without tutorials, the API is hard to onboard onto. Reference is necessary but not sufficient.
|
||||
|
||||
**No documentation framework at all, just gut-check.** The status quo for most projects. Fails silently — users walk away rather than file issues, so the feedback loop is broken. Diataxis gives a structured signal even before users complain.
|
||||
|
||||
## Related
|
||||
|
||||
- **Reference for the skill that implements this:** [`document-generate/SKILL.md`](../document-generate/SKILL.md)
|
||||
- **Reference for the audit that uses this taxonomy:** [`document-release/SKILL.md`](../document-release/SKILL.md)
|
||||
- **Tutorial for using `/document-generate`:** [`tutorial-document-generate.md`](./tutorial-document-generate.md)
|
||||
- **How-to: document a shipped feature:** [`howto-document-a-shipped-feature.md`](./howto-document-a-shipped-feature.md)
|
||||
- **Diataxis homepage:** https://diataxis.fr/ — Procida's canonical reference for the framework
|
||||
105
docs/howto-document-a-shipped-feature.md
Normal file
105
docs/howto-document-a-shipped-feature.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# How to document a feature you just shipped
|
||||
|
||||
This is the post-ship workflow: you merged a PR, the docs are stale, and you want a coverage map plus filled gaps in one pass. You'll run `/document-release` to audit, then `/document-generate` to fill the gaps it finds.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- gstack installed (`./setup` complete; verify with `which gstack` or by typing `/` in Claude Code and seeing skills listed)
|
||||
- The branch with your shipped feature is checked out
|
||||
- A PR exists on GitHub or GitLab (recommended — the workflow updates the PR body with a coverage map)
|
||||
|
||||
If no PR exists yet, run `/ship` first to create one; that's what `/document-release` is designed to run against.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Audit current coverage
|
||||
|
||||
Run:
|
||||
|
||||
```
|
||||
/document-release
|
||||
```
|
||||
|
||||
The skill walks your diff against the base branch, extracts new public surface (skills, CLI flags, config options, API endpoints, new modules), and scores each entity across the four Diataxis quadrants. You'll see a coverage map like:
|
||||
|
||||
```
|
||||
Coverage map:
|
||||
[entity] [reference?] [how-to?] [tutorial?] [explanation?]
|
||||
/new-skill ✅ AGENTS.md ❌ ❌ ❌
|
||||
--new-flag ✅ README ✅ README ❌ ❌
|
||||
FooProcessor ❌ ❌ ❌ ❌
|
||||
```
|
||||
|
||||
Items with zero coverage are **critical gaps**. Items with only reference coverage are **common gaps**. Both land in the PR body as a `### Documentation Debt` subsection so reviewers see them.
|
||||
|
||||
If `/document-release` reports everything is covered, you're done. Skip the rest of this how-to.
|
||||
|
||||
### 2. Read the documentation debt section in the PR body
|
||||
|
||||
Open your PR (the skill prints the URL). Scroll to `## Documentation` → `### Documentation Debt`. Each item is tagged with the Diataxis quadrant that would fill it:
|
||||
|
||||
```
|
||||
### Documentation Debt
|
||||
|
||||
- ⚠️ /new-skill — has reference in AGENTS.md but no how-to example in README. Diataxis quadrant: how-to.
|
||||
- ⚠️ FooProcessor — zero coverage. Diataxis quadrants: reference, explanation.
|
||||
```
|
||||
|
||||
This is the input to the next step. Each line tells you what's missing and which quadrant fills it.
|
||||
|
||||
### 3. Fill the gaps with /document-generate
|
||||
|
||||
Run:
|
||||
|
||||
```
|
||||
/document-generate
|
||||
```
|
||||
|
||||
When the skill asks about scope, tell it the specific entities flagged in the debt section. The skill reads the codebase (its Step 1 archaeology phase is mandatory), partitions by Diataxis quadrant, and writes the missing docs.
|
||||
|
||||
You can also let the skill auto-discover: if /document-release passed you the gaps explicitly (it does this when chained), `/document-generate` already knows what to write.
|
||||
|
||||
### 4. Verify the gaps closed
|
||||
|
||||
Re-run `/document-release`:
|
||||
|
||||
```
|
||||
/document-release
|
||||
```
|
||||
|
||||
The coverage map should now show the previously-flagged entities with green checkmarks in the previously-empty quadrants. The PR body's Documentation Debt section should be empty or reduced to items you intentionally deferred.
|
||||
|
||||
## Verification
|
||||
|
||||
Open your PR and confirm:
|
||||
|
||||
1. The PR body has a `## Documentation` section with a doc-diff preview.
|
||||
2. The `### Documentation Debt` subsection lists zero critical gaps (or only items you knowingly deferred).
|
||||
3. Each generated doc file in `docs/` opens cleanly and cross-links to siblings (reference → how-to → tutorial → explanation).
|
||||
4. Run `grep -rE '\]\([^)]*\.md\)' docs/` and verify no link points to a missing file.
|
||||
|
||||
If all four check, your PR is ready to land with complete documentation.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**`/document-release` reports "No public surface changes detected."**
|
||||
The diff is internal-only (refactors, tests, infra). No docs are needed. Skip to landing.
|
||||
|
||||
**The Diataxis quadrant tag on a gap doesn't match what you'd expect.**
|
||||
The skill uses an entity taxonomy to decide which quadrants matter (CLI flags want reference + how-to; internal modules want reference + explanation; user-facing features want all four). If you disagree, you can override by hand-editing the docs after generation. The audit is a guide, not a constraint.
|
||||
|
||||
**`/document-generate` writes a tutorial that takes 8 steps to reach a working result.**
|
||||
Tutorials should hit a working result in 3 steps or fewer. Re-run the skill and ask it to compress, or hand-edit. The Step 8 Quality Self-Review catches some of these but not all.
|
||||
|
||||
**You want to document a feature but no PR exists yet.**
|
||||
Run `/ship` first to create the PR, then this workflow. Without a PR, `/document-release` can still audit but skips the PR-body update.
|
||||
|
||||
**A generated reference doc has hallucinated API signatures.**
|
||||
File a bug. The skill's Step 1 archaeology is supposed to read implementation files end-to-end, not just signatures, specifically to prevent this. Include the generated text and the actual code so we can trace why the archaeology missed it.
|
||||
|
||||
## Related
|
||||
|
||||
- **Tutorial: first time using `/document-generate`:** [tutorial-document-generate.md](./tutorial-document-generate.md)
|
||||
- **Why gstack uses the Diataxis framework:** [explanation-diataxis-in-gstack.md](./explanation-diataxis-in-gstack.md)
|
||||
- **Reference for the audit skill:** [`document-release/SKILL.md`](../document-release/SKILL.md)
|
||||
- **Reference for the generation skill:** [`document-generate/SKILL.md`](../document-generate/SKILL.md)
|
||||
142
docs/tutorial-document-generate.md
Normal file
142
docs/tutorial-document-generate.md
Normal file
@@ -0,0 +1,142 @@
|
||||
# Tutorial: generate docs for a feature in 90 seconds
|
||||
|
||||
You'll run `/document-generate` against a project you already have, watch it write tutorial / how-to / reference / explanation docs in the right places, and end with a coverage map you can drop into a PR. By the end, you'll know the four moves: scope, archaeology, partition, write.
|
||||
|
||||
## What you'll need
|
||||
|
||||
- gstack installed (`git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup`)
|
||||
- Claude Code running in any project that has at least one piece of public surface (a CLI command, an exported function, a config option, a skill, an API endpoint)
|
||||
- About 90 seconds
|
||||
|
||||
You do not need a `docs/` directory in advance — the skill creates one if it's missing. You do not need to know Diataxis terminology — the skill labels the output for you.
|
||||
|
||||
## Step 1: Invoke the skill in any project
|
||||
|
||||
Open Claude Code in the project you want to document. Type:
|
||||
|
||||
```
|
||||
/document-generate
|
||||
```
|
||||
|
||||
You'll see the skill ask one question about output target:
|
||||
|
||||
```
|
||||
A) Write documentation inline in existing files (README, ARCHITECTURE, etc.)
|
||||
B) Create standalone documentation files (e.g., docs/ directory)
|
||||
C) Both — inline summaries in existing files + deep docs in standalone files
|
||||
|
||||
RECOMMENDATION: Choose C because it maximizes both discoverability and depth.
|
||||
```
|
||||
|
||||
Pick C. You'll get a README pointer plus a full set of standalone docs.
|
||||
|
||||
## Step 2: Watch the archaeology run
|
||||
|
||||
The skill goes silent for ~30 seconds while it reads the codebase. This is intentional — the Step 1 "Codebase Archaeology" phase is the most important step in the workflow. The skill is reading:
|
||||
|
||||
- The full repository structure
|
||||
- README, ARCHITECTURE, CONTRIBUTING, CLAUDE.md (the entry points)
|
||||
- The implementation files for whatever you're documenting (full file, not just signatures)
|
||||
- The tests (which reveal edge cases and intended behavior)
|
||||
- Inline comments tagged `// NOTE:`, `// DESIGN:`, `// WHY:`
|
||||
|
||||
When it finishes, you'll see a line like:
|
||||
|
||||
```
|
||||
Researched 47 files, identified 12 public surface items, 8 concepts, and 4 design decisions.
|
||||
```
|
||||
|
||||
That number tells you the skill actually read the code rather than guessing from filenames.
|
||||
|
||||
## Step 3: See the Diataxis partition plan
|
||||
|
||||
The skill prints a partition plan showing which quadrants it'll write for which entity:
|
||||
|
||||
```
|
||||
Documentation plan:
|
||||
[entity] [tutorial] [how-to] [reference] [explanation]
|
||||
WidgetService ✅ new ✅ new ✅ new ✅ new
|
||||
--verbose flag ❌ ✅ new ✅ inline ❌
|
||||
Bayesian scheduler ❌ ❌ ✅ new ✅ new
|
||||
```
|
||||
|
||||
Not every entity needs all four quadrants. CLI flags get reference + how-to. Internal modules get reference + explanation. User-facing features get all four. The skill picks based on entity type.
|
||||
|
||||
If the plan has more than 5 documents, the skill asks you to confirm before proceeding. Otherwise it goes.
|
||||
|
||||
## Step 4: Read the first doc that lands
|
||||
|
||||
Reference docs land first because they fix the vocabulary. You'll see lines like:
|
||||
|
||||
```
|
||||
GENERATED: docs/reference-widget-service.md
|
||||
```
|
||||
|
||||
Open that file. It has a strict structure: one-paragraph intro, complete API listing with types and defaults, 2-3 runnable examples, and a Related section linking to the how-to and tutorial that will land next.
|
||||
|
||||
This is what reference docs look like in Diataxis: factual, exhaustive, no narrative. If you find yourself wanting to explain *why* an option exists, that belongs in the explanation doc the skill will write next.
|
||||
|
||||
## Step 5: See the explanation, how-to, and tutorial appear
|
||||
|
||||
In quick succession (each ~5-10 seconds), the skill writes the remaining quadrants:
|
||||
|
||||
```
|
||||
GENERATED: docs/explanation-widget-architecture.md
|
||||
GENERATED: docs/howto-create-a-custom-widget.md
|
||||
GENERATED: docs/tutorial-build-your-first-widget.md
|
||||
```
|
||||
|
||||
Open each one. Notice they don't repeat each other:
|
||||
|
||||
- **Explanation** leads with the problem, then the approach, then trade-offs and alternatives considered
|
||||
- **How-to** has prerequisites, numbered steps with exact commands, a verification section, and a troubleshooting section
|
||||
- **Tutorial** gets you to a working result in under 3 steps, ends with "What you built"
|
||||
|
||||
The skill enforces these structures. If a how-to was missing a verification section, the Step 8 Quality Self-Review caught it before commit.
|
||||
|
||||
## Step 6: Check cross-linking
|
||||
|
||||
Every doc links to the others. Reference doc Related section: links to how-to and tutorial. How-to Related section: links to reference. Tutorial "What you built" section: links to reference for deeper exploration.
|
||||
|
||||
Run a grep to verify no broken links:
|
||||
|
||||
```bash
|
||||
grep -rE '\]\([^)]*\.md\)' docs/ | head -10
|
||||
```
|
||||
|
||||
Every linked file should exist. The skill's Step 7 "Cross-Document Linking & Discoverability" checks this before commit.
|
||||
|
||||
## Step 7: See the coverage summary in the PR body
|
||||
|
||||
If you're on a feature branch with an open PR, the skill updates the PR body with a `## Documentation Generated` table:
|
||||
|
||||
```
|
||||
## Documentation Generated
|
||||
|
||||
| File | Quadrant | Description |
|
||||
|------|----------|-------------|
|
||||
| docs/tutorial-build-your-first-widget.md | Tutorial | Walk-through from install to first working widget |
|
||||
| docs/reference-widget-service.md | Reference | Complete widget API with types, defaults, examples |
|
||||
| docs/explanation-widget-architecture.md | Explanation | Why widgets are isolated services |
|
||||
| docs/howto-create-a-custom-widget.md | How-to | Creating and registering custom widgets |
|
||||
```
|
||||
|
||||
A reviewer opening the PR sees the table and knows immediately what kind of coverage shipped.
|
||||
|
||||
## What you built
|
||||
|
||||
You now have four documents that serve four different readers:
|
||||
|
||||
- A newcomer to your project can read `tutorial-*.md` and get something working
|
||||
- An experienced user can read `howto-*.md` to accomplish a specific task
|
||||
- An API caller can read `reference-*.md` for exact signatures
|
||||
- A code reviewer can read `explanation-*.md` to understand the design
|
||||
|
||||
Each one is short enough to maintain. Each one has a single job. The PR body shows which quadrants were covered. If you run `/document-release` later, the Diataxis coverage map will report this entity as fully covered (4/4 quadrants).
|
||||
|
||||
## What to do next
|
||||
|
||||
- **If you have gaps** /document-release flagged but didn't fill: run `/document-generate` again, scoped to those entities specifically.
|
||||
- **If you want to understand why the four quadrants exist:** read [explanation-diataxis-in-gstack.md](./explanation-diataxis-in-gstack.md).
|
||||
- **If you want to document one specific shipped feature** (not the whole project): read [howto-document-a-shipped-feature.md](./howto-document-a-shipped-feature.md).
|
||||
- **Reference for the skill itself:** [`document-generate/SKILL.md`](../document-generate/SKILL.md).
|
||||
Reference in New Issue
Block a user