user-request

name	user-request
description	Capture user feature request verbatim (Phase 1)

User Request (Phase 1)

Command: pasture:user:request — Capture user feature request verbatim (Phase 1)

-> Full workflow in PROCESS.md <- Phase 1

[user-req-verbatim-capture]

• Given: user provides request
• When: capturing
• Then: store verbatim without paraphrasing
• Should not: summarize or interpret

[user-req-classify-label]

• Given: request captured
• When: classifying
• Then: use pasture:p1-user:s1_1-classify label
• Should not: use other labels for the initial capture

[user-req-research-depth]

• Given: classification complete
• When: user confirms research depth
• Then: run s1_2-research and s1_3-explore in parallel
• Should not: skip research depth confirmation

[user-req-proceed-to-elicit]

• Given: Phase 1 complete
• When: proceeding
• Then: invoke /pasture:user-elicit for Phase 2
• Should not: skip to proposal

[user-req-fix-intent]

• Given: a request whose user intent is to FIX existing behavior (a bug, regression, or incorrect output)
• When: classifying in Phase 1
• Then: recognize the fix-intent SEMANTICALLY during classification (record it in the classification comment) so the downstream URE/UAT/impl validation cases capture the currently-failing behaviours; validation cases themselves are elicited for EVERY request regardless
• Should not: introduce a request-type axis or enum to detect fix-intent — recognition is semantic, not a fifth classification axis; gate validation cases on fix-intent

[frag--validation-cases]

• Given: any REQUEST (every request, not only fix-intent ones)
• When: eliciting (URE), acceptance-testing (UAT), or implementing
• Then: elicit concrete validation cases — a definition of done plus correct and incorrect behaviours (inputs/behaviors that must pass or must fail), confirm the case set with the user in UAT, evaluate the implementation against them, and store failing real-data cases as test fixtures
• Should not: ship without validation cases; treat validation cases as applying to fix-intent requests only; introduce a request-type axis or enum to gate them

Phase 1 Sub-steps

Sub-step	Label	Description	Parallel?
s1_1-classify	pasture:p1-user:s1_1-classify	Capture verbatim + classify along 4 axes	Sequential (first)
s1_2-research	pasture:p1-user:s1_2-research	Find domain standards, prior art	Parallel with s1_3
s1_3-explore	pasture:p1-user:s1_3-explore	Codebase exploration for integration points	Parallel with s1_2

Step 1: Capture and Classify (s1_1)

Capture verbatim and create the request task

1. Get the user's request verbatim:

   AskUserQuestion: "What feature or change would you like to request?"
   

2. Create the request task:

   bd create --labels "pasture:p1-user:s1_1-classify" \
     --title "REQUEST: {{short summary}}" \
     --description "{{VERBATIM user request - do not edit}}" \
     --assignee architect
   

3. Classify along 4 axes:

   • Scope: Single file, module, cross-cutting
   • Complexity: Low, medium, high
   • Risk: Breaking changes, new API, internal-only
   • Domain novelty: Familiar patterns vs new territory

4. Record classification via comment on the request task:

   bd comments add {{request-task-id}} \
     "Classification: scope={{scope}}, complexity={{complexity}}, risk={{risk}}, novelty={{novelty}}"
   

Recognize fix-intent (semantic, NOT a classification axis)

Separately from the 4 axes above, judge semantically whether the user's intent is to FIX existing behavior (a bug, regression, or wrong output) versus build something new. This is a recognition step, not a fifth axis and not a request-type enum — do not add a typed field for it.

When the intent is to fix existing behavior, the validation-case lifecycle applies for the rest of the epoch: concrete failing/expected cases are elicited in URE (/pasture:user-elicit), confirmed with the user in UAT (/pasture:user-uat), evaluated against the fix, and the failing real-data cases are stored as test fixtures.

Record the recognition in the same classification comment so downstream phases pick it up:

bd comments add {{request-task-id}} \
  "Fix-intent: yes — validation-case lifecycle applies (elicit cases in URE, confirm in UAT, store as fixtures)"

Step 2: Research Depth Confirmation

After classification, confirm research depth with the user:

AskUserQuestion:
  question: "Based on classification ({{scope}}, {{complexity}}, {{risk}}, {{novelty}}), how deep should research go?"
  header: "Research Depth"
  options:
    - label: "Quick scan"
      description: "Familiar domain, low complexity — brief prior art check"
    - label: "Standard research"
      description: "Moderate complexity or some novelty — find existing patterns and standards"
    - label: "Deep dive"
      description: "High complexity, new territory, or high risk — thorough domain analysis"

Step 3: Record Depth + Spawn Parallel Agents (s1_2 || s1_3)

Record depth and spawn agents

Record the user's depth choice, then spawn two parallel agents:

bd comments add {{request-task-id}} \
  "Research depth: {{depth}} (user confirmed)"

Spawn both agents in parallel (via Task tool with run_in_background: true). Each agent invokes its dedicated skill.

s1_2-research: Domain Research

Invoke /pasture:research with:

• topic: derived from the user's request
• depth: the user-confirmed research depth
• request-task-id: the REQUEST beads task ID

The /pasture:research skill handles the full research workflow: depth-scoped checklist, structured report written to docs/research/<topic>.md, and summary comment on the REQUEST task.

See skills/research/SKILL.md for full procedure, output format, and examples.

Depth determines scope:

Depth	Local	Web	Deliverable
Quick scan	Grep project for related patterns, check README/docs	None	1-paragraph summary of local findings
Standard research	Local scan + check project dependencies, related repos	Search for domain standards, established patterns	List of prior art with relevance notes
Deep dive	Full local analysis + dependency tree	Search for competing solutions, RFCs, academic papers, well-regarded projects	Structured report: standards found, competing approaches, recommended direction

Research checklist:

1. What domain standards exist? (RFCs, specs, community conventions)
2. What well-regarded projects solve similar problems? (prior art)
3. What patterns are established in this domain? (idioms, best practices)
4. Are there existing solutions that could be reused or adapted?

Record findings as a comment on the REQUEST task:

bd comments add {{request-task-id}} \
  "Research findings ({{depth}}):
  - Standards: {{list or 'none found'}}
  - Prior art: {{list of projects/solutions}}
  - Patterns: {{established approaches}}
  - Recommendation: {{brief direction}}
  - Full report: docs/research/{{topic}}.md"

s1_3-explore: Codebase Exploration

Invoke /pasture:explore with:

• topic: derived from the user's request
• depth: the user-confirmed research depth (same depth applies)
• request-task-id: the REQUEST beads task ID

The /pasture:explore skill handles the full exploration workflow: depth-scoped checklist, structured findings, and summary comment on the REQUEST task.

See skills/explore/SKILL.md for full procedure, output format, and examples.

Exploration checklist:

1. Entry points: Where would this feature plug in? (CLI commands, API routes, event handlers)
2. Data flow: What existing data structures, types, or schemas are relevant?
3. Dependencies: What modules/packages would this feature depend on or extend?
4. Existing patterns: How do similar features work in this codebase? (conventions, DI patterns, test structure)
5. Conflicts: Are there existing implementations that would need modification or could conflict?

Depth determines thoroughness:

Depth	Scope	Tools
Quick scan	Grep for keywords, check obvious entry points	Glob, Grep
Standard research	Trace data flow, map dependencies, read related modules	Glob, Grep, Read
Deep dive	Full dependency graph, architectural analysis, identify all touchpoints	Glob, Grep, Read, Bash (for build/dep tools)

Record findings as a comment on the REQUEST task:

bd comments add {{request-task-id}} \
  "Explore findings ({{depth}}):
  - Entry points: {{list of files/functions}}
  - Related types: {{existing types/schemas}}
  - Dependencies: {{modules this would use}}
  - Patterns: {{how similar features work here}}
  - Conflicts: {{potential issues or 'none'}}"

Completion

Both agents must complete before proceeding to Phase 2. Their findings are recorded as comments on the REQUEST task, available for the elicitation survey and proposal phases.

Example

User says: "I want to add a logout button to the header that clears the session and redirects to the login page"

bd create --labels "pasture:p1-user:s1_1-classify" \
  --title "REQUEST: Add logout button to header" \
  --description "I want to add a logout button to the header that clears the session and redirects to the login page" \
  --assignee architect
# Returns: bd-abc123

bd comments add bd-abc123 \
  "Classification: scope=module, complexity=low, risk=internal-only, novelty=familiar"

Next Phase

After Phase 1 completes, invoke /pasture:user-elicit to begin requirements elicitation (Phase 2).

The elicit task will block this request task:

bd dep add {{request-task-id}} --blocked-by {{elicit-task-id}}