Feature how-to article

# Feature how-to article

Use when drafting a customer-facing or internal how-to article from a feature and its requirements.

## Workflow

1. Read the target feature and all of its requirements before drafting. Treat requirements as the source of truth for customer-visible behavior when the description is broad. If the feature is not specified, ask for it.
2. Determine the audience. Default to external customers unless the user says internal. For external audiences, prefer plain language and spell out permission roles in full.
3. Check whether the record is publishable. Identify missing details that would create support debt if guessed: exact UI labels, permissions, plan availability, limits, shipped versus planned behavior, and data handling. Say what is missing before drafting, then draft only when enough confirmed behavior exists to be useful.
4. Draft the article around the user's job to be done. Open with one sentence naming the capability and when it is useful.
5. Write the procedural content. In **How it works** , use numbered steps in the order the reader performs them. Bold UI labels and use the exact product copy when it is confirmed. Use the arrow symbol for navigation paths.
6. Write the supporting guidance. **Tips** covers non-obvious usage notes, caveats, or shortcuts. **FAQs** covers the real questions the feature raises, such as permissions, plans, limits, and existing-data behavior.
7. Close with outcome, not promotion. End with a short **Why it matters** section framed as user value.

## Rules

- Do not invent steps, settings, or system behavior. If an answer is not confirmed, say it needs confirmation.
- Keep the article at 500 words or fewer unless the user asks otherwise
- Never use marketing superlatives or guarantees
- Reference the source feature by reference number and name outside the article body
- Do not publish or imply publication happened
- When multiple features are provided, combine them only when the workflow is truly unified. Otherwise, explain why separate articles are clearer
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
<preface naming the source feature by reference number and title, plus any details to confirm before publishing>  
  
### Overview  
### How it works  
### Tips  
### FAQs  
### Why it matters
```

## Quality checks

- The draft is grounded in the feature and its requirements
- The opener names the capability clearly
- Steps are ordered correctly
- UI labels are bolded only when confirmed
- Permissions and limits are stated or explicitly marked for confirmation
- The draft avoids invented behavior and unnecessary marketing language
- The article stays within the length target