원클릭으로
howto-docs
How-To guide patterns for documentation - task-oriented guides for users with specific goals
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
How-To guide patterns for documentation - task-oriented guides for users with specific goals
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Create Claude Code skills with best practices, structure, validation, and testing. Use when designing or refining skills, prompts, references, or supporting files.
Use when the user wants a cited, structured read of local documents and project knowledge. Triggers on: "analyze these docs", "scan my project for context", "read the docs folder", "summarize what's in .beagle/concepts/", "extract context from docs/", "what's in this folder", "go read everything in X and tell me what's there". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), web research (use web-research), LLM-as-judge evaluation (use llm-judge), or document editing (use humanize-beagle). Produces a written scan plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
Use when the user has a fuzzy idea and wants to shape it into a concrete project spec before planning or building. Triggers on: "brainstorm this", "I have an idea for...", "help me think through this project", "what should I build", "spec this out". Also catches vague feature descriptions needing structured questioning to clarify scope. Does NOT write code, plan implementation, review strategy docs, or run strategy interviews — produces a WHAT/WHY spec through dialogue, not a HOW plan.
Use when the user wants to pressure-test a product, internal-tool, or OSS concept against Amazon's Working Backwards PRFAQ gauntlet before committing to a spec. Triggers on: "work backwards", "write a PRFAQ", "press release first", "is this idea worth building", "pressure-test this concept", "filter this before brainstorm", "is this a real product". Also catches solution-first pitches ("I want to build X that does Y") and technology-first pitches ("use AI to...") that need customer-first filtering. Produces a binary pass/fail verdict, not a polished doc. Hardcore coaching — direct, skeptical, concrete. On pass, hands off to brainstorm-beagle with a concept brief. Does NOT write code, plan implementation, scaffold projects, or draft specs.
Use when the user wants web research: gathering cited, multi-angle evidence on a specific question. Triggers on: "research X for me", "do web research on", "look up sources for", "find citations for", "gather evidence on", "what does the web say about X". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), local file search, LLM-as-judge evaluation, or paywalled/auth-gated scraping. Produces a written plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
generate release notes for changes since a given tag
| name | howto-docs |
| description | How-To guide patterns for documentation - task-oriented guides for users with specific goals |
| user-invocable | false |
| autoContext | {"whenUserAsks":["how to guide","how-to guide","howto guide","task guide","procedural guide","step-by-step guide","how to documentation"]} |
| dependencies | ["docs-style"] |
This skill provides patterns for writing effective How-To guides in documentation. How-To guides are task-oriented content for users who have a specific goal in mind.
Target readers:
How-To guides are NOT:
Use this structure for all how-to guides:
---
title: "How to [achieve specific goal]"
description: "Learn how to [goal] using [product/feature]"
---
# How to [Goal]
Brief intro (1-2 sentences): what you'll accomplish and why it's useful.
## Prerequisites
- [What user needs before starting]
- [Required access, tools, or setup]
- [Any prior knowledge assumed]
## Steps
### 1. [Action verb] the [thing]
[Clear instruction with expected outcome]
<Note>
[Optional tip or important context]
</Note>
### 2. [Next action]
[Continue with clear, single-action steps]
```bash
# Example command or code if needed
[Each step should be one discrete action]
[How to confirm success - what should user see/experience?]
## Writing Principles
### Title Conventions
- **Always start with "How to"** - makes the goal immediately clear
- Use active verbs: "How to configure...", "How to deploy...", "How to migrate..."
- Be specific: "How to add SSO authentication" not "How to set up auth"
### Step Structure
1. **One action per step** - if you write "and", consider splitting
2. **Start with action verbs**: Click, Navigate, Enter, Select, Run, Create
3. **Show expected outcomes** after key steps:
```markdown
### 3. Save the configuration
Click **Save**. You should see a success message: "Configuration updated."
Write from the user's perspective, not the product's:
| Avoid (product-centric) | Prefer (user-centric) |
|---|---|
| "The API accepts..." | "Send a request to..." |
| "The system will..." | "You'll see..." |
| "This feature allows..." | "You can now..." |
Be explicit about what's needed:
## Prerequisites
- An active account with admin permissions
- API key generated from Settings > API
- Node.js v18 or later installed
- Completed the [initial setup guide](/getting-started)
For numbered procedures, use a Steps component:
<Steps>
<Step title="Create a new project">
Navigate to the dashboard and click **New Project**.
</Step>
<Step title="Configure settings">
Enter your project name and select a region.
</Step>
<Step title="Deploy">
Click **Deploy** to launch your project.
</Step>
</Steps>
When showing different approaches:
<CodeGroup>
```bash npm
npm install @company/sdk
yarn add @company/sdk
pnpm add @company/sdk
```
<Warning>
This action cannot be undone. Make sure to backup your data first.
</Warning>
<Note>
This step may take 2-3 minutes to complete.
</Note>
<Tip>
You can also use keyboard shortcut Cmd+K for faster navigation.
</Tip>
For optional details that shouldn't interrupt flow:
<Expandable title="Advanced options">
If you need custom configuration, you can also set:
- `timeout`: Request timeout in milliseconds
- `retries`: Number of retry attempts
</Expandable>
---
title: "How to set up webhook notifications"
description: "Learn how to configure webhooks to receive real-time event notifications"
---
# How to Set Up Webhook Notifications
Configure webhooks to receive instant notifications when events occur in your account. This enables real-time integrations with your existing tools.
## Prerequisites
- Admin access to your account
- A publicly accessible HTTPS endpoint to receive webhooks
- Completed the [authentication setup](/getting-started/auth)
## Steps
<Steps>
<Step title="Navigate to webhook settings">
Go to **Settings** > **Integrations** > **Webhooks**.
</Step>
<Step title="Add a new webhook endpoint">
Click **Add Endpoint** and enter your webhook URL:
```
https://your-domain.com/webhooks/receiver
```
<Note>
Your endpoint must use HTTPS and be publicly accessible.
</Note>
</Step>
<Step title="Select events to subscribe">
Choose which events should trigger notifications:
- `user.created` - New user sign up
- `payment.completed` - Successful payment
- `subscription.cancelled` - Subscription ended
Select at least one event to continue.
</Step>
<Step title="Save and get your signing secret">
Click **Create Webhook**. Copy the signing secret shown - you'll need this to verify webhook authenticity.
<Warning>
Store the signing secret securely. It won't be shown again.
</Warning>
</Step>
</Steps>
## Verify it worked
Send a test event by clicking **Send Test** next to your webhook. You should receive a POST request at your endpoint with this structure:
```json
{
"event": "test.webhook",
"timestamp": "2024-01-15T10:30:00Z",
"data": {}
}
Check your endpoint logs to confirm receipt.
## Checklist for How-To Guides
Before publishing, verify:
- [ ] Title starts with "How to" and describes a specific goal
- [ ] Prerequisites section lists all requirements
- [ ] Each step is a single, clear action
- [ ] Action verbs start each step (Click, Enter, Select, Run)
- [ ] Expected outcomes shown after key steps
- [ ] Verification section explains how to confirm success
- [ ] Troubleshooting covers common issues
- [ ] Next steps link to related content
- [ ] No unnecessary explanations - links to concepts instead
- [ ] Written from user perspective, not product perspective
## When to Use How-To vs Other Doc Types
| User's mindset | Doc type | Example |
|---------------|----------|---------|
| "I want to learn" | Tutorial | "Getting started with our API" |
| "I want to do X" | How-To | "How to configure SSO" |
| "I want to understand" | Explanation | "How our caching works" |
| "I need to look up Y" | Reference | "API endpoint reference" |
## Related Skills
- **docs-style**: Core writing conventions and components
- **tutorial-docs**: Tutorial patterns for learning-oriented content
- **reference-docs**: Reference documentation patterns
- **explanation-docs**: Conceptual documentation patterns