Help us improve
Share bugs, ideas, or general feedback.
From blueprints
Creates or updates technical blueprint documentation for features, APIs, and architecture. Searches existing blueprints first via Glob/Grep to avoid duplication, using standard structure and frontmatter.
npx claudepluginhub thebushidocollective/han --plugin blueprintsHow this skill is triggered — by the user, by Claude, or both
Slash command
/blueprints:blueprints-writingThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Technical blueprints document **how systems work internally**. They differ from user documentation (how to use) and README files (project overview).
Researches codebase systems and generates or updates technical blueprint docs in repo root blueprints/ directory with architecture diagrams and data flows.
Creates long-form technical documentation from existing codebases by analyzing architecture, patterns, and implementation details.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Technical blueprints document how systems work internally. They differ from user documentation (how to use) and README files (project overview).
Write blueprints for:
Skip blueprints for:
IMPORTANT: Always check for existing blueprints before creating new ones, and use the proper frontmatter format.
# 1. List existing blueprints
Glob("blueprints/*.md")
# 2. Search for related blueprints by keyword
Grep("keyword", path: "blueprints/", output_mode: "files_with_matches")
# 3. Read existing blueprint if updating
Read("blueprints/authentication.md")
# 4. Write the blueprint with frontmatter
Write("blueprints/system-name.md", content_with_frontmatter)
The frontmatter format is:
---
name: system-name
summary: Brief one-line description
---
Use this structure for blueprint content:
---
name: system-name
summary: One-line description of what this system does.
---
# System Name
One-line description of what this system does.
## Overview
2-3 paragraphs covering:
- Why this system exists (problem it solves)
- What it does at a high level
- Where it fits in the larger architecture
## Architecture
### Components
List major components:
- **ComponentA** - Purpose and responsibility
- **ComponentB** - Purpose and responsibility
### Data Flow
Describe how data moves through the system:
1. Input arrives via X
2. ComponentA processes and transforms
3. Result passed to ComponentB
4. Output returned/stored
### Dependencies
- **Dependency** - Why it's needed, what it provides
## API / Interface
### Functions
#### `functionName(param1, param2)`
Clear description of what the function does.
**Parameters:**
- `param1` (Type) - What this parameter controls
- `param2` (Type, optional) - Default behavior if omitted
**Returns:** Type - Description of return value
**Throws:** ErrorType - When this error occurs
**Example:**
```typescript
const result = functionName('value', { option: true });
| Option | Type | Default | Description |
|---|---|---|---|
optionA | boolean | false | What it controls |
Step-by-step description of typical execution flow.
How the system responds to:
Document non-obvious behaviors:
Key files and their roles:
src/main.ts:1-50 - Entry point, initializationsrc/processor.ts - Core processing logicsrc/types.ts - Type definitionsExample format:
- [Related System](./related-system.md) - How they interact
## Writing Style
### Be Precise
Bad: "The system handles errors gracefully"
Good: "Invalid input returns a ValidationError with the field name and reason"
### Document Behavior, Not Implementation
Bad: "Uses a for loop to iterate through items"
Good: "Processes items sequentially, stopping at the first failure"
### Include Examples
Show, don't just tell:
```typescript
// Good: concrete example
const result = processItems(['a', 'b', 'c'], { parallel: true });
// Returns: { processed: 3, failed: 0 }