Overview

Choosing Your Workflow

Not every task needs the same level of planning. Use the right tool for the job:

Workflow	When to Use	Commands
My Kit	Bug fixes, minor tweaks, simple features	/mykit.*
Spec Kit	Complex features, multi-file changes, new systems	/speckit.*

Quick Decision Guide

Is this a bug fix or minor tweak?
  → Yes: Use My Kit (/mykit.quickfix)
  → No: Continue...

Can it be completed in under a day?
  → Yes: Use My Kit with quick spec
  → No: Continue...

Does it affect multiple systems or require design decisions?
  → Yes: Use Spec Kit (/speckit.*)
  → No: Use My Kit

Complexity Indicators

Use My Kit When:

• Single file change
• Bug fix with clear cause
• Minor UI tweak
• Documentation update
• Configuration change
• Estimated time < 4 hours

Use Spec Kit When:

• New feature or capability
• Multiple files affected
• API or data model changes
• Requires design decisions
• Has dependencies on other work
• Estimated time > 1 day
• Needs stakeholder alignment

My Kit Workflow

Fast, streamlined workflow for simple tasks:

/mykit.backlog → /mykit.quickfix → /mykit.validate → /mykit.commit → /mykit.pr

Commands

Command	Purpose
/mykit.backlog	Select issue from backlog
/mykit.quickfix	Streamlined fix workflow
/mykit.validate	Run quality checks
/mykit.commit	Create conventional commit
/mykit.pr	Create pull request
/mykit.release	Create release

My Kit Process

1. Select Issue: /mykit.backlog to pick a task
2. Quick Fix: /mykit.quickfix handles branch creation and guides implementation
3. Validate: /mykit.validate --fix runs checks and auto-fixes issues
4. Commit: /mykit.commit creates conventional commit with changelog
5. PR: /mykit.pr creates pull request with quality report

Spec Kit Workflow

Comprehensive workflow for complex features:

/speckit.init → /speckit.write → /speckit.review → Implementation → /mykit.validate → /mykit.pr

Commands

Command	Purpose
/speckit.init	Initialize spec for issue
/speckit.write	Generate spec from template
/speckit.review	Review spec completeness
/speckit.approve	Mark spec as approved

Spec Kit Process

1. Initialize: /speckit.init creates spec directory and template
2. Write Spec: Define problem, goals, user stories, acceptance criteria
3. Review: /speckit.review validates completeness
4. Approve: Get sign-off before implementation
5. Implement: Build against the spec
6. Validate: /mykit.validate runs quality checks
7. Release: /mykit.pr and /mykit.release

Spec Directory Structure

Full specs are stored in the specs/ directory:

specs/
├── 26-spec-driven-development-docs/
│   └── spec.md
├── 28-update-spec-driven-docs/
│   └── spec.md
└── {issue#}-{short-name}/
    └── spec.md

When to Switch Workflows

Started with My Kit but scope grew? Switch to Spec Kit:

• Original estimate exceeded by 2x
• Scope expanded beyond initial issue
• Design decisions needed
• Multiple stakeholders involved
• Breaking changes required

How to switch: Create a spec document, get it reviewed, then continue implementation.

Key Topics

• Specification Format - Full spec and quick spec templates
• Feature Specs - Writing specifications for features, APIs, and components
• Validation - Quality checks for both workflows
• Implementation Workflow - Step-by-step guides for both workflows