# Lp Do Idea Generate > Radical business growth process auditor. Cabinet Secretary orchestrates multi-lens composite idea generation with attribution, confidence gating, and priority ranking. - Skill: `majiayu000/lp-do-idea-generate` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds add majiayu000/lp-do-idea-generate` - Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/lp-do-idea-generate/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: majiayu000 (https://skillmd.com/u/majiayu000) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/majiayu000/lp-do-idea-generate --- # Ideas Go Faster — Cabinet Secretary Cabinet Secretary orchestrates composite business idea generation across multiple expert lenses. Not a kanban health checker. Not a WIP counter. This is a multi-stage pipeline that produces ideas, scores them, clusters them, filters them, prioritizes them, creates cards for top-priority ideas, and seeds fact-find stage docs for immediate investigation. Pete triggers the sweep via `/lp-do-idea-generate`. Everything after that is autonomous. --- ## Invocation ``` /lp-do-idea-generate # default: --stance=improve-data /lp-do-idea-generate --stance=improve-data /lp-do-idea-generate --stance=grow-business /lp-do-idea-generate --dry-run # preview-only: generate/report ideas, no API writes /lp-do-idea-generate --dry-run --stance=grow-business /lp-do-idea-generate --dry-run --allow-api-degraded # allow filesystem-only fallback when API preflight fails /lp-do-idea-generate --force-code-review # force technical cabinet even without triggers /lp-do-idea-generate --assumptions-file # optional assumptions input file /lp-do-idea-generate --verbosity=compact|standard|extended /lp-do-idea-generate --stage7b # enable optional Stage 7b single-card backfill slot scripts/run-idea-generate.sh --dry-run --stance=improve-data # recommended runner (loads .env.local) scripts/run-idea-generate.sh --dry-run --allow-api-degraded --stance=improve-data ``` **Invocation control contract:** - Assumptions input supports both: - inline assumptions block in invocation context - `--assumptions-file ` - If both inline and file assumptions are present, file input takes precedence. - Verbosity mode supports `compact`, `standard`, `extended` (default: `standard`). - `--allow-api-degraded` is valid only with `--dry-run` (never valid for live mode). - Recommended execution path is `scripts/run-idea-generate.sh` so Agent API env vars are loaded from `.env.local`. - `scripts/run-idea-generate.sh` is initiator-agent-preserving: it auto-selects the local agent CLI (`codex` first, then `claude`) so the invoking agent can execute the sweep without forced cross-agent handoff. ### Mandatory CLI Reminder At the start of every `/lp-do-idea-generate` run, emit this exact CLI message: `remember to find out why any good ideas generated via this skill have not been picked up automatically, and revise the workflow so that in the future they are` --- ## Constitution (Non-Negotiable Invariants) These rules override all other instructions. The sweep must not produce output that violates any of them. ### The Elon Musk 5-Step Algorithm (Constitutional Invariant) The Musk lens applies this algorithm in **strict order** during its generation pass. Every recommendation from the Musk lens must be classified into one of these steps. They are executed **in strict order** — you must exhaust each step before moving to the next. This is not a tiebreaker. This is the law. 1. **Question every requirement.** Each must have a named owner (a person, not a department). All requirements are recommendations until proven otherwise. Only physics is immutable. If you cannot name who requested it and why, delete it. 2. **Delete parts and processes.** If you're not adding back at least 10% of what you deleted, you didn't delete enough. The best part is no part. The best process is no process. 3. **Simplify and optimize.** Only AFTER steps 1-2. The most common mistake is optimizing something that should not exist. Do not make this mistake. 4. **Accelerate cycle time.** Every process can be sped up. But only AFTER steps 1-3. Speed up a bad process and you get bad results faster. 5. **Automate.** Last, never first. Automating a process that should be deleted is worse than not automating it. ### Anti-Theater Invariants - **Constraint-first.** Do not propose work until you name the current constraint and the evidence that proves it. No unsourced claims. No hand-waving. - **Do not optimize work that should not exist.** Before improving a process, ask: should this process exist at all? - **Activity is not progress.** More tasks does not mean more throughput. More ideas does not mean better ideas. Measure outcomes, not output volume. - **Do not produce feature-factory outputs.** Every recommendation must tie directly to a named constraint. If it doesn't relieve a constraint, it doesn't belong in the sweep. - **Evidence and traceability.** Every claim must point to observable facts — API data, plan targets, profile capacity, maturity model position. No hallucinated metrics. - **Named ownership.** Every recommendation must name a responsible person and clarify handoffs. - **Smallest shippable learning unit.** Prefer minimal changes that produce a measurable signal quickly. Do not propose 6-month roadmaps. - **Safety and sustainability.** Do not recommend burnout, heroics, or policy violations. Optimize for sustained throughput. ### Sales-First Portfolio Directives (Ideas-Generation Scope) For `/lp-do-idea-generate`, operate in **sales-first mode**: - Treat **revenue businesses** as primary: `BRIK`, `PIPE`, `XA`, `HEAD`, `PET`, `HBAG`. - Treat **enabling systems** as secondary: `PLAT`, `BOS`. - **Mission:** maximize startup sales velocity; all but `BRIK` are startup streams and must be pushed to first/next sales ASAP. - **Portfolio split:** target `95%` of promoted/card-eligible output on direct revenue-business sales outcomes, max `5%` on side-project platform work. - **CMS exception:** `3-hour launch via CMS` remains a side project and must not block direct app delivery for sales. - **PLAT/BOS idea rule:** allowed only when they explicitly unblock a named revenue business sales bottleneck. - **UI/DS rule:** no standalone `@acme/ui` / `@acme/design-system` cleanup ideas. UI/DS ideas are valid only when attached to a concrete startup-sales deliverable. - **Convergence rule:** checkout/inventory paths for startup businesses must converge to shared platform authority; ideas that preserve long-term divergence are not promotable. - **Launch proof rule:** launch/sales-go-live ideas must include unit/integration/e2e evidence, two-source user testing evidence (CLI audit + ChatGPT prompting), SEO baseline, and Google monitoring baseline (GA4 + Search Console). --- ## Operating Mode **READ + ANALYZE + CONDITIONAL WRITE (Live) / PREVIEW (Dry-Run)** **Allowed:** - Read all agent API endpoints (businesses, people, cards, ideas, stage-docs) - Read business plans from filesystem: `docs/business-os/strategy//plan.user.md` - Read people profiles from filesystem: `docs/business-os/people/people.user.md` - Read the maturity model: `docs/business-os/strategy/business-maturity-model.md` - Read persona files from `_shared/cabinet/` as needed during execution - Create ideas via `POST /api/agent/ideas` (live mode only) - Create cards via `POST /api/agent/cards` (live mode only) - Create fact-find stage docs via `POST /api/agent/stage-docs` (live mode only) - Write sweep report to `docs/business-os/sweeps/-sweep.user.md` **Persistence mode (run-level):** - **Default (`live`):** run full pipeline including Stage 6/7 persistence. - **`--dry-run`:** run full analysis and ranking pipeline, but do NOT perform Stage 6/7 API write calls. Output preview tables for would-create ideas/cards/stage-docs in the sweep report. - **`--dry-run --allow-api-degraded`:** if Agent API preflight fails, continue using filesystem-only fallback inputs and mark run as degraded. **API preflight mode (run-level):** - **`strict` (default):** API preflight failures are fatal. - **`degraded-filesystem-only` (dry-run only):** allowed only when `--allow-api-degraded` is present. **Not allowed:** - Modify existing cards or ideas (no PATCH on cards/ideas — Drucker/Porter runs before card creation, so no priority updates needed) - Stage-doc PATCH is allowed only for latest-wins `fact-find` upsert safety (avoid duplicate stage-doc POSTs) - Move cards between lanes directly (baseline deterministic lane transitions are handled downstream by /lp-do-plan and /lp-do-build) - Run destructive commands - Auto-schedule or self-invoke ### In-Run Progress Updates (Mandatory) The sweep must provide progress visibility while execution is underway. **Progress artifact:** - Write to `docs/business-os/sweeps/-progress.user.md` (or run-scoped subdirectory equivalent when used). - Create the progress artifact as the first write action after invocation parsing. **Progress artifact frontmatter (required):** ```yaml --- Type: Sweep-Progress Date: YYYY-MM-DD Run-Status: running | complete | partial | failed-preflight Persistence-Mode: live | dry-run Stance: improve-data | grow-business Current-Stage: preflight | stage-1 | stage-2 | stage-3 | stage-4 | stage-5 | stage-5.5 | stage-6 | stage-7 | stage-7.5 | complete Last-Updated-UTC: YYYY-MM-DDTHH:MM:SSZ Progress-Events: N Final-Report-Path: --- ``` **Update cadence (required):** - Emit a progress event at each stage transition (start + complete). - Emit per-business progress events during long loops (Stage 1, Stage 2, Stage 4, Stage 5). - Emit heartbeat updates every `<=90 seconds` while a long stage is running. - After each progress artifact update, emit a concise terminal line: - `Progress: (/)` **Completion/failure finalization (required):** - On success or partial completion, set `Run-Status`, `Current-Stage: complete`, and `Final-Report-Path`. - On fatal preflight, still finalize progress artifact with `Run-Status: failed-preflight` and failure reason. ### Failure Policy (Two-Phase) **Phase 1 — Fatal (STOP sweep pipeline stages before persistence):** Stop the sweep if any of these fail: - Fetch businesses list from Agent API - Read maturity model file - Fetch existing cards/ideas/stage-docs for dedup + priority baseline In fatal cases: stop all pipeline stages and attempt one final write of a minimal sweep report marked `Run-Status: failed-preflight` including the error. **Dry-run degraded preflight fallback (explicitly opt-in):** - Trigger condition: `--dry-run --allow-api-degraded` and Agent API preflight fails. - Continue in `API-Preflight-Mode: degraded-filesystem-only` using: - filesystem business plans under `docs/business-os/strategy//plan.user.md` - maturity model file (still required) - people profiles file - Degraded consequences (must be reported): - existing cards/ideas/stage-doc baseline dedup may be unavailable - reaffirmation/addendum matching becomes low-confidence - set run `partial` unless API preflight recovers before Stage 6 - Live mode never uses degraded preflight fallback. **Phase 2 — Non-fatal (record + continue during persistence):** During Stages 6–7 (live-mode creates): - In `--dry-run`, do NOT issue write calls (`POST/PATCH`) to ideas/cards/stage-docs endpoints; record preview output instead. - Ideas/cards are non-idempotent POST creates. Do NOT blind-retry create calls. - On idea/card create failure: run one reconciliation read. If entity is confirmed, treat as success; if not, record failure and continue. - Stage docs use latest-wins upsert semantics (`GET /api/agent/stage-docs/{cardId}/fact-find` -> `PATCH` when present, `POST` only when missing). - Mark sweep report `Run-Status: partial` and list all failed creates/updates - Never create a stage doc unless its card exists - Emit a reconciliation checklist in the sweep report (what succeeded, what failed, exact repair commands, and next action owner) Rationale: ideas are always documented in the sweep report; persistence is best-effort without pretending transactional guarantees. --- ## MACRO Framework (Business Process Audit Categories) Every business is audited against 5 process categories. **Measure comes first** because without measurement, everything else is guesswork. ### M — Measure (Can you see what's happening?) Without measurement, you are flying blind. This is always the first question. | Diagnostic Question | What a "No" Means | |---|---| | Is web analytics installed and collecting data? (GA, Plausible, etc.) | You cannot measure traffic, conversion, or content performance. CRITICAL gap. | | Is Search Console connected? | You cannot measure SEO performance, indexing, or keyword rankings. | | Are conversion events tracked? (bookings, purchases, signups) | You cannot measure whether your site works. | | Is there marketing attribution? (UTM params, channel tracking) | You cannot measure which acquisition channels work. | | Are revenue metrics visible? (ADR, RevPAR, occupancy, GMV, AOV) | You cannot measure business health. | | Is customer feedback collected? (NPS, reviews, surveys, support tickets) | You cannot hear your customers. | | Are operational metrics tracked? (response time, fulfillment, error rates) | You cannot measure whether the machine runs well. | | Is there a time-series record? (even a spreadsheet) | You cannot detect trends. Every sweep starts from scratch. | ### A — Acquire (Are customers finding you?) Traffic that costs nothing to maintain is the foundation of sustainable growth. | Diagnostic Question | What a "No" Means | |---|---| | Is there organic search traffic? | All acquisition is paid — spend stops, traffic stops. | | Are content assets being produced? (guides, articles, landing pages) | No compounding SEO assets. Every visitor costs marginal money. | | Is content in target languages? | Missing international traffic at near-zero marginal cost. | | Are social/referral channels active? | Single-channel dependency. | | Is there a content calendar or production cadence? | Content production is ad-hoc, not systematic. | | Does the business appear in relevant directories/aggregators? | Missing distribution channels. | ### C — Convert (Are they buying?) Traffic without conversion is a vanity metric. | Diagnostic Question | What a "No" Means | |---|---| | Is there a clear call-to-action on every page? | Visitors don't know what to do. | | Is the checkout/booking flow optimized? | Friction kills conversion. | | Are pricing and availability clear? | Uncertainty prevents purchase. | | Is trust established? (reviews, social proof, security signals) | Customers don't trust you enough to transact. | | Are abandoned carts/bookings tracked and recovered? | Leaving money on the table. | | Is there A/B testing on conversion paths? | You're guessing, not learning. | ### R — Retain (Are they coming back?) Acquisition without retention is a leaky bucket. | Diagnostic Question | What a "No" Means | |---|---| | Is there post-purchase communication? (email, follow-up) | Customer relationship ends at checkout. | | Is there a loyalty/repeat purchase mechanism? | No reason to come back. | | Are customer service channels responsive? | Customers leave when ignored. | | Is there self-service content for common questions? | Every support query costs human time. | | Is customer satisfaction measured? | You don't know if customers are happy. | ### O — Operate (Is the machine efficient?) Even a good product fails if the operations are broken. | Diagnostic Question | What a "No" Means | |---|---| | Are core business operations documented? | Knowledge is in people's heads — bus factor = 1. | | Is there cross-app data flow? (products ↔ content ↔ bookings) | Manual data re-entry. Inconsistency. | | Are operational costs tracked? | You can't optimize what you don't measure. | | Is the development/deployment pipeline reliable? | Shipping is slow or risky. | | Are there automated quality checks? (content validation, data integrity) | Quality is manual and inconsistent. | | Is there capacity planning? (people, infrastructure, budget) | Surprises instead of planning. | --- ## Cabinet Pipeline (7 Stages) ### Stage 1: Preflight + Composite Generation **Source of truth for businesses:** Agent API (NOT businesses.json). **Preflight (per sweep):** 1. Fetch businesses from `GET /api/agent/businesses` (fatal if fails). 2. For each business: - Read business plan: `docs/business-os/strategy//plan.user.md` (degrade if missing). - Read maturity model fallback: `docs/business-os/strategy/business-maturity-model.md` (fatal if missing). - Read people profiles: `docs/business-os/people/people.user.md` (degrade if missing). - Fetch existing cards + ideas + stage-docs via Agent API (fatal if fails): - Build **Existing Priority Set**: - open cards (not Done/Archived), prioritize P1–P3 - tags include `cabinet-v1` and/or `sweep-generated` - Build **Existing Canon** for dedup: - normalize titles, cluster tags, and referenced problem statements 3. Build a **DGP Resurfacing Queue** from existing ideas (MANDATORY): - Include ideas tagged `dgp` + `gap:` with `status=raw` - Query contract: Agent API list calls support only `location=inbox|worked`. For full DGP backlog coverage, query both `inbox` and `worked`, then union by idea ID (do not use `location=all`). - Partition by `gap:data`, `gap:timing`, `gap:dependency` - Compute `Resurfacing-State`: - `ready-now`: - `gap:data`: default when stance is `improve-data`; rank by `VOI-Score` DESC - `gap:timing`: `Re-evaluate-When` is due (date <= today) or trigger explicitly met - `gap:dependency`: dependency evidence indicates prerequisite is complete - `watch`: valid DGP but trigger/dependency not yet satisfied - Output resurfacing table in sweep report (ready-now first) 4. For each business, write a **Constraint Statement** (1–3 sentences) with: - Current constraint (MACRO category) - Evidence pointers (file paths and/or API entities) - Constraint confidence (0–100, subjective) 5. Resolve **Human Assumptions Input** (optional): - Accept inline assumptions block from invocation context. - Accept `--assumptions-file ` when provided. - If both are present, file input wins. - Record assumptions source in report frontmatter (`none` | `inline` | `file`). 6. Apply **sales-first portfolio classification** for this run: - mark each business as `revenue` or `enabler` - define startup set (`PIPE`, `XA`, `HEAD`, `PET`, `HBAG`) for sales-velocity emphasis - enforce CMS work as side-project lane (non-blocking) **Composite Generation (per business):** Run sequential multi-lens passes to generate ideas. **Generation cadence (quality-first, mandatory):** 1. **Divergence pass:** Each sub-expert contributes at most 1 net-new candidate idea per business. 2. **Focus shortlist:** Rank divergence candidates by direct constraint relief + evidence quality + owner-fit + time-to-signal. 3. **Deepening pass:** Deepen only the top 8 candidates per business (hard cap: 10) before Stage 2. 4. **Depth gate:** Any candidate missing minimum evidence/falsification fields cannot enter Stage 2. **Sub-experts in order (generic — all businesses except BRIK):** 1. `musk` (Musk lens — feasibility) 2. `bezos` (Bezos lens — customer-backwards) 3. `hopkins` (Marketing lens — scientific advertising) 4. `ogilvy` (Marketing lens — brand) 5. `reeves` (Marketing lens — USP) 6. `lafley` (Marketing lens — consumer insight) 7. `patterson` (Sales lens — systematic selling) 8. `benioff` (Sales lens — challenger positioning) 9. `chambers` (Sales lens — ecosystem and distribution) 10. `finder` (Sourcing lens — product selection and supplier discovery) 11. `bridge` (Sourcing lens — negotiation and supplier relationship depth) 12. `mover` (Sourcing lens — logistics, compliance, and landed cost) **BRIK-specific sub-experts (replaces sourcing with brikette lens):** 1. `musk` (Musk lens — feasibility) 2. `bezos` (Bezos lens — customer-backwards) 3. `hopkins` (Marketing lens — scientific advertising) 4. `ogilvy` (Marketing lens — brand) 5. `reeves` (Marketing lens — USP) 6. `lafley` (Marketing lens — consumer insight) 7. `patterson` (Sales lens — systematic selling) 8. `benioff` (Sales lens — challenger positioning) 9. `chambers` (Sales lens — ecosystem and distribution) 10. `crawford` (Brikette lens — interior/lived comfort) 11. `starck` (Brikette lens — interior/bold identity) 12. `nakajima` (Brikette lens — maintenance/TPM) 13. `deming` (Brikette lens — maintenance/quality systems) 14. `kroc` (Brikette lens — cleaning/standards) 15. `gawande` (Brikette lens — cleaning/checklists) 16. `schulze` (Brikette lens — cleaning/culture) 17. `hopkins` (Brikette lens — hostel promotion/scientific advertising) 18. `ogilvy` (Brikette lens — hostel promotion/brand) 19. `sutherland` (Brikette lens — hostel promotion/behavioral economics) 20. `meyer` (Brikette lens — F&B/hospitality) 21. `degroff` (Brikette lens — F&B/bar program) 22. `schrager` (Brikette lens — events/atmosphere) 23. `jones` (Brikette lens — events/community) 24. `generator` (Brikette lens — events/hostel-native ops) **Note:** Hopkins and Ogilvy appear twice for BRIK — once under Marketing lens (generic frameworks) and once under Brikette lens (hostel-specific framing). Distinguished by `Originator-Lens: marketing` vs `Originator-Lens: brikette`. Clustering (Stage 3) handles any duplicate ideas. **Existing Priority Check (MANDATORY, per sub-expert):** Before proposing a new idea, check the Existing Priority Set / Canon: - If idea is already covered: do NOT create a new idea. - Output a "Reaffirmation/Addendum" note (lens viewpoint + existing card/idea reference) in the sweep report. - If genuinely new or materially different: proceed. **For each sub-expert (new ideas only):** 1. Read the lens file from `.claude/skills/_shared/cabinet/lens-.md` - For composite lenses with split experts (**marketing**, **sales**): also read `lens--.md` for the current sub-expert pass (e.g., `lens-marketing-hopkins.md` for Hopkins, `lens-sales-benioff.md` for Benioff). The coordinator file provides shared toolbox, stance behavior, and cross-lens rules; the individual file provides the expert's evidence anchor, required tools, and diagnostic questions. 2. Apply stance-specific diagnostic questions to the business: - Under `improve-data`: Focus on measurement, data quality, knowledge gaps - Under `grow-business`: Focus on revenue, acquisition, conversion, retention 3. Generate 0-1 candidate idea per sub-expert per business (divergence pass only) 4. Format each idea with Dossier Header (see `dossier-template.md`): - `Originator-Expert`: person-level attribution (e.g., `hopkins`) - `Originator-Lens`: lens-level grouping (e.g., `marketing`) - `Confidence-Tier`: Set to `candidate` initially - `Confidence-Score`: 0-100 (preliminary, before confidence gate) - `Pipeline-Stage`: Set to `candidate` - **`Impact-Type`:** growth | savings | risk-avoidance | time - **`Impact-Mechanism`:** Acquire | Convert | Retain | Measure | Operate - **`Impact-Band`:** XS | S | M | L | XL (see Impact rubric) - **`Impact-Confidence`:** 0-100 (subjective; must cite evidence pointers or mark unknown) **Impact rubric (for Impact-Band):** - **XS:** small/local improvement; unlikely to move a plan target materially - **S:** noticeable improvement; could move a sub-metric - **M:** meaningful; could move a primary KPI if executed well - **L:** large; likely to move a plan target materially - **XL:** step-change; materially changes the business trajectory **Deepening pass (mandatory before Stage 2):** - Keep top 8 candidates per business from divergence ranking (hard cap 10) - For each deepened candidate, add all of: - `Evidence-Pointers`: at least 2 concrete pointers (files, API entities, or metrics) - `Falsification-Test`: one explicit condition that could disprove the core claim - `First-Signal`: one measurable leading indicator with owner + review date - Candidates missing deepening fields are rerouted: - to DGP (`Gap-Type=data`) if thesis is promising but under-evidenced - to hunch log if no credible test/evidence path exists **Context discipline:** use compress-and-carry-forward plus summary-block mode and coverage thresholds from the Context Discipline Strategy section. **MACRO emphasis by stance** (see `stances.md`): - Under `improve-data`: Measure (HIGH), Operate (HIGH), Acquire (MEDIUM), Convert (MEDIUM), Retain (LOW) - Under `grow-business`: Acquire (HIGH), Convert (HIGH), Retain (MEDIUM), Measure (MEDIUM), Operate (LOW) **Musk 5-step constitutional invariant:** During the Musk lens pass, all recommendations must follow strict step ordering (Question → Delete → Simplify → Accelerate → Automate). This is a first-order constraint on the Musk lens only, not on other lenses. ### Stage 2: Confidence Gate For each candidate idea, evaluate against the 5 presentable criteria (see `dossier-template.md`). **Prerequisites:** - Impact fields (Impact-Type, Impact-Mechanism, Impact-Band, Impact-Confidence) must exist in the Dossier Header, even if values are `unknown`. - Stage 1 depth-gate fields must be present for every candidate entering Stage 2: - `Evidence-Pointers` (>=2) - `Falsification-Test` (exactly one explicit disproof condition) - `First-Signal` (metric + owner + review date) - Candidates missing depth-gate fields must not enter Stage 2; reroute to DGP/hunch per Stage 1 rules. **Assumption Challenge (F3, conditional):** - If `Assumptions-Source` is `inline` or `file`, evaluate each assumption and classify as `accept`, `condition`, or `reject`. - Each assumption verdict must include at least one evidence pointer and list affected ideas. - Ideas that depend on a `reject` assumption cannot remain Promote candidates; reroute to Hold (`Gap-Type=data`) unless revised with new evidence. - Record assumption-verdict notes in dossier decision logs and summarize in the report's Assumption Challenge section. 1. Customer/user identified — Who is this for? Named segment or persona. 2. Problem statement present — What pain or opportunity? Clear and specific. 3. At least one feasibility signal — Technical or commercial evidence this is doable. 4. Evidence or reasoning chain — Not just assertion. Data, research, or logical argument. 5. Business alignment — How does this serve a known business goal or fill a plan gap? **Scoring:** - **5/5 criteria met** → Confidence-Tier: `presentable`, Confidence-Score: 60-100 → Proceed to clustering - **3-4/5 criteria met** → Confidence-Tier: `decision-gap`, Confidence-Score: 30-59 → Create DGP (see below) - **0-2/5 criteria met** → Confidence-Tier: `hunch`, Confidence-Score: 0-29 → Log in sweep report only, do NOT persist **Decision Gap Proposals (DGPs):** DGP = **Decision Gap Proposal** (not only data gaps). - Create via `POST /api/agent/ideas` with: - `Status`: `raw` - `Tags`: `["sweep-generated", "cabinet-v1", "dgp", "gap:"]` where `` is `data`, `timing`, or `dependency` - `Content`: Full Dossier with Dossier Header **Required DGP fields in Dossier Header:** - `Gap-Type`: `data` | `timing` | `dependency` - `VOI-Score`: required only if Gap-Type=data (0-1 scale) - `Decision-Blocked`: what decision cannot be made - `Re-evaluate-When`: date or trigger condition - `Owner`: named person responsible for closing the gap **DGP content must include** (see `data-gap-lifecycle.md`): - Problem statement (provisional) - Proposed solution (sketch) - Blocking questions or triggers (numbered list) - Proposed investigation or re-evaluation plan - Presentable Criteria Check — which criteria are met, which are missing - VOI Justification — required for Gap-Type=data; optional for timing/dependency **Gap-Type definitions:** - **data**: Missing information blocks the decision. Requires VOI-Score + investigation plan. - **timing**: Idea is sound but timing is wrong. Requires triggers + re-evaluation date. - **dependency**: Prerequisite work must complete first. Names the prerequisite work + owners. **VOI-Score** (Value of Information, 0-1 — required for Gap-Type=data): - 0.8-1.0: High VOI (decision completely changes if data contradicts assumptions) - 0.4-0.7: Medium VOI (data helps but doesn't fundamentally change decision) - 0.1-0.3: Low VOI (could make decent decision without data) **Hunches (not persisted):** - Log in sweep report with rationale for suppression - If hunch gains new evidence in future sweep, re-submit as fresh evaluation **Stance sensitivity:** INVARIANT (confidence criteria do not change by stance) ### Stage 3: Cluster/Dedup Group presentable ideas using clustering rules (see `clustering.md`): **Hard clustering boundaries (NEVER violated):** 1. Never merge across businesses — BRIK ideas don't cluster with PIPE ideas 2. Never merge across jobs-to-be-done — Customer-facing vs infrastructure vs data-quality 3. Max cluster size: 4 lens variants **Clustering heuristic:** Two ideas cluster if: - Same business - Same MACRO category (same job-to-be-done) - Same core problem or opportunity (can be phrased differently but same essence) **Merged dossier structure:** 1. **Unified Dossier Header:** - `Originator-Expert`: First dossier in cluster (chronological) - `Originator-Lens`: First dossier in cluster - `Contributors`: All experts from all dossiers in cluster - `Confidence-Tier`: Highest tier from cluster - `Confidence-Score`: Highest score from cluster - `Pipeline-Stage`: Must be same for all cluster members (enforced) - `Cluster-ID`: Assigned (format: `{BUSINESS}-CLU-{NNN}`) - `Rival-Lenses`: Lenses that disagree on approach/priority/feasibility 2. **Unified Decision Log:** Concatenate all Decision Log blocks from cluster members 3. **Main Idea Content:** Most complete variant or synthesis 4. **Lens Variants Section:** Each lens's original perspective preserved as subsection 5. **Agreement Section:** Where lenses converge (what they agree on) 6. **Rivalry Section:** Where lenses disagree (what they disagree on, why, how to resolve) **Singletons:** Ideas with no match pass through unchanged **Stance sensitivity:** INVARIANT (clustering rules do not change by stance) ### Stage 4: Munger/Buffett/Thiel Filter Apply `filter-munger-buffett.md` persona (v2.2) to each clustered dossier. The filter now runs a two-phase process: **Read the filter persona file:** `.claude/skills/_shared/cabinet/filter-munger-buffett.md` **Phase 1 — Munger–Thiel Contrarian Gate (mandatory pre-check):** Produces a **Contrarian Status** (PASS / UNRESOLVED / FAIL) by evaluating 7 required artifacts: 1. Opposite-Side Steelman (Munger) — best argument against the idea 2. Inversion Pre-Mortem (Munger) — top 5 ways it dies with leading indicators + exits 3. Contrarian Secret (Thiel) — "most believe X, truth is ¬X" + operational advantage 4. Capture-Value Proof (Thiel) — pricing power under stress, why customers pay us 5. Competition Escape Plan (Thiel) — wedge, path to differentiation, "by cycle N" milestone 6. Market Definition Reality Check (Thiel) — narrow vs. skeptical framing 7. Incentive Truth-Bending Check (Munger × Thiel) — where we're tempted to misdescribe **Contrarian Status constrains the final verdict:** - **PASS** → verdict may be Kill, Hold, or Promote - **UNRESOLVED** (missing cheap facts) → verdict must be Hold (Promote is blocked) - **FAIL** (fatal) → verdict must be Kill (unless reframed as tiny timeboxed test → Hold) **Phase 2 — Munger–Buffett Capital-Allocation Verdict:** - **Munger:** Inversion (how could this fail?), mental model lattice, avoiding stupidity - **Buffett:** Circle of competence, margin of safety, opportunity cost, competitive moats **Verdicts (constrained by Contrarian Status):** - **Kill** → Reject permanently (outside competence, catastrophic downside, negative opportunity cost, no contrarian secret, commodity with no escape) - **Hold** → Defer (reason varies — see Gap-Type below) - **Promote** → Approve for next stage (requires Contrarian Status PASS + within competence, bounded downside, high optionality, passes inversion test, value capture credible) **Output:** Append TWO Decision Log blocks to dossier: 1. **Munger–Thiel Contrarian Gate block:** Contrarian Status + all 7 artifact sections 2. **Munger-Buffett Filter block:** Verdict + Verdict-Constrained-By + Rationale + Risk-Assessment + Opportunity-Cost **Killed ideas:** Logged in sweep report with Contrarian Status, not persisted **Held ideas:** Stored as DGPs (Decision Gap Proposals) with: - `Tags`: `["sweep-generated", "cabinet-v1", "dgp", "gap:", "held"]` - Gap-Type determined by Hold reason: - `data` — promising thesis but insufficient evidence (needs investigation) - `data` — Contrarian Status UNRESOLVED (missing cheap facts for gate artifacts — see `data-gap-lifecycle.md`) - `timing` — good idea but market/team isn't ready (needs trigger/date) - `dependency` — blocked by prerequisite work (needs that work to complete) - For Contrarian Gate UNRESOLVED holds: add `gate-unresolved` tag and specify which of the 7 artifacts are incomplete **Promoted ideas:** Must have Contrarian Status PASS. Proceed to Drucker/Porter priority (Stage 5) **Stance sensitivity:** STANCE-INVARIANT (bad ideas are bad regardless of stance) ### Stage 5: Drucker/Porter Priority Apply `prioritize-drucker-porter.md` persona to rank all promoted dossiers **before** card creation: **Input validation:** Only ideas with Verdict=Promote and Contrarian Status=PASS enter this stage. Ideas with Kill or Hold verdicts must not reach Stage 5 (Kill → sweep report only; Hold → DGP). **Read the prioritizer persona file:** `.claude/skills/_shared/cabinet/prioritize-drucker-porter.md` **Read business plans:** For each business, read `docs/business-os/strategy//plan.user.md` - If plan missing: flag as critical finding in sweep report, fall back to maturity model - Maturity model path: `docs/business-os/strategy/business-maturity-model.md` **Evaluation framework:** - **Drucker:** Effectiveness over efficiency (doing the right things), manage by objectives, knowledge worker productivity - **Porter:** Five forces, value chain, strategic positioning (cost leadership OR differentiation), activity system fit **Priority levels:** - **P1:** Do immediately (high impact, clear path, urgent timing, strong plan alignment) - **P2:** Do soon (high impact but needs preparation) - **P3:** Schedule for later (medium impact, good fit, lower urgency) - **P4:** Keep in backlog (low urgency, potentially valuable later) - **P5:** Deprioritize (low fit, low impact, wrong timing) **Stance weighting (STANCE-SENSITIVE):** Under `improve-data`: - Higher weight: Measurement infrastructure, data quality, knowledge gaps, feedback loops, plan/profile completeness - Lower weight: Revenue tactics, feature development, market expansion - MACRO emphasis: Measure (HIGH), Operate (HIGH), Acquire (MEDIUM), Convert (MEDIUM), Retain (LOW) Under `grow-business`: - Higher weight: Customer acquisition, conversion optimization, revenue growth, retention, competitive positioning - Lower weight: Pure infrastructure without growth link, measurement for measurement's sake - MACRO emphasis: Acquire (HIGH), Convert (HIGH), Retain (MEDIUM), Measure (MEDIUM), Operate (LOW) **Sales-first portfolio gates (mandatory in both stances):** - Revenue businesses (`BRIK`, `PIPE`, `XA`, `HEAD`, `PET`, `HBAG`) are the default promotion path. - `PLAT`/`BOS` ideas must include: - `Enabled-Business`: one of the revenue businesses - `Sales-Blocker`: explicit blocker removed - `Unblock-SLA`: date/clock for expected unblock signal - `CMS` 3-hour launch ideas are side-project candidates only; cap to <=5% of P1-P3 card-eligible output per sweep and never ahead of unresolved startup sales blockers. - Reject standalone UI/DS cleanup (`@acme/ui`, `@acme/design-system`) unless tied to a named startup-sales deliverable and measurable sales effect. - Startup commerce ideas must reinforce checkout/inventory convergence toward shared platform authority; non-convergent proposals are capped at P4/P5 unless they include an explicit convergence milestone. **Output:** Append Decision Log block to dossier with: - Priority: [P1|P2|P3|P4|P5] - Potential-Impact: [Impact-Band from dossier + mechanism + confidence assessment] - Strategic-Fit: How this aligns with business plan targets - Plan-Target: Which specific plan target this addresses - Stance-Weight: How stance influenced the ranking - Sales-Link: direct sales outcome path for this idea - Enabled-Business: revenue business directly enabled (`self` for revenue-business ideas) - Economics-Gate: [pass|blocked] - Economics-Missing-Fields: [list of missing fields, empty if pass] - Sales-Readiness-Gate: [pass|blocked|n/a] - Sales-Readiness-Missing-Fields: [list of missing launch-proof fields, empty if pass] - Rationale: 2-3 sentences using effectiveness, positioning, or value chain reasoning **Economics gate (F5, mandatory before Stage 6):** - A Promote candidate must include all fields: - `Upside` - `Downside` - `Reversibility` - `Cost-of-Delay` - `Time-to-Signal` - If any field is missing: - set `Economics-Gate: blocked` - block card eligibility for that idea - reroute to Hold (`Gap-Type=data`) with missing fields recorded - include the idea in the report's Economics Gate section with blocker reason **Sales-readiness gate (mandatory for startup launch/sales-go-live ideas):** - If idea claims launch readiness, checkout readiness, or near-term sales-go-live, it must include: - `Unit-Test-Evidence` - `Integration-Test-Evidence` - `E2E-Test-Evidence` - `User-Test-CLI-Audit-Evidence` - `User-Test-ChatGPT-Evidence` - `SEO-Baseline-Evidence` - `Google-Monitoring-Evidence` (GA4 + Search Console baseline; equivalent signal allowed only with explicit rationale) - CLI audit settings contract for `User-Test-CLI-Audit-Evidence`: - Must reference a current output from `.claude/skills/meta-user-test/scripts/run-meta-user-test.mjs` - Must include no-JS predicate evidence: `NO_JS_BAILOUT_MARKER`, `hasNoI18nKeyLeak`, `hasMetadataBodyParity`, `hasSocialProofSnapshotDate` - Must include SEO artifacts from the same run: `...-seo-summary.json` and `...-seo-artifacts/` - Must include smoke/go-live signal for launch path confidence: `pnpm launch-smoke --wait --json` (or config `smokeChecks`) and applicable launch-go-live gate status - Two-source user-testing contract (mandatory): - Source A: CLI-agent audit evidence (contract above) - Source B: ChatGPT prompting evidence (prompt set, date, verdict, critical risks/open questions) - Single-source user testing is invalid for launch/sales-go-live promotion - If any required field is missing: - set `Sales-Readiness-Gate: blocked` - block card eligibility for that idea - reroute to Hold (`Gap-Type=data`) with missing fields recorded - include the idea in the report's gate section with blocker reason **Traction mode (under `grow-business`, market-facing L1-L2 businesses only):** - Use traction-mode Decision Log format for P1/P2 (includes Traction Objective, Test Plan, Porter Fit, Abandonment) - Output a **Rigor Pack** for each P1/P2 (5 components: Objective & Contribution Card, Traction Test Card, Trade-off Statement, Evidence & Unknowns, Abandonment Note) - Rigor Pack content is passed to Stage 7 for fact-find stage doc pre-population - P1 cap: max 3 P1s per business per sweep - Reversibility rule: if Munger/Buffett noted "bounded and reversible downside" → Rigor Pack sufficient; if cautious → require Full Strategy Pack - Infrastructure businesses (PLAT, BOS) use standard format under `grow-business`, no traction mode **No PATCH calls needed:** Priority is assigned before card creation (Stage 6), so cards are created with the correct priority from the start. **Stance sensitivity:** STANCE-SENSITIVE (plan target weighting changes by stance; traction mode activates under `grow-business` for L1-L2 market-facing businesses) ### Stage 5.5: Persistence Prepare (3A Contract) Build persistence artifacts before any write …(truncated)