The material below is a bundle of source-file excerpts, with each original file and line range labeled.
SKILL.md is the entry point; the labeled ranges identify which excerpts are supplied.

--- BEGIN FILE "document-generate/SKILL.md" (lines 418-821; entrypoint) ---
## Step 0: Scope & Intent

1. Determine what to document:
   - **If invoked with a specific target** (feature, module, file, skill): scope is that target
   - **If invoked for an entire project**: scope is the full project
   - **If called from /document-release with gaps**: scope is the specific entities from the coverage map

2. Use AskUserQuestion to confirm scope and ask about documentation 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.

3. Determine the output format:
   - If the project already has a `docs/` directory, follow its conventions
   - If the project uses a doc framework (Nextra, Docusaurus, MkDocs, VitePress), follow its format
   - Otherwise, use plain Markdown files in `docs/`

---

## Step 1: Codebase Archaeology (Research Phase)

The quality of the documentation depends on how well you understand the code, so this
step carries the most weight.

1. **Map the project structure:**

```bash
find . -type f -not -path "./.git/*" -not -path "./node_modules/*" -not -path "./.gstack/*" -not -path "./dist/*" -not -path "./build/*" -not -path "./.next/*" | head -200
```

2. **Read the entry points.** Identify and read:
   - README.md, ARCHITECTURE.md, CONTRIBUTING.md, CLAUDE.md / AGENTS.md
   - package.json / Cargo.toml / pyproject.toml / go.mod (understand the project type)
   - Main entry files (index.ts, main.rs, app.py, cmd/main.go)
   - Configuration files and examples

3. **Read the source code for each target entity.** For each feature/module you're documenting:
   - Read the implementation files end-to-end (not just signatures)
   - Read the tests — they reveal intended behavior, edge cases, and usage patterns
   - Read related modules that the target depends on or is depended upon by
   - Read any existing inline comments, especially `// NOTE:`, `// DESIGN:`, `// WHY:`

4. **Build a concept map.** Before writing, produce an internal outline:

```
Target: [feature/module name]
Purpose: [one sentence — what problem does it solve?]
Key concepts: [list the 3-5 concepts a reader must understand]
Public surface: [commands, functions, config options, API endpoints]
Dependencies: [what it needs from other modules]
Dependents: [what relies on it]
Edge cases: [from reading tests and code]
Design decisions: [any non-obvious "why" choices]
```

5. Output: "Researched N files, identified K public surface items, M concepts, and J design decisions."

---

## Steps 2-6: Write the docs

Write whatever documentation seems most useful for the scope, in whatever structure fits.

---

## Step 7: Cross-Document Linking & Discoverability

After writing all documents:

1. **Add cross-links between quadrants.** Every reference doc should link to its how-to.
   Every how-to should link to its reference. Tutorials should link to both.

2. **Update entry-point files.** Add references to new docs in:
   - README.md — add to documentation section or table of contents
   - CLAUDE.md / AGENTS.md — add to project structure if relevant
   - Any existing docs index or sidebar config

3. **Verify discoverability.** Every new document must be reachable within 2 clicks from
   README.md. If a docs framework is in use, add to the sidebar/nav config.

4. **Check for broken links.** Grep for any `](` references that point to files that don't exist.

---

## Step 8: Quality Self-Review

This review happens after Step 9 has committed and pushed. Optionally skim each document against these criteria:

**Accuracy gate:**
- [ ] Every code example compiles / runs / passes if copy-pasted
- [ ] Every API description matches the actual code signature
- [ ] Every command shown produces the output described
- [ ] No stale references to renamed/removed entities

**Completeness gate:**
- [ ] Reference docs cover 100% of public surface
- [ ] How-tos cover the top 3 tasks a user would attempt
- [ ] Tutorials get to a working result in ≤3 steps
- [ ] Explanation docs name trade-offs, not just choices

**Voice gate:**
- [ ] Written for a smart person who hasn't seen the code
- [ ] No jargon without brief inline gloss on first use
- [ ] Active voice, concrete nouns, short sentences
- [ ] "You can now..." not "The system provides..."

Failures can be fixed in a later PR.

---

## Step 9: Commit & Output

1. Stage new documentation files by name (never `git add -A` or `git add .`).

**Redaction scan before commit.** Generated docs frequently contain example
credentials; scan the staged doc content and block on a HIGH credential (a
live-format secret in committed docs is a leak). The per-span placeholder
filter passes obvious docs examples (e.g. `AKIAIOSFODNN7EXAMPLE`); a
live-format secret blocks wherever it appears, fenced or not:

```bash
REDACT_VIS=$(~/.claude/skills/gstack/bin/gstack-config get redact_repo_visibility 2>/dev/null)
[ -z "$REDACT_VIS" ] && REDACT_VIS=$(gh repo view --json visibility -q .visibility 2>/dev/null | tr 'A-Z' 'a-z')
git diff --cached --no-color | grep '^+' | sed 's/^+//' | \
  ~/.claude/skills/gstack/bin/gstack-redact --repo-visibility "${REDACT_VIS:-unknown}" --json
# exit 3 (HIGH) → unstage the offending doc, remove the secret, re-stage. Do NOT commit.
```

2. Create a commit:

```bash
git commit -m "$(cat <<'EOF'
docs: generate [scope] documentation (Diataxis)

[One-line summary of what was documented]

Quadrants: [list which quadrants were produced]

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
```

3. Push to the current branch:

```bash
git push
```

4. **If a PR exists**, update the PR body with a `## Documentation Generated` section listing
   every new file with its Diataxis quadrant and a one-line description:

```
## Documentation Generated

| File | Quadrant | Description |
|------|----------|-------------|
| docs/tutorial-getting-started.md | Tutorial | Walk-through from install to first working example |
| docs/reference-widget-api.md | Reference | Complete widget API with types, defaults, examples |
| docs/explanation-bayesian-scheduler.md | Explanation | Why the scheduler uses Bayesian inference |
| docs/howto-custom-widgets.md | How-to | Creating and registering custom widgets |
```

5. Output a structured summary:

```
Documentation generated:
  Scope: [what was documented]
  Files: [N] new, [M] updated
  Coverage:
    Tutorials:    [count] ([list])
    How-tos:      [count] ([list])
    Reference:    [count] ([list])
    Explanation:  [count] ([list])
  Quality: [pass/fail on each gate]
```

---

## Important Rules

- **Research before writing.** Step 1 is not optional. Read the code, read the tests, read the
  existing docs. Insufficient research produces surface-level documentation.
- **Accuracy is non-negotiable.** Every code example must work. Every API description must match
  the actual code. If you're unsure about a detail, read the source again — do not guess.
- **Diataxis quadrants serve different readers.** Do not mix tutorial content into reference docs
  or reference content into how-tos. Each quadrant has a specific reader in a specific mode.
- **Time to first result in tutorials.** If a reader can't see something working by step 3,
  restructure the tutorial.
- **Cross-link everything.** Isolated docs are undiscoverable docs.
- **Voice: friendly, concrete, user-forward.** Write like you're explaining to a smart person
  who hasn't seen the code. Never corporate, never academic.
- **Completeness over minimalism.** AI makes comprehensive documentation cheap. Don't write
  "minimal viable docs" — write complete docs. Boil the ocean.

--- END FILE "document-generate/SKILL.md" ---