fitme·story

The PM-flow ecosystem

A task comes in. The hub classifies it, wakes only the right skills, routes it through the right slice of the lifecycle, and loops evidence back into the next request.

The process is a cycle, not a pipeline.

Product development never ends with shipping. It loops back through monitoring, feedback, and analysis into the next iteration. The inner ring below shows the 10 phases. After P8 Release, three feedback skills (CX, Ops, Marketing) observe the shipped product and feed signals back to Research and Learn — closing the loop. A separate Docs satellite sits off-cycle, carrying internal artifacts (PRDs, QA reports, runbooks) bidirectionally between PRD, Tasks, UX, and Test.

New capability — research, PRD, design, build, measure.

Two-ring lifecycle diagram. Inner ring: ten forward phases — Research, PRD, Tasks, UX, Implement, Test, Review, Merge, Release, Learn — clockwise. After Release at P8, three feedback skills (Marketing, Ops, CX) observe the shipped product and feed back into Research and Learn, closing the loop. A separate Docs satellite sits off-cycle, flowing artifacts between PRD, Tasks, UX, and Test. Hover or focus the Release phase or any feedback pill to see the fan-out and return arrows; hover the Docs satellite to see its connectors.MarketingASO · campaigns · launch funnelsOpsincidents · latency · SLOs · always-onCXreviews · sentiment · NPSDocsinternal artifactsP0 ResearchP1 PRDP2 TasksP3 UX/DesignP4 ImplementP5 TestP6 ReviewP7 MergeP8 ReleaseP9 Learnthe product-development looprelease fans out · feedback closes the loop

Hover or focus P8 Release or any feedback pill to see the ship-fan-out and feedback-return arrows. Hover the Docs satellite to see which phases produce and consume internal artifacts.

work-item types
  • Feature10 phases

    New capability — research, PRD, design, build, measure.

    P0P1P2P3P4P5P6P7P8P9
  • Enhancement4 phases

    Improve a shipped feature. Parent PRD already exists.

    P2P4P5P7
  • Fix2 phases

    Bug fix, security patch, error handling.

    P4P5
  • Chore1 phase

    Docs, config, refactor, dependency bump.

    P4

Not every work item runs all ten phases. Features get the full lifecycle; smaller work skips the upstream phases it doesn't need. Pick a type above to see which phases fire.

Every skill stands alone. All skills fit together.

Each skill is a Lego brick — it works on its own AND it snaps into the 10-phase lifecycle (the hub-and-spoke topology). Toggle Scattered to see them standalone; toggle Assembled to see them fit into phase columns. Click any brick to flip it and read the details.

Click a brick to flip • Esc to close

How the ecosystem grew

From a single monolithic skill in v1.0 to a hub-and-spoke topology by v4.3, then SoC-on-software optimizations, dispatch intelligence, and hardware-aware dispatch. Six milestones that matter most.

The files the skills speak through.

Skills do not call each other directly — they read and write shared JSON files in .claude/shared/. Decoupling by design. Any skill can run standalone because every skill just reads state and writes state. The colored dots show which skills touch each file.

context.json

Global product context — personas, mission, top-level goals.

read by
writes
feature-registry.json

Master list of all features, their phase, branch, and current state.

read by
writes
skill-routing.json

Maps each phase to 1-2 skills the hub loads on-demand.

read by
writes
framework-manifest.json

Canonical version + structural metadata for the framework.

read by
writes
case-study-monitoring.json

Every feature opens an entry here — process + quality metrics become case studies.

read by
writes
design-system.json

Token inventory, component catalog, WCAG compliance status.

read by
writes
test-coverage.json

Per-feature test counts, coverage percentages, CI status.

read by
writes
metric-status.json

Current value of every tracked product metric vs PRD targets.

read by
writes
cx-signals.json

App-store reviews, NPS, sentiment, post-deployment feedback.

read by
writes
campaign-tracker.json

Marketing campaigns in flight + post-campaign performance.

read by
writes
health-status.json

Infrastructure health — crash-free rate, uptime, error-tracking signals.

read by
writes
change-log.json

Per-version changelog — auto-generated from merged features.

read by
writes
token-budget.json

Context-window usage tracking per skill per session.

read by
writes
chip-affinity-map.json

17 chip profiles + 7 cloud signatures for V7.0 HADF hardware-aware dispatch.

read by
writes
external-sync-status.json

Linear + Notion sync snapshot — detects workspace drift.

read by
writes

Three cache tiers, just like a CPU.

The framework borrows the L1/L2/L3 cache hierarchy directly from CPU architecture. L1 is per-skill (fastest), L2 is shared across skills, L3 is project-wide lore. When a skill needs context, it checks L1 first — if it misses, it tries L2, then L3.

L1.claude/cache/{skill}/

Per-skill cache. Fastest to hit. Holds skill-specific recent patterns.

L2.claude/cache/_shared/

Cross-skill shared patterns. Hit when L1 misses.

L3.claude/cache/_project/

Project-wide lore. Slowest tier. Cache of last resort.

Want this pattern in your own setup?

  • Start with one hub skill + one phase. Do not try to stand up the whole ten-phase lifecycle on day one.
  • Shared-state-first. Skills read and write JSON state. They never call each other directly — that decoupling is what makes the ecosystem composable.
  • Add phases and spokes incrementally. The evolution strip above is a real receipt of how this grew. Iteration, not planning.

The skill source files are open under CC-BY-4.0 at github.com/Regevba/FitTracker2 — .claude/skills.