Product Context Docs
Overview
Use this skill to create or update product context documentation under /docs in the current repository. Keep the docs accurate, concise, and easy to scan, and preserve existing content when it is already correct.
Workflow
- Locate the repo root (use the current working directory unless told otherwise).
- Read existing context first:
README.md, docs/ (if present), product briefs, and any architecture or design notes.
- Ask targeted questions only for missing essentials: product name, target users, key jobs-to-be-done, differentiators, primary user flows, core features, and any technical constraints.
- Ensure the folder structure exists:
/docs/product and /docs/tech.
- Create or update the default doc set (see below). Reuse existing content and update deltas rather than rewriting everything.
- Cross-link the docs where helpful (e.g., features to architecture, sitemap to features).
- Call out assumptions explicitly and mark placeholders as
TODO when information is missing.
Default Doc Set
Create or maintain these files as the minimum set:
/docs/product/product-profile.md (product summary, users, value, metrics)/docs/product/product-features.md (feature list, scope, status)/docs/product/sitemap.md (information architecture and core flows)/docs/tech/architecture.md (system overview, components, data flows)/docs/tech/tech-stack.md (languages, frameworks, infra, tooling)
Add additional docs only when requested or clearly needed (e.g., /docs/product/glossary.md, /docs/tech/security.md).
Templates
Use the templates in assets/templates/ as starting points. Copy the closest template into /docs/... and fill it with repo-specific details:
assets/templates/product-profile.mdassets/templates/product-features.mdassets/templates/sitemap.mdassets/templates/architecture.mdassets/templates/tech-stack.md
Writing Guidelines
- Use Markdown with short sections, tables, and bullet lists.
- Prefer concrete details over generic language.
- Use Mermaid diagrams for architecture when it clarifies flows.
- Keep each doc independently readable; repeat minimal context where needed.
- Preserve correct existing content and only change what is outdated or missing.
1---2name: product-context-docs3description: Create and update in-repo product context documentation in /docs (product profile, features, sitemap, architecture, tech stack). Use when asked to document a product, bootstrap /docs structure, or refresh product/tech context docs for a repo.4---5
6# Product Context Docs
7
8## Overview
9
10Use this skill to create or update product context documentation under `/docs` in the current repository. Keep the docs accurate, concise, and easy to scan, and preserve existing content when it is already correct.
11
12## Workflow
13
141. Locate the repo root (use the current working directory unless told otherwise).
152. Read existing context first: `README.md`, `docs/` (if present), product briefs, and any architecture or design notes.
163. Ask targeted questions only for missing essentials: product name, target users, key jobs-to-be-done, differentiators, primary user flows, core features, and any technical constraints.
174. Ensure the folder structure exists: `/docs/product` and `/docs/tech`.
185. Create or update the default doc set (see below). Reuse existing content and update deltas rather than rewriting everything.
196. Cross-link the docs where helpful (e.g., features to architecture, sitemap to features).
207. Call out assumptions explicitly and mark placeholders as `TODO` when information is missing.
21
22## Default Doc Set
23
24Create or maintain these files as the minimum set:
25
26- `/docs/product/product-profile.md` (product summary, users, value, metrics)
27- `/docs/product/product-features.md` (feature list, scope, status)
28- `/docs/product/sitemap.md` (information architecture and core flows)
29- `/docs/tech/architecture.md` (system overview, components, data flows)
30- `/docs/tech/tech-stack.md` (languages, frameworks, infra, tooling)
31
32Add additional docs only when requested or clearly needed (e.g., `/docs/product/glossary.md`, `/docs/tech/security.md`).
33
34## Templates
35
36Use the templates in `assets/templates/` as starting points. Copy the closest template into `/docs/...` and fill it with repo-specific details:
37
38- `assets/templates/product-profile.md`
39- `assets/templates/product-features.md`
40- `assets/templates/sitemap.md`
41- `assets/templates/architecture.md`
42- `assets/templates/tech-stack.md`
43
44## Writing Guidelines
45
46- Use Markdown with short sections, tables, and bullet lists.
47- Prefer concrete details over generic language.
48- Use Mermaid diagrams for architecture when it clarifies flows.
49- Keep each doc independently readable; repeat minimal context where needed.
50- Preserve correct existing content and only change what is outdated or missing.
majiayu000