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.

Task orbit The wall Evolution Data layer Cache tiers Build your own

This is your home base. The PM-flow ecosystem — phases, skills, handoffs, and shared state — is how disciplined product development runs end to end. It led the framework; the engineering exists to serve it.

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.

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.

Code is the source of truth; Figma mirrors it.

The /design build skill pushes screens into Figma via the Figma plugin API. A Code Connect bridge was prototyped (2026-05-09) to close the other direction — surfacing each component's code snippet in Figma Dev Mode — but Figma Code Connect requires an Organization/Enterprise plan, and this project runs on Figma Pro. Code Connect publishing is disabled as of 2026-06-15; the mapping files below remain as documentation of intent. The design systems themselves — tokens and components, in code — are fully operational and CI-gated.

Web — fitme-story

.figma.tsx files map React components to Figma file fsjHfFLAHELACZHku8Rfcl (FitMe Story Web — Design System). Parsed by the @figma/code-connect npm package.

17 component mapping files authored (3 buttons · 3 tags · 5 callouts · 2 cards · 2 search · 2 layouts) — documentation-only; not published (Code Connect needs an Org/Enterprise plan).

iOS — FitTracker2

.figma.swift files map SwiftUI Views to Figma file 0Ai7s3fCFqR5JXDW8JvgmD (FitTracker Design System Library). Build-safety wrapper #if canImport(Figma) keeps Xcode green without the toolchain.

5 screen-level mapping files authored from features' state.json::figma_node_ids — documentation-only (publishing is disabled on Figma Pro).

The scaffold + skill automation (scripts/scaffold-figma-mapping.{py,mjs}, Layers A/B) shipped, and the CI publish workflow (Layer C) exists — but the final figma connect publish step never succeeded: it requires the code_connect:write scope, which Figma only grants on Organization/Enterprise plans. On Pro, the workflow is a disabled stub. Figma is instead maintained as a visual mirror via the Figma plugin API; code stays the source of truth.

iOS Code Connect Workflow doc →fitme-story Design Architecture doc →Figma Code Connect repo →

Every skill knows the patterns that can block its work.

The framework keeps a single, append-only Observed Patterns Catalog — 64 entries today (25 gate-firing patterns + 39 workflow patterns W1–W39), each documenting a recognized failure-mode (a gate that fires, a launchd quirk, an MDX gotcha) with a trigger description, a why-expected classification, and a silence path. Before v7.9.1, those entries lived in a flat catalog and were consulted reactively — after something broke. Since 2026-06-04, each entry now declares which of the 12 skills it is most relevant to, and each skill carries the inverse map: here are the patterns my work is exposed to.

The wiring is bidirectional and self-auditing: run make skill-preflight SKILL=<name> and that skill probes its mechanized patterns live (23 of the 63 mapped entries have a script detector) and emits an awareness checklist for the rest. A PATTERN_SKILL_UNMAPPEDadvisory surfaces any new catalog entry that hasn't been mapped yet, so the bidirectional invariant can't silently drift.

Source of truth

pattern-skill-map.json

63 entries — each carries {id, title, detector, blocker, autoheal, skills[], remediation}. Many-to-many — a pattern can block several skills.

Per-skill probe

make skill-preflight

Runs the mechanized detectors for the skill's patterns + emits manual checklists for the rest. Writes an additive overlay into preflight-cache.json.

Self-audit

PATTERN_SKILL_UNMAPPED

Cycle-time advisory: catches a new catalog entry without a corresponding map entry. Catalog growth and map growth stay in lockstep.

One catalog entry (W33) documents the overlay tool itself, exempted from the advisory via a single-element SELF_DOC_EXEMPT set — so 63 of the 64 entries are mapped. The map will eventually be the build-time input for an Acts III–V overlay on the framework universe visualization (3D feature, Phase 2).

Pattern↔Skill overlay doc →pattern-skill-map.json source →Observed Patterns Catalog →

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.

The 6-floor building →

Zoom out to the full framework architecture.

Watch it run →

A real feature flowing through the framework in real time.

Glossary →

Plain-language definitions for every term on this page.