281 lines
13 KiB
YAML
281 lines
13 KiB
YAML
version: 1
|
||
|
||
file_associations:
|
||
"request.md": "feature_request"
|
||
"feature.discussion.md": "feature_discussion_update"
|
||
"feature.discussion.sum.md": "discussion_summary"
|
||
"design.discussion.md": "design_discussion_update"
|
||
"design.discussion.sum.md": "discussion_summary"
|
||
"implementation.discussion.md": "implementation_discussion_update"
|
||
"implementation.discussion.sum.md": "discussion_summary"
|
||
|
||
rules:
|
||
feature_request:
|
||
outputs:
|
||
feature_discussion:
|
||
path: "Docs/features/{feature_id}/discussions/feature.discussion.md"
|
||
output_type: "feature_discussion_writer"
|
||
design_gate:
|
||
path: "Docs/features/{feature_id}/discussions/design.discussion.md"
|
||
output_type: "design_gate_writer"
|
||
|
||
feature_discussion_update:
|
||
participants:
|
||
- { path: "agents/moderator.py" }
|
||
- { path: "agents/designer.py" }
|
||
- { path: "agents/visualizer.py", background: true }
|
||
- { path: "agents/researcher.py", background: true }
|
||
outputs:
|
||
self_append:
|
||
path: "{path}"
|
||
output_type: "feature_discussion_writer"
|
||
design_gate:
|
||
path: "Docs/features/{feature_id}/discussions/design.discussion.md"
|
||
output_type: "design_gate_writer"
|
||
|
||
design_discussion_update:
|
||
participants:
|
||
- { path: "agents/moderator.py" }
|
||
- { path: "agents/designer.py" }
|
||
- { path: "agents/visualizer.py", background: true }
|
||
- { path: "agents/researcher.py", background: true }
|
||
outputs:
|
||
self_append:
|
||
path: "{path}"
|
||
output_type: "design_discussion_writer"
|
||
implementation_gate:
|
||
path: "Docs/features/{feature_id}/discussions/implementation.discussion.md"
|
||
output_type: "implementation_gate_writer"
|
||
design_doc:
|
||
path: "Docs/features/{feature_id}/design/design.md"
|
||
output_type: "design_doc_writer"
|
||
implementation_tasks:
|
||
path: "Docs/features/{feature_id}/implementation/tasks.md"
|
||
output_type: "implementation_tasks_writer"
|
||
implementation_plan:
|
||
path: "Docs/features/{feature_id}/implementation/plan.md"
|
||
output_type: "implementation_plan_writer"
|
||
|
||
implementation_discussion_update:
|
||
participants:
|
||
- { path: "agents/moderator.py" }
|
||
- { path: "agents/designer.py" }
|
||
- { path: "agents/visualizer.py", background: true }
|
||
- { path: "agents/researcher.py", background: true }
|
||
outputs:
|
||
self_append:
|
||
path: "{path}"
|
||
output_type: "impl_discussion_writer"
|
||
|
||
discussion_summary:
|
||
outputs:
|
||
normalize:
|
||
path: "{path}"
|
||
output_type: "discussion_summary_normalizer"
|
||
instruction: |
|
||
If missing, create summary with standard markers. Only modify the content between the SUMMARY markers.
|
||
|
||
implementation_tasks_writer:
|
||
model_hint: fast
|
||
instruction: |
|
||
Create the implementation tasks file from the design discussion.
|
||
- Locate the sibling design discussion (`design.discussion.md`).
|
||
- Read its YAML header. Only create/update this implementation file when that header shows `status: READY_FOR_IMPLEMENTATION`.
|
||
- If the status is `OPEN` or `DESIGN_REJECTED`, produce **no diff**.
|
||
- The tasks should be a checklist of concrete steps (Markdown checkboxes) based on the design discussion.
|
||
- Include assignees or related PR/issue identifiers inline when available.
|
||
|
||
implementation_plan_writer:
|
||
model_hint: quality
|
||
instruction: |
|
||
Draft the implementation plan from the approved design discussion.
|
||
- Locate the sibling design discussion (`design.discussion.md`).
|
||
- Only create/update this plan when the design status is `READY_FOR_IMPLEMENTATION`; otherwise emit **no diff**.
|
||
- Summarise the rollout approach (Overview), key milestones, dependencies, deployment/rollback considerations, and open questions.
|
||
- Keep sections idempotent; append incremental notes rather than rewriting the entire document each run.
|
||
|
||
feature_discussion_writer:
|
||
model_hint: fast # Simple vote counting and comment appending - use fast models
|
||
instruction: |
|
||
You maintain the feature discussion derived from the feature request.
|
||
|
||
If the discussion file is missing:
|
||
- Create it with this header (respect spacing/keys):
|
||
---
|
||
type: feature-discussion
|
||
stage: feature
|
||
status: OPEN
|
||
feature_id: <match the feature id from request.md>
|
||
created: <today in YYYY-MM-DD>
|
||
promotion_rule:
|
||
allow_agent_votes: false
|
||
ready_min_eligible_votes: 2
|
||
reject_min_eligible_votes: 1
|
||
participation:
|
||
instructions: |
|
||
- Use this structure for each comment:
|
||
Name: <your name>
|
||
<multiline feedback with QUESTION:/TODO:/DECISION: markers>
|
||
VOTE: READY|CHANGES|REJECT
|
||
- Agents/bots must prefix names with "AI_". Example: "AI_Claude"
|
||
voting:
|
||
values: [READY, CHANGES, REJECT]
|
||
---
|
||
- Add sections:
|
||
## Summary – one short paragraph summarising the request
|
||
## Participation – reminder list of how to comment & vote
|
||
- Append an initial comment using this structure, signed `AI_Claude` and ending with a vote line.
|
||
|
||
If the discussion exists:
|
||
- Append a concise AI_Claude comment using the same Name/Comment/VOTE structure.
|
||
- Always end with exactly one vote line: `VOTE: READY`, `VOTE: CHANGES`, or `VOTE: REJECT`.
|
||
|
||
Voting & promotion rules:
|
||
- Read `promotion_rule` from the header.
|
||
- Eligible voters:
|
||
* allow_agent_votes=false → ignore names starting with "AI_" (case-insensitive)
|
||
* allow_agent_votes=true → everyone counts
|
||
- For each participant the most recent vote wins. A vote is a line matching `VOTE:\s*(READY|CHANGES|REJECT)`.
|
||
- Count READY and REJECT votes among eligible voters. CHANGES is neutral (and blocks `ready_min_eligible_votes: "all"`).
|
||
- Threshold interpretation:
|
||
* Integer `N` → require at least `N` votes.
|
||
* `"all"` → require a vote from every eligible voter (and none opposing for READY).
|
||
* If there are no eligible voters the `"all"` condition never passes.
|
||
- Promotion (`status: READY_FOR_DESIGN`):
|
||
* READY threshold satisfied AND REJECT threshold NOT satisfied.
|
||
- Rejection (`status: FEATURE_REJECTED`):
|
||
* REJECT threshold satisfied AND READY threshold NOT satisfied.
|
||
- Otherwise keep `status: OPEN`.
|
||
- When the status changes, update the header and state the outcome explicitly in your comment.
|
||
|
||
Output requirements:
|
||
- Emit a single unified diff touching only this discussion file.
|
||
- Keep diffs minimal (append-only plus header adjustments).
|
||
|
||
design_gate_writer:
|
||
model_hint: fast # Simple gate checking and file creation - use fast models
|
||
instruction: |
|
||
Create or update the design discussion located at the path provided.
|
||
|
||
Creation criteria:
|
||
- Locate the sibling feature discussion (`feature.discussion.md`).
|
||
- Read its YAML header. Only create/update this design file when that header shows `status: READY_FOR_DESIGN`.
|
||
- If the status is `OPEN` or `FEATURE_REJECTED`, produce **no diff**.
|
||
|
||
When creating the design discussion:
|
||
---
|
||
type: design-discussion
|
||
stage: design
|
||
status: OPEN
|
||
feature_id: <same feature id as the source request>
|
||
created: <today in YYYY-MM-DD>
|
||
promotion_rule:
|
||
allow_agent_votes: false
|
||
ready_min_eligible_votes: 2
|
||
reject_min_eligible_votes: 1
|
||
participation:
|
||
instructions: |
|
||
- Use this structure for each comment:
|
||
Name: <your name>
|
||
<multiline design notes with DECISION:/TODO:/QUESTION: markers>
|
||
VOTE: READY|CHANGES|REJECT
|
||
- Agents/bots must prefix names with "AI_".
|
||
voting:
|
||
values: [READY, CHANGES, REJECT]
|
||
---
|
||
Sections to include:
|
||
## Summary – brief overview of design goals
|
||
## Architecture – component interactions, system structure
|
||
## Technology Choices – frameworks, libraries, rationale
|
||
## Data Models – schemas, API contracts
|
||
## Risks / Trade-offs – known concerns or alternatives
|
||
|
||
Subsequent updates:
|
||
- Keep diffs minimal, amending sections in place.
|
||
- Do not change status automatically; human votes or policies will manage it.
|
||
|
||
Output a unified diff for this file only. If no changes are required, emit nothing.
|
||
|
||
design_discussion_writer:
|
||
model_hint: quality # Complex architecture and design work - use quality models
|
||
instruction: |
|
||
You maintain the design discussion derived from the feature discussion.
|
||
|
||
If the discussion file is missing:
|
||
- Create it with the same YAML header structure as feature discussions (see design_gate_writer).
|
||
- Add sections:
|
||
## Summary – brief overview linking to feature request
|
||
## Architecture – system design and component interactions
|
||
## Technology Stack – chosen technologies and rationale
|
||
## Data Models & APIs – schemas, contracts, endpoints
|
||
## Acceptance Criteria – measurable design quality gates
|
||
## Risks / Trade-offs – known concerns or alternatives
|
||
- Append an initial comment using the Name/Comment/VOTE structure, signed `AI_Claude`.
|
||
|
||
If the discussion exists:
|
||
- Append a concise AI_Claude comment using the same structure.
|
||
- Always end with exactly one vote line: `VOTE: READY`, `VOTE: CHANGES`, or `VOTE: REJECT`.
|
||
|
||
Voting & promotion rules:
|
||
- Read `promotion_rule` from the header (same logic as feature_discussion_writer).
|
||
- Eligible voters:
|
||
* allow_agent_votes=false → ignore names starting with "AI_" (case-insensitive)
|
||
* allow_agent_votes=true → everyone counts
|
||
- For each participant the most recent vote wins. A vote is a line matching `VOTE:\s*(READY|CHANGES|REJECT)`.
|
||
- Count READY and REJECT votes among eligible voters. CHANGES is neutral.
|
||
- Threshold interpretation:
|
||
* Integer `N` → require at least `N` votes.
|
||
* `"all"` → require a vote from every eligible voter (and none opposing for READY).
|
||
* If there are no eligible voters the `"all"` condition never passes.
|
||
- Promotion (`status: READY_FOR_IMPLEMENTATION`):
|
||
* READY threshold satisfied AND REJECT threshold NOT satisfied.
|
||
- Rejection (`status: DESIGN_REJECTED`):
|
||
* REJECT threshold satisfied AND READY threshold NOT satisfied.
|
||
- Otherwise keep `status: OPEN`.
|
||
- When the status changes, update the header and state the outcome explicitly in your comment.
|
||
|
||
Output requirements:
|
||
- Emit a single unified diff touching only this discussion file.
|
||
- Keep diffs minimal (append-only plus header adjustments).
|
||
|
||
implementation_gate_writer:
|
||
model_hint: fast # Simple gate checking and file creation - use fast models
|
||
instruction: |
|
||
Create or update the implementation discussion located at the path provided.
|
||
|
||
Creation criteria:
|
||
- Locate the sibling design discussion (`design.discussion.md`).
|
||
- Read its YAML header. Only create/update this implementation file when that header shows `status: READY_FOR_IMPLEMENTATION`.
|
||
- If the status is `OPEN` or `DESIGN_REJECTED`, produce **no diff**.
|
||
|
||
When creating the implementation discussion:
|
||
---
|
||
type: implementation-discussion
|
||
stage: implementation
|
||
status: OPEN
|
||
feature_id: <same feature id as the source request>
|
||
created: <today in YYYY-MM-DD>
|
||
---
|
||
Sections to include:
|
||
## Scope – high-level intent
|
||
## Tasks – checklist of concrete steps (Markdown checkboxes)
|
||
## Acceptance Criteria – bullet list
|
||
## Risks / Notes – known concerns or follow-ups
|
||
|
||
Subsequent updates:
|
||
- Keep diffs minimal, amending sections in place.
|
||
- Do not change status automatically; human votes or policies will manage it.
|
||
|
||
Output a unified diff for this file only. If no changes are required, emit nothing.
|
||
|
||
impl_discussion_writer:
|
||
model_hint: quality # Implementation planning requires careful task breakdown - use quality models
|
||
instruction: |
|
||
Append planning updates to the implementation discussion in an incremental, checklist-driven style.
|
||
- Work within the existing sections (Scope, Tasks, Acceptance Criteria, Risks / Notes).
|
||
- Prefer adding or checking off checklist items rather than rewriting history.
|
||
- Whenever you add or complete work, update the local checklist in the **Tasks** section (use `- [ ]` and `- [x]`), referencing owners/PR links inline.
|
||
- Cite corresponding entries in `implementation/tasks.md` (the workflow mirrors these checkboxes automatically).
|
||
- Keep each comment short and concrete (one or two sentences plus list updates).
|
||
- Do not close the discussion automatically; maintainers handle status transitions. If work is done, note it and leave the READY vote for humans.
|