home / skills / popup-studio-ai / bkit-claude-code / bkit-templates

bkit-templates skill

/skills/bkit-templates

This skill helps you generate PDCA documents with consistent structure using Plan, Design, Analysis, and Report templates.

npx playbooks add skill popup-studio-ai/bkit-claude-code --skill bkit-templates

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

Files (1)
SKILL.md
4.7 KB
---
name: bkit-templates
description: |
  PDCA document templates for consistent documentation.
  Plan, Design, Analysis, and Report templates with proper structure.

  Use proactively when generating PDCA documents to ensure consistent format.

  Triggers: template, plan document, design document, analysis document, report,
  템플릿, 계획서, 설계서, 분석서, 보고서, テンプレート, 計画書, 設計書, 模板, 计划书, 设计书,
  plantilla, documento de plan, documento de diseño, documento de análisis, informe,
  modèle, document de plan, document de conception, document d'analyse, rapport,
  Vorlage, Plandokument, Designdokument, Analysedokument, Bericht,
  modello, documento di piano, documento di progettazione, documento di analisi, rapporto

  Do NOT use for: code implementation, deployment, or non-documentation tasks.
---

# bkit Document Templates

> Use these templates when generating PDCA documents.

## Available Templates

| Template | Path | Purpose |
|----------|------|---------|
| Plan | `${CLAUDE_PLUGIN_ROOT}/templates/plan.template.md` | Feature planning |
| Design | `${CLAUDE_PLUGIN_ROOT}/templates/design.template.md` | Technical design |
| Analysis | `${CLAUDE_PLUGIN_ROOT}/templates/analysis.template.md` | Gap analysis |
| Report | `${CLAUDE_PLUGIN_ROOT}/templates/report.template.md` | Completion report |
| Index | `${CLAUDE_PLUGIN_ROOT}/templates/_INDEX.template.md` | Document index |
| CLAUDE | `${CLAUDE_PLUGIN_ROOT}/templates/CLAUDE.template.md` | CLAUDE.md template |

## Template Usage

### Plan Template
For **P**lan phase - feature planning before design.

Key sections:
- Overview & Purpose
- Scope (In/Out)
- Requirements (Functional/Non-Functional)
- Success Criteria
- Risks & Mitigation

### Design Template
For **D**o phase - technical design before implementation.

Key sections:
- Architecture (diagrams, data flow)
- Data Model (entities, relationships)
- API Specification (endpoints, request/response)
- UI/UX Design (layouts, components)
- Error Handling
- Security Considerations
- Test Plan
- Implementation Guide

### Analysis Template
For **C**heck phase - gap analysis between design and implementation.

Key sections:
- Design vs Implementation comparison
- Missing features
- Inconsistencies
- Quality metrics
- Recommendations

### Report Template
For **A**ct phase - completion report and lessons learned.

Key sections:
- Summary of completed work
- Metrics (LOC, test coverage, etc.)
- Issues encountered
- Lessons learned
- Future improvements

## Document Output Paths

```
docs/
├── 01-plan/
│   └── features/
│       └── {feature}.plan.md
├── 02-design/
│   └── features/
│       └── {feature}.design.md
├── 03-analysis/
│   └── features/
│       └── {feature}.analysis.md
└── 04-report/
    └── features/
        └── {feature}.report.md
```

## Variable Substitution

Templates use `{variable}` syntax:
- `{feature}`: Feature name
- `{date}`: Creation date (YYYY-MM-DD)
- `{author}`: Document author

## Pipeline Templates

Additional templates for Development Pipeline phases:
- `${CLAUDE_PLUGIN_ROOT}/templates/pipeline/` directory

---

## Document Standards

### File Naming Rules

```
{number}_{english_name}.md      # 01_system_architecture.md
{number}-{english_name}.md      # 01-system-architecture.md
{feature}.{type}.md             # login.design.md
```

### Common Header

All documents should include:

```markdown
# {Document Title}

> **Summary**: {One-line description}
>
> **Author**: {Name}
> **Created**: {YYYY-MM-DD}
> **Last Modified**: {YYYY-MM-DD}
> **Status**: {Draft | Review | Approved | Deprecated}

---
```

### Version Control

Track changes within documents:

```markdown
## Version History

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | 2024-12-01 | Initial draft | Kay |
| 1.1 | 2024-12-05 | Added API spec | Kay |
```

### Cross-References

Link related documents:

```markdown
## Related Documents
- Plan: [login.plan.md](../01-plan/features/login.plan.md)
- Design: [login.design.md](../02-design/features/login.design.md)
- Analysis: [login.analysis.md](../03-analysis/features/login.analysis.md)
```

### Status Tracking

Use _INDEX.md in each folder:

| Status | Meaning | Claude Behavior |
|--------|---------|-----------------|
| ✅ Approved | Use as reference | Follow as-is |
| 🔄 In Progress | Being written | Notify of changes |
| ⏸️ On Hold | Temporarily paused | Request confirmation |
| ❌ Deprecated | No longer valid | Ignore |

### Conflict Resolution

- **Code vs Design mismatch**: Code is truth, suggest document update
- **Multiple versions**: Reference only the latest version

Overview

This skill provides PDCA document templates for consistent planning, design, analysis, and reporting. It packages ready-made Plan, Design, Analysis, and Report templates with standard headers, versioning, and file structure to accelerate and standardize documentation. Use it proactively when generating PDCA documents to ensure consistent format and traceability.

How this skill works

The skill supplies markdown templates that enforce a uniform structure: common header, version history, cross-references, and status tracking. Each template targets a PDCA phase (Plan, Design, Analysis, Report) and includes recommended sections like requirements, architecture, gap comparisons, and lessons learned. Variables such as {feature}, {date}, and {author} are substituted into filenames and headers so generated documents fit the repo layout and naming rules.

When to use it

  • When creating a new feature plan before design work
  • When documenting technical architecture and API specifications
  • When performing gap analysis between design and implementation
  • When producing a completion report and lessons learned
  • When you need consistent headers, version history, and cross-references

Best practices

  • Populate the common header (Summary, Author, Dates, Status) for every document
  • Follow the file-naming conventions and place files in the prescribed docs/ folders
  • Keep version history up to date with concise change notes and dates
  • Link related Plan, Design, Analysis, and Report documents using cross-references
  • Treat code as the source of truth when resolving design vs implementation mismatches

Example use cases

  • Create a feature.plan.md before starting implementation to capture scope, requirements, success criteria, and risks
  • Draft a feature.design.md with architecture diagrams, data models, API specs, and test plans
  • Run a feature.analysis.md to compare design against implemented code and list missing items and quality metrics
  • Publish a feature.report.md at completion summarizing metrics, issues, lessons learned, and future improvements
  • Use _INDEX.md files to surface document status and direct reviewers to the latest approved artifacts

FAQ

Which template should I use first?

Start with the Plan template to capture scope and success criteria, then produce Design, Analysis, and Report in sequence following PDCA.

How do I name files?

Use the documented naming rules (numeric prefixes or feature.type.md) and place files under the matching docs/NN-... folders.

What if code and design differ?

Treat code as truth: update design or document the discrepancy in Analysis with recommendations and next steps.