Blueprint Discovery
Handles Steps 1-3 of the blueprint workflow: Interview decision, Acceptance Criteria gathering, and Feature Classification.
Input
feature_description: string # Raw feature description from user
1. Interview Decision
Suggest interview when:
- Feature description < 2 sentences
- Contains uncertainty words: "maybe", "probably", "something like", "not sure"
- Involves multiple stakeholders or systems
- User seems uncertain
Skip interview for:
- Bug fixes with clear reproduction steps
- Small, well-defined tasks (< 3 files likely)
- Features with existing specs/PRDs referenced
If interview suggested:
AskUserQuestion:
question: "This feature could benefit from a requirements interview. Explore in depth first?"
options:
- "Yes, interview me first" → Invoke /majestic:interview with feature_description
- "No, proceed to planning" → Continue
2. Acceptance Criteria
MANDATORY: Ask what "done" means.
AC describes feature behaviors only. Quality gates (tests, lint, review) handled by other agents.
AskUserQuestion:
question: "What behavior must work for this feature to be done?"
header: "Done when"
multiSelect: true
options:
- label: "User can perform action"
description: "Feature enables a specific user action"
- label: "System responds correctly"
description: "API/backend behaves as expected"
- label: "UI displays properly"
description: "Visual elements render correctly"
- label: "Data is persisted"
description: "Changes are saved to database"
Good AC examples:
- "Authenticated user can login and redirect to dashboard"
- "Form validates email format before submission"
- "API returns 404 for non-existent resources"
Bad AC examples (handled elsewhere):
- "Tests pass" → always-works-verifier
- "Code reviewed" → quality-gate
- "No lint errors" → slop-remover
Capture verification method for each criterion:
| Criterion |
Verification |
| User can login |
curl -X POST /login or manual |
| Form validates |
rspec spec/features/signup_spec.rb |
| API returns 404 |
curl /api/nonexistent |
3. Feature Classification
| Type |
Detection Keywords |
Action |
| UI |
page, component, form, button, modal, design, view, template |
Check design system |
| DevOps |
terraform, ansible, infrastructure, cloud, docker, deploy, server |
Delegate to devops-plan |
| API |
endpoint, route, controller, request, response, REST, GraphQL |
Standard flow |
| Data |
migration, model, schema, database, query |
Standard flow |
UI Feature Flow:
- Read config:
/majestic:config design_system_path
- If empty, check:
docs/design/design-system.md
- If no design system: Suggest
/majestic:ux-brief first
DevOps Feature Flow:
Skill(skill: "majestic-devops:devops-plan")
Output
discovery_result:
interview_conducted: boolean
interview_output: string | null # If interview was run
acceptance_criteria:
- criterion: string
verification: string
feature_type: "ui" | "devops" | "api" | "data" | "general"
design_system_path: string | null # For UI features
ready_for_research: boolean
1---2name: blueprint-discovery3description: Discovery phase for blueprint workflow - interview triggers, acceptance criteria, and feature classification4---56# Blueprint Discovery78Handles Steps 1-3 of the blueprint workflow: Interview decision, Acceptance Criteria gathering, and Feature Classification.910## Input1112```yaml13feature_description: string # Raw feature description from user14```1516## 1. Interview Decision1718**Suggest interview when:**19- Feature description < 2 sentences20- Contains uncertainty words: "maybe", "probably", "something like", "not sure"21- Involves multiple stakeholders or systems22- User seems uncertain2324**Skip interview for:**25- Bug fixes with clear reproduction steps26- Small, well-defined tasks (< 3 files likely)27- Features with existing specs/PRDs referenced2829**If interview suggested:**30```31AskUserQuestion:32 question: "This feature could benefit from a requirements interview. Explore in depth first?"33 options:34 - "Yes, interview me first" → Invoke /majestic:interview with feature_description35 - "No, proceed to planning" → Continue36```3738## 2. Acceptance Criteria3940**MANDATORY: Ask what "done" means.**4142AC describes feature behaviors only. Quality gates (tests, lint, review) handled by other agents.4344```45AskUserQuestion:46 question: "What behavior must work for this feature to be done?"47 header: "Done when"48 multiSelect: true49 options:50 - label: "User can perform action"51 description: "Feature enables a specific user action"52 - label: "System responds correctly"53 description: "API/backend behaves as expected"54 - label: "UI displays properly"55 description: "Visual elements render correctly"56 - label: "Data is persisted"57 description: "Changes are saved to database"58```5960**Good AC examples:**61- "Authenticated user can login and redirect to dashboard"62- "Form validates email format before submission"63- "API returns 404 for non-existent resources"6465**Bad AC examples (handled elsewhere):**66- "Tests pass" → always-works-verifier67- "Code reviewed" → quality-gate68- "No lint errors" → slop-remover6970**Capture verification method for each criterion:**7172| Criterion | Verification |73|-----------|--------------|74| User can login | `curl -X POST /login` or manual |75| Form validates | `rspec spec/features/signup_spec.rb` |76| API returns 404 | `curl /api/nonexistent` |7778## 3. Feature Classification7980| Type | Detection Keywords | Action |81|------|-------------------|--------|82| **UI** | page, component, form, button, modal, design, view, template | Check design system |83| **DevOps** | terraform, ansible, infrastructure, cloud, docker, deploy, server | Delegate to devops-plan |84| **API** | endpoint, route, controller, request, response, REST, GraphQL | Standard flow |85| **Data** | migration, model, schema, database, query | Standard flow |8687**UI Feature Flow:**881. Read config: `/majestic:config design_system_path`892. If empty, check: `docs/design/design-system.md`903. If no design system: Suggest `/majestic:ux-brief` first9192**DevOps Feature Flow:**93```94Skill(skill: "majestic-devops:devops-plan")95```9697## Output9899```yaml100discovery_result:101 interview_conducted: boolean102 interview_output: string | null # If interview was run103 acceptance_criteria:104 - criterion: string105 verification: string106 feature_type: "ui" | "devops" | "api" | "data" | "general"107 design_system_path: string | null # For UI features108 ready_for_research: boolean109```