product-context-docs
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/productand/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
TODOwhen 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.
More from generaljerel/chalk-skills
python-clean-architecture
Clean architecture patterns for Python services — service layer, repository pattern, domain models, dependency injection, error hierarchy, and testing strategy
23create-handoff
Generate a handoff document after implementation work is complete — summarizes changes, risks, and review focus areas for the review pipeline. Use when done coding and ready to hand off for review.
16create-review
Bootstrap a local AI review pipeline and generate a paste-ready review prompt for any reviewer agent. Use after creating a handoff or when ready to get an AI code review.
15fix-findings
Fix findings from the active review session — reads reviewer findings files, applies fixes by priority, and updates the resolution log. Use after pasting reviewer output into findings files.
15fix-review
When the user asks to fix, address, or work on PR review comments — fetch review comments from a GitHub pull request and apply fixes to the local codebase. Requires gh CLI.
15review-changes
End-to-end review pipeline — creates a handoff, generates a review (self-review or paste-ready for another provider), then offers to fix findings. Use when you want to review your changes before pushing.
13