Implement from Spec (with GitHub Spec Kit)

Step 6 of 6 in the Reverse Engineering to Spec-Driven Development process.

Estimated Time: Hours to days (depends on gaps) Prerequisites: Step 5 completed (all specs finalized, no [NEEDS CLARIFICATION] markers) Output: Fully implemented application with all specs marked ✅ COMPLETE

When to Use This Skill

Use this skill when:

• You've completed Step 5 (Complete Specification)

• All specifications in specs/ are finalized

• Implementation plans exist in specs/

• Ready to use /speckit.implement to build features

Trigger Phrases:

• "Implement missing features"

• "Use speckit to implement"

• "Build from specifications"

• "Run speckit implement"

What This Skill Does

Uses GitHub Spec Kit's implementation workflow to systematically build features:

• Use /speckit.tasks - Generate actionable task lists from implementation plans

• Use /speckit.implement - Execute tasks step-by-step for each feature

• Validate with /speckit.analyze - Verify implementation matches specs

• Update Specs Automatically - Spec Kit marks features ✅ COMPLETE as you implement

• Track Progress - Monitor completion via .specify/memory/ status markers

• Achieve 100% Completion - All specs implemented and validated

Key Benefit: Spec Kit's /speckit.implement command guides you through implementation plans, updates specs automatically, and validates work against acceptance criteria.

⚠️ Two Contexts: Handoff vs Standard Implementation

This skill works differently based on context:

Context A: Handoff (After Reverse Engineering)

When: Just completed Gears 1-5, on main branch, gaps identified What happens: Handoff procedure (celebrate, explain transition, offer feature branch setup)

Context B: Standard Implementation (Ongoing)

When: On feature branch (002-, 003-), working on specific feature What happens: Standard GitHub Spec Kit implementation workflow See: Process Overview below

The handoff only happens ONCE (after initial reverse engineering). After that, you always use standard /speckit.* workflow on feature branches.

GitHub Spec Kit Implementation Workflow

The standard Spec Kit workflow is:

/speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement → /speckit.analyze

For reverse engineering, we've already done the first two steps:

• ✅ /speckit.specify

• Done in Step 3 (created specifications)

• ✅ /speckit.plan

• Done in Step 3 (created implementation plans)

Now we use the remaining commands:

• /speckit.tasks

• Generate task lists

• /speckit.implement

• Build features

• /speckit.analyze

• Validate

Process Overview

Step 1: Review Implementation Roadmap

From docs/gap-analysis-report.md , review the phased plan:

Phase 1: P0 Critical (~12 hours)

• Essential features

• Security fixes

• Blocking issues

Phase 2: P1 High Value (~20 hours)

• Important features

• High user impact

• Key improvements

Phase 3: P2/P3 (~TBD)

• Nice-to-have

• Future enhancements

Confirm with user:

• Start with Phase 1 (P0 items)?

• Any blockers to address first?

• Time constraints?

Step 2: For Each Feature - Generate Tasks

Use /speckit.tasks to generate actionable tasks from implementation plan:

Example: Implement user authentication frontend

/speckit.tasks user-authentication-frontend

What this does:

• Reads specs/user-authentication-frontend.md

• Breaks down plan into specific, actionable tasks

• Creates task checklist

Output example:

Tasks: User Authentication Frontend

Based on implementation plan in specs/user-authentication-frontend.md

Tasks

• Create LoginPage component (app/login/page.tsx)
• Create RegistrationPage component (app/register/page.tsx)
• Create PasswordResetPage component (app/reset-password/page.tsx)
• Add Zod validation schemas (lib/validation/auth.ts)
• Create useAuth hook (hooks/useAuth.ts)
• Implement API integration (lib/api/auth.ts)
• Add loading states to all forms
• Add error handling and display
• Write component tests (LoginPage.test.tsx, etc.)
• Update routing configuration (app/layout.tsx)

Dependencies

• Backend API endpoints must be functional
• UI component library installed

Acceptance Criteria (from specification)

• User can register with email and password
• User can log in with credentials
• User can reset forgotten password
• JWT tokens stored securely
• Forms validate input before submission
• Loading states shown during API calls
• Error messages displayed clearly

Step 3: Implement Feature with /speckit.implement

Use /speckit.implement to execute the implementation plan:

Implement the feature step-by-step

/speckit.implement user-authentication-frontend

What this does:

• Loads tasks from /speckit.tasks output

• Walks through each task systematically

• Generates code for each task

• Tests implementation against acceptance criteria

• Updates specification status markers

• Commits changes with descriptive messages

Interactive flow:

/speckit.implement user-authentication-frontend

Starting implementation of: User Authentication Frontend Plan: specs/user-authentication-frontend.md

Task 1/10: Create LoginPage component

I'll create app/login/page.tsx with:

• Email/password form
• Form validation
• Submit handler
• Link to registration and password reset

[Code generated]

✅ Task 1 complete

Task 2/10: Create RegistrationPage component [...]

All tasks complete! Running validation...

✅ All acceptance criteria met ✅ Tests passing (8/8) ✅ No TypeScript errors

Updating specification status... user-authentication.md: ⚠️ PARTIAL → ✅ COMPLETE

Implementation complete!

Step 4: Validate Implementation

After implementing, use /speckit.analyze to verify:

/speckit.analyze

What it checks:

• Implementation matches specification

• All acceptance criteria met

• No inconsistencies with related specs

• Status markers accurate

If issues found:

⚠️ Issues detected:

1. user-authentication.md marked COMPLETE

   • Missing: Token refresh mechanism
   • Action: Add token refresh or update spec

2. Inconsistency with user-profile.md

   • user-profile depends on authentication
   • user-profile marked PARTIAL
   • Recommendation: Complete user-profile next

Fix any issues and re-run /speckit.analyze until clean.

Step 5: Update Progress and Continue

After each feature:

Check progress:

/speckit.analyze

Shows: X/Y features complete

Update gap report:

• Mark feature as ✅ COMPLETE

• Update overall completion percentage

• Move to next priority feature

Commit changes:

git commit -m "feat: implement user authentication frontend (user-authentication.md)"

Select next feature:

• Follow prioritized roadmap

• Choose next P0 item, or move to P1 if P0 complete

Step 6: Iterate Until 100% Complete

Repeat Steps 2-5 for each feature in the roadmap:

Phase 1: P0 Critical

/speckit.tasks fish-management-ui /speckit.implement fish-management-ui /speckit.analyze

/speckit.tasks photo-upload-api /speckit.implement photo-upload-api /speckit.analyze

Phase 2: P1 High Value

/speckit.tasks analytics-dashboard /speckit.implement analytics-dashboard /speckit.analyze

Continue until all features complete...

Track progress:

• Phase 1: 3/3 complete (100%) ✅

• Phase 2: 2/4 complete (50%) 🔄

• Phase 3: 0/5 complete (0%) ⏳

Example: Complete Implementation Flow

1. Review roadmap

User: "Let's implement the missing features" Claude: Reviews docs/gap-analysis-report.md Claude: "I see 3 P0 items. Let's start with fish-management-ui?" User: "Yes, let's do it"

2. Generate tasks

/speckit.tasks fish-management-ui Output: 12 tasks identified

3. Implement

/speckit.implement fish-management-ui

Starting implementation...

Task 1/12: Create FishEditPage component [Code generated for app/fish/[id]/edit/page.tsx] ✅ Task 1 complete

Task 2/12: Add photo upload UI [Code generated for components/PhotoUpload.tsx] ✅ Task 2 complete

[... continues through all 12 tasks ...]

Implementation complete! ✅ All acceptance criteria met ✅ Tests passing (15/15)

4. Validate

/speckit.analyze ✅ No issues found fish-management.md: ⚠️ PARTIAL → ✅ COMPLETE

5. Commit

git commit -m "feat: complete fish management UI (fish-management.md)"

6. Next feature

Claude: "Phase 1 progress: 1/3 complete. Next: photo-upload-api?" User: "Yes"

Repeat...

Integration with Reverse Engineering Process

Your reverse-engineered codebase is now:

• ✅ Fully documented (Step 2)

• ✅ Formal specs created (Step 3)

• ✅ Gaps identified (Step 4)

• ✅ Clarifications resolved (Step 5)

• 🔄 Being implemented systematically (Step 6)

Spec Kit ensures:

• Implementation matches specs exactly

• Specs stay up-to-date with code

• No drift between docs and reality

• Continuous validation

After completion:

• Use /speckit.specify for new features

• Use /speckit.plan → /speckit.tasks → /speckit.implement for development

• Use /speckit.analyze to maintain consistency

• Your codebase is now fully spec-driven!

Success Criteria

After running this skill (implementing all features), you should have:

• ✅ All P0 features implemented (Phase 1 complete)

• ✅ All P1 features implemented (Phase 2 complete)

• ✅ P2/P3 features implemented or intentionally deferred

• ✅ All specifications marked ✅ COMPLETE

• ✅ /speckit.analyze shows no issues

• ✅ All tests passing

• ✅ Application at 100% completion

• ✅ Ready for production deployment

Ongoing spec-driven development established:

• New features start with /speckit.specify

• Implementation uses /speckit.plan → /speckit.tasks → /speckit.implement

• Continuous validation with /speckit.analyze

Best Practices

During Implementation

• One feature at a time - Don't start multiple features in parallel

• Follow the roadmap - Respect P0 → P1 → P2 priority order

• Use /speckit.implement

• Don't implement manually, let Spec Kit guide you

• Validate frequently - Run /speckit.analyze after each feature

• Commit often - Commit after each feature completion

• Update specs - If you discover new requirements, update specs first

Quality Standards

For each implementation:

• ✅ Meets all acceptance criteria

• ✅ Tests added and passing

• ✅ TypeScript types correct (if applicable)

• ✅ Error handling implemented

• ✅ Loading states for async operations

• ✅ Responsive design (if UI)

• ✅ Accessibility standards met

When Issues Arise

If /speckit.analyze finds problems:

• Fix the implementation to match spec, OR

• Update the spec if requirements changed

• Never leave specs and code out of sync

Continuous Spec-Driven Development

After completing the reverse engineering process:

For New Features

1. Create specification

/speckit.specify

2. Create implementation plan

/speckit.plan

3. Generate tasks

/speckit.tasks

4. Implement

/speckit.implement

5. Validate

/speckit.analyze

For Refactoring

1. Update affected specifications

/speckit.specify

2. Update implementation plan

/speckit.plan

3. Implement changes

/speckit.implement

4. Validate no regression

/speckit.analyze

For Bug Fixes

1. Update spec if bug reveals requirement gap

/speckit.specify

2. Fix implementation

[manual fix or /speckit.implement]

3. Validate

/speckit.analyze

Technical Notes

• Spec Kit's /speckit.implement generates code - review before committing

• Implementation plans should be detailed for best results

• /speckit.tasks output can be refined if tasks are too broad

• Use /speckit.clarify if you discover ambiguities during implementation

• Keep .specify/memory/ in version control

• specs/ is the source of truth

Final Outcome

You've transformed:

• Partially-complete codebase with no specs

• → Fully spec-driven development workflow

• → 100% implementation aligned with specifications

• → Continuous validation with /speckit.analyze

• → Sustainable spec-first development process

Your application is now:

• ✅ Fully documented

• ✅ Completely specified

• ✅ 100% implemented

• ✅ Continuously validated

• ✅ Ready for ongoing spec-driven development

Gear 6.5: Validate & Review

Before finalizing, let's ensure everything meets quality standards through systematic validation.

Step 1: Run Validation

Validate implementation against specs

/stackshift.validate --fix

This will:

• ✅ Run full test suite

• ✅ Validate TypeScript compilation

• ✅ Check spec compliance

• ✅ Categorize any issues

• ✅ Auto-fix issues (with --fix flag)

• ✅ Rollback if fixes fail

Expected result:

✅ VALIDATION PASSED

All tests passing: ✅ TypeScript compiling: ✅ Spec compliance: ✅ Code quality: ✅

🚀 Implementation is production-ready!

If validation finds issues, they'll be fixed automatically. If critical issues are found that can't be auto-fixed, I'll report them for manual resolution.

Step 2: Code Review

Perform comprehensive code review

/stackshift.review

This reviews across 5 dimensions:

• 🔍 Correctness - Works as intended, meets requirements

• 📏 Standards - Follows conventions, well documented

• 🔒 Security - No vulnerabilities, proper validation

• ⚡ Performance - Efficient, scalable implementation

• 🧪 Testing - Adequate coverage, edge cases handled

Expected result:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 Review Report ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ APPROVED

All quality checks passed Ready for deployment

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If issues are found, I'll provide specific feedback with line numbers and recommendations.

Step 3: Generate Spec Coverage Map

After validation passes, let's create the coverage map...

Final Step: Generate Spec Coverage Map

Now let's create a visual coverage map showing the relationship between your specifications and code:

Generate coverage map

I'll analyze all specs in .specify/specs/ and create:

• ASCII box diagrams - Visual map of each spec's files

• Reverse index - Which spec(s) cover each file

• Coverage statistics - Percentages by category

• Heat map - Visual coverage representation

• Gap analysis - Files not covered by specs

• Shared files - High-risk files used by multiple specs

Output: docs/spec-coverage-map.md

This provides crucial visibility into spec-code alignment and helps identify any gaps!

Spec Coverage Health Report

After generating the coverage map, I'll show you a summary:

📊 Spec Coverage Health Report

Overall Coverage: 91% (99/109 files)

By Category: Backend: 93% [████████████████░░] Frontend: 92% [████████████████░░] Infrastructure: 83% [███████████████░░░] Database: 100% [████████████████████] Scripts: 67% [█████████░░░░░░░░░]

Status: ✅ 12 specs covering 99 files ⚠️ 10 gap files identified (need review) 🔴 2 high-risk shared files (used by 4+ specs)

Full report: docs/spec-coverage-map.md

Congratulations! You've completed the 6-step Reverse Engineering to Spec-Driven Development process. Your codebase is now enterprise-grade, fully specified, and ready for sustainable development using GitHub Spec Kit or continue using StackShift to help develop new functionality. 🎉

Remember: Maintain the spec-driven workflow going forward:

• Requirements change → Update specs first (/speckit.specify )

• Plan implementation (/speckit.plan )

• Generate tasks (/speckit.tasks )

• Implement (/speckit.implement )

• Validate (/speckit.analyze )

This ensures specs and code never drift apart.