Master Ship Learn Next

A productivity skill that transforms learning into action through iterative Ship-Learn-Next cycles. Instead of consuming content passively, this skill helps you extract actionable takeaways, build something concrete, reflect on what you learned, and define your next iteration — creating a continuous improvement loop.

When to Use This Skill

Choose Master Ship Learn Next when:

• You've read an article, watched a talk, or completed a course and want to act on it
• You're stuck in a learning loop without producing tangible output
• You need to break ambitious learning goals into shippable iterations
• You want to build a habit of learning through doing rather than just consuming

Consider alternatives when:

• You need detailed project planning with dependencies and timelines (use a planning skill)
• You're working on established production code with no learning component
• You need to document existing knowledge rather than learn something new

Quick Start

Copy
claude "I just read about React Server Components. Help me create a Ship-Learn-Next cycle"

Copy
# Ship-Learn-Next: React Server Components

## 🚢 Ship (What I'll Build)
**Deliverable:** Convert the /dashboard page from client-side fetching to RSC
**Scope:** Single page, read-only data, no mutations
**Timebox:** 4 hours

## 📚 Learn (What I Expect to Discover)
- How RSC data fetching differs from useEffect patterns
- Where the client/server boundary actually matters
- Whether bundle size measurably decreases

## ⏭️ Next (What Comes After)
- If it works: Apply RSC to /settings and /profile pages
- If it doesn't: Document blockers and try with a simpler page
- Either way: Write a short post comparing before/after metrics

Core Concepts

The Ship-Learn-Next Loop

Phase	Question	Output
Ship	"What's the smallest thing I can build?"	Working artifact (code, prototype, doc)
Learn	"What did I actually discover?"	Reflection notes with evidence
Next	"What should I do differently?"	Next cycle's Ship definition

Cycle Sizing

Copy
## Cycle Size Guide

### Micro (1-2 hours)
- Try one API endpoint
- Build a single component
- Write a failing test and make it pass

### Standard (half day)
- Convert one page/feature
- Integrate one new library
- Build a working prototype

### Extended (1-2 days)
- Build an end-to-end feature
- Compare two architectural approaches
- Create a reusable module with tests

Learning Capture Template

Copy
## Learning Log: [Topic]

### What I Expected
[Hypothesis before starting]

### What Actually Happened
[Concrete observations with evidence]

### Surprises
- [Thing that contradicted my expectations]
- [Thing I didn't anticipate at all]

### Key Insight
[Single most important takeaway in one sentence]

### Evidence
- Bundle size: 340KB → 285KB (-16%)
- Load time: 1.2s → 0.8s (-33%)
- Lines of code: 89 → 62 (-30%)

Configuration

Parameter	Description	Default
cycle_size	Micro, standard, or extended timebox	standard
include_metrics	Track before/after measurements	true
reflection_depth	Brief, standard, or detailed reflection	standard
chain_cycles	Auto-generate next cycle from learnings	true
output_format	Markdown, JSON, or checklist format	markdown

Best Practices

1. Timebox aggressively. A Ship phase that takes more than a day is too big. Split it into smaller iterations — shipping a rough version teaches more than planning a perfect one you never finish.

2. Write the Learn section immediately after shipping. Insights fade fast. Capture observations, measurements, and surprises within 30 minutes of completing the Ship phase while context is fresh.

3. Make the Next step concrete. "Learn more about databases" is not actionable. "Build a read-replica query for the dashboard page" is. Each Next should be specific enough to start immediately.

4. Include quantitative evidence. Whenever possible, measure something before and after. Bundle size, response time, lines of code, test coverage — numbers make learning tangible and comparable across cycles.

5. Accept failed cycles as valuable. If your Ship phase doesn't work, the Learn section is even more important. Document exactly what went wrong and why — failed experiments often teach more than successful ones.

Common Issues

Cycles keep growing in scope. If your Ship phase takes more than the timebox, you're trying to learn too many things at once. Split into multiple cycles focused on one concept each. "Build a full CRUD API with auth" should become three separate cycles: read endpoint, write endpoint, then auth layer.

Learn section is just "it worked" or "it didn't." Push for specific observations. What surprised you? What was easier or harder than expected? What would you do differently? Use the "What I Expected vs. What Actually Happened" format to force deeper reflection.

Next cycles don't build on previous learnings. Review your last 3-5 Learn sections before defining the next Ship phase. Look for patterns — recurring difficulties suggest a foundational gap worth addressing directly rather than working around.