Session 9: Shipping Your First Real Feature

Duration: 2 hours
Prerequisites: Sessions 1-8 completed
You'll need: Full environment, Leigher repo with clean main branch

The Stakes

This is not practice. You're shipping a real feature to the Leigher codebase.

Your PR will be reviewed. If approved, it gets merged. Your code will be in production.

Everything you've learned comes together now—including a new skill: working from specs.

Part 1: The Spec-First Workflow (20 min)

Why Specs Matter

In Sessions 1-8, you worked from informal briefs: "create a notification banner," "add an empty state." That's fine for practice.

Real features come with specs—documented requirements that define what to build, why, and how to verify it's right.

Leigher keeps specs in docs/spec/. Each feature has:

Requirements — What it must do
UI/UX decisions — How it should work
Acceptance criteria — How to verify it's complete

Two Ways to Read Specs

1. Markdown files (for Claude)

The source of truth lives in markdown:

docs/spec/
├── features/
│   ├── authentication.md
│   ├── projects.md
│   ├── surfaces.md
│   └── ...
└── user-journeys/
    ├── onboarding.md
    ├── create-publish.md
    └── ...

Claude reads these directly. When implementing, you can say "follow the spec" and Claude knows what you mean.

2. HTML artifact (for you)

The same specs compile into a browsable HTML file:

docs/leigher-product-spec.html

Open this in your browser for easy reading. It has navigation, search, and formatting. Use it to understand the feature before designing.

The rule: Browse the HTML to understand. Point Claude to the markdown to implement.

Exercise: Explore the Specs

Open docs/leigher-product-spec.html in your browser
Navigate to the Features section
Find "Surfaces" and read through the requirements
Note the acceptance criteria at the bottom

This is how you'll start every real feature.

Part 2: Your Feature Assignment (15 min)

The Feature: Surface Status Indicator

Open the HTML spec and navigate to Features → Surfaces.

Read the "Draft/Published states" row. Currently marked ✅ Complete—but the visual indicator is minimal.

Your task: Improve the surface card's status indicator to be more visible and informative.

Read the Spec

From the surfaces spec, the relevant requirements are:

Surfaces have two states: Draft and Published
Users need to clearly see which state each surface is in
Published surfaces show a "live" indicator
Draft surfaces show they're not yet visible

Acceptance Criteria

Your implementation must:

[ ] Show clear visual distinction between Draft and Published
[ ] Use existing design tokens (no new colors)
[ ] Match the card pattern from component-patterns.md
[ ] Work on mobile (status visible without truncation)
[ ] Include appropriate icon or badge

Design Direction

This is deliberately open. The spec tells you what, you decide how:

Badge in corner vs. inline text?
Color-coded vs. icon-based?
Subtle vs. prominent?

Your design judgment matters here.

Part 3: Design Phase (30 min)

Step 1: Review Existing Implementation

Before designing, see what exists.

Ask Claude:

Show me how surface cards currently display the draft/published status.
What does the current implementation look like?

Understanding the starting point helps you design the improvement.

Step 2: Explore in Figma

Open the Leigher Figma file.

Find the surface card component. Create variations for the status indicator:

Try a colored badge (e.g., green for Published, gray for Draft)
Try an icon-based approach
Try different positions (top-right corner, inline with title, bottom of card)

Create 2-3 options. Pick the one that's clearest and fits the existing aesthetic.

Step 3: Validate Against Patterns

Check your design against existing patterns:

Colors: Are you using existing accent colors? (--accent-green for published?)
Typography: Badge text using the type scale?
Spacing: Badge padding from the spacing scale?
Radius: Badge radius from the radius scale?

Adjust your Figma design if needed.

Part 4: Implementation (40 min)

Step 1: Create Branch

In GitHub Desktop, create a new branch: feature/surface-status-indicator

Step 2: Point Claude to the Spec

This is the key difference from practice sessions. Start by grounding Claude in the spec:

Read the surfaces feature spec at docs/spec/features/surfaces.md.
I'm improving the status indicator for surface cards to make 
Draft vs Published states more visible.

Claude now has the context of what this feature is supposed to do.

Step 3: Implement from Figma

Select your chosen design in Figma.

Implement this status indicator design from Figma.
Update the existing SurfaceCard component to show the status 
more prominently, following the design I've selected.

Requirements from the spec:
- Draft surfaces show they're not yet visible
- Published surfaces show a "live" indicator
- Must be clearly visible on the card

Step 4: Check in Browser

Go to localhost:5173.

Does the status indicator appear on surface cards?
Is Draft visually distinct from Published?
Does it match your Figma design?

Step 5: Iterate

What needs adjustment?

"The badge needs more contrast—the green is too subtle"

"Add a small icon before the status text"

"On mobile, the badge overlaps the title. Move it below."

"The Draft state should feel more muted than Published"

Keep refining until it matches your design and feels right.

Step 6: Verify Against Acceptance Criteria

Go back to your acceptance criteria checklist:

[ ] Clear visual distinction between Draft and Published?
[ ] Using existing design tokens only?
[ ] Matches card pattern?
[ ] Works on mobile?
[ ] Includes icon or badge?

If any are unchecked, address them now.

Part 5: Ship It (25 min)

Step 1: Review Changes

In GitHub Desktop, review all changed files.

You should see modifications to:

Surface card component
Surface card CSS
Possibly shared styles if you created a reusable badge

Step 2: Final Test

Before committing:

Refresh the browser
Check both Draft and Published surfaces
Resize to mobile width
Verify colors match tokens (inspect element if unsure)

Step 3: Commit

Write a clear commit message:

Summary: "Improve surface card status indicator"

Description:

Makes Draft/Published status more visible on surface cards.

Changes:
- Added colored status badge to surface cards
- Green badge for Published, gray for Draft
- Includes status icon for additional clarity
- Responsive: badge repositions on mobile

Implements requirements from docs/spec/features/surfaces.md

Note: Referencing the spec in your commit message is good practice.

Step 4: Push and Create PR

Push to origin.

Create Pull Request with description:

## What
Improves the visual indicator for surface Draft/Published status.

## Why
Current status display is minimal. Users need to quickly 
identify which surfaces are live vs. still in draft.

## Spec Reference
See: docs/spec/features/surfaces.md → Draft/Published states

## Acceptance Criteria
- [x] Clear visual distinction between Draft and Published
- [x] Uses existing design tokens
- [x] Matches card pattern
- [x] Works on mobile
- [x] Includes status badge with icon

## Screenshots
[Desktop view]
[Mobile view]
[Both states side-by-side]

Including the acceptance criteria checklist in your PR shows reviewers you verified the requirements.

Step 5: Address Feedback and Merge

If reviewer requests changes:

Read feedback
Adjust via Claude Code
Commit: "Address review feedback"
Push

Once approved, merge.

🎉 Your feature is in production.

Part 6: The Complete Workflow (10 min)

What You Just Did

Spec → Design → Implement → Verify → Ship

Read the spec — Understood requirements and acceptance criteria
Designed in Figma — Explored options, picked the best
Implemented with spec context — Claude knew the requirements
Verified against criteria — Checked every requirement
Shipped with documentation — PR references the spec

This is the professional workflow. Specs keep everyone aligned—including Claude.

The HTML Artifact

You used the HTML artifact to browse and understand the spec. That's its purpose: human-readable navigation of what would otherwise be scattered markdown files.

For your own projects, consider generating a similar artifact. Tools like MkDocs or Docusaurus compile markdown into browsable documentation.

Your New Capability

You can now:

Read a feature spec
Design a solution
Implement it with Claude (spec-aware)
Verify against acceptance criteria
Ship with proper documentation

That's the complete skill set of a Shipping AI Designer.

Session 9 Checklist

[ ] Explored specs in HTML artifact
[ ] Read feature requirements and acceptance criteria
[ ] Designed in Figma with 2-3 variations
[ ] Validated design against patterns
[ ] Implemented with Claude reading the spec
[ ] Iterated until polished
[ ] Verified against all acceptance criteria
[ ] Created PR with spec reference
[ ] Merged to main

What's Next

Session 10: When Things Break

You've shipped successfully. But things will break. Session 10 teaches you what you can fix yourself and when to ask for engineering help.

Session 9 of 10 • The Shipping AI Designer Course
Next: Session 10 — When Things Break

Shipping Your First Real Feature