mustflow 2.25.0 → 2.25.2

package/templates/default/locales/en/.mustflow/skills/file-path-cross-platform-change/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.file-path-cross-platform-change
 locale: en
 canonical: true
-revision: 1
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: file-path-cross-platform-change
-description: Apply this skill when file path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported.
+description: Apply this skill when file path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, clone or checkout destinations, scaffold roots, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,7 +35,8 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 ## Use When
 
 - Code accepts, stores, serializes, validates, normalizes, joins, resolves, compares, scans, extracts, uploads, downloads, writes, deletes, locks, packages, or reports paths.
-- Path behavior appears in CLI arguments, API request or response schemas, config files, snapshots, fixtures, generated output, package artifacts, logs, manifests, caches, temp directories, upload or download flows, archive extraction, or scanner output.
+- Path behavior appears in CLI arguments, API request or response schemas, config files, snapshots, fixtures, generated output, package artifacts, logs, manifests, caches, temp directories, upload or download flows, archive extraction, repository clone or checkout destinations, project scaffolding, installer output, or scanner output.
+- Code clones or checks out repositories, downloads and extracts templates, scaffolds projects, installs dependency trees, or cleans up partially materialized project folders after a filesystem or toolchain failure.
 - A change claims path traversal safety, base-directory containment, symlink safety, junction or reparse-point safety, archive extraction safety, atomic write behavior, durable write behavior, lock ownership, cleanup safety, deterministic scanning, or Windows/macOS/Linux compatibility.
 - A test or docs example includes paths that must behave consistently across Windows, macOS, Linux, CI, containers, archives, package artifacts, or user machines.
 
@@ -53,6 +54,7 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 - Every path input and output, including user input, CLI args, API fields, config fields, archive entries, generated files, temp files, cache paths, lock files, uploaded filenames, download filenames, scanner roots, package artifact paths, and logs.
 - The path owner and trust class: user-controlled, repository-owned, generated, temp, cache, archive-contained, package artifact, external file, or unknown.
 - The base directory or allowed root, expected relative/absolute policy, symlink and reparse-point policy, case-sensitivity policy, invalid-name policy, atomic-write policy, lock policy, archive extraction policy, scanner bounds, cleanup policy, and platform expectations.
+- For clone, checkout, scaffold, extract, and install flows: requested source, destination root, final project directory, deepest expected entry when known, path-length budget, component-length budget, byte budget, preflight coverage, partial-output owner, staging directory owner, promotion policy, cleanup policy, and failure classification contract.
 - Current path helpers, safe filesystem wrappers, temp/cache helpers, archive helpers, upload/download helpers, scanners, schema validators, snapshots, and tests.
 - Relevant command-intent entries for build, tests, docs, release, and mustflow validation.
 
@@ -75,34 +77,45 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Build a path ledger. List every path field, argument, helper, schema, snapshot, generated output, package artifact, archive entry, upload/download filename, scanner root, temp/cache path, lock file, and cleanup target touched by the change.
+1. Build a path ledger. List every path field, argument, helper, schema, snapshot, generated output, package artifact, archive entry, clone or checkout destination, scaffold output, installer output, upload/download filename, scanner root, temp/cache path, lock file, and cleanup target touched by the change.
 2. Classify each path by trust and owner: trusted repository path, user input, generated state, template path, package artifact, temporary file, cache file, archive-contained path, external path, uploaded name, downloaded name, scanner root, or unknown.
 3. Define the allowed root and representation. Decide whether the contract accepts relative paths, absolute paths, URLs, file URLs, archive entry names, package-relative paths, repository-relative paths, or display-only paths.
 4. Reject dangerous path text before filesystem access: null bytes, empty names where not allowed, absolute paths where relative paths are required, dot segments where not allowed, Windows device names, drive-relative paths, UNC roots, namespace prefixes, alternate data streams, trailing dots or spaces, reserved characters, and mixed separator bypasses.
 5. Treat Windows drive-relative paths such as `C:tmp.txt` as relative to a drive current directory, not as `C:\tmp.txt`.
 6. Treat Windows reserved names as reserved even with extensions. Names such as `CON`, `PRN`, `AUX`, `NUL`, `COM1`, and `LPT1` must not become ordinary user filenames.
-7. Treat macOS and Windows case-insensitive defaults as compatibility risks. Decide whether to reject case-only collisions, preserve spelling, normalize display only, or rely on the host filesystem.
-8. Do not solve containment with string prefixes. Establish the base real path, resolve or canonicalize the candidate parent when possible, then use path-aware relative containment with a separator boundary.
-9. For new files whose final path does not exist yet, canonicalize the existing parent directory and verify that parent remains inside the allowed root.
-10. Recheck symlink, junction, reparse-point, and final-target behavior at the operation boundary where the runtime allows it. Do not claim race-free behavior from normalize-then-open code alone.
-11. For uploads and downloads, separate displayed filename from storage key. Validate extension, size, content type, magic bytes when relevant, path separators, Unicode aliasing, reserved names, collision policy, overwrite policy, and tenant or user ownership.
-12. For archive extraction, validate every entry before extraction. Reject absolute entries, parent traversal, empty names, platform-reserved names, symlink entries unless explicitly supported, hard links unless explicitly supported, duplicate or case-colliding entries, oversized entries, zip bombs, and extraction outside the target root.
-13. Do not call extract-all behavior on untrusted archives unless the helper performs per-entry validation and bounded extraction.
-14. For atomic writes, create the temporary file in the target directory on the same filesystem, use an unpredictable temp name, write, flush, close, replace or rename, and flush the parent directory when the platform and helper support it.
-15. Scope atomicity claims. Cross-filesystem moves, network filesystems, Windows sharing violations, antivirus/indexer locks, and missing directory fsync support can downgrade a claim to best effort.
-16. For Windows replace or rename failures caused by sharing violations, use bounded retry or report the platform limitation. Do not turn every transient lock into silent data loss.
-17. For locks and mutexes, define owner token, stale lock policy, crash recovery, deletion race handling, PID reuse handling, and whether the lock works on local filesystems only. Do not treat a PID file alone as proof of ownership.
-18. For scanners, set max depth, max file count, max file size, binary-file handling, ignored directories, hidden-file policy, permission-error behavior, symlink traversal policy, loop detection, deterministic ordering, and output path format.
-19. For temp and cache paths, keep them under an owned root, avoid global temp rename into a target location, include cleanup bounds, and avoid leaking user data through predictable names.
-20. For CLI, API, schema, snapshot, docs, and package artifact path changes, update every contract surface together. Path spelling, separators, slash policy, absolute/relative policy, escaping, sorting, and error messages are part of the contract.
-21. Add focused tests for the riskiest path shapes: traversal, absolute input, drive-relative input, UNC-like input, reserved names, trailing dots or spaces, case collision, symlink escape, archive traversal, duplicate archive entries, scanner loop, large file cap, and cleanup boundary.
-22. Select verification from the command contract based on risk. Public CLI/API/schema/package artifact changes need broader checks than internal helper-only changes.
+7. For clone, checkout, scaffold, extract, and install flows, use an explicit `preflight -> dangerous operation -> classifier -> safe cleanup` pipeline. Preflight must estimate the effective path budget before materializing files, including the destination root, project directory, generated path segments, archive or repository entry names when known, operating-system path limits, component-name limits, byte limits, and safety headroom.
+8. For Git clone and checkout materialization, do not treat `clone` as one indivisible operation. When feasible, fetch repository metadata into an app-owned staging area without checkout, inspect the tree or manifest entries, check the final destination budget, Windows reserved names, byte limits, Unicode aliases, and case collisions, then perform checkout or promotion only after the destination is known to be safe.
+9. Do not clone, extract, scaffold, or install directly into a user-selected final directory when the operation may partially materialize an externally sourced tree. Materialize into an owned staging directory, preserve diagnostics on failure, and promote or move into the final directory only after success.
+10. On Windows Git checkout paths, do not assume the operating system long-path setting alone is enough. Product code that invokes Git should prefer per-invocation `core.longpaths=true` configuration when compatible, avoid mutating global Git config without explicit user intent, and still surface a path-specific error if checkout cannot create an entry.
+11. Treat POSIX `ENAMETOOLONG`, component-length failures, case-only conflicts on case-sensitive filesystems, missing executable bits, watcher limits, descriptor limits, quota, and mount permission errors as platform failures, not generic application failures.
+12. Count bytes where the platform counts bytes. A filename that looks short in characters can exceed component limits when it contains CJK, combining marks, emoji, or mixed normalization forms. Do not treat JavaScript string length, Python `len`, or UI character count as a filesystem byte-budget proof.
+13. Do not silently hash, truncate, underscore-prefix, fullwidth-convert, or otherwise rename user, repository, archive, or generated filenames to dodge platform restrictions unless the product contract explicitly defines a reversible mapping, collision handling, display name, migration behavior, and user-facing explanation.
+14. Treat macOS and Windows case-insensitive defaults as compatibility risks. Decide whether to reject case-only collisions, preserve spelling, normalize display only, or rely on the host filesystem.
+15. Detect candidate collisions before writing when entries come from Git trees, archives, generators, uploads, or package artifacts. Include case collisions, Unicode normalization aliases, reserved names, trailing dot or space aliases, and duplicate archive entries.
+16. Do not solve containment with string prefixes. Establish the base real path, resolve or canonicalize the candidate parent when possible, then use path-aware relative containment with a separator boundary.
+17. For new files whose final path does not exist yet, canonicalize the existing parent directory and verify that parent remains inside the allowed root.
+18. Recheck symlink, junction, reparse-point, and final-target behavior at the operation boundary where the runtime allows it. Do not claim race-free behavior from normalize-then-open code alone.
+19. For uploads and downloads, separate displayed filename from storage key. Validate extension, size, content type, magic bytes when relevant, path separators, Unicode aliasing, reserved names, collision policy, overwrite policy, and tenant or user ownership.
+20. For archive extraction, validate every entry before extraction. Reject absolute entries, parent traversal, empty names, platform-reserved names, symlink entries unless explicitly supported, hard links unless explicitly supported, duplicate or case-colliding entries, oversized entries, zip bombs, and extraction outside the target root.
+21. Do not call extract-all behavior on untrusted archives unless the helper performs per-entry validation and bounded extraction.
+22. Classify filesystem and platform errors before reporting a generic network, auth, dependency, or unknown failure. Use a stable taxonomy such as `path_too_long`, `filename_too_long`, `byte_limit_exceeded`, `invalid_path`, `reserved_name`, `case_collision`, `unicode_collision`, `symlink_escape`, `permission_denied`, `file_locked`, `cross_device_move`, `disk_full_or_quota`, `executable_bit_missing`, `line_ending_mismatch`, `watcher_limit`, and `descriptor_limit`.
+23. Preserve bounded diagnostic evidence before cleaning up a failed clone, scaffold, extraction, install, or generated-output write. Cleanup may remove only an app-owned staging directory or owned partial output, never an ambiguous parent directory, an existing project directory, or a user-selected final folder.
+24. For atomic writes, create the temporary file in the target directory on the same filesystem, use an unpredictable temp name, write, flush, close, replace or rename, and flush the parent directory when the platform and helper support it.
+25. Scope atomicity claims. Cross-filesystem moves, network filesystems, Windows sharing violations, antivirus/indexer locks, and missing directory fsync support can downgrade a claim to best effort.
+26. For Windows replace or rename failures caused by sharing violations, use bounded retry or report the platform limitation. Do not turn every transient lock into silent data loss.
+27. For locks and mutexes, define owner token, stale lock policy, crash recovery, deletion race handling, PID reuse handling, and whether the lock works on local filesystems only. Do not treat a PID file alone as proof of ownership.
+28. For scanners, set max depth, max file count, max file size, binary-file handling, ignored directories, hidden-file policy, permission-error behavior, symlink traversal policy, loop detection, deterministic ordering, and output path format.
+29. For temp and cache paths, keep them under an owned root, avoid global temp rename into a target location, include cleanup bounds, and avoid leaking user data through predictable names.
+30. For CLI, API, schema, snapshot, docs, and package artifact path changes, update every contract surface together. Path spelling, separators, slash policy, absolute/relative policy, escaping, sorting, and error messages are part of the contract.
+31. Add focused tests for the riskiest path shapes: traversal, absolute input, drive-relative input, UNC-like input, reserved names, trailing dots or spaces, case collision, Unicode collision, long path, overlong filename, byte-limit overflow with multibyte names, symlink escape, archive traversal, duplicate archive entries, scanner loop, large file cap, clone checkout failure classification, and cleanup boundary.
+32. Select verification from the command contract based on risk. Public CLI/API/schema/package artifact changes need broader checks than internal helper-only changes.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Path trust classes, accepted path representation, invalid-name policy, case policy, root boundary, symlink and reparse-point policy, archive policy, upload/download policy, scanner policy, atomic-write policy, lock policy, temp/cache policy, and cleanup policy are explicit.
 - Path contracts are synchronized across helpers, schemas, CLI/API docs, snapshots, fixtures, generated outputs, package artifacts, tests, and reports.
+- Clone, checkout, scaffold, extract, and install flows have explicit preflight, staging, promotion, path-length, collision, platform-failure classification, diagnostic-preservation, and cleanup policies.
 - Any race-safety, atomicity, durability, lock, or cross-platform claim is scoped to what the current runtime and helpers can actually guarantee.
 - Platform behavior that was not tested is reported as remaining risk.
 
@@ -129,6 +142,7 @@ Prefer focused tests for helper-only path changes. Use release or package checks
 - If root containment is unclear, stop before writing, deleting, extracting, scanning, or opening and report the ambiguous path owner.
 - If the platform cannot prove symlink-safe behavior, fail closed or report the exact remaining gap.
 - If archive entries cannot be validated before extraction, do not extract the archive.
+- If clone, checkout, scaffold, extraction, or install fails mid-materialization, classify filesystem and platform causes before network or auth causes, preserve bounded diagnostics, and cleanup only the owned staging directory or owned partial output.
 - If atomic replace, file fsync, parent directory fsync, no-follow open, lock ownership, or final-target verification is unavailable, downgrade the claim and keep the operation bounded.
 - If Windows, macOS, Linux, container, CI, or network-filesystem behavior differs and cannot be tested, state the untested platform boundary.
 - If cleanup might remove user data or files outside generated state, do not proceed without a tighter owned root.
@@ -139,7 +153,8 @@ Prefer focused tests for helper-only path changes. Use release or package checks
 - Path contract changed
 - Path ledger and trust classes
 - Accepted representation and base-root policy
-- Windows, macOS, Linux, archive, upload/download, scanner, lock, temp/cache, atomic-write, and cleanup decisions
+- Windows, macOS, Linux, byte-limit, Unicode, archive, upload/download, scanner, lock, temp/cache, atomic-write, and cleanup decisions
+- Clone, checkout, scaffold, extract, install, preflight, staging, promotion, failure-taxonomy, diagnostic-preservation, and safe-cleanup decisions
 - CLI/API/schema/snapshot/generated-output/package artifact surfaces synchronized
 - Tests or fixtures added or reused
 - Command intents run

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/line-ending-hygiene/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.line-ending-hygiene
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: line-ending-hygiene
-description: Apply this skill when Git reports CRLF/LF warnings or when tracked text files may need repository line-ending normalization.
+description: Apply this skill when Git reports CRLF/LF warnings, Docker or shell scripts fail with CRLF interpreter errors, or tracked text files may need repository line-ending policy or normalization review.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -30,6 +30,8 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 
 - Git reports CRLF, LF, or line-ending replacement warnings.
 - A diff or formatter appears to rewrite files only because of line endings.
+- Docker, Linux, WSL, CI, or shell execution fails with `bad interpreter`, `bash\r`, `env: ...\r`, `exec format error`, or similar CRLF-related symptoms.
+- A proposal suggests creating `.gitattributes`, running renormalization, or rewriting tracked files to fix cross-platform line endings.
 - A user asks why line-ending warnings appear.
 - A user asks to normalize tracked files to the repository line-ending policy.
 
@@ -46,6 +48,7 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 - The warning text or changed-file evidence.
 - Current `.gitattributes` or equivalent repository line-ending policy.
 - Current changed-file status.
+- Whether the request is diagnosis-only, policy authoring, or explicit tracked-file normalization.
 - The configured command intents for line-ending checks and manual normalization.
 
 <!-- mustflow-section: preconditions -->
@@ -62,6 +65,7 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 - Normalize tracked text files only when the user explicitly requests normalization and the repository declares an LF policy.
 - Do not rewrite binary files, generated archives, dependency folders, or unrelated source files.
 - Do not change formatting, indentation, or content while handling line endings.
+- Do not create `.gitattributes`, run repository-wide renormalization, or commit line-ending changes as an automatic fallback from a build, Docker, clone, scaffold, or script failure.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
@@ -69,15 +73,18 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 1. Inspect the changed-file status before deciding whether line endings are the actual issue.
 2. Use the `line_endings_check` intent when it is configured and agent-runnable.
 3. If no LF policy is declared, report the missing policy instead of normalizing files.
-4. If drift is found, report the affected tracked files and whether normalization was only previewed.
-5. Use normalization only after an explicit user request, and treat `line_endings_normalize` as manual-only unless the repository declares otherwise.
-6. After any normalization, re-run the line-ending check and a relevant validation intent for the touched scope.
-7. Keep the final report focused on policy, files changed, checks run, and remaining risk.
+4. If a runtime error mentions CRLF symptoms, classify it as a line-ending/platform issue before treating it as a missing executable, missing dependency, Docker image problem, or shell bug.
+5. If drift is found, report the affected tracked files and whether normalization was only previewed.
+6. If a policy file needs to be created or changed, keep that as an explicit policy change with reviewable scope. Do not smuggle a new repository-wide policy into an unrelated bug fix.
+7. Use normalization only after an explicit user request, and treat `line_endings_normalize` as manual-only unless the repository declares otherwise.
+8. After any normalization, re-run the line-ending check and a relevant validation intent for the touched scope.
+9. Keep the final report focused on policy, files changed, checks run, and remaining risk.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - The agent has not silently rewritten the working tree.
+- The agent has not silently created or changed a repository-wide line-ending policy.
 - Any normalization is tied to a declared repository policy.
 - Remaining CRLF, mixed line endings, missing policy, or manual-only command gaps are reported.
 
@@ -99,11 +106,13 @@ If normalization touched code, documentation, templates, or release surfaces, al
 - If a line-ending check fails because drift exists, do not treat it as a tool failure; report the affected files and next safe action.
 - If normalization fails, stop after the first relevant error and do not attempt broader formatting.
 - If the repository policy conflicts with user intent, ask for an explicit policy decision before editing.
+- If a fix would require repository-wide policy authoring or tracked-file renormalization, report the prerequisite unless the user explicitly requested that scope.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
 
 - Line-ending policy found
+- Policy changes made or deferred
 - Files with CRLF or mixed line endings
 - Files normalized
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/process-execution-safety/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.process-execution-safety
 locale: en
 canonical: true
-revision: 1
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: process-execution-safety
-description: Apply this skill when spawning, wrapping, previewing, timing out, terminating, buffering, streaming, or reporting child processes, built-in command reruns, shell commands, argv commands, environment variables, output limits, process trees, or long-running command patterns.
+description: Apply this skill when spawning, wrapping, previewing, timing out, terminating, buffering, streaming, classifying, or reporting child processes, built-in command reruns, shell commands, argv commands, environment variables, output limits, process trees, Git or package-manager failures, or long-running command patterns.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -32,6 +32,7 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 
 - Code spawns, wraps, previews, streams, buffers, times out, kills, reruns, or reports a child process or in-process built-in command.
 - A command path handles shell mode, argv mode, process groups, Windows task termination, POSIX signals, output limits, stdin, environment variables, or working directories.
+- Code invokes Git clone or checkout, package managers, project scaffolders, archive tools, build tools, test runners, Docker wrappers, or installers whose failures can be misclassified as network, token, auth, dependency, or unknown errors.
 - Long-running, background, watcher, server, browser, daemon, shell wrapper, package-manager, or project-local executable patterns are allowed, blocked, or classified.
 - Receipts, logs, verification, write tracking, or final reports depend on whether a command actually finished.
 
@@ -46,8 +47,10 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 ## Required Inputs
 
 - The execution path: shell, argv, built-in rerun, preview, dry run, JSON mode, streaming mode, or configured command intent.
-- Timeout, grace period, force-kill behavior, output limit, stdin policy, environment policy, working directory, process tree behavior, and receipt or write-tracking expectations.
+- Timeout, grace period, force-kill behavior, output limit, stdin policy, argv and shell command-length budget, environment policy, working directory, process tree behavior, and receipt or write-tracking expectations.
 - Platform boundary for Windows and POSIX process termination.
+- Failure classification rules for child-process output and exit causes, including filesystem/path, permission/lock, resource exhaustion, shell/environment, missing executable, network, token, auth, dependency, timeout, output overflow, and unknown categories.
+- For Git and scaffolding flows: clone or checkout destination, path-length policy, per-process Git config policy, partial-output owner, cleanup timing, and diagnostic-preservation expectations.
 - Existing tests for timeout, output overflow, environment redaction, local executable avoidance, command eligibility, and receipt status.
 - Relevant command-intent entries for related tests, release checks, and mustflow validation.
 
@@ -65,25 +68,40 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 - Prefer one execution path for JSON and human modes when output format alone should differ.
 - Do not bypass timeouts, output limits, working-directory checks, environment policy, or receipt generation for convenience.
 - Do not run unconfigured servers, watchers, background tasks, or interactive commands.
+- Do not use child-process code to apply privileged host repairs such as registry edits, global Git config, Developer Mode changes, WSL shutdown or mount edits, sysctl writes, Docker Desktop setting changes, antivirus exclusions, shell profile edits, or automatic commits unless an explicit configured command intent and user request authorize that setup operation.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
 
 1. Map the execution path from command contract to child process, output handling, receipt writing, write tracking, and final status.
 2. Confirm that shell and argv modes enforce the same safety boundary where they represent the same command intent.
-3. Check timeout semantics. A timeout should initiate termination, wait through the declared grace behavior when possible, attempt force termination when needed, and record whether cleanup was confirmed or still uncertain.
-4. Check output limit semantics. Output overflow should be distinct from process start failure, apply consistently across output modes, preserve bounded tails, and avoid unbounded memory growth.
-5. Check process-tree cleanup. On POSIX, account for process groups and signals. On Windows, account for task termination behavior and the fact that process-group semantics differ.
-6. Check in-process shortcuts. Built-in commands should not bypass timeout, output, environment, working-directory, or receipt policy unless the command contract explicitly accepts the weaker boundary.
-7. Check environment exposure. Minimal or allowlisted environments should be the default for agent-runnable commands, with redaction only as a logging safeguard, not as execution isolation.
-8. Check command eligibility before execution. Long-running and shell-wrapper patterns should be blocked or made manual-only before relying on timeout as the only defense.
-9. Check write tracking and receipts. Do not finalize a receipt or write-drift snapshot as complete while a child process may still be writing, unless the receipt states cleanup is unconfirmed.
-10. Add focused tests for timeout, output limit, environment, built-in rerun, local executable avoidance, and platform-neutral status semantics as justified by the change.
+3. Prefer argv execution over shell-string execution for dynamic commands. Do not build `exec("long command string")` or shell wrappers from repository paths, file lists, prompts, JSON, or user input when the tool can accept a file plus args, stdin, or an owned temporary parameter file.
+4. Keep large payloads out of argv and shell strings. Pass large JSON, file lists, AI prompts, generated context, and batch parameters through stdin or an owned temporary file with bounded lifetime, ownership, redaction, and cleanup policy.
+5. Classify command-length failures separately. Windows process creation, `cmd.exe`, POSIX `ARG_MAX`, shells, package managers, and wrapper scripts can fail at different limits; map these to `argv_too_long` or `shell_command_too_long` before retrying or reporting an unknown tool failure.
+6. In Node.js path handling around process execution, use explicit `path.win32` or `path.posix` behavior when parsing a path format that may differ from the host OS. Do not assume host-default `node:path` behavior proves cross-platform command construction.
+7. Check timeout semantics. A timeout should initiate termination, wait through the declared grace behavior when possible, attempt force termination when needed, and record whether cleanup was confirmed or still uncertain.
+8. Check output limit semantics. Output overflow should be distinct from process start failure, apply consistently across output modes, preserve bounded tails, and avoid unbounded memory growth.
+9. Check process-tree cleanup. On POSIX, account for process groups and signals. On Windows, account for task termination behavior and the fact that process-group semantics differ.
+10. Check in-process shortcuts. Built-in commands should not bypass timeout, output, environment, working-directory, or receipt policy unless the command contract explicitly accepts the weaker boundary.
+11. Check environment exposure. Minimal or allowlisted environments should be the default for agent-runnable commands, with redaction only as a logging safeguard, not as execution isolation.
+12. Check command eligibility before execution. Long-running and shell-wrapper patterns should be blocked or made manual-only before relying on timeout as the only defense.
+13. For Git clone or checkout on Windows, prefer argv mode with a per-process `core.longpaths=true` configuration when compatible. Do not mutate global Git config from product code unless the user explicitly selected that setup action.
+14. For Git, package-manager, and scaffolder materialization, coordinate with filesystem safety: preflight entries when feasible, run the dangerous operation only against an app-owned staging area, classify failure before cleanup, then delete only owned partial output.
+15. Classify child-process failures before retrying or reporting them. Separate filesystem/path, permission/lock, resource exhaustion, shell/environment, missing executable, network, token, auth, dependency, timeout, output overflow, argv length, shell command length, and unknown causes.
+16. Do not classify a Git checkout path failure as network, token, or auth merely because the top-level operation was clone. Output such as filename-too-long, invalid path, reserved name, permission denied, file locked, no space left, too many open files, watcher limit, bad interpreter, missing executable bit, argv-too-long, or shell-command-too-long should map to platform, filesystem, resource, or shell categories first.
+17. Preserve bounded stdout/stderr tails, exit status, signal, timeout status, cwd, argv summary, and cleanup status before deleting partial output from clone, checkout, scaffold, install, or archive-tool failures.
+18. Keep retry policy cause-aware. Retry transient locks or recoverable process cleanup only when bounded and idempotent; do not blindly retry auth, token, path-too-long, reserved-name, or destructive cleanup failures.
+19. Treat environment repair as a separate setup workflow, not as an invisible fallback inside clone, install, build, or test execution. Report missing host prerequisites and the blocked action rather than silently running privileged or global mutation commands.
+20. Check write tracking and receipts. Do not finalize a receipt or write-drift snapshot as complete while a child process may still be writing, unless the receipt states cleanup is unconfirmed.
+21. Add focused tests for timeout, output limit, environment, built-in rerun, local executable avoidance, failure classification, diagnostic preservation, partial-output cleanup, blocked host-repair fallback, and platform-neutral status semantics as justified by the change.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Execution status, timeout status, output status, cleanup status, receipt status, and write tracking tell the same story.
+- Child-process failures have cause-aware categories that separate filesystem/path, permission/lock, resource exhaustion, shell/environment, network, token, auth, dependency, timeout, output overflow, argv length, shell command length, and unknown causes.
+- Partial clone, checkout, scaffold, install, or archive outputs are cleaned up only after bounded diagnostics and app-owned staging or generated-state ownership are known.
+- Host repair commands are either modeled as explicit configured setup intents or reported as prerequisites, not hidden inside ordinary command execution.
 - JSON and human modes differ only in presentation unless a documented contract says otherwise.
 - Any unconfirmed cleanup or platform limitation is explicit in the report.
 
@@ -104,6 +122,8 @@ Escalate to broader configured tests when execution behavior crosses many comman
 ## Failure Handling
 
 - If a timed-out or output-limited process cannot be confirmed terminated, record the uncertainty and do not claim full cleanup.
+- If a child process fails after creating files, preserve bounded diagnostics and classify path/platform causes before deleting owned partial output or reporting a network, token, auth, dependency, or unknown failure.
+- If recovery would require privileged or global host mutation, stop and report the prerequisite instead of running the mutation as a fallback.
 - If environment isolation cannot be applied to a path, fail closed or route through a spawned process that can honor the contract.
 - If a platform-specific termination test is not available, report the skipped platform check and cover the shared status contract.
 - If a process safety fix conflicts with convenience or performance, preserve safety and report the tradeoff.
@@ -115,6 +135,8 @@ Escalate to broader configured tests when execution behavior crosses many comman
 - Timeout, force-kill, output-limit, environment, stdin, cwd, and process-tree boundaries
 - Receipt, write-tracking, and cleanup-confirmation behavior
 - Shell, argv, JSON, streaming, and built-in path consistency
+- Failure classification, retry policy, argv and shell length handling, diagnostic preservation, and partial-output cleanup behavior
+- Host repair prerequisites reported or deferred
 - Tests or fixtures added or reused
 - Command intents run
 - Remaining process execution risk

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

@@ -114,6 +114,12 @@ 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."api-contract-change"]
 category = "general_code"
 route_type = "primary"
@@ -348,6 +354,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"