Files
sar/.claude/skills/wds-8-product-evolution/steps-a/step-02-gather-context.md
julian 17c08e6392 chore: initial monorepo scaffold + WDS Phase 1+2 artifacts
- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24)
- apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004)
- apps/web: React 19 + Vite 8 (ESM)
- libs/shared/api-interface: Zod contract base
- Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit
- WDS artifacts:
  - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs)
  - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact)
- Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md
- AGENTS.md + README.md como entrada para devs/agentes

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 14:34:20 +00:00

214 lines
7.1 KiB
Markdown

---
name: 'step-02-gather-context'
description: 'Understand the existing product context before making changes'
# File References
workflowFile: '../workflow.md'
activityWorkflowFile: '../workflow-analyze.md'
# Data References
contextTemplates: '../data/context-templates.md'
---
# Step 2: Gather Context
## STEP GOAL:
Understand the existing product context deeply before designing improvements - whether you're joining an existing product for the first time or iterating on a product you designed.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring UX research expertise and product insight, user brings domain knowledge and product experience
- ✅ Maintain curious and analytical tone throughout
### Step-Specific Rules:
- 🎯 Focus only on gathering existing context - no solution design yet
- 🚫 FORBIDDEN to propose solutions or design changes
- 💬 Approach: Ask questions to understand deeply, help user synthesize insights
- 📋 Experience the product yourself if possible - firsthand understanding is critical
- 📋 Distinguish between two contexts: new product entry vs continuous improvement
## EXECUTION PROTOCOLS:
- 🎯 Guide user through appropriate context path (A or B) based on their situation
- 💾 Help user collect and organize materials systematically
- 📖 Reference templates from {contextTemplates} for all deliverables
- 🚫 Do not skip to solutions - root cause identification comes first
## CONTEXT BOUNDARIES:
- Available context: Limited brief or improvement file (from step 01), context templates
- Focus: Understanding current state, identifying root causes, forming hypotheses
- Limits: Do not design solutions, do not scope work (that's step S)
- Dependencies: Requires completed step 01 (opportunity identified), limited brief or improvement file created
## Sequence of Instructions (Do not deviate, skip, or optimize)
### 1. Determine Context Path
**Clarify user's situation:**
Are you:
- **A) Joining an existing product** (first time working on this product)
- **B) Continuous improvement** (you designed this product, now improving it)
Guide user to appropriate section below.
### 2. Context A: Existing Product Entry Point
**For users joining an existing product:**
#### 2a. Gather Existing Materials
**Help user collect everything:**
| Category | Upload To | Review For |
|----------|-----------|------------|
| **Business** | `A-Project-Brief/existing-context/business/` | Why product exists, business model, competitors |
| **Users** | `A-Project-Brief/existing-context/users/` | Who are users, needs, pain points |
| **Product** | `A-Project-Brief/existing-context/product/` | Features, tech stack, constraints |
**Prompt user to upload materials they have available.**
#### 2b. Use the Product
**Critical: Experience it yourself!**
Guide user through:
1. Download/access the product
2. Create an account, go through onboarding
3. Use all major features
4. Document your experience
**Reference:** Use First Impressions template from {contextTemplates}
#### 2c. Create Focused Trigger Map
**Based on your strategic challenge:**
**File:** `B-Trigger-Map/focused-trigger-map.md`
**Reference:** Use Focused Trigger Map template from {contextTemplates}
Help user identify:
- Trigger moment (when does this happen?)
- Current experience (what happens now?)
- Desired outcome (what should happen?)
- Barriers (what's preventing success?)
- Solution focus (what will we change?)
### 3. Context B: Continuous Improvement
**For users who designed the product:**
#### 3a. Analytics Deep Dive
Focus on the specific feature/flow you're improving.
**Reference:** Use Analytics template from {contextTemplates}
Help user analyze:
- Usage metrics for specific feature
- User segments (new vs returning vs power users)
- Drop-off points
- Time spent
- Key insights
#### 3b. User Feedback Analysis
Categorize feedback about this specific feature.
**Reference:** Use User Feedback template from {contextTemplates}
Guide user to identify:
- Themes (confusion, requests, praise)
- Frequency of mentions
- Specific quotes
- Patterns
#### 3c. Review Original Design Intent
**Ask user to reflect:**
- Why did you design it this way?
- What assumptions did you make?
- What constraints existed?
- What has changed since?
#### 3d. Competitive Analysis
**Guide user to research:**
- How do competitors handle this?
- What patterns work well?
- What can we learn?
- What should we avoid?
### 4. Synthesis (Both Paths)
**Combine all context into actionable insights:**
**Reference:** Use Context Synthesis template from {contextTemplates}
Help user create synthesis with:
- **What we know** (key insights from all sources)
- **Root cause** (why is this happening?)
- **Hypothesis** (what will solve it?)
- **Validation plan** (how will we know?)
**Critical:** Root cause must be identified before moving forward.
### 5. Present MENU OPTIONS
Display: "**Select an Option:** [M] Return to Activity Menu (suggest [S] Scope Improvement)"
#### Menu Handling Logic:
- IF M: Return to {workflowFile} or {activityWorkflowFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- User can chat or ask questions - always respond and then redisplay menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN user selects [M] and context gathering is complete will you then return to the activity workflow to suggest next step [S] Scope Improvement.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All relevant materials gathered (Context A) or fresh data collected (Context B)
- Product experienced firsthand (Context A required)
- Focused trigger map created (Context A) or analytics analyzed (Context B)
- User feedback categorized and themed
- Root cause clearly identified with evidence
- Hypothesis formed with expected impact
- Validation plan defined
- Context synthesis document complete
### ❌ SYSTEM FAILURE:
- Not using the product yourself (Context A)
- Relying only on documentation without firsthand experience
- Ignoring user feedback or analytics data
- Not identifying root cause (jumping to symptoms)
- Jumping to solutions too quickly (skipping analysis)
- Generating content without user input
- Proposing design changes (not this step's purpose)
- Skipping synthesis step
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.