kata-discuss-phase

Gather phase context through adaptive questioning before planning, clarifying implementation decisions, or exploring gray areas for a phase. Triggers include "discuss phase", "clarify phase", "gather context", "what are the gray areas", and "phase discussion".

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "kata-discuss-phase" with this command: npx skills add gannonh/kata-skills/gannonh-kata-skills-kata-discuss-phase

<objective> Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.

How it works:

  1. Analyze the phase to identify gray areas (UI, UX, behavior, etc.)
  2. Present gray areas — user selects which to discuss
  3. Deep-dive each selected area until satisfied
  4. Create CONTEXT.md with decisions that guide research and planning

Output: {phase}-CONTEXT.md — decisions clear enough that downstream agents can act without asking the user again </objective>

<execution_context> @./references/phase-discuss.md @./references/context-template.md </execution_context>

<context> Phase number: $ARGUMENTS (required)

Load project state: @.planning/STATE.md

Load roadmap: @.planning/ROADMAP.md </context>

<process> 1. Validate phase number (error if missing or not in roadmap) 2. Check if CONTEXT.md exists (offer update/view/skip if yes) 3. **Analyze phase** — Identify domain and generate phase-specific gray areas 4. **Present gray areas** — Multi-select: which to discuss? (NO skip option) 5. **Deep-dive each area** — 4 questions per area, then offer more/next 6. **Write CONTEXT.md** — Sections match areas discussed 7. Offer next steps (research or plan)

CRITICAL: Scope guardrail

  • Phase boundary from ROADMAP.md is FIXED
  • Discussion clarifies HOW to implement, not WHETHER to add more
  • If user suggests new capabilities: "That's its own phase. I'll note it for later."
  • Capture deferred ideas — don't lose them, don't act on them

Domain-aware gray areas: Gray areas depend on what's being built. Analyze the phase goal:

  • Something users SEE → layout, density, interactions, states
  • Something users CALL → responses, errors, auth, versioning
  • Something users RUN → output format, flags, modes, error handling
  • Something users READ → structure, tone, depth, flow
  • Something being ORGANIZED → criteria, grouping, naming, exceptions

Generate 3-4 phase-specific gray areas, not generic categories.

Probing depth:

  • Ask 4 questions per area before checking
  • "More questions about [area], or move to next?"
  • If more → ask 4 more, check again
  • After all areas → "Ready to create context?"

Do NOT ask about (Claude handles these):

  • Technical implementation
  • Architecture choices
  • Performance concerns
  • Scope expansion </process>

<success_criteria>

  • Gray areas identified through intelligent analysis
  • User chose which areas to discuss
  • Each selected area explored until satisfied
  • Scope creep redirected to deferred ideas
  • CONTEXT.md captures decisions, not vague vision
  • User knows next steps </success_criteria>

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

kata-resume-work

No summary provided by upstream source.

Repository SourceNeeds Review
General

kata-review-pull-requests

No summary provided by upstream source.

Repository SourceNeeds Review
General

kata-add-issue

No summary provided by upstream source.

Repository SourceNeeds Review
General

kata-list-phase-assumptions

No summary provided by upstream source.

Repository SourceNeeds Review