@windagency/valora 2.0.1

package/data/prompts/02_context/analyze-commits-for-pr.md

@@ -0,0 +1,258 @@
+---
+id: context.analyze-commits-for-pr
+version: 1.0.0
+category: context
+experimental: true
+name: Analyze Commits for PR
+description: Extract and analyze commit messages to understand changes for PR description
+tags:
+  - commit-analysis
+  - conventional-commits
+  - pr-context
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+    - context.analyze-git-branch
+inputs:
+  - name: current_branch
+    description: Current branch name
+    type: string
+    required: true
+  - name: base_branch
+    description: Base branch for comparison
+    type: string
+    required: true
+  - name: commits_ahead
+    description: Number of commits ahead
+    type: number
+    required: true
+outputs:
+  - commit_messages
+  - change_summary
+  - affected_files
+  - change_types
+  - breaking_changes
+  - authors
+tokens:
+  avg: 3000
+  max: 6000
+  min: 1500
+---
+
+# Analyze Commits for PR
+
+## Objective
+
+Extract detailed commit information and analyze changes to generate comprehensive PR context.
+
+## Instructions
+
+### Step 1: Get Detailed Commit Information
+
+Fetch commits with full details:
+
+```bash
+git log origin/<base>..HEAD --format='%H|%an|%ae|%s|%b'
+```
+
+**Parse each commit**:
+
+- `%H`: Full commit hash
+- `%an`: Author name
+- `%ae`: Author email
+- `%s`: Subject (first line)
+- `%b`: Body (remaining lines)
+
+### Step 2: Parse Conventional Commits
+
+For each commit subject, parse the conventional commit format:
+
+**Format**: `type(scope): description`
+
+**Common types**:
+
+- `feat`: New feature
+- `fix`: Bug fix
+- `refactor`: Code refactoring
+- `chore`: Maintenance tasks
+- `docs`: Documentation changes
+- `test`: Test additions/changes
+- `style`: Code style changes
+- `perf`: Performance improvements
+- `ci`: CI/CD changes
+- `build`: Build system changes
+- `revert`: Revert previous commit
+
+**Extract**:
+
+- Type
+- Scope (optional)
+- Description
+- Breaking change indicator (`!` after type, or `BREAKING CHANGE:` in body)
+
+### Step 3: Analyze Changed Files
+
+Get list of changed files with status:
+
+```bash
+git diff --name-status origin/<base>...HEAD
+```
+
+**Parse status**:
+
+- `A`: Added
+- `M`: Modified
+- `D`: Deleted
+- `R`: Renamed
+- `C`: Copied
+
+**Categorize files by type**:
+
+- Source code: `.js`, `.ts`, `.py`, `.go`, etc.
+- Tests: `*.test.*`, `*.spec.*`, `__tests__/`
+- Documentation: `*.md`, `docs/`
+- Configuration: `*.json`, `*.yaml`, `*.toml`, `.env*`
+- Assets: images, fonts, stylesheets
+
+### Step 4: Identify Change Types
+
+Aggregate change types from commits:
+
+- **Primary type**: Most frequent commit type
+- **Secondary types**: Other types present
+- **Breaking changes**: Any commits with breaking change markers
+
+### Step 5: Detect Breaking Changes
+
+Check for breaking change indicators:
+
+1. **In commit messages**: `BREAKING CHANGE:`, `!` after type
+2. **In file changes**: Major version bumps, API removals
+3. **In descriptions**: Keywords like "removed", "deprecated", "incompatible"
+
+Extract breaking change descriptions.
+
+### Step 6: Extract Authors and Co-Authors
+
+**Primary authors**: From commit author field
+
+**Co-authors**: Look for `Co-authored-by:` trailers in commit bodies
+
+### Step 7: Generate Change Summary
+
+Synthesize a high-level summary:
+
+- **Single commit**: Use commit message directly
+- **Multiple commits**: Group by type and summarize
+
+**Example**:
+
+```
+- Added OAuth2 authentication flow (3 commits)
+- Fixed token refresh bug (1 commit)
+- Updated API documentation (2 commits)
+```
+
+### Step 8: Calculate Complexity Metrics
+
+```bash
+git diff --shortstat origin/<base>...HEAD
+```
+
+**Extract**:
+
+- Files changed
+- Lines added
+- Lines deleted
+
+## Output Format
+
+```json
+{
+	"commit_messages": [
+		{
+			"hash": "abc123...",
+			"author": "Alice",
+			"email": "alice@example.com",
+			"subject": "feat(auth): add OAuth2 authentication",
+			"body": "Implements OAuth2 flow with token refresh...",
+			"type": "feat",
+			"scope": "auth",
+			"description": "add OAuth2 authentication",
+			"breaking": false
+		}
+	],
+	"change_summary": {
+		"primary_change": "Added OAuth2 authentication flow",
+		"grouped_changes": {
+			"feat": ["OAuth2 authentication", "Token refresh"],
+			"fix": ["Login redirect bug"],
+			"docs": ["API documentation"]
+		}
+	},
+	"affected_files": {
+		"total": 15,
+		"by_status": {
+			"added": 5,
+			"modified": 9,
+			"deleted": 1
+		},
+		"by_type": {
+			"source": 10,
+			"tests": 3,
+			"docs": 2
+		},
+		"files": [
+			{ "path": "src/auth/oauth2.ts", "status": "A", "type": "source" },
+			{ "path": "src/auth/tokens.ts", "status": "M", "type": "source" }
+		]
+	},
+	"change_types": {
+		"primary": "feat",
+		"all": ["feat", "fix", "docs"],
+		"distribution": {
+			"feat": 3,
+			"fix": 1,
+			"docs": 2
+		}
+	},
+	"breaking_changes": [
+		{
+			"commit": "abc123",
+			"description": "Changed /auth/login endpoint signature",
+			"migration": "Update client calls to include clientId parameter"
+		}
+	],
+	"authors": [
+		{ "name": "Alice", "email": "alice@example.com", "commits": 5 },
+		{ "name": "Bob", "email": "bob@example.com", "commits": 2 }
+	],
+	"complexity": {
+		"files_changed": 15,
+		"lines_added": 342,
+		"lines_deleted": 87,
+		"net_change": 255
+	}
+}
+```
+
+## Success Criteria
+
+- ✅ All commits parsed and analyzed
+- ✅ Conventional commit types extracted
+- ✅ Changed files categorized
+- ✅ Breaking changes identified
+- ✅ Authors and co-authors extracted
+- ✅ Change summary generated
+
+## Error Handling
+
+- **Non-conventional commits**: Extract what's possible, mark format as "freeform"
+- **No commits**: Return empty structures
+- **Git errors**: Provide clear error message

package/data/prompts/02_context/analyze-functional-scope.md

@@ -0,0 +1,380 @@
+---
+id: context.analyze-functional-scope
+version: 1.0.0
+category: context
+experimental: true
+name: Analyze Functional Scope
+description: Identify feature scope, requirements, acceptance criteria, and user workflows for functional validation
+tags:
+  - functional-review
+  - requirements-analysis
+  - scope-definition
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+  optional:
+    - context.load-prd
+    - context.load-task
+inputs:
+  - name: scope
+    description: The scope to review (file paths, feature name, or description)
+    type: string
+    required: true
+outputs:
+  - feature_scope
+  - requirements_list
+  - acceptance_criteria
+  - user_workflows
+  - integration_points
+tokens:
+  avg: 3500
+  max: 7000
+  min: 2000
+---
+
+# Analyze Functional Scope
+
+## Objective
+
+Identify the feature being reviewed, extract requirements and acceptance criteria, map user workflows, and define validation boundaries for functional review.
+
+## Context
+
+You are preparing for a functional review. You need to understand what was supposed to be built, identify all acceptance criteria, and map out user workflows that need validation.
+
+## Instructions
+
+### Step 1: Identify Feature Scope
+
+Analyze the provided scope to understand what feature is being reviewed.
+
+**Actions**:
+
+1. Parse the scope argument (file paths, feature name, or description)
+2. Use `codebase_search` to locate related components
+3. Identify all modified/created files
+4. Determine feature boundaries
+
+**Output**:
+
+```json
+{
+	"feature_name": "Email Verification",
+	"feature_description": "Token-based email verification for new user registrations",
+	"affected_files": ["src/api/auth.ts", "src/services/email.service.ts", "src/models/user.model.ts"],
+	"scope_type": "backend",
+	"risk_level": "medium"
+}
+```
+
+### Step 2: Extract Requirements and Acceptance Criteria
+
+Locate and extract requirements from PRD, task description, or commit messages.
+
+**Sources to Check**:
+
+1. `knowledge-base/PRD.md` - Product Requirements Document
+2. `knowledge-base/FUNCTIONAL.md` - Functional requirements
+3. Recent commit messages
+4. Code comments with acceptance criteria
+5. Test descriptions
+
+**Actions**:
+
+- Read PRD/task specifications
+- Extract acceptance criteria (Given-When-Then format preferred)
+- Identify success metrics
+- Note constraints and business rules
+
+**Output**:
+
+```json
+{
+	"requirements_source": "knowledge-base/PRD.md",
+	"requirements": [
+		{
+			"id": "REQ-001",
+			"description": "User receives verification email upon registration",
+			"priority": "P0",
+			"type": "functional"
+		},
+		{
+			"id": "REQ-002",
+			"description": "User can verify email by clicking token link",
+			"priority": "P0",
+			"type": "functional"
+		}
+	],
+	"acceptance_criteria": [
+		{
+			"id": "AC-001",
+			"requirement_id": "REQ-001",
+			"criterion": "Given a new user registers, When registration succeeds, Then verification email is sent within 5 seconds",
+			"testable": true
+		},
+		{
+			"id": "AC-002",
+			"requirement_id": "REQ-002",
+			"criterion": "Given a verification link, When user clicks it, Then email is marked as verified",
+			"testable": true
+		}
+	],
+	"business_rules": [
+		"Verification tokens expire after 24 hours",
+		"Unverified users cannot access protected features",
+		"Email must be unique per user"
+	]
+}
+```
+
+### Step 3: Map User Workflows
+
+Identify all user workflows that need validation.
+
+**Primary Workflows**:
+
+- Main happy path from user perspective
+- Common use cases
+
+**Secondary Workflows**:
+
+- Alternative paths
+- Edge cases
+- Error scenarios
+
+**Actions**:
+
+- Map out step-by-step user journeys
+- Identify decision points
+- Note expected outcomes at each step
+
+**Output**:
+
+```json
+{
+	"primary_workflows": [
+		{
+			"id": "WF-001",
+			"name": "Email Verification - Happy Path",
+			"steps": [
+				"User completes registration form",
+				"System creates account and sends verification email",
+				"User receives email with verification link",
+				"User clicks verification link",
+				"System validates token and marks email as verified",
+				"User is redirected to dashboard"
+			],
+			"expected_outcome": "User has verified email and full account access",
+			"priority": "critical"
+		}
+	],
+	"secondary_workflows": [
+		{
+			"id": "WF-002",
+			"name": "Expired Token Handling",
+			"steps": [
+				"User clicks verification link after 24 hours",
+				"System detects expired token",
+				"User sees error message with option to resend",
+				"User requests new verification email",
+				"New email sent with fresh token"
+			],
+			"expected_outcome": "User can request new verification link",
+			"priority": "high"
+		}
+	],
+	"edge_cases": [
+		"User clicks same link multiple times",
+		"User registers with already-verified email",
+		"Email service is unavailable",
+		"Token is tampered with or invalid"
+	]
+}
+```
+
+### Step 4: Identify Integration Points
+
+Map out where this feature integrates with existing systems.
+
+**Check for**:
+
+- API endpoints called
+- External services used
+- Database interactions
+- State management
+- Event emissions
+
+**Output**:
+
+```json
+{
+	"integration_points": [
+		{
+			"type": "api",
+			"component": "POST /api/auth/register",
+			"interaction": "Creates user and triggers email verification"
+		},
+		{
+			"type": "external_service",
+			"component": "EmailService",
+			"interaction": "Sends verification emails via SMTP"
+		},
+		{
+			"type": "data",
+			"component": "UserModel",
+			"interaction": "Stores verification status and token"
+		}
+	],
+	"dependencies": [
+		"Email service must be configured",
+		"User model must have verification fields",
+		"Token generation must be secure"
+	]
+}
+```
+
+### Step 5: Define Edge Cases to Verify
+
+List specific edge cases and boundary conditions to test.
+
+**Categories**:
+
+- Empty states (no data, zero results)
+- Error states (network failures, validation errors)
+- Extreme values (very long text, large numbers)
+- Concurrent operations (race conditions)
+- Permission boundaries (unauthorized access)
+
+**Output**:
+
+```json
+{
+	"edge_cases": [
+		{
+			"category": "error_handling",
+			"case": "Email service unavailable during registration",
+			"expected_behavior": "User account created but flagged for retry, clear error message shown"
+		},
+		{
+			"category": "boundary_condition",
+			"case": "Token clicked after expiration",
+			"expected_behavior": "Clear error with option to resend verification"
+		},
+		{
+			"category": "concurrent_operation",
+			"case": "Same verification link clicked simultaneously",
+			"expected_behavior": "Only first request succeeds, subsequent show already verified"
+		}
+	]
+}
+```
+
+## Output Format
+
+Return comprehensive scope analysis:
+
+```json
+{
+	"feature_scope": {
+		"name": "Email Verification",
+		"description": "Token-based email verification for user registration",
+		"affected_components": ["AuthAPI", "EmailService", "UserModel"],
+		"affected_files": ["src/api/auth.ts", "src/services/email.service.ts"],
+		"scope_type": "backend",
+		"risk_level": "medium"
+	},
+	"requirements_list": {
+		"source": "knowledge-base/PRD.md",
+		"total_requirements": 5,
+		"p0_requirements": 3,
+		"requirements": [
+			{
+				"id": "REQ-001",
+				"description": "User receives verification email",
+				"priority": "P0",
+				"type": "functional"
+			}
+		],
+		"business_rules": ["Tokens expire in 24 hours", "Unverified users have limited access"]
+	},
+	"acceptance_criteria": [
+		{
+			"id": "AC-001",
+			"requirement_id": "REQ-001",
+			"criterion": "Given new registration, When account created, Then verification email sent within 5s",
+			"testable": true
+		}
+	],
+	"user_workflows": {
+		"primary": [
+			{
+				"id": "WF-001",
+				"name": "Happy Path - Email Verification",
+				"steps": ["Register", "Receive email", "Click link", "Verify"],
+				"priority": "critical"
+			}
+		],
+		"secondary": [
+			{
+				"id": "WF-002",
+				"name": "Expired Token",
+				"steps": ["Click expired link", "See error", "Request new"],
+				"priority": "high"
+			}
+		],
+		"edge_cases": ["Multiple clicks on same link", "Invalid/tampered token", "Email service down"]
+	},
+	"integration_points": [
+		{
+			"type": "api",
+			"component": "AuthAPI",
+			"interaction": "Handles registration and verification endpoints"
+		},
+		{
+			"type": "external_service",
+			"component": "EmailService",
+			"interaction": "Sends verification emails"
+		}
+	],
+	"validation_checklist": [
+		"All P0 requirements implemented",
+		"Primary workflow functions end-to-end",
+		"Error handling for email failures",
+		"Token expiration enforced",
+		"Security: tokens are cryptographically secure"
+	]
+}
+```
+
+## Success Criteria
+
+- ✅ Feature scope clearly defined
+- ✅ All requirements extracted from source
+- ✅ Acceptance criteria identified (testable)
+- ✅ User workflows mapped (primary + secondary)
+- ✅ Integration points documented
+- ✅ Edge cases listed for validation
+- ✅ Validation checklist prepared
+
+## Rules
+
+**DO**:
+
+- ✅ Search for PRD/task specifications first
+- ✅ Extract actual acceptance criteria (don't infer)
+- ✅ Map complete user journeys (not just API calls)
+- ✅ Identify integration points explicitly
+- ✅ Consider edge cases and error scenarios
+
+**DON'T**:
+
+- ❌ Don't assume requirements (always find source)
+- ❌ Don't skip edge case identification
+- ❌ Don't ignore error workflows
+- ❌ Don't overlook integration dependencies