pro-workflow
Advanced tools
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
| #!/usr/bin/env node | ||
| /** | ||
| * ConfigChange Hook (Claude Code 2.1.49+) | ||
| * | ||
| * Fires when configuration files change during a session. | ||
| * Detects when quality gates, hooks, or permissions are modified. | ||
| * | ||
| * Input (stdin): { config_file, changes } | ||
| * Output (stdout): Same JSON (pass-through) | ||
| */ | ||
| const fs = require('fs'); | ||
| const path = require('path'); | ||
| const os = require('os'); | ||
| function getTempDir() { | ||
| return path.join(os.tmpdir(), 'pro-workflow'); | ||
| } | ||
| function ensureDir(dir) { | ||
| if (!fs.existsSync(dir)) { | ||
| fs.mkdirSync(dir, { recursive: true }); | ||
| } | ||
| } | ||
| function log(msg) { | ||
| console.error(msg); | ||
| } | ||
| async function main() { | ||
| let data = ''; | ||
| process.stdin.on('data', chunk => { | ||
| data += chunk; | ||
| }); | ||
| process.stdin.on('end', () => { | ||
| try { | ||
| const input = JSON.parse(data); | ||
| const configFile = input.config_file || input.file || ''; | ||
| const fileName = path.basename(configFile); | ||
| const sensitiveFiles = [ | ||
| 'settings.json', | ||
| 'settings.local.json', | ||
| 'hooks.json', | ||
| '.claudeignore' | ||
| ]; | ||
| const isSensitive = sensitiveFiles.some(f => fileName === f); | ||
| if (isSensitive) { | ||
| log(`[ProWorkflow] Config changed: ${fileName}`); | ||
| if (fileName === 'hooks.json') { | ||
| log('[ProWorkflow] Hooks configuration modified — quality gates may be affected'); | ||
| } | ||
| if (fileName === 'settings.json' || fileName === 'settings.local.json') { | ||
| log('[ProWorkflow] Settings changed mid-session — verify permissions are as expected'); | ||
| } | ||
| const tempDir = getTempDir(); | ||
| ensureDir(tempDir); | ||
| const logFile = path.join(tempDir, 'config-changes.log'); | ||
| const MAX_LOG_SIZE = 100 * 1024; | ||
| try { | ||
| const stat = fs.statSync(logFile); | ||
| if (stat.size > MAX_LOG_SIZE) { | ||
| fs.writeFileSync(logFile, ''); | ||
| } | ||
| } catch (_e) { | ||
| // File doesn't exist yet | ||
| } | ||
| const entry = `${new Date().toISOString()} ${configFile}\n`; | ||
| fs.appendFileSync(logFile, entry); | ||
| } | ||
| console.log(data); | ||
| } catch (err) { | ||
| console.error('[ProWorkflow] config-watcher error:', err.message); | ||
| console.log(data || '{}'); | ||
| } | ||
| }); | ||
| } | ||
| main().catch(err => { | ||
| console.error('[ProWorkflow] Error:', err.message); | ||
| process.exit(0); | ||
| }); |
| #!/usr/bin/env node | ||
| const fs = require('fs'); | ||
| const path = require('path'); | ||
| function getStore() { | ||
| const distPath = path.join(__dirname, '..', 'dist', 'db', 'store.js'); | ||
| if (fs.existsSync(distPath)) { | ||
| const mod = require(distPath); | ||
| if (typeof mod.createStore === 'function') { | ||
| return mod.createStore(); | ||
| } | ||
| } | ||
| return null; | ||
| } | ||
| async function main() { | ||
| let data = ''; | ||
| process.stdin.on('data', chunk => { data += chunk; }); | ||
| process.stdin.on('end', () => { | ||
| try { | ||
| const input = JSON.parse(data); | ||
| const response = input.assistant_response || ''; | ||
| if (!response) { | ||
| console.log(data); | ||
| return; | ||
| } | ||
| const regex = /\[LEARN\]\s*([\w][\w\s-]*?)\s*:\s*(.+?)(?:\nMistake:\s*(.+?))?(?:\nCorrection:\s*(.+?))?(?=\n\[LEARN\]|\n\n|$)/gim; | ||
| let match; | ||
| let store = null; | ||
| let count = 0; | ||
| let lastIndex = -1; | ||
| while ((match = regex.exec(response)) !== null) { | ||
| if (regex.lastIndex === lastIndex) break; | ||
| lastIndex = regex.lastIndex; | ||
| if (!store) store = getStore(); | ||
| if (!store) break; | ||
| const projectDir = process.env.CLAUDE_PROJECT_DIR || ''; | ||
| store.addLearning({ | ||
| project: projectDir ? path.basename(projectDir) : null, | ||
| category: match[1].trim(), | ||
| rule: match[2].trim(), | ||
| mistake: match[3]?.trim() || null, | ||
| correction: match[4]?.trim() || null, | ||
| }); | ||
| count++; | ||
| } | ||
| if (count > 0) { | ||
| console.error(`[ProWorkflow] Auto-saved ${count} learning(s) to database`); | ||
| } | ||
| if (store) store.close(); | ||
| } catch (err) { | ||
| console.error(`[ProWorkflow] Learn-capture error: ${err.message}`); | ||
| } | ||
| console.log(data); | ||
| }); | ||
| } | ||
| main().catch(() => process.exit(0)); |
| --- | ||
| name: deslop | ||
| description: Remove AI-generated code slop, unnecessary comments, and over-engineering from the current branch diff. Use after completing changes and before committing. | ||
| --- | ||
| # Remove AI Code Slop | ||
| Check the diff against main and remove AI-generated slop introduced in the branch. | ||
| ## Trigger | ||
| Use after completing changes, before committing, or when code feels over-engineered. | ||
| ## Commands | ||
| ```bash | ||
| git fetch origin main | ||
| git diff origin/main...HEAD --stat | ||
| git diff origin/main...HEAD | ||
| ``` | ||
| ## Focus Areas | ||
| - Extra comments that state the obvious or are inconsistent with local style | ||
| - Defensive try/catch blocks that are abnormal for trusted internal code paths | ||
| - Casts to `any` used only to bypass type issues | ||
| - Over-engineered abstractions for one-time operations (premature helpers, factories) | ||
| - Deeply nested code that should be simplified with early returns | ||
| - Backwards-compatibility hacks (renamed `_vars`, re-exports, `// removed` comments) | ||
| - Features, refactoring, or "improvements" beyond what was requested | ||
| - Added docstrings, type annotations, or comments on code that wasn't changed | ||
| - Error handling for scenarios that can't happen in trusted internal paths | ||
| ## Guardrails | ||
| - Keep behavior unchanged unless fixing a clear bug. | ||
| - Prefer minimal, focused edits over broad rewrites. | ||
| - Three similar lines of code is better than a premature abstraction. | ||
| - If you remove something, verify it's truly unused first. | ||
| - Keep the final summary concise (1-3 sentences). | ||
| ## Output | ||
| - List of slop patterns found with file locations | ||
| - Edits applied | ||
| - One-line summary of what was cleaned |
| --- | ||
| name: insights | ||
| description: Show session analytics, learning patterns, correction trends, heatmaps, and productivity metrics. Use when wanting to understand your coding patterns over time. | ||
| --- | ||
| # Session Insights | ||
| Surface patterns from learnings and session history. | ||
| ## Trigger | ||
| Use when asking "show stats", "how am I doing", "analytics", "insights", "heatmap", or "correction rate". | ||
| ## What It Shows | ||
| ### Session Summary | ||
| ``` | ||
| Session Insights | ||
| Duration: 47 min | ||
| Edits: 23 files modified | ||
| Corrections: 2 self-corrections applied | ||
| Learnings: 3 new patterns captured | ||
| Context: 62% used (safe) | ||
| ``` | ||
| ### Learning Analytics | ||
| ``` | ||
| Learning Insights (42 total) | ||
| Top categories: | ||
| Testing 12 learnings (29%) | ||
| Navigation 8 learnings (19%) | ||
| Git 7 learnings (17%) | ||
| Quality 6 learnings (14%) | ||
| Most applied: | ||
| #12 [Testing] Run tests before commit — 15 times | ||
| #8 [Navigation] Confirm path for common names — 11 times | ||
| Stale learnings (never applied): | ||
| #15 [Editing] Prefer named exports — 0 times (45 days old) | ||
| ``` | ||
| ### Correction Heatmap | ||
| ``` | ||
| Correction Heatmap | ||
| By category (all time): | ||
| ████████████ Testing 34 corrections | ||
| ████████ Navigation 22 corrections | ||
| ██████ Git 18 corrections | ||
| ████ Quality 12 corrections | ||
| Hot learnings (most corrected, least learned): | ||
| - [Testing] Mock external deps — corrected 8x, learned 0x | ||
| → Consider: /learn-rule to capture this permanently | ||
| Cold learnings (learned but never applied): | ||
| - [Editing] Use named exports — learned 45 days ago, applied 0x | ||
| → Consider removing if no longer relevant | ||
| ``` | ||
| ### Productivity Metrics | ||
| ``` | ||
| Productivity (last 10 sessions) | ||
| Avg session: 35 min | ||
| Avg edits/session: 18 | ||
| Correction rate: 12% (improving) | ||
| Learning capture: 2.1 per session | ||
| ``` | ||
| ## Guardrails | ||
| - Use actual data from project memory and session history. | ||
| - Surface actionable suggestions, not just numbers. | ||
| - Flag recurring corrections that should become permanent rules. | ||
| - Identify stale learnings that may no longer be relevant. | ||
| ## Output | ||
| Formatted analytics report with: | ||
| - Current session stats | ||
| - Category breakdown | ||
| - Most/least applied learnings | ||
| - Correction trends with suggestions | ||
| - Productivity metrics over time |
| --- | ||
| name: learn-rule | ||
| description: Capture a correction or lesson as a persistent learning rule with category, mistake, and correction. Use after mistakes or when the user says "remember this". | ||
| --- | ||
| # Learn Rule | ||
| Capture a lesson from the current session into permanent memory. | ||
| ## Trigger | ||
| Use when the user says "remember this", "add to rules", "don't do that again", or after a mistake is identified. | ||
| ## Workflow | ||
| 1. Identify the lesson — what mistake was made? What should happen instead? | ||
| 2. Format the rule with full context. | ||
| 3. Propose the addition and wait for user approval. | ||
| 4. After approval, persist to LEARNED section or project memory. | ||
| ## Format | ||
| ``` | ||
| [LEARN] Category: One-line rule | ||
| Mistake: What went wrong | ||
| Correction: How it was fixed | ||
| ``` | ||
| ## Categories | ||
| | Category | Examples | | ||
| |----------|---------| | ||
| | Navigation | File paths, finding code, wrong file edited | | ||
| | Editing | Code changes, patterns, wrong approach | | ||
| | Testing | Test approaches, coverage gaps, flaky tests | | ||
| | Git | Commits, branches, merge issues | | ||
| | Quality | Lint, types, style violations | | ||
| | Context | When to clarify, missing requirements | | ||
| | Architecture | Design decisions, wrong abstractions | | ||
| | Performance | Optimization, O(n^2) loops, memory | | ||
| ## Example | ||
| ``` | ||
| Recent mistake: Edited wrong utils.ts file | ||
| [LEARN] Navigation: Confirm full path when multiple files share a name. | ||
| Add to LEARNED section? (y/n) | ||
| ``` | ||
| ## Guardrails | ||
| - Always wait for user approval before persisting. | ||
| - Keep rules to one line — specific and actionable. | ||
| - Bad: "Write good code". Good: "Always use snake_case for database columns". | ||
| - Include the mistake context so the rule makes sense later. | ||
| ## Output | ||
| - The proposed `[LEARN]` rule with category | ||
| - Confirmation after persisting |
| --- | ||
| name: parallel-worktrees | ||
| description: Set up parallel coding sessions using git worktrees for zero dead time. Use when blocked on tests, builds, or wanting to explore multiple approaches simultaneously. | ||
| --- | ||
| # Parallel Worktrees | ||
| Zero dead time. While one session runs tests, work on something else. | ||
| ## Trigger | ||
| Use when waiting on tests, long builds, exploring approaches, or needing to review and develop simultaneously. | ||
| ## Quick Start | ||
| **Claude Code:** | ||
| ```bash | ||
| claude --worktree # or claude -w (auto-creates isolated worktree) | ||
| ``` | ||
| **Cursor / Any editor:** | ||
| ```bash | ||
| git worktree add ../project-feat feature-branch | ||
| # Open the new worktree folder in a second editor window | ||
| ``` | ||
| Both approaches create an isolated working copy where changes don't interfere with your main session. | ||
| ## Claude Code Extras | ||
| These features are Claude Code-specific (skip if using Cursor): | ||
| - `claude -w` auto-creates and cleans up worktrees | ||
| - Subagents support `isolation: worktree` in agent frontmatter | ||
| - `Ctrl+F` kills all background agents (two-press confirmation) | ||
| - `Ctrl+B` sends a task to background | ||
| ## Workflow | ||
| 1. Show current worktrees: `git worktree list` | ||
| 2. Create a worktree for the parallel task. | ||
| 3. Open a new editor/terminal session in the worktree. | ||
| 4. When done, clean up the worktree. | ||
| ## Commands | ||
| ```bash | ||
| git worktree list | ||
| git worktree add ../project-feat feature-branch | ||
| git worktree add ../project-fix bugfix-branch | ||
| git worktree add ../project-exp -b experiment | ||
| git worktree remove ../project-feat | ||
| git worktree prune | ||
| ``` | ||
| ## Usage Pattern | ||
| ``` | ||
| Terminal 1: ~/project → Main work | ||
| Terminal 2: ~/project-feat → Feature development | ||
| Terminal 3: ~/project-fix → Bug fixes | ||
| ``` | ||
| Each worktree runs its own AI session independently. | ||
| ## When to Parallelize | ||
| | Scenario | Action | | ||
| |----------|--------| | ||
| | Tests running (2+ min) | Start new feature in worktree | | ||
| | Long build | Debug issue in parallel | | ||
| | Exploring approaches | Compare 2-3 simultaneously | | ||
| | Review + new work | Reviewer in one, dev in other | | ||
| | Waiting on CI | Start next task in worktree | | ||
| ## Guardrails | ||
| - Each worktree is a full working copy — changes are isolated. | ||
| - Don't forget to clean up worktrees when done (`git worktree prune`). | ||
| - Avoid editing the same files in multiple worktrees simultaneously. | ||
| ## Output | ||
| - Current worktree list | ||
| - Created worktree path and branch | ||
| - Instructions for opening a new session |
| --- | ||
| name: replay-learnings | ||
| description: Surface past learnings relevant to the current task before starting work. Searches correction history and patterns. Use when starting a task or saying "what do I know about". | ||
| --- | ||
| # Replay Learnings | ||
| Like muscle memory for your coding sessions. Find and surface relevant learnings before you start working. | ||
| ## Trigger | ||
| Use when starting a new task, saying "what do I know about", "before I start", "replay", or "remind me about". | ||
| ## Workflow | ||
| 1. Extract keywords from the task description. | ||
| 2. Search learnings/memory for matching patterns (corrections, rules, past mistakes). | ||
| 3. Check session history for similar work — what was the correction rate? | ||
| 4. Surface the top learnings ranked by relevance. | ||
| 5. If no learnings found, suggest starting with the scout agent to explore first. | ||
| ## Output | ||
| ``` | ||
| REPLAY BRIEFING: <task> | ||
| ======================= | ||
| Past learnings (ranked by relevance): | ||
| 1. [Testing] Always mock external APIs in auth tests (applied 8x) | ||
| Mistake: Called live API in tests, caused flaky failures | ||
| 2. [Navigation] Auth middleware is in src/middleware/ not src/auth/ (applied 5x) | ||
| 3. [Quality] Add error boundary around auth state changes (applied 3x) | ||
| Session history for similar work: | ||
| - 2026-02-01: auth refactor — 23 edits, 2 corrections (8.7% rate) | ||
| - 2026-01-28: auth middleware — 15 edits, 4 corrections (26.7% rate) | ||
| ^ Higher correction rate — review patterns before starting | ||
| Suggested approach: | ||
| - Mock external APIs (learning #1) | ||
| - Check src/middleware/ first for auth code (learning #2) | ||
| ``` | ||
| ## Guardrails | ||
| - Rank by relevance, not recency. | ||
| - Include the original mistake context so the learning is actionable. | ||
| - Flag high correction-rate sessions as areas requiring extra care. | ||
| - If no learnings match, say so explicitly rather than forcing irrelevant results. |
| --- | ||
| name: session-handoff | ||
| description: Generate a structured handoff document designed for the next session to consume immediately and continue where you left off. Use when ending a session. | ||
| --- | ||
| # Session Handoff | ||
| Different from wrap-up. Wrap-up is a checklist for *you*. Handoff is a document written for the *next session*. | ||
| ## Trigger | ||
| Use when saying "handoff", "continue later", "pass to next session", "session transfer", or ending a session and wanting to resume smoothly. | ||
| ## Workflow | ||
| 1. Gather current state from git. | ||
| 2. List completed, in-progress, and pending work. | ||
| 3. Note key decisions made and their reasoning. | ||
| 4. Capture any learnings from this session. | ||
| 5. Generate a resume command for the next session. | ||
| ## Commands | ||
| ```bash | ||
| git status | ||
| git diff --stat | ||
| git log --oneline -5 | ||
| git branch --show-current | ||
| ``` | ||
| ## Output | ||
| ```markdown | ||
| # Session Handoff — [date] [time] | ||
| ## Status | ||
| - **Branch**: feature/xyz | ||
| - **Commits this session**: 3 | ||
| - **Uncommitted changes**: 2 files modified | ||
| - **Tests**: passing / failing / not run | ||
| ## What's Done | ||
| - [completed task 1] | ||
| - [completed task 2] | ||
| ## What's In Progress | ||
| - [current task with context on where you stopped] | ||
| - [file:line that needs attention next] | ||
| ## What's Pending | ||
| - [next task that hasn't been started] | ||
| - [blocked items with reason] | ||
| ## Key Decisions Made | ||
| - [decision 1 and why] | ||
| - [decision 2 and why] | ||
| ## Learnings Captured | ||
| - [Category] Rule (from this session) | ||
| ## Files Touched | ||
| - `path/to/file1.ts` — [what changed] | ||
| - `path/to/file2.ts` — [what changed] | ||
| ## Gotchas for Next Session | ||
| - [thing that tripped you up] | ||
| - [non-obvious behavior discovered] | ||
| ## Resume Command | ||
| > Continue working on [branch]. [1-2 sentence context]. Next step: [specific action]. | ||
| ``` | ||
| ## Guardrails | ||
| - Write for the reader (next session), not the writer. | ||
| - Include specific file paths and line numbers where relevant. | ||
| - The resume command should be copy-pasteable into the next session. | ||
| - Keep it factual — describe changes functionally, don't infer motivation. |
| --- | ||
| name: smart-commit | ||
| description: Run quality gates, review staged changes for issues, and create a well-crafted conventional commit. Use when ready to commit after making changes. | ||
| --- | ||
| # Smart Commit | ||
| ## Trigger | ||
| Use when saying "commit", "save changes", or ready to commit after making changes. | ||
| ## Workflow | ||
| 1. Check current state and identify what to commit. | ||
| 2. Run quality gates (lint, typecheck, tests on affected files). | ||
| 3. Scan staged changes for issues. | ||
| 4. Draft a conventional commit message from the diff. | ||
| 5. Stage specific files, create the commit. | ||
| 6. Prompt for learnings from this change. | ||
| ## Commands | ||
| ```bash | ||
| git status | ||
| git diff --stat | ||
| npm run lint 2>&1 | tail -5 | ||
| npm run typecheck 2>&1 | tail -5 | ||
| npm test -- --changed --passWithNoTests 2>&1 | tail -10 | ||
| git add <specific files> | ||
| git commit -m "<type>(<scope>): <summary>" | ||
| ``` | ||
| ## Code Review Scan | ||
| Before committing, check staged changes for: | ||
| - `console.log` / `debugger` statements | ||
| - TODO/FIXME/HACK comments without ticket references | ||
| - Hardcoded secrets or API keys | ||
| - Leftover test-only code | ||
| Flag any issues before proceeding. | ||
| ## Commit Message Format | ||
| ``` | ||
| <type>(<scope>): <short summary> | ||
| <body - what changed and why> | ||
| ``` | ||
| **Types:** feat, fix, refactor, test, docs, chore, perf, ci, style | ||
| ## Guardrails | ||
| - Never skip quality gates unless user explicitly says to. | ||
| - Stage specific files by name. Never `git add -A` or `git add .`. | ||
| - Summary under 72 characters. Body explains *why*, not *what*. | ||
| - No generic messages ("fix bug", "update code"). | ||
| - Reference issue numbers when applicable. | ||
| ## Output | ||
| - Quality gate results (pass/fail) | ||
| - Issues found in staged changes | ||
| - Suggested commit message | ||
| - Commit hash after committing | ||
| - Prompt: any learnings to capture? |
| --- | ||
| name: wrap-up | ||
| description: End-of-session ritual that audits changes, runs quality checks, captures learnings, and produces a session summary. Use when ending a coding session. | ||
| --- | ||
| # Wrap-Up Ritual | ||
| End your coding session with intention. | ||
| ## Trigger | ||
| Use when ending a session, saying "wrap up", "done for now", or before closing the editor. | ||
| ## Workflow | ||
| 1. **Changes Audit** — What files were modified? Anything uncommitted? TODOs left in code? | ||
| 2. **Quality Check** — Run lint, typecheck, and tests. All passing? Any warnings? | ||
| 3. **Learning Capture** — What mistakes were made? What patterns worked well? Format as `[LEARN] Category: Rule` | ||
| 4. **Next Session Context** — What's the next logical task? Any blockers? Context to preserve? | ||
| 5. **Summary** — One paragraph: what was accomplished, current state, what's next. | ||
| ## Commands | ||
| ```bash | ||
| git status | ||
| git diff --stat | ||
| npm run lint 2>&1 | head -20 | ||
| npm run typecheck 2>&1 | head -20 | ||
| npm test -- --changed --passWithNoTests | ||
| ``` | ||
| ## Learning Categories | ||
| Navigation, Editing, Testing, Git, Quality, Context, Architecture, Performance | ||
| ## Guardrails | ||
| - Do not skip any checklist step. | ||
| - If tests are failing, flag before ending session. | ||
| - If uncommitted changes exist, ask whether to commit or stash. | ||
| ## Output | ||
| - Modified file list with uncommitted changes highlighted | ||
| - Quality gate results | ||
| - Captured learnings (if any) | ||
| - One-paragraph session summary | ||
| - Next session resume context | ||
| After completing checklist, ask: "Ready to end session?" |
+16
-21
| --- | ||
| name: planner | ||
| description: Specialized agent for breaking down complex tasks | ||
| description: Break down complex tasks into implementation plans before writing code. Use when task touches >5 files, requires architecture decisions, or has unclear requirements. | ||
| tools: ["Read", "Glob", "Grep"] | ||
| model: opus | ||
| --- | ||
| # Planner Agent | ||
| # Planner | ||
| Specialized agent for breaking down complex tasks. | ||
| Read-only task planner for complex work. | ||
| ## When to Use | ||
| - Multi-file changes | ||
| - Architectural decisions | ||
| - Unclear requirements | ||
| - >10 tool calls expected | ||
| ## Trigger | ||
| ## Tools Allowed | ||
| - Read, Glob, Grep (exploration) | ||
| - NO Edit, Write, Bash (read-only) | ||
| Use when multi-file changes, architecture decisions, unclear requirements, or >10 tool calls expected. | ||
| ## Process | ||
| ## Workflow | ||
| 1. Understand the goal | ||
| 2. Explore relevant code | ||
| 2. Explore relevant code (read-only) | ||
| 3. Identify all files to change | ||
| 4. List dependencies/order | ||
| 4. List dependencies and ordering | ||
| 5. Estimate complexity | ||
| 6. Present plan for approval | ||
| ## Output Format | ||
| ## Output | ||
| ``` | ||
@@ -39,3 +34,2 @@ ## Plan: [Task Name] | ||
| 1. path/to/file.ts - [what changes] | ||
| 2. path/to/other.ts - [what changes] | ||
@@ -52,5 +46,6 @@ ### Approach | ||
| ## NEVER | ||
| - Make changes | ||
| - Skip approval step | ||
| - Assume requirements | ||
| ## Rules | ||
| - Never make changes. Read-only exploration. | ||
| - Never skip approval step. | ||
| - Never assume requirements. Ask when unclear. |
+14
-19
| --- | ||
| name: reviewer | ||
| description: Specialized agent for code review and quality checks | ||
| description: Code review specialist that checks for logic errors, security issues, and quality problems. Use before committing, for PR reviews, or after major changes. | ||
| tools: ["Read", "Glob", "Grep", "Bash"] | ||
| model: opus | ||
| --- | ||
| # Reviewer Agent | ||
| # Reviewer | ||
| Specialized agent for code review and quality checks. | ||
| Code review and quality checks. | ||
| ## When to Use | ||
| - Before committing | ||
| - PR reviews | ||
| - Security audits | ||
| - After major changes | ||
| ## Trigger | ||
| ## Tools Allowed | ||
| - Read, Glob, Grep (analysis) | ||
| - Bash (for lint, typecheck, test) | ||
| - NO Edit, Write (read-only) | ||
| Use before committing, for PR reviews, security audits, or after major changes. | ||
| ## Checklist | ||
| 1. **Logic** - Does it do what's intended? | ||
@@ -28,6 +21,7 @@ 2. **Edge Cases** - Null, empty, bounds? | ||
| 4. **Security** - Injection, auth, secrets? | ||
| 5. **Performance** - O(n²) loops, memory? | ||
| 5. **Performance** - O(n^2) loops, memory? | ||
| 6. **Tests** - Coverage adequate? | ||
| ## Output Format | ||
| ## Output | ||
| ``` | ||
@@ -52,5 +46,6 @@ ## Review: [Files/PR] | ||
| ## NEVER | ||
| - Auto-approve without review | ||
| - Skip security checks | ||
| - Make changes (suggest only) | ||
| ## Rules | ||
| - Never auto-approve without review. | ||
| - Never skip security checks. | ||
| - Suggest fixes, don't just flag problems. |
+35
-52
| --- | ||
| name: scout | ||
| description: Confidence-gated exploration agent that assesses readiness before implementation | ||
| description: Confidence-gated exploration that assesses readiness before implementation. Scores 0-100 across five dimensions and gives GO/HOLD verdict. | ||
| tools: ["Read", "Glob", "Grep", "Bash"] | ||
| model: opus | ||
| background: true | ||
| isolation: worktree | ||
| --- | ||
| # Scout Agent - Confidence-Gated Exploration | ||
| # Scout - Confidence-Gated Exploration | ||
| You are the Scout agent for pro-workflow. Your job is to assess whether there's enough context to implement a task confidently, and if not, gather what's missing. | ||
| Assess whether there's enough context to implement a task confidently. | ||
| ## How You Work | ||
| Runs in the background so you can continue working while it explores. | ||
| 1. **Receive a task description** from the user or planner | ||
| 2. **Explore the codebase** to understand the scope | ||
| 3. **Score your confidence** (0-100) on whether the task can be implemented correctly | ||
| 4. **If confidence >= 70**: Output a go-ahead with your findings | ||
| 5. **If confidence < 70**: Identify what's missing and gather more context, then re-score | ||
| ## Trigger | ||
| Use before starting implementation of unfamiliar or complex tasks. | ||
| ## Workflow | ||
| 1. Receive task description | ||
| 2. Explore the codebase to understand scope | ||
| 3. Score confidence (0-100) | ||
| 4. If >= 70: GO with findings | ||
| 5. If < 70: Identify what's missing, gather more context, re-score | ||
| ## Confidence Scoring | ||
| Rate each dimension (0-20 points each): | ||
| Rate each dimension (0-20 points): | ||
| - **Scope clarity**: Do you know exactly what files need to change? (0-20) | ||
| - **Pattern familiarity**: Does the codebase have similar patterns to follow? (0-20) | ||
| - **Dependency awareness**: Do you know what depends on the code being changed? (0-20) | ||
| - **Edge case coverage**: Can you identify the edge cases? (0-20) | ||
| - **Test strategy**: Do you know how to verify the changes work? (0-20) | ||
| - **Scope clarity** - Do you know exactly what files need to change? | ||
| - **Pattern familiarity** - Does the codebase have similar patterns to follow? | ||
| - **Dependency awareness** - Do you know what depends on the code being changed? | ||
| - **Edge case coverage** - Can you identify the edge cases? | ||
| - **Test strategy** - Do you know how to verify the changes work? | ||
| Total = sum of all dimensions | ||
| ## Output | ||
| ## Output Format | ||
| ``` | ||
| SCOUT REPORT | ||
| ============ | ||
| Task: [task description] | ||
| Task: [description] | ||
| Confidence: [score]/100 | ||
| Dimensions: | ||
| Scope clarity: [x]/20 - [brief reason] | ||
| Pattern familiarity: [x]/20 - [brief reason] | ||
| Dependency awareness: [x]/20 - [brief reason] | ||
| Edge case coverage: [x]/20 - [brief reason] | ||
| Test strategy: [x]/20 - [brief reason] | ||
| Scope clarity: [x]/20 | ||
| Pattern familiarity: [x]/20 | ||
| Dependency awareness: [x]/20 | ||
| Edge case coverage: [x]/20 | ||
| Test strategy: [x]/20 | ||
| Key files: | ||
| - [file] - [why it matters] | ||
| [IF confidence >= 70] | ||
| VERDICT: GO - Ready to implement | ||
| Implementation notes: | ||
| - [specific guidance for implementation] | ||
| [IF confidence < 70] | ||
| VERDICT: HOLD - Need more context | ||
| Missing context: | ||
| - [what needs investigation] | ||
| - [questions that need answers] | ||
| Gathering... | ||
| [then explore and re-score] | ||
| VERDICT: GO / HOLD | ||
| ``` | ||
| ## Learning Integration | ||
| Before scoring, check `~/.pro-workflow/data.db` for past learnings related to the task: | ||
| - Use Bash to run: `sqlite3 ~/.pro-workflow/data.db "SELECT category, rule, times_applied FROM learnings WHERE rule LIKE '%keyword%' ORDER BY times_applied DESC LIMIT 5"` | ||
| - If past corrections exist for similar work, reduce confidence by 10 per recurring pattern | ||
| - Surface relevant learnings in the report | ||
| ## Rules | ||
| - Never edit files. You are read-only + bash for queries | ||
| - Be honest about gaps. A false "GO" wastes more time than a "HOLD" | ||
| - Re-score after gathering context. If still < 70 after 2 rounds, escalate to user | ||
| - Keep reports concise. The planner/implementer will do the detailed work | ||
| - Never edit files. Read-only exploration. | ||
| - Be honest about gaps. A false GO wastes more time than a HOLD. | ||
| - Re-score after gathering context. If still < 70 after 2 rounds, escalate to user. | ||
| - Runs in isolated worktree to avoid interfering with main session. |
+79
-8
@@ -18,2 +18,3 @@ # /learn - Claude Code Best Practices & Learning Capture | ||
| - Don't compact mid-task. You lose working context. | ||
| - Plan mode now survives compaction (fixed in 2.1.49). | ||
| - **Docs:** https://code.claude.com/docs/common-workflows | ||
@@ -34,2 +35,3 @@ - **Pattern:** Context Discipline (Pattern 7) | ||
| - **Plan** — Research first, then propose plan (complex tasks) | ||
| - **Simple** — Bash + Edit tools only (lightweight, no extra overhead) | ||
| - Use Plan mode when: >3 files, architecture decisions, multiple approaches, unclear requirements. | ||
@@ -43,8 +45,9 @@ - Toggle with `Shift+Tab`. | ||
| |----------|--------| | ||
| | `Shift+Tab` | Cycle modes (Normal/Auto-Accept/Plan/Delegate) | | ||
| | `Shift+Tab` | Cycle modes (Normal/Auto-Accept/Plan) | | ||
| | `Ctrl+L` | Clear screen | | ||
| | `Ctrl+C` | Cancel generation | | ||
| | `Ctrl+B` | Run task in background | | ||
| | `Ctrl+F` | Kill all background agents (two-press confirmation) | | ||
| | `Ctrl+T` | Toggle task list (agent teams) | | ||
| | `Shift+Up/Down` | Navigate teammates (agent teams) | | ||
| | `Shift+Down` | Navigate teammates (wraps around) | | ||
| | `Up/Down` | Prompt history | | ||
@@ -55,2 +58,3 @@ | `/compact` | Compact context | | ||
| | `/agents` | Manage subagents | | ||
| | `/model` | Switch models | | ||
| | `/commit` | Smart commit with quality gates | | ||
@@ -60,2 +64,9 @@ | `/insights` | Session analytics and patterns | | ||
| ### Worktrees | ||
| Native worktree support (2.1.49+): | ||
| ```bash | ||
| claude --worktree # or claude -w | ||
| ``` | ||
| Creates an isolated git worktree automatically. Subagents support `isolation: worktree` in frontmatter. | ||
| ### Prompting | ||
@@ -89,4 +100,7 @@ Good prompts have four parts: | ||
| - Press `Ctrl+B` to send tasks to background. | ||
| - Press `Ctrl+F` to kill all background agents (two-press confirmation). | ||
| - ESC cancels the main thread only; background agents keep running. | ||
| - Create custom subagents in `.claude/agents/` (project) or `~/.claude/agents/` (user). | ||
| - Subagents support: custom tools, permission modes, persistent memory, hooks, and skill preloading. | ||
| - Subagents support: custom tools, permission modes, persistent memory, hooks, skill preloading, and **worktree isolation**. | ||
| - Agent definitions support `background: true` to always run as background tasks. | ||
| - Built-in subagents: Explore (fast read-only), Plan (research), general-purpose (multi-step). | ||
@@ -103,4 +117,4 @@ - Use `/agents` to manage subagents interactively. | ||
| - Shared task list with self-coordination and dependency management. | ||
| - Display modes: in-process (Shift+Up/Down to navigate) or split panes (tmux/iTerm2). | ||
| - Delegate mode (Shift+Tab): restricts lead to coordination only. | ||
| - Display modes: in-process (`Shift+Down` to navigate, wraps around) or split panes (tmux/iTerm2). | ||
| - Delegate mode (`Shift+Tab`): restricts lead to coordination only. | ||
| - Best for: parallel code review, competing hypotheses debugging, cross-layer changes, research. | ||
@@ -114,3 +128,9 @@ - Avoid for: sequential tasks, same-file edits, simple operations. | ||
| - No configuration needed - works out of the box with Opus 4.6. | ||
| - Extended thinking is built-in — no need to toggle a separate mode. | ||
| ### Model Selection | ||
| - **Sonnet 4.5 with 1M context has been retired** — switch to Sonnet 4.6 (now has 1M context) via `/model`. | ||
| - Opus 4.6 has adaptive thinking built-in. | ||
| - Use Haiku 4.5 for quick, read-only exploration subagents. | ||
| ### Context Compaction | ||
@@ -122,10 +142,18 @@ Keeps long-running agents from hitting context limits. | ||
| - Use PreCompact hooks to save state before compaction. | ||
| - Plan mode now survives compaction (2.1.49 fix). | ||
| ### Hooks | ||
| Hooks run scripts on events to automate quality enforcement. | ||
| - Types: PreToolUse, PostToolUse, SessionStart, SessionEnd, Stop, UserPromptSubmit, PreCompact, SubagentStart, SubagentStop | ||
| - Pro-Workflow ships hooks for edit tracking, quality gates, and learning capture. | ||
| - Types: PreToolUse, PostToolUse, SessionStart, SessionEnd, Stop, UserPromptSubmit, PreCompact, SubagentStart, SubagentStop, **ConfigChange**, Notification | ||
| - **ConfigChange** (2.1.49+): fires when settings files change mid-session — useful for security auditing. | ||
| - **Stop hook** now receives `last_assistant_message` for context-aware reminders. | ||
| - Pro-Workflow ships hooks for edit tracking, quality gates, config monitoring, and learning capture. | ||
| - Subagent hooks: define in frontmatter or settings.json for lifecycle events. | ||
| - **Docs:** https://code.claude.com/docs/hooks | ||
| ### Plugins | ||
| - Plugins can ship `settings.json` for default permission configuration (2.1.49+). | ||
| - Pro-Workflow ships default permissions for quality gate commands (lint, test, typecheck). | ||
| - **Docs:** https://code.claude.com/docs/plugins | ||
| ### Security | ||
@@ -142,2 +170,3 @@ - Review permission requests carefully. | ||
| - Each MCP adds context overhead. | ||
| - MCP auth failures are now cached to avoid repeated connection attempts. | ||
| - **Docs:** https://code.claude.com/docs/mcp | ||
@@ -158,4 +187,8 @@ | ||
| Capture a lesson from this session: | ||
| When the user runs `/learn save`, capture a lesson from this session. | ||
| ### Step 1: Identify the learning | ||
| Ask the user what they learned, or extract it from the conversation. Format it as: | ||
| ``` | ||
@@ -180,2 +213,36 @@ Category: <category> | ||
| ### Step 2: Save to database | ||
| After the user confirms the learning, write it to the database: | ||
| ```bash | ||
| sqlite3 ~/.pro-workflow/data.db "INSERT INTO learnings (project, category, rule, mistake, correction) VALUES ('<project>', '<category>', '<rule>', '<mistake>', '<correction>');" | ||
| ``` | ||
| Replace `<project>` with the current project name (from `basename $PWD`), or `NULL` if unknown. Escape single quotes in values by doubling them (`''`). | ||
| Alternatively, use the store API: | ||
| ```bash | ||
| node -e "const p = require('path'); const {createStore} = require(p.join(process.env.HOME, '.claude/plugins/marketplaces/pro-workflow/dist/db/store.js')); const s = createStore(); const l = s.addLearning({project: '<project>', category: '<category>', rule: '<rule>', mistake: '<mistake>', correction: '<correction>'}); console.log('Saved as learning #' + l.id); s.close();" | ||
| ``` | ||
| ### Step 3: Confirm to user | ||
| After saving, output a confirmation with the learning ID: | ||
| ``` | ||
| Saved as learning #<id>. Use /search <keyword> to find this later. | ||
| ``` | ||
| ### Auto-capture via [LEARN] tags | ||
| You can also emit `[LEARN]` blocks in your response, which the Stop hook will auto-capture: | ||
| ``` | ||
| [LEARN] Category: Rule text here | ||
| Mistake: What went wrong | ||
| Correction: How it was fixed | ||
| ``` | ||
| ### Example | ||
@@ -188,3 +255,7 @@ | ||
| Correction: Enter plan mode first, get approval, then execute | ||
| ``` | ||
| After user confirms → run the sqlite3 INSERT → output: | ||
| ``` | ||
| Saved as learning #42. Use /search plan to find this later. | ||
@@ -191,0 +262,0 @@ ``` |
+39
-15
@@ -5,2 +5,24 @@ # /parallel - Worktree Setup Guide | ||
| ## Native Worktree Mode (Claude Code 2.1.49+) | ||
| Claude Code now has built-in worktree support: | ||
| ```bash | ||
| claude --worktree | ||
| claude -w | ||
| ``` | ||
| This creates an isolated git worktree automatically and runs Claude inside it. No manual setup needed. | ||
| ### Subagent Worktree Isolation | ||
| Subagents can also run in isolated worktrees: | ||
| ```yaml | ||
| # In .claude/agents/my-agent.md frontmatter | ||
| isolation: worktree | ||
| ``` | ||
| This gives each subagent its own working copy, preventing file conflicts. | ||
| ## Current State | ||
@@ -12,12 +34,9 @@ | ||
| ## Create Worktree | ||
| ## Manual Worktree Setup | ||
| For cases where you want more control: | ||
| ```bash | ||
| # For a new feature | ||
| git worktree add ../[project]-feat [branch-name] | ||
| # For a bugfix | ||
| git worktree add ../[project]-fix [branch-name] | ||
| # For exploration | ||
| git worktree add ../[project]-exp -b experiment | ||
@@ -29,5 +48,5 @@ ``` | ||
| ``` | ||
| Terminal 1: ~/project → Main work | ||
| Terminal 2: ~/project-feat → Feature development | ||
| Terminal 3: ~/project-fix → Bug fixes | ||
| Terminal 1: ~/project → Main work (or `claude`) | ||
| Terminal 2: ~/project-feat → claude --worktree (auto-isolated) | ||
| Terminal 3: ~/project-fix → claude -w (shorthand) | ||
| ``` | ||
@@ -39,4 +58,5 @@ | ||
| | Scenario | Action | | ||
| |----------|--------| | ||
| | Scenario | Recommended Approach | | ||
| |----------|---------------------| | ||
| | Quick parallel task | `claude -w` (auto worktree) | | ||
| | Tests running | Start feature in worktree | | ||
@@ -46,10 +66,14 @@ | Long build | Debug in parallel | | ||
| | Review + new work | Reviewer in one, dev in other | | ||
| | Background exploration | Subagent with `isolation: worktree` | | ||
| ## Managing Background Agents | ||
| - `Ctrl+F` — Kill all background agents (two-press confirmation) | ||
| - `Ctrl+B` — Send current task to background | ||
| - Background agents continue running when you press ESC | ||
| ## Cleanup | ||
| ```bash | ||
| # Remove worktree when done | ||
| git worktree remove ../[project]-feat | ||
| # Clean stale references | ||
| git worktree prune | ||
@@ -60,2 +84,2 @@ ``` | ||
| **Tip:** "Like having a dev team you can clone" - zero dead time. | ||
| **Tip:** `claude -w` is the fastest way to parallelize. Like having a dev team you can clone. |
+6
-4
@@ -37,10 +37,12 @@ { | ||
| "suggest_worktrees": true, | ||
| "worktree_prefix": "../" | ||
| "worktree_prefix": "../", | ||
| "native_worktree": true | ||
| }, | ||
| "model_preferences": { | ||
| "quick_fixes": "sonnet", | ||
| "quick_fixes": "haiku", | ||
| "features": "sonnet", | ||
| "refactors": "opus", | ||
| "architecture": "opus-thinking", | ||
| "debugging": "opus-thinking" | ||
| "architecture": "opus", | ||
| "debugging": "opus" | ||
| } | ||
| } |
+23
-1
@@ -67,3 +67,13 @@ { | ||
| ], | ||
| "description": "Periodic wrap-up reminder and learning prompt" | ||
| "description": "Context-aware wrap-up reminders using last_assistant_message" | ||
| }, | ||
| { | ||
| "matcher": "*", | ||
| "hooks": [ | ||
| { | ||
| "type": "command", | ||
| "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/learn-capture.js\"" | ||
| } | ||
| ], | ||
| "description": "Auto-capture [LEARN] blocks from responses into database" | ||
| } | ||
@@ -129,2 +139,14 @@ ], | ||
| ], | ||
| "ConfigChange": [ | ||
| { | ||
| "matcher": "*", | ||
| "hooks": [ | ||
| { | ||
| "type": "command", | ||
| "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/config-watcher.js\"" | ||
| } | ||
| ], | ||
| "description": "Detect when quality gates or hooks are modified mid-session" | ||
| } | ||
| ], | ||
| "Notification": [ | ||
@@ -131,0 +153,0 @@ { |
+2
-2
| { | ||
| "name": "pro-workflow", | ||
| "version": "1.2.0", | ||
| "version": "1.3.0", | ||
| "description": "Battle-tested Claude Code workflows with agent teams, smart commit, insights, and searchable learnings", | ||
@@ -46,3 +46,3 @@ "main": "dist/index.js", | ||
| "@types/better-sqlite3": "^7.6.12", | ||
| "@types/node": "^20.17.14", | ||
| "@types/node": "^25.2.2", | ||
| "typescript": "^5.7.3" | ||
@@ -49,0 +49,0 @@ }, |
+90
-68
@@ -6,21 +6,4 @@ # Pro Workflow | ||
| Battle-tested Claude Code workflows from power users. Self-correcting memory, parallel worktrees, wrap-up rituals, and the 80/20 AI coding ratio. | ||
| Battle-tested AI coding workflows from power users. Self-correcting memory, parallel worktrees, wrap-up rituals, and the 80/20 AI coding ratio. Works with **Claude Code** and **Cursor**. | ||
| **v1.2.0: Scout agent, /replay, /handoff, drift detection, adaptive quality gates, and correction heatmap!** | ||
| **If this helps your workflow, please give it a star!** | ||
| ## What's New in v1.2.0 | ||
| - **Scout Agent**: Confidence-gated exploration — scores readiness (0-100) before implementation, auto-gathers missing context | ||
| - **`/replay`**: Surface relevant past learnings before starting a task — your SQLite-powered coding muscle memory | ||
| - **`/handoff`**: Generate structured session handoff documents for seamless continuation in the next session | ||
| - **Drift Detection**: Hook that tracks your original intent and warns when you've strayed from the goal | ||
| - **Adaptive Quality Gates**: Gates adjust based on your correction history — high correction rate = tighter gates, low rate = relaxed gates | ||
| - **Correction Heatmap**: `/insights heatmap` shows which categories and projects get corrected most, with hot/cold learning analysis | ||
| ### Previous: v1.1.0 | ||
| - Smart `/commit` with quality gates, `/insights` analytics, agent teams, persistent SQLite storage with FTS5 | ||
| ## The Core Idea | ||
@@ -37,7 +20,7 @@ | ||
| | **Self-Correction Loop** | Claude learns from your corrections automatically | | ||
| | **Parallel Worktrees** | Zero dead time - work while Claude thinks | | ||
| | **Parallel Worktrees** | Zero dead time - native `claude -w` worktrees | | ||
| | **Wrap-Up Ritual** | End sessions with intention, capture learnings | | ||
| | **Split Memory** | Modular CLAUDE.md for complex projects | | ||
| | **80/20 Review** | Batch reviews at checkpoints | | ||
| | **Model Selection** | Opus+Thinking for one-shot accuracy | | ||
| | **Model Selection** | Opus 4.6 adaptive thinking, Sonnet 4.6 (1M context) | | ||
| | **Context Discipline** | Manage your 200k token budget | | ||
@@ -48,5 +31,13 @@ | **Learning Log** | Auto-document insights | | ||
| ### One-Click Plugin Install (Recommended) | ||
| ### Cursor (Recommended) | ||
| ```bash | ||
| /add-plugin pro-workflow | ||
| ``` | ||
| The plugin includes 9 skills, 3 agents, and 6 rules that load automatically. | ||
| ### Claude Code — One-Click Plugin Install | ||
| ```bash | ||
| # Add marketplace | ||
@@ -66,3 +57,3 @@ /plugin marketplace add rohitg00/pro-workflow | ||
| ### Build with SQLite Support | ||
| ### Claude Code — Build with SQLite Support | ||
@@ -110,4 +101,29 @@ After installation, build the TypeScript for persistent storage: | ||
| ## Commands | ||
| ## Skills (Cursor) | ||
| | Skill | Description | | ||
| |:------|:------------| | ||
| | `pro-workflow` | Core 8 workflow patterns for AI-assisted coding | | ||
| | `smart-commit` | Quality gates, staged review, and conventional commits | | ||
| | `wrap-up` | End-of-session ritual with change audit and learning capture | | ||
| | `learn-rule` | Capture corrections as persistent learning rules | | ||
| | `parallel-worktrees` | Set up git worktrees for zero dead time | | ||
| | `replay-learnings` | Surface past learnings relevant to the current task | | ||
| | `session-handoff` | Generate handoff documents for session continuity | | ||
| | `insights` | Session analytics, correction trends, and productivity metrics | | ||
| | `deslop` | Remove AI-generated code slop and clean up style | | ||
| ## Rules (Cursor) | ||
| | Rule | Applies To | Description | | ||
| |:-----|:-----------|:------------| | ||
| | `quality-gates` | Always | Lint, typecheck, and test before commits | | ||
| | `atomic-commits` | Always | Conventional format, feature branches, specific staging | | ||
| | `context-discipline` | Always | Read before edit, plan before multi-file changes | | ||
| | `self-correction` | Always | Capture mistakes as compounding learnings | | ||
| | `no-debug-statements` | `*.{ts,tsx,js,jsx,py,go,rs}` | Remove console.log, debugger, print before committing | | ||
| | `communication-style` | Always | Concise, action-oriented, no over-engineering | | ||
| ## Commands (Claude Code) | ||
| After plugin install, commands are namespaced: | ||
@@ -170,6 +186,7 @@ | ||
| | PostToolUse | After tests | Suggest [LEARN] from failures | | ||
| | UserPromptSubmit | Each prompt |Drift detection — warns when straying from original intent | | ||
| | UserPromptSubmit | Each prompt | Drift detection — warns when straying from original intent | | ||
| | SessionStart | New session | Load learnings from database | | ||
| | Stop | Each response | Periodic wrap-up reminders | | ||
| | Stop | Each response | Context-aware reminders using `last_assistant_message` | | ||
| | SessionEnd | Session close | Save session stats to database | | ||
| | ConfigChange | Settings modified | Detect when quality gates or hooks are changed mid-session | | ||
@@ -198,3 +215,3 @@ ### Install Hooks | ||
| | reviewer | Code review, security audit | | ||
| | scout |Confidence-gated exploration before implementation | | ||
| | scout | Background confidence-gated exploration with worktree isolation | | ||
@@ -213,3 +230,3 @@ ### Agent Teams (Experimental) | ||
| - Shared task list with dependency management | ||
| - Display modes: in-process (`Shift+Up/Down`) or split panes (tmux/iTerm2) | ||
| - Display modes: in-process (`Shift+Down` to navigate, wraps around) or split panes (tmux/iTerm2) | ||
| - Delegate mode (`Shift+Tab`): lead orchestrates only | ||
@@ -222,49 +239,54 @@ - Docs: https://code.claude.com/docs/agent-teams | ||
| pro-workflow/ | ||
| ├── .claude-plugin/ | ||
| │ ├── plugin.json # Plugin manifest | ||
| │ ├── marketplace.json # Marketplace config | ||
| ├── .claude-plugin/ # Claude Code plugin | ||
| │ ├── plugin.json | ||
| │ ├── marketplace.json | ||
| │ ├── settings.json # Default permissions for quality gates | ||
| │ └── README.md | ||
| ├── src/ # TypeScript source | ||
| │ ├── db/ | ||
| │ │ ├── index.ts # Database initialization | ||
| │ │ ├── store.ts # Stateless store factory | ||
| │ │ └── schema.sql # SQLite schema with FTS5 | ||
| │ ├── search/ | ||
| │ │ └── fts.ts # BM25 search helpers | ||
| │ └── index.ts | ||
| ├── dist/ # Compiled JavaScript | ||
| ├── skills/ | ||
| │ └── pro-workflow/ | ||
| │ └── SKILL.md # Main skill | ||
| ├── agents/ | ||
| │ ├── planner.md # Planner agent | ||
| │ ├── reviewer.md # Reviewer agent | ||
| │ └── scout.md # Confidence-gated scout agent | ||
| ├── commands/ | ||
| ├── .cursor-plugin/ # Cursor plugin | ||
| │ └── plugin.json | ||
| ├── skills/ # Shared skills (Cursor + Claude Code) | ||
| │ ├── pro-workflow/SKILL.md | ||
| │ ├── smart-commit/SKILL.md | ||
| │ ├── wrap-up/SKILL.md | ||
| │ ├── learn-rule/SKILL.md | ||
| │ ├── parallel-worktrees/SKILL.md | ||
| │ ├── replay-learnings/SKILL.md | ||
| │ ├── session-handoff/SKILL.md | ||
| │ ├── insights/SKILL.md | ||
| │ └── deslop/SKILL.md | ||
| ├── agents/ # Shared agents (Cursor + Claude Code) | ||
| │ ├── planner.md | ||
| │ ├── reviewer.md | ||
| │ └── scout.md | ||
| ├── rules/ # Rules | ||
| │ ├── core-rules.md # Claude Code rules | ||
| │ ├── quality-gates.mdc # Cursor rules | ||
| │ ├── atomic-commits.mdc | ||
| │ ├── context-discipline.mdc | ||
| │ ├── self-correction.mdc | ||
| │ ├── no-debug-statements.mdc | ||
| │ └── communication-style.mdc | ||
| ├── commands/ # Claude Code commands | ||
| │ ├── wrap-up.md | ||
| │ ├── learn-rule.md | ||
| │ ├── parallel.md | ||
| │ ├── learn.md | ||
| │ ├── search.md | ||
| │ ├── list.md | ||
| │ ├── commit.md | ||
| │ ├── insights.md | ||
| │ ├── replay.md # Surface past learnings | ||
| │ └── handoff.md # Session handoff document | ||
| ├── hooks/ | ||
| │ └── hooks.json # Hooks file | ||
| ├── scripts/ # Hook scripts | ||
| ├── contexts/ | ||
| │ ├── dev.md # Dev context | ||
| │ ├── review.md # Review context | ||
| │ └── research.md # Research context | ||
| ├── references/ | ||
| │ └── claude-code-resources.md # Claude code resources reference file | ||
| ├── rules/ | ||
| │ └── core-rules.md # Core rules file | ||
| ├── templates/ | ||
| │ └── split-claude-md/ # Split claude md template | ||
| │ ├── replay.md | ||
| │ ├── handoff.md | ||
| │ └── ... | ||
| ├── hooks/ # Claude Code hooks | ||
| │ └── hooks.json | ||
| ├── scripts/ # Hook scripts (includes config-watcher.js) | ||
| ├── contexts/ # Context modes | ||
| │ ├── dev.md | ||
| │ ├── review.md | ||
| │ └── research.md | ||
| ├── src/ # TypeScript source (SQLite) | ||
| │ ├── db/ | ||
| │ └── search/ | ||
| ├── assets/ | ||
| │ └── logo.svg # Plugin logo | ||
| ├── package.json | ||
| ├── tsconfig.json # TypeScript configuration file | ||
| └── README.md # README file | ||
| ├── tsconfig.json | ||
| └── README.md | ||
| ``` | ||
@@ -271,0 +293,0 @@ |
+76
-35
@@ -7,3 +7,3 @@ #!/usr/bin/env node | ||
| * Periodic reminders for wrap-up and learning capture. | ||
| * Based on Twitter thread: "DevOps agent with /wrap-up command" | ||
| * Uses last_assistant_message (2.1.49+) for smarter context-aware reminders. | ||
| */ | ||
@@ -29,46 +29,87 @@ | ||
| function detectCompletionSignals(message) { | ||
| if (!message) return false; | ||
| const signals = [ | ||
| /all (changes|files|tests|updates) (are |have been )?(committed|pushed|complete|done|pass)/i, | ||
| /successfully (created|merged|deployed|published|released)/i, | ||
| /PR (created|merged|opened)/i, | ||
| /implementation is complete/i, | ||
| /everything (looks good|is working|passes)/i, | ||
| /all \d+ tests pass/i | ||
| ]; | ||
| return signals.some(p => p.test(message)); | ||
| } | ||
| function detectLargeChange(message) { | ||
| if (!message) return false; | ||
| const patterns = [ | ||
| /(\d+) files? (changed|modified|updated|created)/i, | ||
| /across \d+ files/i, | ||
| /refactored? \d+ (files?|modules?|components?)/i | ||
| ]; | ||
| return patterns.some(p => p.test(message)); | ||
| } | ||
| async function main() { | ||
| const tempDir = getTempDir(); | ||
| ensureDir(tempDir); | ||
| let data = ''; | ||
| const sessionId = process.env.CLAUDE_SESSION_ID || process.ppid || 'default'; | ||
| const responseCountFile = path.join(tempDir, `response-count-${sessionId}`); | ||
| const lastReminderFile = path.join(tempDir, `last-reminder-${sessionId}`); | ||
| process.stdin.on('data', chunk => { | ||
| data += chunk; | ||
| }); | ||
| let count = 1; | ||
| process.stdin.on('end', () => { | ||
| try { | ||
| const input = JSON.parse(data); | ||
| const lastMessage = (input.last_assistant_message || '').slice(-2000); | ||
| if (fs.existsSync(responseCountFile)) { | ||
| count = parseInt(fs.readFileSync(responseCountFile, 'utf8').trim(), 10) + 1; | ||
| } | ||
| const tempDir = getTempDir(); | ||
| ensureDir(tempDir); | ||
| fs.writeFileSync(responseCountFile, String(count)); | ||
| const sessionId = input.session_id || process.env.CLAUDE_SESSION_ID || process.ppid || 'default'; | ||
| const responseCountFile = path.join(tempDir, `response-count-${sessionId}`); | ||
| // Check if we should show a reminder (every 20 responses) | ||
| const shouldRemind = count % 20 === 0; | ||
| let count = 1; | ||
| // Alternate between different reminders | ||
| if (shouldRemind) { | ||
| const reminderType = Math.floor(count / 20) % 3; | ||
| if (fs.existsSync(responseCountFile)) { | ||
| count = parseInt(fs.readFileSync(responseCountFile, 'utf8').trim(), 10) + 1; | ||
| } | ||
| switch (reminderType) { | ||
| case 0: | ||
| log('[ProWorkflow] Consider /wrap-up if ending session soon'); | ||
| break; | ||
| case 1: | ||
| log('[ProWorkflow] Any corrections to capture? Use /learn-rule'); | ||
| break; | ||
| case 2: | ||
| log('[ProWorkflow] Good checkpoint for /compact if context is heavy'); | ||
| break; | ||
| } | ||
| } | ||
| fs.writeFileSync(responseCountFile, String(count)); | ||
| // At 50 responses, stronger reminder | ||
| if (count === 50) { | ||
| log('[ProWorkflow] Long session - strongly consider:'); | ||
| log('[ProWorkflow] /wrap-up - capture learnings'); | ||
| log('[ProWorkflow] /compact - preserve context'); | ||
| } | ||
| if (lastMessage && detectCompletionSignals(lastMessage)) { | ||
| log('[ProWorkflow] Task looks complete — consider /wrap-up to capture learnings'); | ||
| } else if (lastMessage && detectLargeChange(lastMessage)) { | ||
| log('[ProWorkflow] Large change detected — good checkpoint for review'); | ||
| } else { | ||
| const shouldRemind = count % 20 === 0; | ||
| process.exit(0); | ||
| if (shouldRemind) { | ||
| const reminderType = Math.floor(count / 20) % 3; | ||
| switch (reminderType) { | ||
| case 0: | ||
| log('[ProWorkflow] Consider /wrap-up if ending session soon'); | ||
| break; | ||
| case 1: | ||
| log('[ProWorkflow] Any corrections to capture? Use /learn-rule'); | ||
| break; | ||
| case 2: | ||
| log('[ProWorkflow] Good checkpoint for /compact if context is heavy'); | ||
| break; | ||
| } | ||
| } | ||
| } | ||
| if (count === 50) { | ||
| log('[ProWorkflow] Long session - strongly consider:'); | ||
| log('[ProWorkflow] /wrap-up - capture learnings'); | ||
| log('[ProWorkflow] /compact - preserve context'); | ||
| } | ||
| console.log(data); | ||
| } catch (err) { | ||
| console.error('[ProWorkflow] session-check error:', err.message); | ||
| console.log(data || '{}'); | ||
| } | ||
| }); | ||
| } | ||
@@ -75,0 +116,0 @@ |
| --- | ||
| name: pro-workflow | ||
| description: Battle-tested Claude Code workflows from power users. Self-correcting memory, parallel worktrees, wrap-up rituals, and the 80/20 AI coding ratio. Distilled from real production use. | ||
| tools: Read, Glob, Grep, Bash, Edit, Write | ||
| description: Battle-tested AI coding workflows from power users. Self-correcting memory, parallel worktrees, wrap-up rituals, and the 80/20 AI coding ratio. Works with Claude Code, Cursor, and other agents. | ||
| --- | ||
@@ -9,4 +8,6 @@ | ||
| Real-world Claude Code patterns from power users who ship production code daily. Not theory - workflows that compound over time. | ||
| Real-world AI coding patterns from power users who ship production code daily. Not theory - workflows that compound over time. | ||
| **Works with:** Claude Code, Cursor, and other AI coding agents. Sections marked *(Claude Code)* use features specific to Claude Code — Cursor users can skip those or use the noted alternatives. | ||
| ## The Core Insight | ||
@@ -71,12 +72,20 @@ | ||
| **Claude Code:** | ||
| ```bash | ||
| # Create worktrees for parallel work | ||
| claude --worktree # or claude -w (auto-creates isolated worktree) | ||
| ``` | ||
| **Cursor / Any editor:** | ||
| ```bash | ||
| git worktree add ../project-feat feature-branch | ||
| git worktree add ../project-fix bugfix-branch | ||
| # Each gets its own Claude session | ||
| # Terminal 1: cd ~/project && claude | ||
| # Terminal 2: cd ~/project-feat && claude | ||
| ``` | ||
| ### Background Agent Management *(Claude Code)* | ||
| - `Ctrl+F` — Kill all background agents (two-press confirmation) | ||
| - `Ctrl+B` — Send task to background | ||
| - Subagents support `isolation: worktree` in agent frontmatter | ||
| ### When to Parallelize | ||
@@ -94,3 +103,4 @@ | ||
| ## Parallel Work | ||
| When blocked on long operations, suggest starting a parallel session in a worktree. | ||
| When blocked on long operations, use `claude -w` for instant parallel sessions. | ||
| Subagents with `isolation: worktree` get their own safe working copy. | ||
| ``` | ||
@@ -193,15 +203,14 @@ | ||
| **Opus 4.6 with adaptive thinking** calibrates reasoning depth automatically. | ||
| **Opus 4.6 and Sonnet 4.6** both support adaptive thinking and 1M-token context. The 1M context is available as a beta option (via the `context-1m-2025-08-07` beta header); the default context window remains 200K. Sonnet 4.5 (200K context) has been retired from the Max plan in favor of Sonnet 4.6. | ||
| | Task | Model | | ||
| |------|-------| | ||
| | Quick fixes | Haiku 4.5 | | ||
| | Features | Sonnet 4.5 | | ||
| | Refactors | Opus 4.6 | | ||
| | Architecture | Opus 4.6 + Extended Thinking | | ||
| | Hard bugs | Opus 4.6 + Extended Thinking | | ||
| | Quick fixes, exploration | Haiku 4.5 | | ||
| | Features, balanced work | Sonnet 4.6 | | ||
| | Refactors, architecture | Opus 4.6 | | ||
| | Hard bugs, multi-system | Opus 4.6 | | ||
| ### Adaptive Thinking | ||
| Opus 4.6 automatically calibrates reasoning depth per task - lightweight for simple operations, deep analysis for complex problems. No configuration needed. | ||
| Opus 4.6 and Sonnet 4.6 automatically calibrate reasoning depth per task — lightweight for simple operations, deep analysis for complex problems. No configuration needed. Extended thinking is built-in. | ||
@@ -212,4 +221,4 @@ ### Add to CLAUDE.md | ||
| ## Model Hints | ||
| Escalate to Opus+Thinking when: first attempt failed, multi-system coordination, non-obvious bugs. | ||
| Use subagents with Haiku for fast read-only exploration, Sonnet for balanced work. | ||
| Opus 4.6 and Sonnet 4.6 auto-calibrate reasoning depth — no need to toggle thinking mode. | ||
| Use subagents with Haiku for fast read-only exploration, Sonnet 4.6 for balanced work. | ||
| ``` | ||
@@ -332,5 +341,5 @@ | ||
| ## Hooks | ||
| ## Hooks *(Claude Code)* | ||
| Pro-workflow includes automated hooks to enforce the patterns. | ||
| Pro-workflow includes automated hooks to enforce the patterns. Cursor users get equivalent enforcement through `.mdc` rules in the `rules/` directory. | ||
@@ -357,4 +366,5 @@ ### PreToolUse Hooks | ||
| | SessionStart | Load LEARNED patterns, show worktree count | | ||
| | Stop | Periodic wrap-up/compact reminders | | ||
| | Stop | Context-aware reminders using `last_assistant_message` | | ||
| | SessionEnd | Check uncommitted changes, prompt for learnings | | ||
| | ConfigChange | Detect when quality gates or hooks are modified mid-session | | ||
@@ -414,3 +424,3 @@ ### Install Hooks | ||
| ### Custom Subagents | ||
| ### Custom Subagents *(Claude Code)* | ||
@@ -423,3 +433,3 @@ Create project-specific subagents in `.claude/agents/` or user-wide in `~/.claude/agents/`: | ||
| ### Agent Teams (Experimental) | ||
| ### Agent Teams *(Claude Code, Experimental)* | ||
@@ -431,3 +441,3 @@ Coordinate multiple Claude Code sessions as a team: | ||
| - Shared task list with dependency management | ||
| - Display: in-process (Shift+Up/Down) or split panes (tmux/iTerm2) | ||
| - Display: in-process (`Shift+Down` to navigate, wraps around) or split panes (tmux/iTerm2) | ||
| - Delegate mode (Shift+Tab): lead coordinates only, no code edits | ||
@@ -439,3 +449,3 @@ - Best for: parallel reviews, competing hypotheses, cross-layer changes | ||
| ## MCP Config | ||
| ## MCP Config *(Claude Code)* | ||
@@ -453,15 +463,17 @@ Keep <10 MCPs enabled, <80 tools total. | ||
| ## Commands | ||
| ## Commands *(Claude Code)* | ||
| | Command | Purpose | | ||
| |---------|---------| | ||
| | `/wrap-up` | End-of-session ritual | | ||
| | `/learn-rule` | Extract correction to memory | | ||
| | `/parallel` | Worktree setup guide | | ||
| | `/learn` | Claude Code best practices & save learnings | | ||
| | `/search` | Search learnings by keyword | | ||
| | `/list` | List all stored learnings | | ||
| | `/commit` | Smart commit with quality gates and code review | | ||
| | `/insights` | Session analytics, learning patterns, correction trends | | ||
| These slash commands are available when using pro-workflow as a Claude Code plugin. Cursor users get the same functionality through the **skills** listed above (wrap-up, smart-commit, parallel-worktrees, etc.). | ||
| | Command | Purpose | Cursor Equivalent | | ||
| |---------|---------|-------------------| | ||
| | `/wrap-up` | End-of-session ritual | `wrap-up` skill | | ||
| | `/learn-rule` | Extract correction to memory | `learn-rule` skill | | ||
| | `/parallel` | Worktree setup guide | `parallel-worktrees` skill | | ||
| | `/learn` | Best practices & save learnings | — | | ||
| | `/search` | Search learnings by keyword | — | | ||
| | `/list` | List all stored learnings | — | | ||
| | `/commit` | Smart commit with quality gates | `smart-commit` skill | | ||
| | `/insights` | Session analytics and patterns | `insights` skill | | ||
| --- | ||
@@ -474,6 +486,6 @@ | ||
| 3. **Zero dead time** - Parallel sessions | ||
| 4. **Memory is precious** - Yours and Claude's | ||
| 4. **Memory is precious** - Yours and the AI's | ||
| --- | ||
| *From Claude Code power users and real production use.* | ||
| *From AI coding power users and real production use.* |
Shell access
Supply chain riskThis module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.
Found 1 instance in 1 package
Dynamic require
Supply chain riskDynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.
Found 1 instance in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 2 instances in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
Shell access
Supply chain riskThis module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.
Found 1 instance in 1 package
Dynamic require
Supply chain riskDynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.
Found 1 instance in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
157938
23.31%68
30.77%1540
14.07%340
6.92%25
19.05%