mustflow 2.25.1 → 2.26.0

package/README.md

@@ -404,6 +404,8 @@ mf run maintainer_check_node
 mf run docs_validate_fast
 mf run docs_validate
 mf run mustflow_check
+mf run release_npm_version_available
+mf run release_npm_published_verify
 ```
 
 The Bun scripts remain available for human maintainers and release packaging. `test_fast` runs the fast CLI regression baseline, `test_related` selects tests from changed files and falls back to the fast baseline, and both use 8 Node test workers by default. Set `MUSTFLOW_TEST_CONCURRENCY=1`, `2`, or another positive integer to tune those workers on local machines. `test_release` keeps package metadata and packaging checks out of routine local edits. `test_coverage` runs the fast CLI baseline through Node's built-in coverage report with no enforced threshold; set `MUSTFLOW_TEST_COVERAGE_CONCURRENCY=1`, `2`, or another positive integer to adjust its worker count. `lint` and test-audit are configured as narrow repository-local gates. `docs_validate_fast` checks documentation navigation and localized content links without building the entire static site; `docs_validate` performs the full static documentation build, search index, and sitemap gate for release-sensitive changes.
@@ -416,7 +418,7 @@ Run the full release check before publishing:
 bun run release:check
 ```
 
-`release:check` validates the CLI, builds the documentation site, packs the npm tarball, installs it into a temporary project, and runs the public `mf` workflow. Maintainer npm publishing uses the `Publish npm package` GitHub Actions workflow from a published GitHub Release. The release tag must match the `package.json` version, with an optional leading `v`. npm Trusted Publishing must be configured for the workflow before maintainers publish through it.
+`release:check` validates the CLI, builds the documentation site, packs the npm tarball, installs it into a temporary project, and runs the public `mf` workflow. Maintainer npm publishing uses the `Publish npm package` GitHub Actions workflow from a published GitHub Release. The release tag must match the `package.json` version, with an optional leading `v`. Run `mf run release_npm_version_available` before creating the tag and `mf run release_npm_published_verify` after the publish workflow completes. npm Trusted Publishing must be configured for the workflow before maintainers publish through it.
 
 ## Documentation site
 

package/dist/cli/i18n/hi.js

@@ -577,7 +577,7 @@ export const hiMessages = {
     "doctor.diagnostic.localIndex": "स्थानीय इंडेक्स",
     "doctor.diagnostic.latestRun": "नवीनतम रन",
     "docs.help.summary": "LLM creation या modification के बाद prose review की जरूरत वाले documents track करें.",
-    "docs.help.option.all": "Approved और ignored documents भी शामिल करें",
+    "docs.help.option.all": "स्वीकृत और अनदेखे documents भी शामिल करें",
     "docs.help.option.status": "Review status से filter करें",
     "docs.help.option.reason": "Document को review क्यों चाहिए यह record करें",
     "docs.help.option.origin": "Review need का source record करें, जैसे llm_modified",
@@ -595,12 +595,12 @@ export const hiMessages = {
     "docs.review.wrote": "लिखा",
     "docs.review.added": "जोड़ा",
     "docs.review.commented": "टिप्पणी जोड़ी गई",
-    "docs.review.marked.approved": "Approved",
+    "docs.review.marked.approved": "स्वीकृत",
     "docs.review.marked.needs_human": "needs_human mark किया",
-    "docs.review.marked.ignored": "Ignored",
+    "docs.review.marked.ignored": "अनदेखा किया गया",
     "docs.error.missingTopic": "docs topic missing है",
     "docs.error.unknownTopic": "Unknown docs topic: {topic}",
-    "docs.error.unknownAction": "Unknown docs review action: {action}",
+    "docs.error.unknownAction": "अज्ञात docs review action: {action}",
     "docs.error.missingPath": "Document path missing है",
     "docs.error.missingComment": "Review comment missing है",
     "docs.error.emptyComment": "Review comment खाली नहीं हो सकता",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustflow",
-  "version": "2.25.1",
+  "version": "2.26.0",
   "description": "Agent workflow documents and CLI for mustflow repository roots.",
   "type": "module",
   "license": "MIT-0",

package/templates/default/common/.mustflow/config/commands.toml

@@ -19,6 +19,10 @@ kill_after_seconds = 5
 env_policy = "minimal"
 env_allowlist = []
 
+[resources.local_index_cache]
+description = "Generated mustflow SQLite local index under .mustflow/cache/."
+concurrency = "exclusive_writer"
+
 [intents.test]
 status = "unknown"
 description = "Run the test suite."
@@ -200,6 +204,23 @@ network = false
 destructive = false
 required_after = ["clean_mustflow_update_plan", "template_update_apply"]
 
+[intents.local_index]
+status = "configured"
+kind = "mustflow_builtin"
+lifecycle = "oneshot"
+run_policy = "agent_allowed"
+description = "Create or refresh the generated mustflow SQLite local index."
+argv = ["mf", "index"]
+cwd = "."
+timeout_seconds = 300
+stdin = "closed"
+success_exit_codes = [0]
+writes = [".mustflow/cache/**"]
+effects = [{ type = "write", mode = "replace", path = ".mustflow/cache/**", lock = "local_index_cache", concurrency = "exclusive" }]
+network = false
+destructive = false
+required_after = ["structure_change", "directory_change"]
+
 [intents.repo_map]
 status = "configured"
 kind = "mustflow_builtin"

package/templates/default/i18n.toml

@@ -56,7 +56,7 @@ translations = {}
 [documents."skills.index"]
 source = "locales/en/.mustflow/skills/INDEX.md"
 source_locale = "en"
-revision = 85
+revision = 88
 translations = {}
 
 [documents."skill.adapter-boundary"]
@@ -191,6 +191,18 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.bun-code-change"]
+source = "locales/en/.mustflow/skills/bun-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
+[documents."skill.cpp-code-change"]
+source = "locales/en/.mustflow/skills/cpp-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.dart-code-change"]
 source = "locales/en/.mustflow/skills/dart-code-change/SKILL.md"
 source_locale = "en"
@@ -233,6 +245,12 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.node-code-change"]
+source = "locales/en/.mustflow/skills/node-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.python-code-change"]
 source = "locales/en/.mustflow/skills/python-code-change/SKILL.md"
 source_locale = "en"
@@ -347,6 +365,12 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.github-contribution-quality-gate"]
+source = "locales/en/.mustflow/skills/github-contribution-quality-gate/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.facade-pattern"]
 source = "locales/en/.mustflow/skills/facade-pattern/SKILL.md"
 source_locale = "en"

package/templates/default/locales/en/.mustflow/skills/INDEX.md

@@ -2,7 +2,7 @@
 mustflow_doc: skills.index
 locale: en
 canonical: true
-revision: 85
+revision: 88
 authority: router
 lifecycle: mustflow-owned
 ---
@@ -100,6 +100,9 @@ routes. Event routes stay inactive until their event occurs.
 | An unfamiliar codebase area needs an evidence-based map before planning, implementation, or reporting | `.mustflow/skills/codebase-orientation/SKILL.md` | User request, target area, relevant instructions, and current source, test, schema, template, configuration, or documentation files | Read-only orientation notes and any smallest follow-up edit chosen from inspected evidence | stale documentation, wrong ownership boundary, or invented architecture claim | `changes_status`, `changes_diff_summary`, `mustflow_check` | Scope inspected, entrypoints, flow map, ownership boundaries, verification options, risks, unknowns, and smallest safe next step |
 | A coding task has missing intent, scope, domain, data, security, UX, dependency, architecture, or verification decisions that cannot be safely inferred from repository evidence | `.mustflow/skills/clarifying-question-gate/SKILL.md` | User request, inspected repository evidence, unresolved decisions, reversibility classification, recommended option, and tradeoffs | Blocking questions, safe assumptions, and the smallest safe implementation boundary | over-questioning, lazy questions, expensive wrong assumptions, user-owned decision drift, data loss, auth bypass, public-contract drift, dependency bloat, or unverifiable completion | `changes_status`, `changes_diff_summary`, `mustflow_check` | Repository evidence inspected, blocking questions with recommendations, safe assumptions, selected scope, verification, and remaining ambiguity |
 | HTTP, REST, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, request/response schema, status code, header, error envelope, pagination, filtering, sorting, search, generated client, SDK, mock, fixture, or API docs contract is created or changed | `.mustflow/skills/api-contract-change/SKILL.md` | API style, contract source of truth, changed operations, request and response schemas, status and headers, error envelope, auth and permission behavior, pagination/filter/sort/search semantics, generated clients, SDKs, mocks, fixtures, callers, docs, and command contract entries | Routes, handlers, resolvers, validators, schemas, generated clients, SDKs, mocks, fixtures, docs, tests, and directly synchronized examples | route-only change, schema drift, generated-client breakage, hidden breaking change, status or error drift, pagination/search semantic drift, auth/permission drift, or stale docs examples | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | API contract source, changed operations, compatibility classification, synchronized client/schema/docs/tests surfaces, verification, and remaining API contract risk |
+| C++ source, headers, modules, native build metadata, toolchains, package managers, public headers, shared or static libraries, ABI surfaces, generated bindings, FFI, tests, or benchmarks are created or changed | `.mustflow/skills/cpp-code-change/SKILL.md` | Owning target, compilation identity, build front door, changed consumed surface, public API/ABI/FFI/binding surfaces, ownership and lifetime contracts, and command contract entries | C++ source, headers, modules, build metadata, package metadata, generated bindings, FFI code, tests, benchmarks, and directly synchronized docs | target drift, source API break, binary ABI break, undefined behavior, lifetime bug, build-graph drift, generated-binding drift, FFI memory bug, unverified modern C++ feature, or false performance claim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Owning target, compilation identity, highest compatibility risk, ownership/lifetime/UB/concurrency notes, public API/ABI/FFI/binding impact, verification, and remaining C++ risk |
+| Node.js runtime code, package manager ownership, module format, package entry metadata, native dependencies, Node test runner behavior, TypeScript execution mode, or deployment runtime support is created or changed | `.mustflow/skills/node-code-change/SKILL.md` | Node version signals, package manager and lockfile owner, module/package metadata, TypeScript loader, test runner, native dependency, deployment target, and command contract entries | Node runtime code, package metadata, lockfiles, scripts, CI or Docker runtime declarations, test runner config, native dependency handling, docs examples, and directly synchronized package surfaces | newest-Node assumption, package manager drift, ESM/CJS break, blocked deep import, native dependency break, Node native TypeScript overclaim, test runner migration risk, deployment mismatch, or permission-model overclaim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Runtime and package manager decision, module/package entry notes, TypeScript/test runner notes, native/deployment risks, verification, and remaining Node.js risk |
+| Bun runtime code, Bun package manager behavior, `bun.lock`, `bunfig.toml`, Bun test runner behavior, Bun bundling, Bun TypeScript execution, or Bun-specific APIs are created or changed | `.mustflow/skills/bun-code-change/SKILL.md` | Bun role signals, `package.json`, Bun and non-Bun lockfiles, `bunfig.toml`, CI/Docker Bun setup, TypeScript config, Bun APIs, native dependency signals, and command contract entries | Bun runtime code, Bun package manager metadata, lockfiles, `bunfig.toml`, scripts, tests, bundler config, TypeScript/declaration pipeline, package metadata, and directly synchronized docs | Bun role confusion, lockfile drift, trusted dependency overgrant, runtime/package-manager conflation, Bun TypeScript typecheck overclaim, Bun build declaration gap, Node compatibility break, shebang mismatch, or native binary break | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Bun role classification, lockfile/trust notes, runtime/type/build/test notes, Node compatibility risks, verification, and remaining Bun risk |
 | TypeScript source, declarations, tsconfig, package exports, module resolution, public API, or TypeScript tests are created or changed | `.mustflow/skills/typescript-code-change/SKILL.md` | TypeScript config, package entry metadata, target runtime, changed files, and command contract entries | TypeScript source, declarations, compiler config, exports, tests, and directly synchronized docs | weakened type safety, module drift, public API drift, or unverified declaration output | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, module, type, and public API boundary checked, changes made, verification, and remaining TypeScript risk |
 | JavaScript source, module format, package entry, browser or Node runtime, dependency usage, Promise handling, bundler config, or JavaScript tests are created or changed | `.mustflow/skills/javascript-code-change/SKILL.md` | Package metadata, module system, runtime target, entrypoints, changed files, and command contract entries | JavaScript source, package exports, bundler config, dependencies, tests, and docs examples | runtime API leakage, ESM/CJS drift, discarded Promise, dependency bloat, or broken package entry | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime and module boundary checked, async and dependency notes, verification, and remaining JavaScript risk |
 | Python source, package metadata, runtime version, import layout, type checking, linting, CLI entry points, or tests are created or changed | `.mustflow/skills/python-code-change/SKILL.md` | Python version source, packaging files, import layout, lint/type/test config, changed files, and command contract entries | Python source, packaging metadata, imports, type hints, tests, and docs examples | unsupported syntax, import hacks, packaging drift, swallowed errors, or weakened lint/type checks | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, packaging, import, and type boundary checked, verification, and remaining Python risk |
@@ -207,6 +210,7 @@ routes. Event routes stay inactive until their event occurs.
 | Dates, versions, counts, durations, limits, metrics, benchmarks, prices, percentages, or other numeric facts are created, edited, or reported | `.mustflow/skills/date-number-audit/SKILL.md` | Date or numeric fact, source of truth, dependent surfaces, precision expectation, and command contract entries | Numeric statements, metadata, tests, docs, templates, and reports | invented, stale, or mismatched numeric claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Audited values, source of truth, synchronized surfaces, skipped checks, and remaining numeric risk |
 | Git reports CRLF/LF warnings, Docker or shell scripts fail with CRLF interpreter errors, `.gitattributes` policy is proposed, or tracked text files may need line-ending normalization | `.mustflow/skills/line-ending-hygiene/SKILL.md` | Warning or runtime error text, changed-file evidence, line-ending policy, requested scope, changed-file status, and command contract entries | Line-ending policy files when explicitly requested, tracked text files when explicitly normalized, command metadata, tests, and reports | silent working-tree rewrite, hidden repository-wide policy change, unrelated renormalization, or policy drift | `line_endings_check`, `changes_status`, `mustflow_check` | Policy found or deferred, drift files, normalization status, verification, and remaining line-ending risk |
 | External `SKILL.md` files, skill packs, awesome lists, GitHub skill repositories, installer recommendations, or third-party skill procedures are reviewed for possible mustflow adoption | `.mustflow/skills/external-skill-intake/SKILL.md` | Source path or URL, license or provenance evidence, external skill files, intended adoption outcome, existing skill overlap, and command contract entries | Skill procedures, skill routes, template metadata, tests, docs, and review notes that adapt the external idea | third-party command bypass, license or provenance gap, unsafe helper script, duplicated skill, stale source claim, or default-profile bloat | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Source review, overlap decision, safety findings, command-intent mapping, adoption decision, synchronized surfaces, verification, and remaining intake risk |
+| GitHub issue, pull request, review thread, or maintainer-facing comment content is drafted, opened, revised, or answered | `.mustflow/skills/github-contribution-quality-gate/SKILL.md` | Target repository, intended GitHub action, repository rules and templates, duplicate search, evidence, verification level, and desired result | Issue, pull request, review reply, or comment draft plus posting gate report | maintainer time waste, duplicate report, unsupported claim, public security leak, unverified AI content, or wrong support channel | `changes_status`, `changes_diff_summary`, `mustflow_check` | Gate decision, repository rules found, duplicate and context check, evidence, missing evidence, draft, and final self-check |
 | Repository, host, user, nested-project, command-contract, preference, or generated instruction sources conflict or make safe scope unclear | `.mustflow/skills/instruction-conflict-scope-check/SKILL.md` | Conflicting instruction sources, affected scope, direct user request, command contract entries, and nearest instruction files | Workflow docs, skills, templates, tests, reports, and selected repository scope | authority drift, unsafe scope expansion, wrong repository edit, or unauthorized command | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Conflicts reviewed, chosen priority rule, narrowed or skipped actions, clarification changes, and remaining authority risk |
 | `.mustflow/context/PROJECT.md` needs cautious project context | `.mustflow/skills/project-context-authoring/SKILL.md` | Supported project facts | `.mustflow/context/PROJECT.md` | authority drift | `mustflow_check` | Updated cautious context |
 | Skill procedures or routes are created or maintained | `.mustflow/skills/skill-authoring/SKILL.md` | Repeated task evidence | `.mustflow/skills/**` | overlap and command drift | `mustflow_check`, `docs_validate` | Skill route and procedure changes |

package/templates/default/locales/en/.mustflow/skills/bun-code-change/SKILL.md

@@ -0,0 +1,143 @@
+---
+mustflow_doc: skill.bun-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: bun-code-change
+description: Apply this skill when Bun runtime code, Bun package manager behavior, bun.lock, bunfig.toml, Bun test runner behavior, Bun bundling, Bun TypeScript execution, or Bun-specific APIs are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.bun-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Bun Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Bun's separate roles as runtime, package manager, script runner, test runner, bundler, transpiler, and Node-compatible environment without mistaking one successful role for another.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `bun.lock`, `bun.lockb`, `bunfig.toml`, `packageManager: "bun@..."`, Bun install settings, `trustedDependencies`, Bun workspace behavior, or Bun lockfile migration changes.
+- Bun runtime code or config changes, including `Bun.*`, `Bun.serve`, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.$`, `bun:sqlite`, `#!/usr/bin/env bun`, Bun preload, Bun `.env` behavior, or `bun run --bun`.
+- Bun test runner behavior changes, including `bun test`, `bun:test`, `[test]` in `bunfig.toml`, snapshots, mocks, preload, isolation, coverage, sharding, or parallelism.
+- Bun bundling, compile, transpiler, build target, JSX settings, path aliases, TypeScript runtime execution, or library packaging with Bun changes.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Bun appears only as the local command used by mustflow's configured command intents, and the changed project surface is not Bun-specific.
+- The task changes generic TypeScript type modeling or declaration surfaces without Bun runtime, bundler, package manager, or test runner behavior; use `typescript-code-change`.
+- The task changes generic JavaScript without Bun ownership; use `javascript-code-change`.
+- Elysia route, schema, plugin, OpenAPI, or Eden behavior is the main surface; use `elysia-code-change` first and this skill only for Bun runtime or tooling risks.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `package.json` fields: `packageManager`, `scripts`, `workspaces`, `trustedDependencies`, `overrides`, `resolutions`, `patchedDependencies`, `dependencies`, `devDependencies`, `optionalDependencies`, and package entry metadata.
+- Bun ownership files: `bun.lock`, `bun.lockb`, `bunfig.toml`, npm, pnpm, or Yarn lockfiles that coexist with Bun, CI install commands, Docker install and runtime commands, and `oven-sh/setup-bun` usage.
+- Bun config sections: `[install]`, `[test]`, top-level preload, env, define, loader, JSX, and run settings.
+- Runtime and compatibility surfaces: `Bun.*`, `bun:test`, `node:*`, `.node`, `node-gyp`, lifecycle scripts, Prisma, sharp, Playwright, esbuild, native binary packages, streams, workers, child processes, crypto, filesystem watch, and shebangs.
+- TypeScript and package surfaces: `tsconfig*.json`, `@types/bun`, `types: ["bun"]`, module resolution, path aliases, JSX runtime, declaration output, build targets, package exports, and command contract entries.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Classify Bun's role before editing. Bun may be only the package manager, only the script runner, only the test runner, only the bundler, the runtime, or several of these at once.
+- Do not treat Bun package installation as proof that Bun runtime behavior works.
+- Do not treat Bun runtime execution, Bun transpilation, Bun tests, or Bun bundling as TypeScript typechecking or declaration generation.
+- Treat lockfile, trusted dependency, build target, and package entry changes as release-sensitive unless proven internal.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep Bun-specific APIs in Bun-owned runtime files, adapters, tests, or package entrypoints.
+- Keep Bun package manager changes aligned with `bun.lock`, `bunfig.toml`, CI, Docker, and workspace ownership.
+- Preserve existing Node, browser, edge, Jest, Vitest, TypeScript, and package-consumer contracts unless the task explicitly asks to migrate them.
+- Add focused tests or package checks only when they protect changed Bun runtime, package manager, test runner, build, or public package behavior.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify every Bun signal by role before editing:
+   - `bun install`, `bun add`, `bun remove`, `bun update`, `bun.lock`, `trustedDependencies`, and `[install]` are package manager signals.
+   - `bun <file>`, `bun --watch`, `bun run --bun`, `#!/usr/bin/env bun`, `Bun.serve`, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.$`, and preload settings are runtime signals.
+   - `bun test`, `bun:test`, and `[test]` are test runner signals.
+   - `bun build`, `Bun.build`, `--compile`, and build target settings are bundler or compiler signals.
+   - `bun run <script>` is script execution until the script body proves a more specific role.
+2. Determine package manager ownership from `packageManager`, Bun lockfiles, other lockfiles, CI, Docker, workspace config, and `bunfig.toml`. If `bun.lock` exists, treat Bun as the dependency owner unless current project evidence says otherwise.
+3. Do not delete `bun.lockb`, create `bun.lock`, or switch between npm, pnpm, Yarn, and Bun lockfiles as a side effect. If multiple lockfiles exist, identify whether the state is migration, legacy compatibility, or intentional parallel ownership before editing dependencies.
+4. For Bun installs, check frozen lockfile behavior, workspace filters, linker mode, global virtual store, cache settings, registry settings, overrides, resolutions, patched dependencies, peer dependency behavior, optional dependency behavior, OS, CPU, and libc-sensitive packages when relevant.
+5. Treat `trustedDependencies` as install-time code execution policy. Omitted, explicit array, and empty array each have different trust semantics. Do not broaden trust with a generic trust-all action. If a native package or binary install fails, inspect blocked lifecycle scripts, trust only the required package, and verify with a fresh install and real import or CLI use when a configured intent exists.
+6. Do not claim Bun runs TypeScript as typecheck. Bun runtime execution and `Bun.Transpiler` strip or transform syntax for execution; they do not run the TypeScript checker, emit declarations, or prove generic, JSX, path alias, or public type correctness.
+7. Do not claim Bun bundling replaces TypeScript build output. Bun build output proves bundling for the selected target and format, not `tsc --noEmit`, declaration emit, or downstream TypeScript consumer compatibility.
+8. For TypeScript changes in a Bun project, keep the existing typecheck intent and declaration pipeline. For libraries, inspect declaration output when package exports, path aliases, public types, or build output change. Source-only aliases must not leak into public declarations unless consumers can resolve them.
+9. Align Bun and TypeScript JSX settings when JSX runtime, factory, fragment, or import source changes. TypeScript seeing one JSX runtime while Bun transpiles another is a runtime contract bug.
+10. For Bun bundling and package output, distinguish `bun run build` from direct Bun bundler usage. Confirm script bodies before treating a build as Bun bundling. Choose target and format according to actual consumers; Bun-targeted output is not automatically Node-compatible.
+11. If Node consumers are supported, do not emit package entrypoints that rely on Bun-only APIs, Bun-only wrappers, or Bun-only module resolution unless the package clearly exposes a Bun-specific entry.
+12. Treat Bun runtime as Node-compatible, not Node itself. JavaScriptCore, Node API compatibility gaps, native addons, Node internals, worker options, child process IPC, stream/backpressure, crypto/FIPS, watch behavior, Prisma CLI, sharp, Playwright, and esbuild all need targeted evidence when touched.
+13. Check shebang and runner behavior. A CLI with `#!/usr/bin/env node` may execute under Node even when launched through Bun. Do not call a path Bun-runtime-verified unless the entrypoint actually ran under Bun.
+14. Use Bun's test runner only when the project intentionally uses it or the task targets Bun. Do not silently migrate Jest or Vitest tests to `bun:test`. Treat mocks, snapshots, preloads, globals, path aliases, coverage, isolation, and parallelism as migration-risk areas.
+15. Do not update Bun snapshots as a generic fix. Snapshot updates require intended output change, diff inspection, and a follow-up run without update mode through configured intents.
+16. Choose configured verification intents that cover typecheck, build, tests, package metadata, package artifact risk, docs examples, Bun runtime behavior, Bun test behavior, and mustflow contract checks when available. Report missing frozen install, Bun runtime, Bun test, declaration, package artifact, native dependency, Node compatibility, Docker, or CI verification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Bun's role is explicit: package manager, runtime, script runner, test runner, bundler, transpiler, or mixed.
+- Bun lockfile, install, workspace, trust, and lifecycle behavior is aligned with project ownership.
+- Bun runtime, test, bundler, TypeScript, and declaration claims are not conflated.
+- Bun-only APIs do not leak into Node, browser, edge, or shared package surfaces unintentionally.
+- Native dependency, shebang, Node compatibility, and package consumer risks are handled or reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Report missing frozen install, Bun runtime, Bun test, declaration output, package artifact, Node compatibility, native dependency, CI, Docker, or snapshot review verification intents when those surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If Bun's role is unclear, stop changing runtime or dependency behavior and inspect scripts, lockfiles, `bunfig.toml`, CI, Docker, and entrypoints.
+- If lockfile ownership conflicts, do not run dependency migration or generate a new lockfile unless the task explicitly asks for migration.
+- If Bun runtime execution succeeds but typecheck or declarations are unverified, report that gap instead of claiming TypeScript correctness.
+- If a package works under Bun but claims Node support, repair the Node-compatible entry or report the compatibility risk.
+- If a native dependency, lifecycle script, or trusted dependency change cannot be verified, keep the change scoped and report release-sensitive risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Bun role classification
+- Package manager, lockfile, and trust notes
+- Runtime, TypeScript, bundler, and test runner notes
+- Native, shebang, Node compatibility, or package consumer risks
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Bun risk

package/templates/default/locales/en/.mustflow/skills/cpp-code-change/SKILL.md

@@ -0,0 +1,181 @@
+---
+mustflow_doc: skill.cpp-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: cpp-code-change
+description: Apply this skill when C++ source, headers, modules, native build metadata, toolchains, package managers, ABI surfaces, generated bindings, FFI, tests, or benchmarks are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.cpp-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# C++ Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve C++ target identity, ownership, lifetime, undefined-behavior, build-graph, API, ABI, FFI, generated-binding, modern-language, concurrency, and performance contracts while making a focused change.
+
+A C++ change is successful only when the affected target and consumed surface are understood. Local compile success alone does not prove C++ correctness, compatibility, ABI safety, memory safety, or performance.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.c`, `.cc`, `.cpp`, `.cxx`, `.h`, `.hh`, `.hpp`, `.hxx`, `.ipp`, `.tpp`, `.ixx`, `.cppm`, C++ tests, examples, benchmarks, modules, or generated C++ glue change.
+- C++ build metadata changes, including `CMakeLists.txt`, `CMakePresets.json`, toolchain files, `meson.build`, `meson_options.txt`, Meson native or cross files, `BUILD`, `BUILD.bazel`, `.bazelrc`, `WORKSPACE`, `MODULE.bazel`, `Makefile`, `.mk`, Autotools files, `conanfile.py`, `conanfile.txt`, `conan.lock`, Conan profiles, `vcpkg.json`, `vcpkg-configuration.json`, triplets, package config files, or pkg-config files.
+- The task touches C++ standard version, compiler, standard library, ABI mode, platform branches, generated bindings, shared or static library artifacts, exported symbols, public headers, FFI, ownership, raw pointers, references, smart pointers, views, iterators, allocators, exceptions, errors, templates, concepts, coroutines, modules, atomics, locks, sanitizers, fuzzing, or benchmarks.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- C++ files are read-only context and no C++ source, header, build, package, binding, test, or benchmark surface changes.
+- The task is only formatting, comments, or documentation and does not affect a public header, exported symbol, generated binding, FFI surface, build graph, or documented C++ contract.
+- A generated C++ file must be regenerated by a declared project command rather than edited manually.
+- The change is purely C source with no C++ target, C++ compiler, C++ ABI, C++ build metadata, or C++ consumer boundary involved.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Changed files and their consumed surface classification: private implementation, private header, public header, module interface, shared library, static library, executable, generated binding input, generated binding output, FFI boundary, test, benchmark, or build metadata.
+- Owning build target for every changed C++ source, header, module, generated file, and native artifact.
+- Target-specific compilation identity: C++ standard, compiler family and version, standard library, ABI mode, exception and RTTI mode, build type, platform, architecture, visibility policy, linkage mode, dependency source, and active build front door when available.
+- Relevant CMake, Meson, Bazel, Make, Autotools, Conan, vcpkg, pkg-config, CI, package, and install/export metadata.
+- Public headers, exported symbols, public types, public constants, macros, enum values, generated bindings, FFI functions, target-language surfaces, and downstream consumer expectations when any public surface changes.
+- Ownership, lifetime, allocator, error, exception, callback, thread-safety, synchronization, and performance contracts touched by the change.
+- Configured verification intents from the repository command contract.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine the owning build target before editing. Do not treat repository-wide defaults, editor settings, or the local machine compiler as target authority.
+- Determine whether the change can affect source API, binary ABI, generated binding API, FFI ABI, behavior, memory safety, thread safety, performance, package consumers, or only private implementation.
+- Classify compatibility risk by the highest-risk consumed surface touched by the change. Do not downgrade risk because the diff is small, private-looking, or compile-clean.
+- If C++ standard, compiler, standard library, ABI mode, platform, dependency source, active build front door, or owning target cannot be determined, report the missing boundary and avoid changes that depend on it.
+- Use only configured command intents for validation. Do not invent native build, test, sanitizer, fuzz, package, or benchmark commands.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep edits scoped to the affected C++ target, build graph, tests, generated-binding source of truth, and directly synchronized docs or template surfaces.
+- Prefer RAII, rule of zero, value semantics, explicit ownership transfer, explicit borrowed views, and narrow lifetime contracts over raw ownership or hidden sharing.
+- Prefer additive API and ABI changes when existing consumers must keep working.
+- Add focused tests, compile checks, smoke tests, or benchmark guards only when they protect the changed C++ contract and are covered by configured intents.
+- Do not hand-edit generated output unless the project explicitly treats it as authoritative or the user explicitly requests it with the drift risk understood.
+- Do not weaken compiler, warning, sanitizer, ABI, package, test, or compatibility checks to make a patch appear complete.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read the repository instructions and configured command intents, then inspect the changed C++ files plus nearby source, headers, tests, build files, package metadata, and CI hints.
+2. Identify the owning target for each changed file. For CMake, inspect target sources, include directories, compile definitions, compile features, options, link libraries, install/export surfaces, and public/private/interface propagation. For Meson, inspect targets, dependencies, include directories, options, cross/native files, and install surfaces. For Bazel, inspect `cc_library`, `cc_binary`, `cc_test`, `srcs`, `hdrs`, `deps`, `implementation_deps`, `defines`, `local_defines`, `visibility`, toolchains, and `select()` branches. For Make or Autotools, inspect object rules, included fragments, flags, libraries, generated headers, and install surfaces.
+3. Identify the active build front door. If several active graphs own the same changed file, keep them synchronized or report the unsupported or stale graph explicitly.
+4. Record the target compilation identity: C++ standard, compiler, standard library, ABI mode, platform, architecture, build type, exception and RTTI mode, visibility, linkage, dependency source, and generated-header source when relevant.
+5. Classify risk by highest consumed surface:
+   - `internal_only`: private implementation or private helper only.
+   - `source_api`: public header, exported type, namespace, macro, enum, overload, template, inline function, default argument, include path, or package consumer compile surface.
+   - `binary_abi`: shared library symbol, public object layout, vtable, RTTI, calling convention, visibility, allocator boundary, exception boundary, struct packing, alignment, or ABI flag.
+   - `static_link_contract`: static artifact, object compatibility, compile flags, PIC, LTO, link order, duplicate symbol, ODR, or consumer relink surface.
+   - `generated_binding`: generator input, generated output, wrapper API, target-language package surface, ownership mapping, nullability, or exception/error mapping.
+   - `ffi_boundary`: `extern "C"`, callback, raw buffer, fixed layout, allocator, ownership/free function, error ABI, calling convention, or cross-language thread ownership.
+   - `semantic_compatibility`: behavior, ownership, lifetime, error, ordering, threading, range, default, or resource contract changed without a signature change.
+   - `performance_resource`: hot path, allocation, lock contention, inlining, template instantiation, serialization, binary size, latency, throughput, or memory footprint.
+6. For ownership and lifetime changes, classify every affected value as owner, borrowed non-null reference, borrowed nullable pointer, view, iterator, handle, shared owner, weak observer, or moved-from value. Check raw pointer ownership, reference escape, lambda capture, async or callback storage, move-after-use, `unique_ptr::release`, duplicate `shared_ptr` ownership, custom deleters, container invalidation, member initialization order, and RAII cleanup on failure paths.
+7. For undefined-behavior risk, inspect dangling pointers and references, iterator invalidation, uninitialized memory, out-of-bounds access, signed overflow, bad shifts, strict aliasing, alignment, object lifetime, invalid downcasts, non-virtual base deletion, data races, C string length mistakes, and `string_view` or `span` lifetime.
+8. For public headers, review function signatures, overload sets, namespaces, includes, macros, type aliases, enum values, constants, templates, inline functions, public class layout, virtual functions, base classes, alignment, default arguments, exported concepts, deduced return types, modules, and standard-library types exposed as API or ABI.
+9. For shared libraries, review exported symbol names, symbol visibility, version scripts, import/export macros, SONAME or equivalent policy, name mangling, calling convention, public object layout, vtable layout, RTTI, exception behavior, allocator ownership, dependency ABI, and standard-library ABI flags.
+10. For static libraries, review rebuild and relink contracts, public headers, object compatibility, compiler and standard-library assumptions, build flags, PIC, LTO, ODR risk, duplicate symbols, and consumer link behavior. Do not treat static libraries as ABI-free.
+11. For generated bindings, identify the source of truth, generator version when available, generated output, target-language API, smoke tests, and ownership/error/nullability mapping. Reject source/output drift unless the drift is explicitly intended and verified.
+12. For FFI, prefer a stable C ABI unless the project explicitly marks the boundary unstable. Use fixed-size types, explicit layout, explicit ownership and release functions, explicit error reporting, explicit calling convention, null handling, callback lifetime rules, and thread ownership. Do not leak C++ exceptions, STL types, templates, overloaded functions, implicit ownership, or compiler-specific C++ ABI across FFI without an explicit unstable-boundary policy.
+13. For template, concepts, overload, ADL, and SFINAE changes, verify positive and negative compile behavior when configured checks exist. Review which overloads are added, removed, or silently selected differently. Use return-type, constraint, and ADL fixtures when the repository has that pattern.
+14. For error handling, classify failures as programmer bug, recoverable input or environment failure, resource failure, or invariant violation. Preserve the layer's existing channel: exceptions, error codes, project Result, `std::expected`, assertions, or logging. Do not mix two public failure channels for the same failure without a boundary reason. Treat `noexcept` as a termination contract, not a performance hint.
+15. For concurrency, list shared mutable state, owner thread, guard mutex, atomic invariant, lifetime rule, lock ordering, callback execution, shutdown path, and join or wait path. Do not introduce unguarded shared mutation, locks held across callbacks or blocking I/O, unexplained memory orders, detached lifetime, or relaxed atomics without proof.
+16. For modern C++ features, reject changes justified only as modern, shorter, or cleaner-looking. A feature is allowed only when it removes a concrete failure mode, narrows state, clarifies lifetime or ownership, improves misuse resistance, or has measured performance value. Check public-surface exposure, compiler support, standard-library support, build-system support, CI support, and fallback or configure-time failure before adopting C++20 or C++23 features.
+17. Treat `std::span`, `std::string_view`, ranges views, iterator/sentinel pairs, and coroutine captures as borrowed views. Never store or return them unless owner lifetime is explicit and verified.
+18. For performance work, require baseline, workload, target metric, profile evidence, hypothesis, targeted change, remeasurement, and regression guard when configured verification exists. Do not claim performance from syntax changes, `std::move`, `string_view`, ranges, modules, coroutines, or `constexpr` without evidence or a clear complexity argument.
+19. Choose configured validation by highest-risk surface. All C++ changes need compile-equivalent validation when available. Public headers need downstream-style compile or public-header validation when available. Library artifacts need link validation when available. Shared ABI changes need ABI or exported-symbol validation when available. Generated bindings need regeneration and target-language smoke validation when available. FFI changes need boundary smoke and memory validation when available. Hot-path changes need benchmark validation when available.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise the patch when any of these appear without strong local evidence and risk reporting:
+
+- A changed C++ file has no identified owning target, active build front door, or compilation identity.
+- A public header, exported symbol, generated binding, FFI surface, or library artifact changes without compatibility classification.
+- API compatibility is claimed without inspecting public headers, generated bindings, or downstream-style consumer compile surface.
+- ABI compatibility is claimed after exported symbols, object layout, vtable layout, calling convention, visibility, or FFI layout changed without ABI or equivalent binary-compatibility evidence.
+- A raw pointer, reference, view, iterator, or callback is stored or returned without owner lifetime evidence.
+- `std::string_view`, `std::span`, ranges views, coroutine captures, or iterator pairs outlive their owner or cross mutation/reallocation boundaries without proof.
+- `std::move`, `unique_ptr::release`, `shared_ptr`, custom deleters, or manual cleanup obscure ownership transfer.
+- New manual `new`, `delete`, `malloc`, `free`, close, unlock, or release paths appear where RAII can express the ownership.
+- A `noexcept` function calls code that may throw without an intentional termination policy.
+- Public API exposes C++20 or C++23 features without consumer compiler, standard-library, build-system, and fallback review.
+- Performance improvement is claimed without baseline, workload, measurement, or complexity evidence.
+- Sanitizer, ABI, FFI, binding, benchmark, or downstream checks are missing but the output claims those properties were proven.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The owning target, active build graph, and target compilation identity are known or the missing boundary is reported.
+- The highest compatibility risk is stated: internal-only, source API, binary ABI, static-link contract, generated binding, FFI, semantic compatibility, or performance/resource.
+- Ownership, lifetime, allocator, error, concurrency, and modern-feature impacts are intentional and evidence-backed.
+- Public headers, exported symbols, generated bindings, FFI surfaces, build metadata, tests, docs, and template surfaces are synchronized when they are part of the changed contract.
+- Generated files match their source of truth and generator flow, or drift is reported.
+- No API, ABI, memory-safety, thread-safety, FFI, binding, or performance compatibility is claimed beyond the validation evidence.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Choose validation by highest-risk surface, not by diff size.
+
+Report whether configured validation exists for C++ compile, public-header compile, downstream consumer compile, link, unit, integration, API diff, ABI diff, generated-binding regeneration, target-language smoke, FFI smoke, sanitizer, valgrind or equivalent memory analysis, fuzzing, benchmark, and package-consume scenarios when those surfaces change.
+
+When a required validation intent is unavailable, record the missing intent, why it matters, the weaker validation that was run, and the remaining compatibility risk. Do not invent a command or claim compatibility was proven.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the owning target or active build front door is unclear, stop the risky part and inspect build metadata before editing further.
+- If multiple build graphs own the same changed file and only one can be updated, report the stale graph and compatibility risk.
+- If public API or ABI policy is absent, classify the risk explicitly instead of assuming semver, SONAME, or package compatibility rules.
+- If generated bindings drift, restore source/output alignment or report the generator/source-of-truth gap.
+- If an ownership or lifetime fix creates broad shared ownership, manual cleanup, or hidden view lifetime, revisit the owner boundary before continuing.
+- If concurrency changes lack a synchronization proof, stop that part and inspect the state owner, guard, lifetime, and shutdown path.
+- If performance measurements are unavailable, report that performance compatibility was not proven.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Owning target and compilation identity
+- Highest compatibility risk
+- Ownership, lifetime, UB, concurrency, modern-feature, or performance impact
+- Public API, ABI, binding, FFI, or build-graph impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining C++ risk

package/templates/default/locales/en/.mustflow/skills/github-contribution-quality-gate/SKILL.md

@@ -0,0 +1,166 @@
+---
+mustflow_doc: skill.github-contribution-quality-gate
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: github-contribution-quality-gate
+description: Apply this skill before drafting, opening, or replying to public GitHub issues, pull requests, review threads, or maintainer-facing comments so the contribution follows repository rules, avoids duplicate low-value content, and includes verified evidence.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.github-contribution-quality-gate
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - mustflow_check
+---
+
+# GitHub Contribution Quality Gate
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Create GitHub issues, pull requests, review replies, and maintainer-facing comments that save maintainer time.
+
+The goal is not polished prose. The goal is verified, scoped, actionable information that follows the target repository's rules and gives maintainers enough evidence to reproduce, review, merge, redirect, close, or reject the work faster.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The user asks to draft, open, improve, or reply to a public GitHub issue, pull request, review thread, or maintainer-facing comment.
+- A PR description, issue body, bug report, feature request, documentation report, review reply, or follow-up comment needs repository-template alignment.
+- The contribution may depend on `README.md`, `CONTRIBUTING.md`, issue templates, pull request templates, `SUPPORT.md`, `SECURITY.md`, maintainer comments, duplicate issues, duplicate pull requests, or project-specific contribution rules.
+- AI-generated analysis, generated code, generated tests, generated reproduction steps, or generated security reasoning may influence the public GitHub content.
+- The user has evidence that may belong in an existing issue or pull request instead of a new thread.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only to review code before a report; use `code-review` or `diff-risk-review`.
+- The task is to publish a release, release notes, or changelog entry; use `release-publish-change` or `release-notes-authoring`.
+- The content is a private vulnerability report, credential leak, exploit path, account compromise, or sensitive security issue. Follow the repository security policy and do not draft a public issue.
+- The user asks to mass-generate issues, mass-generate pull requests, farm contribution graphs, farm bounties, or post content the human contributor cannot explain.
+- The task requires a GitHub operation that the host, repository, or user has not permitted. This skill can draft and gate content, but it does not grant external service permission.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Target repository owner and name, plus the URL when available.
+- Intended GitHub action: bug issue, feature issue, documentation issue, question redirect, pull request, review reply, issue comment, PR comment, or follow-up update.
+- Repository rules found in `README.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SUPPORT.md`, `SECURITY.md`, issue templates, issue forms, pull request templates, and linked development docs.
+- Duplicate and context search evidence: searched terms, open and closed issues, open and closed pull requests, discussions when used by the repository, documentation, changelog, and related maintainer comments.
+- User evidence: reproduction steps, minimal example, logs, screenshots, recordings, changed files, local test output, failing command, environment, version, linked issue, or maintainer question being answered.
+- Verification level: personally reproduced, partially reproduced, inferred from code, inferred from logs, not reproduced, not searched, or not verified.
+- Desired result: report a bug, propose a feature, submit a fix, ask for design approval, answer a maintainer, provide missing evidence, or close the loop.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Treat repository-specific rules as the source of truth for the draft format.
+- Prefer repository templates over fallback structures.
+- If template fields are required, preserve the headings and answer each field. Use `N/A` only when the field truly does not apply, with one short reason.
+- If the repository sends support questions to Discussions, Discord, Slack, Stack Overflow, a mailing list, or another support channel, do not draft a bug issue for a support question.
+- If duplicate search is not possible with available context or host tools, state that clearly and lower confidence.
+- If essential evidence is missing, do not fabricate it. Return a blocking gate decision or ask for the exact missing evidence.
+- If a public post may expose a private vulnerability, credential, exploit, private log, customer data, or account-specific detail, return `PRIVATE_SECURITY_REPORT`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Draft or revise issue bodies, PR descriptions, review replies, and maintainer-facing comments.
+- Summarize repository rules, duplicate-search results, evidence, missing evidence, and posting risk.
+- Update local documentation only when the user explicitly asks to save the draft or the repository task separately requires documentation changes.
+- Do not edit code, tests, templates, schemas, repository settings, labels, milestones, or GitHub state as part of this skill unless a separate task and matching skill authorize that work.
+- Do not add generic filler, speculative root causes, fake test results, fake reproduction steps, or unverified claims.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the intended contribution surface: new issue, existing issue comment, new PR, existing PR comment, review reply, or follow-up update.
+2. Read repository contribution rules before drafting:
+   - root, `.github/`, and `docs/` `CONTRIBUTING.md`;
+   - `CODE_OF_CONDUCT.md`;
+   - `SUPPORT.md`;
+   - `SECURITY.md`;
+   - `.github/ISSUE_TEMPLATE/` Markdown templates, YAML issue forms, and `config.yml`;
+   - `pull_request_template.md`, `.github/pull_request_template.md`, `docs/pull_request_template.md`, and `PULL_REQUEST_TEMPLATE/`;
+   - development docs linked from the contribution guide.
+3. Identify mandatory repository fields: title format, labels or issue type guidance, reproduction requirements, test expectations, AI-assistance disclosure rules, security-reporting path, support channel, contribution scope, and linked-issue requirements.
+4. Search for duplicates and context before drafting. Use exact error text, function names, component names, stack trace fragments, package names, version numbers, platform names, and user-facing symptoms. Record likely duplicates with number, status, and why they are or are not the same.
+5. Decide whether the contribution adds new verified value:
+   - new value includes a minimal reproduction, different affected version, regression range, failing test, confirmed workaround, smaller root-cause evidence, platform-specific observation, or logs that materially improve triage;
+   - `same problem here` without new evidence is not new value.
+6. For bug issues, require actual behavior, expected behavior, exact reproduction steps, smallest reasonable reproduction, version, environment, relevant logs or screenshots, regression status, attempted workarounds, and concrete impact.
+7. For feature or enhancement issues, require user problem, affected users, concrete workflow, why existing behavior is insufficient, related discussions, compatibility impact, alternatives considered, and non-goals when the proposal can sprawl.
+8. For documentation issues, require exact page, section, symbol, command, or example; current wording or behavior; expected wording or explanation; and evidence that the current documentation is stale or misleading when available.
+9. For pull requests, require focused scope, linked issue or prior discussion when non-trivial, changed behavior, intentionally unchanged behavior, tests added or updated, exact verification results, compatibility notes for public surfaces, UI screenshots when relevant, and draft status when incomplete.
+10. For review replies, answer the maintainer's actual question first. Provide requested logs, reproduction, design tradeoff, tests, or blocker. Do not answer a different question because it is easier.
+11. Apply AI-assistance rules:
+    - the human contributor remains responsible for accuracy, completeness, copyright, testing, follow-up, and explanation;
+    - disclose substantial AI assistance when the repository requires it or when AI-generated analysis, code, tests, reproduction steps, or security reasoning materially shaped the content;
+    - do not submit AI output that the human contributor has not reviewed, cannot explain, or could have tested but did not.
+12. Choose a gate decision before writing the final draft:
+    - `POST` when the content follows repository rules and has enough verified value;
+    - `POST_AS_DRAFT` when a PR direction is useful but not ready for final review;
+    - `ASK_IN_EXISTING_THREAD` when the evidence belongs in a related issue or PR;
+    - `DO_NOT_POST` when the content lacks verified value, duplicates existing content, violates repository rules, or the human contributor cannot defend it;
+    - `PRIVATE_SECURITY_REPORT` when the content should not be public.
+13. Draft concise maintainer-ready content. Put the core fact early, keep sections short, include only relevant evidence, quote logs narrowly, and avoid generic flattery, repeated apology, AI disclaimers, or project background that maintainers already know.
+14. Run or report configured local verification only when the GitHub content depends on the current local diff or repository workflow. Do not infer missing commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The gate decision is explicit and evidence-backed.
+- Repository templates and rules are followed or the reason they could not be checked is stated.
+- Duplicate search is summarized with confidence.
+- Every technical claim in the draft is tied to evidence or marked uncertain.
+- Security-sensitive content is not prepared for public posting.
+- AI assistance is disclosed when required or material.
+- The draft helps maintainers act faster or the skill blocks posting.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available and relevant:
+
+- `changes_status`
+- `changes_diff_summary`
+- `mustflow_check`
+
+Use `changes_status` and `changes_diff_summary` when drafting a PR description or review reply for the current local diff. Use `mustflow_check` when the GitHub content concerns mustflow workflow files or skill changes. If a repository-specific test, lint, build, or docs check is required but not declared as a configured intent, report the missing intent instead of inventing a command.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If repository rules cannot be inspected, draft only a low-confidence outline and list the missing rule files or inaccessible templates.
+- If duplicate search cannot be performed, do not claim the issue is new.
+- If a duplicate exists and the user has no new evidence, return `DO_NOT_POST`.
+- If a duplicate exists and the user has new evidence, draft a concise comment for the existing thread instead of a new issue.
+- If the report is a support request, redirect to the repository's support path instead of drafting a bug report.
+- If the issue may be security-sensitive, return `PRIVATE_SECURITY_REPORT` and cite the repository security policy path when known.
+- If the human contributor cannot explain the claim, fix, or answer, return `DO_NOT_POST`.
+- If tests were feasible but not run, keep the draft honest and explain the skipped verification.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Gate decision: `POST`, `POST_AS_DRAFT`, `ASK_IN_EXISTING_THREAD`, `DO_NOT_POST`, or `PRIVATE_SECURITY_REPORT`
+- Why
+- Repository rules found
+- Duplicate and context check
+- Evidence checked
+- Missing evidence
+- Draft
+- Final self-check:
+  - Can a maintainer reproduce or review this without guessing?
+  - Does this follow repository rules and templates?
+  - Does this add new information beyond existing issues or PRs?
+  - Is every technical claim backed by evidence?
+  - Were feasible tests or verification checks run or honestly skipped?
+  - Is AI assistance disclosed when required or material?
+  - Can the human contributor explain and defend the content without AI?
+  - Does posting this save maintainer time?

package/templates/default/locales/en/.mustflow/skills/node-code-change/SKILL.md

@@ -0,0 +1,145 @@
+---
+mustflow_doc: skill.node-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: node-code-change
+description: Apply this skill when Node.js runtime code, package manager ownership, module format, package entry metadata, native dependencies, Node test runner behavior, TypeScript execution mode, or deployment runtime support is created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.node-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Node Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve the actual Node.js runtime, module, package manager, TypeScript execution, test runner, package entry, native dependency, and deployment boundaries.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Node.js runtime code, `node:*` APIs, `process`, `Buffer`, streams, workers, child processes, native addons, Node permission flags, Node test runner behavior, package entry metadata, or deployment runtime support changes.
+- `package.json` Node fields change, including `engines.node`, `devEngines`, `packageManager`, `type`, `main`, `exports`, `imports`, `types`, `typesVersions`, `files`, `bin`, `sideEffects`, or `workspaces`.
+- Node version signals, CI Node setup, Docker Node base images, serverless Node runtime settings, Corepack usage, npm, pnpm, Yarn, or lockfile ownership changes.
+- The task proposes native Node TypeScript execution, ESM/CJS conversion, conditional exports, package manager migration, or Node built-in test runner migration.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes TypeScript type modeling, validators, declarations, or `.ts` source without Node runtime or package entry impact; use `typescript-code-change`.
+- The task only changes plain JavaScript without Node-specific runtime, package, or deployment behavior; use `javascript-code-change`.
+- Bun owns the runtime, package manager, test runner, or bundler behavior being changed; use `bun-code-change`.
+- A narrower framework skill owns the changed route or handler surface, unless Node runtime, package, or deployment behavior is also affected.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Node version signals: `.nvmrc`, `.node-version`, `.tool-versions`, Volta or mise/asdf config, `package.json#engines.node`, `package.json#devEngines`, CI Node matrix, Docker `FROM node:*`, and deployment runtime config.
+- Package ownership signals: `package.json#packageManager`, npm, pnpm, Yarn, Bun, or vlt lockfiles, workspace config, `.npmrc`, `.yarnrc.yml`, Corepack usage, CI install commands, and Docker install commands.
+- Module and package metadata: nearest `package.json#type`, file extensions, `main`, `module`, `exports`, `imports`, `types`, `typings`, `typesVersions`, `files`, `bin`, `sideEffects`, and documented import paths.
+- TypeScript and loader signals: `tsconfig*.json`, `tsx`, `ts-node`, SWC, Babel, Vite, tsup, esbuild, Node native type stripping, path aliases, declaration output, and test or build transforms.
+- Test, native, and deployment signals: package scripts, test runner config, `node:test` usage, native dependency indicators such as `.node`, `binding.gyp`, `node-gyp`, lifecycle scripts, optional dependencies, serverless or edge config, and command contract entries.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine the effective Node runtime before using newer syntax, APIs, or flags.
+- Determine package manager ownership before editing dependencies or lockfiles.
+- Determine Node's actual module loading path before changing imports, file extensions, or package entry metadata.
+- Treat package entry, engine, and lockfile changes as public contract or release-sensitive changes unless proven internal.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep runtime-specific Node APIs in Node-owned files or adapters.
+- Keep package manager changes aligned with the owner already used by CI, Docker, and lockfiles.
+- Keep ESM, CJS, and dual package boundaries explicit and synchronized with declarations, tests, docs examples, and consumer entrypoints.
+- Preserve existing TypeScript build, typecheck, declaration, and loader pipelines unless the task explicitly asks to replace them.
+- Add or update focused tests only when they protect the changed runtime, package, module, native, or deployment contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read runtime version signals before editing. Treat deployment runtime as the hard constraint, CI runtime as the verified constraint, `engines.node` as the compatibility contract, and local version files as developer hints. If these conflict, report the conflict before introducing APIs or syntax that depend on one side.
+2. Do not assume Node Current. Use Current-only APIs only when local tooling, CI, Docker, deployment, package metadata, and intended consumers all prove support for that Current major. For production applications, prefer Active LTS or Maintenance LTS when the project does not declare otherwise.
+3. Determine package manager ownership from `packageManager`, lockfiles, workspace config, CI, and Docker. If `packageManager` and lockfiles disagree, or multiple lockfiles exist, do not rewrite dependencies until the owner and migration intent are clear.
+4. Keep package manager semantics distinct:
+   - npm dependency changes update `package.json` and npm lockfiles; clean CI installs use npm's clean-install mode.
+   - pnpm workspaces and frozen lockfile behavior can affect every workspace even when one package changed.
+   - Yarn PnP, Zero-Install, and immutable installs can make `node_modules` assumptions wrong.
+   - Corepack availability depends on the Node/runtime environment; do not assume it exists in every Node version, image, or CI runner.
+5. Determine Node module loading from Node rules, not preference or `tsconfig` alone. `.mjs` and `.mts` are ESM, `.cjs` and `.cts` are CommonJS, and `.js` or `.ts` follows the nearest package `type` after the project's loader/build path is considered.
+6. Treat `type`, `main`, `exports`, `imports`, file extensions, and conditional export changes as package entry contract changes. Adding `exports` can block deep imports and should be classified as compatibility-sensitive unless all previously supported paths remain exported or the release is intentionally breaking.
+7. For conditional exports, keep condition order deliberate, include a `default` fallback when multi-runtime or bundler consumers are intended, and avoid splitting `import` and `require` into separate stateful implementations unless dual package hazards are tested.
+8. For `imports`, use `#` aliases only for package-internal paths, and keep TypeScript paths, bundler aliases, test runner aliases, and declaration output aligned.
+9. For JSON imports, `require(esm)`, top-level await, `.mts`, `.cts`, `.d.mts`, and `.d.cts`, verify the minimum Node version, TypeScript module resolution, generated output, and consumer path before changing code.
+10. Do not replace an existing TypeScript pipeline with native Node TypeScript execution unless the task explicitly asks for that migration. Node native TypeScript execution is limited type stripping; it does not typecheck, read `tsconfig`, resolve path aliases, emit declarations, downlevel syntax, transform decorators or enums, or support TSX as a full build pipeline.
+11. If native Node TypeScript execution is intentionally used, keep syntax erasable-only, use `import type` for type-only imports, avoid runtime TypeScript features that require transforms, and keep the configured typecheck/build pipeline for application and library code.
+12. Detect the actual test runner from scripts, config files, dependencies, and CI. Do not migrate Jest, Vitest, Playwright, or another runner to `node:test` just because Node has a built-in runner. Watch, coverage, mock, snapshot, worker, and cleanup behavior are runner-specific.
+13. Treat watch mode and snapshot update modes as development or review actions, not final verification. Use the configured oneshot intents and report when no configured runner-specific intent exists.
+14. Before using Node APIs in deployment code, classify the target as Node server, Docker, serverless Node, edge runtime, static build, or multi-runtime package. Edge runtimes are not full Node.js runtimes.
+15. Inspect native and install-sensitive dependencies when package metadata or runtime imports touch `.node`, `binding.gyp`, `node-gyp`, `preinstall`, `install`, `postinstall`, `prepare`, optional dependencies, peer dependencies, OS, CPU, libc, or Node ABI boundaries.
+16. Treat optional dependencies and optional peers as absent until code handles absence. Do not require optional packages directly without fallback or error handling that matches the existing project pattern.
+17. Treat the Node permission model as a trusted-code seatbelt, not a sandbox for untrusted code. If permission flags are introduced or changed, map required filesystem, network, child process, worker, native addon, WASI, inspector, and temporary directory access explicitly.
+18. Choose configured verification intents that cover lint, build, tests, package metadata, release-sensitive package output, docs examples, and mustflow contract checks when available. Report missing consumer fixture, ESM, CJS, TypeScript consumer, native dependency, deployment, or permission verification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Effective Node runtime and package manager ownership are known or explicitly reported as conflicting.
+- Module and package entry changes are synchronized with declarations, tests, docs examples, and consumer surfaces when relevant.
+- Native TypeScript execution is not mistaken for typecheck, declaration emit, or a full build pipeline.
+- Node-only APIs do not leak into browser, edge, Bun, or shared package surfaces unintentionally.
+- Native dependency, lifecycle, optional dependency, and permission-model risks are handled or reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Report missing ESM/CJS consumer, declaration output, package artifact, frozen install, native dependency, deployment runtime, permission-model, or runner-specific verification intents when those surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If runtime signals conflict, do not resolve the conflict by assuming the newest Node version.
+- If package manager ownership conflicts, do not add, remove, or migrate dependencies until the owner is clear.
+- If a package entry change blocks a documented or previously supported import path, restore compatibility or report the breaking-change requirement.
+- If native Node TypeScript execution fails, repair the build/loader boundary instead of weakening typecheck or deleting the TypeScript pipeline.
+- If native dependency installation or optional dependency behavior is unclear, classify the change as release-sensitive and report the missing install or runtime evidence.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Runtime and package manager decision
+- Module and package entry notes
+- TypeScript execution and test runner notes
+- Native, lifecycle, deployment, or permission risks
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Node.js risk

package/templates/default/locales/en/.mustflow/skills/routes.toml

@@ -114,6 +114,24 @@ route_type = "adjunct"
 priority = 42
 applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "public_api_change", "security_change", "privacy_change", "data_change", "migration_change", "package_metadata_change"]
 
+[routes."cpp-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
+
+[routes."node-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
+
+[routes."bun-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
+
 [routes."api-contract-change"]
 category = "general_code"
 route_type = "primary"
@@ -348,6 +366,12 @@ route_type = "authoring"
 priority = 70
 applies_to_reasons = ["mustflow_docs_change"]
 
+[routes."github-contribution-quality-gate"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 60
+applies_to_reasons = ["unknown_change", "docs_change", "workflow_change", "public_api_change"]
+
 [routes."instruction-conflict-scope-check"]
 category = "workflow_contracts"
 route_type = "adjunct"

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.25.1"
+version = "2.26.0"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -21,7 +21,9 @@ creates = [
   ".mustflow/skills/codebase-orientation/SKILL.md",
   ".mustflow/skills/clarifying-question-gate/SKILL.md",
   ".mustflow/skills/astro-code-change/SKILL.md",
+  ".mustflow/skills/bun-code-change/SKILL.md",
   ".mustflow/skills/css-code-change/SKILL.md",
+  ".mustflow/skills/cpp-code-change/SKILL.md",
   ".mustflow/skills/dart-code-change/SKILL.md",
   ".mustflow/skills/elysia-code-change/SKILL.md",
   ".mustflow/skills/flutter-code-change/SKILL.md",
@@ -29,6 +31,7 @@ creates = [
   ".mustflow/skills/hono-code-change/SKILL.md",
   ".mustflow/skills/html-code-change/SKILL.md",
   ".mustflow/skills/javascript-code-change/SKILL.md",
+  ".mustflow/skills/node-code-change/SKILL.md",
   ".mustflow/skills/python-code-change/SKILL.md",
   ".mustflow/skills/rust-code-change/SKILL.md",
   ".mustflow/skills/svelte-code-change/SKILL.md",
@@ -62,6 +65,7 @@ creates = [
   ".mustflow/skills/ui-quality-gate/SKILL.md",
   ".mustflow/skills/external-prompt-injection-defense/SKILL.md",
   ".mustflow/skills/external-skill-intake/SKILL.md",
+  ".mustflow/skills/github-contribution-quality-gate/SKILL.md",
   ".mustflow/skills/file-path-cross-platform-change/SKILL.md",
   ".mustflow/skills/idea-triage/SKILL.md",
   ".mustflow/skills/facade-pattern/SKILL.md",
@@ -127,7 +131,9 @@ minimal = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -135,6 +141,7 @@ minimal = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -179,7 +186,9 @@ patterns = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -187,6 +196,7 @@ patterns = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -242,7 +252,9 @@ oss = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -250,6 +262,7 @@ oss = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -276,6 +289,7 @@ oss = [
   "docs-update",
   "external-prompt-injection-defense",
   "external-skill-intake",
+  "github-contribution-quality-gate",
   "facade-pattern",
   "failure-triage",
   "file-path-cross-platform-change",
@@ -317,7 +331,9 @@ team = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -325,6 +341,7 @@ team = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -348,6 +365,7 @@ team = [
   "diff-risk-review",
   "docs-update",
   "external-prompt-injection-defense",
+  "github-contribution-quality-gate",
   "facade-pattern",
   "failure-triage",
   "file-path-cross-platform-change",
@@ -380,7 +398,9 @@ product = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -388,6 +408,7 @@ product = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -411,6 +432,7 @@ product = [
   "docs-update",
   "external-prompt-injection-defense",
   "facade-pattern",
+  "github-contribution-quality-gate",
   "failure-triage",
   "file-path-cross-platform-change",
   "idea-triage",
@@ -448,7 +470,9 @@ library = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
+  "cpp-code-change",
   "dart-code-change",
   "elysia-code-change",
   "flutter-code-change",
@@ -456,6 +480,7 @@ library = [
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -482,6 +507,7 @@ library = [
   "docs-update",
   "external-prompt-injection-defense",
   "facade-pattern",
+  "github-contribution-quality-gate",
   "failure-triage",
   "file-path-cross-platform-change",
   "idea-triage",
@@ -523,6 +549,7 @@ managed_targets = [".gitignore"]
 generated_targets = [
   "REPO_MAP.md",
   ".mustflow/config/manifest.lock.toml",
+  ".mustflow/cache/**",
   ".mustflow/state/**",
   ".mustflow/worklogs/**",
   ".mustflow/plans/**",
@@ -593,6 +620,7 @@ default = "abort"
 [conflict_policy.generated]
 "REPO_MAP.md" = "prompt"
 ".mustflow/config/manifest.lock.toml" = "regenerate"
+".mustflow/cache/**" = "keep"
 ".mustflow/state/**" = "keep"
 ".mustflow/worklogs/**" = "keep"
 ".mustflow/plans/**" = "keep"