devflow-kit 0.9.0 → 1.1.0

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

@@ -1,223 +0,0 @@
----
-allowed-tools: AskUserQuestion, TodoWrite, Bash
-description: Triage issues from discussion - implement now, defer to GitHub issue, or skip
----
-
-## Your task
-
-Triage issues and decisions from the current conversation. For each item, help user understand it and decide: implement now, defer to GitHub issue, or skip entirely. Convert "now" decisions into actionable todos.
-
-**Goal**: Deliberate decision-making on each issue, not batch selection.
-
----
-
-## Step 1: Extract Issues from Conversation
-
-Scan the conversation for:
-- **Technical issues** found in code review
-- **Design decisions** that need to be made
-- **Bugs or vulnerabilities** discovered
-- **Refactoring opportunities** discussed
-- **Missing features** or incomplete implementations
-- **Technical debt** identified
-- **Questions or uncertainties** raised
-
-For each item, note:
-- What is it?
-- Why does it matter?
-- Severity/impact (Critical, High, Medium, Low)
-
-Group similar or trivial items together for batch triage.
-
----
-
-## Step 2: Triage Each Issue
-
-Present issues one at a time (or in small batches for similar items):
-
-```markdown
-## Issue ${n}/${total}: ${short_title}
-
-**What**: ${clear_explanation}
-
-**Why it matters**: ${impact_and_consequences}
-
-**Severity**: ${Critical|High|Medium|Low}
-```
-
-Then ask using `AskUserQuestion`:
-
-```
-header: "Issue ${n}"
-question: "What do you want to do with: ${short_title}?"
-multiSelect: false
-options: [
-  {
-    label: "Implement now",
-    description: "Add to current implementation tasks"
-  },
-  {
-    label: "Create GitHub issue",
-    description: "Defer to later - will create and lock issue"
-  },
-  {
-    label: "Skip entirely",
-    description: "Not relevant or not worth tracking"
-  }
-]
-```
-
-**Batch similar issues** when appropriate:
-```
-header: "Simple fixes"
-question: "These 3 similar issues (typos, formatting, minor cleanup) - handle them together?"
-options: [
-  { label: "Implement all now", description: "Add all to current tasks" },
-  { label: "Create single GitHub issue", description: "Group into one deferred issue" },
-  { label: "Skip all", description: "Not worth the effort" }
-]
-```
-
-**Handle emerging clarifications**: If user's response raises new questions or reveals misunderstandings, address them immediately before continuing triage.
-
----
-
-## Step 3: Create GitHub Issues for Deferred Items
-
-For each "Create GitHub issue" decision, use `Bash` to create the issue:
-
-```bash
-gh issue create \
-  --title "${issue_title}" \
-  --body "$(cat <<'EOF'
-## Context
-
-${why_this_was_identified}
-
-## Issue Details
-
-${clear_description_of_the_issue}
-
-## Suggested Approach
-
-${potential_solution_if_discussed}
-
-## Severity
-
-${Critical|High|Medium|Low}
-
----
-
-*Created during triage session. Review before implementation.*
-EOF
-)" \
-  --label "${appropriate_labels}"
-```
-
-Then lock the issue (no reason required):
-
-```bash
-gh issue lock ${issue_number}
-```
-
-Track created issues for final summary.
-
----
-
-## Step 4: Convert "Now" Items to Actionable Todos
-
-For all items marked "Implement now":
-
-1. **Break down** into specific, actionable tasks
-2. **Order** by dependencies and priority
-3. **Estimate** complexity (simple: 15min, medium: 30min, complex: 1hr+)
-
-Good task breakdown:
-- ✅ "Fix SQL injection in `src/db/users.ts:45` - use parameterized queries"
-- ✅ "Add input validation for email field in registration endpoint"
-- ✅ "Refactor `UserService` to use Result types instead of throwing"
-
-Bad task breakdown:
-- ❌ "Fix security issues" (too vague)
-- ❌ "Improve error handling" (not specific)
-
----
-
-## Step 5: Save Todos with TodoWrite
-
-Use `TodoWrite` to save actionable tasks:
-
-```json
-[
-  {
-    "content": "${specific_task_description}",
-    "status": "pending",
-    "activeForm": "${task_in_progress_form}"
-  }
-]
-```
-
-Each task should be:
-- Completable in 15-60 minutes
-- Clear success criteria
-- Include file paths when relevant
-- Ordered by dependencies
-
----
-
-## Step 6: Final Summary
-
-```markdown
-## TRIAGE COMPLETE
-
-### Implementing Now (${count} items → ${task_count} tasks)
-
-${For each "now" item:}
-- **${issue_title}**
-  - ${brief_description}
-  - Tasks: ${list_of_specific_todos}
-
-### Deferred to GitHub Issues (${count} items)
-
-${For each deferred item:}
-- **${issue_title}** → Issue #${number}
-  - ${brief_description}
-  - Severity: ${severity}
-  - [View issue](${issue_url})
-
-### Skipped (${count} items)
-
-${For each skipped item:}
-- ${issue_title} - ${reason_user_gave_or_inferred}
-
----
-
-**Next Steps**:
-- ${task_count} tasks saved to todo list
-- ${issue_count} GitHub issues created and locked
-- Run `/implement` to start working through tasks
-```
-
----
-
-## Behavior Rules
-
-### ALWAYS:
-- Explain each issue clearly before asking for decision
-- Create actual GitHub issues via `gh` CLI
-- Lock created issues immediately
-- Break "now" items into specific, actionable todos
-- Track all decisions for final summary
-- Address clarifications that arise during triage
-
-### NEVER:
-- Present all issues as a batch selection list
-- Skip the understanding phase
-- Create vague or unactionable todos
-- Forget to lock GitHub issues
-- Ignore user questions that arise during triage
-
-### Handle Edge Cases:
-- **No issues found**: "I didn't identify any issues to triage from this conversation. Did I miss something?"
-- **gh CLI not available**: Warn user, offer to output issue text for manual creation
-- **User wants to reconsider**: Allow changing previous decisions before final save

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

@@ -1,20 +0,0 @@
----
-allowed-tools: Task
-description: Create pull request with comprehensive analysis and smart description generation
----
-
-## Your task
-
-Launch the `pull-request` sub-agent to create a PR from the current branch.
-
-Pass `$ARGUMENTS` to the sub-agent (may contain base branch and/or `--draft` flag).
-
-The agent will:
-1. Detect current branch and base branch (auto-detect if not specified)
-2. Run pre-flight checks (commits exist, no existing PR, branch pushed)
-3. Analyze commits and code changes
-4. Generate PR title and comprehensive description
-5. Create the PR using `gh pr create`
-6. Return the PR URL
-
-Trust the agent's judgment. It handles all validation and creation.

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