Menu
提取下游代理所需的实施决策。分析阶段以识别灰色地带，与用户讨论，并为研究和计划捕获决策。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | discuss-phase |
| description | 提取下游代理所需的实施决策。分析阶段以识别灰色地带，与用户讨论，并为研究和计划捕获决策。 |
<downstream_awareness> CONTEXT.md feeds into:
gsd-phase-researcher — Reads CONTEXT.md to know WHAT to research
gsd-planner — Reads CONTEXT.md to know WHAT decisions are locked
Your job: Capture decisions clearly enough that downstream agents can act on them without asking the user again.
Not your job: Figure out HOW to implement. That's what research and planning do with the decisions you capture. </downstream_awareness>
**User = founder/visionary. Copilot = builder.**The user knows:
The user doesn't know (and shouldn't be asked):
Ask about vision and implementation choices. Capture decisions for downstream agents.
<scope_guardrail> CRITICAL: No scope creep.
The phase boundary comes from ROADMAP.md and is FIXED. Discussion clarifies HOW to implement what's scoped, never WHETHER to add new capabilities.
Allowed (clarifying ambiguity):
Not allowed (scope creep):
The heuristic: Does this clarify how we implement what's already in the phase, or does it add a new capability that could be its own phase?
When user suggests scope creep:
"[Feature X] would be a new capability — that's its own phase.
Want me to note it for the roadmap backlog?
For now, let's focus on [phase domain]."
Capture the idea in a "Deferred Ideas" section. Don't lose it, don't act on it. </scope_guardrail>
<gray_area_identification> Gray areas are implementation decisions the user cares about — things that could go multiple ways and would change the result.
How to identify gray areas:
Don't use generic category labels (UI, UX, Behavior). Generate specific gray areas:
Phase: "User authentication"
→ Session handling, Error responses, Multi-device policy, Recovery flow
Phase: "Organize photo library"
→ Grouping criteria, Duplicate handling, Naming convention, Folder structure
Phase: "CLI for database backups"
→ Output format, Flag design, Progress reporting, Error recovery
Phase: "API documentation"
→ Structure/navigation, Code examples depth, Versioning approach, Interactive elements
The key question: What decisions would change the outcome that the user should weigh in on?
Copilot handles these (don't ask):
Load and validate:
.gsd/ROADMAP.mdIf phase not found:
Phase [X] not found in roadmap.
Use /progress.md to see available phases.
Exit workflow.
If phase found: Continue to analyze_phase.
Check if CONTEXT.md already exists:# Match both zero-padded (05-*) and unpadded (5-*) folders
PADDED_PHASE=$(printf "%02d" ${PHASE})
ls .gsd/phases/${PADDED_PHASE}-*/*-CONTEXT.md .gsd/phases/${PHASE}-*/*-CONTEXT.md 2>/dev/null
If exists: Use HumanAgent MCP (HumanAgent_Chat):
If "Update": Load existing, continue to analyze_phase If "View": Display CONTEXT.md, then offer update/skip If "Skip": Exit workflow
If doesn't exist: Continue to analyze_phase.
Analyze the phase to identify gray areas worth discussing.Read the phase description from ROADMAP.md and determine:
Domain boundary — What capability is this phase delivering? State it clearly.
Gray areas by category — For each relevant category (UI, UX, Behavior, Empty States, Content), identify 1-2 specific ambiguities that would change implementation.
Skip assessment — If no meaningful gray areas exist (pure infrastructure, clear-cut implementation), the phase may not need discussion.
Output your analysis internally, then present to user.
Example analysis for "Post Feed" phase:
Domain: Displaying posts from followed users
Gray areas:
- UI: Layout style (cards vs timeline vs grid)
- UI: Information density (full posts vs previews)
- Behavior: Loading pattern (infinite scroll vs pagination)
- Empty State: What shows when no posts exist
- Content: What metadata displays (time, author, reactions count)
First, state the boundary:
Phase [X]: [Name]
Domain: [What this phase delivers — from your analysis]
We'll clarify HOW to implement this.
(New capabilities belong in other phases.)
Then use HumanAgent MCP (HumanAgent_Chat) (multiSelect: true):
Do NOT include a "skip" or "you decide" option. User ran this command to discuss — give them real choices.
Examples by domain:
For "Post Feed" (visual feature):
☐ Layout style — Cards vs list vs timeline? Information density?
☐ Loading behavior — Infinite scroll or pagination? Pull to refresh?
☐ Content ordering — Chronological, algorithmic, or user choice?
☐ Post metadata — What info per post? Timestamps, reactions, author?
For "Database backup CLI" (command-line tool):
☐ Output format — JSON, table, or plain text? Verbosity levels?
☐ Flag design — Short flags, long flags, or both? Required vs optional?
☐ Progress reporting — Silent, progress bar, or verbose logging?
☐ Error recovery — Fail fast, retry, or prompt for action?
For "Organize photo library" (organization task):
☐ Grouping criteria — By date, location, faces, or events?
☐ Duplicate handling — Keep best, keep all, or prompt each time?
☐ Naming convention — Original names, dates, or descriptive?
☐ Folder structure — Flat, nested by year, or by category?
Continue to discuss_areas with selected areas.
For each selected area, conduct a focused discussion loop.Philosophy: 4 questions, then check.
Ask 4 questions per area before offering to continue or move on. Each answer often reveals the next question.
For each area:
Announce the area:
Let's talk about [Area].
Ask 4 questions using HumanAgent MCP (HumanAgent_Chat):
After 4 questions, check:
If "More questions" → ask 4 more, then check again If "Next area" → proceed to next selected area
After all areas complete:
Question design:
Scope creep handling: If user mentions something outside the phase domain:
"[Feature] sounds like a new capability — that belongs in its own phase.
I'll note it as a deferred idea.
Back to [current area]: [return to current question]"
Track deferred ideas internally.
Create CONTEXT.md capturing decisions made.Find or create phase directory:
# Match existing directory (padded or unpadded)
PADDED_PHASE=$(printf "%02d" ${PHASE})
PHASE_DIR=$(ls -d .gsd/phases/${PADDED_PHASE}-* .gsd/phases/${PHASE}-* 2>/dev/null | head -1)
if [ -z "$PHASE_DIR" ]; then
# Create from roadmap name (lowercase, hyphens)
PHASE_NAME=$(grep "Phase ${PHASE}:" .gsd/ROADMAP.md | sed 's/.*Phase [0-9]*: //' | tr '[:upper:]' '[:lower:]' | tr ' ' '-')
mkdir -p ".gsd/phases/${PADDED_PHASE}-${PHASE_NAME}"
PHASE_DIR=".gsd/phases/${PADDED_PHASE}-${PHASE_NAME}"
fi
File location: ${PHASE_DIR}/${PADDED_PHASE}-CONTEXT.md
Structure the content by what was discussed:
# Phase [X]: [Name] - Context
**Gathered:** [date]
**Status:** Ready for planning
<domain>
## Phase Boundary
[Clear statement of what this phase delivers — the scope anchor]
</domain>
<decisions>
## Implementation Decisions
### [Category 1 that was discussed]
- [Decision or preference captured]
- [Another decision if applicable]
### [Category 2 that was discussed]
- [Decision or preference captured]
### Copilot's Discretion
[Areas where user said "you decide" — note that Copilot has flexibility here]
</decisions>
<specifics>
## Specific Ideas
[Any particular references, examples, or "I want it like X" moments from discussion]
[If none: "No specific requirements — open to standard approaches"]
</specifics>
<deferred>
## Deferred Ideas
[Ideas that came up but belong in other phases. Don't lose them.]
[If none: "None — discussion stayed within phase scope"]
</deferred>
---
_Phase: XX-name_
_Context gathered: [date]_
Write file.
Present summary and next steps:Created: .gsd/phases/${PADDED_PHASE}-${SLUG}/${PADDED_PHASE}-CONTEXT.md
## Decisions Captured
### [Category]
- [Key decision]
### [Category]
- [Key decision]
[If deferred ideas exist:]
## Noted for Later
- [Deferred idea] — future phase
---
## ▶ Next Up
**Phase ${PHASE}: [Name]** — [Goal from ROADMAP.md]
`/plan-phase.md ${PHASE}`
<sub>`/clear` first → fresh context window</sub>
---
**Also available:**
- `/plan-phase.md ${PHASE} --skip-research` — plan without research
- Review/edit CONTEXT.md before continuing
---
Check planning config:
COMMIT_PLANNING_DOCS=$(cat .gsd/config.json 2>/dev/null | grep -o '"commit_docs"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")
git check-ignore -q .gsd 2>/dev/null && COMMIT_PLANNING_DOCS=false
If COMMIT_PLANNING_DOCS=false: Skip git operations
If COMMIT_PLANNING_DOCS=true (default):
git add "${PHASE_DIR}/${PADDED_PHASE}-CONTEXT.md"
git commit -m "$(cat <<'EOF'
docs(${PADDED_PHASE}): capture phase context
Phase ${PADDED_PHASE}: ${PHASE_NAME}
- Implementation decisions documented
- Phase boundary established
EOF
)"
Confirm: "Committed: docs(${PADDED_PHASE}): capture phase context"
<success_criteria>
将已发布版本（v1.0、v1.1、v2.0）标记为完成。在 MILESTONES.md 中创建历史记录，执行 PROJECT.md 演进审查，重组 ROADMAP.md，并在 git 中打标签。
编排并行调试代理以调查 UAT 差距并查找根本原因。按差距生成调试代理，收集诊断结果，更新 UAT.md。
以适当的深度级别执行发现。生成 DISCOVERY.md 用于指导 PLAN.md 的创建。支持快速验证、标准和深度模式。
使用波次并行执行阶段中的所有计划。编排器将计划执行委托给子代理，管理波次和检查点。
执行阶段提示（PLAN.md）并创建结果摘要（SUMMARY.md）。处理任务执行并集成 git。
在计划之前揭示 Copilot 对阶段的假设，使用户能够尽早纠正误解。纯对话式分析。