mustflow 1.15.97

package/templates/default/locales/hi/.mustflow/skills/date-number-audit/SKILL.md

@@ -0,0 +1,116 @@
+---
+mustflow_doc: skill.date-number-audit
+locale: hi
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: date-number-audit
+description: Apply this skill when a task creates, edits, or reports dates, versions, counts, durations, limits, metrics, benchmarks, prices, percentages, or other numeric facts.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.date-number-audit
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Date and Number Audit
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Prevent code, docs, tests, and final reports from inventing, copying stale, or mis-synchronizing dates and numeric facts.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A change adds, edits, removes, or reports a date, deadline, release version, count, duration, timeout, limit, quota, size, percentage, price, benchmark, score, coverage value, or generated-file total.
+- Documentation summarizes how many commands, files, pages, templates, locales, tests, checks, or supported items exist.
+- A final report or user-facing message depends on a number that may drift after code, template, package, docs, or generated-output changes.
+- A failing check suggests a stale revision, mismatched version, wrong count, outdated date, or inconsistent numeric threshold.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The number is a local variable, loop index, enum value, or test fixture with no public or cross-file meaning.
+- The task only preserves existing numeric text without relying on it.
+- A specialized skill for release versioning, dependency reality, artifact integrity, or source freshness is the narrower match.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The date or numeric fact and every surface that states, derives, or validates it.
+- The source of truth for the value, such as package metadata, template metadata, schema, code constant, generated output, test assertion, or current command result.
+- The acceptable precision and wording when a value is approximate, sampled, local-only, or time-sensitive.
+- Relevant command-intent contract entries for docs, packaging, build, or mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Align dates and numeric facts across source files, generated metadata, tests, documentation, and final reports.
+- Replace exact numbers with bounded or source-linked wording when exactness is not stable.
+- Do not invent a number to make a document feel complete.
+- Do not change behavior thresholds, timeouts, limits, or release versions unless the task and source of truth support the change.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. List the date or numeric facts that the task creates, edits, or reports.
+2. Identify the source of truth for each value before changing dependent surfaces.
+3. Search related code, templates, docs, schemas, tests, and generated metadata for duplicate statements of the same value.
+4. Update dependent surfaces from the source of truth, or mark the value as approximate, local, sampled, or unverified when exact verification is unavailable.
+5. Keep version numbers, template revisions, schema revisions, locale source revisions, package assertions, and public examples synchronized.
+6. Prefer phrasing such as "about", "currently", "at the time of this check", or "from the latest generated output" only when that uncertainty is true and useful.
+7. Run the narrowest configured verification that proves the value and dependent surfaces still agree.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every public or cross-file date and numeric fact has a named source of truth or an explicit uncertainty note.
+- Tests and metadata that assert numbers are synchronized with the changed source.
+- The final report names any values that were intentionally left approximate or unverified.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use a narrower configured test, build, or docs intent when it better proves the changed numeric surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If two sources disagree, do not guess. Identify the higher-authority source or report the conflict.
+- If a value depends on time, network state, package registry state, generated output, or external data that was not refreshed, state that boundary.
+- If an exact number is unnecessary and expensive to keep current, rewrite the statement to avoid brittle precision.
+- If changing a number affects behavior, activate the relevant code, test, release, or dependency skill before continuing.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Dates or numeric facts audited
+- Source of truth for each value
+- Surfaces synchronized
+- Exact values changed or made approximate
+- Command intents run
+- Skipped checks and reasons
+- Remaining date or numeric risk

package/templates/default/locales/hi/.mustflow/skills/dependency-injection/SKILL.md

@@ -0,0 +1,161 @@
+---
+mustflow_doc: skill.dependency-injection
+locale: hi
+canonical: false
+revision: 3
+lifecycle: mustflow-owned
+authority: procedure
+name: dependency-injection
+description: Apply this skill when core or application logic creates, imports, resolves, or hides external dependencies such as databases, APIs, SDKs, filesystems, clocks, random generators, identifiers, loggers, configuration, framework request objects, AI clients, queues, or payment/email providers.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.dependency-injection
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Dependency Injection
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep business logic from creating, finding, or importing the tools it needs. External-world objects belong at assembly boundaries; core logic receives narrow ports, explicit values, or request context from the outside.
+
+Dependency injection is not an abstraction quota. Use it to keep replaceable infrastructure, hidden global state, and side effects from leaking into domain and use-case code.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Core, domain, application, service, or use-case code directly constructs a database client, external SDK, queue, file storage, logger, clock, random generator, identifier generator, AI model client, email sender, payment gateway, HTTP client, or framework object.
+- Code reads `process.env`, current time, random values, UUIDs, files, local storage, global containers, or global loggers away from the assembly boundary.
+- A refactor aims to make behavior easier to test without real databases, network calls, API keys, filesystem writes, current time, or random identifiers.
+- New ports, adapters, provider modules, transaction runners, or composition roots are being introduced.
+- A function's signature hides required collaborators or accepts broad technical objects instead of the narrow capability it actually needs.
+- An optional collaborator should be wired as a real implementation or a safe null, no-op, disabled, identity, empty, deny-all, or failing implementation at the assembly boundary.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The code is a pure function, value object, entity constructor, small data formatter, or internal helper with no external dependency.
+- The task is a disposable one-off script that is not imported, tested, repeated, used in production, or connected to external services.
+- A framework's dependency injection mechanism is already confined to the application boundary and does not leak into domain code.
+- The only change needed is to confirm a package or tool exists; use `dependency-reality-check`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The target code area and the direct dependency, global state, or hidden collaborator being introduced or removed.
+- The intended business capability and which layer owns the rule: domain, application, infrastructure, adapter, route, worker, or assembly root.
+- Existing local patterns for ports, adapters, fakes, transaction runners, clocks, configuration loading, and test setup.
+- Current changed files and command-intent contract entries relevant to tests, builds, docs, release metadata, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- If the local structure is unfamiliar, use `pattern-scout` or `codebase-orientation` before introducing new folders or naming conventions.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Define narrow consumer-owned ports where core logic needs external behavior.
+- Move concrete client creation, environment reads, lifecycle setup, and disposal to assembly boundaries.
+- Add infrastructure adapters that implement the ports and translate external rows, responses, errors, and identifiers into internal types.
+- Add local fakes, fixed clocks, fixed identifiers, and contract tests when needed to preserve behavior.
+- Wire optional collaborators with `null-object-pattern` when absence is explicit, safe, and should not leak nullable checks into business logic.
+- Do not add a service locator, global container access, broad application dependency bag, framework decorator in domain code, or speculative interface for every class.
+- When the dependency also crosses an external protocol, provider, database, webhook, queue, file, cache, AI model, or framework boundary, use `adapter-boundary` for the translation and failure-handling rules.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the code under change:
+   - Core logic: domain rules, use cases, state transitions, policy checks, calculations, and business decisions.
+   - Edge logic: routes, controllers, workers, command handlers, adapters, repositories, SDK wrappers, and assembly roots.
+2. Find direct external dependencies before editing. Look for concrete SDK construction, database clients, HTTP clients, file APIs, environment reads, current-time calls, random or UUID generation, global loggers, global containers, framework request or response objects, and external error types.
+3. Decide whether dependency injection is warranted. Inject only collaborators that cross a boundary, are hard to test, may change implementation, or represent hidden global state. Do not wrap pure helpers, value objects, or stable internal data structures just to add ceremony.
+4. Define ports from the consumer's need, not from the provider's API.
+   - Prefer `PaymentGateway`, `UserRepository`, `EmailSender`, `ImageStorage`, or `TextGenerator`.
+   - Avoid provider-shaped ports such as `StripeService`, `PrismaUserStore`, `ResendMailer`, `S3ImageStorage`, or `OpenAITextGenerator` at the core boundary.
+5. Choose the injection style:
+   - Use constructor injection or a dependency object for classes with stable collaborators.
+   - Use function-closure injection for small use cases or function-oriented modules.
+   - Use method parameters for per-call data such as actor, tenant, locale, request id, pagination, filters, or command input.
+   - Use factories only when runtime values decide the implementation, lifecycle, or resource handle.
+6. Keep construction at the assembly boundary. Create concrete clients, load and validate configuration, register containers, open connections, and wire adapters in files such as bootstrap, server setup, worker setup, route setup, module registration, or test setup.
+   - If a dependency is optional and disabled by explicit configuration, choose the real collaborator or the safe neutral implementation here, not inside business logic.
+   - If a dependency is required, validate configuration here and fail early instead of injecting a null object.
+7. Treat time, random values, identifiers, configuration, logging, transactions, and framework objects as dependencies.
+   - For domain decisions, prefer an already captured instant or time context over passing a clock that can be queried inside the domain.
+   - Pass fixed implementations in tests so time, identifiers, and random choices are reproducible.
+8. Keep adapters responsible for translation. Repositories and provider adapters should convert database rows, external responses, external errors, and provider identifiers before returning to core logic.
+9. If the injected collaborator is an external boundary, apply `adapter-boundary` before finalizing the port and adapter. Dependency injection decides how core logic receives the collaborator; adapter boundaries decide how external protocols, data, errors, timeouts, retries, idempotency, security, and observability are translated.
+10. Keep transaction ownership explicit. Inject a transaction runner when a use case needs atomic persistence across multiple repositories. Do not hide transaction boundaries inside repositories when the use case owns the unit of work, and do not call external APIs inside a database transaction.
+11. Reject hidden dependency patterns:
+    - no property injection for required collaborators
+    - no service locator or `container.resolve` in core logic
+    - no process-wide mutable singleton holding request state
+    - no broad `AppDeps` object when a use case needs only a few collaborators
+    - no circular service dependencies unless a smaller use case, shared policy, or event boundary has been considered first
+12. Keep tests honest. Unit tests for core logic should use fakes or fixed collaborators and should not require a real database, real network, real API key, real email, real payment, real filesystem side effect, current time, or random UUID. Test real adapters separately with integration or contract coverage.
+13. Verify with the narrowest configured command intents that cover the changed code, tests, template files, docs, and release metadata.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Core logic declares its collaborators through constructor parameters, function parameters, or narrow context objects.
+- Concrete external implementation creation is easy to find at assembly boundaries.
+- Core logic does not import provider SDKs, database clients, framework request or response objects, global containers, or external provider error types.
+- Tests can replace external collaborators, time, identifiers, and random values without live infrastructure.
+- Adapter boundaries translate external data and failures before they reach core logic.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `test_related`
+- `test`
+- `lint`
+- `build`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured test or build intent that proves the affected boundary. Use documentation and release checks when templates, skill routes, public docs, package metadata, or installed-file surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If extracting a port would duplicate an existing local interface, reuse or narrow the existing local pattern instead of creating a parallel abstraction.
+- If a class needs many collaborators, stop before adding a giant dependency object and look for mixed responsibilities, smaller use cases, or adapter boundaries.
+- If a framework forces decorators or container registration, keep that integration in the application boundary and do not let it shape domain types.
+- If a direct dependency cannot be removed in one safe step, first wrap it at the smallest local boundary and report the remaining leakage.
+- If tests still need real infrastructure after the refactor, report which dependency is still not injectable and why.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Dependency boundary reviewed
+- Direct external dependencies found
+- Injection style selected
+- Ports and adapters added or reused
+- Assembly boundary used
+- External data or error translation handled
+- Tests, fakes, or fixed collaborators added or reused
+- Command intents run
+- Skipped checks and reasons
+- Remaining dependency leakage or lifecycle risk

package/templates/default/locales/hi/.mustflow/skills/dependency-reality-check/SKILL.md

@@ -0,0 +1,115 @@
+---
+mustflow_doc: skill.dependency-reality-check
+locale: hi
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: dependency-reality-check
+description: Apply this skill when a task assumes, adds, removes, imports, invokes, or documents a package, runtime, tool, command, service, or platform capability.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.dependency-reality-check
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - build
+    - test_release
+    - mustflow_check
+---
+
+# Dependency Reality Check
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Prevent code, docs, tests, and final reports from assuming unavailable packages, tools, commands, runtimes, services, or platform capabilities.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A change adds, removes, renames, imports, invokes, or documents a dependency, tool, runtime, command, plugin, service, or platform feature.
+- A solution relies on a package manager, binary, environment variable, browser API, operating-system command, hosted service, or optional integration.
+- A generated instruction tells another agent or user to run a tool that may not be declared in the repository.
+- A failure may be caused by a missing install, mismatched version, unsupported runtime, or unavailable command.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes repository-local prose and does not mention tools, runtime behavior, package metadata, or commands.
+- The dependency is already proven by the current task context and no dependency-facing surface changes.
+- The user explicitly asks for a speculative design that should not be implemented or verified yet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The dependency, tool, command, runtime, service, or platform capability being assumed.
+- Package, lock, config, import, script, command-intent, or documentation files that declare or reference it.
+- The minimum version, capability, or availability claim if one is required.
+- Relevant command-intent contract entries for build, package, test, or documentation verification.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Align dependency declarations, imports, scripts, command metadata, tests, and docs that describe the same capability.
+- Prefer existing repository dependencies and declared command intents before adding new packages or tools.
+- Do not install packages, widen runtime requirements, or introduce new external services unless the user request and repository contract support it.
+- Do not claim a dependency is available just because it exists on the internet or in another project.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the assumed dependency or capability and where the task relies on it.
+2. Check the repository declarations first: package metadata, lockfiles, config files, imports, command intents, docs, and templates.
+3. Decide whether the dependency is present, absent, optional, transitive, host-provided, or external.
+4. If present, verify that the requested capability and version expectation match the declared dependency.
+5. If absent, prefer an existing local alternative. Add a new dependency only when it is necessary and within the task scope.
+6. Keep all dependency-facing surfaces aligned: package metadata, lockfiles when intentionally updated, command contract, docs, tests, and installation notes.
+7. Run the narrowest configured verification that proves the dependency path used by the change.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every dependency or tool claim is backed by a repository declaration, configured command, host boundary, or explicit unverified-risk note.
+- New dependency requirements are reflected in the appropriate metadata and public documentation.
+- The final report states whether the dependency was existing, added, optional, unavailable, or intentionally not verified.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `build`
+- `test_release`
+- `mustflow_check`
+
+Use a narrower configured test, package, or docs intent when it better proves the dependency path.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the dependency is missing, report the missing declaration or command instead of silently adding a workaround.
+- If the declared version lacks the needed capability, report the mismatch and avoid claiming support.
+- If a dependency requires network, credentials, operating-system setup, or service access, stop at that boundary and name the unchecked requirement.
+- If generated docs would instruct users to run undeclared tools, rewrite the docs to use declared commands or mark the tool as a manual prerequisite.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Dependency or capability checked
+- Repository declaration or absence
+- Surfaces synchronized
+- Command intents run
+- Skipped dependency checks and reasons
+- Remaining dependency risk

package/templates/default/locales/hi/.mustflow/skills/diff-risk-review/SKILL.md

@@ -0,0 +1,136 @@
+---
+mustflow_doc: skill.diff-risk-review
+locale: hi
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: diff-risk-review
+description: Apply this skill when changed files need risk classification, verification selection, and rollback notes before final reporting.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.diff-risk-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test
+    - test_related
+    - test_audit
+    - lint
+    - build
+    - docs_validate
+    - mustflow_check
+---
+
+# Diff Risk Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Classify the risk of a completed change, choose the smallest relevant configured verification, and record rollback notes without expanding into a broad code review or speculative refactor.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A change touches more than one public surface, workflow file, command contract, template, generated map, test, or documentation area.
+- The user asks for the next roadmap slice, a completed change summary, a pre-commit check, or a risk-aware final report.
+- Verification breadth is unclear and the agent must decide between targeted, docs-only, build, strict check, or full test intents.
+- A change has potential rollback concerns because it affects installed templates, package metadata, generated files, user-facing docs, command behavior, security-sensitive paths, or data-handling rules.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only to perform a detailed code review with findings; use `code-review` instead.
+- No diff or changed-file list is available.
+- The change is a trivial wording edit that is already covered by a more specific documentation or translation procedure.
+- The user explicitly asks not to review risk or verification scope.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Current changed-file list or diff summary.
+- User task goal and any acceptance criteria.
+- `.mustflow/config/commands.toml` command intent statuses.
+- `.mustflow/config/preferences.toml` verification-selection settings.
+- Relevant skill or context documents for the changed surfaces.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep edits within the scope described by this skill, the user request, and the matching route in `.mustflow/skills/INDEX.md`.
+- Do not broaden command permission, invent project facts, change unrelated files, or add new abstractions only because a risk was noticed.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read the changed-file list and diff summary before judging risk.
+2. Group changed files by surface:
+   - source or runtime behavior
+   - tests and fixtures
+   - command contract or workflow policy
+   - installed template files
+   - package, release, or version metadata
+   - public documentation
+   - generated maps or local state
+   - security, privacy, data, migration, or external integration boundaries
+3. Assign a risk level:
+   - `low`: wording, translation, or isolated documentation with matching docs validation
+   - `medium`: templates, tests, package metadata, generated maps, or workflow docs without runtime behavior changes
+   - `high`: runtime behavior, command execution, security, privacy, data handling, migrations, release behavior, or multi-surface changes
+4. Identify the minimum relevant configured verification intents. Prefer the narrowest configured intents that cover the changed surfaces, but do not hide missing, unknown, manual-only, or skipped intents.
+5. Record rollback notes for any changed installed template, command contract, package version, generated file, migration-like change, or public behavior change.
+6. Check for scope drift: unrelated files, invented facts, unnecessary abstractions, weakened validation, or unreported generated-file refreshes.
+7. Produce a concise risk and verification summary. Use `code-review` only if findings require a full review-style report.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The expected output can be produced with clear evidence, executed command intents, skipped checks, and remaining risks.
+- Any missing command intent, unknown input, or authority conflict is reported instead of hidden.
+- The final report can explain why each verification intent was run or skipped.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `mustflow_check`
+- `docs_validate`
+- `build`
+- `test_related`
+- `test`
+- `test_audit`
+- `lint`
+
+Do not infer missing commands. If `test_related`, `test_audit`, or `lint` is unknown or manual-only, report the status and choose the next configured intent that covers the risk.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the changed-file list is unavailable, run or request a configured status intent before classifying risk.
+- If a configured verification fails, switch to `failure-triage` for that failing intent.
+- If the risk level is high but the matching verification intent is missing, report the gap instead of downgrading risk.
+- If generated files such as `REPO_MAP.md` are stale, refresh them only through their configured intent.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Changed surfaces
+- Risk level and reason
+- Minimum relevant verification
+- Command intents run
+- Skipped command intents and reasons
+- Rollback notes
+- Scope drift or generated-file notes
+- Remaining risk

package/templates/default/locales/hi/.mustflow/skills/docs-prose-review/SKILL.md

@@ -0,0 +1,119 @@
+---
+mustflow_doc: skill.docs-prose-review
+locale: hi
+canonical: false
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: docs-prose-review
+description: Apply this skill when a documentation review queue entry needs prose cleanup for LLM-like wording, awkward phrasing, literal translation, unnatural tone, or review comments attached to the queue entry.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.docs-prose-review
+  command_intents:
+    - docs_validate
+    - mustflow_check
+---
+
+# Docs Prose Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review one queued documentation file at a time and make its prose read naturally while preserving the document's technical contract.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The task asks to review documentation created or modified by an LLM.
+- A document is listed in the mustflow documentation review queue.
+- The queue entry includes a review comment that explains how the document should be checked or revised.
+- Prose sounds like LLM output, literal translation, filler, duplicated explanation, or unnatural Korean, English, or localized writing.
+- The reviewer is a human, LLM, tool, or external process and needs to record the review result.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task asks for new product documentation, API documentation, or workflow policy changes instead of prose review.
+- The document is not in the review queue and the task does not ask to add it.
+- The requested change would alter commands, paths, code blocks, schemas, field names, public contracts, or technical meaning.
+- The reviewer cannot understand the target language well enough to improve prose safely.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The documentation review queue entry or a user-selected document path.
+- Any review comment attached to the queue entry.
+- The current file contents.
+- The intended document language and existing document structure.
+- The reviewer kind and free-form reviewer identifier for the review record.
+- `.mustflow/config/commands.toml` to resolve any verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- The queue entry or selected path exists in the current mustflow root.
+- Higher-priority instructions, repository style, and command policy have been checked for the current scope.
+- The reviewer can preserve technical meaning while improving prose.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Edit only the selected documentation file and review ledger entry unless the user explicitly broadens scope.
+- Preserve headings, frontmatter identity, tables, command examples, code blocks, paths, field names, and schema names unless they are the direct source of the prose issue.
+- Do not rewrite the whole document only to change tone.
+- Do not remove a document from the queue without either improving it, marking it as still needing review, or explicitly recording why it should be ignored.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Inspect the documentation review queue and choose one queued file unless the user selected a specific path.
+2. If the entry has a review comment, treat it as the primary review guidance. Preserve the same technical safety boundaries as the rest of this skill.
+3. If the entry has no review comment, inspect the document normally for awkward, LLM-like, over-explained, duplicated, literal, or unnatural prose.
+4. Read the entire selected file before editing so terminology, heading structure, examples, and references stay consistent.
+5. Apply the review comment or prose cleanup with minimal, meaning-preserving edits.
+6. Preserve executable snippets, paths, field names, option names, identifiers, frontmatter identity, and tables.
+7. If the comment is ambiguous or the meaning is unclear, do not guess. Mark the entry as still needing human review and summarize what needs a human decision.
+8. If the file does not need prose changes, mark the entry approved or ignored with a concise summary that explains why.
+9. After a successful prose review, mark the queue entry approved with reviewer metadata and a short summary.
+10. Run relevant configured verification intents when the edit changes public docs or installed workflow docs.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The selected document reads more naturally without changing technical meaning.
+- The review queue entry is approved, marked for human review, or ignored with reviewer metadata.
+- Any skipped edit, unresolved meaning question, or missing command intent is reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available and relevant:
+
+- `docs_validate`
+- `mustflow_check`
+
+Do not infer missing validation commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the queue cannot be inspected, report the blocked queue step and do not edit blindly.
+- If the selected file is missing, mark or report the stale queue entry instead of creating a replacement document.
+- If the language or technical meaning is uncertain, mark the entry as still needing human review.
+- If validation fails after prose edits, fix the first relevant documentation or workflow issue before marking the review complete.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Queue entry selected
+- Review comment followed or reason no comment was present
+- Prose issues fixed
+- Review status recorded
+- Reviewer kind and reviewer identifier used
+- Command intents run
+- Skipped command intents and reasons
+- Remaining language, meaning, or validation risks