devflow-kit 0.1.2 → 0.3.0

package/src/claude/agents/devflow/research.md

@@ -118,20 +118,20 @@ For each approach, document:
 ```bash
 echo "=== DOCUMENTATION RESEARCH ==="
 
-# Look for package.json or requirements to understand current stack
-if [ -f "package.json" ]; then
-    echo "Node.js project detected"
-    cat package.json | grep -A 20 "dependencies"
-elif [ -f "requirements.txt" ]; then
-    echo "Python project detected"
-    cat requirements.txt
-elif [ -f "Cargo.toml" ]; then
-    echo "Rust project detected"
-    cat Cargo.toml | grep -A 10 "dependencies"
-elif [ -f "go.mod" ]; then
-    echo "Go project detected"
-    cat go.mod
-fi
+# Auto-detect project stack from common manifest files
+echo "Detecting project stack..."
+for manifest in package.json requirements.txt Pipfile Cargo.toml go.mod Gemfile pom.xml build.gradle composer.json Package.swift; do
+    if [ -f "$manifest" ]; then
+        echo "=== Found: $manifest ==="
+        head -30 "$manifest" | grep -i "depend\|version\|name" || head -30 "$manifest"
+        echo ""
+    fi
+done
+
+# Show detected languages from git (file extensions)
+echo "Primary file types in project:"
+find . -type f ! -path "*/.*" ! -path "*/node_modules/*" ! -path "*/vendor/*" ! -path "*/target/*" ! -path "*/build/*" ! -path "*/dist/*" 2>/dev/null \
+    | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -10
 ```
 
 **For each relevant library/framework**:
@@ -185,17 +185,23 @@ echo "=== CODEBASE PATTERN ANALYSIS ==="
 # Find similar existing implementations
 echo "Searching for similar patterns..."
 
-# Example: If implementing auth, search for existing auth patterns
-# grep -r "auth\|Auth\|authenticate" --include="*.js" --include="*.ts" . | head -20
+# Generic search across all source files (language-agnostic)
+# Example: If implementing auth, adapt the search term below
+# find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.py" -o -name "*.go" -o -name "*.rs" \
+#     -o -name "*.java" -o -name "*.rb" -o -name "*.php" -o -name "*.cs" -o -name "*.cpp" \) \
+#     ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/vendor/*" ! -path "*/target/*" \
+#     -exec grep -l "auth\|authenticate" {} \; | head -20
 
 # Find architectural patterns
 echo "Analyzing project structure..."
 ls -la | head -20
-find . -type f -name "*.config.*" -o -name "*.json" | head -10
+find . -type f \( -name "*.config.*" -o -name "*.json" -o -name "*.yaml" -o -name "*.yml" -o -name "*.toml" \) \
+    ! -path "*/node_modules/*" ! -path "*/.git/*" | head -15
 
-# Look for test patterns
+# Look for test patterns (language-agnostic)
 echo "Checking test patterns..."
-find . -type f -name "*.test.*" -o -name "*.spec.*" | head -10
+find . -type f \( -name "*test*" -o -name "*spec*" -o -name "*Test*" -o -name "*Spec*" \) \
+    ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/vendor/*" | head -15
 ```
 
 **Analysis Areas**:
@@ -217,17 +223,22 @@ find . -type f -name "*.test.*" -o -name "*.spec.*" | head -10
 ### 4.2 Code Style & Conventions
 
 ```bash
-# Check TypeScript/JavaScript patterns
-if [ -f "tsconfig.json" ]; then
-    echo "TypeScript configuration:"
-    cat tsconfig.json | head -30
-fi
-
-# Check linting rules
-if [ -f ".eslintrc.js" ] || [ -f ".eslintrc.json" ]; then
-    echo "ESLint configuration found"
-    cat .eslintrc.* | head -20
-fi
+# Auto-detect language configuration files
+echo "=== DETECTING CODE STYLE & CONVENTIONS ==="
+
+# Check for common configuration files across languages
+for config in tsconfig.json jsconfig.json .eslintrc* .prettierrc* pyproject.toml setup.cfg .pylintrc \
+    .rubocop.yml Cargo.toml rustfmt.toml .editorconfig .clang-format checkstyle.xml; do
+    if [ -f "$config" ] || ls $config 2>/dev/null | grep -q .; then
+        echo "=== Found: $config ==="
+        head -30 "$config" 2>/dev/null
+        echo ""
+    fi
+done
+
+# Look for linter/formatter patterns
+echo "Checking for linting/formatting tools..."
+ls -la | grep -E "lint|format|style" | head -10
 ```
 
 **Document**:
@@ -247,9 +258,17 @@ fi
 # Find similar features already implemented
 echo "Looking for similar existing features..."
 
-# Example searches - adapt to specific research topic
-# grep -r "export.*function" --include="*.ts" --include="*.js" . | head -10
-# grep -r "export.*class" --include="*.ts" --include="*.js" . | head -10
+# Generic pattern search across all source files (adapt search term to research topic)
+# Example: searching for function/class definitions across common languages
+# find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" \
+#     -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.java" -o -name "*.rb" \
+#     -o -name "*.php" -o -name "*.cs" -o -name "*.cpp" -o -name "*.c" -o -name "*.h" \) \
+#     ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/vendor/*" ! -path "*/target/*" \
+#     -exec grep -H "^export\|^public\|^def\|^func\|^fn\|^function\|^class" {} \; 2>/dev/null | head -20
+
+# Show most commonly edited files (good candidates for similar patterns)
+echo "Frequently modified files (likely contain patterns to follow):"
+git log --pretty=format: --name-only --since="6 months ago" 2>/dev/null | sort | uniq -c | sort -rn | head -15
 ```
 
 **Analyze and document**:

package/src/claude/commands/devflow/pre-commit.md

@@ -7,6 +7,13 @@ allowed-tools: Task, Bash, Read, Write, Grep, Glob
 
 Perform a comprehensive review of uncommitted changes by orchestrating multiple specialized sub-agents in parallel. This provides quick feedback before committing changes.
 
+**Audit Strategy**:
+- **Always Run** (5 core audits): Security, Performance, Architecture, Tests, Complexity
+- **Language-Specific** (conditional): TypeScript (runs only if .ts/.tsx files changed or tsconfig.json exists)
+- **Available on demand**: Documentation, Dependencies, Database (use `/pre-pr` for full audit)
+
+This lightweight approach provides fast feedback for individual commits. Use `/pre-pr` for comprehensive branch reviews before creating pull requests.
+
 ### Step 1: Analyze Current Changes
 
 First, check what changes are available for review:
@@ -32,10 +39,15 @@ echo ""
 Launch these sub-agents in parallel:
 
 1. audit-security sub-agent
-2. audit-performance sub-agent
-3. audit-architecture sub-agent
-4. audit-tests sub-agent
-5. audit-complexity sub-agent
+2. audit-typescript sub-agent (automatically skips if not applicable)
+3. audit-performance sub-agent
+4. audit-architecture sub-agent
+5. audit-tests sub-agent
+6. audit-complexity sub-agent
+
+**Note**: The audit-typescript agent contains built-in detection logic and will automatically skip if:
+- No .ts/.tsx files were changed AND
+- No tsconfig.json exists in the project
 
 ### Step 3: Synthesize Review Findings
 
@@ -78,6 +90,9 @@ Create a comprehensive review document at `.docs/reviews/diff-{YYYY-MM-DD_HHMM}.
 ### Security Review (audit-security)
 {security findings with file:line references}
 
+### TypeScript Review (audit-typescript)
+{type safety findings, or "⏭️ Skipped - not applicable" if no TS files}
+
 ### Performance Review (audit-performance)
 {performance findings with specific optimizations}
 

package/src/claude/commands/devflow/pre-pr.md

@@ -53,27 +53,52 @@ git log --oneline $BASE_BRANCH..HEAD
 echo ""
 ```
 
-### Step 2: Launch Specialized Sub-Agents in Parallel
+### Step 2: Detect Change Categories
 
-Launch these sub-agents in parallel:
+Analyze what types of changes are in this branch to determine which specialized agents are needed:
 
+```bash
+# Check if database-related files changed
+DB_CHANGES=$(git diff --name-only $BASE_BRANCH...HEAD | grep -E '\.(sql|prisma|migration|knex|sequelize|db)' || true)
+DB_CHANGES+=$(git diff --name-only $BASE_BRANCH...HEAD | grep -iE '(migration|schema|database|models/)' || true)
+
+if [ -n "$DB_CHANGES" ]; then
+    echo "🗄️  Database changes detected - will run database audit"
+    INCLUDE_DB_AUDIT=true
+else
+    echo "ℹ️  No database changes detected - skipping database audit"
+    INCLUDE_DB_AUDIT=false
+fi
+echo ""
+```
+
+### Step 3: Launch Specialized Sub-Agents in Parallel
+
+Launch these sub-agents in parallel based on change detection:
+
+**Core Audits (Always Run)**:
 1. audit-security sub-agent
 2. audit-performance sub-agent
 3. audit-architecture sub-agent
 4. audit-tests sub-agent
 5. audit-complexity sub-agent
 6. audit-dependencies sub-agent
+7. audit-documentation sub-agent
 
-### Step 3: Synthesize Comprehensive Review
+**Conditional Audits** (automatically detect and skip if not applicable):
+8. audit-typescript sub-agent (only if .ts/.tsx files changed or tsconfig.json exists)
+9. audit-database sub-agent (only if database changes detected)
+
+### Step 4: Synthesize Comprehensive Review
 
 After all sub-agents complete their analysis:
 
-1. **Collect Results**: Gather findings from all 6 specialized sub-agents
+1. **Collect Results**: Gather findings from all 7-8 specialized sub-agents (depending on change types)
 2. **Cross-Reference Issues**: Identify overlapping concerns between domains
 3. **Prioritize for PR**: Focus on merge-blocking vs nice-to-have improvements
 4. **Create PR-Ready Review**: Structure for easy consumption by human reviewers
 
-### Step 4: Save Comprehensive Review Document
+### Step 5: Save Comprehensive Review Document
 
 Create a detailed review document at `.docs/reviews/branch-{BRANCH_NAME}-{YYYY-MM-DD_HHMM}.md`:
 
@@ -133,6 +158,16 @@ Create a detailed review document at `.docs/reviews/branch-{BRANCH_NAME}-{YYYY-M
 #### Security Recommendations
 {specific security improvements needed}
 
+### 📘 TypeScript Analysis (audit-typescript)
+**Type Safety**: {Excellent/Good/Acceptable/Poor}
+**Note**: Only included if TypeScript files changed or project uses TypeScript
+
+#### TypeScript Issues Found
+{detailed type safety findings with file:line references}
+
+#### TypeScript Recommendations
+{specific type safety improvements needed}
+
 ### ⚡ Performance Analysis (audit-performance)
 **Performance Impact**: {Positive/Neutral/Negative}
 
@@ -178,6 +213,25 @@ Create a detailed review document at `.docs/reviews/branch-{BRANCH_NAME}-{YYYY-M
 #### Dependency Recommendations
 {specific dependency management improvements}
 
+### 📚 Documentation Analysis (audit-documentation)
+**Documentation Quality**: {Excellent/Good/Acceptable/Poor}
+
+#### Documentation Issues Found
+{detailed documentation drift, missing docs, stale examples}
+
+#### Documentation Recommendations
+{specific documentation updates needed}
+
+### 🗄️ Database Analysis (audit-database)
+**Database Health**: {Excellent/Good/Acceptable/Poor}
+**Note**: Only included if database changes detected
+
+#### Database Issues Found
+{detailed database design, migration, and query issues}
+
+#### Database Recommendations
+{specific database improvements needed}
+
 ---
 
 ## 🎯 Action Plan
@@ -204,11 +258,14 @@ Create a detailed review document at `.docs/reviews/branch-{BRANCH_NAME}-{YYYY-M
 
 **Breakdown**:
 - Security: {score}/10
+- TypeScript: {score}/10 (if applicable)
 - Performance: {score}/10
 - Architecture: {score}/10
 - Test Coverage: {score}/10
 - Maintainability: {score}/10
 - Dependencies: {score}/10
+- Documentation: {score}/10
+- Database: {score}/10 (if applicable)
 
 ### Comparison to {BASE_BRANCH}
 - Quality Trend: {Improving/Stable/Declining}
@@ -253,7 +310,7 @@ Based on sub-agent analysis, human reviewers should focus on:
 *Next: Address blocking issues, then create PR with this review as reference*
 ```
 
-### Step 5: Provide Executive Summary
+### Step 6: Provide Executive Summary
 
 Give the developer a clear, actionable summary:
 

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

@@ -0,0 +1,251 @@
+---
+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