mustflow 2.108.8 → 2.112.3

package/templates/default/locales/en/.mustflow/skills/technology-stack-selection/SKILL.md

@@ -0,0 +1,328 @@
+---
+mustflow_doc: skill.technology-stack-selection
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: technology-stack-selection
+description: Apply this skill when choosing, adding, replacing, upgrading, rejecting, or standardizing a technology stack, framework, runtime, database, cache, queue, auth provider, payment provider, AI provider, SDK, hosting platform, deployment tool, build tool, ORM, observability tool, or vendor integration, especially when the decision affects migration path, rollback path, ecosystem maturity, maintainer risk, debugging surface, lock-in, CI/CD cost, deployment cost, operating toil, or solo-maintainer survivability.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.technology-stack-selection
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_related
+    - test_release
+    - mustflow_check
+---
+
+# Technology Stack Selection
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose technology by whether the project can operate, debug, deploy, upgrade, pay for, and
+replace it for the full expected life of the product.
+
+This skill prevents agents from accepting technology because it is fashionable, fast in a
+benchmark, convenient for a demo, popular in another company's architecture, or attractive to the
+developer. For indie, solo, and small-team projects, the core question is whether the stack can
+keep earning value while the maintainer is tired, busy, away from the codebase, or handling an
+incident without a dedicated platform team.
+
+Treat survival-path decisions as failure-survivability decisions, not feature-implementation
+decisions.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task chooses, compares, adopts, replaces, upgrades, rejects, or standardizes a technology,
+  framework, runtime, database, queue, cache, auth provider, payment provider, AI provider, SDK,
+  hosting platform, deployment tool, build tool, ORM, observability tool, package ecosystem, or
+  vendor integration.
+- A technology is proposed for authentication, authorization, billing, payment, durable data,
+  permissions, deployment, backup, restore, queueing, file storage, customer money, customer data,
+  security, or another survival path.
+- The decision depends on migration path, rollback path, local reproducibility, CI/CD cost,
+  deployment cost, operating toil, observability cost, backup and restore cost, maintainer capacity,
+  hiring availability, lock-in, data export, ecosystem maturity, or debugging surface.
+- A new or experimental technology may belong in a differentiating edge feature, internal tool,
+  read-only path, derived-data path, analytics surface, search layer, recommendation layer, AI
+  layer, or feature-flagged experiment.
+- A stack choice is being justified for solo, indie, small-team, funded-startup, open-source,
+  library, or enterprise contexts where the same technology can be appropriate in one context and
+  dangerous in another.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only edits code within an already selected technology and no new dependency, runtime,
+  vendor, data contract, deployment path, or operational surface is being chosen. Use the matching
+  implementation skill.
+- The task only checks whether a dependency exists, is declared, or is safe to import. Use
+  `dependency-reality-check`.
+- The task only chooses a primary language, runtime, compile target, or execution environment. Use
+  `runtime-target-selection` first, then this skill only for broader stack and operations tradeoffs.
+- A user or repository owner has already mandated the technology. In that case, use this skill only
+  to document constraints, guardrails, migration, rollback, observability, and verification.
+- The task asks for an unconstrained brainstorming list with no adoption decision. Use
+  `idea-triage` or `complex-decision-analysis` when those narrower conditions match.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Decision scope: affected product surface, repository, packages, services, data, deployment,
+  users, operators, and time horizon.
+- Candidate technologies: name, intended role, version range when relevant, adoption type, and
+  whether the candidate is a new stack, replacement, upgrade, or vendor migration.
+- Baseline and boring default: current choice, no-change option, most conventional low-risk option,
+  current pain, current costs, known failure modes, and existing team knowledge.
+- Criticality: `experiment`, `internal_tool`, `customer_facing`, `production_core`, or
+  `irreversible_core`.
+- Reversibility class: `code_only`, `config`, `build_pipeline`, `runtime_dependency`,
+  `persistent_data`, `public_api`, `customer_workflow`, `vendor_contract`, `security_boundary`, or
+  `money_or_permission`.
+- Team and maintainer capacity: solo, indie, small team, funded startup, enterprise, open-source
+  maintainer count, on-call owner, runbook owner, training cost, and hiring or support availability.
+- Evidence: repository patterns, official docs, changelogs, migration guides, security advisories,
+  issue trackers, production incidents, prototypes, CI results, command receipts, pricing pages, and
+  support or SLA evidence when available.
+- Success and failure criteria: what must improve, what must not regress, what would stop the
+  adoption, and what evidence would reverse the recommendation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the
+  current scope.
+- External AI output, blog posts, vendor marketing, popularity signals, benchmark claims, and
+  famous-company usage are evidence candidates only, not authority.
+- Current external facts such as versions, prices, license terms, platform limits, and release
+  status are refreshed through an authorized source path or marked as unverified when they affect
+  the decision.
+- The status quo and a boring default are included unless the user explicitly fixed the option set.
+- A narrower implementation skill will be selected before editing implementation files.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Create or update technology decision records, architecture notes, migration plans, rollback
+  plans, runbook notes, route metadata, skill procedures, template metadata, tests, and docs that
+  directly support the stack decision.
+- Add only the smallest reversible implementation scaffold when the user requests implementation
+  and the decision has passed this skill's gates.
+- Do not install dependencies, run package managers, start services, run benchmarks, perform
+  migrations, deploy, open vendor dashboards, or change cloud resources unless the repository
+  command contract and user request explicitly allow that action.
+- Do not let a score total, popularity, benchmark, developer experience, or novelty override a hard
+  rejection gate.
+
+<!-- mustflow-section: core-definitions -->
+## Core Definitions
+
+`survival_path` means a path where failure can block accounts, money, permissions, durable data,
+deployment, backup, recovery, customer trust, or the maintainer's ability to keep the product alive.
+Typical surfaces include auth, authorization, payment, billing, database, deployment, backup,
+restore, queues, file storage, secrets, customer money, customer data, and operational recovery.
+
+`migration_path` means a staged move from the baseline to the candidate while keeping the product or
+workflow usable. It covers code, data, configuration, deployment, tests, cutover, ownership, and the
+middle state. A big-bang rewrite is not a migration path.
+
+`rollback_path` means a rehearsable return to the previous stable state or a safe degraded state. It
+covers data compatibility, schema compatibility, feature flags, routing, backups, cutover timing,
+customer impact, and the point after which rollback becomes unsafe. Backup alone is not rollback.
+
+`ecosystem_maturity` means the candidate and its surrounding tools can survive ordinary production
+use: docs, changelogs, migration guides, security response, integrations, testing tools, debugging
+tools, production failure knowledge, release cadence, and available operators.
+
+`maintainer_risk` means the risk that the candidate becomes abandoned, unsupported, vendor-captured,
+relicensed, incompatibly changed, underfunded, or dependent on too few people.
+
+`debugging_surface` means the layers and opaque states a maintainer must inspect during failure:
+generated code, runtime magic, plugins, hidden cache, async queues, network boundaries, vendor
+dashboards, local reproducibility, logs, traces, metrics, error codes, and request correlation.
+
+<!-- mustflow-section: hard-rejection-criteria -->
+## Hard Rejection Criteria
+
+Reject a candidate for `production_core` or `irreversible_core` when any condition is true:
+
+- No staged migration path exists.
+- The only migration path is a big-bang rewrite.
+- Rollback depends on luck, manual data surgery, unbounded downtime, or customer-visible data loss.
+- The candidate writes persistent data, events, files, auth state, money records, permission
+  records, cache keys, or public API contracts that the previous system cannot read or safely ignore.
+- The candidate is beta, experimental, preview-only, unstable, deprecated, or vendor-opaque for a
+  customer-facing or core surface.
+- Maintainer risk concentrates on one person, one abandoned project, one unfunded package, or one
+  vendor-controlled API without an adapter, fork, export, or replacement plan.
+- The ecosystem lacks current docs, migration guides, security response, basic integrations, or
+  searchable operational failure knowledge for the intended use.
+- Debugging crosses opaque generated code, hidden runtime state, async infrastructure, or remote
+  vendor behavior without local reproduction, logs, traces, metrics, request IDs, and an error
+  taxonomy.
+- The team cannot operate the technology and has no owner, training plan, runbook, or support plan.
+- License, pricing, data retention, region, privacy, compliance, or security constraints conflict
+  with the project.
+- The candidate solves taste, novelty, resume value, or aesthetic discomfort rather than a real
+  product, operational, security, performance, or maintenance bottleneck.
+- A local reversible problem would become a global architecture commitment.
+
+Do not average scores until hard rejection criteria have been applied.
+
+<!-- mustflow-section: scoring-rubric -->
+## Scoring Rubric
+
+Score each non-rejected candidate from 0 to 5:
+
+- `0`: no evidence, impossible, or actively unsafe.
+- `1`: theoretical, undocumented, or dependent on heroic manual work.
+- `2`: possible with high manual cost, fragile assumptions, or large downtime.
+- `3`: usable with known limits, documented mitigation, and acceptable blast radius.
+- `4`: documented, staged, testable, rehearsable, observable, and owned.
+- `5`: boring, standard, widely proven, easy to operate, easy to replace, and compatible with the
+  project.
+
+Required dimensions:
+
+- Migration path
+- Rollback path
+- Ecosystem maturity
+- Maintainer health
+- Debuggability
+- Operating surface and toil
+- Cost predictability
+- Data ownership and export
+- Security and privacy fit
+
+For `experiment` or `internal_tool`, scores of 2 or 3 can be acceptable when the candidate is
+isolated, timeboxed, feature-flagged, and easy to remove.
+
+For `customer_facing`, require no hard rejection and at least 3 in migration, rollback, ecosystem,
+maintainer health, and debuggability.
+
+For `production_core`, require no hard rejection, at least 4 in migration, rollback, debuggability,
+operating surface, and data ownership, and at least 3 in ecosystem and maintainer health.
+
+For `irreversible_core`, require no hard rejection, at least 4 in every dimension, a named owner,
+and a rehearsed recovery path.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the decision contract: what is being chosen, what is not being chosen, baseline, boring
+   default, owner, time horizon, and affected survival paths.
+2. Classify criticality and reversibility. Raise the evidence bar for persistent data, public APIs,
+   auth, payment, permission, deployment, backup, restore, and customer workflows.
+3. Build the option set. Include the status quo and boring default. Compare no more than three
+   additional candidates unless the user asks for a broader survey.
+4. Build the evidence ledger. Separate facts, inferences, assumptions, and unknowns. Prefer current
+   primary evidence over social proof, benchmark marketing, generated advice, or repeated citations.
+5. Evaluate maintainer life. For solo or indie work, prefer the smallest operating surface: one
+   understandable app path, managed boring infrastructure, simple CI/CD, automatic backups,
+   observable failures, and cheap rollback. Treat maintainer time as a real cost.
+6. Place experimentation at the edge. New or experimental technology belongs in replaceable parts,
+   read-only paths, derived-data paths, internal tools, feature-flagged features, analytics, search,
+   recommendation, or AI differentiators that can fail without corrupting the source of truth.
+7. Assess migration path for each candidate: source, target, compatibility layer, data conversion,
+   dual-run or shadow mode, cutover, validation, owner, blast radius, and stop condition.
+8. Assess rollback path for each candidate: trigger, steps, data preservation, schema compatibility,
+   feature flag or routing control, backup and restore limits, customer impact, irreversible cutoff,
+   and rehearsal requirement.
+9. Assess ecosystem maturity and maintainer risk: docs, changelog, release cadence, security
+   response, issue and PR handling, governance, funding, license stability, support, and exit path.
+10. Assess debugging surface: local reproduction, logs, traces, metrics, request IDs, error codes,
+    generated code, runtime magic, caches, queues, network boundaries, vendor dashboards, and blind
+    spots.
+11. Assess cost and operating surface: fixed cost, variable cost, CI/CD cost, observability cost,
+    backup and restore cost, failure-spike cost, egress, retry storms, log volume, billing meters,
+    and monthly maintainer labor.
+12. Apply hard rejection criteria before scoring. Do not rescue a hard-failed candidate with
+    popularity, performance, developer experience, or future promises.
+13. Score remaining candidates with one sentence of evidence for each dimension. Avoid invented
+    weights unless the user provided a decision model.
+14. Attack the leading candidate. State the strongest reason not to choose it and the smallest
+    evidence that would reverse the recommendation.
+15. Choose exactly one decision state: `adopt`, `adopt_with_constraints`, `experiment_first`,
+    `defer`, `reject`, or `reject_until_evidence_exists`.
+16. Define the next action. For adoption, specify the smallest safe rollout, guardrails, migration,
+    rollback, observability, owner, verification, and stop condition. For experiment, specify the
+    question, timebox, success criteria, failure criteria, cleanup path, and decision-reversing
+    evidence.
+17. Hand off to implementation only after selecting the narrower implementation skill and carrying
+    forward accepted constraints, migration steps, rollback steps, observability, and verification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The recommendation is based on survivability, reversibility, debugging, operating cost, and team
+  capacity, not novelty.
+- Survival-path choices prefer boring proven technology unless the candidate proves a stronger
+  recovery and operating story.
+- Experimental technology is isolated from source-of-truth data, money, permissions, and deployment
+  unless the project explicitly accepts the risk and can roll back.
+- Hard rejection criteria are applied before any score comparison.
+- Migration, rollback, observability, owner, and stop conditions are explicit.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_related`
+- `test_release`
+- `mustflow_check`
+
+Use `docs_validate_fast` when a decision record, architecture note, skill, template, or mustflow doc
+changes. Use `test_related` or `test_release` when installed template behavior, package output, or
+tests change. Use `mustflow_check` when mustflow-owned skills, routes, indexes, templates, or command
+contracts change.
+
+Report missing benchmark, migration, deployment, restore, cloud, vendor, pricing, or observability
+verification instead of inventing raw commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the user provides only a favorite technology and no baseline, compare it with the status quo
+  and a boring default.
+- If evidence is missing for a production-core decision, return `reject_until_evidence_exists` or
+  `experiment_first`, not `adopt`.
+- If rollback is weak, constrain the candidate to experiment, edge usage, or non-core usage.
+- If a mature candidate creates a large debugging surface, require observability and local
+  reproduction before adoption.
+- If maintainer risk is concentrated, require an adapter, fork plan, vendor alternative, or deferral.
+- If cost cannot be estimated across normal, success, and failure-spike scenarios, mark cost
+  predictability as unresolved.
+- If every option fails hard constraints, return `defer`, `reject`, or
+  `reject_until_evidence_exists` and name what would need to change.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Skill selection and overlap decision
+- Decision state: `adopt`, `adopt_with_constraints`, `experiment_first`, `defer`, `reject`, or
+  `reject_until_evidence_exists`
+- Decision scope, baseline, boring default, criticality, reversibility class, owner, and time horizon
+- Candidate matrix with hard-gate result, scores, evidence, mitigations, and verdict
+- Survival-path impact and experimental-edge placement
+- Migration path
+- Rollback path
+- Debugging surface
+- Cost and operating-surface notes
+- Hard rejections and exact criteria
+- Guardrails, owner, runbook, observability, security, privacy, and data-export requirements
+- Experiment plan when the decision is `experiment_first`
+- Command intents run
+- Skipped verification and reasons
+- Remaining risk and decision-reversing evidence

package/templates/default/locales/en/.mustflow/skills/version-freshness-check/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.version-freshness-check
 locale: en
 canonical: true
-revision: 9
+revision: 10
 lifecycle: mustflow-owned
 authority: procedure
 name: version-freshness-check
-description: Apply this skill when generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, Python standard-library/API references, TypeScript compiler-track references, Go release, toolchain, standard-library, runtime, experiment, framework, or dependency references such as Gin, Rust release, toolchain, standard-library, Cargo, edition, MSRV, lint, or target references, HTTP standard or browser-support references, or migration-sensitive snippets introduce explicit external version references that may be stale.
+description: Apply this skill when generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, Python standard-library/API references, TypeScript compiler-track references, Go release, toolchain, standard-library, runtime, experiment, framework, or dependency references such as Gin, Java or JDK release, GA, LTS, support, JEP, JVM flag, GC, virtual-thread, preview, incubator, or build-tool references, Rust release, toolchain, standard-library, Cargo, edition, MSRV, lint, or target references, HTTP standard or browser-support references, or migration-sensitive snippets introduce explicit external version references that may be stale.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -37,6 +37,7 @@ Prevent agents from writing stale external version references from memory, while
 - Python wording mentions current/stable/support status, Python 3.14+ or 3.15+ syntax, standard-library APIs, runtime flags, changed default behavior, security defaults, or examples that depend on `requires-python`.
 - TypeScript wording mentions current/stable/RC/nightly status for TypeScript 6, TypeScript 7, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
 - Go wording mentions current/stable/support status, Go release numbers, `go.mod` language version behavior, `toolchain` behavior, standard-library APIs, `GOEXPERIMENT`, runtime defaults, container behavior, JSON experiments, third-party Go framework releases such as Gin, framework minimum-Go requirements, or examples that depend on a specific Go or framework version.
+- Java wording mentions current/stable/GA/LTS/support status, Java or JDK release numbers, Oracle/OpenJDK/vendor support tracks, JEP status, preview or incubator APIs, JVM flags, GC behavior, virtual-thread behavior, `ScopedValue`, structured concurrency, final-field reflection restrictions, applet removal, HTTP/3, AOT cache, Compact Object Headers, JFR, JMH, container memory or CPU behavior, Maven or Gradle toolchains, bytecode target, or examples that depend on a specific Java version.
 - Rust wording mentions current/stable/support status, Rust release numbers, `rust-version`, edition behavior, `rust-toolchain`, Cargo resolver or workspace behavior, standard-library APIs, compiler lints, target behavior, release profiles, or examples that depend on a specific Rust version.
 - HTTP delivery wording mentions current support, baseline status, default behavior, standard status, or compatibility for zstd content coding, compression dictionary transport, SSE/EventSource, WebTransport, WebSocket fallback, HTTP/2, HTTP/3, QUIC, CDN behavior, proxy buffering, or browser transport APIs.
 - An agent proposes a versioned dependency, tool, framework, action, image, or runtime based on memory, copied snippets, older project examples, or user-provided text that may be stale.
@@ -93,7 +94,7 @@ Prevent agents from writing stale external version references from memory, while
 9. For existing projects, do not cross a major, migration-required, engine, framework, CI-image, or generated-output boundary without user approval or explicit repository policy.
 10. For patch, security-minimum, and low-risk minor differences, update only when the declaration, examples, lockfile policy, and verification surface can stay aligned. Otherwise report the proposed change and leave the pinned value unchanged.
 11. For GitHub Actions and CI tools, review the action source, major tag policy, runtime support, cache behavior, permissions, and organization pinning rule. Do not assume a newer major is safe only because it exists.
-12. For framework and runtime majors such as Astro, Tauri, Electron, Next, SvelteKit, Node, Bun, Deno, Python, Rust, or Java, check migration notes, config schema, plugin and adapter compatibility, generated files, security model, deployment target, and rollback path before recommending a major change.
+12. For framework and runtime majors such as Astro, Tauri, Electron, Next, SvelteKit, Node, Bun, Deno, Python, Go, Java, Rust, or JavaScript runtimes, check migration notes, config schema, plugin and adapter compatibility, generated files, security model, deployment target, and rollback path before recommending a major change.
 13. For Python standard-library or runtime-behavior claims, refresh official Python documentation before writing durable wording. Check `requires-python`, CI/runtime matrices, and container images before using or recommending Python 3.14+ standard-library APIs or version-gated features such as template string literals, `annotationlib`, Python 3.14+ `map(strict=True)`, `functools.Placeholder`, `heapq` max-heap helpers, import-timing flag behavior, `finally` flow-control warnings, or changed security defaults.
 14. For Python examples that use newer standard-library APIs, either keep the example behind an explicit runtime floor or provide a supported fallback. Do not call a Python 3.14-only API a general Python best practice when the repository declares lower support.
 15. For Python 3.15+ claims, keep beta, release-candidate, and stable tracks separate. Refresh official docs before using explicit lazy imports, built-in `frozendict`, built-in `sentinel`, unpacking comprehensions, typed `TypedDict` extra items, startup configuration files, or changed encoding behavior in durable examples.
@@ -102,13 +103,16 @@ Prevent agents from writing stale external version references from memory, while
 18. For Go release, toolchain, standard-library, runtime, or experiment claims, refresh official Go release notes or package documentation before writing durable wording. Check the repository's `go` directive, `toolchain` directive, CI/runtime matrix, and container target before using or recommending version-gated features such as expression operands to `new`, range-over-function iterators, generic type aliases, reflect iterator methods, `errors.AsType`, `sync.WaitGroup.Go`, `testing/synctest`, `testing.B.Loop`, `T.ArtifactDir`, `B.ArtifactDir`, `F.ArtifactDir`, `testing/cryptotest.SetGlobalRandom`, `os.Root`, `os.OpenInRoot`, `omitzero`, `go.mod` `tool`, `ReverseProxy.Rewrite`, container-aware `GOMAXPROCS`, goroutine leak profiles, `encoding/json/v2`, or `GOEXPERIMENT` APIs.
 19. For Go framework and dependency release claims, refresh the source that owns the artifact before writing durable wording. For Gin, prefer official Gin release notes, pkg.go.dev module metadata, and the upstream repository release or source files for claims about latest stable version, minimum Go version, HTTP/3 support, BSON support, binding behavior, router options, logger options, trusted proxy behavior, or `Context` APIs. Keep framework upgrade advice separate from repository adoption, because a framework minor can still require a Go toolchain, CI image, Docker base, middleware, route, or binding migration.
 20. For Go examples that use newer standard-library APIs, framework APIs, or runtime defaults, either keep the example behind an explicit Go or framework version floor or provide a supported fallback. Do not call an experimental `GOEXPERIMENT` feature, a newer `go` directive behavior, or a newly added framework method a general Go best practice when the repository declares lower support.
-21. For Rust release, toolchain, standard-library, Cargo, edition, lint, target, or MSRV claims, refresh official Rust release notes, standard-library docs, the Cargo Book, Rust Reference, or rustc book before writing durable wording. Check `rust-version`, edition, `rust-toolchain.toml`, CI toolchain matrix, target triples, docs.rs metadata, and crate publish policy before using or recommending version-gated features such as let chains, match `if let` guards, `cfg_select!`, `assert_matches!`, `core::range`, `Vec::push_mut`, `HashMap::get_disjoint_mut`, `Option::take_if`, `LazyLock`, `OnceLock`, `workspace.lints`, `resolver = "2"`, Rust 2024 `unsafe extern`, unsafe attributes, Rust 2024 `unsafe_op_in_unsafe_fn`, temporary drop-scope changes, macro fragment behavior, or release-profile defaults.
-22. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Use an API-by-API MSRV ledger for features such as `cfg_select!`, match `if let` guards, `core::range` items, `Vec::push_mut`, `assert_matches!`, and `debug_assert_matches!`; do not collapse them into a single "latest Rust" bucket, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
-23. For HTTP standards, browser APIs, proxy defaults, CDN defaults, and transport support claims, prefer official RFCs, standards bodies, MDN or browser vendor docs, and vendor-owned proxy/CDN documentation. Keep WebTransport, compression dictionary transport, zstd content coding, SSE/EventSource, HTTP/2, HTTP/3, QUIC, and proxy-buffering claims track-specific and dated when support is changing.
-24. For HTTP delivery examples that depend on newer or unevenly supported behavior, require feature detection, fallback behavior, or explicit deployment constraints. Do not present WebTransport, dictionary compression, or zstd negotiation as a universal default when the project still needs browsers, proxies, CDNs, or networks that may not support it.
-25. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
-26. Synchronize every accepted version decision across package metadata, lockfiles when intentionally updated, CI, Docker, runtime files, docs, examples, templates, tests, and release notes.
-27. Run the narrowest configured verification that covers the changed versioned surface. Use broader verification for major, migration-required, runtime, framework, generated-output, package-publish, Docker, CI, TypeScript compiler-track, Go toolchain or runtime support, Go framework runtime support, Rust toolchain or MSRV support, HTTP delivery compatibility, or security-sensitive changes.
+21. For Java or JDK release, support, JEP, standard-library, JVM flag, GC, virtual-thread, preview, incubator, or build-tool claims, refresh official Java, OpenJDK, vendor, Maven, or Gradle sources before writing durable wording. Check the repository's source and target release, Maven or Gradle toolchain, wrapper, CI runtime matrix, container image, JDK vendor policy, and bytecode compatibility before using or recommending version-gated features such as module import declarations, compact source files, instance main methods, flexible constructor bodies, `ScopedValue`, structured concurrency, primitive pattern matching, final-field reflection restrictions, applet API removal, `java.net.http.HttpClient` HTTP/3, AOT cache or method profiling, Compact Object Headers, Generational Shenandoah, JFR method timing, KDF APIs, PEM APIs, Lazy Constants, or Vector API.
+22. For Java examples that use newer language, standard-library, JVM, or build-tool behavior, either keep the example behind an explicit Java and toolchain version floor or provide a supported fallback. Do not collapse latest GA, latest LTS, repository runtime, vendor support, delivered JEP, preview JEP, incubator API, product feature, and default-enabled behavior into one "latest Java" bucket. Treat JVM AOT cache as startup or warmup optimization, not Native Image, and treat Java HTTP/3 as client-side opt-in unless current official docs say otherwise.
+23. For Java performance and JVM tuning claims, refresh official JVM, GC, JFR, JMH, and vendor documentation before writing durable wording. Keep G1 pause targets as goals rather than SLAs, ZGC and Shenandoah as CPU and headroom tradeoffs rather than free latency switches, Compact Object Headers and Generational Shenandoah as enablement-specific when applicable, and container memory claims separate across heap, direct buffers, metaspace, code cache, thread stacks, native memory, `MaxRAMPercentage`, `MaxDirectMemorySize`, and `ActiveProcessorCount`.
+24. For Rust release, toolchain, standard-library, Cargo, edition, lint, target, or MSRV claims, refresh official Rust release notes, standard-library docs, the Cargo Book, Rust Reference, or rustc book before writing durable wording. Check `rust-version`, edition, `rust-toolchain.toml`, CI toolchain matrix, target triples, docs.rs metadata, and crate publish policy before using or recommending version-gated features such as let chains, match `if let` guards, `cfg_select!`, `assert_matches!`, `core::range`, `Vec::push_mut`, `HashMap::get_disjoint_mut`, `Option::take_if`, `LazyLock`, `OnceLock`, `workspace.lints`, `resolver = "2"`, Rust 2024 `unsafe extern`, unsafe attributes, Rust 2024 `unsafe_op_in_unsafe_fn`, temporary drop-scope changes, macro fragment behavior, or release-profile defaults.
+25. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Use an API-by-API MSRV ledger for features such as `cfg_select!`, match `if let` guards, `core::range` items, `Vec::push_mut`, `assert_matches!`, and `debug_assert_matches!`; do not collapse them into a single "latest Rust" bucket, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
+26. For HTTP standards, browser APIs, proxy defaults, CDN defaults, and transport support claims, prefer official RFCs, standards bodies, MDN or browser vendor docs, and vendor-owned proxy/CDN documentation. Keep WebTransport, compression dictionary transport, zstd content coding, SSE/EventSource, HTTP/2, HTTP/3, QUIC, and proxy-buffering claims track-specific and dated when support is changing.
+27. For HTTP delivery examples that depend on newer or unevenly supported behavior, require feature detection, fallback behavior, or explicit deployment constraints. Do not present WebTransport, dictionary compression, or zstd negotiation as a universal default when the project still needs browsers, proxies, CDNs, or networks that may not support it.
+28. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
+29. Synchronize every accepted version decision across package metadata, lockfiles when intentionally updated, CI, Docker, runtime files, docs, examples, templates, tests, and release notes.
+30. Run the narrowest configured verification that covers the changed versioned surface. Use broader verification for major, migration-required, runtime, framework, generated-output, package-publish, Docker, CI, TypeScript compiler-track, Go toolchain or runtime support, Go framework runtime support, Java JDK/toolchain/bytecode/runtime support, JVM tuning, Rust toolchain or MSRV support, HTTP delivery compatibility, or security-sensitive changes.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -121,6 +125,7 @@ Prevent agents from writing stale external version references from memory, while
 - Python template strings, annotation inspection, explicit lazy imports, immutable mappings, sentinels, and advanced `TypedDict` shape claims are either official-source checked or omitted.
 - TypeScript 6 stable API, TypeScript 7 RC compiler, TypeScript 7 nightly, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
 - Go release, `go.mod` language version, standard-library API, framework dependency API such as Gin, runtime-default, and `GOEXPERIMENT` claims match the declared Go support matrix or name the required runtime or framework floor.
+- Java release, JDK vendor, source or target release, bytecode target, JEP status, standard-library API, virtual-thread behavior, preview or incubator API, build-tool support, JVM flag, GC behavior, and container-runtime claims match the declared Java support matrix or name the required runtime, toolchain, and feature floor.
 - Rust release, `rust-version`, edition, standard-library API, Cargo resolver, lint-default, target, and nightly/stable claims match the declared Rust support matrix or name the required API-specific runtime floor.
 - HTTP standard, browser-support, proxy-default, CDN-default, and transport-support claims are not written from stale memory and keep feature detection or fallback boundaries explicit where support varies.
 - Docs and examples do not make unverifiable current-version claims.
@@ -149,6 +154,7 @@ Choose the narrowest configured intent that proves the changed versioned surface
 - If a proposed major or migration-required version is better for greenfield work but risky for the existing project, present both choices and ask before changing the project.
 - If TypeScript 7 RC, nightly, or stable freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from comparison-only checks.
 - If Go release, framework release, or experiment freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, `go` directive adoption, framework adoption, CI support, and `GOEXPERIMENT` adoption separate.
+- If Java release, JEP, JVM flag, GC, or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep latest GA, latest LTS, repository runtime, vendor support, preview or incubator status, product feature status, default-enabled behavior, build-tool support, and CI or container adoption separate.
 - If Rust release or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, MSRV adoption, edition adoption, CI support, target support, and nightly or unstable features separate.
 - If HTTP delivery support changes during the task, update wording to a dated or track-specific claim and keep standards, browser support, CDN behavior, proxy defaults, and repository adoption separate.
 - If verification fails after a freshness update, do not weaken tests, lower type checks, delete lockfiles, or widen ranges to make the update pass. Revert or narrow the version decision unless the behavior change is intentional.

package/templates/default/locales/en/.mustflow/skills/writing-elegance/SKILL.md

@@ -0,0 +1,193 @@
+---
+mustflow_doc: skill.writing-elegance
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: writing-elegance
+description: Apply this skill when a user provides Korean or English prose and asks to extract reusable elegant wording candidates, collect selected phrase fragments into a phrase bank, or polish writing with previously selected modular expressions. Also apply it as a style-polish adjunct for report-style answers, final reports, GitHub issue bodies, pull request descriptions, review replies, maintainer-facing comments, release or update notes, documentation prose, summaries, and explanatory writing when facts are already established and the goal is clearer, more graceful wording.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.writing-elegance
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Writing Elegance
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Build and use a small phrase bank of reusable wording patterns that make prose, documentation,
+answers, summaries, issue or pull-request text, reports, and narrative explanations more graceful
+without locking the agent into over-specific sentences.
+
+This skill is not a generic rewrite machine. It collects modular fragments that can survive across
+contexts, languages, subjects, and genres.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The user provides Korean or English prose and asks for elegant words, expressions, phrasing, or
+  sentence patterns that could be reused later.
+- The user asks for seven numbered candidate expressions from a supplied text and intends to choose
+  which candidates should be stored.
+- The user selects candidate numbers to keep, reject, or revise for future skill guidance.
+- The task is to polish a document, answer, report, comment, or explanation using a curated phrase
+  bank rather than inventing style from scratch.
+- The task is to improve the wording of a final report, implementation summary, GitHub issue body,
+  pull request description, review reply, maintainer-facing comment, release note, update note, or
+  Markdown report after the factual evidence and owning workflow skill have already set the content.
+- The work needs Korean source fragments translated into English guidance for a reusable skill.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a documentation review queue entry or AI-slop cleanup for a mustflow document. Use
+  `docs-prose-review` first.
+- The task changes technical facts, commands, API contracts, code snippets, schema text, legal text,
+  safety instructions, or release/change history where correctness, evidence, or repository policy
+  still needs the owning skill before any style polish.
+- The user asks for one-off translation, summarization, grammar correction, or copy editing with no
+  reusable phrase-bank goal.
+- The candidate expression depends on a proper noun, character name, unique setting, private event,
+  or one-time plot situation that would not transfer to other writing.
+- The phrase only sounds ornate but does not improve precision, tone control, rhythm, or emotional
+  framing.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Source text in Korean or English.
+- The intended mode: candidate extraction, selected-candidate storage, phrase-bank application, or
+  phrase-bank cleanup.
+- The target register when known: literary, technical, explanatory, product, support, review,
+  maintainer-facing, casual, formal, or emotionally restrained.
+- The target surface when relevant: chat answer, final report, Markdown report, GitHub issue, pull
+  request description, review reply, release note, update note, documentation page, or comment.
+- Any user feedback about what to keep, reject, generalize, split, shorten, or rewrite.
+- The current phrase bank when storing or applying selected expressions.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Candidate extraction can preserve the original meaning without copying long source passages.
+- Phrase-bank entries can be generalized without retaining private names, narrow plot facts, or
+  one-off circumstances.
+- If repository files will be edited, higher-priority instructions and command contracts have been
+  checked first.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- For ordinary chat rounds, make no file edits. Return only a numbered candidate table.
+- When the user asks to preserve selected candidates, update the phrase bank and only directly
+  synchronized skill/template metadata needed for that stored expression.
+- Keep `SKILL.md` procedural and short. Store accumulated expressions in `references/phrase-bank.md`
+  or a split reference file when the bank grows.
+- Do not store raw source excerpts beyond the short fragment needed to identify the pattern.
+- Do not store private names, unique character names, narrow plot facts, or whole paragraphs in the
+  phrase bank.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the round:
+   - `candidate_extraction`: the user supplied prose and needs seven numbered candidates;
+   - `selection_storage`: the user selected candidate numbers to keep or discard;
+   - `application`: the user wants existing phrase-bank patterns applied to a text;
+   - `cleanup`: the phrase bank needs deduplication, splitting, or reorganization.
+2. For candidate extraction, read the supplied text and choose exactly seven candidates unless the
+   user asks for a different count.
+3. Prefer reusable fragments over finished sentences:
+   - keep fragments that can attach to many nouns, scenes, arguments, or explanations;
+   - split before a proper noun, unique event, one-time setting, or over-specific object;
+   - keep the smallest phrase that carries the style value.
+4. For Korean source text, include the Korean source fragment and translate the reusable guidance
+   into English.
+5. For English source text, preserve the short source fragment, include a concise Korean
+   translation column in candidate tables, and derive a generalized English pattern.
+6. Reject candidates that are:
+   - tied to a named person, place, product, fictional setting, or unique incident;
+   - too complete to recombine;
+   - too vague to guide future writing;
+   - decorative without improving meaning;
+   - likely to overwrite the writer's actual register.
+7. Return a numbered table with these columns:
+   - `No.`
+   - `Source Fragment`
+   - `Korean Translation` when the source text is English
+   - `Reusable English Pattern`
+   - `Reusable Range`
+   - `Skill Note`
+8. When the user selects entries, store only those entries. Preserve rejected numbers as absent, not
+   as negative examples, unless the user explicitly asks to record a rejection rule.
+9. Store entries as compact rows with:
+   - source language;
+   - source fragment;
+   - reusable English pattern;
+   - use guidance;
+   - avoid guidance when a common misuse is known.
+10. When applying the phrase bank, use entries as taste constraints, not mandatory substitutions.
+    Preserve technical facts, evidence, legal meaning, safety warnings, user intent, and the original
+    level of certainty.
+11. When polishing GitHub, release, verification, or final-report content, apply the owning skill
+    first for evidence, repository rules, version facts, and verification scope. Use this skill only
+    to make the already-correct wording clearer, smoother, or more elegant.
+12. When the phrase bank grows too large, split it by usage type such as emotional framing,
+    restrained technical polish, transitions, softening, emphasis, scene atmosphere, or answer tone.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Candidate tables contain reusable fragments rather than narrow finished sentences.
+- Stored entries are in English guidance even when the source text was Korean.
+- Proper nouns, private details, unique plot facts, and one-off situations are excluded or
+  generalized.
+- The phrase bank remains compact enough to load only when needed.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when repository files are changed:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Do not infer raw validation commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the source text is too long, extract candidates from the most style-dense sections and report
+  that the pass was selective.
+- If all appealing phrases are too situation-specific, return fewer strong candidates or ask for a
+  different sample instead of padding the table.
+- If the user rejects a candidate for being too narrow, split it into a smaller reusable fragment
+  and avoid storing the rejected broad form.
+- If a phrase-bank entry starts to duplicate another entry, merge the guidance instead of adding a
+  near-copy.
+- If applying a phrase would make a technical or factual answer less clear, preserve clarity and
+  report that the phrase was skipped.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Mode: candidate extraction, selection storage, application, or cleanup
+- Candidate table or stored entries
+- Entries kept and rejected when relevant
+- Phrase-bank file changed when relevant
+- Command intents run when repository files changed
+- Skipped checks and reasons
+- Remaining style, specificity, or privacy risk