mustflow 2.116.4 → 2.117.0

package/templates/default/locales/en/.mustflow/skills/llm-product-monetization-review/SKILL.md

@@ -0,0 +1,311 @@
+---
+mustflow_doc: skill.llm-product-monetization-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: llm-product-monetization-review
+description: Apply this skill when an LLM product changes token-based versus task- or outcome-based pricing, bounded document/image/analysis units, standard versus precision service tiers, free versus paid queue priority, first-value queue exemptions, automatic credit restoration or retry rights for failed work, user-facing model disclosure or model pinning, cheap-default and premium-model packaging, internal model escalation, managed provider cost, BYOK or customer-supplied API keys, platform fees, included credits, margin, conversion, or retained contribution and must keep user-visible value understandable while internal provider cost, capacity, failure, transparency, and credential risk remain controlled.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.llm-product-monetization-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# LLM Product Monetization Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Sell an understandable unit of user value while metering tokens, tools, models, retries, storage,
+capacity, and provider cost internally. Package quality, queue priority, failure recovery, model
+transparency, and credential funding without manufacturing delay, charging for unusable work,
+exposing unstable vendor implementation as the product contract, surprising users after automatic
+escalation, or turning BYOK into insecure onboarding friction and a margin escape hatch.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A consumer, SMB, developer, or enterprise LLM product chooses token, character, page, document,
+  image, minute, run, analysis, report, accepted result, credit, seat, or hybrid billing units.
+- A task unit changes its page, byte, duration, source, OCR, search, tool, output, retry, quality,
+  latency, concurrency, or variable-cost boundary.
+- A product offers standard, fast, precise, premium, verified, or named-model tiers, or automatically
+  escalates from a cheaper model to a stronger model.
+- Free and paid users receive different queue priority, concurrency, start-time objectives, capacity
+  shares, first-value treatment, background completion, or paid fast-lane promises.
+- Provider errors, timeouts, empty or malformed output, quality-gate failures, subjective
+  dissatisfaction, automatic retries, credit restoration, bound retry rights, or abuse controls
+  change.
+- A product chooses outcome-mode labels, provider or model-family disclosure, exact model and
+  version receipts, fallback disclosure, model pinning, or internal provider replacement policy.
+- A product chooses managed provider credentials, BYOK, customer cloud accounts, a platform fee,
+  included usage, prepaid credits, or enterprise provider routing.
+- Conversion, cost per accepted result, gross margin, failed-work charging, heavy-tail cost, retained
+  use, or provider migration economics are created, changed, reviewed, or reported.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is prompt payload, token counting, caching, RAG packing, retry replay, output budget,
+  or internal cost telemetry; use `llm-token-cost-control-review`.
+- The main risk is whether a router, cascade, escalation, fallback, or context handoff preserves
+  accepted outcomes; use `llm-model-routing-integrity-review`.
+- The task only changes a model picker, progress, result, citation, or error interface without price
+  or credential economics; use `llm-service-ux-review`.
+- The task only changes scheduler fairness, queue durability, starvation, admission control, or
+  latency instrumentation without a free-versus-paid product policy; use
+  `queue-processing-integrity-review` and `llm-response-latency-review`.
+- The task only changes generic plan price, annual billing, trial, regional pricing, or non-LLM usage
+  pricing; use `pricing-model-integrity-review`.
+- The main risk is credit reserve, balance, capture, release, reversal, expiry, or spend order; use
+  `credit-monetization-integrity-review` and `credit-ledger-integrity-review`.
+- The main risk is secret storage, tenant isolation, key brokerage, credential access, exfiltration,
+  provider terms, residency, or incident response. Use the security, privacy, secret, and provider
+  owners; this skill supplies the product and economics contract.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Audience ledger: consumer, prosumer, developer, SMB, enterprise, procurement, technical ability,
+  expected cadence, willingness evidence, failure cost, and budget predictability.
+- Task-unit ledger: user job, accepted result, input and output bounds, pages, bytes, duration, media,
+  OCR, search, tools, sources, iterations, revisions, latency, concurrency, price, credits, and overage.
+- Internal-cost ledger: provider, model, input, cached, output, and reasoning tokens; tool calls;
+  images, audio, video, storage, search, OCR, egress, retry, verification, moderation, support,
+  payment, fraud, refund, and failed-work cost.
+- Quality-tier ledger: public tier, accepted-outcome contract, latency, evidence, verification,
+  included operations, route version, automatic escalation, fallback, user-selected upgrade, and
+  price authorization.
+- Credential ledger: managed or customer-funded account, provider, key owner, scope, storage,
+  encryption, access, rotation, deletion, logging, quota, residency, audit, failure, and support.
+- Economics ledger: eligible-user conversion, useful completion, paid use, cumulative revenue,
+  provider cost, tail cost, contribution, refund, chargeback, support, abuse, churn, and retention.
+- Experiment ledger: pre-price assignment, package parity, audience and task strata, exposure,
+  horizon, provider and model versions, guardrails, and promotion rule.
+- Queue-service ledger: first owned value, free and paid eligibility, real capacity state, weight or
+  reservation policy, concurrency, aging, starvation bound, enqueue and start time, estimated range,
+  background delivery, abandonment, cancellation, capacity cost, and service objective.
+- Failure-recovery ledger: attempt and quote identity, failure classifier, provider and product
+  evidence, deterministic quality gate, retry lineage, reservation, capture, release, reversal,
+  restored asset, bound retry right, expiry, abuse evidence, appeal, and support state.
+- Transparency ledger: public mode, accepted-outcome contract, provider, model family and version,
+  route and fallback version, execution receipt, customer pin, reproducibility need, procurement or
+  jurisdiction requirement, AI-origin marking, change notice, and retention policy.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate the customer-visible billing unit, internal resource meter, service-quality tier, and
+  credential-funding model. One does not prove the others.
+- Define an accepted user result and failure policy before pricing a task or capturing credit.
+- Define first owned value before imposing a materially slower free queue, and classify objective
+  system failure separately from subjective dissatisfaction before granting a reusable asset.
+- Assign experiments before price, model tier, or BYOK setup becomes visible and keep abandoners in
+  the intent-to-treat denominator.
+- Refresh current provider models, prices, meters, tool charges, tokenizers, key rules, retention,
+  regional availability, and platform terms before embedding exact claims.
+- Treat copied page limits, credit ratios, percentiles, margin targets, model names, price multiples,
+  and another product's BYOK policy as hypotheses, not defaults.
+- This skill does not authorize live price, provider, credential, credit, routing, experiment,
+  payment, or production changes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine task units, scope limits, quotes, quality tiers, model-independent service contracts,
+  real-capacity queue classes, first-value exemptions, failure classifiers, automatic restoration,
+  bound retry rights, execution receipts, model disclosure and pinning, BYOK and managed-cost policy,
+  platform fees, contribution metrics, experiment events, fixtures, tests, docs, route metadata, and
+  synchronized templates.
+- Add explicit handoffs to token-cost, model-routing, credit-ledger, payment, security, privacy,
+  provider, accounting, tax, or legal owners.
+- Remove unbounded per-document pricing, post-hoc token bills, surprise escalation charges,
+  client-side key storage, hidden provider cost, fake unlimited use, or free BYOK that receives the
+  full product platform without covering its cost.
+- Do not change the promised price after internal retry or escalation unless the user explicitly
+  authorized a separately defined higher service tier before execution.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split seven decisions: external billing unit, internal resource meter, public service tier,
+   managed versus customer-funded credentials, queue priority, failure recovery, and model
+   transparency. Do not present one bundle as the only possible design.
+2. Classify the buyer. End-user products need predictable job and result language; developer APIs can
+   expose resource meters where technical buyers control payload and value that transparency;
+   enterprise products may need both task budgets and provider-account control.
+3. Prefer a user-recognizable unit when the product owns an end-to-end job. Name the accepted result
+   and scope rather than selling an ambiguous document, image, analysis, or agent run with no bounds.
+4. Bound every task unit. Define input pages or bytes, media duration and resolution, OCR, search,
+   tools, sources, revisions, output length, latency, concurrency, timeout, and overflow behavior.
+   Split materially different jobs instead of hiding extreme cost in one average.
+5. Quote before execution. Show task tier, fixed or bounded credit spend, included work, maximum
+   scope, and failure treatment. Route reservation, useful-result capture, release, and reversal
+   through the credit skills.
+6. Treat paid priority as a capacity contract, not synthetic friction. When capacity is available,
+   start eligible free and paid work promptly; never add sleep solely to manufacture an upgrade.
+7. Protect first owned value. Let a new eligible user receive enough successful representative work
+   to judge the product before a materially slower free lane where cost, safety, and abuse permit.
+   Derive the allowance from result variance and marginal cost rather than copying a universal count.
+8. Design queue priority from observed load and abandonment. Define work class, weight or reserved
+   capacity, concurrency, aging, cancellation, starvation bound, and overload behavior. Preserve a
+   bounded free path rather than strict paid-first starvation.
+9. Show honest wait state. Measure enqueue-to-start separately from generation time, show a range or
+   queue state backed by current evidence, preserve work after the user leaves where appropriate, and
+   notify or place completed work in an owned result surface. Do not show fake exact countdowns.
+10. Derive queue objectives from task duration, user attention, first-value state, capacity cost,
+    abandonment curves, and paid value. Treat copied seconds, minutes, weights, or capacity shares as
+    experiment candidates, not service laws.
+11. Meter the complete internal cost. Include tokens, cache behavior, reasoning, tools, media,
+   retrieval, storage, retries, verification, moderation, support, payment, abuse, and refunds. A
+   token-only ledger can understate the cost of the task the customer bought.
+12. Price tail risk deliberately. Use the observed cost distribution and a declared service objective
+   rather than average cost alone; a percentile such as p95 can be a candidate, not a universal law.
+   Add scope splits, overage, or a higher tier when bounded honest pricing cannot cover the tail.
+13. Derive the floor from retained contribution, not a copied markup. Include full variable cost,
+   refunds, support, acquisition, provider volatility, and useful-result probability. Validate that
+   the customer values the bounded result above that floor.
+14. Classify failures before settlement. Treat provider errors, timeouts, empty output, corrupt media,
+    truncated required output, deterministic schema failure, duplicate execution, and declared
+    quality-gate failure as objective candidates when current evidence can reproduce the rule.
+15. For objective operator-owned failure, retry only when the same logical attempt can do so safely;
+    otherwise release or reverse the authorized charge automatically and idempotently. Do not make
+    users file a claim for a failure the system already proved.
+16. Keep subjective dissatisfaction separate. A same-lineage, nontransferable retry right can be a
+    candidate when intent fit is uncertain, but do not convert every dislike into general-purpose
+    credit. Bound reuse, model escalation, expiry, review, and appeal from observed abuse and cost.
+17. Evaluate restoration by incremental variable cost and retained contribution, not credit face
+    value alone. Include extra execution, support avoided, repurchase, refunds, disputes, abuse, and
+    user trust; never use a universal refund or complaint quota as the product contract.
+18. Route reserve, capture, release, reversal, retry identity, and reconciliation through the credit
+    skills. A browser timeout or client cancellation alone does not prove provider failure or permit
+    duplicate restoration.
+19. Keep public tiers model-independent by default. Describe speed, result quality, verification,
+   source coverage, revision policy, and latency. Do not promise a vendor model name unless that
+   identity is itself a required and maintainable contract.
+20. Make the standard tier good enough to represent the product. A deliberately poor cheap result is
+    an activation failure, not an upgrade funnel. Escalate internally when needed to meet the promised
+    standard accepted outcome.
+21. Do not surprise-charge automatic escalation. Router, verifier, retry, and stronger-model cost
+    used to satisfy the selected tier belongs to the operator. Charge more only for a user-selected,
+    prepriced tier with materially different scope or outcome.
+22. Route quality through `llm-model-routing-integrity-review`. Compare total cost per accepted
+    outcome, false accepts, retries, repairs, context handoff, OOD fallback, and fixed evaluation
+    cost; cheap per-call price alone is not product margin.
+23. Separate AI transparency from vendor merchandising. Tell users they are using AI and expose
+    material limitations, provenance, or generated-content marking required by the product and
+    current authority; that does not require turning an unstable model brand into the plan name.
+24. Keep an auditable execution receipt. Record provider, model family and version, route, fallback,
+    tools, and execution time internally, and expose the subset needed for user verification,
+    procurement, reproducibility, support, or jurisdiction rules without leaking secrets.
+25. Offer exact model pinning only when identity or reproducibility is a paid or regulated contract.
+    A pinned execution must not silently substitute another model; fail, ask, or use an explicitly
+    accepted fallback. Outcome-mode routes may change providers only while preserving their accepted
+    result and disclosure contract.
+26. Refresh transparency and marking duties by product role, geography, content type, publication
+    path, and date. Do not infer that a visible watermark alone satisfies machine-readable marking,
+    disclosure, accessibility, provenance, or legal obligations.
+27. Use an expensive-only baseline when the declared failure cost, safety floor, or narrow task value
+    justifies it. Do not generalize a high-stakes exception to ordinary extraction, transformation,
+    drafting, or classification.
+28. Compare managed and BYOK from the full activation path. Include external account creation,
+    billing setup, key creation, trust, storage, quota, provider support, first-value delay, conversion,
+    cost control, and retained platform revenue.
+29. Keep managed credentials as a strong candidate when immediate end-user activation and integrated
+    usage revenue matter. Bound abuse with task limits, concurrency, budgets, idempotency, cost alerts,
+    and explicit included usage rather than a secretly throttled unlimited promise.
+30. Offer BYOK where technical or enterprise buyers need provider ownership, negotiated pricing,
+    region, model, quota, or procurement control. Charge a platform fee for workflow, storage,
+    collaboration, retrieval, audit, support, and automation value that remains operator-owned.
+31. Treat customer keys as secrets, never ordinary preferences. Require server-side or approved
+    secure handling, least privilege, encryption, access audit, redaction, rotation, deletion,
+    tenant isolation, and bounded provider errors; route the implementation to security owners.
+32. Prevent credential-mode arbitrage and lock-in. Define which features, support, quotas, providers,
+    credits, and usage records differ between managed and BYOK modes, and let qualified customers
+    migrate without losing owned product data.
+33. Preserve external price meaning across provider and model changes. Version the task, quality,
+    cost, route, and credential contracts so internal optimization can improve margin without
+    silently reducing the result the user purchased.
+34. Evaluate from eligible assignment over meaningful repeat-use and billing horizons. Track first
+    value, queue wait and abandonment, useful completion, conversion, task mix, tail cost, gross
+    margin, contribution, provider failures, automatic reversals, retry-right use, abuse, support,
+    BYOK setup loss, churn, and retained use.
+35. Promote only a reversible policy that improves eligible-user contribution while preserving
+    understandable scope, nonmanufactured queueing, useful-result charging, fair failure recovery,
+    acceptable quality, credential security, current transparency duties, provider compliance, and
+    explicit latency, model-routing, credit, and security handoffs.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- External task or resource units and internal provider-cost meters are separate and reconstructable.
+- Each task unit has an accepted result, scope, quote, overflow, failure, and tail-cost policy.
+- Standard and premium tiers describe product outcomes rather than relying on unstable model names.
+- Automatic retry or model escalation cannot create an unapproved price increase.
+- Free and paid queue classes consume real capacity, preserve first value and a bounded free path,
+  expose honest wait state, and do not manufacture delay.
+- Objective operator-owned failure can release or reverse charges idempotently, while subjective
+  dissatisfaction uses a separately bounded recovery asset when offered.
+- AI-origin, outcome mode, execution receipt, exact model pinning, fallback, and provider replacement
+  have explicit transparency and reproducibility boundaries.
+- Managed and BYOK modes have explicit activation, credential, quota, platform-fee, support, revenue,
+  migration, and security boundaries.
+- Headline economics use eligible users and total cost per accepted result over retained use.
+
+<!-- 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 provider, model, key, billing, credit, analytics, experiment, deployment, or
+production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If task scope or accepted result is undefined, do not publish a fixed task price.
+- If complete internal cost is unavailable, label margin as unverified and add bounded limits before
+  expanding managed usage.
+- If a cheaper route lacks accepted-outcome evidence, keep the capable baseline and route the gap to
+  the model-routing skill.
+- If a paid queue converts only by intentionally slowing idle free capacity, reject it as synthetic
+  friction. If the free lane can starve, add bounded capacity or aging before promotion.
+- If failure cannot be classified or the attempt cannot be reconciled, keep the reservation pending
+  under a bounded recovery policy; do not both retry and restore reusable value blindly.
+- If current product-role, content, or jurisdiction transparency duties are unresolved, preserve an
+  auditable execution receipt and route the launch decision to qualified authority.
+- If customer keys cannot be isolated, redacted, rotated, and deleted securely, do not offer hosted
+  BYOK; preserve managed mode or require an approved enterprise integration boundary.
+- If a pricing arm wins conversion but loses accepted results, retained contribution, support, or
+  security guardrails, reject or narrow it.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Audience, accepted result, task unit, limits, quote, overflow, and settlement policy
+- Internal token, tool, media, retry, verification, support, and tail-cost ledger
+- Standard and premium outcome contracts, automatic route, escalation, and price authorization
+- Queue eligibility, first-value treatment, capacity, fairness, wait evidence, abandonment, and paid
+  priority decision
+- Objective failure, subjective dissatisfaction, retry lineage, restoration asset, abuse, appeal,
+  reserve, capture, release, and reversal decision
+- AI-origin disclosure, execution receipt, model family and version, pinning, fallback, provider
+  replacement, reproducibility, and authority decision
+- Managed and BYOK activation, credential, quota, platform-fee, migration, and security decision
+- Eligible conversion, accepted results, margin, contribution, retention, and provider evidence
+- Files changed
+- Command intents run and skipped checks
+- Remaining LLM product monetization risk

package/templates/default/locales/en/.mustflow/skills/llm-token-cost-control-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.llm-token-cost-control-review
 locale: en
 canonical: true
-revision: 5
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: llm-token-cost-control-review
@@ -47,6 +47,12 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - The main risk is unsupported factual output, fabricated citations, source coverage, answerability, abstain behavior, retrieval thresholds, or hallucination metrics; use `llm-hallucination-control-review`.
 - The main risk is time to first token, first useful output, streaming, LLM round trips, tool wait, prompt-cache latency, model routing speed, priority tier, realtime continuation, or user-perceived response speed; use `llm-response-latency-review`.
 - The main risk is autonomous agent execution control, tool-call approval, side-effect replay safety, durable resume behavior, handoffs, guardrails, loop budgets, retry classification, or trace outcome evaluation; use `agent-execution-control-review`.
+- The main risk is whether a model router, cascade, escalation, fallback, or stage switch preserves
+  accepted outcomes under quality, safety, latency, context-handoff, and distribution-shift risk;
+  use `llm-model-routing-integrity-review`. Keep this skill for token and request-cost mechanics.
+- The main risk is customer-visible token versus task pricing, bounded outcome units, standard versus
+  premium packaging, managed provider cost, BYOK, platform fees, or failed-work charging; use
+  `llm-product-monetization-review`. Keep this skill for internal resource and cost mechanics.
 - The main risk is cloud account, infrastructure, SaaS, quota, budget, tag, retention, or provider-account spend guardrails outside the model-call payload; use `cloud-cost-guardrail-review`.
 - The main risk is rate-limit fairness, throttling, quota counters, concurrency limits, 429 response behavior, or protected-resource definition; use `rate-limit-integrity-review`.
 - The task only edits user-visible copy and does not affect LLM payload, model choice, retry behavior, or cost telemetry.
@@ -69,6 +75,9 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
   prompt-packing rule, and current input-token measurement.
 - Output ledger: output schema size, repeated key length, patch versus full-output policy, `max_output_tokens`, reasoning budget, retry repair inputs, validator errors, and incomplete-response handling.
 - Routing ledger: deterministic prefilters, small-model router, expensive-model escalation rule, batch or flex eligibility, predicted-output eligibility, image or file preprocessing, and fallback behavior.
+- For route-quality decisions, include the accepted-outcome evaluator, false-accept behavior,
+  distribution support, context-switch loss, and fixed router or verifier cost through
+  `llm-model-routing-integrity-review` instead of treating token price as sufficient evidence.
 - Observability ledger: input tokens, cached tokens when exposed by the provider, output tokens, reasoning tokens when exposed or billable, retry count, validation failure count, cache hit rate, cost per successful task, model, endpoint, prompt version, tool version, schema version, and budget breach events.
 - Boundary ledger: token estimates and caps owned here; accepted-work reservation persistence owned by `command-pattern`; prepaid or money-equivalent reserve, capture, and release owned by `credit-ledger-integrity-review`; allow, block, downgrade, and obligation provenance owned by `policy-decision-integrity-review`.
 
@@ -134,6 +143,9 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 17. Pack by references before raw text. Prefer stable document ids, chunk ids, section anchors, source maps, block refs, and token counts when choosing context. Expand only the needed source spans instead of replaying a whole corpus or full document list.
 18. Keep tool and schema payloads boring. Tool descriptions and JSON schemas should be long enough for correct routing and validation but not narrative prose. If permissions differ by user, keep schema stable and enforce permission at tool execution.
 19. Route before calling the expensive model. Use deterministic code, regexes, database lookups, small models, or cheap classifiers for tasks that do not need a large reasoning model; escalate only ambiguous, high-value, or failed cases.
+    Judge candidate models by total cost per accepted outcome, including verifier, escalation,
+    retry, repair, and handoff cost. Route calibration, OOD fallback, false-accept risk, and hard
+    safety constraints through `llm-model-routing-integrity-review`.
 20. Budget reasoning and output together. Set reasoning effort and output limits according to task value; leave enough room for visible output, and handle incomplete responses instead of silently retrying the full expensive request.
 21. Prefer patches over full regeneration when the product already owns most of the output. Use unified diff, JSON Patch, line-range replacement, IDs, labels, scores, or reason codes when downstream code can merge the result.
 22. Repair failures without full replay. For parse failures, enum mismatches, missing fields, or validator errors, retry with previous output, validator error, and schema summary when safe instead of resending the entire original context.
@@ -155,6 +167,8 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - Compression quality is evaluated against answer, citation, numeric, constraint, and refusal behavior rather than judged by shorter text alone.
 - Deterministic work is handled outside the model unless language judgment is required.
 - Metrics can explain cost per successful task, cache-prefix drift, retry cost, validation failures, and model routing decisions without leaking sensitive prompt or user data.
+- Cheaper-model claims are separated from route-integrity evidence and do not rely on per-call price
+  alone.
 - Final reports distinguish proven cost-control evidence from assumed provider behavior, anecdotal token savings, and latency-only optimizations.
 
 <!-- mustflow-section: verification -->

package/templates/default/locales/en/.mustflow/skills/localization-market-expansion-review/SKILL.md

@@ -0,0 +1,224 @@
+---
+mustflow_doc: skill.localization-market-expansion-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: localization-market-expansion-review
+description: Apply this skill when a product changes single-language versus simultaneous multilingual launch, first-market language selection, staged locale rollout, AI or machine translation followed by human review, exploration versus revenue versus fully supported locales, localized SEO demand, language-specific checkout and trust copy, translation maintenance cost, locale promotion gates, per-locale conversion refunds support or contribution, or claims that multilingual traffic creates profitable market expansion.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.localization-market-expansion-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Localization Market Expansion Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose which languages to operate, how deeply to support them, and when to promote them from demand
+and retained contribution. Keep the product internationalization-ready without opening more
+translation, support, legal, billing, SEO, and release obligations than the team can maintain.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A product compares launching in one language with launching in many languages simultaneously.
+- A team chooses the first market language, locale rollout order, language count, or promotion gate.
+- AI or machine translation is used for landing pages, SEO pages, product UI, onboarding, checkout,
+  help, email, support, policy, or store listings with selective human review.
+- Languages are classified as exploratory, marketing-only, revenue-ready, fully supported,
+  deprecated, frozen, or removed.
+- International SEO, localized queries, language URLs, `hreflang`, translated metadata, search
+  traffic, signup, payment, refund, support, retention, or per-locale contribution changes.
+- A report claims translation volume, localized traffic, country reach, or supported-language count
+  creates revenue or efficient global expansion.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is implementation correctness for message catalogs, pluralization, formatting, RTL,
+  locale routing, SSR hydration, `hreflang`, exports, or translation keys without a market rollout
+  decision; use `frontend-localization-review`.
+- The task only edits copy in one known language or translates user-provided prose with no product
+  support, SEO, checkout, or market-expansion decision.
+- The task only changes regional prices, currencies, tax presentation, or purchasing-power policy;
+  use `pricing-model-integrity-review`.
+- The task requests jurisdiction-specific legal, privacy, tax, medical, financial, consumer, or
+  advertising translation approval. Use qualified native-language reviewers and current authority.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Market ledger: target job, buyer, purchase owner, current customer language, country and script,
+  local alternatives, search demand, paid demand, willingness evidence, product fit, support demand,
+  regulatory or trust risk, and acquisition channel.
+- Locale-state ledger: locale, script, region, stage, supported surfaces, excluded surfaces, launch
+  date, owner, glossary, review level, fallback, deprecation, and user-facing disclosure.
+- Surface ledger: landing, SEO, product UI, signup, onboarding, pricing, checkout, receipt, refund,
+  security, privacy, legal, error, email, notification, help, support, store listing, screenshots,
+  exports, and in-product content.
+- Translation ledger: source version, locale version, model or vendor, prompt or glossary, machine
+  output, reviewer, review sample, risk class, placeholder parity, stale state, and correction path.
+- SEO ledger: local query language, intent and terminology research, stable locale URL, translated
+  main content, canonical, reciprocal alternate mapping, `x-default`, sitemap or HTML method,
+  crawl and index state, and scaled-content risk.
+- Economics ledger: incremental nonbrand traffic, qualified visit, download or signup, checkout,
+  payment, refund, chargeback, support time, translation and review cost, engineering maintenance,
+  content update cost, retained revenue, and contribution by eligible locale cohort.
+- Experiment ledger: locale eligibility, assignment or rollout, source-language baseline, country
+  and language distinction, exposure, product-language disclosure, horizon, guardrails, and
+  promotion or retirement rule.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate internationalization readiness from languages actively marketed, sold, supported, and
+  serviced. Code readiness does not create an operating-language commitment.
+- Choose the first language from the fastest credible paying-customer path, not from an assumption
+  that English or the founder's language is universally correct.
+- Define support depth and human-review requirements before publishing or accepting payment in a
+  locale.
+- Treat copied language counts, rollout batches, review percentages, contribution multiples,
+  traffic lifts, and maintenance budgets as hypotheses, not defaults.
+- Refresh current search-engine, store, payment, tax, privacy, accessibility, and jurisdiction
+  requirements before launching localized public or transactional surfaces.
+- This skill does not authorize bulk translation, index submission, pricing, live campaigns,
+  checkout activation, messages, store publication, or production rollout.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine locale stages, market qualification, surface support matrices, translation risk and
+  review policy, SEO demand tests, source and locale versioning, promotion and retirement gates,
+  economics, events, fixtures, tests, docs, route metadata, and synchronized templates.
+- Add explicit handoffs to frontend localization, SEO, product copy, payment, pricing, support,
+  privacy, security, accessibility, legal, or native-language review owners.
+- Replace language-count goals, traffic-only success, unreviewed transactional copy, silent English
+  fallback, or mass translated SEO pages with staged and observable support commitments.
+- Do not label a locale fully supported when core UI, support, checkout, policies, or failure
+  recovery remain undisclosed in another language.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split three decisions: internationalization readiness, marketed or indexed locale, and operational
+   support depth. Do not launch every technically possible locale.
+2. Choose the first market language from buyer concentration, product fit, payment ability, search or
+   direct demand, support feasibility, trust, and speed to paid learning. English is a candidate, not
+   a universal first language.
+3. Make architecture ready for future locales early where proportionate. Externalize strings and
+   account for plural, format, time, currency, expansion, script, font, RTL, route, metadata, and
+   export boundaries without translating every surface immediately.
+4. Define explicit locale stages. A useful model can distinguish candidate, exploratory,
+   revenue-ready, fully supported, frozen, and retired locales, but names and counts are product
+   policy rather than universal law.
+5. For an exploratory locale, state what is translated and what remains in the source language.
+   Use it to measure real demand only when the page gives local users useful, accurate content and a
+   truthful path to the actual product.
+6. Before accepting payment, require native-capable review for price, CTA, checkout, renewal,
+   cancellation, refund, security, privacy, legal claims, onboarding, critical errors, and other
+   trust-bearing text according to product risk. Machine output alone is not proof of correct rights.
+7. Promote to full support only when product UI, high-frequency help, support ownership, incident
+   communication, billing recovery, policy updates, and release maintenance have declared owners.
+8. Classify translation by consequence, not only language. High-trust and rights-bearing surfaces
+   need stricter review in every public locale; lower-risk long-tail help or marketing drafts may use
+   sampled review when current evidence and policy permit it.
+9. Treat AI translation as a versioned draft producer. Preserve source version, model or vendor,
+   glossary, placeholder rules, reviewer evidence, correction feedback, stale detection, and
+   rollback or unpublish behavior.
+10. Do not translate keywords literally and call it localization. Research local category names,
+    jobs, search intent, alternatives, trust signals, and purchase language before choosing titles,
+    metadata, examples, and calls to action.
+11. Create stable crawler-visible locale URLs only when the localized main content and user path are
+    real. Keep canonical and alternate relationships accurate and route implementation through
+    `frontend-localization-review`.
+12. Maintain reciprocal locale relationships and one coherent alternate-marking method where the
+    current search owner requires it. A tag existing in source does not prove crawl, index, or
+    conversion success.
+13. Do not mass-publish translated or generated pages whose main purpose is ranking coverage.
+    Evaluate unique local usefulness, accuracy, relevance, product availability, and maintenance;
+    generation method alone neither guarantees safety nor proves spam.
+14. Disclose product-language gaps. Localized acquisition pages must show when the app, support,
+    checkout, documentation, or store binary remains available only in another language.
+15. Measure the full language funnel. Start with eligible nonbrand demand, then useful visit,
+    product start, first owned value, checkout, payment, retained use, refund, support, and
+    contribution. Traffic and indexed-page counts are diagnostic, not the headline result.
+16. Include recurring maintenance cost. Price source-copy changes, catalog and screenshot updates,
+    UI regressions, reviewer availability, customer support, policy changes, store assets, incident
+    messages, and stale translation cleanup across the planned horizon.
+17. Promote a locale only when expected retained contribution and learning value justify initial and
+    recurring obligations under declared uncertainty. Do not embed a universal payback multiple or
+    day horizon.
+18. Retire or freeze honestly. Preserve customer rights, access, receipts, support and incident
+    communication, and state what will stop changing; do not silently fall back after selling a
+    supported-language promise.
+19. Sequence locale launches so causes remain identifiable. When several locales launch together,
+    report aggregate evidence and do not claim which language, channel, or review depth caused the
+    result.
+20. Promote only a reversible rollout that improves per-eligible-locale contribution while
+    preserving accurate high-trust text, product-language disclosure, search value, support,
+    accessibility, current authority, and maintainable translation workflow.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Internationalization readiness, public locale, revenue readiness, and full support are separate
+  observable states.
+- The first language and later locale order follow customer and economics evidence rather than a
+  fixed English-first or many-language rule.
+- AI translation has source, glossary, risk, review, correction, and stale-state controls.
+- Localized SEO represents useful maintained content and an honest product path.
+- High-trust surfaces receive the required native-capable review before payment or rights change.
+- Headline expansion uses retained contribution rather than language count, page count, traffic, or
+  translation volume.
+
+<!-- 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 translation, TMS, browser, crawler, index, payment, support,
+campaign, store, analytics, deployment, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If local demand and purchase intent are unknown, keep the locale exploratory and do not claim
+  revenue readiness from translated traffic.
+- If high-trust review is unavailable, do not accept payment or publish rights-bearing claims in that
+  locale; keep the surface clearly limited or unpublished.
+- If the localized page promises a product experience that remains undisclosed in another language,
+  correct the promise before acquiring more traffic.
+- If crawl or traffic evidence exists without checkout, refund, support, and retention evidence,
+  report acquisition reach rather than profitable market expansion.
+- If translation maintenance ownership is missing, limit the supported surface instead of opening
+  another full locale.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- First-market language, buyer, job, demand, fit, support, trust, and current authority
+- Locale stage, supported and excluded surfaces, product-language disclosure, owner, fallback, and
+  retirement
+- Translation source, AI or vendor, glossary, consequence class, human review, stale handling, and
+  correction
+- Local query intent, URL, canonical and alternate mapping, crawl, index, usefulness, and
+  scaled-content risk
+- Eligible demand, activation, payment, refund, support, maintenance cost, retained contribution,
+  rollout decision, files changed, commands run and skipped checks
+- Remaining localization-market-expansion risk
+

package/templates/default/locales/en/.mustflow/skills/multi-agent-work-coordination/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.multi-agent-work-coordination
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: multi-agent-work-coordination
@@ -54,7 +54,12 @@ Do not use this skill when:
 
 - one agent is doing a small linear task
 - the user only asks for a normal code change, review, or test run
-- the requested work is a production automation runtime rather than repository coordination
+- the requested work decides whether several agents in a production runtime beat one, or designs
+  orchestrator-worker topology, role diversity, correlated-error controls, artifact ownership, and
+  central verification; use `agent-runtime-multi-worker-review`
+- the requested work separates durable agent state from queued short-lived workers, ephemeral
+  sandboxes, temporary credentials, or a trusted effect broker; use
+  `agent-runtime-isolation-review`
 - the requested work designs an LLM product agent's planner, executor, verifier, tool gates, approval or interrupt state, durable resume behavior, loop budgets, handoffs, guardrails, or trace outcome evaluation; use `agent-execution-control-review`
 - the repository or host instructions forbid starting workers or long-running processes