mustflow 2.99.1 → 2.103.3

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.github-contribution-quality-gate
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: github-contribution-quality-gate
@@ -55,6 +55,9 @@ The goal is not polished prose. The goal is verified, scoped, actionable informa
 - 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.
 - Draft structure evidence: proposed title, first-screen summary, section headings, Markdown tables, task lists, code blocks, details blocks, screenshots, links, review order, and unresolved questions.
+- Pull request readiness evidence when relevant: whether the PR should be ready for review or draft,
+  whether the title follows repository style without agent/vendor prefixes, and whether any review
+  re-request is explicitly warranted.
 - 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.
 
@@ -97,13 +100,27 @@ The goal is not polished prose. The goal is verified, scoped, actionable informa
    - `same problem here` without new evidence is not new value.
 6. Plan the reading order before polishing prose.
    - Title should name the observed result for issues or the guaranteed behavior after a PR, not labels such as `[BUG]`, `fix`, `WIP`, or implementation chores.
+   - Do not add agent, assistant, vendor, or tool prefixes such as `[codex]`, `[AI]`, or `[bot]`
+     unless the target repository explicitly requires them. Prefer the repository's conventional
+     commit or title style so the changed behavior stays first.
    - First screen should contain conclusion, impact, and requested decision. Move long logs, full outputs, screenshots, and alternatives below or into `<details>`.
    - Headings should answer one question each. Avoid dump headings such as `Details`, `Misc`, `Notes`, or `Context` unless the repository template requires them.
    - Separate observed facts, current hypotheses, decisions, and unknowns. Use `Cause` only when the cause is confirmed.
 7. For bug issues, require actual behavior, expected behavior, exact reproduction steps, smallest reasonable reproduction, version, environment, relevant logs or screenshots, regression status, attempted workarounds, concrete impact, and completion criteria.
 8. For feature or enhancement issues, require user problem, affected users, current workflow, desired workflow, why existing behavior is insufficient, related discussions, compatibility impact, alternatives considered, and non-goals when the proposal can sprawl.
 9. 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.
-10. 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 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 a readiness decision.
+    - Use ready-for-review as the default for small, independent fixes or narrow improvements when
+      the relevant checks were run, known limitations can be stated in the PR body, and no
+      maintainer design decision is needed.
+    - Use draft only when the PR is intentionally discussion-first, changes public API shape, needs
+      design direction, has blocked or intentionally incomplete verification, or is likely to
+      conflict with other active work.
+    - If a draft PR becomes ready after verification, mark that transition in the PR body or update
+      comment instead of leaving the ready state implicit.
+    - Do not re-request review merely because a draft was marked ready. Re-request only when a
+      specific reviewer was already involved, the maintainer asked for it, or repository rules say
+      to request review after the ready transition.
 11. For PR review guidance, provide a review order by reasoning path rather than dumping changed files. Name files or commits only when they help reviewers inspect behavior, generated output, tests, or mechanical-only changes in the right order.
 12. 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.
 13. Use Markdown elements by job, not decoration.
@@ -134,7 +151,8 @@ The goal is not polished prose. The goal is verified, scoped, actionable informa
     - do not submit AI output that the human contributor has not reviewed, cannot explain, or could have tested but did not.
 18. 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;
+    - `POST_AS_DRAFT` when a PR direction is useful but not ready for final review, such as
+      discussion-first work, public API shape changes, blocked verification, or design approval;
     - `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.
@@ -149,6 +167,8 @@ The goal is not polished prose. The goal is verified, scoped, actionable informa
 - Duplicate search is summarized with confidence.
 - Every technical claim in the draft is tied to evidence or marked uncertain.
 - Title, first-screen summary, section order, Markdown elements, verification, and risk handling help maintainers decide what to do next.
+- PR readiness, draft state, and review-request behavior are chosen from evidence instead of using
+  draft or re-request as generic defaults.
 - 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.
@@ -185,10 +205,12 @@ Use `changes_status` and `changes_diff_summary` when drafting a PR description o
 - Duplicate and context check
 - Evidence checked
 - Information-structure and Markdown checks
+- PR title, readiness, and review-request decision when relevant
 - Missing evidence
 - Draft
 - Final self-check:
   - Does the title state the observed issue result or PR outcome instead of metadata?
+  - Does the PR title avoid agent, assistant, vendor, or tool prefixes unless the repository requires them?
   - Can a maintainer understand the conclusion, impact, and requested action from the first screen?
   - Do headings, tables, task lists, details blocks, code blocks, screenshots, and links each have one clear job?
   - Can a maintainer reproduce or review this without guessing?
@@ -197,6 +219,8 @@ Use `changes_status` and `changes_diff_summary` when drafting a PR description o
   - Is every technical claim backed by evidence?
   - Are facts, hypotheses, decisions, and unknowns separated?
   - Does a PR include review focus, verification results, unverified areas, and risk or rollback notes when relevant?
+  - Is a verified small PR ready for review instead of unnecessarily draft?
+  - If a draft PR became ready, is any review re-request justified by maintainer request, repository rules, or an already involved reviewer?
   - 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?

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.html-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: html-code-change
-description: Apply this skill when HTML, templates, JSX or component markup, native forms, controls, popovers, dialogs, navigation, tables, media, metadata, SEO head content, or structured data are created or changed.
+description: Apply this skill when HTML, templates, JSX or component markup, semantic document structure, native forms, controls, popovers, dialogs, navigation, tables, media, metadata, SEO head content, or structured data are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -47,6 +47,7 @@ Preserve semantic structure, native controls, keyboard access, focus behavior, f
 
 - Existing page layout, document shell, head/SEO helpers, metadata builders, canonical URL helpers, sitemap or robots config, form components, interactive control components, and tests.
 - Target framework conventions for rendering, routing, hydration, and metadata.
+- Semantic structure ledger: the intended `main`, landmark, heading, `section`, `article`, `nav`, `time`, `figure`, form group, table, media, and visible-label contracts.
 - Visible page content, H1 or primary title, main entity, locale, indexing intent, and data sources for title, description, image, author, date, price, rating, availability, and FAQ content when metadata changes.
 - Browser-native behavior expected from the markup: navigation, form submission, validation, autocomplete, input modality, popover behavior, dialog focus, inert background handling, media sizing, lazy loading, and history integration.
 - Accessibility and validation tooling declared in the command contract.
@@ -73,25 +74,37 @@ Preserve semantic structure, native controls, keyboard access, focus behavior, f
 
 1. Read the page shell, route layout, metadata helpers, component patterns, and tests before editing.
 2. Check document outline, landmarks, source order, and heading levels.
-3. Classify each interactive element by intent. Navigation to a URL uses an anchor with `href`. Commands, toggles, submit actions, open/close actions, destructive actions, copy actions, disclosure triggers, and modal triggers use buttons.
-4. Use native form controls for text entry, selection, checkbox, radio, and file input. Use grouped native radio or checkbox controls with fieldset and legend when the group label matters.
-5. Treat composite widgets such as tabs, action menus, comboboxes, listboxes, trees, grids, and custom selects as high-risk. Prefer native HTML or an existing audited component; otherwise implement the complete role, state, focus, and keyboard pattern.
-6. Reject clickable `div` or `span` controls, clickable icons without buttons, anchors without `href`, links used as buttons, nested interactive controls, positive `tabindex`, focusable `aria-hidden` content, and focus outline removal without a replacement focus style.
-7. Use ARIA only when native HTML cannot express the needed semantics. Validate the role is legal for the element, the accessible name exists, required states are present, visual and ARIA states stay synchronized, keyboard behavior matches the widget pattern, and focus behavior is explicit.
-8. For custom legacy button-like elements that cannot be replaced, require `role`, focusability, Enter activation, Space activation, Space scroll prevention, pointer activation, duplicate-event prevention, and visible focus. Use native buttons instead whenever possible.
-9. For popovers, prefer the native popover pattern for lightweight anchored disclosure, teaching UI, picker panels, or menus that do not need modal focus trapping. Verify trigger ownership, light-dismiss behavior, focus behavior, accessible name, and fallback or browser target.
-10. For dialogs, prefer native dialog when the project can support it. Otherwise implement focus entry, Tab and Shift+Tab containment, Escape behavior, inert or unreachable background content, visible close or cancel control, focus return, and an accessible name.
-11. Do not use dialog for every overlay. Use popover for non-modal transient UI, details/summary for simple disclosure, and dialog for modal tasks or interruptions that require focus containment.
-12. For tabs, use tablist, tab, and tabpanel semantics only for a real tabbed interface. Require one active tab, panel linkage, roving tabindex, arrow key movement, Home and End where expected, and Enter or Space activation when activation is manual.
-13. For menus, do not use ARIA menu roles for ordinary site navigation. Site navigation is a nav landmark with links. Use ARIA menu patterns only for application-style action menus with a button trigger, expanded state, focus strategy, Escape close behavior, and focus return.
-14. For forms, verify visible label association, help association, error association, required text, native required state, autocomplete, `inputmode`, `enterkeyhint`, validation timing, invalid state, error summary behavior, and submission behavior.
-15. Prefer native constraint validation for simple required, type, length, pattern, range, and step rules. Add custom validation only for business rules, cross-field rules, async validation, or localized error ownership the native browser cannot express.
-16. Use placeholder, title, aria-label, color, icon, or toast-only feedback only as supplementary affordances, not as the only label, required indicator, or error explanation.
-17. For metadata, read visible content and the metadata generation path first. Keep title, description, canonical, Open Graph, Twitter or X card data, robots, hreflang, and JSON-LD aligned with visible content, locale, URL, and indexing intent.
-18. Structured data must describe content visible on the same page. Do not invent ratings, reviews, FAQ items, authors, prices, availability, dates, organizations, product properties, or claims not backed by the page data source.
-19. Ensure every HTML page has a valid non-empty language and responsive viewport that does not disable zoom. Mixed-language passages should identify their language when needed.
-20. Keep inline script and style minimal; move behavior and styling to the existing project layers unless the framework requires an inline boundary.
-21. Choose configured verification intents that cover markup validity, lint, build, accessibility, route rendering, metadata, and docs when available.
+3. Treat semantic HTML as a machine-readable contract, not as styling decoration. Use `div` for pure wrappers and styling shells.
+4. Use `section` only for a thematic group that has a heading or explicit accessible label. Do not use `section` as a card, spacing, or script wrapper.
+5. Use `article` only for self-contained content that remains meaningful when syndicated, embedded, or moved out of the list, such as posts, articles, reviews, comments, or complete product entries.
+6. Use `nav` only for major navigation or table-of-contents regions. Do not label every incidental link group as navigation.
+7. Keep exactly one active visible `main` region for the page or current SPA view. Do not put repeated headers, footers, sidebars, or global navigation inside the main content unless that is the actual page task.
+8. Treat heading elements as content outline, not font-size controls. Preserve hierarchy by meaning, and use CSS for visual scale.
+9. Classify each interactive element by intent. Navigation to a URL uses an anchor with `href`. Commands, toggles, submit actions, open/close actions, destructive actions, copy actions, disclosure triggers, and modal triggers use buttons.
+10. Use native form controls for text entry, selection, checkbox, radio, and file input. Use grouped native radio or checkbox controls with fieldset and legend when the group label matters.
+11. Keep interactive elements out of labels. Do not place terms links, help buttons, or other controls inside a `label`; connect the label with `for` and `id`, then place related links or buttons outside the label.
+12. Treat composite widgets such as tabs, action menus, comboboxes, listboxes, trees, grids, and custom selects as high-risk. Prefer native HTML or an existing audited component; otherwise implement the complete role, state, focus, and keyboard pattern.
+13. Reject clickable `div` or `span` controls, clickable icons without buttons, anchors without `href`, links used as buttons, nested interactive controls, positive `tabindex`, focusable `aria-hidden` content, and focus outline removal without a replacement focus style.
+14. Use ARIA only when native HTML cannot express the needed semantics. Validate the role is legal for the element, the accessible name exists, required states are present, visual and ARIA states stay synchronized, keyboard behavior matches the widget pattern, and focus behavior is explicit.
+15. For custom legacy button-like elements that cannot be replaced, require `role`, focusability, Enter activation, Space activation, Space scroll prevention, pointer activation, duplicate-event prevention, and visible focus. Use native buttons instead whenever possible.
+16. For popovers, prefer the native popover pattern for lightweight anchored disclosure, teaching UI, picker panels, or menus that do not need modal focus trapping. Verify trigger ownership, light-dismiss behavior, focus behavior, accessible name, and fallback or browser target.
+17. For dialogs, prefer native dialog when the project can support it. Otherwise implement focus entry, Tab and Shift+Tab containment, Escape behavior, inert or unreachable background content, visible close or cancel control, focus return, and an accessible name.
+18. Do not use dialog for every overlay. Use popover for non-modal transient UI, details/summary for simple disclosure, and dialog for modal tasks or interruptions that require focus containment.
+19. For tabs, use tablist, tab, and tabpanel semantics only for a real tabbed interface. Require one active tab, panel linkage, roving tabindex, arrow key movement, Home and End where expected, and Enter or Space activation when activation is manual.
+20. For menus, do not use ARIA menu roles for ordinary site navigation. Site navigation is a nav landmark with links. Use ARIA menu patterns only for application-style action menus with a button trigger, expanded state, focus strategy, Escape close behavior, and focus return.
+21. For forms, verify visible label association, help association, error association, required text, native required state, autocomplete, `inputmode`, `enterkeyhint`, validation timing, invalid state, error summary behavior, and submission behavior.
+22. Prefer native constraint validation for simple required, type, length, pattern, range, and step rules. Add custom validation only for business rules, cross-field rules, async validation, or localized error ownership the native browser cannot express.
+23. Use placeholder, title, aria-label, color, icon, or toast-only feedback only as supplementary affordances, not as the only label, required indicator, or error explanation.
+24. Use `time` with a machine-readable `datetime` when the content represents a precise date, time, duration, or time-like value that tests, crawlers, calendars, or automation may need to parse.
+25. Use `figure` and `figcaption` only for self-contained referenced media, code, diagrams, charts, screenshots, or examples whose caption describes the figure. Do not use `figcaption` for ordinary card titles or unrelated image captions.
+26. Use real tables for tabular data. Include a useful `caption` when the table needs a name, use `th` for row and column headers, and set `scope` when it clarifies the header relationship.
+27. For meaningful media, prefer `img`, `picture`, `video`, or framework media components that preserve alt text, intrinsic dimensions, responsive candidate selection, and browser discovery. Keep decorative media out of the accessibility tree.
+28. For responsive image markup, verify `width`, `height`, `srcset`, `sizes`, `picture` art direction, and lazy or eager loading reflect the rendered slot. Route LCP, preload, priority, CDN, or byte-size claims to `image-delivery-performance-review`.
+29. For metadata, read visible content and the metadata generation path first. Keep title, description, canonical, Open Graph, Twitter or X card data, robots, hreflang, and JSON-LD aligned with visible content, locale, URL, and indexing intent.
+30. Structured data must describe content visible on the same page. Do not invent ratings, reviews, FAQ items, authors, prices, availability, dates, organizations, product properties, or claims not backed by the page data source.
+31. Ensure every HTML page has a valid non-empty language and responsive viewport that does not disable zoom. Mixed-language passages should identify their language when needed.
+32. Keep inline script and style minimal; move behavior and styling to the existing project layers unless the framework requires an inline boundary.
+33. Choose configured verification intents that cover markup validity, lint, build, accessibility, route rendering, metadata, and docs when available.
 
 <!-- mustflow-section: form-accessibility -->
 ## Form Accessibility Rules
@@ -128,16 +141,19 @@ Reject or revise the patch when any of these appear without strong justification
 
 - New `div` or `span` interaction where a native link, button, or form control would work.
 - Anchors without `href`, buttons implemented as links, links implemented as buttons, nested interactive controls, clickable icons without native controls, or site navigation using ARIA menu roles.
+- Decorative `section`, card-only `article`, incidental-link `nav`, multiple active `main` regions, headings chosen for visual size, labels containing nested interactive controls, or data tables rebuilt as non-table grids.
 - Custom controls without complete accessible name, role, state, keyboard, focus, and hidden-content behavior.
 - Popovers, dialogs, or overlays that replace native behavior without trigger, focus, light-dismiss, inert, or fallback review.
 - Positive `tabindex`, hidden content that remains tabbable, focusable `aria-hidden` content, or invisible focus.
 - Form controls without visible labels, placeholder-only labels, disconnected help or error text, color-only required or error state, premature `aria-invalid`, or autocomplete removed without reason.
+- Meaningful dates without parseable `time datetime`, figures used for ordinary card content, tables without header relationships, or meaningful media that lacks alt, intrinsic dimensions, or responsive candidate review.
 - Metadata or JSON-LD that contradicts visible content, fabricates facts, points canonical or social URL at the wrong page, disables zoom, omits page language, or accidentally noindexes a public page.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Markup communicates the intended structure without relying on visual styling alone.
+- Sections, articles, navigation, main regions, headings, forms, figures, tables, time values, and media expose truthful document semantics.
 - Keyboard and focus behavior are preserved.
 - Forms have labels and errors connected.
 - Metadata and structured data reflect visible content.

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

@@ -0,0 +1,278 @@
+---
+mustflow_doc: skill.react-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: react-code-change
+description: Apply this skill when React, React DOM, React Server Components, Server Actions, React Compiler, Hooks, Suspense, Actions, forms, refs, context, concurrent rendering, SSR streaming, resource hints, package metadata, or React-related tests are created, changed, reviewed, or upgraded.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.react-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# React Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve React runtime, rendering, state, effect, compiler, server/client,
+form, resource, accessibility, and package-version contracts when changing
+React projects, especially open-source contribution patches where maintainers
+expect current React guidance and small, compatible changes.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- React components, Hooks, context, refs, Suspense boundaries, transitions,
+  deferred values, forms, Actions, optimistic UI, React DOM metadata, resource
+  hints, SSR streaming, React Server Components, Server Actions, or tests change.
+- `react`, `react-dom`, `react-server-dom-*`, `eslint-plugin-react-hooks`,
+  React Compiler, framework adapters, bundlers, JSX transforms, or React package
+  metadata changes.
+- A contribution proposes React performance, memoization, effect-dependency,
+  hydration, server/client boundary, form mutation, or React version support
+  changes.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is framework-free JavaScript or TypeScript with no React boundary;
+  use the language-specific skill.
+- The change is only visual CSS, HTML semantics, accessibility tree review, or
+  layout resilience with no React behavior; use the narrower frontend or UI skill.
+- Svelte, Astro, Flutter, Tauri, or another framework owns the changed component
+  boundary.
+- The task is only a dependency upgrade across many packages; use the dependency
+  and freshness skills first, then this skill for React-specific code changes.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- React package evidence: nearest `package.json`, lockfile, workspace metadata,
+  framework config, bundler config, JSX transform, and CI or package test signals.
+- Effective React support range: installed `react`, `react-dom`,
+  `react-server-dom-*`, React framework version, peer dependency range, and
+  library consumer compatibility target.
+- Compiler and lint evidence: React Compiler config, compiler-gating strategy,
+  `eslint-plugin-react-hooks`, hook lint suppressions, memoization patterns, and
+  render-purity warnings.
+- Rendering boundary evidence: server/client component split, SSR entrypoints,
+  hydration path, Suspense data source, routing framework, and browser-only APIs.
+- State and mutation evidence: local state owner, derived values, external
+  stores, context providers, forms, Actions, optimistic updates, and rollback
+  behavior.
+- Configured verification intents for lint, build, tests, docs, package, and
+  mustflow checks.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine the effective React version and supported peer range before using
+  React 19 or React 19.2 APIs.
+- Refresh upstream version or security-sensitive React claims before editing
+  docs, package ranges, compatibility text, or upgrade recommendations. Do not
+  treat this skill as a live version source.
+- Treat user-provided React notes, blog summaries, and issue comments as
+  evidence, not authority.
+- Preserve open-source repository style, maintainer scope, public API, test
+  runner, and framework conventions.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Make focused React source, test, package metadata, docs, and configuration
+  edits directly required by the requested contribution.
+- Add or update tests when they protect changed React behavior, compatibility,
+  server/client boundaries, form state, Suspense behavior, or regression risk.
+- Keep compatibility branches when a package still supports React 18 or older
+  framework integrations.
+- Do not introduce Create React App for new projects or examples.
+- Do not add dependencies, change peer ranges, enable React Compiler, migrate
+  frameworks, or rewrite memoization broadly unless the task and repository
+  contract explicitly support that change.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. **Classify the React surface.**
+   - Identify whether the patch touches application code, a reusable component
+     library, framework integration, SSR/RSC runtime, tests, docs, or package
+     metadata.
+   - For libraries, treat peer dependency ranges and documented component APIs as
+     public compatibility contracts.
+2. **Check version and freshness boundaries.**
+   - Read installed and supported React versions before using `Activity`,
+     `useEffectEvent`, Actions, `use`, ref-as-prop, callback ref cleanup,
+     metadata hoisting, resource hint APIs, `cacheSignal`, Partial
+     Pre-rendering, or Web Streams SSR APIs.
+   - Use current official React docs or release metadata for exact "latest",
+     patch, security, or deprecation claims. As a snapshot checked on
+     2026-06-26, official React docs describe React 19.2 as the current
+     feature line, and GitHub release metadata showed `v19.2.7` released on
+     2026-06-01; re-check before relying on those values in future work.
+   - For RSC packages, check patched `react-server-dom-webpack`,
+     `react-server-dom-parcel`, and `react-server-dom-turbopack` versions when
+     security advisories or framework updates are part of the task.
+3. **Keep app setup modern and local.**
+   - Do not propose Create React App for new projects. Follow the repository's
+     existing framework or build tool; for new React app examples, prefer the
+     project's chosen framework or modern build-tool pattern.
+   - Do not migrate an existing stack to Next.js, Vite, Parcel, Rsbuild, or a
+     React framework merely because React documentation recommends frameworks
+     for new apps.
+4. **Repair effects by responsibility.**
+   - Use Effects for synchronization with external systems such as timers,
+     subscriptions, DOM or browser APIs, third-party widgets, network
+     connections, and cleanup.
+   - Do not use Effects to copy props/state into derived state, send event-owned
+     mutations, or paper over rendering data flow.
+   - Do not silence `react-hooks/exhaustive-deps` as a default fix. If effect
+     logic contains non-reactive event behavior and React 19.2 is supported, use
+     `useEffectEvent` for that event-like logic only.
+5. **Preserve state ownership.**
+   - Derive renderable values during render when they are computed from current
+     props or state.
+   - Use updater functions for repeated state updates based on the previous
+     value.
+   - Normalize state that can otherwise contradict itself. Avoid duplicated,
+     deeply nested, or derived state unless the repository has a clear owner.
+   - Use `key` for intentional component state reset, and keep component
+     functions at top level so React does not recreate component types on every
+     render.
+6. **Treat memoization and the compiler as contracts, not decoration.**
+   - Do not blanket-add `memo`, `useMemo`, or `useCallback` to look faster.
+     Require profiler, dependency, identity, or compiler evidence.
+   - Do not blanket-remove existing memoization in legacy code without tests;
+     removal can change identity, effect dependencies, and compiler output.
+   - If React Compiler is enabled or proposed, keep components and Hooks pure,
+     keep compiler-powered `eslint-plugin-react-hooks` findings visible, and
+     report when compiler verification is missing.
+7. **Handle context, refs, and external stores deliberately.**
+   - Split frequently changing context values from stable actions or identities;
+     `memo` does not block re-renders caused by context updates.
+   - Use React 19 ref-as-prop and callback-ref cleanup only when the support
+     range allows it. Preserve `forwardRef` where React 18 compatibility matters.
+   - Expose narrow imperative handles with `useImperativeHandle` instead of
+     leaking whole DOM nodes or child internals.
+   - Use `useSyncExternalStore` for external mutable stores or subscriptions
+     instead of ad hoc Effect plus state mirroring.
+8. **Use concurrent and async primitives for the right boundary.**
+   - Use `startTransition` or `useTransition` for non-urgent updates, but do not
+     control text input values through a transition.
+   - Use `useDeferredValue` when stale-but-responsive derived UI is acceptable;
+     use the `initialValue` form only when the React version supports it.
+   - Do not expect Suspense to catch ordinary Effect fetches. Suspense needs
+     lazy code, framework data, or cached Promise reads.
+   - Treat `use` as render-time Promise or context reading, not a normal Hook
+     with the ordinary top-level-only mental model. Do not create fresh Promises
+     in render and pass them to `use`.
+9. **Use React 19 form and Action APIs only when supported.**
+   - Prefer `useActionState`, `useFormStatus`, `useOptimistic`, `<form action>`,
+     and `formAction` for supported React 19 mutation flows with pending,
+     errors, resets, progressive enhancement, and rollback.
+   - Keep explicit error handling, authorization, validation, idempotency, and
+     rollback behavior. Do not hide server failures behind optimistic UI.
+10. **Respect React 19.2 rendering and performance APIs.**
+    - Treat `<Activity>` as hidden UI with preserved state, unmounted effects,
+      and lower-priority hidden updates, not as `display: none` or ordinary
+      conditional rendering.
+    - Use React Performance Tracks, React DevTools, or existing profiler evidence
+      when claiming render, effect, Scheduler, transition, or component
+      performance improvements.
+11. **Keep server rendering and RSC boundaries exact.**
+    - Distinguish Server Components from Server Actions. `"use server"` marks
+      server functions or modules for actions; it is not a Server Component tag.
+    - Keep browser APIs, client state, and event handlers out of Server
+      Components; keep secrets and server-only imports out of Client Components.
+    - Use `cacheSignal` only for RSC cached work where abort or cleanup is
+      meaningful.
+    - For Partial Pre-rendering, `prerender`, `resume`, `resumeAndPrerender`,
+      and streaming APIs, verify the framework/runtime owns those APIs before
+      changing lower-level React DOM server code.
+    - In Node environments, do not assume Web Streams are faster than Node
+      streams; preserve the existing SSR stream API unless the task proves the
+      runtime benefit and compression behavior.
+12. **Use React DOM document and resource APIs close to the owner.**
+    - Metadata, stylesheets with `precedence`, async scripts, `preinit`,
+      `preload`, `preconnect`, and `prefetchDNS` may belong near the component
+      that needs them when React and the framework support that behavior.
+    - Avoid duplicate head managers, resource hint spam, and hints for assets
+      whose timing or priority is unproven.
+13. **Verify through the repository contract.**
+    - Run the smallest configured checks that cover changed React code, package
+      metadata, build output, docs, and tests.
+    - Report missing browser, hydration, SSR, RSC, compiler, profiler, or
+      cross-version React verification when those surfaces changed.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Effective React version, peer range, framework ownership, and compiler/lint
+  status are known or explicitly reported as unknown.
+- Effects, state, memoization, context, refs, forms, Suspense, and async
+  boundaries follow React's current model for the supported version.
+- React 19 and React 19.2 APIs are not introduced into code that still promises
+  older React compatibility.
+- SSR, RSC, Server Action, browser-only, and resource-hint boundaries are
+  preserved.
+- Performance claims have profiler or benchmark evidence, or are reported as
+  unverified.
+
+<!-- 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 React-version matrix, browser automation, hydration, SSR/RSC,
+Compiler, performance profiling, or package-consumer verification when those
+surfaces changed.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If React version evidence conflicts, do not assume the newest API is
+  available. Preserve the older-compatible path or report the compatibility
+  decision.
+- If an effect dependency fix causes reconnects, stale closures, or event logic
+  churn, separate reactive synchronization from event-like behavior instead of
+  disabling lint.
+- If a compiler or memoization change shifts behavior, restore the previous
+  identity boundary or add focused evidence before continuing.
+- If Suspense, `use`, Actions, or RSC behavior is framework-owned, read the
+  framework boundary before editing raw React assumptions.
+- If freshness checks are unavailable for a React release, security patch, or
+  deprecation claim, avoid embedding exact "latest" wording and report the gap.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- React surface and supported version checked
+- Compiler, lint, effect, state, memoization, context, ref, form, Suspense, SSR,
+  RSC, and resource-boundary notes
+- Freshness-sensitive React claims checked or left conservative
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining React compatibility or verification risk

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

@@ -150,6 +150,12 @@ route_type = "primary"
 priority = 50
 applies_to_reasons = ["unknown_change", "docs_change", "mustflow_docs_change", "workflow_change", "product_change"]
 
+[routes."complex-decision-analysis"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 45
+applies_to_reasons = ["unknown_change", "product_change", "cross_cutting_code_change"]
+
 [routes."codebase-orientation"]
 category = "general_code"
 route_type = "primary"
@@ -426,6 +432,24 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
 
+[routes."c-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "performance_change", "security_change", "package_metadata_change", "release_risk"]
+
+[routes."shell-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "docs_change", "workflow_change", "security_change", "package_metadata_change", "release_risk"]
+
+[routes."structured-config-change"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 84
+applies_to_reasons = ["code_change", "docs_change", "workflow_change", "mustflow_config_change", "package_metadata_change", "test_change", "security_change", "release_risk"]
+
 [routes."node-code-change"]
 category = "general_code"
 route_type = "primary"
@@ -960,6 +984,12 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["ui_change", "docs_change", "code_change", "behavior_change", "migration_change", "package_metadata_change"]
 
+[routes."react-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "code_change", "behavior_change", "public_api_change", "data_change", "security_change", "privacy_change", "performance_change", "test_change", "package_metadata_change", "release_risk"]
+
 [routes."svelte-code-change"]
 category = "ui_assets"
 route_type = "primary"