菜单
Use when planning how to structure a product — deciding whether to build one large app or several focused apps. Gives generic decomposition guidance always (reliability + token economy), and steers to the specific app breakdown when docs/<app>/product.md defines one. Do NOT use for single-file edits or for app-internal component structure.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | product-apps-decomposition |
| description | Use when planning how to structure a product — deciding whether to build one large app or several focused apps. Gives generic decomposition guidance always (reliability + token economy), and steers to the specific app breakdown when docs/<app>/product.md defines one. Do NOT use for single-file edits or for app-internal component structure. |
| source_inspiration | conceptual-only |
| license_status | clean-room-original |
| fusebase_flow_version | 3.5 |
| risk_level | low |
| invocation | automatic |
| expected_outputs | ["a product->apps decomposition recommendation","app boundaries (one product = several focused apps) with rationale"] |
| related_workflows | ["eight-phase-flow.md","implementation-planning.md"] |
| hook_dependencies | ["none"] |
Style: Mode-B-lite. Generic guidance always; steers to the product breakdown when
docs/<app>/product.mddefines one (generic-with-enhancement, not pure no-op — E3).
Encode the "a product is composed of focused apps" model: breaking a product into smaller, focused apps (vs one monolith) improves reliability (one app's failure can't sink the rest) and token economy (the LLM loads only the relevant app's context). Apps talk via internal API; complexity per app stays low.
docs/<app>/product.md exists with an apps breakdown (steer to it).| Input | Where it lives | If missing |
|---|---|---|
| Product breakdown (optional) | docs/<app>/product.md | give generic guidance; do not invent a breakdown |
| Reliability/scale needs | operator / North Star | ask if scope-critical (FR-19) |
docs/<app>/product.md defines an apps breakdown → read and steer to it. Otherwise give generic guidance (do not fabricate a specific breakdown).callAppApi contract to author and keep green (CLI skill app-api-contract-testing).docs/<app>/product.md § apps breakdown (authored via product-docs-first, templates/product.md): per app — one-line job, owned data, planned call edges. Later sessions steer to it (step 1) instead of re-deciding. Do not leave a locked breakdown chat-only.implementation-planning) per app.| Split signals (favor separate apps) | Concretely |
|---|---|
| Distinct data ownership | Each app owns its dashboards/stores; peers read via API, never write the other's data directly |
| Independent deploy cadence | One area ships weekly, the other is stable — separate apps deploy without re-verifying the other |
| Failure blast radius | A crash or bad deploy in one area must not take down the other (client-facing portal vs internal admin is the classic cut) |
| Per-app context size | Combined codebase would bloat the LLM window; per-app context stays small enough for reliable edits (token economy) |
| Split costs (favor one app) | Concretely |
|---|---|
| Cross-app API + contract maintenance | Every runtime call between apps is AppApisApi.callAppApi(...) and needs a consumer contract kept green (CLI skill app-api-contract-testing); each call edge is permanent maintenance |
| Per-app auth/permission/embed overhead | Each app separately configures permissions, portal embedding, public access |
| Per-app deploy/ops overhead | Separate builds, deploys, smoke runs, and remote-log surfaces per app |
| Chatty boundary | If the areas constantly need each other's data inside one interaction, the network seam adds latency + failure modes a single app doesn't have |
Rules of thumb: ≥2 signals and ≤2–3 planned call edges → split. 0–1 signals, or a chatty seam → one app. Undecidable → ask the operator (FR-19).
Candidate areas: pipeline board (internal sales), client portal (clients see their own deals/documents), reporting.
| Boundary | Signals | Costs | Verdict |
|---|---|---|---|
| Portal vs pipeline | Data ownership (portal reads deals, never writes); blast radius (client surface must survive internal-tool breakage); independent cadence | 1 call edge (client-portal → crm-pipeline: getClientDeals) + 1 contract | Split — crm-pipeline + client-portal |
| Reporting vs pipeline | Same data, same cadence, no blast-radius concern | Would add 3+ chatty aggregate-query edges | Keep inside crm-pipeline as a view |
Result: 2 apps, 1 contract, recorded in docs/crm/product.md § apps breakdown (step 5).
| Artifact | Location | Mode |
|---|---|---|
| Decomposition recommendation | chat / product doc | Mode A / Mode-B-lite |
| Recorded apps breakdown (job + owned data + call edges per app) | docs/<app>/product.md via product-docs-first | Mode B |
| Failure | Detection | Response |
|---|---|---|
| Over-splitting (too many tiny apps) | step 2 | consolidate; split has a cost too |
| Monolith pressure | step 2 | flag reliability/token risk; recommend split |
workflows/architect-escalation.md.product-docs-first / ask operator.app-api-contract-testing CLI skill before the edge ships.product.md has none — give generic guidance.Original Fusebase Flow content. See docs/source-map.md. No third-party code, prompts, or skill files copied.
Use ONLY when the operator runs "/find-wasted-code" (or explicitly asks to "scan the repo for dead-end tool calls / broken links / missing helpers / footgun configs / silent push-through"). Statically scans THIS repo for friction footguns and writes a tracked report to docs/wasted-code/report.md. Manual-trigger ONLY — do NOT auto-invoke; the skill carries disable-model-invocation and no hook wires it. Read-only except the one report write. Findings are review candidates, never auto-fixes. Do NOT use for token/transcript economy (/token-waste-audit), for process ceremony (/find-wasted-effort), or for CLI/Flow drift health (/fusebase-health).
Use at Specify to classify a ticket Full vs Lightweight, and whenever a change looks small / reversible / low-risk ("small fix", "tweak", "hotfix", "drop pretty-printing", "bump a constant"). Operationalizes FR-21 — ceremony proportional to change size. Defines the eligibility gate, the change-note artifact, the one-pass build→verify→deploy procedure, and mid-flight promotion. Do NOT use for risky/uncertain work, schema/data migrations, security/permission changes, new public contracts needing a decision, unknown-root-cause diagnostics, or large features — those take the Full lane.
ALWAYS load at session start. After self-attesting, Read references/<role>.md for your role (Product Owner / AI Developer / Architect / Deploy phase) — role-specific don't-list, exact refusal phrasing for FR violations, and recovery pointers; shared cross-role protocols live in this file. Mandatory; not on-demand.
Use when the operator types /product-owner, asks to activate Product Owner, start a Product Owner or PO session, or searches /product in Codex for Fusebase Flow project management. Do NOT use for implementing code; route implementation to the AI Developer role.
Use when planning tasks that touch big source files, when an edit would push a file past the module-size ceiling, when the pre-commit module-size ratchet warns or blocks, or when generating policies/module-size-baseline.txt. Operationalizes FR-25 — module-size ratchet (ceiling default 800; over-ceiling files may shrink, never grow; extraction along a responsibility seam is in-scope, not scope creep). Do NOT use for docs/markdown size (FR-23 owns docs), to force decomposition of an existing monolith (that is its own explicit ticket), or to judge split quality by regex (seam-vs-mechanical is semantic — code-review owns it).
Use ONLY when verification passed AND operator explicitly says "prepare deploy" / "draft deploy" / "ship it"; drafts deploy handoff, captures deploy hash + probes + smoke, advises spec DRAFT→DONE flip. Do NOT auto-invoke; operator triggers explicitly.