gen-docs

# Gen Docs ## Overview This repository (`github.com/Pythoughts-labs/pythinker-code`) maintains English user documentation under `docs/`, published at **https://code.pythinker.com**. Use this skill to update the corresponding documentation whenever the codebase has changes that affect product behavior or user experience. For a **full pre-release audit** of all pages (detecting hallucinations and coverage gaps), use the `audit-docs` skill instead. ## Prerequisites This skill depends on the following being in place. If any are missing, stop and report to the user before continuing: - `docs/` directory with documentation pages and `docs/.vitepress/config.ts` set up (VitePress site, deployed to code.pythinker.com). - `docs/AGENTS.md` style guide — defines terminology, typography, and writing style. ## Workflow 1. **Inspect changes** - `git log main..HEAD --oneline` — commits on the current branch - `git diff main..HEAD --stat` — file-level scope - `ls .changeset/*.md` (excluding `README.md`) — pending changeset entries - Read `CHANGELOG.md` and any subpackage `packages/*/CHANGELOG.md` for already-recorded entries. 2. **Understand user-facing impact** For each change, read the actual implementation when needed; **do not infer behavior from commit messages or PR titles alone**. Skip: - Internal refactors with no externally visible behavior change - Tests, CI, type-only changes - Tooling / build-system changes that do not change how users invoke the CLI If after the scan you conclude there is no user-facing impact, say so and stop. 3. **Keep release changelog syncing separate** Do not copy unreleased changesets into `docs/release-notes/changelog.md`. After a release is published, use the `sync-changelog` skill to sync `apps/pythinker-code/CHANGELOG.md` into the docs site with release dates and section classification. 4. **Update user docs** Following the rules in `docs/AGENTS.md`, edit the affected pages under `docs/`. Match terminology with the term table in `docs/AGENTS.md` and the existing wording in surrounding pages. Cover all relevant sections: - Guides (getting-started, use cases, interaction, sessions, IDE integration) - Customization (skills, agents, MCP, hooks, plugins, etc.) - Configuration (config files, env vars, providers, data locations) - Reference (CLI subcommands, slash commands, keyboard shortcuts) - Release notes (`docs/release-notes/breaking-changes.md` if a breaking change is involved) ## Rules and conventions - **Terminology**: Use the term table in `docs/AGENTS.md` exactly. Do not invent synonyms. - **Scope discipline**: Only update sections affected by the recent changes. Do not opportunistically rewrite unrelated docs. - **Public examples**: Never write real internal endpoints, key names, account names, or service names into docs. Use neutral placeholders such as `https://api.example.com/v1`, `https://registry.example.com/v1/models/api.json`, `example.test`, and `YOUR_API_KEY`. - **Breaking changes**: If any change is breaking, also update `docs/release-notes/breaking-changes.md` (under `## Unreleased`) with `**Affected**` + `**Migration**` subsections. - **Do not edit auto-synced files**: `docs/release-notes/changelog.md` is regenerated by the sync script; any manual edit will be overwritten. ## Common mistakes - Describing what code changed instead of what the user can now do (or can no longer do). - Adding a new section heading per feature instead of weaving the change into existing prose.