Doc feat desc
Practical agent skills for real engineering workflows.
npx -y skills add lencamo/skills --skill doc-feat-descAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
2.2 KB, as published. Nobody here has run it
Doc Feat Desc
Generate three user-facing docs for an already implemented feature and write them to disk.
Read references/workspace-projects.md for repo targeting and requirement naming.
Read 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.mdofficial-site-copy.mdin-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
- Resolve the target repo, subject, requirement name, and output language
- Read the main implementation and enough nearby code or UI copy to confirm behavior
- If docs already exist, read them first and preserve correct naming
- Create
doc/<requirement-name>/if it does not exist - Create or update:
help-center-full.mdofficial-site-copy.mdin-product-short.md
- Write the three Markdown files into
doc/<requirement-name>/ - 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
Gives 0 of the 12 instructions most docs writing skills give
Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-06
- announce the skill at startin 54 of 1637, across 21 files
- convert legacy doc files before editingin 45 of 1637, across 7 files
- predict questions readers might askin 42 of 1637, across 3 files
- Generate clarifying questions for initial contextin 42 of 1637, across 3 files
- Create document scaffold with placeholder textin 42 of 1637, across 3 files
- Brainstorm content options for each sectionin 42 of 1637, across 3 files
- Test document with fresh context-less instancein 42 of 1637, across 3 files
- ask interview questions one at a timein 42 of 1637, across 26 files
- include exact file paths in every taskin 42 of 1637, across 15 files
- Apply surgical edits during refinementin 41 of 1637, across 2 files
- Offer structured workflow or freeformin 40 of 1637, across 1 file
- Ask for document meta-contextin 40 of 1637, across 1 file
Said here and by no other author read
- Keep all three docs in the same language
- Use real product labels and terminology
- Keep the docs user-facing and concise
- Read existing docs first to preserve naming
- Keep formatting simple Markdown
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.