home / skills / thebushidocollective / han / create-blueprint

This skill researches a system in the codebase and generates or updates its blueprint documentation at the repository root blueprints directory.

npx playbooks add skill thebushidocollective/han --skill create-blueprint

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.1 KB
---
name: create-blueprint
description: Research a specific system and create or update its blueprints/ documentation
---

## Name

blueprints:create-blueprint - Generate or update blueprint documentation for a specific system

## Synopsis

```text
/blueprint <system-name>
```

## Description

Research a specific system in the codebase and create or update its technical blueprint documentation in the `blueprints/` directory at the **repository root**.

## Important: Blueprint Location

**CRITICAL:** Blueprints MUST be created at the repository root, never in subdirectories or packages.

- `{repo-root}/blueprints/{system-name}.md`
- `{repo-root}/packages/foo/blueprints/{system-name}.md`
- `{repo-root}/src/blueprints/{system-name}.md`

Blueprints are repository-wide system design documents. A single system may span multiple packages or directories, but there should be ONE blueprint at the repo root describing the entire system.

## Implementation

You are tasked with creating or updating technical blueprint documentation for a specific system.

## Process

### 1. Identify the Target System

The user will specify which system to document. This could be:

- A feature name (e.g., "authentication", "caching")
- A directory path (e.g., "lib/commands/mcp")
- A component name (e.g., "MCP server", "hook dispatcher")

### 2. Deep Research Phase

Thoroughly investigate the system:

1. **Find all relevant files** using Glob and Grep
2. **Read the implementation** to understand:
   - Entry points and public APIs
   - Internal architecture and data flow
   - Dependencies and integrations
   - Configuration options
   - Error handling and edge cases
3. **Check for existing documentation**:
   - README files in the directory
   - Inline code comments
   - Existing blueprints/ files
   - Test files (they document expected behavior)

### 3. Check for Duplicates

Before creating a new blueprint, check what already exists:

1. **List all blueprints**: Use `Glob("blueprints/*.md")` to see all existing blueprint files
2. **Search by keyword**: Use `Grep` to search frontmatter in `blueprints/` for related topics
3. **Read related blueprints**: Use `Read("blueprints/{related-name}.md")` to check for overlap
4. **Identify overlapping systems** that should be documented together

### 4. Write the Blueprint

Use the `Write` tool to create or update the blueprint file at `blueprints/{system-name}.md`.

The file MUST include YAML frontmatter:

```markdown
---
name: system-name
summary: Brief one-line description
---

# {System Name}
...
```

The blueprint content should follow this structure:

```markdown
---
name: system-name
summary: Brief one-line description
---

# {System Name}

{Brief one-line description}

## Overview

{2-3 paragraphs explaining the system's purpose, why it exists, and its role in the larger system}

## Architecture

{Describe the system structure}

### Components

- **{Component A}** - {description}
- **{Component B}** - {description}

### Data Flow

{How data moves through the system}

### Dependencies

- {Dependency 1} - {why it's needed}
- {Dependency 2} - {why it's needed}

## API / Interface

### Public Functions/Methods

#### `functionName(params)`

{Description}

**Parameters:**
- `param1` (type) - {description}

**Returns:** {description}

### Commands

{If applicable, document CLI commands}

### Configuration

{Document configuration options}

## Behavior

### Normal Operation

{How the system behaves under normal conditions}

### Error Handling

{How errors are handled}

### Edge Cases

{Notable edge cases and how they're handled}

## Files

Key implementation files:

- `path/to/main.ts` - {brief description}
- `path/to/helper.ts` - {brief description}

## Related Systems

- [{Related System}](./related-system.md) - {relationship description}
```

## Output

After completing the research and documentation:

1. Create/update the blueprint using `Write("blueprints/{system-name}.md", content)`
2. Report what was documented and any related systems that may need documentation

**Note:** The blueprint index at `.claude/rules/blueprints/blueprints-index.md` is automatically regenerated by the SessionStart hook - you don't need to manually update it.

Overview

This skill researches a specific system in the codebase and generates or updates a canonical blueprint document at the repository root. It produces a structured technical blueprint (with required frontmatter and sections) that describes the system end-to-end. The result is a single, repo-root blueprint per system that covers architecture, API, data flow, configuration, and related systems.

How this skill works

Given a target system name or path, the skill locates all relevant files using glob and grep patterns and reads implementation, tests, and existing docs. It checks for existing blueprints to avoid duplication and identifies overlapping systems to document together. Finally, it writes or updates the file at blueprints/{system-name}.md using the required YAML frontmatter and standardized blueprint structure.

When to use it

  • You need a consolidated system design document for a feature, component, or directory.
  • Onboarding engineers who must understand system boundaries, APIs, and interactions.
  • Before major refactors or cross-team work to capture current behavior and contracts.
  • When tests, code, and README fragments are scattered and need a single source of truth.
  • To establish consistent documentation format across multiple systems in a repository.

Best practices

  • Always create the blueprint at the repository root: blueprints/{system-name}.md.
  • Search existing blueprints first to avoid duplicate or fragmented documentation.
  • Include implementation file references and tests to make behavior verifiable.
  • Document public APIs, configuration options, error handling, and notable edge cases.
  • Keep the overview and architecture sections concise; use components and data flow diagrams where helpful.

Example use cases

  • Documenting the authentication subsystem spanning multiple packages so teams share one source of truth.
  • Creating a blueprint for a CLI command folder (e.g., lib/commands/mcp) to capture entry points and options.
  • Updating an existing blueprint after a refactor that moves logic between packages.
  • Generating documentation for a service integration (e.g., payment gateway) including dependencies and failure modes.

FAQ

Where must the blueprint file be placed?

Blueprints must be written to blueprints/{system-name}.md at the repository root. Do not place blueprints inside packages or subdirectories.

How does the skill avoid creating duplicate blueprints?

It lists existing blueprints and greps their frontmatter and contents to detect overlap, then suggests combining related systems into a single repo-root blueprint.