@windagency/valora 2.0.1

package/data/prompts/04_code/determine-commit-strategy.md

@@ -0,0 +1,300 @@
+---
+id: code.determine-commit-strategy
+version: 1.0.0
+category: code
+experimental: true
+name: Determine Commit Strategy
+description: Decide whether to create single or multiple commits and group changes logically
+tags:
+  - commit-strategy
+  - change-grouping
+  - atomic-commits
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+  - software-engineer
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+    - context.analyze-change-scope
+inputs:
+  - name: change_summary
+    description: Summary of changes
+    type: string
+    required: true
+  - name: affected_areas
+    description: Affected functional areas
+    type: array
+    required: true
+  - name: breaking_changes
+    description: Whether breaking changes detected
+    type: boolean
+    required: true
+outputs:
+  - should_split
+  - commit_groups
+  - commit_strategy
+tokens:
+  avg: 3000
+  max: 6000
+  min: 1500
+---
+
+# Determine Commit Strategy
+
+## Objective
+
+Decide whether changes should be committed as a single commit or split into multiple logical commits.
+
+## Instructions
+
+### Step 1: Evaluate Split Criteria
+
+Check if any of these conditions apply:
+
+**Split if**:
+
+1. **Multiple distinct features** - Separate logical features that could be independent
+2. **Mixed concerns** - Feature + refactor, or feature + docs, or fix + feature
+3. **Large changeset** - Total changes > 500 LOC
+4. **Frontend + backend** - Separate layers when appropriate
+5. **Schema migrations** - Always separate migrations from code changes
+6. **Multiple affected areas** - Changes to unrelated functional areas
+
+**Single commit if**:
+
+1. **Single logical unit** - All changes relate to one feature/fix
+2. **Small changeset** - Total changes < 500 LOC
+3. **Tightly coupled** - Changes depend on each other
+4. **Single area** - All changes in one functional area
+
+### Step 2: Group Changes by Logical Unit
+
+If splitting, group files by:
+
+**Priority order**:
+
+1. **Schema/migrations** (highest priority)
+   - Database migrations
+   - API contract changes
+   - Data model changes
+
+2. **Backend/core logic**
+   - Business logic
+   - APIs
+   - Services
+
+3. **Frontend/UI**
+   - Components
+   - Pages
+   - Styles
+
+4. **Tests**
+   - Unless tightly coupled to feature
+   - Can be separate commit
+
+5. **Documentation**
+   - README
+   - API docs
+   - Comments
+
+6. **Configuration**
+   - CI/CD
+   - Build tools
+   - Linting
+
+**Grouping rules**:
+
+```typescript
+groups = [];
+
+// Group 1: Migrations (if any)
+if (has_migrations) {
+  groups.push({
+    type: "build" or "feat",
+    scope: "schema" or "migrations",
+    files: migration_files,
+    description: "schema changes"
+  });
+}
+
+// Group 2: Backend changes
+if (has_backend_changes) {
+  groups.push({
+    type: primary_change_type,
+    scope: backend_scope,
+    files: backend_files,
+    description: backend_description
+  });
+}
+
+// Group 3: Frontend changes
+if (has_frontend_changes && !tightly_coupled_with_backend) {
+  groups.push({
+    type: "feat" or "fix",
+    scope: frontend_scope,
+    files: frontend_files,
+    description: frontend_description
+  });
+}
+
+// Group 4: Tests (if large)
+if (test_files.length > 5 || test_loc > 200) {
+  groups.push({
+    type: "test",
+    scope: test_scope,
+    files: test_files,
+    description: "tests for X"
+  });
+}
+
+// Group 5: Documentation
+if (has_doc_changes && !docs_tightly_coupled) {
+  groups.push({
+    type: "docs",
+    scope: doc_scope,
+    files: doc_files,
+    description: doc_description
+  });
+}
+```
+
+### Step 3: Validate Grouping
+
+Ensure each group is:
+
+1. **Atomic** - Can be committed independently
+2. **Coherent** - All files relate to same logical change
+3. **Self-contained** - Includes all necessary changes for that unit
+4. **Buildable** - Codebase builds after this commit
+5. **Testable** - Tests pass after this commit
+
+**Bad grouping examples**:
+
+- ❌ Half of a feature in one commit
+- ❌ Part of a function in one commit, rest in another
+- ❌ Breaking backend without frontend adaptation
+- ❌ Code change without corresponding test updates
+
+**Good grouping examples**:
+
+- ✅ Complete feature in one commit with tests
+- ✅ Schema migration + backend adaptation together
+- ✅ Backend API + frontend consumer separately (if not breaking)
+- ✅ Refactor separate from feature implementation
+
+### Step 4: Determine Commit Order
+
+Order commits by dependency:
+
+**Commit order**:
+
+1. Migrations first (other commits may depend on schema)
+2. Backend/API changes (frontend depends on these)
+3. Frontend changes (consumes backend APIs)
+4. Tests (validate implementation)
+5. Documentation (documents implemented features)
+6. Configuration (supporting infrastructure)
+
+**Rationale**: Each commit should be deployable, so dependencies must be committed first.
+
+### Step 5: Calculate Strategy Metadata
+
+```typescript
+commit_strategy = {
+	should_split: groups.length > 1,
+	strategy: groups.length > 1 ? 'split' : 'single',
+	commit_count: groups.length,
+	total_files: sum(groups.map((g) => g.files.length)),
+	rationale: explain_why_split_or_single()
+};
+```
+
+## Output Format
+
+**Single commit**:
+
+```json
+{
+	"should_split": false,
+	"commit_strategy": "single",
+	"commit_groups": [
+		{
+			"id": "group_1",
+			"type": "feat",
+			"scope": "auth",
+			"files": ["src/auth/oauth.ts", "src/auth/tokens.ts", "tests/auth/oauth.test.ts"],
+			"description": "OAuth2 refresh token rotation",
+			"line_count": 145,
+			"priority": 1
+		}
+	],
+	"rationale": "All changes are part of single OAuth2 feature, tightly coupled, under 500 LOC"
+}
+```
+
+**Split commits**:
+
+```json
+{
+	"should_split": true,
+	"commit_strategy": "split",
+	"commit_groups": [
+		{
+			"id": "group_1",
+			"type": "feat",
+			"scope": "auth",
+			"files": ["src/auth/oauth.ts", "src/auth/tokens.ts"],
+			"description": "OAuth2 refresh token rotation",
+			"line_count": 145,
+			"priority": 1
+		},
+		{
+			"id": "group_2",
+			"type": "test",
+			"scope": "auth",
+			"files": ["tests/auth/oauth.test.ts", "tests/auth/tokens.test.ts"],
+			"description": "OAuth2 refresh token tests",
+			"line_count": 120,
+			"priority": 2
+		},
+		{
+			"id": "group_3",
+			"type": "docs",
+			"scope": "auth",
+			"files": ["docs/auth/oauth2.md"],
+			"description": "OAuth2 setup documentation",
+			"line_count": 50,
+			"priority": 3
+		}
+	],
+	"rationale": "Large changeset (315 LOC) with separable concerns: implementation, tests, and documentation can be independent commits"
+}
+```
+
+## Success Criteria
+
+- ✅ Strategy determined (single vs split)
+- ✅ If split, changes grouped logically
+- ✅ Each group is atomic and coherent
+- ✅ Commit order respects dependencies
+- ✅ Rationale provided for decision
+
+## Rules
+
+**DO**:
+
+- ✅ Keep migrations separate from code changes
+- ✅ Split when changeset > 500 LOC
+- ✅ Group by logical units, not file types
+- ✅ Ensure each commit is buildable/testable
+
+**DON'T**:
+
+- ❌ Split too granularly (1 file = 1 commit)
+- ❌ Create commits that break the build
+- ❌ Mix unrelated changes in one commit
+- ❌ Separate tightly coupled changes

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

@@ -0,0 +1,380 @@
+---
+id: code.determine-labels
+version: 1.0.0
+category: code
+experimental: true
+name: Determine Labels
+description: Automatically determine appropriate labels for pull request based on changes
+tags:
+  - labels
+  - categorization
+  - 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: labels_arg
+    description: User-specified labels
+    type: string
+    required: false
+  - name: change_types
+    description: Types of changes
+    type: object
+    required: true
+  - name: impact_areas
+    description: Functional areas impacted
+    type: object
+    required: true
+  - name: breaking_changes
+    description: Breaking changes detected
+    type: array
+    required: true
+  - name: complexity_metrics
+    description: Change complexity
+    type: object
+    required: true
+outputs:
+  - labels_list
+  - label_rationale
+tokens:
+  avg: 2000
+  max: 4000
+  min: 1000
+---
+
+# Determine Labels
+
+## Objective
+
+Automatically determine appropriate GitHub labels for the pull request based on change analysis.
+
+## Instructions
+
+### Step 1: Check for Manual Labels
+
+If `labels_arg` is provided:
+
+- Parse comma-separated labels
+- Return as-is with minimal rationale
+- Skip auto-detection logic
+
+**Example**: `--labels=feature,backend` → `["feature", "backend"]`
+
+### Step 2: Detect Available Labels
+
+Query repository for available labels:
+
+```bash
+gh label list --json name,description
+```
+
+**Extract**:
+
+- Label names
+- Label descriptions
+- Common label patterns
+
+**Common label patterns**:
+
+- Change type: `feature`, `bug`, `enhancement`, `refactor`, `chore`
+- Areas: `backend`, `frontend`, `api`, `database`, `infrastructure`
+- Priority: `critical`, `high`, `medium`, `low`, `p0`, `p1`, `p2`
+- Status: `needs-review`, `work-in-progress`, `ready`, `blocked`
+- Special: `breaking-change`, `security`, `performance`, `documentation`
+
+### Step 3: Determine Change Type Labels
+
+From `change_types.primary`, map to labels:
+
+**Mapping**:
+
+| Commit Type | Label                          |
+| ----------- | ------------------------------ |
+| `feat`      | `feature` or `enhancement`     |
+| `fix`       | `bug` or `bugfix`              |
+| `refactor`  | `refactor` or `technical-debt` |
+| `chore`     | `chore` or `maintenance`       |
+| `docs`      | `documentation`                |
+| `test`      | `testing`                      |
+| `perf`      | `performance`                  |
+| `style`     | `styling`                      |
+| `ci`        | `ci-cd`                        |
+| `build`     | `build`                        |
+| `security`  | `security`                     |
+
+**Select most appropriate** label that exists in repository.
+
+### Step 4: Determine Area Labels
+
+From `impact_areas.primary` and `impact_areas.secondary`:
+
+**Common area labels**:
+
+- `backend` - Backend services, APIs
+- `frontend` - UI, client code
+- `api` - API endpoints
+- `database` - Schema, migrations
+- `infrastructure` - DevOps, cloud
+- `authentication` or `auth` - Auth/security
+- `docs` - Documentation
+- `tests` - Testing
+
+**Select**:
+
+- Primary area (always)
+- Secondary areas (if significant changes, e.g., >20% of total)
+
+### Step 5: Determine Priority Labels
+
+Based on `complexity_metrics` and change nature:
+
+**Priority mapping**:
+
+| Criteria                    | Priority           |
+| --------------------------- | ------------------ |
+| Breaking changes present    | `critical` or `p0` |
+| Security-sensitive          | `high` or `p1`     |
+| High complexity (score >85) | `high` or `p1`     |
+| Medium complexity (61-85)   | `medium` or `p2`   |
+| Low complexity (<60)        | `low` or `p3`      |
+| Bug fix                     | `high` or `p1`     |
+| Feature                     | `medium` or `p2`   |
+| Chore/refactor              | `low` or `p3`      |
+
+**Select one** priority label (if available in repository).
+
+### Step 6: Determine Special Labels
+
+Check for special conditions:
+
+#### Breaking Change
+
+If `breaking_changes` is not empty:
+
+- Add `breaking-change` or `breaking` label
+- High priority
+
+#### Security
+
+If `impact_areas` includes `authentication` or `security`:
+
+- Add `security` label
+- Consider `needs-security-review`
+
+#### Performance
+
+If `change_types` includes `perf`:
+
+- Add `performance` label
+- Consider `needs-benchmarking`
+
+#### Dependencies
+
+If dependency files changed:
+
+- Add `dependencies` or `deps` label
+
+#### Large PR
+
+If `complexity_metrics.files_changed` > 20 or `lines_added` > 500:
+
+- Add `large-pr` or `needs-splitting` label
+
+#### Documentation
+
+If only documentation files changed:
+
+- Add `documentation` label
+- Remove technical labels
+
+#### WIP/Draft
+
+If PR is marked as draft (from command args):
+
+- Add `work-in-progress` or `wip` label
+
+### Step 7: Filter and Validate Labels
+
+**Filter**:
+
+1. Check each label exists in repository
+2. Remove duplicates
+3. Limit to 5-7 labels max (avoid label spam)
+4. Prioritize important labels
+
+**Priority order** (keep if need to limit):
+
+1. Breaking change / Security (critical)
+2. Change type (feature, bug, refactor)
+3. Primary area (backend, frontend)
+4. Priority (p0, p1, p2)
+5. Status (needs-review, wip)
+6. Secondary areas / Special labels
+
+### Step 8: Generate Rationale
+
+For each label, provide reasoning:
+
+**Example rationales**:
+
+- `feature`: "Primary change type (3 feat commits)"
+- `backend`: "Main impact area (8 files, 234 lines)"
+- `breaking-change`: "Detected breaking changes in /auth/login API"
+- `security`: "Changes to authentication module"
+- `p1`: "High priority (security-sensitive changes)"
+- `needs-review`: "Ready for review"
+
+## Output Format
+
+```json
+{
+	"labels_list": ["feature", "backend", "security", "breaking-change", "needs-review"],
+	"label_rationale": {
+		"feature": {
+			"reason": "Primary change type (3 feat commits)",
+			"confidence": "high",
+			"priority": 1
+		},
+		"backend": {
+			"reason": "Main impact area (8 files, 234 lines)",
+			"confidence": "high",
+			"priority": 2
+		},
+		"security": {
+			"reason": "Changes to authentication module",
+			"confidence": "high",
+			"priority": 1
+		},
+		"breaking-change": {
+			"reason": "Detected breaking changes in /auth/login API",
+			"confidence": "high",
+			"priority": 1
+		},
+		"needs-review": {
+			"reason": "PR ready for review",
+			"confidence": "high",
+			"priority": 3
+		}
+	},
+	"labels_available": true,
+	"labels_not_found": [],
+	"recommendations": ["Consider adding 'high' priority label for security changes"]
+}
+```
+
+## Success Criteria
+
+- ✅ 3-7 labels selected (optimal range)
+- ✅ All labels exist in repository
+- ✅ No duplicate labels
+- ✅ Rationale provided for each
+- ✅ Critical labels prioritized
+
+## Special Cases
+
+### Repository Has No Labels
+
+**Fallback**:
+
+- Return empty list
+- Suggest creating standard label set
+- Provide recommended labels
+
+### Only Custom Labels
+
+**If** repository has non-standard labels:
+
+- Attempt fuzzy matching
+- Use label descriptions to map
+- Fall back to manual assignment
+
+### Conflicting Labels
+
+**Example**: Both `bug` and `feature` detected
+
+**Resolution**:
+
+- Use primary change type (most frequent)
+- Or select based on priority (bug > feature for urgency)
+
+### Too Many Labels
+
+**If** auto-detection suggests >7 labels:
+
+- Apply priority filtering
+- Keep critical/breaking/security
+- Keep change type + primary area
+- Drop secondary areas
+- Drop low-priority labels
+
+## Examples
+
+### Example 1: Feature Addition
+
+**Input**:
+
+```json
+{
+	"change_types": { "primary": "feat" },
+	"impact_areas": { "primary": ["backend"] },
+	"breaking_changes": [],
+	"complexity_metrics": { "complexity_score": 55 }
+}
+```
+
+**Output**:
+
+```json
+{
+	"labels_list": ["feature", "backend", "medium"],
+	"label_rationale": {
+		"feature": { "reason": "Primary change type (feat)" },
+		"backend": { "reason": "Main impact area" },
+		"medium": { "reason": "Medium complexity (score: 55)" }
+	}
+}
+```
+
+---
+
+### Example 2: Breaking Bug Fix
+
+**Input**:
+
+```json
+{
+	"change_types": { "primary": "fix" },
+	"impact_areas": { "primary": ["api"] },
+	"breaking_changes": [{ "description": "Changed API signature" }],
+	"complexity_metrics": { "complexity_score": 45 }
+}
+```
+
+**Output**:
+
+```json
+{
+	"labels_list": ["bug", "api", "breaking-change", "critical"],
+	"label_rationale": {
+		"bug": { "reason": "Primary change type (fix)" },
+		"api": { "reason": "Main impact area" },
+		"breaking-change": { "reason": "Detected API signature change" },
+		"critical": { "reason": "Breaking change requires immediate attention" }
+	}
+}
+```
+
+## Notes
+
+- Labels improve discoverability and organization
+- Help with automated workflows (e.g., release notes)
+- Enable filtering and reporting
+- Should be consistent across repository