Wx_WxCheck_Prod/.amazonq/prompts/openspec-proposal.md

description

description
Scaffold a new OpenSpec change and validate strictly.

The user has requested the following change proposal. Use the openspec instructions to create their change proposal.

$ARGUMENTS **Guardrails** - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. - Keep changes tightly scoped to the requested outcome. - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. - Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files. - Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.

Steps

1. Review openspec/project.md, run openspec list and openspec list --specs, and inspect related code or docs (e.g., via rg/ls) to ground the proposal in current behaviour; note any gaps that require clarification.
2. Choose a unique verb-led change-id and scaffold proposal.md, tasks.md, and design.md (when needed) under openspec/changes/<id>/.
3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
4. Capture architectural reasoning in design.md when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
5. Draft spec deltas in changes/<id>/specs/<capability>/spec.md (one folder per capability) using ## ADDED|MODIFIED|REMOVED Requirements with at least one #### Scenario: per requirement and cross-reference related capabilities when relevant.
6. Draft tasks.md as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
7. Validate with openspec validate <id> --strict and resolve every issue before sharing the proposal.

Reference

• Use openspec show <id> --json --deltas-only or openspec show <spec> --type spec to inspect details when validation fails.
• Search existing requirements with rg -n "Requirement:|Scenario:" openspec/specs before writing new ones.
• Explore the codebase with rg <keyword>, ls, or direct file reads so proposals align with current implementation realities.