mustflow 2.18.7 → 2.18.21

package/templates/default/locales/en/.mustflow/skills/llm-service-ux-review/SKILL.md

@@ -0,0 +1,139 @@
+---
+mustflow_doc: skill.llm-service-ux-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: llm-service-ux-review
+description: Apply this skill when designing, implementing, or reviewing conversational AI, chat, copilot, prompt, multimodal input, streaming generation, citation, feedback, or conversation-history UI.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.llm-service-ux-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# LLM Service UX Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep LLM service interfaces clear, controllable, responsive, readable, and recoverable while making probabilistic AI limits visible enough for users to verify, correct, or reject output.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A change touches chat, assistant, copilot, prompt composer, prompt template, model picker, file or image upload, multimodal input, streaming response, generation progress, citation, feedback, copy, export, history, or new-conversation UI.
+- A task asks whether an LLM product feels clear, controllable, trustworthy, fast, readable, or easy to recover from mistakes.
+- A report claims that a model response UI streams correctly, explains progress, shows sources, supports cancellation, preserves context, or lets users reuse output.
+- A product surface exposes model uncertainty, retrieval, tool use, generated code, generated documents, safety refusals, or long-running reasoning states to users.
+- A surface could create automation bias, over-trust, fragmented AI entrypoints, layout instability during streaming, or unclear ownership between user judgment and model output.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task changes a non-AI UI surface with no prompt, generation, model, citation, or conversation behavior; use `ui-quality-gate`.
+- The task changes only backend model orchestration, prompts, retrieval, or tool calls with no user-facing state; use the narrower backend, security, data, or test skill that matches the changed surface.
+- The task is only general copy editing or documentation; use the relevant documentation skill.
+- Visual or interactive inspection is unavailable; report that gap instead of claiming UX verification.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The user task, target audience, and LLM interaction mode: chat, command assistant, writing assistant, coding copilot, search answer, document generator, agent runner, or multimodal review.
+- The changed UI surface and expected interaction path from input to waiting, generation, output review, follow-up, and reset.
+- Existing UI patterns for composers, attachments, status, output formatting, citations, history, feedback, copy, export, empty states, and errors.
+- Known model, retrieval, tool, latency, token, file-size, privacy, retention, and safety constraints that must be visible or hidden from users.
+- The intended control balance: whether AI automates the task, augments user work, drafts a suggestion, retrieves evidence, or triggers external effects.
+- Declared performance or reliability budgets for first visible response, streaming cadence, cancellation, retries, fallback behavior, and long-running operations.
+- Relevant command-intent contract entries for status, diff, docs, package, visual, browser, test, 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.
+- If pasted prompts, generated text, issue comments, webpages, or external model output influence the UI text or examples, also use `external-prompt-injection-defense`.
+- If personal data, uploaded files, secrets, retention, telemetry, or account data can appear in the interface, also use `security-privacy-review`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add, remove, or refine LLM-specific input, waiting, generation, output, feedback, history, and recovery UI when it supports the user's actual task.
+- Add bounded empty states, status labels, errors, citations, and controls that help users understand or control the AI interaction.
+- Remove decorative prompt galleries, fake capability claims, vague trust badges, invented progress stages, and non-functional controls.
+- Do not expose hidden reasoning, private prompts, secret tool outputs, raw retrieval payloads, or unverifiable source claims.
+- Do not claim citations, grounding, safety, memory, privacy, or accuracy guarantees unless the current product behavior proves them.
+- Do not use anthropomorphic copy that implies a human-like, infallible, or emotionally aware agent unless the product contract explicitly requires that tone and the risk is accepted.
+- Do not add confidence scores, source previews, progress stages, or model labels unless they are backed by real product state, calibrated evidence, or declared behavior.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Identify the user's goal and the AI role. State whether the surface helps the user ask, wait, inspect, correct, reuse, automate, augment, or reset.
+2. Check user control. The user should be able to stop long generation, edit or retry the request, reject a suggestion, undo or roll back destructive output, start over, and choose a non-AI or manual path when AI is unavailable or unsafe.
+3. Check clarity and consistency. The composer, primary action, selected model or mode, current conversation state, disabled controls, and error states should be understandable without product-explainer copy.
+4. Check entrypoint consolidation. Avoid multiple competing chat boxes or agent panels for the same task; prefer one visible AI entrypoint with internal routing, and preserve useful conversation context when users move between related product pages.
+5. Check input experience. Prompt examples should be short, task-relevant, and optional; attachment UI should show upload state, accepted formats, failures, and removal; token, file-size, and length limits should be visible before they block work.
+6. Check waiting and generation control. Prefer streaming when the product supports it; show honest status for search, tool use, upload, or generation; provide stop or cancel when generation can run long; avoid fake chain-of-thought or invented internal stages.
+7. Check streaming rendering. Incomplete Markdown, code fences, tables, links, and rich blocks should not cause layout jumps or broken formatting; auto-scroll should pause when the user scrolls, selects text, or interacts with earlier output.
+8. Check output readability. Use structured text, code blocks, tables, headings, or summaries only when they fit the answer type; long output needs scanning, copy, and overflow behavior; generated code or data should preserve formatting.
+9. Check evidence and citations. Clickable citations should appear only for sources actually used or retrieved; distinguish model output from source evidence; prefer exact passage links or previews when the product has real snippets; show unavailable, stale, or partial-source states plainly.
+10. Check uncertainty and automation bias. Avoid language that makes probabilistic output sound guaranteed; expose limitations, confidence, retrieval coverage, or verification needs only when backed by real state; keep important decisions under user review.
+11. Check correction and reuse. Users should be able to retry, edit the prompt, continue, fork from an earlier point, copy, export, provide feedback, or start a new conversation without losing context accidentally.
+12. Check history and reset. Conversation history, current thread, summarized context, and new-chat behavior should be clearly separated; destructive clearing or context reset should be deliberate and recoverable where possible.
+13. Check latency and cost controls. Use declared budgets when they exist; avoid resending unnecessary history; prefer summarized context, caching, parallel retrieval, or staged loading only when the implementation actually supports them.
+14. Check error prevention and recovery. Safety refusals, tool failures, retrieval misses, rate limits, unsupported files, token overflow, and network errors should name the problem and the next useful action.
+15. Check accessibility and responsiveness. Keyboard flow, focus return after generation, busy states, reduced motion, screen-reader status updates, mobile composer layout, attachment chips, and long translated labels should not block the task.
+16. Check trust, privacy, and retention boundaries. Do not imply long-term memory, private processing, deletion, or citation certainty unless the product actually provides it. Prefer concise state labels over broad disclaimers.
+17. Run the narrowest configured verification that covers changed UI, docs, package, or mustflow contracts, and report any visual or interactive checks that could not be performed.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The interface lets users control the LLM interaction across input, waiting, generation, output review, correction, reuse, history, and reset.
+- LLM-specific latency, uncertainty, source, failure, privacy, and recovery states are visible where needed and not overstated.
+- Probabilistic output, automation boundaries, fallback paths, and evidence gaps are visible enough for users to make their own judgment.
+- Decorative or explanatory UI has not replaced task-focused controls and real state.
+- Final reports separate implemented behavior from unverified UX, citation, privacy, or visual claims.
+
+<!-- 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 UI, browser, screenshot, accessibility, build, or test intent when it better proves the changed LLM service surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If model behavior, retrieval, citations, memory, retention, or tool stages cannot be verified, avoid promising them and report the gap.
+- If streaming or cancellation is unavailable, keep status honest and report the missing control instead of simulating it in the UI.
+- If output can contain unsafe, private, or fabricated content, route the relevant surface through security, privacy, or evidence checks before polishing the interface.
+- If visual inspection requires an undeclared development server, watcher, or browser command, stop at that boundary and report the skipped check.
+- If the requested UI conflicts with repository UI minimalism rules, keep the smallest task-focused control and explain the omitted decorative or tutorial content.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- LLM service surface reviewed
+- Input, waiting, generation, streaming, output, feedback, history, and reset states checked
+- Control, uncertainty, citation, fallback, privacy, error, accessibility, and responsiveness findings
+- Decorative, fake, or unverifiable UI avoided or removed
+- Command intents run
+- Skipped visual or interactive checks and reasons
+- Remaining LLM UX risk

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

@@ -0,0 +1,120 @@
+---
+mustflow_doc: skill.process-execution-safety
+locale: en
+canonical: true
+revision: 1
+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.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.process-execution-safety
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test_release
+    - mustflow_check
+---
+
+# Process Execution Safety
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Ensure process execution obeys declared command contracts, terminates reliably, bounds output and environment exposure, and does not treat a kill attempt as a verified process exit.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- 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.
+- 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.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes a command contract entry and not process execution code; use `command-contract-authoring`.
+- The task only changes filesystem writes after a process exits; use `cross-platform-filesystem-safety` if path safety is the main risk.
+- The task only changes CLI output wording; use `cli-output-contract-review`.
+
+<!-- mustflow-section: required-inputs -->
+## 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.
+- Platform boundary for Windows and POSIX process termination.
+- 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.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- `.mustflow/config/commands.toml` has been checked for configured verification intents.
+- Process execution changes are treated as security, data-consistency, and verification-integrity risk, not just runtime plumbing.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update process execution code, process-tree helpers, output buffers, environment creation, receipts, eligibility checks, tests, and directly synchronized docs.
+- 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.
+
+<!-- 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.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Execution status, timeout status, output status, cleanup status, receipt status, and write tracking tell the same story.
+- 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.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `test_related`
+- `test_release`
+- `mustflow_check`
+
+Escalate to broader configured tests when execution behavior crosses many command surfaces.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a timed-out or output-limited process cannot be confirmed terminated, record the uncertainty and do not claim full cleanup.
+- 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.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Process execution surface reviewed
+- 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
+- Tests or fixtures added or reused
+- Command intents run
+- Remaining process execution risk

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

@@ -42,6 +42,18 @@ route_type = "primary"
 priority = 80
 applies_to_reasons = ["code_change", "behavior_change"]
 
+[routes."command-contract-authoring"]
+category = "workflow_contracts"
+route_type = "authoring"
+priority = 80
+applies_to_reasons = ["mustflow_config_change", "mustflow_docs_change"]
+
+[routes."cli-output-contract-review"]
+category = "workflow_contracts"
+route_type = "adjunct"
+priority = 65
+applies_to_reasons = ["public_api_change", "behavior_change", "docs_change"]
+
 [routes."facade-pattern"]
 category = "architecture_patterns"
 route_type = "primary"
@@ -108,6 +120,12 @@ route_type = "adjunct"
 priority = 75
 applies_to_reasons = ["docs_change"]
 
+[routes."llm-service-ux-review"]
+category = "ui_assets"
+route_type = "primary"
+priority = 65
+applies_to_reasons = ["ui_change", "product_change"]
+
 [routes."diff-risk-review"]
 category = "general_code"
 route_type = "adjunct"
@@ -136,7 +154,13 @@ applies_to_reasons = ["code_change", "behavior_change"]
 category = "data_external"
 route_type = "adjunct"
 priority = 45
-applies_to_reasons = ["code_change", "docs_change"]
+applies_to_reasons = ["code_change", "docs_change", "security_change"]
+
+[routes."cross-platform-filesystem-safety"]
+category = "data_external"
+route_type = "adjunct"
+priority = 65
+applies_to_reasons = ["code_change", "security_change", "migration_change"]
 
 [routes."adapter-boundary"]
 category = "data_external"
@@ -144,6 +168,12 @@ route_type = "primary"
 priority = 55
 applies_to_reasons = ["code_change", "behavior_change"]
 
+[routes."process-execution-safety"]
+category = "data_external"
+route_type = "primary"
+priority = 70
+applies_to_reasons = ["code_change", "behavior_change", "security_change"]
+
 [routes."dependency-injection"]
 category = "data_external"
 route_type = "primary"
@@ -202,7 +232,7 @@ applies_to_reasons = ["command_failure"]
 category = "security_privacy"
 route_type = "adjunct"
 priority = 40
-applies_to_reasons = ["docs_change", "security_change"]
+applies_to_reasons = ["docs_change", "security_change", "mustflow_config_change"]
 
 [routes."external-skill-intake"]
 category = "workflow_contracts"
@@ -276,6 +306,12 @@ route_type = "primary"
 priority = 55
 applies_to_reasons = ["release_risk", "docs_change"]
 
+[routes."search-ad-content-authoring"]
+category = "docs_release"
+route_type = "primary"
+priority = 60
+applies_to_reasons = ["docs_change", "copy_change", "product_change"]
+
 [routes."docs-prose-review"]
 category = "docs_release"
 route_type = "adjunct"

package/templates/default/locales/en/.mustflow/skills/search-ad-content-authoring/SKILL.md

@@ -0,0 +1,148 @@
+---
+mustflow_doc: skill.search-ad-content-authoring
+locale: en
+canonical: true
+revision: 3
+lifecycle: mustflow-owned
+authority: procedure
+name: search-ad-content-authoring
+description: Apply this skill when planning, writing, editing, or reviewing search-friendly, ad-supported articles, blog posts, guides, reviews, comparisons, FAQs, or evergreen content.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.search-ad-content-authoring
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Search Ad Content Authoring
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Create useful, readable, search-oriented content that can support advertising layouts without keyword stuffing, thin-content filler, misleading ad placement, or unverifiable ranking and revenue claims.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task asks for a blog post, article, guide, comparison, review, cost breakdown, how-to page, FAQ, glossary entry, or evergreen content intended for search traffic.
+- A task mentions search visibility, SEO, featured snippets, Google traffic, AdSense, Ezoic, Raptive, Mediavine, RPM, ad viewability, affiliate content, or monetized content layout.
+- A content draft needs paragraph structure, heading hierarchy, table or list placement, FAQ coverage, source use, image placement, internal links, or ad slot layout review.
+- A report claims that an article is search-friendly, mobile-readable, ad-friendly, snippet-ready, or aligned with a publisher monetization strategy.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only product UI copy, release notes, README writing, legal policy text, or technical docs with no search or monetization goal; use the narrower writing or documentation skill.
+- The task asks to manipulate rankings, hide ads, mislead readers, copy competitor content, generate doorway pages, or maximize ads at the expense of user value.
+- Current Google, ad-network, legal, or policy claims are required but cannot be checked; use `source-freshness-check` and keep claims conservative.
+- The task only changes ad scripts, consent management, performance code, or analytics implementation without article content; use the relevant frontend, privacy, performance, or dependency skill.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Target reader, search intent, article topic, jurisdiction or market if relevant, and the action the reader should be able to complete after reading.
+- Content type: definition, how-to, troubleshooting, comparison, cost guide, review, alternatives, checklist, buying guide, FAQ, or news-style update.
+- Known source requirements, freshness needs, original experience, product data, pricing, images, tables, calculators, affiliate disclosures, and monetization constraints.
+- Existing content style, heading conventions, article-type defaults, link policy, image policy, accessibility rules, ad layout rules, and performance constraints.
+- Title, introduction, conclusion, call-to-action, semantic markup, ad slot, and link constraints when the content will be rendered as a webpage.
+- Publishing metadata requirements such as title, summary, search tags, author, published date, updated date, canonical URL, and structured data when the site supports them.
+- Relevant command-intent contract entries for status, diff, docs, package, visual, 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.
+- If the article depends on current facts, prices, policy behavior, product availability, laws, medical, legal, financial, or safety-sensitive claims, also use `source-freshness-check`.
+- If the content includes personal data, user submissions, health, finance, legal, minors, consent, tracking, affiliate disclosure, or ad personalization concerns, also use `security-privacy-review`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or revise outlines, headings, paragraphs, lists, tables, FAQs, summaries, source notes, image captions, internal links, and disclosure wording that improve reader value.
+- Adjust paragraph breaks, section order, table placement, media placement, and ad-slot separation to support mobile readability and stable ad layout.
+- Add semantic content-structure guardrails for titles, introductions, conclusions, calls to action, paragraphs, headings, image blocks, and ad-slot separation.
+- Add conservative content-quality guardrails that prevent thin filler, keyword stuffing, misleading ad adjacency, invented sources, or unsupported ranking claims.
+- Do not promise search rankings, featured snippets, approval by a specific ad network, RPM improvement, or ad-policy compliance unless verified against current authoritative sources.
+- Do not treat exact word counts, heading counts, paragraph counts, keyword positions, or FAQ counts as universal ranking formulas; use them only as project-specific editorial defaults.
+- Do not pad content solely to create more ad slots, add unrelated FAQs, or place ads where they can be mistaken for navigation, images, controls, or editorial recommendations.
+- Do not recommend delaying the reader's primary answer, using uncloseable or deceptive sticky ads, or adding visual spacers, widgets, or media solely to inflate scroll depth.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the search intent. Decide whether the reader needs a quick definition, step-by-step fix, comparison, price range, recommendation, troubleshooting path, or deeper research.
+2. Check volatile monetization claims. RPM formulas, network thresholds, revenue estimates, ad-refresh behavior, traffic eligibility, and current policy rules must be sourced and dated or omitted.
+3. Shape the title, summary, and introduction around the query. Use the target phrase naturally in the title or opening when it helps clarity, then open with the direct answer, reader problem, promised outcome, and any real evidence or experience without generic throat-clearing.
+4. Build the outline around reader decisions. Use H2 and H3 sections that match real subquestions, not keyword variants created only for search coverage.
+5. Apply site-specific editorial defaults when they exist. Article-type defaults for section count, paragraph count, or paragraph length can guide editing, but they are not ranking promises and should not override completeness.
+6. Keep paragraphs mobile-readable. Prefer one to three focused sentences per paragraph, but do not split a technical idea so aggressively that meaning becomes fragmented.
+7. Use semantic content structure. Real paragraphs, headings, figures, images, captions, lists, and tables should carry the structure; avoid stacked line breaks or meaningless wrapper markup when authoring rendered article templates.
+8. Use structured elements only when they help. Tables should compare real attributes; lists should sequence actions or options; pull summaries should reduce scanning cost.
+9. Add evidence and experience. Include first-hand observations, examples, screenshots, data, source links, or methodology when available. For data-heavy claims, use the pattern: number or claim, interpretation, then limitation.
+10. Handle freshness. Dates, prices, policy behavior, product availability, screenshots, benchmarks, and network rules need a source date or conservative wording.
+11. Design ad-friendly layout without harming trust. Keep content readable around ad slots, reserve layout space where applicable, separate ads from images and controls, avoid deceptive placement, and never make ads look like menus, downloads, recommendations, or content actions.
+12. Protect performance and accessibility. Use meaningful alt text, captions when useful, explicit image dimensions, lazy loading after critical content where appropriate, and avoid layout shifts.
+13. Add internal and external navigation thoughtfully. Use a table of contents, jump links, related articles, internal links, or authoritative external source links only when they help readers verify, choose, or continue.
+14. Add FAQs only for genuine follow-up questions. Three to five concise FAQs are often enough; avoid duplicated headings, fabricated long-tail questions, or answers that repeat the body.
+15. Check publishing metadata and machine-readable article signals when the platform supports them. Keep title, summary, tags, author, dates, canonical URL, images, and structured data aligned with the article body.
+16. Check monetization-sensitive ethics. Include affiliate or sponsorship disclosure when relevant, avoid exaggerated claims, keep editorial recommendations distinct from ads, and do not hide the core answer or resource at the bottom solely to force more scrolling.
+17. Close with a clean conclusion. Summarize the decision or next step, include a useful call to action when appropriate, and do not introduce new claims in the conclusion.
+18. Check final shape. The article should have a direct answer, useful body sections, structured support, source or experience signals, clear next steps, and no filler written only for algorithms or ad inventory.
+19. Run the narrowest configured verification that covers changed content, docs, template, package, or mustflow contracts.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The content serves the reader's search intent before optimizing for ad viewability or page length.
+- Paragraphs, headings, tables, lists, FAQs, images, links, and disclosures are purposeful and not filler.
+- The rendered article structure uses semantic blocks and avoids deceptive scroll-depth tactics.
+- Article length, section counts, paragraph counts, and keyword placement follow local editorial defaults when available, not universal SEO myths.
+- Publishing metadata and structured article signals match the visible content when the platform supports them.
+- Advertising layout considerations are separated from editorial claims and do not create deceptive or unstable UI.
+- Ranking, network approval, revenue, or policy-compliance claims are either verified, dated, or omitted.
+- Final reports separate content improvements from unverified search, ad-network, or revenue expectations.
+
+<!-- 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 prose, docs, link, accessibility, performance, visual, or package check when it better proves the changed content surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If source freshness cannot be checked, remove or soften claims about current rankings, ad-network rules, prices, dates, or policy behavior.
+- If the draft becomes keyword-stuffed, repetitive, or ad-slot filler, shorten it and restore reader-first structure.
+- If exact length, section, paragraph, or keyword-count advice conflicts with reader intent or local style, treat the number as an editorial suggestion and report the tradeoff.
+- If a source recommends intrusive, uncloseable, deceptive, or artificially delayed monetization patterns, keep only the user-respecting layout principle and reject the tactic.
+- If ad placement conflicts with readability, accessibility, privacy, consent, or performance constraints, prioritize user trust and report the monetization tradeoff.
+- If the topic is regulated or high stakes, avoid generic advice and require authoritative sources, qualified review, or a narrower scope.
+- If verification requires external policy pages, analytics, ad-console access, or live browser inspection not available in the current environment, report the skipped check.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Search and reader intent
+- Article type and outline shape
+- Title, summary, introduction, paragraph, heading, semantic markup, table, list, FAQ, image, link, metadata, structured data, conclusion, call-to-action, and disclosure checks
+- Source freshness and evidence notes
+- Ad layout, readability, performance, accessibility, and trust checks
+- Ranking, policy, revenue, or network claims omitted or verified
+- Command intents run
+- Skipped checks and reasons
+- Remaining content or monetization risk

package/templates/default/locales/en/.mustflow/skills/security-privacy-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.security-privacy-review
 locale: en
 canonical: true
-revision: 4
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: security-privacy-review
-description: Apply this skill when code, configuration, docs, templates, logs, telemetry, credentials, or data flows affect secrets, personal data, authentication, authorization, retention, or external disclosure.
+description: Apply this skill when code, configuration, docs, templates, logs, telemetry, credentials, data flows, AI-generated code, authentication, authorization, network calls, dependencies, cryptography, secure transport, agent configuration, or release surfaces affect secrets, personal data, retention, or external disclosure.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -31,7 +31,14 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 ## Use When
 
 - A change touches authentication, authorization, sessions, admin behavior, tenant boundaries, personal data, secrets, tokens, credentials, API keys, or private files.
+- A change comes from AI-generated code, vibe-coded output, copied examples, or a broad assistant patch that may have optimized for the happy path without proving abuse boundaries.
 - A change adds or modifies logging, telemetry, diagnostics, receipts, reports, caches, generated state, retention, redaction, export, or external transmission.
+- A change adds external URL fetching, webhook callbacks, redirects, browser previews, remote downloads, database-as-a-service rules, security headers, CORS, CSRF handling, or rate limits.
+- A change touches cookies, JWTs, reset tokens, invite tokens, OAuth callbacks, file upload or download, browser storage, business rules, pricing, entitlements, database queries, ORM bulk operations, or deployment configuration.
+- A change touches cryptography, password hashing, token generation, random number generation, TLS/HTTPS, certificate validation, scanner gates, or a security invariant that could drift across architecture boundaries.
+- A change adds, imports, recommends, or installs third-party dependencies that may affect the software supply chain.
+- A change introduces or edits agent configuration, MCP/tool configuration, prompt files, model instructions, or repository-local rule files.
+- A change affects CI/CD workflow permissions, fork pull-request handling, build scripts, package lifecycle scripts, deployment secrets, container users, storage buckets, debug flags, or public admin, metrics, GraphQL, cache, or search endpoints.
 - Documentation, templates, examples, tests, or final reports mention sensitive data handling, privacy behavior, secret handling, or user-identifying data.
 - A diff could expose data through filenames, paths, command output, screenshots, generated artifacts, package contents, or public docs.
 - A change constructs, recommends, copies, resolves, or runs commands based on repository-controlled names, configuration, or generated reports.
@@ -51,6 +58,9 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 
 - Changed files, diff summary, and the user goal.
 - Sensitive data, actor, trust boundary, storage, logging, retention, export, or external disclosure surfaces involved.
+- Actor, resource owner, tenant boundary, server-side authorization rule, state-changing route, external network target, dependency source, and agent/tool permission surface involved.
+- Cookie, JWT, OAuth, file upload, file download, business-value, database mutation, ORM bulk operation, CI/CD permission, deployment setting, or secret-source surface involved.
+- Cryptographic primitive, password hashing, random-token, secure transport, certificate validation, scanner gate, or security invariant involved.
 - Existing project rules for secrets, privacy, generated state, public docs, package contents, and command output.
 - Relevant command-intent contract entries for status, diff, docs, release, or mustflow validation.
 - Any repository-controlled names, paths, symlinks, command strings, environment path entries, workflow actions, or package contents that cross a trust boundary.
@@ -70,6 +80,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Remove sensitive-looking sample values from docs, fixtures, templates, logs, reports, and final output when they are not required.
 - Mark unknown privacy or secret-handling behavior as unverified instead of claiming it is safe.
 - Do not invent compliance claims, privacy guarantees, secret scanning results, or audit coverage.
+- Do not treat a working UI, passing happy-path test, or generated assistant explanation as proof that authorization, privacy, dependency, or external-request boundaries are safe.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
@@ -77,21 +88,41 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 1. Identify the sensitive surface: secret, personal data, actor, permission, storage location, log, generated artifact, package file, public document, or external recipient.
 2. Decide whether the change creates, stores, reads, transforms, logs, exports, deletes, or reports sensitive information.
 3. Check whether the changed surface is public, packaged, generated, cached, retained, user-visible, or sent outside the repository boundary.
-4. Treat shell commands, copyable command text, executable names, workflow action references, publish identities, package manifests, and environment path entries as disclosure and execution surfaces, not as harmless strings.
-5. For filesystem changes, distinguish lexical containment from the real target. Check symlinks, generated state, package contents, and file APIs that may follow links before claiming a path stays inside the repository.
-6. For code-scanning alerts, group findings by root cause and rule. Fix the underlying pattern, not only the exact flagged line, and separate repository-setting alerts such as branch protection or maintainer activity from code changes.
-7. For workflow scanner alerts, check action pinning, `persist-credentials`, job-level permissions, reusable workflow permissions, artifact upload boundaries, and privileged identity timing before treating the warning as cosmetic.
-8. For pinned action references, distinguish tag objects from the commit that implements the tag. Verify pinned SHAs against the action repository so scanner tooling does not report an imposter or non-member commit.
-9. For dependency scanner alerts, separate production dependency manifests from fixtures, examples, generated test repositories, and intentionally vulnerable samples. Narrow the scan scope before treating fixture-only alerts as product vulnerabilities.
-10. Verify that examples, fixtures, screenshots, command outputs, and final reports do not expose real-looking secrets or unnecessary personal data.
-11. Prefer omission or minimal metadata over masking when the sensitive value is not needed for the user to understand the result.
-12. If the change affects an authorization or abuse boundary, activate `security-regression-tests` for test selection instead of folding test generation into this review.
-13. Run the narrowest configured verification that covers the changed docs, templates, package, or mustflow contract.
+4. Treat AI-generated code as untrusted until the protected resource, actor, ownership rule, and denied case are inspected. UI-only hiding, client-side role checks, and passing happy-path flows do not prove server-side authorization.
+5. For each read, write, update, delete, export, or admin route, confirm the server-side query or policy binds the session actor to the target resource owner, tenant, role, or capability.
+6. Do not stop at "is logged in". Separate authentication from authorization, then inspect tenant, workspace, organization, team, owner, role, and guest filters on both reads and writes.
+7. For database and ORM changes, check for unscoped `findMany`, `updateMany`, `deleteMany`, mass assignment of `role`, `price`, `ownerId`, `isPaid`, or similar privileged fields, unsafe migration defaults, and missing row-level or policy-based access controls where the platform supports them.
+8. For state-changing routes that rely on cookies or browser credentials, check CSRF, origin, CORS, same-site, and rate-limit behavior instead of assuming the framework default is active.
+9. For session and token behavior, check cookie flags, JWT verification instead of decode-only logic, expiration, issuer and audience validation, reset or invite token entropy and lifetime, server-side revocation, logout invalidation, and reauthentication before sensitive account or payment changes.
+10. For external URL, webhook, preview, redirect, download, or callback behavior, check allowlists, protocol restrictions, redirect handling, DNS/IP re-resolution, private network ranges, link-local metadata endpoints, webhook signatures, timeout limits, retry limits, and open redirect parameters such as `next` or `redirect`.
+11. For database-as-a-service, storage bucket, or realtime rules, check that server-side policies are default-deny, ownership-scoped, and not left in public read/write development mode.
+12. For input sinks, check parameterized queries, ORM binding, static command maps, output encoding, HTML/Markdown rendering boundaries, unsafe dynamic evaluation, XML/YAML/Markdown parser options, redirect and sort parameters, page-size limits, and framework escape hatches.
+13. For file upload and download, check MIME and content signatures, size limits, storage outside executable web roots, SVG/HTML/PDF rendering rules, image or document metadata, filename controls, Unicode confusion, path traversal, download authorization, and resource limits for resizing, archive extraction, or document conversion.
+14. For business logic, check that server code does not trust client-supplied prices, discounts, roles, owners, entitlement state, plan limits, usage counters, inventory, seats, refunds, credits, or coupon state. Inspect idempotency, transactions, uniqueness, and concurrent requests for repeated side effects.
+15. For secrets and logs, check hardcoded credentials, frontend bundle exposure, public versus secret key confusion, real-looking samples, raw request or session dumps, stack traces, error payloads, screenshots, receipts, generated reports, and whether leaked keys need revocation guidance.
+16. Treat shell commands, copyable command text, executable names, workflow action references, publish identities, package manifests, lifecycle scripts, Dockerfiles, and environment path entries as disclosure and execution surfaces, not as harmless strings.
+17. For dependency changes, activate `dependency-reality-check` to confirm the package is declared, real, necessary, locked when appropriate, and not an assistant-hallucinated or lookalike dependency.
+18. For agent configuration, MCP/tool setup, prompt files, external instructions, or AI context settings, activate `external-prompt-injection-defense` and check hidden instruction text, suspicious Unicode controls, broad filesystem or shell permissions, network egress, sensitive context inclusion, and over-privileged service tokens.
+19. For filesystem changes, distinguish lexical containment from the real target. Check symlinks, generated state, package contents, and file APIs that may follow links before claiming a path stays inside the repository.
+20. For code-scanning alerts, group findings by root cause and rule. Fix the underlying pattern, not only the exact flagged line, and separate repository-setting alerts such as branch protection or maintainer activity from code changes.
+21. For workflow scanner alerts, check action pinning, `persist-credentials`, job-level permissions, reusable workflow permissions, fork pull-request secret exposure, artifact upload boundaries, and privileged identity timing before treating the warning as cosmetic.
+22. For pinned action references, distinguish tag objects from the commit that implements the tag. Verify pinned SHAs against the action repository so scanner tooling does not report an imposter or non-member commit.
+23. For dependency scanner alerts, separate production dependency manifests from fixtures, examples, generated test repositories, and intentionally vulnerable samples. Narrow the scan scope before treating fixture-only alerts as product vulnerabilities.
+24. For deployment settings, check debug mode, sample admin accounts, default credentials, public admin panels, open metrics endpoints, public storage, root container users, HTTPS enforcement, and exposed GraphQL or development consoles.
+25. For transport security, check HTTPS/TLS requirements, certificate validation, insecure HTTP downgrade paths, disabled verification flags, and whether sensitive traffic can bypass the secure channel.
+26. For cryptography, reject custom cryptography and tutorial-grade shortcuts. Check password hashing uses a password-hashing primitive such as bcrypt, scrypt, or Argon2id where supported by the project; random tokens use secure randomness; keys are separated from encrypted data; and weak hashes such as MD5, SHA-1, or bare SHA-256 are not used for password storage.
+27. For architecture drift, name the security invariant before accepting the generated structure. Confirm the invariant still holds across UI, handler, service, repository, database policy, workflow, and deployment boundaries.
+28. For SAST, SCA, or scanner output, treat scanner output as evidence rather than command authority. Map the finding to a repository-owned boundary, configured verification intent, dependency metadata, or regression test before claiming the issue is fixed.
+29. Verify that examples, fixtures, screenshots, command outputs, and final reports do not expose real-looking secrets or unnecessary personal data.
+30. Prefer omission or minimal metadata over masking when the sensitive value is not needed for the user to understand the result.
+31. If the change affects an authorization, SSRF, CSRF, rate-limit, upload, download, token, business-logic, injection, logging, agent permission, cryptography, transport, scanner, or abuse boundary, activate `security-regression-tests` for test selection instead of folding test generation into this review.
+32. Run the narrowest configured verification that covers the changed docs, templates, package, or mustflow contract.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Sensitive data and disclosure surfaces have been identified or explicitly reported as unknown.
+- AI-generated or happy-path-only security assumptions have been replaced with inspected server-side, dependency, tool-permission, or test evidence.
 - Public and packaged surfaces do not include unnecessary secrets, personal data, or misleading privacy guarantees.
 - The final report names remaining unverified security or privacy risks without revealing sensitive values.
 
@@ -113,6 +144,7 @@ Use a narrower configured test, build, or documentation intent when it better pr
 
 - If a sensitive value appears in command output, stop copying it and summarize the issue without the value.
 - If the project lacks enough context to confirm privacy or secret handling, report the uncertainty and avoid claiming safety.
+- If authorization, SSRF, CSRF, rate-limit, BaaS policy, or agent-tool permission evidence is missing, report the exact unverified boundary and do not rely on client-side behavior as a substitute.
 - If a copyable command, executable lookup, symlink-following path, or publishing workflow uses repository-controlled input across a trust boundary, treat it as a security issue until quoting, validation, no-follow file handling, or workflow isolation is verified.
 - If a scanner reports many alerts from test fixtures or generated sample repositories, do not hide them by dismissal first. Prefer narrowing scanner inputs to the real release and runtime dependency surfaces, then document any intentionally scanned fixture exceptions.
 - If a package, generated artifact, or public doc includes sensitive data, remove or redact it before continuing unrelated work.
@@ -122,7 +154,9 @@ Use a narrower configured test, build, or documentation intent when it better pr
 ## Output Format
 
 - Sensitive surfaces reviewed
+- AI-generated happy-path assumptions checked
 - Disclosure or retention paths checked
+- Authorization, session, token, input, file, network, business-logic, dependency, cryptography, transport, deployment, scanner, and agent-tool boundaries checked
 - Redaction, omission, or wording changes made
 - Related security-regression test need
 - Command intents run