Implementation Skills

test-driven-development

The test-driven-development skill enforces the red-green-refactor cycle for all implementation work. It ensures tests exist before code, preventing the common anti-pattern of "I'll add tests later" (which means never).

The TDD Cycle

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│    ┌─────────┐      ┌─────────┐      ┌──────────┐          │
│    │   RED   │─────►│  GREEN  │─────►│ REFACTOR │──┐       │
│    │  Write  │      │  Make   │      │  Clean   │  │       │
│    │ failing │      │   it    │      │   up     │  │       │
│    │  test   │      │  pass   │      │  code    │  │       │
│    └─────────┘      └─────────┘      └──────────┘  │       │
│         ▲                                          │       │
│         └──────────────────────────────────────────┘       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Invocation

# Start TDD workflow for a feature
/test-driven-development "Add user authentication"

# The skill enforces:
# 1. Write test first (must fail)
# 2. Write minimal code to pass
# 3. Refactor while keeping tests green
# 4. Repeat for each behavior

Example TDD Session

You: /test-driven-development "Implement password validation"

Fulcrum: Starting TDD workflow...

**Step 1: RED - Write failing test**

```typescript
// password.test.ts
describe('validatePassword', () => {
  it('should reject passwords shorter than 8 characters', () => {
    expect(validatePassword('short')).toBe(false);
  });
});
```

Running test... ❌ FAILED (validatePassword is not defined)

**Step 2: GREEN - Minimal implementation**

```typescript
// password.ts
export function validatePassword(password: string): boolean {
  return password.length >= 8;
}
```

Running test... ✅ PASSED

**Step 3: Add next test case**

What validation rule should we test next?
- Requires uppercase letter
- Requires number
- Requires special character

When to Skip TDD

TDD is mandatory for business logic, but some code doesn't benefit from test-first:

• Exploratory prototypes — Throwaway code for learning
• Pure configuration — JSON/YAML with no logic
• Generated code — Scaffolding that will be customized

For everything else, write the test first.

frontend-design

The frontend-design skill creates distinctive, production-grade UI that avoids the generic "AI-generated" aesthetic. It applies design principles, accessibility standards, and visual polish automatically.

Design Philosophy

• Distinctive over generic — No cookie-cutter Bootstrap/Tailwind templates
• Accessible by default — WCAG compliance built in
• Performance-aware — Optimized rendering, lazy loading
• Responsive-first — Mobile experience isn't an afterthought

Invocation

# Create a new component
/frontend-design "Create a data visualization dashboard"

# Redesign existing UI
/frontend-design "Modernize the settings page"

# Build with specific constraints
/frontend-design "Build checkout flow" --style "minimal" --framework "React"

What Makes It Different

❌ Generic AI output:          ✅ frontend-design output:

<div class="card">             <article class="metric-card"
  <h2>Revenue</h2>               role="region"
  <p>$1.2M</p>                   aria-labelledby="revenue-title">
</div>                           <h2 id="revenue-title" 
                                   class="metric-label">
                                   Revenue
                                 </h2>
                                 <data value="1200000" 
                                   class="metric-value">
                                   $1.2M
                                 </data>
                                 <span class="metric-trend 
                                   metric-trend--positive"
                                   aria-label="12% increase">
                                   ↑ 12%
                                 </span>
                               </article>

quality-gate-checker

The quality-gate-checker skill validates readiness for handoffs, PR creation, and deployment. It runs 7 quality gates that must pass before work can proceed to the next stage.

The 7 Quality Gates

Invocation

# Run all gates before PR
/quality-gate-checker --stage pr

# Run deployment gates
/quality-gate-checker --stage deploy

# Check specific gate
/quality-gate-checker --gate security

Gate Report Output

Quality Gate Report
═══════════════════════════════════════════════════

Gate 1: Tests ................................. ✅ PASS
  └─ 142 tests passed, 87% coverage (threshold: 80%)

Gate 2: Lint .................................. ✅ PASS
  └─ No errors, 0 warnings

Gate 3: Types ................................. ✅ PASS
  └─ TypeScript strict mode: clean

Gate 4: Security .............................. ⚠️  WARN
  └─ 1 low-severity advisory (lodash)
  └─ Action: Review and update if needed

Gate 5: Docs .................................. ❌ FAIL
  └─ API.md not updated for new endpoints
  └─ Action: Run /documentation-writer

Gate 6: Performance ........................... ✅ PASS
  └─ Bundle: 142kb (limit: 200kb)

Gate 7: Review ................................ ⏳ PENDING
  └─ Awaiting review approval

═══════════════════════════════════════════════════
Result: BLOCKED - 1 gate failed, 1 pending

Remediation:
  1. Update API documentation
  2. Request code review

Implementation Workflow

Planning Complete
       │
       ▼
┌──────────────────┐
│ /test-driven-    │◄── Write tests first
│   development    │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ /frontend-design │◄── (if UI work)
│   or implement   │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ /quality-gate-   │◄── Validate before PR
│    checker       │
└────────┬─────────┘
         │
    All gates pass?
         │
    ├─── No ──► Fix issues, re-run
    │
    └─── Yes ──► Ready for review