@windagency/valora 2.0.1

package/data/prompts/04_code/determine-reviewers.md

@@ -0,0 +1,324 @@
+---
+id: code.determine-reviewers
+version: 1.0.0
+category: code
+experimental: true
+name: Determine Reviewers
+description: Intelligently determine appropriate code reviewers based on ownership and expertise
+tags:
+  - reviewers
+  - codeowners
+  - automation
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+    - context.analyze-commits-for-pr
+    - context.analyze-codebase-changes
+inputs:
+  - name: reviewers_arg
+    description: User-specified reviewers
+    type: string
+    required: false
+  - name: auto_assign
+    description: Whether to auto-assign reviewers
+    type: boolean
+    required: false
+    default: false
+  - name: affected_files
+    description: Files changed in PR
+    type: object
+    required: true
+  - name: impact_areas
+    description: Functional areas impacted
+    type: object
+    required: true
+  - name: authors
+    description: Commit authors
+    type: array
+    required: true
+outputs:
+  - reviewers_list
+  - reviewer_rationale
+tokens:
+  avg: 2500
+  max: 5000
+  min: 1200
+---
+
+# Determine Reviewers
+
+## Objective
+
+Intelligently determine appropriate code reviewers based on code ownership, expertise, and change context.
+
+## Instructions
+
+### Step 1: Check for Manual Reviewers
+
+If `reviewers_arg` is provided:
+
+- Parse comma-separated usernames
+- Validate format (GitHub usernames)
+- Return as-is with minimal rationale
+- Skip auto-assignment logic
+
+**Example**: `--reviewers=alice,bob` → `["alice", "bob"]`
+
+### Step 2: Check Auto-Assign Flag
+
+If `auto_assign` is false and no `reviewers_arg`:
+
+- Return empty reviewers list
+- Indicate manual assignment required
+- Skip analysis
+
+### Step 3: Load CODEOWNERS File
+
+If `auto_assign` is true, check for CODEOWNERS:
+
+**Locations to check**:
+
+- `.github/CODEOWNERS`
+- `CODEOWNERS`
+- `docs/CODEOWNERS`
+
+**Parse CODEOWNERS format**:
+
+```
+# Format: pattern  @owner1 @owner2
+
+*.js @frontend-team
+/api/ @backend-team @alice
+/auth/ @security-team @bob
+* @default-reviewer
+```
+
+**Matching**:
+
+- Match `affected_files` against patterns
+- Use most specific pattern match
+- Extract @usernames or @team-names
+
+### Step 4: Analyze File History (Git Blame)
+
+For each affected file, find frequent contributors:
+
+```bash
+git log --format='%an <%ae>' --follow <file> | sort | uniq -c | sort -rn | head -5
+```
+
+**Extract**:
+
+- Top 3-5 contributors per file
+- Aggregate across all affected files
+- Count contributions per person
+
+### Step 5: Map Functional Areas to Experts
+
+Use `impact_areas` to identify domain experts:
+
+**Common mappings**:
+
+| Area             | Typical Experts               |
+| ---------------- | ----------------------------- |
+| `backend`        | Backend engineers, API owners |
+| `frontend`       | Frontend engineers, UX team   |
+| `database`       | Database admins, data team    |
+| `authentication` | Security team                 |
+| `infrastructure` | DevOps, SRE team              |
+| `api`            | API platform team             |
+
+**Check**:
+
+- Team documentation (`docs/TEAMS.md`)
+- Previous PRs in same area
+- Org chart (if available)
+
+### Step 6: Apply Selection Criteria
+
+**Prioritize reviewers by**:
+
+1. **CODEOWNERS match** (highest priority)
+2. **Frequent file contributors** (git blame)
+3. **Domain expertise** (functional area)
+4. **Recent activity** (active in last 30 days)
+
+**Filter out**:
+
+- PR author (don't assign to self)
+- Inactive users (no activity >90 days)
+- External contributors (unless explicitly listed in CODEOWNERS)
+
+### Step 7: Select 1-3 Reviewers
+
+**Optimal count**: 1-3 reviewers
+
+- **Too few** (<1): May cause bottleneck if reviewer unavailable
+- **Too many** (>3): Diffusion of responsibility, slower reviews
+
+**Selection logic**:
+
+1. If CODEOWNERS match exists: Use those (max 3)
+2. Otherwise: Select top contributor + domain expert
+3. For high-impact changes: Add additional expert
+
+**Balance**:
+
+- At least 1 technical reviewer (code quality)
+- At least 1 domain expert (business logic)
+- Consider security reviewer for auth/security changes
+
+### Step 8: Generate Rationale
+
+For each selected reviewer, provide rationale:
+
+**Example rationales**:
+
+- "CODEOWNERS for `/auth/` directory"
+- "Top contributor to `src/auth/oauth2.ts` (12 commits)"
+- "Security domain expert (authentication changes)"
+- "Recent contributor to authentication module"
+- "API platform team lead"
+
+## Output Format
+
+```json
+{
+	"reviewers_list": ["alice", "bob"],
+	"reviewer_rationale": {
+		"alice": {
+			"username": "alice",
+			"reasons": ["CODEOWNERS for /auth/ directory", "Security domain expert"],
+			"confidence": "high",
+			"priority": 1
+		},
+		"bob": {
+			"username": "bob",
+			"reasons": ["Top contributor to src/auth/oauth2.ts (12 commits)", "Recent activity in authentication module"],
+			"confidence": "medium",
+			"priority": 2
+		}
+	},
+	"assignment_method": "auto",
+	"alternative_reviewers": [
+		{
+			"username": "carol",
+			"reasons": ["Backend team member"],
+			"confidence": "low"
+		}
+	]
+}
+```
+
+## Success Criteria
+
+- ✅ 1-3 reviewers selected (optimal range)
+- ✅ PR author not included in reviewers
+- ✅ Rationale provided for each reviewer
+- ✅ CODEOWNERS respected (if exists)
+- ✅ Domain expertise considered
+
+## Special Cases
+
+### No CODEOWNERS Found
+
+**Fallback**:
+
+1. Use git blame analysis
+2. Select top 2 contributors
+3. Add domain expert if identifiable
+
+### All Owners Are PR Author
+
+**Action**:
+
+1. Skip to next level (file contributors)
+2. Select based on git blame
+3. Flag for manual assignment
+
+### High-Impact Changes
+
+**Criteria**:
+
+- Breaking changes present
+- Security-sensitive code
+- Performance-critical paths
+- Database migrations
+
+**Action**:
+
+- Add additional reviewer (2-3 total)
+- Prioritize senior/lead engineers
+- Include domain architect if available
+
+### Security Changes
+
+**If** `impact_areas` includes `authentication` or `security`:
+
+**Action**:
+
+- Add security team member
+- Require security review
+- Flag for security audit
+
+### Large PRs (>500 lines)
+
+**Action**:
+
+- Add 2-3 reviewers (distribute load)
+- Consider splitting review by area
+- Suggest pair review sessions
+
+## Edge Cases
+
+### User Not Found
+
+**If reviewer username doesn't exist**:
+
+1. Validate GitHub username
+2. Check for typos in CODEOWNERS
+3. Skip invalid user
+4. Warn in output
+
+### Teams vs. Individual Reviewers
+
+**CODEOWNERS may reference teams**:
+
+```
+/auth/ @security-team
+```
+
+**Handle**:
+
+- Teams cannot be directly assigned (GitHub API limitation)
+- Resolve team to individual members
+- Or leave for manual assignment
+
+### Empty Result
+
+**If no reviewers found**:
+
+- Return empty list
+- Provide explanation
+- Suggest manual assignment
+- List potential candidates
+
+## Recommendations
+
+Include in output:
+
+```json
+{
+	"recommendations": [
+		"Consider adding security team reviewer for authentication changes",
+		"Large PR (500+ lines) - consider splitting or adding additional reviewer",
+		"No recent activity in this area - may need longer review time"
+	]
+}
+```

package/data/prompts/04_code/generate-commit-messages.md

@@ -0,0 +1,355 @@
+---
+id: code.generate-commit-messages
+version: 1.0.0
+category: code
+experimental: true
+name: Generate Commit Messages
+description: Generate conventional commit messages for each commit group
+tags:
+  - commit-messages
+  - conventional-commits
+  - message-generation
+model_requirements:
+  min_context: 200000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+  - software-engineer
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+    - code.determine-commit-strategy
+inputs:
+  - name: commit_groups
+    description: Commit groups from strategy determination
+    type: array
+    required: true
+  - name: change_type
+    description: Primary change type
+    type: string
+    required: true
+  - name: scope
+    description: User-specified scope (optional)
+    type: string
+    required: false
+  - name: breaking
+    description: User-specified breaking flag
+    type: boolean
+    required: false
+  - name: custom_message
+    description: User-specified custom message
+    type: string
+    required: false
+  - name: template_config
+    description: Template configuration if using template
+    type: object
+    required: false
+  - name: ticket_number
+    description: Extracted ticket number
+    type: string
+    required: false
+  - name: insights
+    description: Recommendations from insights
+    type: array
+    required: false
+outputs:
+  - commit_messages
+  - commit_descriptions
+  - commit_footers
+tokens:
+  avg: 4000
+  max: 8000
+  min: 2000
+---
+
+# Generate Commit Messages
+
+## Objective
+
+Generate conventional commit messages following best practices for each commit group.
+
+## Instructions
+
+### Step 1: Handle Custom Message Override
+
+If `custom_message` provided:
+
+```typescript
+if (custom_message) {
+	// Validate format
+	if (!follows_conventional_commits(custom_message)) {
+		warn: "Custom message doesn't follow Conventional Commits format";
+	}
+
+	// Use custom message for all groups (if single)
+	// Or use as subject template for groups
+	return custom_message_result;
+}
+```
+
+### Step 2: Generate Message for Each Group
+
+For each commit group, generate:
+
+1. **Subject line** (< 72 characters)
+2. **Body** (optional, wrap at 72 characters)
+3. **Footer** (optional, for breaking changes, issue refs)
+
+### Step 3: Generate Subject Line
+
+**Format**: `<type>(<scope>): <description>`
+
+**Type**: Use group's `type` (feat, fix, docs, etc.)
+
+**Scope**:
+
+- Use user-specified `scope` if provided
+- Otherwise use group's `scope`
+- Omit if change affects multiple areas broadly
+
+**Description**:
+
+- Start with lowercase
+- Use imperative mood ("add", not "added" or "adds")
+- Be specific and concise
+- No period at end
+- < 50 characters ideally
+
+**Breaking change indicator**:
+
+- Add `!` after scope if breaking: `feat(api)!: redesign endpoints`
+
+**Examples**:
+
+```plaintext
+✅ feat(auth): implement OAuth2 refresh token rotation
+✅ fix(cache): resolve race condition in Redis operations
+✅ docs(api): document rate limiting behavior
+✅ test(auth): add OAuth2 integration tests
+✅ refactor(db): extract query builders
+✅ perf(api): optimize user query with indexing
+
+❌ feat: update files (too vague)
+❌ fix: bug (not descriptive)
+❌ Added OAuth2 support (wrong mood)
+❌ feat(auth): implement OAuth2 refresh token rotation with secure storage and configurable expiration (too long)
+```
+
+### Step 4: Generate Body (Optional)
+
+Include body if:
+
+- Changes are complex and need explanation
+- Breaking changes require context
+- Multiple related changes need listing
+- Insights recommendations suggest documentation
+
+**Body structure**:
+
+```plaintext
+<What was changed and why>
+
+<Additional context if needed>
+
+<References to issues/tickets>
+```
+
+**Rules**:
+
+- Explain **what** and **why**, not **how**
+- Wrap at 72 characters
+- Use bullet points for lists
+- Include context for complex changes
+- Reference related issues/tickets
+- Blank line after subject
+
+**Example**:
+
+```plaintext
+feat(auth): implement OAuth2 refresh token rotation
+
+Add secure token rotation mechanism with configurable expiration.
+Tokens are automatically rotated on use and expired tokens are
+invalidated.
+
+This improves security by limiting token lifetime and reducing
+risk of token theft. Rotation happens transparently to clients.
+
+Refs #456
+```
+
+### Step 5: Generate Footer (Optional)
+
+**Footer types**:
+
+1. **Breaking changes** (required if breaking):
+
+   ```plaintext
+   BREAKING CHANGE: /api/login endpoint now requires JWT tokens
+   instead of session cookies. Clients must update authentication flow.
+   ```
+
+2. **Issue references**:
+
+   ```plaintext
+   Closes #123
+   Fixes #456
+   Refs #789
+   ```
+
+3. **Co-authors**:
+
+   ```plaintext
+   Co-authored-by: Jane Doe <jane@example.com>
+   ```
+
+4. **Reviewers** (for some teams):
+   ```plaintext
+   Reviewed-by: John Smith <john@example.com>
+   ```
+
+**Rules**:
+
+- Blank line before footer
+- One footer per line
+- Use standard keywords (Closes, Fixes, Refs)
+- BREAKING CHANGE must be in footer if breaking
+
+### Step 6: Apply Template Variables (If Using Template)
+
+If `template_config` provided:
+
+```typescript
+let message = template_config.subject_template;
+
+// Replace variables
+message = message.replace(/\{\{scope\}\}/g, scope);
+message = message.replace(/\{\{description\}\}/g, description);
+message = message.replace(/\{\{ticket\}\}/g, ticket_number || '');
+
+// Body
+let body = template_config.body_template;
+body = body.replace(/\{\{ticket\}\}/g, ticket_number || '');
+body = body.replace(/\{\{details\}\}/g, change_details);
+
+// Footer
+let footer = template_config.footer_template;
+footer = footer.replace(/\{\{ticket\}\}/g, ticket_number || '');
+```
+
+### Step 7: Incorporate Insights Recommendations
+
+If `insights` provided, apply recommendations:
+
+**Examples**:
+
+- Add migration guide mention in body
+- Reference security implications
+- Document breaking changes more clearly
+- Add issue references
+
+### Step 8: Validate Generated Messages
+
+Check each message:
+
+1. **Format compliance**: Matches Conventional Commits spec
+2. **Length**: Subject < 72 chars (ideally < 50)
+3. **Clarity**: Clear and descriptive
+4. **Completeness**: Includes necessary context
+5. **Breaking changes**: Properly flagged if applicable
+
+## Output Format
+
+```json
+{
+	"commit_messages": [
+		{
+			"group_id": "group_1",
+			"subject": "feat(auth): implement OAuth2 refresh token rotation",
+			"body": "Add secure token rotation mechanism with configurable expiration.\nTokens are automatically rotated on use and expired tokens are invalidated.\n\nThis improves security by limiting token lifetime and reducing risk of token theft.\n\nRefs #456",
+			"footer": "",
+			"full_message": "feat(auth): implement OAuth2 refresh token rotation\n\nAdd secure token rotation mechanism with configurable expiration.\nTokens are automatically rotated on use and expired tokens are invalidated.\n\nThis improves security by limiting token lifetime and reducing risk of token theft.\n\nRefs #456",
+			"character_count": 68,
+			"validation": {
+				"format_valid": true,
+				"length_ok": true,
+				"clarity_score": 9
+			}
+		},
+		{
+			"group_id": "group_2",
+			"subject": "test(auth): add OAuth2 refresh token tests",
+			"body": "Add integration tests for token rotation, expiration, and invalidation scenarios.",
+			"footer": "",
+			"full_message": "test(auth): add OAuth2 refresh token tests\n\nAdd integration tests for token rotation, expiration, and invalidation scenarios.",
+			"character_count": 44,
+			"validation": {
+				"format_valid": true,
+				"length_ok": true,
+				"clarity_score": 8
+			}
+		}
+	],
+	"commit_descriptions": {
+		"group_1": "OAuth2 refresh token rotation implementation",
+		"group_2": "OAuth2 refresh token tests"
+	},
+	"commit_footers": {
+		"group_1": "",
+		"group_2": ""
+	},
+	"total_commits": 2
+}
+```
+
+**With breaking changes**:
+
+```json
+{
+	"commit_messages": [
+		{
+			"group_id": "group_1",
+			"subject": "feat(api)!: redesign authentication endpoints",
+			"body": "Previous endpoints:\n- POST /auth/login (session-based)\n- POST /auth/logout\n\nNew endpoints:\n- POST /auth/token (JWT-based)\n- POST /auth/refresh\n- DELETE /auth/token\n\nAll API consumers must update their authentication implementation.\n\nCloses #234",
+			"footer": "BREAKING CHANGE: Authentication flow has been redesigned to use JWT tokens\ninstead of session-based auth. Session endpoints have been removed.",
+			"full_message": "feat(api)!: redesign authentication endpoints\n\nPrevious endpoints:\n- POST /auth/login (session-based)\n- POST /auth/logout\n\nNew endpoints:\n- POST /auth/token (JWT-based)\n- POST /auth/refresh\n- DELETE /auth/token\n\nAll API consumers must update their authentication implementation.\n\nCloses #234\n\nBREAKING CHANGE: Authentication flow has been redesigned to use JWT tokens\ninstead of session-based auth. Session endpoints have been removed.",
+			"character_count": 50,
+			"validation": {
+				"format_valid": true,
+				"length_ok": true,
+				"clarity_score": 10,
+				"breaking_properly_flagged": true
+			}
+		}
+	]
+}
+```
+
+## Success Criteria
+
+- ✅ Messages follow Conventional Commits format
+- ✅ Subject lines < 72 characters
+- ✅ Imperative mood used
+- ✅ Breaking changes properly flagged
+- ✅ Issue references included if available
+- ✅ Clear and descriptive
+- ✅ Template applied if specified
+
+## Rules
+
+**DO**:
+
+- ✅ Use imperative mood ("add", "fix", "implement")
+- ✅ Be specific and descriptive
+- ✅ Flag breaking changes with `!` and footer
+- ✅ Reference issues/tickets
+- ✅ Keep subject concise
+
+**DON'T**:
+
+- ❌ Use past tense ("added", "fixed")
+- ❌ Be vague ("update files", "changes")
+- ❌ Exceed character limits
+- ❌ Miss breaking change indicators
+- ❌ Skip context for complex changes