Validation

Validation by Workflow

Both workflows include validation, but at different depths:

Workflow	Validation Type	Command
My Kit	Automated checks	/mykit.validate
Spec Kit	Spec review + automated checks	/speckit.review + /mykit.validate

---

My Kit Validation

Quick Validation

Run automated checks before commit:

/mykit.validate

Auto-Fix Mode

Automatically fix common issues:

/mykit.validate --fix

What Gets Checked

Check	Description
Lint	Code style and formatting
Types	TypeScript compilation
Build	Production build succeeds
Tests	Test suite passes

Validation Checklist (My Kit)

Before creating PR:

• bun run build passes
• No lint errors
• No type errors
• Tests pass (if applicable)
• Changes match issue description

---

Spec Kit Validation

Spec Review

Before implementation, validate the spec:

/speckit.review

What Gets Reviewed

Section	Validation
Problem Statement	Clear, specific, impactful
Goals	Measurable, bounded
Non-Goals	Explicit exclusions
User Stories	Proper format, testable criteria
Deliverables	Concrete, specified
Acceptance Criteria	Complete, verifiable

Spec Completeness Checklist

Before marking spec “Approved”:

• Problem statement defines the issue clearly
• Goals are specific and measurable
• Non-goals prevent scope creep
• User stories follow format
• Acceptance criteria are testable
• Deliverables are defined
• Implementation checklist is complete

Implementation Validation

During and after implementation:

/mykit.validate

Same checks as My Kit, plus:

• All acceptance criteria met
• Spec checklist items completed
• No scope creep beyond spec

---

Common Issues

Quick Spec Issues

Issue	Example	Fix
Too vague	”Fix the bug”	Specify which bug and how
No test plan	Missing “Test” section	Add verification steps
Scope creep	Adding unrelated changes	Stick to the issue

Full Spec Issues

Issue	Example	Fix
Vague problem	”Needs improvement”	Explain specific problem
Unmeasurable goals	”Make it better”	Define success criteria
Missing non-goals	No exclusions	Add explicit scope limits
Vague criteria	”Should work”	Make testable

---

Quality Gates

Gate 1: Before Implementation

My Kit:

• Issue exists
• Quick spec in issue/PR

Spec Kit:

• Spec document exists
• Spec reviewed and approved
• Status is “Approved”

Gate 2: Before PR

Both workflows:

• Build passes
• Lint clean
• Tests pass
• Changes match spec/issue

Gate 3: Before Merge

Both workflows:

• PR approved
• All checks pass
• No unresolved comments
• Changelog updated

---

Validation Commands

My Kit

Command	Purpose
/mykit.validate	Run all checks
/mykit.validate --fix	Auto-fix issues
/mykit.security	Security scan

Spec Kit

Command	Purpose
/speckit.review	Validate spec completeness
/speckit.approve	Mark spec approved
/mykit.validate	Run implementation checks

---

Best Practices

For My Kit

• Run /mykit.validate --fix before every commit
• Keep changes focused on the issue
• Don’t skip validation for “small” changes

For Spec Kit

• Get spec reviewed before writing code
• Update spec if requirements change
• Mark acceptance criteria as you complete them
• Don’t mark “Complete” until all criteria pass