Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-03-23 09:35:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(orchestrator): add Discuss Phase and PRD creation workflow (#1124)

Browse Source 
* feat(orchestrator): add Discuss Phase and PRD creation workflow

- Introduce Discuss Phase for medium/complex objectives, generating context‑aware options and logging architectural decisions
- Add PRD creation step after discussion, storing the PRD in docs/prd.yaml
- Refactor Phase 1 to pass task clarifications to researchers
- Update Phase 2 planning to include multi‑plan selection for complex tasks and verification with gem‑reviewer
- Enhance Phase 3 execution loop with wave integration checks and conflict filtering

* feat(gem-team): bump version to 1.3.3 and refine description with Discuss Phase and PRD compliance verification
This commit is contained in:
Muhammad Ubaid Raza
2026-03-23 05:35:01 +05:00
committed by GitHub
parent b3de20181a
commit 80b2129888
8 changed files with 198 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
agents/gem-planner.agent.md
View File

@@ -31,7 +31,8 @@ gem-researcher, gem-planner, gem-implementer, gem-browser-tester, gem-devops, ge
- Read efficiently: tldr + metadata first, detailed sections as needed
- SELECTIVE RESEARCH CONSUMPTION: Read tldr + research_metadata.confidence + open_questions first (≈30 lines). Target-read specific sections (files_analyzed, patterns_found, related_architecture) ONLY for gaps identified in open_questions. Do NOT consume full research files - ETH Zurich shows full context hurts performance.
- READ GLOBAL RULES: If AGENTS.md exists at root, read it to align plan with global project conventions and architectural preferences.
- VALIDATE AGAINST PRD: If docs/prd.yaml exists, read it. Validate new plan doesn't conflict with existing features, state machines, decisions. Flag conflicts for user feedback.
- READ PRD (prd_path): Read user_stories, scope (in_scope/out_of_scope), acceptance_criteria, needs_clarification. These are the source of truth — plan must satisfy all acceptance_criteria, stay within in_scope, exclude out_of_scope.
- APPLY TASK CLARIFICATIONS: If task_clarifications is non-empty, read and lock these decisions into the DAG design. Task-specific clarifications become constraints on task descriptions and acceptance criteria. Do NOT re-question these — they are resolved.
- initial: no plan.yaml → create new
- replan: failure flag OR objective changed → rebuild DAG
- extension: additive objective → append tasks
@@ -67,7 +68,9 @@ gem-researcher, gem-planner, gem-implementer, gem-browser-tester, gem-devops, ge
"plan_id": "string",
"variant": "a | b | c (optional - for multi-plan)",
"objective": "string", // Extracted objective from user request or task_definition
"complexity": "simple|medium|complex" // Required for pre-mortem logic
"complexity": "simple|medium|complex", // Required for pre-mortem logic
"task_clarifications": "array of {question, answer} from Discuss Phase (empty if skipped)",
"prd_path": "string (path to docs/prd.yaml)"
}
```
@@ -148,6 +151,9 @@ tasks:
status: string # pending | in_progress | completed | failed | blocked | needs_revision
dependencies:
- string
parallelizable: boolean # true = can sub-agent parallelize within wave (default: false)
conflicts_with:
- string # Task IDs that touch same files — runs serially even if dependencies allow parallel
context_files:
- string: string
estimated_effort: string # small | medium | large