Implement Direct

Implements a feature from an approved spec using judgment, without writing tests first. You verify the result manually.

Why This Skill Exists

TDD is valuable for complex logic but overkill for:

• •UI/layout changes
• •Simple CRUD operations
• •Features you'll verify visually
• •Rapid iteration where specs evolve

This skill implements with intelligence, not blind compliance.

When to Use

Prerequisites

1. •Spec document exists and is approved
2. •Path to spec provided as argument

Instructions

Step 1: Read and Understand the Spec

Read the spec document. Extract:

• •Problem Statement - What problem are we solving?
• •Acceptance Criteria - What does "done" look like?
• •Non-Goals - What are we NOT doing?
• •Security Considerations - What security patterns apply?
• •Technical Notes - Implementation hints

See shared/spec-io.md for spec sections and structure. See shared/security-lens.md for implementation-time security patterns.

Think about intent, not just words. The spec is a guide, not a legal contract.

Step 2: Identify Existing Patterns

Before writing code, explore the codebase:

• •How are similar features implemented?
• •What patterns does this project use?
• •What components/utilities already exist?

Match existing conventions. Don't invent new patterns.

Step 3: Plan the Implementation

Create a brief mental model:

• •What files need to change?
• •What's the logical order of changes?
• •Are there any ambiguities in the spec?

If something seems wrong or unclear, ASK. Don't blindly implement something that doesn't make sense.

Step 4: Implement with Judgment

Work through each acceptance criterion. As you implement:

DO:

• •Think about what the user actually needs
• •Use appropriate HTML elements (textarea vs input, etc.)
• •Follow existing code patterns
• •Make reasonable inferences when spec is ambiguous

DON'T:

• •Implement something that seems wrong just because the spec says it
• •Add features not in the spec
• •Over-engineer or add unnecessary abstraction
• •Skip error handling

Flag concerns as you go:

⚠️ The spec says "text field" but this looks like it needs a textarea
   for multi-line input. Proceeding with textarea. Let me know if wrong.

Step 5: Verify It Works

After implementation:

1. •Build/compile succeeds
2. •No obvious runtime errors
3. •Feature appears to work (if you can test locally)
4. •Verify at least one acceptance criterion end-to-end (run a test, check the UI, or hit the endpoint)

Report what you verified vs. what you couldn't. Don't claim full verification if you only checked that it compiles.

Don't claim it's done if it doesn't build.

Step 6: Satisfaction Assessment

Before claiming done, re-read each acceptance criterion from the spec. For each, assess honestly:

• •✅ Satisfied — implemented and verified
• •⚠️ Unsure — implemented but couldn't fully verify (explain why)
• •❌ Not satisfied — not implemented or known gap
• •🔒 Security — one line summarizing security posture (see shared/security-lens.md Review-Time section)

Include this assessment in your completion report. The manager uses it to decide whether to present Gate B or ask you to fix gaps first.

Step 7: Summarize Locally

## Implementation Complete

**Spec:** Documents/specs/42-feature-spec.md
**Files changed:** 3

### Changes
- `src/components/FeedbackForm.tsx` - Added textarea for description
- `src/api/feedback.ts` - New endpoint for submission
- `supabase/migrations/xxx_feedback.sql` - New table

### Satisfaction Assessment
- ✅ Form accepts multi-line feedback
- ✅ Submission persists to database
- ⚠️ 500 char limit — implemented, but spec didn't specify a limit (inferred from codebase)
- 🔒 Security: RLS enabled on feedback table, input sanitized at edge function

### Verification
- Verified: form submission persists correctly (tested locally)
- Could not verify: rate limiting (no test infrastructure)

### Decisions Made
- Used textarea instead of input for description (multi-line content)
- Added 500 char limit based on similar forms in codebase

Update the spec's **Status:** from Approved to Implemented.

See shared/spec-io.md for how to update the status field.

End-of-skill check: See shared/primitive-updates.md. Signals: new/changed packages, new scripts, new directories in src/.

Step 8: Hand Off

Implementation complete.

Ready for manager review.

Red Flags to Raise

Stop and ask if you encounter:

• •Contradictory requirements - Spec says X but also implies Y
• •Missing information - Can't implement without knowing Z
• •Seems wrong - "This will create a bad UX because..."
• •Scope creep - Implementing this properly requires touching A, B, C not mentioned in spec

Don't silently make bad decisions. Surface them.

What This Skill Does NOT Do

• •❌ Write tests (that's your choice to add later)
• •❌ Blindly follow spec when it seems wrong
• •❌ Add features beyond the spec
• •❌ Skip the human review step
• •❌ Post to GitHub (manager handles this after review)

Handoff

This skill hands off to:

• •You - Manual verification of the implementation
• •/qa-handoff - When ready for QA testing