@hiai-gg/hiai-opencode 0.1.7 → 0.1.8

package/src/features/builtin-skills/skills/git-master-sections/commit-workflow.ts

@@ -1,509 +0,0 @@
-export const GIT_MASTER_COMMIT_WORKFLOW_SECTION = `## PHASE 0: Parallel Context Gathering (MANDATORY FIRST STEP)
-
-<parallel_analysis>
-**Execute ALL of the following commands IN PARALLEL to minimize latency:**
-
-\`\`\`bash
-# Group 1: Current state
-git status
-git diff --staged --stat
-git diff --stat
-
-# Group 2: History context  
-git log -30 --oneline
-git log -30 --pretty=format:"%s"
-
-# Group 3: Branch context
-git branch --show-current
-git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
-git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "NO_UPSTREAM"
-git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD 2>/dev/null
-\`\`\`
-
-**Capture these data points simultaneously:**
-1. What files changed (staged vs unstaged)
-2. Recent 30 commit messages for style detection
-3. Branch position relative to main/master
-4. Whether branch has upstream tracking
-5. Commits that would go in PR (local only)
-</parallel_analysis>
-
----
-
-## PHASE 1: Style Detection (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)
-
-<style_detection>
-**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the analysis result before moving to Phase 2.
-
-### 1.1 Language Detection
-
-\`\`\`
-Count from git log -30:
-- Korean characters: N commits
-- English only: M commits
-- Mixed: K commits
-
-DECISION:
-- If Korean >= 50% -> KOREAN
-- If English >= 50% -> ENGLISH  
-- If Mixed -> Use MAJORITY language
-\`\`\`
-
-### 1.2 Commit Style Classification
-
-| Style | Pattern | Example | Detection Regex |
-|-------|---------|---------|-----------------|
-| \`SEMANTIC\` | \`type: message\` or \`type(scope): message\` | \`feat: add login\` | \`/^(feat\\|fix\\|chore\\|refactor\\|docs\\|test\\|ci\\|style\\|perf\\|build)(\\(.+\\))?:/\` |
-| \`PLAIN\` | Just description, no prefix | \`Add login feature\` | No conventional prefix, >3 words |
-| \`SENTENCE\` | Full sentence style | \`Implemented the new login flow\` | Complete grammatical sentence |
-| \`SHORT\` | Minimal keywords | \`format\`, \`lint\` | 1-3 words only |
-
-**Detection Algorithm:**
-\`\`\`
-semantic_count = commits matching semantic regex
-plain_count = non-semantic commits with >3 words
-short_count = commits with <=3 words
-
-IF semantic_count >= 15 (50%): STYLE = SEMANTIC
-ELSE IF plain_count >= 15: STYLE = PLAIN  
-ELSE IF short_count >= 10: STYLE = SHORT
-ELSE: STYLE = PLAIN (safe default)
-\`\`\`
-
-### 1.3 MANDATORY OUTPUT (BLOCKING)
-
-**You MUST output this block before proceeding to Phase 2. NO EXCEPTIONS.**
-
-\`\`\`
-STYLE DETECTION RESULT
-======================
-Analyzed: 30 commits from git log
-
-Language: [KOREAN | ENGLISH]
-  - Korean commits: N (X%)
-  - English commits: M (Y%)
-
-Style: [SEMANTIC | PLAIN | SENTENCE | SHORT]
-  - Semantic (feat:, fix:, etc): N (X%)
-  - Plain: M (Y%)
-  - Short: K (Z%)
-
-Reference examples from repo:
-  1. "actual commit message from log"
-  2. "actual commit message from log"
-  3. "actual commit message from log"
-
-All commits will follow: [LANGUAGE] + [STYLE]
-\`\`\`
-
-**IF YOU SKIP THIS OUTPUT, YOUR COMMITS WILL BE WRONG. STOP AND REDO.**
-</style_detection>
-
----
-
-## PHASE 2: Branch Context Analysis
-
-<branch_analysis>
-### 2.1 Determine Branch State
-
-\`\`\`
-BRANCH_STATE:
-  current_branch: <name>
-  has_upstream: true | false
-  commits_ahead: N  # Local-only commits
-  merge_base: <hash>
-  
-REWRITE_SAFETY:
-  - If has_upstream AND commits_ahead > 0 AND already pushed:
-    -> WARN before force push
-  - If no upstream OR all commits local:
-    -> Safe for aggressive rewrite (fixup, reset, rebase)
-  - If on main/master:
-    -> NEVER rewrite, only new commits
-\`\`\`
-
-### 2.2 History Rewrite Strategy Decision
-
-\`\`\`
-IF current_branch == main OR current_branch == master:
-  -> STRATEGY = NEW_COMMITS_ONLY
-  -> Never fixup, never rebase
-
-ELSE IF commits_ahead == 0:
-  -> STRATEGY = NEW_COMMITS_ONLY
-  -> No history to rewrite
-
-ELSE IF all commits are local (not pushed):
-  -> STRATEGY = AGGRESSIVE_REWRITE
-  -> Fixup freely, reset if needed, rebase to clean
-
-ELSE IF pushed but not merged:
-  -> STRATEGY = CAREFUL_REWRITE  
-  -> Fixup OK but warn about force push
-\`\`\`
-</branch_analysis>
-
----
-
-## PHASE 3: Atomic Unit Planning (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)
-
-<atomic_planning>
-**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the commit plan before moving to Phase 4.
-
-### 3.0 Calculate Minimum Commit Count FIRST
-
-\`\`\`
-FORMULA: min_commits = ceil(file_count / 3)
-
- 3 files -> min 1 commit
- 5 files -> min 2 commits
- 9 files -> min 3 commits
-15 files -> min 5 commits
-\`\`\`
-
-**If your planned commit count < min_commits -> WRONG. SPLIT MORE.**
-
-### 3.1 Split by Directory/Module FIRST (Primary Split)
-
-**RULE: Different directories = Different commits (almost always)**
-
-\`\`\`
-Example: 8 changed files
-  - app/[locale]/page.tsx
-  - app/[locale]/layout.tsx
-  - components/demo/browser-frame.tsx
-  - components/demo/shopify-full-site.tsx
-  - components/pricing/pricing-table.tsx
-  - e2e/navbar.spec.ts
-  - messages/en.json
-  - messages/ko.json
-
-WRONG: 1 commit "Update landing page" (LAZY, WRONG)
-WRONG: 2 commits (still too few)
-
-CORRECT: Split by directory/concern:
-  - Commit 1: app/[locale]/page.tsx + layout.tsx (app layer)
-  - Commit 2: components/demo/* (demo components)
-  - Commit 3: components/pricing/* (pricing components)
-  - Commit 4: e2e/* (tests)
-  - Commit 5: messages/* (i18n)
-  = 5 commits from 8 files (CORRECT)
-\`\`\`
-
-### 3.2 Split by Concern SECOND (Secondary Split)
-
-**Within same directory, split by logical concern:**
-
-\`\`\`
-Example: components/demo/ has 4 files
-  - browser-frame.tsx (UI frame)
-  - shopify-full-site.tsx (specific demo)
-  - review-dashboard.tsx (NEW - specific demo)
-  - tone-settings.tsx (NEW - specific demo)
-
-Option A (acceptable): 1 commit if ALL tightly coupled
-Option B (preferred): 2 commits
-  - Commit: "Update existing demo components" (browser-frame, shopify)
-  - Commit: "Add new demo components" (review-dashboard, tone-settings)
-\`\`\`
-
-### 3.3 NEVER Do This (Anti-Pattern Examples)
-
-\`\`\`
-WRONG: "Refactor entire landing page" - 1 commit with 15 files
-WRONG: "Update components and tests" - 1 commit mixing concerns
-WRONG: "Big update" - Any commit touching 5+ unrelated files
-
-RIGHT: Multiple focused commits, each 1-4 files max
-RIGHT: Each commit message describes ONE specific change
-RIGHT: A reviewer can understand each commit in 30 seconds
-\`\`\`
-
-### 3.4 Implementation + Test Pairing (MANDATORY)
-
-\`\`\`
-RULE: Test files MUST be in same commit as implementation
-
-Test patterns to match:
-- test_*.py <-> *.py
-- *_test.py <-> *.py
-- *.test.ts <-> *.ts
-- *.spec.ts <-> *.ts
-- __tests__/*.ts <-> *.ts
-- tests/*.py <-> src/*.py
-\`\`\`
-
-### 3.5 MANDATORY JUSTIFICATION (Before Creating Commit Plan)
-
-**NON-NEGOTIABLE: Before finalizing your commit plan, you MUST:**
-
-\`\`\`
-FOR EACH planned commit with 3+ files:
-  1. List all files in this commit
-  2. Write ONE sentence explaining why they MUST be together
-  3. If you can't write that sentence -> SPLIT
-  
-TEMPLATE:
-"Commit N contains [files] because [specific reason they are inseparable]."
-
-VALID reasons:
-  VALID: "implementation file + its direct test file"
-  VALID: "type definition + the only file that uses it"
-  VALID: "migration + model change (would break without both)"
-  
-INVALID reasons (MUST SPLIT instead):
-  INVALID: "all related to feature X" (too vague)
-  INVALID: "part of the same PR" (not a reason)
-  INVALID: "they were changed together" (not a reason)
-  INVALID: "makes sense to group" (not a reason)
-\`\`\`
-
-**OUTPUT THIS JUSTIFICATION in your analysis before executing commits.**
-
-### 3.7 Dependency Ordering
-
-\`\`\`
-Level 0: Utilities, constants, type definitions
-Level 1: Models, schemas, interfaces
-Level 2: Services, business logic
-Level 3: API endpoints, controllers
-Level 4: Configuration, infrastructure
-
-COMMIT ORDER: Level 0 -> Level 1 -> Level 2 -> Level 3 -> Level 4
-\`\`\`
-
-### 3.8 Create Commit Groups
-
-For each logical feature/change:
-\`\`\`yaml
-- group_id: 1
-  feature: "Add Shopify discount deletion"
-  files:
-    - errors/shopify_error.py
-    - types/delete_input.py
-    - mutations/update_contract.py
-    - tests/test_update_contract.py
-  dependency_level: 2
-  target_commit: null | <existing-hash>  # null = new, hash = fixup
-\`\`\`
-
-### 3.9 MANDATORY OUTPUT (BLOCKING)
-
-**You MUST output this block before proceeding to Phase 4. NO EXCEPTIONS.**
-
-\`\`\`
-COMMIT PLAN
-===========
-Files changed: N
-Minimum commits required: ceil(N/3) = M
-Planned commits: K
-Status: K >= M (PASS) | K < M (FAIL - must split more)
-
-COMMIT 1: [message in detected style]
-  - path/to/file1.py
-  - path/to/file1_test.py
-  Justification: implementation + its test
-
-COMMIT 2: [message in detected style]
-  - path/to/file2.py
-  Justification: independent utility function
-
-COMMIT 3: [message in detected style]
-  - config/settings.py
-  - config/constants.py
-  Justification: tightly coupled config changes
-
-Execution order: Commit 1 -> Commit 2 -> Commit 3
-(follows dependency: Level 0 -> Level 1 -> Level 2 -> ...)
-\`\`\`
-
-**VALIDATION BEFORE EXECUTION:**
-- Each commit has <=4 files (or justified)
-- Each commit message matches detected STYLE + LANGUAGE
-- Test files paired with implementation
-- Different directories = different commits (or justified)
-- Total commits >= min_commits
-
-**IF ANY CHECK FAILS, DO NOT PROCEED. REPLAN.**
-</atomic_planning>
-
----
-
-## PHASE 4: Commit Strategy Decision
-
-<strategy_decision>
-### 4.1 For Each Commit Group, Decide:
-
-\`\`\`
-FIXUP if:
-  - Change complements existing commit's intent
-  - Same feature, fixing bugs or adding missing parts
-  - Review feedback incorporation
-  - Target commit exists in local history
-
-NEW COMMIT if:
-  - New feature or capability
-  - Independent logical unit
-  - Different issue/ticket
-  - No suitable target commit exists
-\`\`\`
-
-### 4.2 History Rebuild Decision (Aggressive Option)
-
-\`\`\`
-CONSIDER RESET & REBUILD when:
-  - History is messy (many small fixups already)
-  - Commits are not atomic (mixed concerns)
-  - Dependency order is wrong
-  
-RESET WORKFLOW:
-  1. git reset --soft $(git merge-base HEAD main)
-  2. All changes now staged
-  3. Re-commit in proper atomic units
-  4. Clean history from scratch
-  
-ONLY IF:
-  - All commits are local (not pushed)
-  - User explicitly allows OR branch is clearly WIP
-\`\`\`
-
-### 4.3 Final Plan Summary
-
-\`\`\`yaml
-EXECUTION_PLAN:
-  strategy: FIXUP_THEN_NEW | NEW_ONLY | RESET_REBUILD
-  fixup_commits:
-    - files: [...]
-      target: <hash>
-  new_commits:
-    - files: [...]
-      message: "..."
-      level: N
-  requires_force_push: true | false
-\`\`\`
-</strategy_decision>
-
----
-
-## PHASE 5: Commit Execution
-
-<execution>
-### 5.1 Register TODO Items
-
-Use TodoWrite to register each commit as a trackable item:
-\`\`\`
-- [ ] Fixup: <description> -> <target-hash>
-- [ ] New: <description>
-- [ ] Rebase autosquash
-- [ ] Final verification
-\`\`\`
-
-### 5.2 Fixup Commits (If Any)
-
-\`\`\`bash
-# Stage files for each fixup
-git add <files>
-git commit --fixup=<target-hash>
-
-# Repeat for all fixups...
-
-# Single autosquash rebase at the end
-MERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
-GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE
-\`\`\`
-
-### 5.3 New Commits (After Fixups)
-
-For each new commit group, in dependency order:
-
-\`\`\`bash
-# Stage files
-git add <file1> <file2> ...
-
-# Verify staging
-git diff --staged --stat
-
-# Commit with detected style
-git commit -m "<message-matching-COMMIT_CONFIG>"
-
-# Verify
-git log -1 --oneline
-\`\`\`
-
-### 5.4 Commit Message Generation
-
-**Based on COMMIT_CONFIG from Phase 1:**
-
-\`\`\`
-IF style == SEMANTIC AND language == KOREAN:
-  -> "feat: 로그인 기능 추가"
-  
-IF style == SEMANTIC AND language == ENGLISH:
-  -> "feat: add login feature"
-  
-IF style == PLAIN AND language == KOREAN:
-  -> "로그인 기능 추가"
-  
-IF style == PLAIN AND language == ENGLISH:
-  -> "Add login feature"
-  
-IF style == SHORT:
-  -> "format" / "type fix" / "lint"
-\`\`\`
-
-**VALIDATION before each commit:**
-1. Does message match detected style?
-2. Does language match detected language?
-3. Is it similar to examples from git log?
-
-If ANY check fails -> REWRITE message.
-\`\`\`
-\</execution>
-
----
-
-## PHASE 6: Verification & Cleanup
-
-<verification>
-### 6.1 Post-Commit Verification
-
-\`\`\`bash
-# Check working directory clean
-git status
-
-# Review new history
-git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD
-
-# Verify each commit is atomic
-# (mentally check: can each be reverted independently?)
-\`\`\`
-
-### 6.2 Force Push Decision
-
-\`\`\`
-IF fixup was used AND branch has upstream:
-  -> Requires: git push --force-with-lease
-  -> WARN user about force push implications
-  
-IF only new commits:
-  -> Regular: git push
-\`\`\`
-
-### 6.3 Final Report
-
-\`\`\`
-COMMIT SUMMARY:
-  Strategy: <what was done>
-  Commits created: N
-  Fixups merged: M
-  
-HISTORY:
-  <hash1> <message1>
-  <hash2> <message2>
-  ...
-
-NEXT STEPS:
-  - git push [--force-with-lease]
-  - Create PR if ready
-\`\`\`
-</verification>`