bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/sprint-status.md

@@ -1,297 +1,55 @@
----
+---
 name: bmad-sprint-status
-description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
+description: Report actual sprint progress, evidence gaps and the next useful action.
 ---
 
-# Sprint Status Workflow
-
-**Goal:** Summarize sprint status, surface risks, and recommend the next workflow action.
-
-**Your Role:** You are a Developer providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps.
-
-## Conventions
-
-- Bare paths (e.g. `checklist.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `implementation_artifacts`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Paths
-
-- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
-
-## Input Files
-
-| Input | Path | Load Strategy |
-|-------|------|---------------|
-| Sprint status | `{sprint_status_file}` | FULL_LOAD |
-
-## Execution
-
-<workflow>
-
-<step n="0" goal="Determine execution mode">
-  <action>Set mode = {{mode}} if provided by caller; otherwise mode = "interactive"</action>
-
-  <check if="mode == data">
-    <action>Jump to Step 20</action>
-  </check>
-
-  <check if="mode == validate">
-    <action>Jump to Step 30</action>
-  </check>
-
-  <check if="mode == interactive">
-    <action>Continue to Step 1</action>
-  </check>
-</step>
-
-<step n="1" goal="Locate sprint status file">
-  <action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
-  <action>Try {sprint_status_file}</action>
-  <check if="file not found">
-    <output>sprint-status.yaml not found.
-Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-status.</output>
-    <action>Exit workflow</action>
-  </check>
-  <action>Continue to Step 2</action>
-</step>
-
-<step n="2" goal="Read and parse sprint-status.yaml">
-  <action>Read the FULL file: {sprint_status_file}</action>
-  <action>Parse fields: generated, last_updated, project, project_key, tracking_system, story_location</action>
-  <action>Parse development_status map. Classify keys:</action>
-- Epics: keys starting with "epic-" (and not ending with "-retrospective")
-- Retrospectives: keys ending with "-retrospective"
-- Stories: everything else (e.g., 1-2-login-form)
-  <action>Map legacy story status "drafted" → "ready-for-dev"</action>
-  <action>Count story statuses: backlog, ready-for-dev, in-progress, review, done</action>
-  <action>Map legacy epic status "contexted" → "in-progress"</action>
-  <action>Count epic statuses: backlog, in-progress, done</action>
-  <action>Count retrospective statuses: optional, done</action>
-
-<action>Validate all statuses against known values:</action>
-
-- Valid story statuses: backlog, ready-for-dev, in-progress, review, done, drafted (legacy)
-- Valid epic statuses: backlog, in-progress, done, contexted (legacy)
-- Valid retrospective statuses: optional, done
-
-  <check if="any status is unrecognized">
-    <output>
-**Unknown status detected:**
-{{#each invalid_entries}}
-
-- `{{key}}`: "{{status}}" (not recognized)
-  {{/each}}
-
-**Valid statuses:**
-
-- Stories: backlog, ready-for-dev, in-progress, review, done
-- Epics: backlog, in-progress, done
-- Retrospectives: optional, done
-  </output>
-  <ask>How should these be corrected?
-  {{#each invalid_entries}}
-  {{@index}}. {{key}}: "{{status}}" → [select valid status]
-  {{/each}}
-
-Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue without fixing:</ask>
-<check if="user provided corrections">
-<action>Update sprint-status.yaml with corrected values</action>
-<action>Re-parse the file with corrected statuses</action>
-</check>
-</check>
-
-<action>Detect risks:</action>
-
-- IF any story has status "review": suggest `/bmad:bmm:workflows:code-review`
-- IF any story has status "in-progress" AND no stories have status "ready-for-dev": recommend staying focused on active story
-- IF all epics have status "backlog" AND no stories have status "ready-for-dev": prompt `/bmad:bmm:workflows:create-story`
-- IF `last_updated` timestamp is more than 7 days old (or `last_updated` is missing, fall back to `generated`): warn "sprint-status.yaml may be stale"
-- IF any story key doesn't match an epic pattern (e.g., story "5-1-..." but no "epic-5"): warn "orphaned story detected"
-- IF any epic has status in-progress but has no associated stories: warn "in-progress epic has no stories"
-  </step>
-
-<step n="3" goal="Select next action recommendation">
-  <action>Pick the next recommended workflow using priority:</action>
-  <note>When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1)</note>
-  1. If any story status == in-progress → recommend `dev-story` for the first in-progress story
-  2. Else if any story status == review → recommend `code-review` for the first review story
-  3. Else if any story status == ready-for-dev → recommend `dev-story`
-  4. Else if any story status == backlog → recommend `create-story`
-  5. Else if any retrospective status == optional → recommend `retrospective`
-  6. Else → All implementation items done; congratulate the user - you both did amazing work together!
-  <action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV)</action>
-</step>
-
-<step n="4" goal="Display summary">
-  <output>
-## Sprint Status
-
-- Project: {{project}} ({{project_key}})
-- Tracking: {{tracking_system}}
-- Status file: {sprint_status_file}
-
-**Stories:** backlog {{count_backlog}}, ready-for-dev {{count_ready}}, in-progress {{count_in_progress}}, review {{count_review}}, done {{count_done}}
-
-**Epics:** backlog {{epic_backlog}}, in-progress {{epic_in_progress}}, done {{epic_done}}
-
-**Next Recommendation:** /bmad:bmm:workflows:{{next_workflow_id}} ({{next_story_id}})
-
-{{#if risks}}
-**Risks:**
-{{#each risks}}
-
-- {{this}}
-  {{/each}}
-  {{/if}}
-
-  </output>
-  </step>
-
-<step n="5" goal="Offer actions">
-  <ask>Pick an option:
-1) Run recommended workflow now
-2) Show all stories grouped by status
-3) Show raw sprint-status.yaml
-4) Exit
-Choice:</ask>
-
-  <check if="choice == 1">
-    <output>Run `/bmad:bmm:workflows:{{next_workflow_id}}`.
-If the command targets a story, set `story_key={{next_story_id}}` when prompted.</output>
-  </check>
-
-  <check if="choice == 2">
-    <output>
-### Stories by Status
-- In Progress: {{stories_in_progress}}
-- Review: {{stories_in_review}}
-- Ready for Dev: {{stories_ready_for_dev}}
-- Backlog: {{stories_backlog}}
-- Done: {{stories_done}}
-    </output>
-  </check>
-
-  <check if="choice == 3">
-    <action>Display the full contents of {sprint_status_file}</action>
-  </check>
-
-  <check if="choice == 4">
-<!-- Adapted for BMAD+: original script dependency removed -->
-    <action>Exit workflow</action>
-  </check>
-</step>
+# Sprint status
 
-<!-- ========================= -->
-<!-- Data mode for other flows -->
-<!-- ========================= -->
+Read the [execution guide](../../shared/execution.md) and
+[Oholiab's role](dev-agent.md).
 
-<step n="20" goal="Data mode output">
-  <action>Load and parse {sprint_status_file} same as Step 2</action>
-  <action>Compute recommendation same as Step 3</action>
-  <template-output>next_workflow_id = {{next_workflow_id}}</template-output>
-  <template-output>next_story_id = {{next_story_id}}</template-output>
-  <template-output>count_backlog = {{count_backlog}}</template-output>
-  <template-output>count_ready = {{count_ready}}</template-output>
-  <template-output>count_in_progress = {{count_in_progress}}</template-output>
-  <template-output>count_review = {{count_review}}</template-output>
-  <template-output>count_done = {{count_done}}</template-output>
-  <template-output>epic_backlog = {{epic_backlog}}</template-output>
-  <template-output>epic_in_progress = {{epic_in_progress}}</template-output>
-  <template-output>epic_done = {{epic_done}}</template-output>
-  <template-output>risks = {{risks}}</template-output>
-  <action>Return to caller</action>
-</step>
+## Inputs
 
-<!-- ========================= -->
-<!-- Validate mode -->
-<!-- ========================= -->
+An explicit sprint or backlog artifact, or a request identifying the project and
+sprint to inspect. Read the actual ledger, relevant stories and available delivery
+evidence. Report the absence of a ledger rather than inventing a sprint.
 
-<step n="30" goal="Validate sprint-status file">
-  <action>Check that {sprint_status_file} exists</action>
-  <check if="missing">
-    <template-output>is_valid = false</template-output>
-    <template-output>error = "sprint-status.yaml missing"</template-output>
-    <template-output>suggestion = "Run sprint-planning to create it"</template-output>
-    <action>Return</action>
-  </check>
+## Procedure
 
-<action>Read and parse {sprint_status_file}</action>
+1. Establish the reporting scope, source revision and observation time. Read
+   current tracking files while preserving their exact status vocabulary and
+   human notes.
+2. Inventory work by stable ID. Count items by their reported statuses and
+   distinguish committed scope, carryover, newly added work and deferred work
+   where the source supports those distinctions.
+3. Inspect relevant acceptance reports, checks or code evidence for material
+   completion claims. Note contradictions such as a done status with a failing
+   required check, or an old blocker whose dependency now has evidence.
+4. Identify dependency bottlenecks, stale evidence and unknown ownership or
+   capacity. State how each affects the next action; do not turn missing estimates
+   into an invented delivery date.
+5. Recommend the next actionable item or the smallest step to remove a blocker.
+   Keep source status and assessed evidence in separate columns. A read-only
+   status request does not authorize rewriting the ledger.
+6. Produce a concise report with source-backed counts and evidence limits.
+   Explain what cannot be concluded from the available artifacts.
 
-<action>Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility)</action>
-<check if="any required field missing">
-<template-output>is_valid = false</template-output>
-<template-output>error = "Missing required field(s): {{missing_fields}}"</template-output>
-<template-output>suggestion = "Re-run sprint-planning or add missing fields manually"</template-output>
-<action>Return</action>
-</check>
+## Output and acceptance
 
-<action>Verify development_status section exists with at least one entry</action>
-<check if="development_status missing or empty">
-<template-output>is_valid = false</template-output>
-<template-output>error = "development_status missing or empty"</template-output>
-<template-output>suggestion = "Re-run sprint-planning or repair the file manually"</template-output>
-<action>Return</action>
-</check>
+Write the report for sprint-status with scope, source timestamps or hashes,
+status counts, exceptions and next actions.
 
-<action>Validate all status values against known valid statuses:</action>
+| Item | Reported status | Evidence inspected | Assessment | Next action |
+| --- | --- | --- | --- | --- |
+| Actual ID | Preserve source value | Specific artifact or check | Supported, contradicted or unknown | Bounded action |
 
-- Stories: backlog, ready-for-dev, in-progress, review, done (legacy: drafted)
-- Epics: backlog, in-progress, done (legacy: contexted)
-- Retrospectives: optional, done
-  <check if="any invalid status found">
-  <template-output>is_valid = false</template-output>
-  <template-output>error = "Invalid status values: {{invalid_entries}}"</template-output>
-  <template-output>suggestion = "Fix invalid statuses in sprint-status.yaml"</template-output>
-  <action>Return</action>
-  </check>
+Counts must reconcile with the inspected item set. Unknown work is not completed,
+and an uninspected check is not passed. Clearly label a partial snapshot when
+some tracking sources are unavailable.
 
-<template-output>is_valid = true</template-output>
-<template-output>message = "sprint-status.yaml valid: metadata complete, all statuses recognized"</template-output>
-<!-- Adapted for BMAD+: original script dependency removed -->
-</step>
+## Continue
 
-</workflow>
+Reload tracking sources and compare them with the prior report. Recompute changed
+items and dependency consequences. Preserve the old observation as history when
+useful; never overwrite manually maintained states just to align them with the
+assistant's assessment.

package/src/bmad-plus/packs/pack-dev-studio/categories/planning/create-prd.md

@@ -1,30 +1,70 @@
----
+---
 name: bmad-create-prd
-description: 'DEPRECATED — consolidated into bmad-prd create intent - this skill will be removed in v7 in favor of `bmad-prd`.'
+description: Create a requirements document with observable behavior, scope and acceptance evidence.
 ---
 
-# DEPRECATED — forwards to bmad-prd (create intent)
+# Create PRD
+
+Load the [execution guide](../../shared/execution.md) and
+[Yosef](pm-agent.md). Define the requested product behavior at the level needed
+for implementation and review. This is a maintained route.
+
+## Inputs
+
+Use the request, problem or product brief, relevant research, known constraints
+and existing product behavior. A formal brief is optional. If a canonical PRD
+already exists for this scope, inspect it before creating a competing document;
+use [Edit PRD](edit-prd.md) when the task is an update.
 
-This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `bmad-create-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
+## Procedure
 
-## On Activation
+1. Establish the intended users, problem, desired outcome and requested scope.
+   Inspect source artifacts first. Distinguish an established constraint from a
+   proposal and an unsupported assumption.
+2. Describe the main user journeys and relevant system interactions. Capture
+   prerequisites, access rules, business rules and the meaningful failure or
+   recovery paths. For an existing product, identify changed behavior explicitly.
+3. Define the first delivery scope, exclusions and dependencies. Keep explicit
+   user requirements visible when proposing priorities or phasing.
+4. Assign stable IDs to functional requirements. For each, state the actor or
+   trigger, required behavior, conditions and an observable acceptance example.
+   Link it to the user need or supplied evidence. Avoid implementation choices
+   unless they are genuine project constraints.
+5. Record applicable nonfunctional requirements such as performance, availability,
+   accessibility, privacy or operational recovery. State the measurement context
+   and verification method. Unknown thresholds stay open; proposed thresholds are
+   labeled as proposals.
+6. Define success measures and guardrails. Identify the baseline, proposed target,
+   measurement method and missing evidence. Check that success does not reward
+   behavior the product is meant to avoid.
+7. Review consistency across journeys, requirements, exclusions and dependencies.
+   Identify feasibility questions for architecture or research. Revise supported
+   contradictions and leave unresolved decisions visible.
 
-<!-- Adapted for BMAD+: original script dependency removed -->
+## Output
 
-2. Load `{project-root}/project config` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
+Produce a PRD with:
 
-3. Emit a deprecation notice to the user in `{communication_language}`:
+- Purpose, users and desired outcomes.
+- Scope, exclusions and assumptions.
+- User journeys and relevant business rules.
+- Functional requirements with stable IDs and acceptance examples.
+- Nonfunctional requirements and verification methods.
+- Dependencies, risks and open decisions.
+- Success measures and readiness for the intended next step.
 
-   > Notice: `bmad-create-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with create intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `bmad-create-prd.toml` to `bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+The report also records input provenance, completed checks and the canonical
+artifact path. A small change can use a compact document; section length is not
+an acceptance criterion.
 
-4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
+## Acceptance and continuation
 
-   - **Intent:** `create` — skip `bmad-prd`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `agent configuration` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
-     - `activation_steps_prepend` = the resolved value from step 1
-     - `activation_steps_append` = the resolved value from step 1
-     - `persistent_facts` = the resolved value from step 1
-     - `on_complete` = the resolved value from step 1
-   - **Original user input:** forward whatever the user said when invoking this skill verbatim.
+Each in-scope behavior must be traceable to a need and verifiable through an
+example or check. Mark unsupported feasibility claims and unapproved targets.
+Do not call the document approved unless the relevant person actually approved it.
 
-   `bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
+On resume, compare inputs and retain established IDs. Revisit only affected
+requirements and record material decision changes. Use
+[Validate PRD](validate-prd.md), [UX design](create-ux-design.md) or
+[Architecture](../architecture/create-architecture.md) when needed for the
+authorized task; a completed draft does not automatically invoke them.

package/src/bmad-plus/packs/pack-dev-studio/categories/planning/create-ux-design.md

@@ -1,75 +1,106 @@
----
+---
 name: bmad-create-ux-design
-description: 'Plan UX patterns and design specifications. Use when the user says "lets create UX design" or "create UX specifications" or "help me plan the UX"'
+description: Define task flows, interaction states, visual constraints and accessibility acceptance for a product.
 ---
 
-# Create UX Design Workflow
-
-**Goal:** Create comprehensive UX design specifications through collaborative visual exploration and informed decision-making where you act as a UX facilitator working with a product stakeholder.
-
-## Conventions
-
-- Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Paths
-
-- `default_output_file` = `{planning_artifacts}/ux-design-specification.md`
-
-## EXECUTION
-
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-- Read fully and follow: `./steps/step-01-init.md` to begin the UX design workflow.
+# Create UX design
+
+Load the [execution guide](../../shared/execution.md) and
+[Rachel](ux-designer-agent.md). Produce an implementable design specification
+that connects user tasks to observable behavior and presentation.
+
+## Inputs
+
+Use the product request or PRD, intended users and tasks, supported surfaces,
+known constraints and any existing interface, components or brand guidance.
+Inspect the current product when available. A missing prototype does not prevent
+a useful draft, but unobserved behavior must remain unverified.
+
+## Procedure
+
+1. **Establish scope and evidence.** Identify the task the user must complete,
+   its starting conditions and success outcome. Read existing requirements,
+   relevant product screens or source components and design conventions.
+   Distinguish observed problems from proposed improvements. Record unresolved
+   product decisions before choosing a layout to conceal them.
+2. **Map the information and journey.** Define relevant destinations, navigation,
+   entry points and how a user knows where they are. Describe the main path,
+   alternate entry, back or cancel behavior and recovery. Map each step to a
+   product requirement or documented need.
+3. **Define the behavior contract.** For each important interaction, specify:
+   - Actor, trigger, prerequisites and access conditions.
+   - Inputs, validation timing and the resulting state or navigation.
+   - Default, loading, empty, success and error states where applicable.
+   - Recovery, retry, cancellation and preservation of user-entered data.
+   - Effects on stored data or external systems, including confirmation when
+     the actual operation warrants it.
+   - Repeated submissions, delayed responses, offline behavior or competing
+     changes when relevant to the product.
+     Mark a state not applicable with a reason instead of inventing features.
+     Keep invariants explicit, such as preserving a draft after a failed save.
+4. **Define the visual contract.** Reuse suitable established components and
+   tokens. Specify hierarchy, content density, typography, color roles, spacing,
+   layout constraints and component variants needed for this task. State narrow
+   and wide viewport behavior, long-content wrapping and text enlargement.
+   Describe focus and error appearance without relying on color alone. Explain
+   the purpose of motion and define reduced-motion behavior where motion exists.
+   Record asset sources and placeholders. A palette or mockup remains a proposal
+   until its relevant contrast and rendering checks have been performed.
+5. **Define accessibility behavior.** Specify semantic structure, accessible
+   names, label and instruction relationships, keyboard order and controls,
+   focus movement after dialogs or navigation, visible focus, status and error
+   announcements, and alternatives for nontext content. Identify checks for
+   contrast, zoom or reflow, text size, touch interaction and reduced motion
+   where applicable. Name the project's target accessibility standard if known;
+   an unconfirmed target remains open. Do not equate an automated scan with
+   complete conformance.
+6. **Create a reviewable representation.** Use a flow diagram, annotated
+   wireframe, component example or prototype appropriate to the request and
+   available tools. Map its states back to the behavior contract. Label
+   illustrative content and distinguish a static representation from working
+   interaction. Do not report generated imagery or a screenshot as usability
+   evidence.
+7. **Walk through and check.** Follow a primary task and a consequential failure
+   path. Check wording, state transitions and consistency with requirements.
+   If a runnable interface is available, inspect relevant keyboard interaction,
+   viewport behavior, focus and errors; record environment and observed results.
+   If only a specification exists, review its acceptance scenarios and mark
+   browser, assistive-technology and user testing as not performed.
+8. **Resolve and hand off.** Correct demonstrated inconsistencies. Record
+   remaining product decisions, technical feasibility questions and validation
+   gaps. Provide implementers with explicit acceptance scenarios and traceable
+   component or requirement references.
+
+## Output
+
+Produce a UX specification containing:
+
+- Scope, users, tasks and inspected evidence.
+- Information architecture and task flows.
+- Behavior contract and state transitions.
+- Visual contract, reusable components and responsive constraints.
+- Accessibility behavior and acceptance checks.
+- Reviewable representation and its limitations.
+- Acceptance scenarios, check results and unresolved decisions.
+
+For each acceptance scenario, record its precondition, user action, expected
+visible or accessible result and relevant requirement. For example, a failed
+submission can require an announced error, retained input and a usable retry;
+the exact behavior must follow the product's actual needs.
+
+The report lists supplied inputs, changed design artifacts and what has been
+specified, implemented and verified separately. Use the invoked workflow's
+report path or the user's requested canonical destination.
+
+## Acceptance and continuation
+
+The main task and relevant failure paths must be understandable without guessing
+missing states. Important visual and accessibility decisions need checkable
+criteria. Do not report user validation, rendering verification or accessibility
+conformance that was not performed.
+
+On resume, compare requirements, component versions and previous decisions.
+Revisit affected flows and states, preserve unaffected user edits and rerun
+checks whose inputs changed. Hand off feasibility questions to
+[Architecture](../architecture/create-architecture.md) or implementation work to
+[Quick development](../implementation/quick-dev.md) only within the active task.