mustflow 2.116.4 → 2.117.0

package/templates/default/locales/en/.mustflow/skills/service-portfolio-capital-allocation-review/SKILL.md

@@ -0,0 +1,245 @@
+---
+mustflow_doc: skill.service-portfolio-capital-allocation-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: service-portfolio-capital-allocation-review
+description: Apply this skill when a solo founder or small product portfolio decides when shared backend or platform investment breaks even, how correlated outages and failure cells change common-versus-independent architecture economics, when a low-usage service should be maintained, rescued, archived, redirected, sold, or shut down, or how to allocate limited time between launching new services and improving conversion, retention, reliability, or contribution in existing services.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.service-portfolio-capital-allocation-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Service Portfolio Capital Allocation Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Allocate shared-platform investment, service continuation, shutdown, rescue experiments, new launches,
+and existing-product improvements by future marginal contribution under correlated failure and founder
+time constraints. Prevent project counts, user counts, gross revenue, sunk cost, or fixed percentage
+rules from keeping zombie services alive or multiplying operational debt.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A portfolio compares shared authentication, billing, data, admin, deployment, or operations with
+  independently built services and asks for a break-even project count.
+- Shared infrastructure may reduce duplicated work while increasing outage blast radius, recovery
+  congestion, security exposure, or portfolio-wide support load.
+- A low-usage or low-revenue service needs a maintain, automate, harvest, rescue, archive, redirect,
+  sell, or shutdown decision.
+- Search traffic, cross-product conversion, brand value, contractual obligations, support time,
+  security risk, closure cost, or customer migration changes a service-retirement decision.
+- A solo founder or small team allocates time between new launches and conversion, activation,
+  retention, reliability, cost, or support improvements in existing products.
+- The decision needs marginal contribution, NPV, opportunity cost, effective service count,
+  diminishing returns, context-switch cost, or portfolio capacity limits.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only designs or implements a shared Product Registry, auth, billing, credit, entitlement,
+  admin, deployment, analytics, or app factory after the investment is approved; use
+  `small-service-platform-architecture-review` and narrower technical skills.
+- The task only changes common accounts, wallets, bundles, product brands, or cross-product customer
+  rights; use `product-portfolio-integrity-review`.
+- The task only optimizes one product's onboarding, pricing, subscription retention, engagement, or
+  acquisition experiment; use the matching product skill.
+- The task only evaluates automation economics; use `automation-investment-case-review`.
+- The task requests legal advice about service termination, refunds, notice, records, tax, employee
+  action, or insolvency. Use current contracts and qualified authority; this skill supplies the
+  economic and operational decision packet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Portfolio ledger: services, owners, lifecycle stage, customer jobs, complements and substitutes,
+  current users, paid customers, contribution margin, growth, retention, support, operations,
+  security, incident, and strategic dependencies.
+- Shared-platform ledger: up-front build and migration, common operation, per-service integration,
+  avoided duplication, vendor and runtime dependencies, change coordination, cells, data stores,
+  queues, deploys, backups, restore, and exit or de-sharing cost.
+- Failure ledger: independent incident probability and loss, shared incident probability and loss,
+  affected services, revenue-at-risk per hour, support and recovery concurrency, secondary failure,
+  security blast radius, RTO, RPO, and insurance or reserve assumptions.
+- Service economics ledger: direct contribution, search and referral contribution, cross-product
+  contribution, cash maintenance, founder hours, replacement cost, best alternative use of time,
+  risk reserve, future investment, and closure cost.
+- Preservation ledger: customer migration, refunds, data export, read-only period, domain and content
+  redirects, search preservation, license or subscription obligations, support tail, archive cost,
+  and value retained after closure.
+- Growth evidence: normalized cohort horizon, renewal cycle, optimistic and conservative growth,
+  seasonality, campaigns, product-market-fit evidence, remaining experiment budget, and confidence.
+- Work candidate ledger: expected incremental twelve-month contribution, success probability,
+  cash cost, required hours, future maintenance, reusable assets, cross-product effect, time-to-learn,
+  diminishing returns, switching cost, and stop condition.
+- Current authority ledger for customer notice, refunds, data retention, deletion, export, domains,
+  marketplace listings, and platform shutdown obligations.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Use contribution after variable cost, refund, support, and direct operating cost rather than gross
+  revenue when the goal is portfolio value.
+- Convert search, referrals, cross-product use, founder time, incident risk, and preserved closure
+  value into one economic unit before combining them. Do not use arbitrary weighted scores.
+- Separate reusable standards and adapters from shared runtime, shared database, and shared failure
+  domains. Common code does not require common outages.
+- Treat copied project counts, service age, user thresholds, growth cutoffs, time splits, discount
+  rates, and valuation horizons as examples, not policy defaults.
+- This skill does not authorize shutdown, customer notice, refund, data deletion, migration,
+  staffing, purchase, production restructuring, release, or deployment.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine portfolio decision records, cost and failure models, service scorecards expressed as
+  contribution, preservation and closure plans, rescue experiment gates, capacity allocation,
+  events, fixtures, tests, docs, route metadata, and synchronized templates.
+- Add explicit handoffs to platform architecture, service boundaries, reliability, auth, payment,
+  data, privacy, legal, SEO, migration, support, or product experiment owners.
+- Replace raw project count, MAU shutdown thresholds, gross revenue, weighted scorecards, sunk-cost
+  arguments, or fixed launch percentages with auditable marginal-value and risk evidence.
+- Do not terminate a live service, delete data, redirect domains, cancel contracts, migrate customers,
+  or change shared infrastructure without explicit authority and the narrower operational skills.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Set the decision horizon and unit. Prefer future contribution or another explicit owner-selected
+   objective; do not silently optimize gross revenue when margin, risk, or founder capacity matters.
+2. Split shared-platform economics into reusable specification, SDK or adapter, control plane,
+   runtime, data, deployment, and failure domain. Common contracts can be valuable before one shared
+   runtime or database is safe.
+3. Model the independent alternative. Include repeated design and build work, per-service auth and
+   billing operations, support tooling, migrations, upgrades, security maintenance, and independent
+   incident reserves.
+4. Model the shared alternative. Include fixed platform and migration investment, per-service
+   integration, common operations, coordination, compatibility, platform maintenance, de-sharing,
+   and per-service residual work.
+5. Price correlated failure separately. Include simultaneous lost contribution, recovery congestion,
+   customer communications, support queues, security blast radius, secondary fixes, and time that a
+   solo operator cannot perform in parallel.
+6. Derive the break-even interval from current inputs. Compare total independent and shared cost for
+   each plausible effective service count. A shared platform can have both a lower break-even bound
+   and an upper point where correlated failure or coordination makes another topology cheaper.
+7. Report denominator failure. If per-service savings are zero or negative, no finite project count
+   repays the fixed platform investment under the model. If correlated loss dominates after a point,
+   report the bounded winning interval rather than "more services is always better."
+8. Use effective service count alongside raw count. Weight services by recurring operations,
+   support, decision load, change coupling, revenue-at-risk, and special compliance rather than
+   treating an automated hobby service and a high-loss product as equal units.
+9. Test cell isolation. Share identity standards, payment adapters, schemas, SDKs, admin patterns,
+   deployment tools, and observability where valuable while bounding runtime, queues, ledgers,
+   databases, backups, deploys, and recovery by product or risk cell.
+10. Choose cell boundaries by failure loss and recovery capacity. A high-revenue, high-risk, or
+    regulated service may need isolation regardless of total project count; a small set of similar
+    low-loss services may safely share more.
+11. Build each service's continue-versus-close cash flow. Include direct contribution, incremental
+    search and cross-product value, cash maintenance, founder time at opportunity cost, incident and
+    security reserve, future investment, and closure timing.
+12. Estimate value preserved after closure. Include migration, redirects, archives, read-only access,
+    customer export, retained search, transferred subscriptions, and ongoing obligations. Avoid
+    treating every current benefit as fully destroyed or fully preserved.
+13. Prevent double counting. A customer acquired through search and then moved to another product
+    cannot create full search value and full cross-product value twice. Attribute one incremental
+    path or split it explicitly.
+14. Price founder time at the greater relevant alternative: replacement cost or the marginal value
+    of the best credible growth, reliability, or risk-reduction work displaced. A nominal wage can
+    keep support-heavy zombie products alive.
+15. Compare continuation NPV with closure now. Include discounting, forecast ranges, closure now and
+    later costs, obligations, and the normal product or renewal cycle. Do not decide from one noisy
+    month.
+16. Derive required growth to cover the remaining burden. Compare the optimistic evidence-supported
+    growth bound with the growth needed by a named horizon after preserved search or cross-product
+    value. If no direct contribution base exists, do not manufacture a percentage.
+17. Require repeated evidence before irreversible closure when the decision is noisy. Use at least
+    one representative usage or renewal cycle and define which second observation, notice window,
+    export, refund, or contractual gate is required.
+18. Gate a final rescue experiment by expected incremental value. Include success probability,
+    contribution if successful, cash cost, founder hours, delay to closure, support tail, and a hard
+    stop. Do not grant another experiment because of effort already spent.
+19. Build the available growth-time budget after unavoidable maintenance, support, incidents,
+    administration, and recovery capacity. If the forced operating load consumes the budget, reduce
+    or retire obligations before starting another product.
+20. Value each launch or improvement candidate on the same horizon. Include probability-adjusted
+    contribution, time-to-learn, cash, future maintenance, reusable assets, cross-product effects,
+    and the remaining upside after prior optimization.
+21. Discount pre-product-market-fit conversion work when retention or repeated value is unproven,
+    while allowing retention, core-value, and learning work to address that uncertainty directly.
+22. Allocate the next hour to the candidate with the highest current marginal contribution until
+    diminishing returns, prerequisites, risk limits, or the time budget changes the order. Do not
+    preserve a fixed launch-versus-improvement percentage after the inputs move.
+23. Charge context switching and work-in-progress. A mathematical solution that assigns tiny slices
+    to many services can lose to a smaller active set once setup, monitoring, interruption, and
+    decision costs are included.
+24. Keep a bounded active portfolio. Select a primary compounding improvement and at most the number
+    of discovery bets the operator can run without hiding support or reliability work; put the rest
+    in an explicit queue with expiry and reevaluation evidence.
+25. Define promotion, pause, archive, sell, and shutdown states. Preserve customer rights, receipts,
+    data, exports, redirects, notices, support, and audit evidence through each transition.
+26. Measure realized portfolio contribution, not plan completion. Re-estimate savings, correlated
+    incidents, service contribution, founder hours, experiment returns, and context-switch load on a
+    fixed cadence, then move capacity only when current evidence changes the marginal order.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Shared-platform break-even includes fixed investment, per-service savings, residual work,
+  correlated incidents, recovery congestion, effective service count, and isolation topology.
+- Service continuation or closure uses future incremental contribution, preserved value, founder
+  opportunity cost, risk, growth requirements, obligations, and closure cost rather than users or
+  gross revenue alone.
+- Rescue experiments have expected-value and stop gates.
+- New launches and existing improvements compete on the same marginal contribution horizon with
+  maintenance, diminishing returns, and context-switch cost visible.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and
+`mustflow_check`. Do not infer live billing, analytics, incident, customer-notice, refund, migration,
+domain, data export, deletion, shutdown, deployment, staffing, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If shared and independent alternatives omit the same outcome or lifecycle stage, stop the
+  break-even claim and normalize the comparator.
+- If correlated outage loss or recovery capacity is unknown, report the platform result without a
+  failure-adjusted break-even claim.
+- If search or cross-product contribution is observational, discount or bound it and state that the
+  service-retirement decision remains sensitive to incrementality.
+- If customer rights, notice, export, refund, retention, or deletion obligations are unknown, do not
+  approve shutdown even when the economic continuation value is negative.
+- If one uncertain assumption reverses the time allocation, report its threshold and choose the
+  smallest reversible measurement before committing a large block of founder capacity.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Portfolio objective, horizon, services, effective service count, and founder capacity
+- Independent and shared fixed, variable, residual, coordination, failure, and de-sharing costs
+- Break-even interval, cell topology, revenue-at-risk, recovery capacity, and sensitivity
+- Per-service direct, search, cross-product, maintenance, founder-time, risk, preservation, closure,
+  NPV, required-growth, and rescue-experiment decision
+- Launch and improvement candidates, marginal contribution, diminishing returns, switching cost,
+  active set, queue, and reallocation rule
+- Current authority, files changed, command intents run and skipped checks
+- Remaining service-portfolio capital-allocation risk

package/templates/default/locales/en/.mustflow/skills/subscription-retention-profit-review/SKILL.md

@@ -0,0 +1,217 @@
+---
+mustflow_doc: skill.subscription-retention-profit-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: subscription-retention-profit-review
+description: Apply this skill when a subscription product designs, implements, experiments on, or reports cancellation flows, churn reasons, save offers, downgrades, pauses, trial extensions, discounts, usage credits, dormant-user reactivation, win-back campaigns, offer sequencing, resumed billing, retention, CLTV, or incremental contribution profit and must avoid counting natural returners, paused users, or discounted would-have-stayed subscribers as causal saves.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.subscription-retention-profit-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Subscription Retention Profit Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose cancellation, pause, downgrade, reactivation, credit, discount, or no-offer policies by
+incremental contribution profit and durable paid behavior rather than offer acceptance or apparent
+save rate. Keep cancellation easy while preventing discounts from cannibalizing full-price revenue.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A product adds or changes cancellation reasons, save offers, downgrade, pause, extension, credit,
+  discount, support, feature-remediation, or cancellation confirmation flows.
+- Dormant active subscribers, expired subscribers, churned payers, trial users, unactivated payers,
+  or seasonal users receive re-engagement or win-back treatment.
+- Offer eligibility, ordering, personalization, holdouts, control groups, observation horizons,
+  retention metrics, reactivation metrics, CLTV, or contribution-margin decisions change.
+- A report claims a pause reduced churn, a discount saved customers, a credit increased return, or a
+  campaign improved lifetime value.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is invoice, entitlement, renewal, proration, tax, refund, chargeback, provider state,
+  webhook, or subscription-state correctness; use `payment-integrity-review`.
+- The main risk is credit reservation, grant, expiry, balance, capture, reversal, or settlement
+  correctness; use `credit-ledger-integrity-review`.
+- The main risk is email, SMS, push, webhook, in-app notification delivery, deduplication, consent,
+  suppression, or provider receipt; use `notification-delivery-integrity-review`.
+- The main risk is new-user signup activation rather than post-purchase retention or reactivation;
+  use `product-onboarding-activation-review`.
+- The task is involuntary churn caused by failed payment and does not change voluntary retention
+  policy; use payment, retry, dunning, and notification skills as appropriate.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Eligibility ledger: subscription state, plan and billing period, trial or paid state, cancellation
+  status, payment health, last core-value event, expected usage cadence, tenure, prior offers,
+  discount or credit history, churn reason, geography, consent, and exclusion rules.
+- State ledger: active paid, inactive paid, cancel scheduled, paused, resumed-unbilled, first resumed
+  payment, later resumed payment, expired, churned, reactivated, refunded, disputed, and terminal
+  states with source-of-truth ownership.
+- Treatment ledger: no contact, feature or task reminder, support, usage credit, downgrade, pause,
+  discount, trial or free-time extension, plan change, and cancellation; eligibility, cost, duration,
+  order, exclusivity, and cooldown for each.
+- Causal ledger: assignment unit, randomization, no-offer or business-as-usual holdout, exposure,
+  natural return, would-have-stayed users, interference, sample-ratio integrity, delayed outcomes,
+  and analysis policy.
+- Profit ledger: collected revenue, refunds, chargebacks, taxes and fees where applicable, variable
+  service cost, credit consumption cost, discount cost, support cost, messaging cost, payment cost,
+  reactivation cost, and contribution margin per eligible assigned user.
+- Pause ledger: eligible plans, start boundary, duration choices, access and entitlement behavior,
+  usage metering, resume date and amount, reminders, extension, early resume, cancellation, payment
+  authentication, dispute risk, and post-resume success definition.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Keep cancellation available without requiring offer acceptance, support contact, hidden steps, or
+  repeated persuasion. Retention optimization does not authorize dark patterns.
+- Separate observed acceptance, resumed billing, later paid survival, and incremental causal profit.
+  None proves another without the declared evidence.
+- Treat vendor benchmarks, case studies, aggregate pause-return rates, churn reasons, discount
+  acceptance, and reactivation rates as priors, not transferable effect sizes or default policy.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  campaigns, production billing changes, credits, discounts, messages, data queries, or experiments.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine retention policy, churn-reason routing, offer eligibility, experiment assignment,
+  holdouts, pause lifecycle, downgrade and credit rules, contribution-margin metrics, event schemas,
+  tests, docs, route metadata, and synchronized templates.
+- Add a no-contact or business-as-usual control when outreach itself can remind inactive subscribers
+  to cancel or natural reactivation can be mistaken for treatment lift.
+- Remove broad discounts or fixed offer ladders that ignore current state, churn reason, prior
+  behavior, cost, or cannibalization.
+- Do not silently alter billing, entitlement, refund, tax, credit, notification consent, or legal
+  cancellation behavior while changing the product-policy layer.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the decision unit and business outcome. Use incremental contribution margin per eligible
+   assigned user over a declared horizon, with retention and paid survival as explanatory outcomes.
+   Offer acceptance and interrupted cancellation are not the optimization target.
+2. Segment by authoritative lifecycle state before choosing a treatment. Distinguish active but
+   inactive subscribers, cancel-scheduled subscribers, paused subscribers, expired or churned former
+   payers, trial users, never-activated payers, and involuntary payment failures.
+3. Define inactivity from missing core-value behavior relative to expected product or user cadence.
+   Do not make a universal last-login day count authoritative for daily, seasonal, project-based,
+   annual, or episodic products.
+4. Preserve a no-offer or business-as-usual holdout. Measure natural continuation, natural return,
+   cancellation triggered by outreach, and treatment cannibalization. Keep holdout eligibility and
+   assignment stable long enough to observe the declared money outcome.
+5. Calculate incremental profit from all assigned users. Include collected full-price and discounted
+   revenue, pause deferral, refunds, disputes, variable service and credit cost, payment and messaging
+   fees, support, and later re-churn. Do not condition the headline result on opening, accepting,
+   resuming, or paying.
+6. Collect one low-friction cancellation reason when it changes the next remedy, while preserving a
+   direct cancellation path and an unknown or decline-to-answer route. Treat free text as evidence,
+   not permission to infer sensitive facts or force an offer.
+7. Match remedy to mechanism. Use a smaller plan for durable price or capacity mismatch, pause for a
+   temporary need gap, task-specific onboarding or support for unrealized value, feature remediation
+   for a missing or broken capability, and a bounded price concession only where price sensitivity
+   is supported and full-price alternatives are unsuitable.
+8. Avoid discount-first policy. An accepted discount may include users who would have stayed or
+   returned at full price. Compare it with no offer, downgrade, pause, credit, support, or task
+   reminder on incremental contribution rather than acceptance count.
+9. Distinguish active-subscriber re-engagement from post-churn win-back. For inactive current payers,
+   compare relevant task or feature help with silence before adding a monetary concession. For former
+   payers, test full-price re-entry and product-use incentives separately from subscription-price
+   discounts.
+10. Price usage credits as real variable cost. Bind credit to a value-producing action when useful,
+    declare expiry from local cadence and user expectation, prevent cash-like substitution unless
+    intended, and route balance correctness through `credit-ledger-integrity-review`.
+11. Treat pause as a distinct nonpaying or deferred-paying state, not an active retained customer.
+    Track pause entry, scheduled resume, actual resume, first successful resumed payment, later paid
+    survival, early cancellation, refund, and dispute separately.
+12. Choose pause duration and defaults from billing period, need cadence, seasonality, resume risk,
+    cash-flow cost, and provider constraints. Do not copy a universal one-month or three-month order.
+    State the resume date and amount clearly and notify the user before automatic resumption under
+    applicable consent and consumer rules.
+13. Keep offer ownership singular. Prefer one reason-matched primary remedy over a parade of offers.
+    If a fallback sequence is necessary, record how earlier offers change eligibility and prevent a
+    later discount from taking credit for a user already retained by another mechanism.
+14. Preserve stable assignment and treatment history across devices, campaigns, support contacts,
+    cancellation retries, plan changes, and later reactivation. Enforce cooldowns so repeated entry
+    cannot farm discounts, extensions, pauses, or credits.
+15. Use an observation horizon that covers the product's billing and usage cycle plus meaningful
+    post-treatment survival. Early save rate, pause acceptance, first resumed payment, or short-term
+    reactivation remains preliminary until the declared contribution outcome matures.
+16. Analyze heterogeneity only with declared segments and enough support. Plan period, category,
+    tenure, prior value, reason, cadence, geography, and cost can change treatment effect; do not turn
+    a post-hoc winning slice into automatic eligibility without new validation.
+17. Separate policy from execution. Route invoice, entitlement, provider, proration, and refund
+    correctness to `payment-integrity-review`; notification delivery and consent to
+    `notification-delivery-integrity-review`; credit accounting to `credit-ledger-integrity-review`.
+18. Promote a policy only when incremental contribution and guardrails improve for the eligible
+    cohort or a preregistered supported segment. Preserve easy cancellation, privacy, support,
+    refund, dispute, and reactivation guardrails.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Retention policy is state- and reason-aware and has a no-offer or business-as-usual causal baseline.
+- The headline metric is incremental contribution per eligible assigned user, not offer acceptance,
+  interrupted cancellation, or acceptor-only revenue.
+- Natural returners, would-have-stayed subscribers, pause states, resumed billing, later paid
+  survival, refunds, and re-churn remain distinguishable.
+- Discounts, credits, downgrade, pause, support, and reminders have explicit cost, eligibility,
+  cooldown, and cannibalization treatment.
+- Cancellation remains direct and user-controlled.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer raw billing, payment-provider, warehouse, campaign, credit, experiment, or production
+commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If no holdout or credible causal comparison exists, report acceptance and cohort outcomes as
+  observational and do not label them incremental saves or profit.
+- If billing or entitlement state is ambiguous, stop offer automation until the authoritative state
+  is reconciled.
+- If pause resume, later payments, refunds, or disputes have not matured, keep the result preliminary.
+- If a monetary offer wins only on save rate but loses contribution margin, reject it as a profit
+  policy.
+- If cancellation requires accepting or exhausting offers, restore a direct path before optimizing
+  retention.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Eligible lifecycle states, cadence, and assignment unit
+- Holdout, exposure, natural-return, and cannibalization evidence
+- Churn reason and reason-matched treatment policy
+- Incremental contribution components and observation horizon
+- Pause, resume, payment-survival, refund, and re-churn states
+- Discount, downgrade, credit, support, reminder, and no-offer decisions
+- Billing, credit, notification, privacy, and cancellation boundaries
+- Files changed
+- Command intents run and skipped checks
+- Remaining subscription-retention profit risk
+

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.116.4"
+version = "2.117.0"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -235,9 +235,32 @@ creates = [
   ".mustflow/skills/llm-hallucination-control-review/SKILL.md",
   ".mustflow/skills/llm-token-cost-control-review/SKILL.md",
   ".mustflow/skills/llm-response-latency-review/SKILL.md",
+  ".mustflow/skills/llm-model-routing-integrity-review/SKILL.md",
   ".mustflow/skills/agent-execution-control-review/SKILL.md",
+  ".mustflow/skills/agent-runtime-multi-worker-review/SKILL.md",
+  ".mustflow/skills/agent-runtime-isolation-review/SKILL.md",
+  ".mustflow/skills/agent-planning-recovery-review/SKILL.md",
+  ".mustflow/skills/agent-release-bundle-rollout-review/SKILL.md",
+  ".mustflow/skills/automation-investment-case-review/SKILL.md",
+  ".mustflow/skills/product-onboarding-activation-review/SKILL.md",
+  ".mustflow/skills/subscription-retention-profit-review/SKILL.md",
+  ".mustflow/skills/product-engagement-retention-review/SKILL.md",
+  ".mustflow/skills/credit-monetization-integrity-review/SKILL.md",
+  ".mustflow/skills/pricing-model-integrity-review/SKILL.md",
+  ".mustflow/skills/game-economy-monetization-review/SKILL.md",
+  ".mustflow/skills/freemium-ad-monetization-review/SKILL.md",
+  ".mustflow/skills/referral-incentive-integrity-review/SKILL.md",
+  ".mustflow/skills/llm-product-monetization-review/SKILL.md",
+  ".mustflow/skills/game-liveops-commerce-integrity-review/SKILL.md",
+  ".mustflow/skills/growth-distribution-integrity-review/SKILL.md",
+  ".mustflow/skills/product-portfolio-integrity-review/SKILL.md",
+  ".mustflow/skills/localization-market-expansion-review/SKILL.md",
+  ".mustflow/skills/desktop-commercial-distribution-review/SKILL.md",
+  ".mustflow/skills/client-platform-strategy-review/SKILL.md",
+  ".mustflow/skills/service-portfolio-capital-allocation-review/SKILL.md",
   ".mustflow/skills/browser-automation-reliability-review/SKILL.md",
   ".mustflow/skills/agent-eval-integrity-review/SKILL.md",
+  ".mustflow/skills/agent-memory-context-governance-review/SKILL.md",
   ".mustflow/skills/ui-quality-gate/SKILL.md",
   ".mustflow/skills/external-prompt-injection-defense/SKILL.md",
   ".mustflow/skills/external-skill-intake/SKILL.md",
@@ -483,9 +506,15 @@ minimal = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "failure-triage",
   "file-path-cross-platform-change",
   "idea-triage",
@@ -684,9 +713,15 @@ patterns = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "facade-pattern",
   "failure-triage",
   "file-path-cross-platform-change",
@@ -898,9 +933,15 @@ oss = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "external-skill-intake",
   "github-contribution-quality-gate",
   "facade-pattern",
@@ -1121,15 +1162,30 @@ team = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "github-contribution-quality-gate",
   "facade-pattern",
   "failure-triage",
   "file-path-cross-platform-change",
   "idea-triage",
   "complex-decision-analysis",
+  "automation-investment-case-review",
+  "product-onboarding-activation-review",
+  "subscription-retention-profit-review",
+  "product-engagement-retention-review",
+  "credit-monetization-integrity-review",
+  "pricing-model-integrity-review",
+  "freemium-ad-monetization-review",
+  "referral-incentive-integrity-review",
+  "localization-market-expansion-review",
   "instruction-conflict-scope-check",
   "migration-safety-check",
   "multi-agent-work-coordination",
@@ -1332,9 +1388,15 @@ product = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "facade-pattern",
   "github-contribution-quality-gate",
   "failure-triage",
@@ -1342,6 +1404,23 @@ product = [
   "frontend-render-stability",
   "idea-triage",
   "complex-decision-analysis",
+  "automation-investment-case-review",
+  "product-onboarding-activation-review",
+  "subscription-retention-profit-review",
+  "product-engagement-retention-review",
+  "credit-monetization-integrity-review",
+  "pricing-model-integrity-review",
+  "game-economy-monetization-review",
+  "freemium-ad-monetization-review",
+  "referral-incentive-integrity-review",
+  "llm-product-monetization-review",
+  "game-liveops-commerce-integrity-review",
+  "growth-distribution-integrity-review",
+  "product-portfolio-integrity-review",
+  "localization-market-expansion-review",
+  "desktop-commercial-distribution-review",
+  "client-platform-strategy-review",
+  "service-portfolio-capital-allocation-review",
   "instruction-conflict-scope-check",
   "migration-safety-check",
   "llm-service-ux-review",
@@ -1555,9 +1634,15 @@ library = [
   "llm-hallucination-control-review",
   "llm-token-cost-control-review",
   "llm-response-latency-review",
+  "llm-model-routing-integrity-review",
   "agent-execution-control-review",
+  "agent-runtime-multi-worker-review",
+  "agent-runtime-isolation-review",
+  "agent-planning-recovery-review",
+  "agent-release-bundle-rollout-review",
   "browser-automation-reliability-review",
   "agent-eval-integrity-review",
+  "agent-memory-context-governance-review",
   "facade-pattern",
   "github-contribution-quality-gate",
   "failure-triage",