user-flow
User Flow Design — Orchestrator
Design — Step 2 of 2. Maps navigation paths, decisions, edge cases, platform-native touchpoints, and screen transitions into a validated flow diagram.
Core Question: "Can the user complete their goal without thinking — on every surface of every platform it ships on?"
Critical Gates — Read First
- No Layer 1 before platforms + surfaces enumerated. See
references/platform-touchpoints.md. Wireframe size, entries, edge states all depend on it. - Reject "cross-platform" as a platform. Enumerate: macOS, iOS, iPadOS, Android, Windows, web-desktop, web-mobile, watchOS, tvOS, visionOS, CarPlay, Android Auto, Linux.
- No diagrams before structure. Diagram-agent needs structure + edge-case outputs first.
- No skipping edge cases. Error/empty/loading/permission/offline + per-surface edge states for every screen and surface.
- Challenge >7 happy-path steps. Miller's threshold. Every step must justify itself.
- One flow = one file. No pooling. Each run writes
.agents/skill-artifacts/product/flow/<flow-name>.md. - Stale product context (>30 days) misaligns flows. Recommend re-running
icp-research.
Inputs Required
- Product/feature requiring flow mapping (new, redesign, or audit)
- Target user role/persona (flows change per role)
More from hungv47/product-skills
system-architecture
Designs technical blueprints — tech stack selection, database schema, API design, file structure, and deployment plan for a defined product or feature. Produces `architecture/system-architecture.md`. Not for unclear requirements (use discover) or task decomposition (use task-breakdown). For user journey mapping, see user-flow. For code quality after building, see fresh-eyes.
11code-cleanup
Audits and refactors existing code for readability, maintainability, and dead code removal without changing behavior. Produces `.agents/skill-artifacts/meta/records/[date]-cleanup-<slug>.md` and applies fixes in-place. Not for diagnosing business problems (use diagnose) or writing documentation (use docs-writing). For writing missing docs after cleanup, see docs-writing.
9technical-writer
Generates documentation from a codebase — READMEs, API references, setup guides, runbooks, architecture docs, and ship logs with consistent structure and terminology. Produces documentation files in the project. Ship log mode writes a plain-language product snapshot to research/product-context.md so agents and humans know what the app does. Not for specifying what to build (use discover) or restructuring code (use code-cleanup). For shipping and PRs, see ship. For task decomposition, see task-breakdown.
9ship
Automated pre-merge pipeline — runs tests, checks review gate, organizes commits, generates PR with structured body. Produces `.agents/ship-report.md`. Not for code review (use review-chain) or task decomposition (use task-breakdown). For code cleanup before shipping, see code-cleanup. For post-deploy health check, see deploy-verify.
6deploy-verify
Post-deploy health check — verifies a production URL is healthy after shipping. Checks page load, console errors, critical flows, and response times. Reports HEALTHY / DEGRADED / BROKEN with evidence. Not for pre-merge review (use review-chain) or shipping (use ship). For code cleanup, see code-cleanup. For architecture decisions, see system-architecture.
6docs-writing
Generates documentation from a codebase — READMEs, API references, setup guides, runbooks, architecture docs, and ship logs with consistent structure and terminology. Produces documentation files in the project. Ship log mode writes a plain-language product snapshot to research/product-context.md so agents and humans know what the app does. Not for specifying what to build (use discover) or restructuring code (use code-cleanup). For task decomposition, see task-breakdown.
2