devflow-kit 0.8.1 → 1.0.0

package/src/claude/commands/devflow/pull-request.md

@@ -1,269 +0,0 @@
----
-allowed-tools: Task, Bash
-description: Create pull request with comprehensive analysis and smart description generation
----
-
-## Your task
-
-Create a pull request from the current branch with a comprehensive description generated by analyzing commits and code changes. This command orchestrates PR creation using the `pull-request` sub-agent for deep analysis.
-
-### Step 1: Parse Arguments and Detect Context
-
-Parse the arguments to determine base branch and PR options:
-
-```bash
-# Parse arguments
-BASE_BRANCH=""
-DRAFT_FLAG=""
-
-for arg in $ARGUMENTS; do
-  case $arg in
-    --draft)
-      DRAFT_FLAG="--draft"
-      ;;
-    *)
-      if [ -z "$BASE_BRANCH" ]; then
-        BASE_BRANCH="$arg"
-      fi
-      ;;
-  esac
-done
-
-# Get current branch
-CURRENT_BRANCH=$(git branch --show-current)
-if [ -z "$CURRENT_BRANCH" ]; then
-    echo "❌ Not on a branch (detached HEAD). Checkout a feature branch first."
-    exit 1
-fi
-
-# Auto-detect base branch if not specified
-if [ -z "$BASE_BRANCH" ]; then
-  for branch in main master develop; do
-    if git show-ref --verify --quiet refs/heads/$branch; then
-      BASE_BRANCH=$branch
-      break
-    fi
-  done
-fi
-
-if [ -z "$BASE_BRANCH" ]; then
-    echo "❌ Could not auto-detect base branch. Specify manually: /pull-request <base-branch>"
-    exit 1
-fi
-
-echo "=== PR CREATION CONTEXT ==="
-echo "Current branch: $CURRENT_BRANCH"
-echo "Base branch: $BASE_BRANCH"
-echo "Draft mode: ${DRAFT_FLAG:-disabled}"
-echo ""
-```
-
-### Step 2: Pre-Flight Checks
-
-Verify the branch state and catch common issues:
-
-```bash
-echo "=== PRE-FLIGHT CHECKS ==="
-
-# Check if branch has commits ahead of base
-COMMITS_AHEAD=$(git rev-list --count $BASE_BRANCH..HEAD)
-if [ "$COMMITS_AHEAD" -eq 0 ]; then
-    echo "❌ No commits to create PR. Branch is up to date with $BASE_BRANCH."
-    exit 1
-fi
-
-# Check if PR already exists for this branch
-EXISTING_PR=$(gh pr list --head "$CURRENT_BRANCH" --json number --jq '.[0].number' 2>/dev/null || echo "")
-if [ -n "$EXISTING_PR" ]; then
-    echo "⚠️ PR #$EXISTING_PR already exists for branch $CURRENT_BRANCH"
-    echo "View: gh pr view $EXISTING_PR"
-    echo "Update: git push to update existing PR"
-    exit 1
-fi
-
-# Check if branch is pushed to remote
-if ! git ls-remote --exit-code --heads origin "$CURRENT_BRANCH" >/dev/null 2>&1; then
-    echo "⚠️ Branch not pushed to remote. Pushing now..."
-    git push -u origin "$CURRENT_BRANCH"
-fi
-
-# Show quick summary
-echo "✅ Ready to create PR"
-echo "   Commits: $COMMITS_AHEAD ahead of $BASE_BRANCH"
-git log --oneline $BASE_BRANCH..HEAD | head -5
-echo ""
-```
-
-### Step 3: Launch Pull Request Sub-Agent
-
-Launch the `pull-request` sub-agent to analyze commits and generate PR content:
-
-**IMPORTANT**: Pass these variables to the sub-agent:
-- `CURRENT_BRANCH`: The branch being reviewed
-- `BASE_BRANCH`: The base branch for comparison
-
-The sub-agent will:
-1. Analyze commit history and messages
-2. Analyze code changes and impact
-3. Extract issue references
-4. Detect breaking changes
-5. Generate PR title and comprehensive description
-6. Assess PR size and suggest splits if needed
-
-Use the Task tool to launch the sub-agent with subagent_type="pull-request":
-
-```
-Launch pull-request sub-agent with:
-- Current branch: {CURRENT_BRANCH}
-- Base branch: {BASE_BRANCH}
-
-The sub-agent will analyze all commits and changes between {BASE_BRANCH} and {CURRENT_BRANCH}, then generate:
-- PR title following conventional commit format
-- Comprehensive PR description with:
-  - Summary of changes
-  - Breaking changes (if any)
-  - Testing recommendations
-  - Related issues
-- Size assessment and recommendations
-
-Return the complete PR title and description ready for `gh pr create`.
-```
-
-### Step 4: Review Sub-Agent Output
-
-After the sub-agent completes, extract the generated PR content and present it to the user for review:
-
-```markdown
-📝 GENERATED PR CONTENT
-
-**Title:**
-{generated PR title}
-
-**Description:**
-{generated PR description}
-
----
-
-**Size Assessment:**
-- Files changed: {X}
-- Lines changed: {Y}
-- Complexity: {Simple/Medium/Complex/Too Large}
-
-{If too large, show recommendations for splitting}
-
-**Recommendations from analysis:**
-{Any warnings or suggestions from sub-agent}
-```
-
-### Step 5: Create Pull Request
-
-Create the PR using `gh pr create` with the generated content:
-
-```bash
-# Save PR body to temp file to preserve formatting
-PR_BODY=$(cat <<'EOF'
-{generated PR description from sub-agent}
-EOF
-)
-
-# Create the PR
-gh pr create \
-  --base "$BASE_BRANCH" \
-  --head "$CURRENT_BRANCH" \
-  --title "{generated PR title}" \
-  --body "$PR_BODY" \
-  $DRAFT_FLAG
-
-# Capture the PR URL
-PR_URL=$(gh pr view --json url --jq '.url' 2>/dev/null || echo "")
-```
-
-### Step 6: Provide Success Summary
-
-Present the final summary to the user:
-
-```markdown
-✅ PULL REQUEST CREATED
-
-🔗 **PR URL:** {PR_URL}
-
-📊 **Summary:**
-- Branch: {CURRENT_BRANCH} → {BASE_BRANCH}
-- Commits: {X} commits
-- Files: {Y} files changed
-- Status: {Draft/Ready for review}
-
-💡 **Next Steps:**
-- View PR: gh pr view {PR_NUMBER}
-- Request reviews: gh pr edit {PR_NUMBER} --add-reviewer @username
-- Monitor CI checks: gh pr checks {PR_NUMBER}
-- If changes needed, push commits or use /resolve-comments after review
-
-📝 **Full PR details:** {PR_URL}
-```
-
----
-
-## Usage Examples
-
-### Basic Usage
-```bash
-# Create PR to main branch (auto-detected)
-/pull-request
-
-# Create PR to develop branch
-/pull-request develop
-
-# Create draft PR
-/pull-request --draft
-
-# Create draft PR to specific base
-/pull-request develop --draft
-```
-
-### When to Use
-
-**✅ Use /pull-request when:**
-- You have commits ready for review
-- Branch is ready for team review
-- You want comprehensive PR description
-- You want to detect breaking changes automatically
-
-**⚠️ Before using:**
-- Run `/code-review` to validate quality
-- Ensure all commits are meaningful (not WIP)
-- Consider if PR is too large (should it be split?)
-
-**💡 Pro Tips:**
-- For small PRs (<10 files), this generates great descriptions automatically
-- For large PRs (>20 files), consider the split recommendations
-- Draft PRs are great for early feedback without formal review requests
-- PR description can be edited after creation with `gh pr edit`
-
----
-
-## Command Behavior
-
-### Pre-Flight Validation:
-- ✅ Verifies branch has commits ahead of base
-- ✅ Checks for existing PRs on this branch
-- ✅ Ensures branch is pushed to remote
-- ✅ Validates base branch exists
-
-### PR Content Generation:
-- ✅ Analyzes all commits since branching from base
-- ✅ Groups changes by feature/fix/refactor
-- ✅ Extracts issue references automatically
-- ✅ Detects breaking changes from commit messages
-- ✅ Generates testing recommendations
-
-### Safety Features:
-- ⚠️ Warns if PR is too large (>500 lines changed)
-- ⚠️ Suggests splitting strategy for large PRs
-- ⚠️ Detects missing tests or documentation
-- ⚠️ Highlights security-sensitive changes
-
-### Integration:
-- Works seamlessly with `/code-review` (run before PR creation)
-- Complements `/resolve-comments` (for handling feedback after PR)
-- Follows conventional commit format for consistency

package/src/claude/commands/devflow/release.md

@@ -1,251 +0,0 @@
----
-description: Automated release workflow with version management and publishing
-allowed-tools: Task, Bash, Read, Write, Edit, Grep, Glob
----
-
-## Your Task
-
-Orchestrate a complete release workflow using the release sub-agent. This command guides you through creating a professional release with version management, changelog generation, building, testing, and publishing.
-
-**Workflow**: User input → Release agent automation → User confirmations at critical steps
-
-### Step 1: Determine Release Type
-
-First, ask the user what type of release they want to create:
-
-```bash
-echo "🚀 DEVFLOW RELEASE AUTOMATION"
-echo ""
-echo "This will guide you through creating a new release."
-echo ""
-```
-
-Present options to the user:
-
-```
-What type of release do you want to create?
-
-1. **patch** - Bug fixes and maintenance (0.1.2 → 0.1.3)
-2. **minor** - New features, backwards compatible (0.1.2 → 0.2.0)
-3. **major** - Breaking changes (0.1.2 → 1.0.0)
-4. **custom** - Specify exact version (e.g., 2.0.0-beta.1)
-5. **analyze** - Analyze changes and get recommendation first
-
-Please specify the release type (patch/minor/major/custom/analyze):
-```
-
-### Step 2: Launch Release Agent
-
-Once the user provides input, launch the release sub-agent with the appropriate prompt:
-
-**If user chose "analyze"**:
-```
-Invoke the release sub-agent with this prompt:
-
-"Analyze the current repository state and recent commits. Execute through Step 3 (Determine New Version) and provide a recommendation for the version bump type. Show:
-- Current version
-- Commits since last release
-- Breaking changes, features, and fixes detected
-- Recommended version bump with reasoning
-
-Stop and wait for user decision before proceeding with the release."
-```
-
-**If user chose "patch", "minor", or "major"**:
-```
-Invoke the release sub-agent with this prompt:
-
-"Create a {bump_type} release. Follow the complete release workflow:
-1. Detect project type and configuration
-2. Verify clean working directory
-3. Analyze recent changes since last release
-4. Calculate new version as {bump_type} bump
-5. Generate changelog entry from commits
-6. Update version files
-7. Build project (if applicable)
-8. Run tests (if applicable)
-
-STOP before Step 8 (Commit Version Bump) and show me:
-- Current version → New version
-- Generated changelog entry
-- Files that will be modified
-- Build/test results
-
-Wait for my confirmation before proceeding with commit, push, publish, and tagging."
-```
-
-**If user chose "custom"**:
-```
-Ask user: "Please specify the exact version number (e.g., 2.0.0-beta.1):"
-
-Then invoke the release sub-agent with this prompt:
-
-"Create a release with custom version {specified_version}. Follow the complete release workflow:
-1. Detect project type and configuration
-2. Verify clean working directory
-3. Analyze recent changes since last release
-4. Use the specified version: {specified_version}
-5. Generate changelog entry from commits
-6. Update version files
-7. Build project (if applicable)
-8. Run tests (if applicable)
-
-STOP before Step 8 (Commit Version Bump) and show me:
-- Current version → New version
-- Generated changelog entry
-- Files that will be modified
-- Build/test results
-
-Wait for my confirmation before proceeding with commit, push, publish, and tagging."
-```
-
-### Step 3: Review and Confirm
-
-After the release agent completes the preparation phase and stops, present the summary to the user:
-
-```
-📋 RELEASE READY FOR REVIEW
-
-Current Version: {current_version}
-New Version: {new_version}
-Project Type: {project_type}
-
-📝 Changelog Entry:
-{generated_changelog}
-
-📄 Files to be Modified:
-- {version_file}
-- {changelog_file}
-
-✅ Build Status: {build_result}
-✅ Test Status: {test_result}
-
----
-
-The release agent will now:
-1. Commit version bump
-2. Push to remote
-3. Publish package (if applicable)
-4. Create git tag
-5. Create GitHub/GitLab release (if available)
-
-⚠️  WARNING: Steps 3-5 are PERMANENT and PUBLIC
-
-Do you want to proceed with the release? (yes/no):
-```
-
-### Step 4: Complete Release (After Confirmation)
-
-If user confirms, continue with the release agent:
-
-```
-Invoke the release sub-agent again with this prompt:
-
-"Continue the release process from Step 8 (Commit Version Bump):
-8. Commit version bump
-9. Push to remote
-10. Publish package (if applicable) - STOP and ask for confirmation before publishing
-11. Create git tag
-12. Create GitHub/GitLab release
-13. Provide final summary
-
-Execute these steps sequentially. Before Step 10 (publishing to package registry), STOP and explicitly ask for confirmation as this is permanent and public."
-```
-
-### Step 5: Publish Confirmation
-
-When the agent reaches the publish step, ask for explicit confirmation:
-
-```
-⚠️  FINAL CONFIRMATION REQUIRED
-
-The package is ready to be published to the public registry.
-
-Project: {project_name}
-Version: {new_version}
-Registry: {registry_name}
-Command: {publish_command}
-
-This action is PERMANENT and IRREVERSIBLE.
-
-Do you want to publish to the public registry? (yes/no):
-```
-
-### Step 6: Final Summary
-
-After the release is complete, the agent will provide a final summary. Display it to the user and provide next steps:
-
-```
-The release agent will show:
-- Release summary with all completed steps
-- Links to package registry
-- Links to GitHub/GitLab release
-- Links to tag and commits
-- Verification steps for the user
-
-Next steps for you:
-1. Verify package appears in registry
-2. Test installation in fresh environment
-3. Announce release to users/team
-4. Update documentation if needed
-```
-
-## Error Handling
-
-If the release agent encounters an error at any step:
-
-1. **Before commit**: Changes can be rolled back easily
-   ```bash
-   git checkout {version_files}
-   ```
-
-2. **After commit, before push**: Can amend or reset
-   ```bash
-   git reset --hard HEAD~1
-   ```
-
-3. **After push, before publish**: Can remove tag and revert
-   ```bash
-   git tag -d {tag}
-   git push origin :{tag}
-   git revert HEAD
-   ```
-
-4. **After publish**: Cannot unpublish in most registries
-   - npm: Can only deprecate, not unpublish after 24h
-   - Document issue and create patch release
-
-Always provide clear recovery instructions if something fails.
-
-## Safety Features
-
-- ✅ Verify clean working directory before starting
-- ✅ Show preview of all changes before committing
-- ✅ Require explicit confirmation before publishing
-- ✅ Provide rollback instructions at each step
-- ✅ Stop and ask before any permanent/public action
-- ✅ Generate proper semantic versioning
-- ✅ Run build and tests before releasing
-
-## Quick Reference
-
-```bash
-# Standard releases
-/release   # Interactive - asks for release type
-
-# With specific type (if supported in future)
-/release patch
-/release minor
-/release major
-
-# Analyze first
-/release analyze   # Show recommendations without releasing
-```
-
-## Notes
-
-- The release sub-agent handles all the technical details
-- This command provides the user interaction layer
-- Critical steps require explicit user confirmation
-- All actions are logged and can be audited
-- Works with any programming language/ecosystem