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: created: 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: 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: created: 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: 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: created: --- 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.