Rewrites 14 commands across 11 plugins to remove all cross-plugin subagent_type references (e.g., "unit-testing::test-automator"), which break when plugins are installed standalone. Each command now uses only local bundled agents or general-purpose with role context in the prompt. All rewritten commands follow conductor-style patterns: - CRITICAL BEHAVIORAL RULES with strong directives - State files for session tracking and resume support - Phase checkpoints requiring explicit user approval - File-based context passing between steps Also fixes 4 plugin.json files missing version/license fields and adds plugin.json for dotnet-contribution. Closes #433
17 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| Orchestrate git workflow from code review through PR creation with quality gates | <target branch> [--skip-tests] [--draft-pr] [--no-push] [--squash] [--conventional] [--trunk-based] |
Git Workflow Orchestrator
CRITICAL BEHAVIORAL RULES
You MUST follow these rules exactly. Violating any of them is a failure.
- Execute steps in order. Do NOT skip ahead, reorder, or merge steps.
- Write output files. Each step MUST produce its output file in
.git-workflow/before the next step begins. Read from prior step files — do NOT rely on context window memory. - Stop at checkpoints. When you reach a
PHASE CHECKPOINT, you MUST stop and wait for explicit user approval before continuing. Use the AskUserQuestion tool with clear options. - Halt on failure. If any step fails (agent error, test failure, missing dependency), STOP immediately. Present the error and ask the user how to proceed. Do NOT silently continue.
- Use only local agents. All
subagent_typereferences use agents bundled with this plugin orgeneral-purpose. No cross-plugin dependencies. - Never enter plan mode autonomously. Do NOT use EnterPlanMode. This command IS the plan — execute it.
Pre-flight Checks
Before starting, perform these checks:
1. Check for existing session
Check if .git-workflow/state.json exists:
-
If it exists and
statusis"in_progress": Read it, display the current step, and ask the user:Found an in-progress git workflow session: Target branch: [branch from state] Current step: [step from state] 1. Resume from where we left off 2. Start fresh (archives existing session) -
If it exists and
statusis"complete": Ask whether to archive and start fresh.
2. Initialize state
Create .git-workflow/ directory and state.json:
{
"target_branch": "$ARGUMENTS",
"status": "in_progress",
"flags": {
"skip_tests": false,
"draft_pr": false,
"no_push": false,
"squash": false,
"conventional": true,
"trunk_based": false
},
"current_step": 1,
"current_phase": 1,
"completed_steps": [],
"files_created": [],
"started_at": "ISO_TIMESTAMP",
"last_updated": "ISO_TIMESTAMP"
}
Parse $ARGUMENTS for the target branch (defaults to 'main') and flags. Use defaults if not specified.
3. Gather git context
Run these commands and save output:
git status— current working tree stategit diff --stat— summary of changesgit diff— full diff of changesgit log --oneline -10— recent commit historygit branch --show-current— current branch name
Save this context to .git-workflow/00-git-context.md.
Phase 1: Pre-Commit Review and Analysis (Steps 1–2)
Step 1: Code Quality Assessment
Read .git-workflow/00-git-context.md.
Use the Task tool to launch the code reviewer:
Task:
subagent_type: "code-reviewer"
description: "Review uncommitted changes for code quality"
prompt: |
Review all uncommitted changes for code quality issues.
## Git Context
[Insert contents of .git-workflow/00-git-context.md]
Check for:
1. Code style violations
2. Security vulnerabilities
3. Performance concerns
4. Missing error handling
5. Incomplete implementations
Generate a detailed report with severity levels (critical/high/medium/low) and provide
specific line-by-line feedback.
## Deliverables
Output format: structured report with:
- Issues list with severity, file, line, description
- Summary counts: {critical: N, high: N, medium: N, low: N}
- Recommendations for fixes
Write your complete review as a single markdown document.
Save the agent's output to .git-workflow/01-code-review.md.
Update state.json: set current_step to 2, add step 1 to completed_steps.
Step 2: Dependency and Breaking Change Analysis
Read .git-workflow/00-git-context.md and .git-workflow/01-code-review.md.
Use the Task tool:
Task:
subagent_type: "code-reviewer"
description: "Analyze changes for dependencies and breaking changes"
prompt: |
Analyze the changes for dependency and breaking change issues.
## Git Context
[Insert contents of .git-workflow/00-git-context.md]
## Code Review
[Insert contents of .git-workflow/01-code-review.md]
Check for:
1. New dependencies or version changes
2. Breaking API changes
3. Database schema modifications
4. Configuration changes
5. Backward compatibility issues
Identify any changes that require migration scripts or documentation updates.
## Deliverables
1. Breaking change assessment
2. Dependency change analysis
3. Migration requirements
4. Documentation update needs
Write your complete analysis as a single markdown document.
Save output to .git-workflow/02-breaking-changes.md.
Update state.json: set current_step to "checkpoint-1", add step 2 to completed_steps.
PHASE CHECKPOINT 1 — User Approval Required
Display a summary of code review and breaking change analysis and ask:
Pre-commit review complete. Please review:
- .git-workflow/01-code-review.md
- .git-workflow/02-breaking-changes.md
Issues found: [X critical, Y high, Z medium, W low]
Breaking changes: [summary]
1. Approve — proceed to testing (or skip if --skip-tests)
2. Fix issues first — I'll address the critical/high issues
3. Pause — save progress and stop here
If user selects option 2, address the critical/high issues, then re-run the review and re-checkpoint.
Do NOT proceed to Phase 2 until the user approves.
Phase 2: Testing and Validation (Steps 3–4)
If --skip-tests flag is set, skip to Phase 3. Write a note in .git-workflow/03-test-results.md explaining tests were skipped.
Step 3: Test Execution and Coverage
Read .git-workflow/00-git-context.md and .git-workflow/01-code-review.md.
Use the Task tool:
Task:
subagent_type: "general-purpose"
description: "Execute test suites for modified code"
prompt: |
You are a test automation expert. Execute all test suites for the modified code.
## Git Context
[Insert contents of .git-workflow/00-git-context.md]
## Code Review Issues
[Insert contents of .git-workflow/01-code-review.md]
Run:
1. Unit tests
2. Integration tests
3. End-to-end tests if applicable
Generate coverage report and identify untested code paths. Ensure tests cover the
critical/high issues identified in the code review.
## Deliverables
Report with:
- Test results: passed, failed, skipped
- Coverage metrics: statements, branches, functions, lines
- Untested critical paths
- Recommendations for additional tests
Write your complete test report as a single markdown document.
Save output to .git-workflow/03-test-results.md.
Update state.json: set current_step to 4, add step 3 to completed_steps.
Step 4: Test Recommendations and Gap Analysis
Read .git-workflow/03-test-results.md and .git-workflow/02-breaking-changes.md.
Use the Task tool:
Task:
subagent_type: "general-purpose"
description: "Identify test gaps and recommend additional tests"
prompt: |
You are a test automation expert. Based on test results and code changes, identify
testing gaps.
## Test Results
[Insert contents of .git-workflow/03-test-results.md]
## Breaking Changes
[Insert contents of .git-workflow/02-breaking-changes.md]
Identify:
1. Missing test scenarios
2. Edge cases not covered
3. Integration points needing verification
4. Performance benchmarks needed
Generate test implementation recommendations prioritized by risk.
## Deliverables
1. Prioritized list of additional tests needed
2. Edge case coverage gaps
3. Integration test recommendations
4. Risk assessment for untested paths
Write your complete analysis as a single markdown document.
Save output to .git-workflow/04-test-gaps.md.
Update state.json: set current_step to "checkpoint-2", add step 4 to completed_steps.
PHASE CHECKPOINT 2 — User Approval Required
Display test results summary and ask:
Testing complete. Please review:
- .git-workflow/03-test-results.md
- .git-workflow/04-test-gaps.md
Test results: [X passed, Y failed, Z skipped]
Coverage: [summary]
Test gaps: [summary of critical gaps]
1. Approve — proceed to commit message generation
2. Fix failing tests first
3. Pause — save progress and stop here
Do NOT proceed to Phase 3 until the user approves. If tests are failing, the user must address them first.
Phase 3: Commit Message Generation (Steps 5–6)
Step 5: Change Analysis and Categorization
Read .git-workflow/00-git-context.md and .git-workflow/03-test-results.md.
Use the Task tool:
Task:
subagent_type: "code-reviewer"
description: "Categorize changes for commit message"
prompt: |
Analyze all changes and categorize them according to Conventional Commits specification.
## Git Context
[Insert contents of .git-workflow/00-git-context.md]
## Test Results
[Insert contents of .git-workflow/03-test-results.md]
Identify the primary change type (feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert)
and scope. Determine if this should be a single commit or multiple atomic commits.
## Deliverables
1. Change type classification
2. Scope identification
3. Single vs multiple commit recommendation
4. Commit structure with groupings
Write your complete categorization as a single markdown document.
Save output to .git-workflow/05-change-categorization.md.
Update state.json: set current_step to 6, add step 5 to completed_steps.
Step 6: Conventional Commit Message Creation
Read .git-workflow/05-change-categorization.md and .git-workflow/02-breaking-changes.md.
Use the Task tool:
Task:
subagent_type: "general-purpose"
description: "Create Conventional Commits message for changes"
prompt: |
You are an expert at writing clear, well-structured Conventional Commits messages.
Create commit message(s) based on the change categorization.
## Change Categorization
[Insert contents of .git-workflow/05-change-categorization.md]
## Breaking Changes
[Insert contents of .git-workflow/02-breaking-changes.md]
Format: <type>(<scope>): <subject>
- Clear subject line (50 chars max)
- Detailed body explaining what and why (not how)
- Footer with BREAKING CHANGE: if applicable
- References to issues/tickets
- Co-authors if applicable
## Deliverables
1. Formatted commit message(s) ready to use
2. Rationale for commit structure choice
Write the commit messages as a single markdown document with clear delimiters.
Save output to .git-workflow/06-commit-messages.md.
Update state.json: set current_step to "checkpoint-3", add step 6 to completed_steps.
PHASE CHECKPOINT 3 — User Approval Required
Display the proposed commit message(s) and ask:
Commit message(s) ready. Please review .git-workflow/06-commit-messages.md
[Display the commit message(s)]
1. Approve — proceed to branch management and push
2. Edit message — tell me what to change
3. Pause — save progress and stop here
Do NOT proceed to Phase 4 until the user approves.
Phase 4: Branch Strategy and Push (Steps 7–8)
Step 7: Branch Management and Pre-Push Validation
Read .git-workflow/00-git-context.md, .git-workflow/06-commit-messages.md, and all previous step files.
Use the Task tool:
Task:
subagent_type: "general-purpose"
description: "Prepare branch strategy and validate push readiness"
prompt: |
You are a deployment engineer specializing in git workflows and CI/CD.
## Git Context
[Insert contents of .git-workflow/00-git-context.md]
## Workflow Flags
[Insert flags from state.json]
Based on workflow type (trunk-based or feature-branch):
For feature branch:
- Ensure branch name follows pattern (feature|bugfix|hotfix)/<ticket>-<description>
- Verify no conflicts with target branch
For trunk-based:
- Prepare for direct main push with feature flag strategy if needed
Perform pre-push checks:
1. Verify all CI checks will pass
2. Confirm no sensitive data in commits
3. Validate commit signatures if required
4. Check branch protection rules
5. Ensure all review comments addressed
## Deliverables
1. Branch preparation commands
2. Conflict status
3. Pre-push validation results
4. Push readiness confirmation or blocking issues
Write your complete validation as a single markdown document.
Save output to .git-workflow/07-branch-validation.md.
Update state.json: set current_step to 8, add step 7 to completed_steps.
If --no-push flag is set, skip Step 8 and proceed to Phase 5.
Step 8: Execute Git Operations
Based on the approved commit messages and branch validation:
- Stage changes:
git addthe relevant files - Create commit(s) using the approved messages from
.git-workflow/06-commit-messages.md - If
--squashflag: squash commits as configured - Push to remote with appropriate flags
Important: Before executing any git operations, display the planned commands and ask for final confirmation:
Ready to execute git operations:
[List exact commands]
1. Execute — run these commands
2. Modify — adjust the commands
3. Abort — do not execute
Save execution results to .git-workflow/08-push-results.md.
Update state.json: set current_step to "checkpoint-4", add step 8 to completed_steps.
PHASE CHECKPOINT 4 — User Approval Required (if not --no-push)
Git operations complete. Please review .git-workflow/08-push-results.md
1. Approve — proceed to PR creation
2. Pause — save progress and stop here
Phase 5: Pull Request Creation (Steps 9–10)
If --no-push flag is set, skip this phase entirely.
Step 9: PR Description Generation
Read all .git-workflow/*.md files.
Use the Task tool:
Task:
subagent_type: "general-purpose"
description: "Create comprehensive PR description"
prompt: |
You are a technical writer specializing in pull request documentation.
Create a comprehensive PR description.
## Code Review
[Insert contents of .git-workflow/01-code-review.md]
## Breaking Changes
[Insert contents of .git-workflow/02-breaking-changes.md]
## Test Results
[Insert contents of .git-workflow/03-test-results.md]
## Commit Messages
[Insert contents of .git-workflow/06-commit-messages.md]
Include:
1. Summary of changes (what and why)
2. Type of change checklist
3. Testing performed summary
4. Screenshots/recordings note if UI changes
5. Deployment notes
6. Related issues/tickets
7. Breaking changes section if applicable
8. Reviewer checklist
Format as GitHub-flavored Markdown.
Write the complete PR description as a single markdown document.
Save output to .git-workflow/09-pr-description.md.
Update state.json: set current_step to 10, add step 9 to completed_steps.
Step 10: PR Creation and Metadata
Read .git-workflow/09-pr-description.md and .git-workflow/00-git-context.md.
Create the PR using the gh CLI:
- Use the description from
.git-workflow/09-pr-description.md - Set draft status if
--draft-prflag is set - Add appropriate labels based on change categorization
- Link related issues if referenced
Important: Display the planned PR creation command and ask for confirmation:
Ready to create PR:
Title: [proposed title]
Target: [target branch]
Draft: [yes/no]
1. Create PR — execute now
2. Edit — adjust title or description
3. Skip — don't create PR
Save PR URL and metadata to .git-workflow/10-pr-created.md.
Update state.json: set current_step to "complete", add step 10 to completed_steps.
Completion
Update state.json:
- Set
statusto"complete" - Set
last_updatedto current timestamp
Present the final summary:
Git workflow complete!
## Files Created
[List all .git-workflow/ output files]
## Workflow Summary
- Code Review: .git-workflow/01-code-review.md
- Breaking Changes: .git-workflow/02-breaking-changes.md
- Test Results: .git-workflow/03-test-results.md
- Test Gaps: .git-workflow/04-test-gaps.md
- Change Categorization: .git-workflow/05-change-categorization.md
- Commit Messages: .git-workflow/06-commit-messages.md
- Branch Validation: .git-workflow/07-branch-validation.md
- Push Results: .git-workflow/08-push-results.md
- PR Description: .git-workflow/09-pr-description.md
- PR Created: .git-workflow/10-pr-created.md
## Results
- Code issues: [X critical, Y high resolved]
- Tests: [X passed, Y failed]
- PR: [URL if created]
## Rollback Procedures
1. Immediate Revert: Create revert PR with `git revert <commit-hash>`
2. Feature Flag Disable: If using feature flags, disable immediately
3. Hotfix Branch: For critical issues, create hotfix branch from main
4. Communication: Notify team via designated channels