Overview Stats
Category Counts
| Category | Count | What It Captures |
|---|---|---|
| Product-line expansion | 35 | Multiple apps, product portfolios, adjacent vertical/horizontal expansion, separate products for different customer bases. |
| Branch decision pressure | 83 | Prompts asking for recommended build sequence, selected ICP impact, branch choices, separate products, or narrowing after divergence. |
| Multi-artifact expansion | 16 | Requests that naturally multiply output artifacts, including many variants, many apps, or matrixed journey maps. |
| Approval or stale-question friction | 40 | Alignment page labels, stale questions, premature route decisions, or branch decisions changing earlier gate answers. |
| Explicit research-lane breadth concern | 2 | Direct concerns that ICP/concept exploration were doing surface-level strategy across too many lanes. |
Evidence Matrix
| Claim | Evidence | Inference | Confidence | Decision Impact |
|---|---|---|---|---|
| The workflow repeatedly surfaces more plausible branches than a single downstream skill can evaluate cleanly. | 35 product-line expansion records and 83 branch decision records. Example, 2026-05-24 `calcllm`: I want you to double check the recommended build sequence, there's a bit of divergence between startup cto and the platform eng lead... two separate products... |
Branching is not rare edge behavior; it is a recurring product-discovery shape where one research pass exposes divergent ICP/problem/product options. | High | The workflow should explicitly triage branches before deep per-skill fan-out. |
| Full-depth downstream artifacts can multiply too quickly when branches are matrixed by ICP, problem, buyer/user, or product line. | 2026-05-25 `calcllm`: I want us to have clean splits between the two problems and the two ICPs. So there should be 8 journey maps: customer + user map for each of the two problems that the two ICPs experience. |
Clean splits are sometimes correct, but the workflow needs a deliberate fan-out threshold so the agent does not accidentally turn every candidate into full research depth. | High | Add a branch manifest and artifact budget before creating many canonical outputs. |
| The user wants product-line thinking, not just single-product ICP selection. | 2026-04-04 `claude-skills`: is there platform or product line skill that we have?... aggressively run a bunch of experiments in parallel... multiple apps under a single brand... vertical... horizontal...2026-05-07 `lexcorp/war-room`: request for one thousand apps as distribution and product-line expansion. |
Some branching belongs above ICP in a portfolio strategy lane, while ordinary ICP should not pretend to solve portfolio strategy in passing. | High | Route broad portfolio questions to `platform-strategy`; keep `icp` focused on segment fit and only emit product-line signals as candidates. |
| Current skill contracts contain useful pieces but no unified branch governor. | `icp` identifies 2-5 ICP candidates and does cross-ICP analysis. `platform-strategy` clusters 4-8 candidates and scores expansion vectors. `ux-variations` creates 5 UI variations and routes to UAT/consolidation. `feature-interview` can park or split scoped feature work. | The system already has specialized branch handlers, but product research lacks a common rule for when to summarize, park, split, or deepen branches. | High | Patch shared research/AFPS contracts rather than create a broad new mega-skill as the first move. |
| Research-lane sprawl is already noticed by the user. | 2026-05-24 `agentic-skills`: should have each research skill solely focused on its research lane as opposed to have a more exhaustive breadth of research?... ICP has a lot of product strategy, competitive analysis, and monetization strategy in it although surface level. |
A branch model should reduce shallow cross-lane analysis by making each skill state what branch evidence it owns and what it only routes downstream. | High | Define branch evidence handoff fields instead of asking every skill to solve every adjacent question. |
| Alignment gates can go stale when branch decisions change after the page was generated. | 2026-05-24 `calcllm`: user asked to validate alignment-page answers against a new direction after deciding platform engineering should be primary and startup CTO a separate product-line branch. | Branch-changing approvals should trigger a gate freshness check and update branch labels before applying YAML answers. | Medium-high | Alignment pages need an explicit branch/verdict gate and stale-answer warning for branch-sensitive decisions. |
Recommended Path
Recommendation: adopt a two-stage branch funnel across product research skills.
Stage 1: Branch Triage. Research skills may surface several candidates, but they should only evaluate all candidates at screening depth. Screening depth means enough evidence to classify the branch, score confidence, note why it might matter, and decide whether it is primary, secondary, parked, merged, killed, or routed to a specialist skill.
Stage 2: Focused Deepening. By default, only the top one branch becomes the canonical downstream path. A second branch can be deepened only when evidence shows it is a distinct product line, a materially different ICP/problem pair, or the user explicitly approves parallel work. Branches three and beyond should be parked with evidence and revisit conditions, not fully researched by default.
Decision Rule
| Branch Verdict | When to Use | Next Action |
|---|---|---|
| Primary | Highest evidence-backed value/accessibility fit and clear near-term product thesis. | Continue the normal AFPS path: ICP, competitive analysis, journey, positioning, UX/UI, prototype, UAT, consolidation, research refresh, spec, roadmap. |
| Secondary deep branch | Materially distinct product line or ICP/problem pair with strong evidence and high strategic value. | Create app/product-scoped research path and require user approval before full fan-out. |
| Parked | Interesting but lower confidence, later-stage, resource-constrained, or dependent on validation from the primary branch. | Record in a branch backlog with evidence, revisit trigger, owner skill, and no downstream artifact fan-out. |
| Merged | Two branches differ in messaging, tiering, or packaging but share the same core problem/user workflow. | Fold into one canonical branch and route packaging/positioning details downstream. |
| Killed | Weak WTP, poor accessibility, no meaningful gap, high cost without strategic payoff, or outside scope. | Document exclusion rationale in the alignment page and search log. |
| Specialist route | Question is clearly portfolio expansion, UX variation, feature add-on, monetization, or GTM rather than the current skill's lane. | Route to the relevant owner after approval: `platform-strategy`, `ux-variations`, `feature-interview`, `monetization`, or similar pack skill. |
Branch Manifest Model
Each research-producing skill that can surface branches should produce a compact branch manifest in the alignment page and, after approval, in the relevant canonical artifact or search log. This avoids hiding branch decisions in prose.
Why This Is More Elegant Than Full Fan-Out
The elegant part is not suppressing branch thinking; it is separating branch discovery from branch commitment. A skill can be honest about 4-8 plausible branches while committing full research depth only where evidence or user approval justifies it. This preserves strategic optionality without turning every run into a sprawling portfolio exercise.
Likely Owner Surface
| Surface | Change | Validation Expectation |
|---|---|---|
| Shared research/alignment contract | Add branch manifest, artifact budget, branch verdict gate, and stale-branch-answer check to research-producing skills. | Layer1 alignment-gates test asserts branch manifest and branch verdict gate language for research skills. |
| `packs/business-discovery/*/icp` | Keep 2-5 candidate discovery, but cap full-depth downstream recommendation to one primary branch unless a secondary branch meets explicit separate-product criteria. | Focused contract test or `rg` validation for primary/secondary/parked/merged/killed verdicts and artifact budget. |
| `packs/business-ops/*/platform-strategy` | Make it the explicit owner for portfolio-scale or 4-8 product-line exploration, with branch backlog output and validation experiments for top 2-3 only. | Benchmark/setup expectation that portfolio exploration routes to validation experiments, not immediate specs for all candidates. |
| `global/*/idea-scope-brief` | When a rough idea contains multiple concepts, write separate slugged briefs only for true separate concepts; otherwise emit a branch manifest and route to ICP. | Contract check for pivot/multi-concept handling and branch manifest handoff. |
| `global/*/ux-variations` | Keep UX variants separate from business/product-line branches; only run after product branch is chosen or explicitly scoped per branch. | Route test prevents UX variations from becoming product-line triage. |
Rejected Alternatives
Rejected: Let every research skill evaluate every surfaced branch in full. This directly matches the bog-down failure mode and creates combinatorial artifact growth.
Rejected: Force the user to choose one branch before any research. The history shows research itself often reveals the branch shape, so this would remove useful discovery.
Rejected: Create a single new mega-skill for all branch decisions. Existing `icp`, `platform-strategy`, `feature-interview`, and `ux-variations` already own specialized branches; the gap is a common branch-governance contract.
Lower-confidence option: A dedicated `$branch-strategy` skill could be useful later if branch manifests become frequent standalone artifacts. Current evidence supports contract remediation first.
Review Gates
Evidence Coverage Gate
The report uses full local Claude/Codex prompt histories plus current skill contracts. It does not include assistant outputs from every rich rollout except as represented in prompt history and repo artifacts.
Assumptions & Confidence Gate
Key assumption: the primary pain is not that branches exist, but that branch discovery and branch commitment are not separated strongly enough in skill contracts.
Recommended Path Gate
The proposed durable change is a shared branch manifest and artifact-budget contract, with `icp` and `platform-strategy` as the first owner surfaces.
Proposed File Changes Gate
No canonical skill files have been changed by this report. If approved, likely changes should be routed through targeted remediation and include mirrored Codex/Claude skill contracts, archives, changelogs, and layer1 checks.
Approval Gate
Approval is required before downstream remediation routing or canonical skill edits.