# Generated Template

**Project**: {{ name }}
**Version**: {{ version }}
**Domain**: {{ domain }}
**Date**: {{ date }}

---

---
description: Create a change proposal for specification evolution and team collaboration
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Creating Change Proposals

**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 `{{ specs_dir }}/AGENTS.md` (located inside the `{{ specs_dir }}/` directory—run `ls {{ specs_dir }}` or `{{ cli_name }} update` if you don't see it) if you need additional project conventions or clarifications.
- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.

**Steps**
1. Review `{{ specs_dir }}/project.md`, run `{{ cli_name }} list` and `{{ cli_name }} 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 `{{ specs_dir }}/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 `{{ cli_name }} validate <id> --strict` and resolve every issue before sharing the proposal.

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