Generate user guide
Domain decomposition + IEEE SWEBOK documentation skills for Claude Code
npx -y skills add eroveda/blueprint-skills --skill generate-user-guideAssembled 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
Creates USER_GUIDE.md for end-users (not developers). Use when preparing onboarding material or end-user documentation. Do NOT use for API docs (use generate-api-catalog) or technical architecture (use generate-architecture-doc). Trigger with "generate user guide", "document for end users", or "create USER_GUIDE.md".
SKILL.md
2.9 KB, as published. Nobody here has run it
Generate User Guide
You create USER_GUIDE.md that helps actual users learn how to use the system.
Document Structure
# User Guide — [Project Name]
## Welcome
One paragraph: what the system is for and who should use it.
## Getting Started
### First Login
1. Step-by-step from first access to first useful action
2. Include screenshots/examples if relevant
3. End with: "You're ready to..."
### Setting Up Your Account
- Profile setup
- Initial configuration
- Inviting teammates (if applicable)
## Daily Usage
### For [Role 1]
Common tasks for this role, ordered by frequency:
#### [Task Name]
1. Go to [section]
2. Click/tap [action]
3. Fill in [fields]
4. Confirm with [action]
5. You'll see [result]
(Repeat for each common task)
### For [Role 2]
(Same structure)
## Understanding the System
### Statuses and What They Mean
For each status in the system:
- **[Status Name]** — Plain explanation, when to use it
- Example scenario
### Permissions
Plain-language explanation of who can do what:
- [Role 1] can: ...
- [Role 2] can: ...
- [Role 1] cannot: ...
## Common Scenarios
### Scenario: [Realistic situation]
"You need to [goal]. Here's how:"
1. ...
2. ...
3. ...
(3-5 realistic scenarios that cover 80% of usage)
## Troubleshooting
### "I can't [action]"
Probably because: [reason]
To fix: [steps]
### "I see the error: [message]"
This means: [explanation]
To fix: [steps]
## FAQs
### Question 1?
Answer in plain language.
### Question 2?
Answer.
## Getting Help
- Where to find help (link/email)
- Response time expectations
- What information to provide when asking for help
Style Rules
- Write for someone who has never used the system before
- Use "you" not "the user"
- Short paragraphs (max 3 sentences)
- One action per step
- Avoid jargon, but if unavoidable, explain in parentheses
- Use realistic examples (real names, real scenarios)
- Include error recovery for every flow
How to Generate
- Read FUNCTIONAL_FLOWS.md if it exists (reuse content)
- Identify the most common 5-10 user actions
- Write each as a step-by-step
- Include screenshots/mockups placeholders:
[Screenshot: action result] - Add troubleshooting based on validation errors in code
- Save as USER_GUIDE.md
Quality Checklist
- A new user can complete their first task without external help
- Every common task has a step-by-step
- Permissions are explained per role
- At least 3 troubleshooting entries for common errors
- FAQs cover real questions, not theoretical ones
- No technical jargon without explanation
- Tone is friendly but professional