# Doc Feat Desc

> Use when the user wants user-facing docs for an implemented feature. Inspect the real implementation first, then write help-center, site-copy, and in-product docs under `doc/{requirement-name}/`.

- Skill: `lencamo/doc-feat-desc` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add lencamo/doc-feat-desc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lencamo/doc-feat-desc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lencamo (https://skillmd.com/u/lencamo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lencamo/doc-feat-desc

---


# Doc Feat Desc

Generate three user-facing docs for an already implemented feature and write them to disk.

Read [references/workspace-projects.md](references/workspace-projects.md) for repo targeting and requirement naming.  
Read [references/doc-variants.md](references/doc-variants.md) for structure, tone, and quality checks.

## Use When

- The user wants docs for a real feature, component, page, API, or module
- You need all three outputs:
  - `help-center-full.md`
  - `official-site-copy.md`
  - `in-product-short.md`
- The docs must come from the real implementation
- The result should be saved under `doc/<requirement-name>/`

## Do Not Use

- For internal architecture docs, ADRs, migration plans, or developer-only docs
- For API reference generation from specs alone
- For speculative copy for features that do not exist yet
- For one-off README edits, release notes, or a single short paragraph

## Core Rules

- Follow the user's language unless another language is explicitly requested
- Keep all three docs in the same language
- Read the implementation before writing
- Do not invent capabilities or hide uncertainty
- Use real product labels, entry names, and terminology
- Keep the docs user-facing and concise

## Workflow

1. Resolve the target repo, subject, requirement name, and output language
2. Read the main implementation and enough nearby code or UI copy to confirm behavior
3. If docs already exist, read them first and preserve correct naming
4. Create `doc/<requirement-name>/` if it does not exist
5. Create or update:
   - `help-center-full.md`
   - `official-site-copy.md`
   - `in-product-short.md`
6. Write the three Markdown files into `doc/<requirement-name>/`
7. Reply with the repo, directory, file paths, and any key assumptions

## Output Rules

- Keep the fixed filenames unless the user explicitly asks otherwise
- Do not create extra README, notes, changelog, or process files
- Keep formatting simple Markdown
- Do not turn internal implementation details into user-facing language