{"items":[{"id":"cmugwi2qi01qqqu06dj5owtke","slug":"rohitg00-pro-workflow-skill-optimizer","name":"skill-optimizer","description":"SkillOpt-flavored offline training loop for any SKILL.md. Treats accumulated learn-rule corrections as training trajectories, proposes bounded patches via an optimizer LLM, gates each candidate against a held-out validation set built from the user's own past corrections, and ships only candidates that demonstrably improve the score. Inspired by Microsoft SkillOpt's ReflACT pipeline (rollout → reflect → aggregate → select → update → evaluate) adapted to pro-workflow's SQLite store. Use when a skill has accumulated 8+ learn-rule rows and the user wants the skill itself to get better, not just longer.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"skill-optimizer","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"SkillOpt-flavored offline training loop for any SKILL.md. Treats accumulated learn-rule corrections as training trajectories, proposes bounded patches via an optimizer LLM, gates each candidate against a held-out validation set built from the user's own past corrections, and ships only candidates that demonstrably improve the score. Inspired by Microsoft SkillOpt's ReflACT pipeline (rollout → reflect → aggregate → select → update → evaluate) adapted to pro-workflow's SQLite store. Use when a skill has accumulated 8+ learn-rule rows and the user wants the skill itself to get better, not just longer.","permissions":[],"systemPrompt":"# Skill Optimizer\n\nTrain an existing SKILL.md the way a deep-learning optimizer trains weights: via rollouts, gradient-like reflections, validation-gated acceptance. No model retraining; only the skill markdown changes.\n\n## When to use\n\nUse this skill when:\n- A pro-workflow skill has accumulated 8+ learn-rule rows for it\n- The user reports the skill is \"getting bloated\" or \"rules keep being repeated\"\n- The user wants offline, budget-capped improvement over multiple sessions\n\nDo not use when:\n- Skill has fewer than 8 trajectories (nothing to learn from)\n- The user wants real-time edits (this is offline, single-shot)\n- No `ANTHROPIC_API_KEY` (or equivalent provider key) is available\n\n## Architecture (mirrors SkillOpt's six-stage loop)\n\n```text\nrollout pull recent learnings from SQLite (existing learn-rule rows)\nreflect optimizer LLM analyzes a minibatch, proposes add/delete/replace patches\naggregate vote-merge patches across minibatches\nselect clip by LR budget (default: 3 adds, 2 deletes, 3 replaces per step)\nupdate apply selected patches to a candidate skill content\nevaluate evaluator LLM scores candidate against held-out validation items\ngate accept candidate only if weighted score >= current + acceptThreshold\nslow update at epoch boundary, consolidate accepted edits into a coherent rewrite\n```\n\nFailed candidates are stored in a rejection buffer and fed back to the next reflect step so the optimizer doesn't propose the same patch twice.\n\n## Run it\n\n```bash\n/skill-optimize [options]\n```\n\nOptions (all optional; sensible defaults shown):\n\n| Flag | Default | Notes |\n|---|---|---|\n| `--epochs N` | 3 | Outer loop count |\n| `--batch-size N` | 8 | Trajectories per minibatch |\n| `--minibatches N` | 2 | Minibatches per epoch |\n| `--holdout N` | 6 | Validation items reserved (max ~25% of trajectories) |\n| `--budget-usd X` | 0.50 | Hard cap; loop aborts when spent |\n| `--optimizer-model M` | `claude-sonnet-4-6` | Reflect + slow-update model |\n| `--evaluator-model M` | `claude-haiku-4-5-20251001` | Gate model (cheaper) |\n| `--max-adds N` | 3 | LR budget per step |\n| `--max-deletes N` | 2 | |\n| `--max-replaces N` | 3 | |\n| `--accept-threshold X` | 0.0 | Minimum score delta to accept candidate |\n| `--max-skill-tokens N` | 2000 | Hard cap on candidate length |\n| `--slow-every N` | 2 | Epochs between consolidation passes |\n| `--json` | off | Machine-readable output |\n\nKill switch: `touch ~/.pro-workflow/STOP` aborts the loop between steps.\n\n## Output\n\n- Candidate accepted → SKILL.md overwritten, hash stamp appended in HTML comment\n- Run details persist in `optimization_runs`, `optimization_candidates`, `optimization_patches`, `optimization_rejections`\n- Validation set persists in `optimization_validation` (reusable across runs)\n\nInspect after:\n\n```bash\nsqlite3 ~/.pro-workflow/data.db \"SELECT id, skill_slug, initial_score, best_score, accepted_steps, rejected_steps, spent_usd FROM optimization_runs ORDER BY id DESC LIMIT 5\"\n```\n\n## Rules\n\n- Validation set is frozen at run start. Never re-derive from new corrections mid-run.\n- One candidate per step. No parallel branches.\n- Slow-update output is itself a candidate; it must pass the gate to replace the best.\n- The optimizer LLM and evaluator LLM may be different models. Mixing a strong optimizer with a cheap evaluator is the SkillOpt-recommended config.\n- If `spent_usd >= budget_usd` at any step boundary, the loop ends with `stopped_reason=\"budget exhausted\"`.\n- Patches whose anchor is no longer present in the skill (because a prior patch in the same step removed it) are recorded as rejected with reason `anchor_missing`.\n\n## Provenance\n\nInspired by Microsoft SkillOpt (arXiv:2605.23904). The six-stage rollout/reflect/aggregate/select/update/evaluate pipeline, LR budget, rejection buffer, and slow / meta update mechanics are adapted to pro-workflow's existing SQLite + learn-rule data plane. No SkillOpt code is reused. \"ReflACT\" is not a SkillOpt term and is not used here; the loop is referred to by stage names only.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/skill-optimizer","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/skill-optimizer/SKILL.md","defaultBranch":"main"},"readme":"# Skill Optimizer\n\nTrain an existing SKILL.md the way a deep-learning optimizer trains weights: via rollouts, gradient-like reflections, validation-gated acceptance. No model retraining; only the skill markdown changes.\n\n## When to use\n\nUse this skill when:\n- A pro-workflow skill has accumulated 8+ learn-rule rows for it\n- The user reports the skill is \"getting bloated\" or \"rules keep being repeated\"\n- The user wants offline, budget-capped improvement over multiple sessions\n\nDo not use when:\n- Skill has fewer than 8 trajectories (nothing to learn from)\n- The user wants real-time edits (this is offline, single-shot)\n- No `ANTHROPIC_API_KEY` (or equivalent provider key) is available\n\n## Architecture (mirrors SkillOpt's six-stage loop)\n\n```text\nrollout pull recent learnings from SQLite (existing learn-rule rows)\nreflect optimizer LLM analyzes a minibatch, proposes add/delete/replace patches\naggregate vote-merge patches across minibatches\nselect clip by LR budget (default: 3 adds, 2 deletes, 3 replaces per step)\nupdate apply selected patches to a candidate skill content\nevaluate evaluator LLM scores candidate against held-out validation items\ngate accept candidate only if weighted score >= current + acceptThreshold\nslow update at epoch boundary, consolidate accepted edits into a coherent rewrite\n```\n\nFailed candidates are stored in a rejection buffer and fed back to the next reflect step so the optimizer doesn't propose the same patch twice.\n\n## Run it\n\n```bash\n/skill-optimize [options]\n```\n\nOptions (all optional; sensible defaults shown):\n\n| Flag | Default | Notes |\n|---|---|---|\n| `--epochs N` | 3 | Outer loop count |\n| `--batch-size N` | 8 | Trajectories per minibatch |\n| `--minibatches N` | 2 | Minibatches per epoch |\n| `--holdout N` | 6 | Validation items reserved (max ~25% of trajectories) |\n| `--budget-usd X` | 0.50 | Hard cap; loop aborts when spent |\n| `--optimizer-model M` | `claude-sonnet-4-6` | Reflect + slow-update model |\n| `--evaluator-model M` | `claude-haiku-4-5-20251001` | Gate model (cheaper) |\n| `--max-adds N` | 3 | LR budget per step |\n| `--max-deletes N` | 2 | |\n| `--max-replaces N` | 3 | |\n| `--accept-threshold X` | 0.0 | Minimum score delta to accept candidate |\n| `--max-skill-tokens N` | 2000 | Hard cap on candidate length |\n| `--slow-every N` | 2 | Epochs between consolidation passes |\n| `--json` | off | Machine-readable output |\n\nKill switch: `touch ~/.pro-workflow/STOP` aborts the loop between steps.\n\n## Output\n\n- Candidate accepted → SKILL.md overwritten, hash stamp appended in HTML comment\n- Run details persist in `optimization_runs`, `optimization_candidates`, `optimization_patches`, `optimization_rejections`\n- Validation set persists in `optimization_validation` (reusable across runs)\n\nInspect after:\n\n```bash\nsqlite3 ~/.pro-workflow/data.db \"SELECT id, skill_slug, initial_score, best_score, accepted_steps, rejected_steps, spent_usd FROM optimization_runs ORDER BY id DESC LIMIT 5\"\n```\n\n## Rules\n\n- Validation set is frozen at run start. Never re-derive from new corrections mid-run.\n- One candidate per step. No parallel branches.\n- Slow-update output is itself a candidate; it must pass the gate to replace the best.\n- The optimizer LLM and evaluator LLM may be different models. Mixing a strong optimizer with a cheap evaluator is the SkillOpt-recommended config.\n- If `spent_usd >= budget_usd` at any step boundary, the loop ends with `stopped_reason=\"budget exhausted\"`.\n- Patches whose anchor is no longer present in the skill (because a prior patch in the same step removed it) are recorded as rejected with reason `anchor_missing`.\n\n## Provenance\n\nInspired by Microsoft SkillOpt (arXiv:2605.23904). The six-stage rollout/reflect/aggregate/select/update/evaluate pipeline, LR budget, rejection buffer, and slow / meta update mechanics are adapted to pro-workflow's existing SQLite + learn-rule data plane. No SkillOpt code is reused. \"ReflACT\" is not a SkillOpt term an","createdAt":"2026-09-25T11:52:10.074Z","updatedAt":"2026-09-25T11:52:10.074Z"},{"id":"cmugwi2gf01ohqu06kjg3xt7r","slug":"rohitg00-pro-workflow-agent-teams","name":"agent-teams","description":"Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and file-lock claiming. Patterns for team sizing, task decomposition, and when to use teams vs sub-agents vs worktrees.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"agent-teams","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and file-lock claiming. Patterns for team sizing, task decomposition, and when to use teams vs sub-agents vs worktrees.","permissions":[],"systemPrompt":"# Agent Teams\n\nCoordinate multiple Claude Code sessions working on the same codebase simultaneously.\n\n## Enable\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\nclaude # starts as team lead\n```\n\nThe first session becomes the team lead. Subsequent sessions in the same repo join as teammates.\n\n## Architecture\n\n```text\nTeam Lead (coordinates, delegates, reviews)\n ├── Teammate 1 (owns task A, messages lead + peers)\n ├── Teammate 2 (owns task B, messages lead + peers)\n └── Teammate 3 (owns task C, messages lead + peers)\n │\n └── Shared: task list + mailbox + file locks\n```\n\n**Key difference from subagents:** Teammates are full Claude Code sessions. They have their own context window, can use all tools, and message each other directly — not just report back to a parent.\n\n## Team Sizing\n\n| Team Size | Best For |\n|-----------|----------|\n| 2 | One builds, one reviews |\n| 3-5 | Parallel features across layers (API, UI, tests) |\n| > 5 | Coordination overhead outweighs parallelism |\n\n3-5 teammates is the productive range. Beyond that, the lead spends more time coordinating than the team saves.\n\n**Task granularity:** Aim for 5-6 tasks per teammate. Fewer means underutilization; more means excessive context switching.\n\n## Display Modes\n\n**In-process navigation:**\n- `Shift+Down` — cycle through teammates (wraps around)\n- See each teammate's current task and output\n\n**Split-pane (recommended for >2 teammates):**\n- tmux: `tmux split-window -h` per teammate\n- iTerm2: Cmd+D for vertical split\n- Each pane runs its own `claude` session\n\n## Task Management\n\nTasks flow through states:\n\n```text\npending → in-progress → completed\n │\n └── blocked (waiting on dependency)\n```\n\n### Task Decomposition\n\nBreak work into units that:\n- Touch non-overlapping files\n- Can be verified independently\n- Have clear done criteria\n\n**Good decomposition:**\n```text\nTask 1: Add rate limiting middleware (src/middleware/rate-limit.ts)\nTask 2: Add rate limit tests (tests/rate-limit.test.ts)\nTask 3: Update API docs for rate limit headers (docs/api.md)\nTask 4: Add Redis config for rate limit store (src/config/redis.ts)\n```\n\n**Bad decomposition:**\n```text\nTask 1: Implement rate limiting\nTask 2: Fix rate limiting bugs\nTask 3: Improve rate limiting\n```\n\n### Dependencies\n\nTasks can declare dependencies:\n```text\nTask 3 (API docs) → depends on Task 1 (middleware)\nTask 2 (tests) → depends on Task 1 (middleware)\nTask 4 (Redis config) → no dependencies\n```\n\nTeammates pick up unblocked tasks automatically.\n\n## File-Lock Claiming\n\nTeammates claim files before editing to prevent conflicts:\n\n1. Teammate checks if file is locked\n2. If free, claims it (file-lock-based)\n3. Edits the file\n4. Releases lock on task completion\n\nIf two teammates need the same file, one waits or the lead reassigns.\n\n## Plan Approval\n\nTeammates plan before implementing:\n\n1. Teammate receives task\n2. Writes a brief plan (files to change, approach)\n3. Lead reviews plan\n4. Lead approves or redirects\n5. Teammate implements\n\nThis prevents wasted work from misunderstood requirements.\n\n## Delegate Mode\n\n`Shift+Tab` toggles delegate mode for the lead:\n- Lead coordinates only — no direct code edits\n- All implementation delegated to teammates\n- Lead reviews, approves plans, manages task flow\n\n## Hook Events\n\n| Hook | Fires When |\n|------|------------|\n| TeammateIdle | A teammate finishes its task and has no pending work |\n| TaskCreated | New task added to the shared list |\n| TaskCompleted | A teammate marks a task done |\n\nUse these to trigger notifications, auto-assign next tasks, or run integration tests when all tasks complete.\n\n## When to Use Teams vs Alternatives\n\n| Scenario | Use |\n|----------|-----|\n| Parallel work on non-overlapping files | Agent teams |\n| Quick background exploration | Subagent |\n| Isolated feature branch work | Worktree (`claude -w`) |\n| Competing approaches to same problem | Worktrees (compare results) |\n| Cross-layer changes (API + UI + tests) | Agent teams |\n| One-off delegation | Subagent with `isolation: worktree` |\n| Large-scale migration (20+ files) | `/batch` command |\n\n## Anti-Patterns\n\n- More than 5 teammates — coordination overhead dominates\n- Tasks that share mutable state or the same files\n- Skipping plan approval — leads to rework\n- Lead doing implementation instead of coordinating (use delegate mode)\n- Not setting dependencies — teammates race on coupled tasks\n\n## Example Session\n\n```text\nLead: \"We need rate limiting. Breaking into 4 tasks.\"\n\n Task 1: middleware implementation → Teammate 1\n Task 2: Redis config → Teammate 2 (no deps)\n Task 3: tests → Teammate 1 (after Task 1)\n Task 4: API docs → Teammate 2 (after Task 1)\n\nTeammate 1 plans → Lead approves → implements Task 1\nTeammate 2 plans → Lead approves → implements Task 2\nTask 1 completes → unblocks Tasks 3 and 4\nTeammate 1 picks up Task 3, Teammate 2 picks up Task 4\nAll complete → Lead runs integration tests → commits\n```\n\n## Docs\n\nhttps://code.claude.com/docs/agent-teams","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/agent-teams","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/agent-teams/SKILL.md","defaultBranch":"main"},"readme":"# Agent Teams\n\nCoordinate multiple Claude Code sessions working on the same codebase simultaneously.\n\n## Enable\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\nclaude # starts as team lead\n```\n\nThe first session becomes the team lead. Subsequent sessions in the same repo join as teammates.\n\n## Architecture\n\n```text\nTeam Lead (coordinates, delegates, reviews)\n ├── Teammate 1 (owns task A, messages lead + peers)\n ├── Teammate 2 (owns task B, messages lead + peers)\n └── Teammate 3 (owns task C, messages lead + peers)\n │\n └── Shared: task list + mailbox + file locks\n```\n\n**Key difference from subagents:** Teammates are full Claude Code sessions. They have their own context window, can use all tools, and message each other directly — not just report back to a parent.\n\n## Team Sizing\n\n| Team Size | Best For |\n|-----------|----------|\n| 2 | One builds, one reviews |\n| 3-5 | Parallel features across layers (API, UI, tests) |\n| > 5 | Coordination overhead outweighs parallelism |\n\n3-5 teammates is the productive range. Beyond that, the lead spends more time coordinating than the team saves.\n\n**Task granularity:** Aim for 5-6 tasks per teammate. Fewer means underutilization; more means excessive context switching.\n\n## Display Modes\n\n**In-process navigation:**\n- `Shift+Down` — cycle through teammates (wraps around)\n- See each teammate's current task and output\n\n**Split-pane (recommended for >2 teammates):**\n- tmux: `tmux split-window -h` per teammate\n- iTerm2: Cmd+D for vertical split\n- Each pane runs its own `claude` session\n\n## Task Management\n\nTasks flow through states:\n\n```text\npending → in-progress → completed\n │\n └── blocked (waiting on dependency)\n```\n\n### Task Decomposition\n\nBreak work into units that:\n- Touch non-overlapping files\n- Can be verified independently\n- Have clear done criteria\n\n**Good decomposition:**\n```text\nTask 1: Add rate limiting middleware (src/middleware/rate-limit.ts)\nTask 2: Add rate limit tests (tests/rate-limit.test.ts)\nTask 3: Update API docs for rate limit headers (docs/api.md)\nTask 4: Add Redis config for rate limit store (src/config/redis.ts)\n```\n\n**Bad decomposition:**\n```text\nTask 1: Implement rate limiting\nTask 2: Fix rate limiting bugs\nTask 3: Improve rate limiting\n```\n\n### Dependencies\n\nTasks can declare dependencies:\n```text\nTask 3 (API docs) → depends on Task 1 (middleware)\nTask 2 (tests) → depends on Task 1 (middleware)\nTask 4 (Redis config) → no dependencies\n```\n\nTeammates pick up unblocked tasks automatically.\n\n## File-Lock Claiming\n\nTeammates claim files before editing to prevent conflicts:\n\n1. Teammate checks if file is locked\n2. If free, claims it (file-lock-based)\n3. Edits the file\n4. Releases lock on task completion\n\nIf two teammates need the same file, one waits or the lead reassigns.\n\n## Plan Approval\n\nTeammates plan before implementing:\n\n1. Teammate receives task\n2. Writes a brief plan (files to change, approach)\n3. Lead reviews plan\n4. Lead approves or redirects\n5. Teammate implements\n\nThis prevents wasted work from misunderstood requirements.\n\n## Delegate Mode\n\n`Shift+Tab` toggles delegate mode for the lead:\n- Lead coordinates only — no direct code edits\n- All implementation delegated to teammates\n- Lead reviews, approves plans, manages task flow\n\n## Hook Events\n\n| Hook | Fires When |\n|------|------------|\n| TeammateIdle | A teammate finishes its task and has no pending work |\n| TaskCreated | New task added to the shared list |\n| TaskCompleted | A teammate marks a task done |\n\nUse these to trigger notifications, auto-assign next tasks, or run integration tests when all tasks complete.\n\n## When to Use Teams vs Alternatives\n\n| Scenario | Use |\n|----------|-----|\n| Parallel work on non-overlapping files | Agent teams |\n| Quick background exploration | Subagent |\n| Isolated feature branch work | Worktree (`claude -w`) |\n| Competing approaches to same problem | Worktrees (compare results) |\n| Cross-layer changes (API + UI + tests) | Agent tea","createdAt":"2026-09-25T11:52:09.711Z","updatedAt":"2026-09-25T11:52:09.711Z"},{"id":"cmugwi2gt01okqu066mpvo3v4","slug":"rohitg00-pro-workflow-auto-setup","name":"auto-setup","description":"Auto-configure quality gates, hooks, and settings for a new project. Detects project type and sets up appropriate tooling. Use when onboarding a new codebase.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"auto-setup","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Auto-configure quality gates, hooks, and settings for a new project. Detects project type and sets up appropriate tooling. Use when onboarding a new codebase.","permissions":[],"systemPrompt":"# Auto Setup\n\nDetect project type and configure pro-workflow quality gates automatically.\n\n## Trigger\n\nUse when:\n- Starting work on a new project\n- Onboarding to an unfamiliar codebase\n- Setting up CI integration\n\n## Detection\n\n### Step 1: Identify Project Type\n\n```bash\nls package.json pyproject.toml Cargo.toml go.mod Gemfile pom.xml build.gradle 2>/dev/null\n```\n\n### Step 2: Configure Quality Gates\n\n**Node.js/TypeScript:**\n```json\n{\n \"lint\": \"npm run lint\",\n \"typecheck\": \"npx tsc --noEmit\",\n \"test\": \"npm test -- --changed --passWithNoTests\",\n \"format\": \"npx prettier --check .\"\n}\n```\n\n**Python:**\n```json\n{\n \"lint\": \"ruff check .\",\n \"typecheck\": \"mypy .\",\n \"test\": \"pytest --tb=short -q\",\n \"format\": \"ruff format --check .\"\n}\n```\n\n**Rust:**\n```json\n{\n \"lint\": \"cargo clippy -- -D warnings\",\n \"typecheck\": \"cargo check\",\n \"test\": \"cargo test --quiet\",\n \"format\": \"cargo fmt --check\"\n}\n```\n\n**Go:**\n```json\n{\n \"lint\": \"golangci-lint run\",\n \"typecheck\": \"go vet ./...\",\n \"test\": \"go test ./... -count=1\",\n \"format\": \"gofmt -l .\"\n}\n```\n\n### Step 3: Verify Tools Are Installed\n\nRun each command with `--version` or `--help` to confirm availability. Report missing tools.\n\n### Step 4: Create Configuration\n\nGenerate a `.claude/settings.json` with:\n- Quality gate commands for the detected project type\n- Suggested permission rules (user reviews and approves)\n- Hook configuration for the project\n\n## Output\n\n```text\nAUTO SETUP\n Project type: [Node.js/Python/Rust/Go/Mixed]\n Package manager: [npm/pnpm/yarn/pip/cargo]\n\n Quality gates configured:\n lint: [command] ✓\n typecheck: [command] ✓\n test: [command] ✓\n format: [command] ✓\n\n Missing tools:\n - [tool] — install with: [command]\n\n Settings written to: .claude/settings.json\n```\n\n## Rules\n\n- Never overwrite existing settings without asking\n- Detect, don't assume — check for tool presence\n- Support monorepos (check for workspaces config)\n- Report missing tools with install commands","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/auto-setup","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/auto-setup/SKILL.md","defaultBranch":"main"},"readme":"# Auto Setup\n\nDetect project type and configure pro-workflow quality gates automatically.\n\n## Trigger\n\nUse when:\n- Starting work on a new project\n- Onboarding to an unfamiliar codebase\n- Setting up CI integration\n\n## Detection\n\n### Step 1: Identify Project Type\n\n```bash\nls package.json pyproject.toml Cargo.toml go.mod Gemfile pom.xml build.gradle 2>/dev/null\n```\n\n### Step 2: Configure Quality Gates\n\n**Node.js/TypeScript:**\n```json\n{\n \"lint\": \"npm run lint\",\n \"typecheck\": \"npx tsc --noEmit\",\n \"test\": \"npm test -- --changed --passWithNoTests\",\n \"format\": \"npx prettier --check .\"\n}\n```\n\n**Python:**\n```json\n{\n \"lint\": \"ruff check .\",\n \"typecheck\": \"mypy .\",\n \"test\": \"pytest --tb=short -q\",\n \"format\": \"ruff format --check .\"\n}\n```\n\n**Rust:**\n```json\n{\n \"lint\": \"cargo clippy -- -D warnings\",\n \"typecheck\": \"cargo check\",\n \"test\": \"cargo test --quiet\",\n \"format\": \"cargo fmt --check\"\n}\n```\n\n**Go:**\n```json\n{\n \"lint\": \"golangci-lint run\",\n \"typecheck\": \"go vet ./...\",\n \"test\": \"go test ./... -count=1\",\n \"format\": \"gofmt -l .\"\n}\n```\n\n### Step 3: Verify Tools Are Installed\n\nRun each command with `--version` or `--help` to confirm availability. Report missing tools.\n\n### Step 4: Create Configuration\n\nGenerate a `.claude/settings.json` with:\n- Quality gate commands for the detected project type\n- Suggested permission rules (user reviews and approves)\n- Hook configuration for the project\n\n## Output\n\n```text\nAUTO SETUP\n Project type: [Node.js/Python/Rust/Go/Mixed]\n Package manager: [npm/pnpm/yarn/pip/cargo]\n\n Quality gates configured:\n lint: [command] ✓\n typecheck: [command] ✓\n test: [command] ✓\n format: [command] ✓\n\n Missing tools:\n - [tool] — install with: [command]\n\n Settings written to: .claude/settings.json\n```\n\n## Rules\n\n- Never overwrite existing settings without asking\n- Detect, don't assume — check for tool presence\n- Support monorepos (check for workspaces config)\n- Report missing tools with install commands","createdAt":"2026-09-25T11:52:09.725Z","updatedAt":"2026-09-25T11:52:09.725Z"},{"id":"cmugwi2ha01onqu06zk25h4ui","slug":"rohitg00-pro-workflow-batch-orchestration","name":"batch-orchestration","description":"Decompose large-scale changes into independent units and spawn parallel agents in isolated worktrees. Use for migrations, refactors, codemods, and any change touching 10+ files with the same pattern.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"batch-orchestration","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Decompose large-scale changes into independent units and spawn parallel agents in isolated worktrees. Use for migrations, refactors, codemods, and any change touching 10+ files with the same pattern.","permissions":[],"systemPrompt":"# Batch Orchestration\n\nThe `/batch` command pattern for large-scale parallel changes.\n\n## How It Works\n\n```text\n/batch \n │\n ├── 1. Research: scan repo, understand scope\n ├── 2. Decompose: split into 5-30 independent units\n ├── 3. Present plan: show units, ask for approval\n ├── 4. Execute: one background agent per unit in isolated worktree\n └── 5. Collect: each agent runs tests and opens a PR\n```\n\n## Syntax\n\n```bash\n/batch Convert all React class components to function components\n/batch Add error boundaries to every page component\n/batch Migrate from moment.js to dayjs across the codebase\n/batch Add OpenTelemetry tracing to all API handlers\n```\n\nThe instruction should describe the change pattern, not individual files. The batch system finds the files.\n\n## Phase 1: Research\n\nThe orchestrator scans the repo to find every instance that matches the instruction:\n\n```bash\ngrep -r \"class.*extends.*Component\" --include=\"*.tsx\" -l\n```\n\nIt builds a complete list of targets and groups them by independence.\n\n## Phase 2: Decompose\n\nEach unit must be:\n\n- **Independent** — no shared state with other units\n- **Self-contained** — can be implemented and tested alone\n- **Verifiable** — has a clear pass/fail criteria\n\n**Good units:**\n```text\nUnit 1: Convert src/components/Header.tsx (class → function)\nUnit 2: Convert src/components/Footer.tsx (class → function)\nUnit 3: Convert src/components/Sidebar.tsx (class → function)\n```\n\n**Bad units:**\n```text\nUnit 1: Convert all components in src/components/ (too broad)\nUnit 2: Fix issues from Unit 1 (dependent)\n```\n\nTarget 5-30 units. Fewer than 5 doesn't justify the overhead. More than 30 and coordination costs grow.\n\n## Phase 3: Plan Approval\n\nThe orchestrator presents:\n\n```text\nBATCH: Convert class components to function components\n\nFound: 18 class components across src/\n\nUnits (18):\n 1. src/components/Header.tsx — class Header → function\n 2. src/components/Footer.tsx — class Footer → function\n ...\n 18. src/pages/Settings.tsx — class Settings → function\n\nPer unit: convert class to function, update hooks, run component tests\nEstimated: ~2 min per unit, ~5 min total (parallel)\n\nProceed? (y/n)\n```\n\n**Wait for approval.** Never spawn agents without explicit confirmation.\n\n## Phase 4: Execute\n\nAfter approval, for each unit:\n\n1. Create isolated git worktree\n2. Spawn background agent in that worktree\n3. Agent implements the change\n4. Agent runs relevant tests\n5. Agent opens a PR\n\nAgents run in parallel. Each has its own context window and worktree — no conflicts.\n\n```text\n[Agent 1] ── worktree-1 ── Header.tsx ── tests pass ── PR #41\n[Agent 2] ── worktree-2 ── Footer.tsx ── tests pass ── PR #42\n[Agent 3] ── worktree-3 ── Sidebar.tsx ── tests fail ── flagged\n```\n\n## Phase 5: Collect\n\nAfter all agents complete:\n\n- Summary of pass/fail per unit\n- Links to opened PRs\n- Any units that failed with error details\n- Failed units can be retried individually\n\n## Best For\n\n| Use Case | Why Batch Works |\n|----------|-----------------|\n| API migrations | Same pattern across many endpoints |\n| Dependency upgrades | Find/replace + fix across codebase |\n| Codemod-style refactors | Mechanical transformation, file by file |\n| Adding instrumentation | Same tracing/logging pattern everywhere |\n| Test coverage gaps | Add tests to untested modules independently |\n| Lint rule adoption | Apply new rule fixes across all files |\n\n## Anti-Patterns\n\n| Don't Batch | Why |\n|-------------|-----|\n| Interdependent changes | Units can't run in parallel if they depend on each other |\n| Shared state modifications | Multiple agents writing to the same config or state file |\n| Architecture changes | Need holistic reasoning, not file-by-file |\n| Schema migrations | Database changes must be sequential |\n| Changes requiring human judgment per file | Defeats the purpose of automation |\n\n## Relationship to Other Patterns\n\n| Pattern | Scale | Isolation |\n|---------|-------|-----------|\n| Direct edit | 1-3 files | None needed |\n| Subagent | 1 focused task | Forked context |\n| Worktree | 1 feature branch | Full repo copy |\n| Agent teams | 3-5 parallel tasks | Shared task list |\n| **Batch** | 5-30 identical pattern | Full worktree per unit |\n\nBatch is the heaviest tool. Use it when the change is mechanical, repetitive, and the units are truly independent.\n\n## Guardrails\n\n- Always review the decomposition before approving\n- Each agent must run tests before opening a PR\n- Failed units get flagged, not silently skipped\n- Clean up worktrees after all agents complete\n- Review PRs in batches — don't merge blindly","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/batch-orchestration","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/batch-orchestration/SKILL.md","defaultBranch":"main"},"readme":"# Batch Orchestration\n\nThe `/batch` command pattern for large-scale parallel changes.\n\n## How It Works\n\n```text\n/batch \n │\n ├── 1. Research: scan repo, understand scope\n ├── 2. Decompose: split into 5-30 independent units\n ├── 3. Present plan: show units, ask for approval\n ├── 4. Execute: one background agent per unit in isolated worktree\n └── 5. Collect: each agent runs tests and opens a PR\n```\n\n## Syntax\n\n```bash\n/batch Convert all React class components to function components\n/batch Add error boundaries to every page component\n/batch Migrate from moment.js to dayjs across the codebase\n/batch Add OpenTelemetry tracing to all API handlers\n```\n\nThe instruction should describe the change pattern, not individual files. The batch system finds the files.\n\n## Phase 1: Research\n\nThe orchestrator scans the repo to find every instance that matches the instruction:\n\n```bash\ngrep -r \"class.*extends.*Component\" --include=\"*.tsx\" -l\n```\n\nIt builds a complete list of targets and groups them by independence.\n\n## Phase 2: Decompose\n\nEach unit must be:\n\n- **Independent** — no shared state with other units\n- **Self-contained** — can be implemented and tested alone\n- **Verifiable** — has a clear pass/fail criteria\n\n**Good units:**\n```text\nUnit 1: Convert src/components/Header.tsx (class → function)\nUnit 2: Convert src/components/Footer.tsx (class → function)\nUnit 3: Convert src/components/Sidebar.tsx (class → function)\n```\n\n**Bad units:**\n```text\nUnit 1: Convert all components in src/components/ (too broad)\nUnit 2: Fix issues from Unit 1 (dependent)\n```\n\nTarget 5-30 units. Fewer than 5 doesn't justify the overhead. More than 30 and coordination costs grow.\n\n## Phase 3: Plan Approval\n\nThe orchestrator presents:\n\n```text\nBATCH: Convert class components to function components\n\nFound: 18 class components across src/\n\nUnits (18):\n 1. src/components/Header.tsx — class Header → function\n 2. src/components/Footer.tsx — class Footer → function\n ...\n 18. src/pages/Settings.tsx — class Settings → function\n\nPer unit: convert class to function, update hooks, run component tests\nEstimated: ~2 min per unit, ~5 min total (parallel)\n\nProceed? (y/n)\n```\n\n**Wait for approval.** Never spawn agents without explicit confirmation.\n\n## Phase 4: Execute\n\nAfter approval, for each unit:\n\n1. Create isolated git worktree\n2. Spawn background agent in that worktree\n3. Agent implements the change\n4. Agent runs relevant tests\n5. Agent opens a PR\n\nAgents run in parallel. Each has its own context window and worktree — no conflicts.\n\n```text\n[Agent 1] ── worktree-1 ── Header.tsx ── tests pass ── PR #41\n[Agent 2] ── worktree-2 ── Footer.tsx ── tests pass ── PR #42\n[Agent 3] ── worktree-3 ── Sidebar.tsx ── tests fail ── flagged\n```\n\n## Phase 5: Collect\n\nAfter all agents complete:\n\n- Summary of pass/fail per unit\n- Links to opened PRs\n- Any units that failed with error details\n- Failed units can be retried individually\n\n## Best For\n\n| Use Case | Why Batch Works |\n|----------|-----------------|\n| API migrations | Same pattern across many endpoints |\n| Dependency upgrades | Find/replace + fix across codebase |\n| Codemod-style refactors | Mechanical transformation, file by file |\n| Adding instrumentation | Same tracing/logging pattern everywhere |\n| Test coverage gaps | Add tests to untested modules independently |\n| Lint rule adoption | Apply new rule fixes across all files |\n\n## Anti-Patterns\n\n| Don't Batch | Why |\n|-------------|-----|\n| Interdependent changes | Units can't run in parallel if they depend on each other |\n| Shared state modifications | Multiple agents writing to the same config or state file |\n| Architecture changes | Need holistic reasoning, not file-by-file |\n| Schema migrations | Database changes must be sequential |\n| Changes requiring human judgment per file | Defeats the purpose of automation |\n\n## Relationship to Other Patterns\n\n| Pattern | Scale | Isolation |\n|---------|-------|-----------|\n| Direct edit | 1-3 files | None needed |\n| Sub","createdAt":"2026-09-25T11:52:09.742Z","updatedAt":"2026-09-25T11:52:09.742Z"},{"id":"cmugwi2hu01oqqu0688h5wrmp","slug":"rohitg00-pro-workflow-bug-capture","name":"bug-capture","description":"Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says \"file an issue\", \"log this as a bug\", \"capture this\".","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"bug-capture","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says \"file an issue\", \"log this as a bug\", \"capture this\".","permissions":[],"systemPrompt":"# bug-capture\n\nTurn a conversation into an issue that still reads correctly after a\nmajor refactor.\n\n## Flow\n\n### 1. Listen, then clarify minimally\n\nLet the user describe the problem in their own words. Ask at most two\nshort clarifying questions, drawn from:\n\n- Expected behavior vs. actual behavior.\n- Concrete reproduction steps if not already implied.\n- Frequency: deterministic, intermittent, or one-off.\n\nIf the description already answers these, skip straight to filing. Over-\ninterviewing is a tax the reporter pays for your uncertainty.\n\n### 2. Explore in parallel\n\nWhile the user is answering, start a background exploration of the\nrelevant area. The goal is **not** to propose a fix. The goal is to\nabsorb the project's own vocabulary — the nouns and verbs the codebase\nuses for this feature — so the issue reads like it was written by a\nmaintainer.\n\nIf the repo has a glossary file (common names: GLOSSARY.md,\nUBIQUITOUS_LANGUAGE.md, docs/domain.md), read it first.\n\n### 3. Check for duplicates before filing\n\nRun `gh issue list --search \"\" --state all --limit 10`. If a\nlive or recently closed issue matches, surface it to the user and ask\nwhether to add a comment instead of opening a new issue. Do not silently\nskip filing.\n\n### 4. Decide: single issue or breakdown\n\nBreak down when the report contains two or more independent failure\nmodes that a different contributor could fix in parallel. Keep as one\nwhen every symptom traces to a single wrong behavior.\n\nFor a breakdown, file in dependency order so each child issue can\nreference a real parent number, and mark honest `Blocked by` links.\nAvoid inventing dependencies to make the tree look tidier.\n\n### 5. File with `gh issue create`\n\nFile without asking the user to review the draft. Send back the URLs.\n\n#### Single-issue template\n\n```\n## What happened\n\n\n## What I expected\n\n\n## Reproduction\n1. \n2. \n3. \n\n## Context\n\n```\n\n#### Child-issue template\n\n```\n## Parent\n#\n\n## What is wrong\n\n\n## What I expected\n\n\n## Reproduction\n1. \n\n## Blocked by\n<#issue or \"none — independent\">\n\n## Context\n\n```\n\n### 6. Rules that apply to every issue body\n\n- No file paths, line numbers, function names, or PR numbers. These go\n stale. Describe behavior, not code.\n- Use the project's domain nouns, not generic tech terms. \"The sync\n worker drops the patch\" beats \"`applyPatch()` throws\".\n- Reproduction steps are mandatory. If you cannot derive them, go back\n to the user once before filing.\n- Thirty-second read target. Cut anything that does not help a\n maintainer decide whether to pick it up.\n\n### 7. Keep going\n\nAfter each issue, print the URL and ask whether there is a next one. Do\nnot batch multiple reports into one filing pass — each bug deserves its\nown scoped issue.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/bug-capture","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/bug-capture/SKILL.md","defaultBranch":"main"},"readme":"# bug-capture\n\nTurn a conversation into an issue that still reads correctly after a\nmajor refactor.\n\n## Flow\n\n### 1. Listen, then clarify minimally\n\nLet the user describe the problem in their own words. Ask at most two\nshort clarifying questions, drawn from:\n\n- Expected behavior vs. actual behavior.\n- Concrete reproduction steps if not already implied.\n- Frequency: deterministic, intermittent, or one-off.\n\nIf the description already answers these, skip straight to filing. Over-\ninterviewing is a tax the reporter pays for your uncertainty.\n\n### 2. Explore in parallel\n\nWhile the user is answering, start a background exploration of the\nrelevant area. The goal is **not** to propose a fix. The goal is to\nabsorb the project's own vocabulary — the nouns and verbs the codebase\nuses for this feature — so the issue reads like it was written by a\nmaintainer.\n\nIf the repo has a glossary file (common names: GLOSSARY.md,\nUBIQUITOUS_LANGUAGE.md, docs/domain.md), read it first.\n\n### 3. Check for duplicates before filing\n\nRun `gh issue list --search \"\" --state all --limit 10`. If a\nlive or recently closed issue matches, surface it to the user and ask\nwhether to add a comment instead of opening a new issue. Do not silently\nskip filing.\n\n### 4. Decide: single issue or breakdown\n\nBreak down when the report contains two or more independent failure\nmodes that a different contributor could fix in parallel. Keep as one\nwhen every symptom traces to a single wrong behavior.\n\nFor a breakdown, file in dependency order so each child issue can\nreference a real parent number, and mark honest `Blocked by` links.\nAvoid inventing dependencies to make the tree look tidier.\n\n### 5. File with `gh issue create`\n\nFile without asking the user to review the draft. Send back the URLs.\n\n#### Single-issue template\n\n```\n## What happened\n\n\n## What I expected\n\n\n## Reproduction\n1. \n2. \n3. \n\n## Context\n\n```\n\n#### Child-issue template\n\n```\n## Parent\n#\n\n## What is wrong\n\n\n## What I expected\n\n\n## Reproduction\n1. \n\n## Blocked by\n<#issue or \"none — independent\">\n\n## Context\n\n```\n\n### 6. Rules that apply to every issue body\n\n- No file paths, line numbers, function names, or PR numbers. These go\n stale. Describe behavior, not code.\n- Use the project's domain nouns, not generic tech terms. \"The sync\n worker drops the patch\" beats \"`applyPatch()` throws\".\n- Reproduction steps are mandatory. If you cannot derive them, go back\n to the user once before filing.\n- Thirty-second read target. Cut anything that does not help a\n maintainer decide whether to pick it up.\n\n### 7. Keep going\n\nAfter each issue, print the URL and ask whether there is a next one. Do\nnot batch multiple reports into one filing pass — each bug deserves its\nown scoped issue.","createdAt":"2026-09-25T11:52:09.763Z","updatedAt":"2026-09-25T11:52:09.763Z"},{"id":"cmugwi2iv01otqu0692tt0ywh","slug":"rohitg00-pro-workflow-compact-guard","name":"compact-guard","description":"Smart context compaction with state preservation. Saves critical files, task progress, and working state before compaction, restores after. Use before manual compact or when auto-compact triggers.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"compact-guard","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Smart context compaction with state preservation. Saves critical files, task progress, and working state before compaction, restores after. Use before manual compact or when auto-compact triggers.","permissions":[],"systemPrompt":"# Compact Guard\n\nProtect important context through compaction cycles. Based on Claude Code internals: compaction restores max 5 files with 5K tokens each, within a 50K total budget.\n\n## Trigger\n\nUse before `/compact` or when auto-compact warning appears.\n\n## Key Constants (from Claude Code source)\n\n- `POST_COMPACT_MAX_FILES_TO_RESTORE = 5` — only 5 files survive\n- `POST_COMPACT_TOKEN_BUDGET = 50K` — total restore budget\n- `POST_COMPACT_MAX_TOKENS_PER_FILE = 5K` — per-file limit\n- Auto-compact fires at `context_window - 13K` buffer\n\n## Pre-Compact Checklist\n\nBefore compacting, save these to memory or a scratch file:\n\n1. **Current task** — What are you working on? One sentence.\n2. **Files in progress** — Which files are being edited? (max 5 — compaction only restores 5)\n3. **Decisions made** — Any architectural choices made this session\n4. **Blockers** — What's preventing progress?\n5. **Next steps** — What to do immediately after compact\n\n## Strategy: Microcompact First\n\nBefore full compaction, try microcompact:\n- Large tool results (test output, grep results) can be trimmed\n- File reads that are no longer relevant can be dropped\n- Use subagents for heavy exploration to keep main context clean\n\n## Post-Compact Recovery\n\nAfter compaction, immediately:\n\n1. Re-read the top-priority file (the one you're actively editing)\n2. Check task list for current progress\n3. Review any scratch notes saved pre-compact\n4. Resume from next steps\n\n## Prevention Strategies\n\n| Strategy | Token Savings | When |\n|----------|--------------|------|\n| Delegate grep/search to subagent | 30-60% per search | Always for broad searches |\n| Read only needed lines (`offset`/`limit`) | 50-90% per read | Large files |\n| Compact at task boundaries | Preserves coherence | Between logical steps |\n| Use `/resume` for fresh start | 100% | Unrelated new task |\n\n## Output\n\nAfter running compact-guard:\n```text\nCOMPACT GUARD\n Files to preserve: [list top 5]\n Task state: [one sentence]\n Decisions: [key choices]\n Next step: [immediate action after compact]\n\n Ready to compact. Run /compact now.\n```\n\n## Rules\n\n- Always save state before compacting — never compact blind\n- Prioritize the file you're actively editing as #1 to restore\n- If auto-compact fires unexpectedly, immediately re-read your working file\n- Keep CLAUDE.md under 60 lines to leave room for actual context","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/compact-guard","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/compact-guard/SKILL.md","defaultBranch":"main"},"readme":"# Compact Guard\n\nProtect important context through compaction cycles. Based on Claude Code internals: compaction restores max 5 files with 5K tokens each, within a 50K total budget.\n\n## Trigger\n\nUse before `/compact` or when auto-compact warning appears.\n\n## Key Constants (from Claude Code source)\n\n- `POST_COMPACT_MAX_FILES_TO_RESTORE = 5` — only 5 files survive\n- `POST_COMPACT_TOKEN_BUDGET = 50K` — total restore budget\n- `POST_COMPACT_MAX_TOKENS_PER_FILE = 5K` — per-file limit\n- Auto-compact fires at `context_window - 13K` buffer\n\n## Pre-Compact Checklist\n\nBefore compacting, save these to memory or a scratch file:\n\n1. **Current task** — What are you working on? One sentence.\n2. **Files in progress** — Which files are being edited? (max 5 — compaction only restores 5)\n3. **Decisions made** — Any architectural choices made this session\n4. **Blockers** — What's preventing progress?\n5. **Next steps** — What to do immediately after compact\n\n## Strategy: Microcompact First\n\nBefore full compaction, try microcompact:\n- Large tool results (test output, grep results) can be trimmed\n- File reads that are no longer relevant can be dropped\n- Use subagents for heavy exploration to keep main context clean\n\n## Post-Compact Recovery\n\nAfter compaction, immediately:\n\n1. Re-read the top-priority file (the one you're actively editing)\n2. Check task list for current progress\n3. Review any scratch notes saved pre-compact\n4. Resume from next steps\n\n## Prevention Strategies\n\n| Strategy | Token Savings | When |\n|----------|--------------|------|\n| Delegate grep/search to subagent | 30-60% per search | Always for broad searches |\n| Read only needed lines (`offset`/`limit`) | 50-90% per read | Large files |\n| Compact at task boundaries | Preserves coherence | Between logical steps |\n| Use `/resume` for fresh start | 100% | Unrelated new task |\n\n## Output\n\nAfter running compact-guard:\n```text\nCOMPACT GUARD\n Files to preserve: [list top 5]\n Task state: [one sentence]\n Decisions: [key choices]\n Next step: [immediate action after compact]\n\n Ready to compact. Run /compact now.\n```\n\n## Rules\n\n- Always save state before compacting — never compact blind\n- Prioritize the file you're actively editing as #1 to restore\n- If auto-compact fires unexpectedly, immediately re-read your working file\n- Keep CLAUDE.md under 60 lines to leave room for actual context","createdAt":"2026-09-25T11:52:09.800Z","updatedAt":"2026-09-25T11:52:09.800Z"},{"id":"cmugwi2j401owqu06nku3e80c","slug":"rohitg00-pro-workflow-context-engineering","name":"context-engineering","description":"Master the four operations of context engineering — Write, Select, Compress, Isolate. Manage token budgets, compaction strategies, and context partitioning to keep AI sessions sharp and efficient.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"context-engineering","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Master the four operations of context engineering — Write, Select, Compress, Isolate. Manage token budgets, compaction strategies, and context partitioning to keep AI sessions sharp and efficient.","permissions":[],"systemPrompt":"# Context Engineering\n\nFour operations control everything about how context flows through an AI coding session. Master them and you control the quality of every response.\n\n## The Four Operations\n\n### 1. Write — Persist Info Outside Context\n\nMove information out of the context window into durable storage so it survives compaction and session boundaries.\n\n**Where to write:**\n\n| Target | When | Example |\n|--------|------|---------|\n| CLAUDE.md | Permanent project rules | \"Always use pnpm, never npm\" |\n| NOTES.md / scratchpad | Working state for current task | Architecture decisions, open questions |\n| `.claude/memory/` | Learnings and patterns | `[LEARN]` rules from corrections |\n| External files | Data too large for context | Test plans, migration checklists |\n\n**Pattern — Scratchpad workflow:**\n```text\n1. Start complex task → create NOTES.md with goals and constraints\n2. After research → write findings to NOTES.md\n3. After compaction → NOTES.md survives, context does not\n4. Resume → read NOTES.md to recover full state\n```\n\n### 2. Select — Retrieve Relevant Info\n\nPull the right information into context at the right time. Precision matters more than volume.\n\n**Methods ranked by precision:**\n\n1. `@file` references — exact file injection\n2. `grep` / `Glob` — targeted pattern search\n3. Subagent exploration — delegated deep search\n4. RAG / embeddings — semantic retrieval for large codebases\n\n**Key principle: Focused 300 tokens > unfocused 113K tokens.**\n\nA surgical grep result that returns the exact function signature beats dumping an entire module into context. Every irrelevant token dilutes attention.\n\n**Pattern — Progressive retrieval:**\n```text\n1. Start with file names (Glob)\n2. Narrow to specific functions (Grep)\n3. Read only the relevant lines (Read with offset+limit)\n4. Never read entire large files when you need one function\n```\n\n### 3. Compress — Reduce Tokens, Preserve Signal\n\nShrink context without losing the information that matters.\n\n**Compaction strategies:**\n\n| Strategy | How | When |\n|----------|-----|------|\n| `/compact` with focus | `/compact focus: auth module changes` | Task boundaries |\n| Microcompact | Ask Claude to summarize tool output inline | After large reads/searches |\n| Head+tail | Read first 20 + last 20 lines of large output | Log analysis, test results |\n| Tool result clearing | Subagent results auto-clear after reporting | Heavy exploration |\n| Semantic selection | Summarize findings, discard raw data | Research phases |\n\n**Compaction triggers:**\n\n- After planning, before implementation\n- After completing a feature or milestone\n- When context exceeds 50% (set `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50`)\n- Before switching task domains\n- After heavy search/read operations\n\n**PostCompact hook — Re-inject critical context:**\n```json\n{\n \"type\": \"PostCompact\",\n \"command\": \"cat .claude/critical-context.md\"\n}\n```\n\nUse this to ensure project rules, current task state, or architecture constraints survive every compaction.\n\n### 4. Isolate — Partition Across Execution Spaces\n\nDon't load everything into one context. Split work across independent execution spaces.\n\n| Method | Isolation Level | Use When |\n|--------|----------------|----------|\n| Subagents | Forked context | Heavy exploration, test runs, doc generation |\n| Worktrees (`claude -w`) | Full repo copy | Parallel features, competing approaches |\n| `/btw` (built-in Claude Code) | Temporary overlay | Quick questions without entering conversation history |\n| Agent teams | Independent sessions | Cross-layer changes, parallel reviews |\n| Fresh session (`/resume`) | Clean slate | Unrelated work, degraded context |\n\n**Pattern — Subagent delegation:**\n```text\nMain session: planning, coordination, commits\nSubagent 1: explore auth module, report findings\nSubagent 2: run test suite, report failures\nSubagent 3: generate migration script\n```\n\nMain context stays clean. Subagents handle the volume.\n\n## Context Budget Planning\n\nExample baseline (calibrate with `/context`): ~200K total window, ~20K overhead (CLAUDE.md, tool definitions, MCP schemas). Plan around **~180K usable** — actual budgets vary by model and configuration.\n\n| Allocation | Budget | What Goes Here |\n|------------|--------|----------------|\n| Static context | 20-30K | CLAUDE.md, tool schemas, MCP definitions |\n| Dynamic context | 150-180K | Code, conversation, tool results |\n\n**Put static context first.** CLAUDE.md and tool definitions load before conversation. Keeping them stable maximizes prompt cache hits — saves cost and latency.\n\n| Phase | Target Usage | Action If Over |\n|-------|-------------|----------------|\n| Planning | < 20% | Keep plans concise, write to scratchpad |\n| Implementation | < 50% | Compact between files, delegate reads |\n| Testing | < 70% | Delegate test runs to subagents |\n| Review | < 85% | Start fresh session if degraded |\n\n## When to /clear vs /compact vs Subagent\n\n| Situation | Action |\n|-----------|--------|\n| Task boundary, want to keep learnings | `/compact` with focus |\n| Context degraded, Claude repeating itself | `/compact`, then `/resume` if still bad |\n| Starting unrelated work | `/clear` or new session |\n| Heavy read/search operation | Delegate to subagent |\n| Quick side question | `/btw` (doesn't pollute main context) |\n| Exploring multiple approaches | Worktrees or agent teams |\n\n## Anti-Patterns\n\n- Loading entire files when you need one function\n- Keeping MCP tool results in context after extracting what you need\n- Running 15+ MCPs (each adds tool schema overhead to every request)\n- Vague prompts that force Claude to search broadly (\"fix the code\")\n- Never compacting until auto-compact triggers at 95%\n\n## Add to CLAUDE.md\n\n```markdown\n## Context Engineering\n\nWrite to NOTES.md for working state that must survive compaction.\nSelect with precision — grep first, read specific lines, never dump whole files.\nCompact at 50% or task boundaries. Set CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50.\nIsolate heavy work to subagents. Main session stays for coordination and commits.\n```","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/context-engineering","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/context-engineering/SKILL.md","defaultBranch":"main"},"readme":"# Context Engineering\n\nFour operations control everything about how context flows through an AI coding session. Master them and you control the quality of every response.\n\n## The Four Operations\n\n### 1. Write — Persist Info Outside Context\n\nMove information out of the context window into durable storage so it survives compaction and session boundaries.\n\n**Where to write:**\n\n| Target | When | Example |\n|--------|------|---------|\n| CLAUDE.md | Permanent project rules | \"Always use pnpm, never npm\" |\n| NOTES.md / scratchpad | Working state for current task | Architecture decisions, open questions |\n| `.claude/memory/` | Learnings and patterns | `[LEARN]` rules from corrections |\n| External files | Data too large for context | Test plans, migration checklists |\n\n**Pattern — Scratchpad workflow:**\n```text\n1. Start complex task → create NOTES.md with goals and constraints\n2. After research → write findings to NOTES.md\n3. After compaction → NOTES.md survives, context does not\n4. Resume → read NOTES.md to recover full state\n```\n\n### 2. Select — Retrieve Relevant Info\n\nPull the right information into context at the right time. Precision matters more than volume.\n\n**Methods ranked by precision:**\n\n1. `@file` references — exact file injection\n2. `grep` / `Glob` — targeted pattern search\n3. Subagent exploration — delegated deep search\n4. RAG / embeddings — semantic retrieval for large codebases\n\n**Key principle: Focused 300 tokens > unfocused 113K tokens.**\n\nA surgical grep result that returns the exact function signature beats dumping an entire module into context. Every irrelevant token dilutes attention.\n\n**Pattern — Progressive retrieval:**\n```text\n1. Start with file names (Glob)\n2. Narrow to specific functions (Grep)\n3. Read only the relevant lines (Read with offset+limit)\n4. Never read entire large files when you need one function\n```\n\n### 3. Compress — Reduce Tokens, Preserve Signal\n\nShrink context without losing the information that matters.\n\n**Compaction strategies:**\n\n| Strategy | How | When |\n|----------|-----|------|\n| `/compact` with focus | `/compact focus: auth module changes` | Task boundaries |\n| Microcompact | Ask Claude to summarize tool output inline | After large reads/searches |\n| Head+tail | Read first 20 + last 20 lines of large output | Log analysis, test results |\n| Tool result clearing | Subagent results auto-clear after reporting | Heavy exploration |\n| Semantic selection | Summarize findings, discard raw data | Research phases |\n\n**Compaction triggers:**\n\n- After planning, before implementation\n- After completing a feature or milestone\n- When context exceeds 50% (set `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50`)\n- Before switching task domains\n- After heavy search/read operations\n\n**PostCompact hook — Re-inject critical context:**\n```json\n{\n \"type\": \"PostCompact\",\n \"command\": \"cat .claude/critical-context.md\"\n}\n```\n\nUse this to ensure project rules, current task state, or architecture constraints survive every compaction.\n\n### 4. Isolate — Partition Across Execution Spaces\n\nDon't load everything into one context. Split work across independent execution spaces.\n\n| Method | Isolation Level | Use When |\n|--------|----------------|----------|\n| Subagents | Forked context | Heavy exploration, test runs, doc generation |\n| Worktrees (`claude -w`) | Full repo copy | Parallel features, competing approaches |\n| `/btw` (built-in Claude Code) | Temporary overlay | Quick questions without entering conversation history |\n| Agent teams | Independent sessions | Cross-layer changes, parallel reviews |\n| Fresh session (`/resume`) | Clean slate | Unrelated work, degraded context |\n\n**Pattern — Subagent delegation:**\n```text\nMain session: planning, coordination, commits\nSubagent 1: explore auth module, report findings\nSubagent 2: run test suite, report failures\nSubagent 3: generate migration script\n```\n\nMain context stays clean. Subagents handle the volume.\n\n## Context Budget Planning\n\nExample baseline (calibrate with `/context`): ~2","createdAt":"2026-09-25T11:52:09.808Z","updatedAt":"2026-09-25T11:52:09.808Z"},{"id":"cmugwi2jg01ozqu068anngpmg","slug":"rohitg00-pro-workflow-context-optimizer","name":"context-optimizer","description":"Optimize token usage and context management. Use when sessions feel slow, context is degraded, or you're running out of budget.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"context-optimizer","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Optimize token usage and context management. Use when sessions feel slow, context is degraded, or you're running out of budget.","permissions":[],"systemPrompt":"# Context Optimizer\n\nManage your context window and token budget effectively.\n\n## Quick Diagnosis\n\n1. Run `/context` to check current usage\n2. If > 70% → compact now before it degrades\n3. If > 90% → you're in the \"dumb zone\", compact immediately\n\n## Optimization Strategies\n\n### Immediate\n\n| Action | Saves | When |\n|--------|-------|------|\n| `/compact` | 30-50% context | At task boundaries |\n| Disable unused MCPs | ~5% per MCP | When switching domains |\n| Use subagents for exploration | Keeps main context clean | Heavy search/read tasks |\n| Fresh session via `/resume` | 100% reset | When starting unrelated work |\n\n### Configuration\n\nSet proactive auto-compaction:\n```json\n{\n \"env\": {\n \"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE\": \"50\"\n }\n}\n```\n\n### MCP Audit\n\nKeep <10 MCPs enabled, <80 tools total. Each MCP adds overhead to every request.\n\n```bash\n/mcp # List active servers\n# Disable what you're not using\n```\n\n### Prompt Engineering for Token Efficiency\n\n- Scope your prompts: \"In src/auth/, fix the login bug\"\n- Provide constraints: \"Don't modify the middleware\"\n- Give acceptance criteria: \"Should return 429 after 5 attempts\"\n- Avoid vague prompts: \"Fix the code\" (forces Claude to read everything)\n\n### Subagent Delegation\n\nHeavy operations that generate lots of output should go to subagents:\n\n- Test suite output → subagent\n- Large file exploration → subagent\n- Documentation generation → subagent\n- Log analysis → subagent\n\nThe main session stays clean while subagents handle the volume.\n\n## Context Budget Planning\n\n| Phase | Target Usage | Action If Over |\n|-------|-------------|----------------|\n| Planning | < 20% | Keep plans concise |\n| Implementation | < 60% | Compact between files |\n| Testing | < 80% | Delegate to subagent |\n| Review | < 90% | Start fresh session |\n\n## Token Efficiency\n\n### Output Reduction (40-60% savings)\n- No sycophantic openers (\"Sure!\", \"Great question!\")\n- No closing fluff (\"Let me know if you need anything!\")\n- No prompt restatement before answering\n- Code first, explanation only if non-obvious\n- Structured output (tables, bullets) over prose\n- ASCII only: -- not em dashes, straight quotes not smart quotes\n\n### Behavioral Efficiency\n- One-pass coding: complete solution, test once, stop if green\n- Read before write: never modify unread files\n- No re-reads: don't re-read unchanged files\n- Tool-call budgets: 20 (quick fix) to 80 (large feature)\n- Never iterate more than twice on the same failure\n\n### Task Profiles\nSwitch response style based on context:\n- **Coding**: code first, minimal explanation, simplest solution\n- **Agent/Pipeline**: structured output only, no prose, parseable\n- **Analysis**: finding first, tables over paragraphs, sourced numbers\n\n## CLAUDE.md Optimization\n\n- Root CLAUDE.md: < 60 lines ideal, < 150 max\n- Move package-specific info to package-level CLAUDE.md\n- Move personal preferences to CLAUDE.local.md\n- Remove obvious or rapidly-changing information\n\n## When Context Is Degraded\n\nSigns:\n- Claude repeats itself or forgets earlier context\n- Responses become generic or lose project-specific knowledge\n- Tool calls start failing for reasons that worked earlier\n\nFix:\n1. Manual `/compact`\n2. If still bad: new session with `/resume`\n3. For recurring issues: reduce CLAUDE.md size, disable MCPs","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/context-optimizer","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/context-optimizer/SKILL.md","defaultBranch":"main"},"readme":"# Context Optimizer\n\nManage your context window and token budget effectively.\n\n## Quick Diagnosis\n\n1. Run `/context` to check current usage\n2. If > 70% → compact now before it degrades\n3. If > 90% → you're in the \"dumb zone\", compact immediately\n\n## Optimization Strategies\n\n### Immediate\n\n| Action | Saves | When |\n|--------|-------|------|\n| `/compact` | 30-50% context | At task boundaries |\n| Disable unused MCPs | ~5% per MCP | When switching domains |\n| Use subagents for exploration | Keeps main context clean | Heavy search/read tasks |\n| Fresh session via `/resume` | 100% reset | When starting unrelated work |\n\n### Configuration\n\nSet proactive auto-compaction:\n```json\n{\n \"env\": {\n \"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE\": \"50\"\n }\n}\n```\n\n### MCP Audit\n\nKeep <10 MCPs enabled, <80 tools total. Each MCP adds overhead to every request.\n\n```bash\n/mcp # List active servers\n# Disable what you're not using\n```\n\n### Prompt Engineering for Token Efficiency\n\n- Scope your prompts: \"In src/auth/, fix the login bug\"\n- Provide constraints: \"Don't modify the middleware\"\n- Give acceptance criteria: \"Should return 429 after 5 attempts\"\n- Avoid vague prompts: \"Fix the code\" (forces Claude to read everything)\n\n### Subagent Delegation\n\nHeavy operations that generate lots of output should go to subagents:\n\n- Test suite output → subagent\n- Large file exploration → subagent\n- Documentation generation → subagent\n- Log analysis → subagent\n\nThe main session stays clean while subagents handle the volume.\n\n## Context Budget Planning\n\n| Phase | Target Usage | Action If Over |\n|-------|-------------|----------------|\n| Planning | < 20% | Keep plans concise |\n| Implementation | < 60% | Compact between files |\n| Testing | < 80% | Delegate to subagent |\n| Review | < 90% | Start fresh session |\n\n## Token Efficiency\n\n### Output Reduction (40-60% savings)\n- No sycophantic openers (\"Sure!\", \"Great question!\")\n- No closing fluff (\"Let me know if you need anything!\")\n- No prompt restatement before answering\n- Code first, explanation only if non-obvious\n- Structured output (tables, bullets) over prose\n- ASCII only: -- not em dashes, straight quotes not smart quotes\n\n### Behavioral Efficiency\n- One-pass coding: complete solution, test once, stop if green\n- Read before write: never modify unread files\n- No re-reads: don't re-read unchanged files\n- Tool-call budgets: 20 (quick fix) to 80 (large feature)\n- Never iterate more than twice on the same failure\n\n### Task Profiles\nSwitch response style based on context:\n- **Coding**: code first, minimal explanation, simplest solution\n- **Agent/Pipeline**: structured output only, no prose, parseable\n- **Analysis**: finding first, tables over paragraphs, sourced numbers\n\n## CLAUDE.md Optimization\n\n- Root CLAUDE.md: < 60 lines ideal, < 150 max\n- Move package-specific info to package-level CLAUDE.md\n- Move personal preferences to CLAUDE.local.md\n- Remove obvious or rapidly-changing information\n\n## When Context Is Degraded\n\nSigns:\n- Claude repeats itself or forgets earlier context\n- Responses become generic or lose project-specific knowledge\n- Tool calls start failing for reasons that worked earlier\n\nFix:\n1. Manual `/compact`\n2. If still bad: new session with `/resume`\n3. For recurring issues: reduce CLAUDE.md size, disable MCPs","createdAt":"2026-09-25T11:52:09.820Z","updatedAt":"2026-09-25T11:52:09.820Z"},{"id":"cmugwi2jr01p2qu06iq9pk2xo","slug":"rohitg00-pro-workflow-cost-tracker","name":"cost-tracker","description":"Track session costs, set budget alerts, and optimize token spend. Use to check costs mid-session or set spending limits.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"cost-tracker","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Track session costs, set budget alerts, and optimize token spend. Use to check costs mid-session or set spending limits.","permissions":[],"systemPrompt":"# Cost Tracker\n\nMonitor and optimize Claude Code session costs.\n\n## Trigger\n\nUse when:\n- Checking session costs\n- Setting budget alerts\n- Optimizing token spend\n- Planning multi-session work\n\n## Cost Awareness\n\n### Check Current Costs\n```bash\n# Session cost is shown at the end of each session\n# Mid-session: check the status bar or run /cost\n```\n\n### Cost Drivers\n\n| Operation | Relative Cost | Optimization |\n|-----------|--------------|-------------|\n| Large file reads | High | Use offset/limit params |\n| Broad grep searches | Medium | Scope to specific dirs |\n| Subagent spawning | High (new context) | Reuse agents via SendMessage |\n| Repeated tool calls | Cumulative | Batch operations |\n| MCP tool calls | Variable | Minimize round-trips |\n| Model selection | 3-10x difference | Use haiku for simple tasks |\n\n### Token Budget by Task Type\n\n| Task | Typical Cost | Budget Alert |\n|------|-------------|-------------|\n| Bug fix | $0.10-0.50 | $1.00 |\n| Feature (small) | $0.50-2.00 | $3.00 |\n| Feature (large) | $2.00-8.00 | $10.00 |\n| Refactor | $1.00-5.00 | $7.00 |\n| Code review | $0.20-1.00 | $2.00 |\n\n### Tool-Call Budgets\n\nSet explicit budgets by task complexity:\n\n| Task Type | Tool-Call Budget | Wrap-Up At |\n|-----------|-----------------|------------|\n| Quick fix / lookup | 20 calls | 15 |\n| Bug fix | 30 calls | 25 |\n| Feature (small) | 50 calls | 40 |\n| Feature (large) | 80 calls | 65 |\n| Refactor | 50 calls | 40 |\n\nAt the wrap-up threshold: commit progress, assess remaining work, decide whether to continue or start fresh.\n\n### Optimization Strategies\n\n1. **Scope prompts tightly** — \"Fix the auth bug in src/auth/login.ts\" vs \"Fix the auth bug\"\n2. **Use the right model** — Haiku for simple lookups, Sonnet for features, Opus for architecture\n3. **Delegate to subagents** — Search/explore operations in subagents keep main context lean\n4. **Compact proactively** — Don't wait for auto-compact; compact at task boundaries\n5. **Read selectively** — Use `offset` and `limit` params for large files\n6. **Batch operations** — Multiple independent tool calls in one message\n7. **One-pass discipline** — Write complete solution, test once, stop if green\n8. **No re-reads** — Don't re-read unchanged files; trust cached knowledge\n9. **Read before write** — Never write a file without reading it first\n10. **Kill output bloat** — No sycophantic openers, no closing fluff, no prompt restatement\n\n## Budget Alerts\n\nSet mental checkpoints:\n- **50% budget** — Are you on track? Should you compact?\n- **80% budget** — Wrap up current task, avoid new exploration\n- **100% budget** — Commit what you have, start fresh session\n\n## Output\n\n```text\nCOST TRACKER\n Session cost: $X.XX\n Token usage: [input]K in / [output]K out\n Cache hit rate: ~XX%\n\n Top cost drivers:\n 1. [operation] — $X.XX\n 2. [operation] — $X.XX\n\n Optimization tips:\n - [specific suggestion]\n```\n\n## Rules\n\n- Track costs as awareness, not hard limits\n- Never sacrifice code quality to save tokens\n- Compact at task boundaries, not mid-task\n- Use subagents for exploration-heavy work","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/cost-tracker","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/cost-tracker/SKILL.md","defaultBranch":"main"},"readme":"# Cost Tracker\n\nMonitor and optimize Claude Code session costs.\n\n## Trigger\n\nUse when:\n- Checking session costs\n- Setting budget alerts\n- Optimizing token spend\n- Planning multi-session work\n\n## Cost Awareness\n\n### Check Current Costs\n```bash\n# Session cost is shown at the end of each session\n# Mid-session: check the status bar or run /cost\n```\n\n### Cost Drivers\n\n| Operation | Relative Cost | Optimization |\n|-----------|--------------|-------------|\n| Large file reads | High | Use offset/limit params |\n| Broad grep searches | Medium | Scope to specific dirs |\n| Subagent spawning | High (new context) | Reuse agents via SendMessage |\n| Repeated tool calls | Cumulative | Batch operations |\n| MCP tool calls | Variable | Minimize round-trips |\n| Model selection | 3-10x difference | Use haiku for simple tasks |\n\n### Token Budget by Task Type\n\n| Task | Typical Cost | Budget Alert |\n|------|-------------|-------------|\n| Bug fix | $0.10-0.50 | $1.00 |\n| Feature (small) | $0.50-2.00 | $3.00 |\n| Feature (large) | $2.00-8.00 | $10.00 |\n| Refactor | $1.00-5.00 | $7.00 |\n| Code review | $0.20-1.00 | $2.00 |\n\n### Tool-Call Budgets\n\nSet explicit budgets by task complexity:\n\n| Task Type | Tool-Call Budget | Wrap-Up At |\n|-----------|-----------------|------------|\n| Quick fix / lookup | 20 calls | 15 |\n| Bug fix | 30 calls | 25 |\n| Feature (small) | 50 calls | 40 |\n| Feature (large) | 80 calls | 65 |\n| Refactor | 50 calls | 40 |\n\nAt the wrap-up threshold: commit progress, assess remaining work, decide whether to continue or start fresh.\n\n### Optimization Strategies\n\n1. **Scope prompts tightly** — \"Fix the auth bug in src/auth/login.ts\" vs \"Fix the auth bug\"\n2. **Use the right model** — Haiku for simple lookups, Sonnet for features, Opus for architecture\n3. **Delegate to subagents** — Search/explore operations in subagents keep main context lean\n4. **Compact proactively** — Don't wait for auto-compact; compact at task boundaries\n5. **Read selectively** — Use `offset` and `limit` params for large files\n6. **Batch operations** — Multiple independent tool calls in one message\n7. **One-pass discipline** — Write complete solution, test once, stop if green\n8. **No re-reads** — Don't re-read unchanged files; trust cached knowledge\n9. **Read before write** — Never write a file without reading it first\n10. **Kill output bloat** — No sycophantic openers, no closing fluff, no prompt restatement\n\n## Budget Alerts\n\nSet mental checkpoints:\n- **50% budget** — Are you on track? Should you compact?\n- **80% budget** — Wrap up current task, avoid new exploration\n- **100% budget** — Commit what you have, start fresh session\n\n## Output\n\n```text\nCOST TRACKER\n Session cost: $X.XX\n Token usage: [input]K in / [output]K out\n Cache hit rate: ~XX%\n\n Top cost drivers:\n 1. [operation] — $X.XX\n 2. [operation] — $X.XX\n\n Optimization tips:\n - [specific suggestion]\n```\n\n## Rules\n\n- Track costs as awareness, not hard limits\n- Never sacrifice code quality to save tokens\n- Compact at task boundaries, not mid-task\n- Use subagents for exploration-heavy work","createdAt":"2026-09-25T11:52:09.831Z","updatedAt":"2026-09-25T11:52:09.831Z"},{"id":"cmugwi2k601p5qu06ftzthdoi","slug":"rohitg00-pro-workflow-design-engineering","name":"design-engineering","description":"Apply interface craft when building or reviewing UI - motion, easing, timing, springs, component feel, and visual foundations. Use when building a component, animation, transition, hover or press state, modal, drawer, toast, or when polishing an interface so it feels right. Says \"make this feel better\", \"add an animation\", \"polish the UI\", \"review this component\".","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"design-engineering","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Apply interface craft when building or reviewing UI - motion, easing, timing, springs, component feel, and visual foundations. Use when building a component, animation, transition, hover or press state, modal, drawer, toast, or when polishing an interface so it feels right. Says \"make this feel better\", \"add an animation\", \"polish the UI\", \"review this component\".","permissions":[],"systemPrompt":"# design-engineering\n\nIn a world where most software works well enough, feel is the differentiator.\nMost of what makes an interface feel right is detail the user never\nconsciously notices - the aggregate of small correct choices. Build for that\naggregate.\n\n## Motion decision framework\n\nAnswer these in order before writing any animation.\n\n### 1. Should it animate at all?\n\nThe deciding factor is frequency. The more often a user sees it, the less it\nshould move.\n\n| How often the user sees it | Decision |\n|----------------------------|----------|\n| 100+ times/day (shortcuts, command palette) | No animation, ever |\n| Tens of times/day (hover, list nav) | Remove or drastically reduce |\n| Occasional (modals, drawers, toasts) | Standard animation |\n| Rare or first-time (onboarding, celebration) | Room for delight |\n\nNever animate a keyboard-initiated action. It repeats all day; animation makes\nit feel slow and disconnected from the keypress.\n\n### 2. What is the purpose?\n\nEvery animation needs an answer to \"why does this move?\" Valid ones: spatial\nconsistency (enters and exits the same edge), state change, feedback (a press\nthat confirms the interface heard you), or preventing a jarring appear/disappear.\n\"It looks cool\" is not a purpose for anything the user sees often.\n\n### 3. What easing?\n\n- Entering or exiting -> `ease-out` (fast start, feels responsive).\n- Moving or morphing on screen -> `ease-in-out`.\n- Hover or color change -> `ease`.\n- Constant motion (marquee, progress) -> `linear`.\n\nNever use `ease-in` for UI. It delays the first moment of movement - exactly\nwhen the user is watching - so a 300ms `ease-in` dropdown feels slower than a\n300ms `ease-out` one. The built-in curves are weak; use stronger custom ones:\n\n```css\n--ease-out: cubic-bezier(0.23, 1, 0.32, 1); /* UI interactions */\n--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1); /* on-screen movement */\n--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1); /* iOS-like drawer */\n```\n\n### 4. How fast?\n\n| Element | Duration |\n|---------|----------|\n| Button press feedback | 100-160ms |\n| Tooltip, small popover | 125-200ms |\n| Dropdown, select | 150-250ms |\n| Modal, drawer | 200-500ms |\n\nKeep frequent, interactive UI under 300ms; the modal and drawer range above (up to 500ms) is the deliberate exception for occasional, first-time surfaces. Perceived speed is real: a faster spinner makes\na load feel faster at the same load time, and an instant tooltip after the first\none makes a whole toolbar feel quick.\n\n## Springs\n\nSprings settle on physics, not a fixed duration, so they feel alive and, unlike\nCSS keyframes, keep their velocity when interrupted. Reach for them on drag and\ngesture interactions the user can reverse mid-motion, and on decorative,\nmouse-tracked motion. Keep bounce subtle (0.1 to 0.3) and usually absent - save\nit for drag-to-dismiss and playful moments, not functional UI.\n\n## Component feel\n\n- **Press feedback.** Any pressable element gets `transform: scale(0.97)` on\n `:active` with a ~160ms `ease-out` transition. Subtle (0.95 to 0.98); it makes\n the interface feel like it is listening.\n- **Never animate from `scale(0)`.** Nothing real appears from nothing. Start at\n `scale(0.9)` or higher plus opacity so the entrance has shape.\n- **Scale from the trigger.** Popovers and dropdowns scale from their origin, not\n their center. Modals stay centered.\n- **Respect `prefers-reduced-motion`.** Drop or shorten non-essential motion.\n\n## Visual foundations\n\n- One spacing scale, one type scale. Consistency reads as intent; ad-hoc values\n read as noise.\n- Restrained color: a small palette with clear roles beats many accents.\n- Make every interactive state explicit - hover, active, focus-visible, disabled.\n A control with no states feels dead.\n\n## Review format\n\nWhen reviewing UI code, output a single markdown table, one row per issue, with\n`Before | After | Why`. Do not use separate \"Before:\" / \"After:\" lines.\n\n| Before | After | Why |\n|--------|-------|-----|\n| `transition: all 300ms` | `transition: transform 200ms ease-out` | Name exact properties; avoid `all` |\n| `transform: scale(0)` | `scale(0.95); opacity: 0` | Nothing appears from nothing |\n| `ease-in` on a dropdown | strong `ease-out` | `ease-in` reads as sluggish |\n| no `:active` state | `scale(0.97)` on `:active` | Presses must feel responsive |","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/design-engineering","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/design-engineering/SKILL.md","defaultBranch":"main"},"readme":"# design-engineering\n\nIn a world where most software works well enough, feel is the differentiator.\nMost of what makes an interface feel right is detail the user never\nconsciously notices - the aggregate of small correct choices. Build for that\naggregate.\n\n## Motion decision framework\n\nAnswer these in order before writing any animation.\n\n### 1. Should it animate at all?\n\nThe deciding factor is frequency. The more often a user sees it, the less it\nshould move.\n\n| How often the user sees it | Decision |\n|----------------------------|----------|\n| 100+ times/day (shortcuts, command palette) | No animation, ever |\n| Tens of times/day (hover, list nav) | Remove or drastically reduce |\n| Occasional (modals, drawers, toasts) | Standard animation |\n| Rare or first-time (onboarding, celebration) | Room for delight |\n\nNever animate a keyboard-initiated action. It repeats all day; animation makes\nit feel slow and disconnected from the keypress.\n\n### 2. What is the purpose?\n\nEvery animation needs an answer to \"why does this move?\" Valid ones: spatial\nconsistency (enters and exits the same edge), state change, feedback (a press\nthat confirms the interface heard you), or preventing a jarring appear/disappear.\n\"It looks cool\" is not a purpose for anything the user sees often.\n\n### 3. What easing?\n\n- Entering or exiting -> `ease-out` (fast start, feels responsive).\n- Moving or morphing on screen -> `ease-in-out`.\n- Hover or color change -> `ease`.\n- Constant motion (marquee, progress) -> `linear`.\n\nNever use `ease-in` for UI. It delays the first moment of movement - exactly\nwhen the user is watching - so a 300ms `ease-in` dropdown feels slower than a\n300ms `ease-out` one. The built-in curves are weak; use stronger custom ones:\n\n```css\n--ease-out: cubic-bezier(0.23, 1, 0.32, 1); /* UI interactions */\n--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1); /* on-screen movement */\n--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1); /* iOS-like drawer */\n```\n\n### 4. How fast?\n\n| Element | Duration |\n|---------|----------|\n| Button press feedback | 100-160ms |\n| Tooltip, small popover | 125-200ms |\n| Dropdown, select | 150-250ms |\n| Modal, drawer | 200-500ms |\n\nKeep frequent, interactive UI under 300ms; the modal and drawer range above (up to 500ms) is the deliberate exception for occasional, first-time surfaces. Perceived speed is real: a faster spinner makes\na load feel faster at the same load time, and an instant tooltip after the first\none makes a whole toolbar feel quick.\n\n## Springs\n\nSprings settle on physics, not a fixed duration, so they feel alive and, unlike\nCSS keyframes, keep their velocity when interrupted. Reach for them on drag and\ngesture interactions the user can reverse mid-motion, and on decorative,\nmouse-tracked motion. Keep bounce subtle (0.1 to 0.3) and usually absent - save\nit for drag-to-dismiss and playful moments, not functional UI.\n\n## Component feel\n\n- **Press feedback.** Any pressable element gets `transform: scale(0.97)` on\n `:active` with a ~160ms `ease-out` transition. Subtle (0.95 to 0.98); it makes\n the interface feel like it is listening.\n- **Never animate from `scale(0)`.** Nothing real appears from nothing. Start at\n `scale(0.9)` or higher plus opacity so the entrance has shape.\n- **Scale from the trigger.** Popovers and dropdowns scale from their origin, not\n their center. Modals stay centered.\n- **Respect `prefers-reduced-motion`.** Drop or shorten non-essential motion.\n\n## Visual foundations\n\n- One spacing scale, one type scale. Consistency reads as intent; ad-hoc values\n read as noise.\n- Restrained color: a small palette with clear roles beats many accents.\n- Make every interactive state explicit - hover, active, focus-visible, disabled.\n A control with no states feels dead.\n\n## Review format\n\nWhen reviewing UI code, output a single markdown table, one row per issue, with\n`Before | After | Why`. Do not use separate \"Before:\" / \"After:\" lines.\n\n| Before | After | Why |\n|--------|-------|-----|\n| `transi","createdAt":"2026-09-25T11:52:09.846Z","updatedAt":"2026-09-25T11:52:09.846Z"},{"id":"cmugwi2kj01p8qu061c7pu37j","slug":"rohitg00-pro-workflow-deslop","name":"deslop","description":"Remove AI-generated code slop, unnecessary comments, and over-engineering from the current branch diff. Cleans up boilerplate, simplifies abstractions, strips defensive code, and in skill-file mode lints SKILL.md files for quality. Use when cleaning up code, simplifying, removing boilerplate, before committing, or when reviewing a skill before promoting it.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"deslop","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Remove AI-generated code slop, unnecessary comments, and over-engineering from the current branch diff. Cleans up boilerplate, simplifies abstractions, strips defensive code, and in skill-file mode lints SKILL.md files for quality. Use when cleaning up code, simplifying, removing boilerplate, before committing, or when reviewing a skill before promoting it.","permissions":[],"systemPrompt":"# Remove AI Code Slop\n\nCheck the diff against main and remove AI-generated slop introduced in the branch.\n\n## Trigger\n\nUse after completing changes, before committing, or when code feels over-engineered.\n\n## Commands\n\n```bash\ngit fetch origin main\ngit diff origin/main...HEAD --stat\ngit diff origin/main...HEAD\n```\n\n## Workflow\n\n1. Run diff commands to see all changes on the branch.\n2. Identify slop patterns from the focus areas below.\n3. Apply minimal, focused edits to remove slop.\n4. Re-run `git diff origin/main...HEAD` to verify only slop was removed.\n5. Run tests or type-check to confirm behaviour unchanged: `npm test -- --changed --passWithNoTests 2>&1 | tail -10`\n6. Summarise what was cleaned.\n\n## Focus Areas\n\n- Extra comments that state the obvious or are inconsistent with local style\n- Defensive try/catch blocks that are abnormal for trusted internal code paths\n- Casts to `any` used only to bypass type issues\n- Over-engineered abstractions for one-time operations (premature helpers, factories)\n- Deeply nested code that should be simplified with early returns\n- Backwards-compatibility hacks (renamed `_vars`, re-exports, `// removed` comments)\n- Features, refactoring, or \"improvements\" beyond what was requested\n- Added docstrings, type annotations, or comments on code that wasn't changed\n- Error handling for scenarios that can't happen in trusted internal paths\n\n## Guardrails\n\n- Keep behavior unchanged unless fixing a clear bug.\n- Prefer minimal, focused edits over broad rewrites.\n- Three similar lines of code is better than a premature abstraction.\n- If you remove something, verify it's truly unused first.\n- Keep the final summary concise (1-3 sentences).\n\n## Skill-file mode\n\nWhen the target is a `SKILL.md` (not a code diff), lint it against the same\nslop instinct applied to prose. Run this before promoting a skill. Flag:\n\n- **Stale lines** - guidance written for an old version of the skill that no\n longer matches what it does. Cut it.\n- **Bloat** - the skill runs past one screen with detail that belongs in a\n linked reference. Push it down: in-skill step, then in-skill reference, then\n an external file behind a pointer.\n- **Dead sentences** - a line that changes nothing if deleted. Delete it.\n- **Duplication** - the same instruction stated in two places, so edits drift.\n Keep one source of truth.\n- **Premature stop** - the method ends before the work does (asks the question\n but never records the answer, cleans but never verifies).\n- **Weak anchor** - no single concept the skill turns on. A skill the reader\n can name in one word triggers and executes in fewer tokens.\n- **Missing invocation intent** - no declared human-run vs auto-triggered mode.\n See [`rules/skill-conventions.mdc`](../../rules/skill-conventions.mdc).\n- **Wrong write op** - a state-changing skill that does not say whether it\n adds, updates, or appends, or that duplicates its output on a second run.\n\n**Skill-file mode output:** the flagged issues by line, the edits applied,\nthe cleanup summary, and whether the skill is ready to promote.\n\n## Output (code mode)\n\n- List of slop patterns found with file locations\n- Edits applied\n- One-line summary of what was cleaned","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/deslop","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/deslop/SKILL.md","defaultBranch":"main"},"readme":"# Remove AI Code Slop\n\nCheck the diff against main and remove AI-generated slop introduced in the branch.\n\n## Trigger\n\nUse after completing changes, before committing, or when code feels over-engineered.\n\n## Commands\n\n```bash\ngit fetch origin main\ngit diff origin/main...HEAD --stat\ngit diff origin/main...HEAD\n```\n\n## Workflow\n\n1. Run diff commands to see all changes on the branch.\n2. Identify slop patterns from the focus areas below.\n3. Apply minimal, focused edits to remove slop.\n4. Re-run `git diff origin/main...HEAD` to verify only slop was removed.\n5. Run tests or type-check to confirm behaviour unchanged: `npm test -- --changed --passWithNoTests 2>&1 | tail -10`\n6. Summarise what was cleaned.\n\n## Focus Areas\n\n- Extra comments that state the obvious or are inconsistent with local style\n- Defensive try/catch blocks that are abnormal for trusted internal code paths\n- Casts to `any` used only to bypass type issues\n- Over-engineered abstractions for one-time operations (premature helpers, factories)\n- Deeply nested code that should be simplified with early returns\n- Backwards-compatibility hacks (renamed `_vars`, re-exports, `// removed` comments)\n- Features, refactoring, or \"improvements\" beyond what was requested\n- Added docstrings, type annotations, or comments on code that wasn't changed\n- Error handling for scenarios that can't happen in trusted internal paths\n\n## Guardrails\n\n- Keep behavior unchanged unless fixing a clear bug.\n- Prefer minimal, focused edits over broad rewrites.\n- Three similar lines of code is better than a premature abstraction.\n- If you remove something, verify it's truly unused first.\n- Keep the final summary concise (1-3 sentences).\n\n## Skill-file mode\n\nWhen the target is a `SKILL.md` (not a code diff), lint it against the same\nslop instinct applied to prose. Run this before promoting a skill. Flag:\n\n- **Stale lines** - guidance written for an old version of the skill that no\n longer matches what it does. Cut it.\n- **Bloat** - the skill runs past one screen with detail that belongs in a\n linked reference. Push it down: in-skill step, then in-skill reference, then\n an external file behind a pointer.\n- **Dead sentences** - a line that changes nothing if deleted. Delete it.\n- **Duplication** - the same instruction stated in two places, so edits drift.\n Keep one source of truth.\n- **Premature stop** - the method ends before the work does (asks the question\n but never records the answer, cleans but never verifies).\n- **Weak anchor** - no single concept the skill turns on. A skill the reader\n can name in one word triggers and executes in fewer tokens.\n- **Missing invocation intent** - no declared human-run vs auto-triggered mode.\n See [`rules/skill-conventions.mdc`](../../rules/skill-conventions.mdc).\n- **Wrong write op** - a state-changing skill that does not say whether it\n adds, updates, or appends, or that duplicates its output on a second run.\n\n**Skill-file mode output:** the flagged issues by line, the edits applied,\nthe cleanup summary, and whether the skill is ready to promote.\n\n## Output (code mode)\n\n- List of slop patterns found with file locations\n- Edits applied\n- One-line summary of what was cleaned","createdAt":"2026-09-25T11:52:09.859Z","updatedAt":"2026-09-25T11:52:09.859Z"},{"id":"cmugwi2kv01pbqu066yf4eu0c","slug":"rohitg00-pro-workflow-domain-modeling","name":"domain-modeling","description":"Build the project's shared language and bounded contexts before writing code, so names stay consistent and the agent stops paraphrasing domain concepts. Produces a CONTEXT.md glossary and decision records. Use at the start of a project or feature, or when the codebase and the people describing it speak different languages.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"domain-modeling","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Build the project's shared language and bounded contexts before writing code, so names stay consistent and the agent stops paraphrasing domain concepts. Produces a CONTEXT.md glossary and decision records. Use at the start of a project or feature, or when the codebase and the people describing it speak different languages.","permissions":[],"systemPrompt":"# domain-modeling\n\nMost misbuilds start as a language gap: the agent is dropped into a project\nand left to infer the jargon, so it uses twenty words where the domain has\none. A shared language closes the gap. When code, conversation, and the model\nall draw from the same vocabulary, names line up, navigation gets cheaper, and\nthe model spends fewer tokens reasoning because it has a tighter language to\nreason in.\n\n## Method\n\n1. **Harvest the terms.** From the request, the codebase, and the user's own\n words, list the nouns and verbs that carry domain meaning - the concepts a\n newcomer would have to ask about. Prefer the user's word over a synonym you\n like better.\n2. **Pin each one.** Write a one-line definition in the project's own language,\n not a dictionary definition. If two terms blur together, force the\n distinction or collapse them - ambiguity here becomes inconsistent names in\n code.\n3. **Draw the boundaries.** Where the same word means different things in\n different parts of the system, that is a boundary. Name each context and\n note which terms belong to it. A term that means two things is two terms.\n4. **Record the hard calls.** When a modeling choice was contested or will be\n questioned later, write a short decision record: context, choice,\n alternatives rejected, why.\n\n## Outputs\n\n- **`CONTEXT.md`** - the shared-language glossary. One term per line:\n `term - what it means in this project`. Grouped by bounded context when\n there is more than one. Point every future session at this file. On re-run,\n add new terms and update definitions that changed; do not rewrite the file\n wholesale.\n- **Bounded-context sketch** - the contexts and which terms live in each,\n short enough to read in fifteen seconds.\n- **Decision records** in `docs/decisions/NNNN-slug.md` for the contested\n modeling calls only. Read the directory first and number from the highest\n existing record so two records never collide. Skip the obvious ones.\n\n## Guardrails\n\n- The glossary is for the model as much as the human - write it to be loaded,\n not framed on a wall.\n- Do not invent terms the project does not use. Reflect the domain; do not\n rename it.\n- Keep it small and current. A glossary that lists everything and updates\n nothing is worse than none. Prune terms that fall out of use.\n\n## Where it fits\n\nRun this before `plan-interrogate` on a new area, or let `plan-interrogate`\ncall back here when it hits terms it cannot pin. The `CONTEXT.md` this produces\nis the same file `plan-interrogate` emits - one shared-language artifact, two\nways in.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/domain-modeling","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/domain-modeling/SKILL.md","defaultBranch":"main"},"readme":"# domain-modeling\n\nMost misbuilds start as a language gap: the agent is dropped into a project\nand left to infer the jargon, so it uses twenty words where the domain has\none. A shared language closes the gap. When code, conversation, and the model\nall draw from the same vocabulary, names line up, navigation gets cheaper, and\nthe model spends fewer tokens reasoning because it has a tighter language to\nreason in.\n\n## Method\n\n1. **Harvest the terms.** From the request, the codebase, and the user's own\n words, list the nouns and verbs that carry domain meaning - the concepts a\n newcomer would have to ask about. Prefer the user's word over a synonym you\n like better.\n2. **Pin each one.** Write a one-line definition in the project's own language,\n not a dictionary definition. If two terms blur together, force the\n distinction or collapse them - ambiguity here becomes inconsistent names in\n code.\n3. **Draw the boundaries.** Where the same word means different things in\n different parts of the system, that is a boundary. Name each context and\n note which terms belong to it. A term that means two things is two terms.\n4. **Record the hard calls.** When a modeling choice was contested or will be\n questioned later, write a short decision record: context, choice,\n alternatives rejected, why.\n\n## Outputs\n\n- **`CONTEXT.md`** - the shared-language glossary. One term per line:\n `term - what it means in this project`. Grouped by bounded context when\n there is more than one. Point every future session at this file. On re-run,\n add new terms and update definitions that changed; do not rewrite the file\n wholesale.\n- **Bounded-context sketch** - the contexts and which terms live in each,\n short enough to read in fifteen seconds.\n- **Decision records** in `docs/decisions/NNNN-slug.md` for the contested\n modeling calls only. Read the directory first and number from the highest\n existing record so two records never collide. Skip the obvious ones.\n\n## Guardrails\n\n- The glossary is for the model as much as the human - write it to be loaded,\n not framed on a wall.\n- Do not invent terms the project does not use. Reflect the domain; do not\n rename it.\n- Keep it small and current. A glossary that lists everything and updates\n nothing is worse than none. Prune terms that fall out of use.\n\n## Where it fits\n\nRun this before `plan-interrogate` on a new area, or let `plan-interrogate`\ncall back here when it hits terms it cannot pin. The `CONTEXT.md` this produces\nis the same file `plan-interrogate` emits - one shared-language artifact, two\nways in.","createdAt":"2026-09-25T11:52:09.872Z","updatedAt":"2026-09-25T11:52:09.872Z"},{"id":"cmugwi2l601pequ062g13dgu9","slug":"rohitg00-pro-workflow-file-watcher","name":"file-watcher","description":"Configure file watching hooks to auto-react to config changes, env file updates, and dependency modifications. Use to set up reactive workflows.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"file-watcher","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Configure file watching hooks to auto-react to config changes, env file updates, and dependency modifications. Use to set up reactive workflows.","permissions":[],"systemPrompt":"# File Watcher\n\nUse Claude Code's `FileChanged` and `CwdChanged` hooks to create reactive workflows that respond to file system changes.\n\n## Trigger\n\nUse when:\n- Setting up auto-reload for config changes\n- Watching for dependency updates\n- Monitoring build output\n- Creating reactive development workflows\n\n## How File Watching Works\n\nClaude Code's `SessionStart` and `CwdChanged` hooks support returning `watchPaths` to register file watchers. The current `cwd-changed.js` script focuses on env injection; to add watch registration, your hook script must output this JSON structure:\n\n```json\n{\n \"hookSpecificOutput\": {\n \"hookEventName\": \"SessionStart\",\n \"watchPaths\": [\n \"/absolute/path/to/.env\",\n \"/absolute/path/to/package.json\"\n ]\n }\n}\n```\n\nWhen watched files change, the `FileChanged` hook fires with:\n```json\n{\n \"hook_event_name\": \"FileChanged\",\n \"file_path\": \"/path/to/changed/file\",\n \"event\": \"change\"\n}\n```\n\n## Environment Injection\n\n`CwdChanged` and `FileChanged` hooks can write to `CLAUDE_ENV_FILE` to inject environment variables into subsequent Bash commands:\n\n```bash\necho \"export PROJECT_TYPE=node\" >> \"$CLAUDE_ENV_FILE\"\necho \"export TEST_CMD='npm test'\" >> \"$CLAUDE_ENV_FILE\"\n```\n\n## Common Watch Patterns\n\n### Watch .env for Changes\n```javascript\nconst envFile = path.join(projectRoot, '.env');\nif (fs.existsSync(envFile)) {\n output.hookSpecificOutput = {\n hookEventName: 'SessionStart',\n watchPaths: [envFile]\n };\n}\n```\n\n### Watch package.json for Dependency Changes\nDetect when dependencies change and remind to run `npm install`.\n\n### Watch tsconfig.json for Config Changes\nRemind to restart TypeScript checks when config changes.\n\n## Setup\n\nAdd to hooks.json:\n```json\n{\n \"FileChanged\": [{\n \"matcher\": \".env|package.json|tsconfig.json\",\n \"hooks\": [{\n \"type\": \"command\",\n \"command\": \"node scripts/file-changed.js\"\n }]\n }]\n}\n```\n\n## Rules\n\n- Use absolute paths for watchPaths (required by Claude Code)\n- Matcher uses pipe-separated filenames\n- Watcher uses 500ms stability threshold and 200ms poll interval\n- Keep file-changed handlers fast (<5s) to avoid blocking\n- Use `CLAUDE_ENV_FILE` for injecting env vars, not direct export","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/file-watcher","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/file-watcher/SKILL.md","defaultBranch":"main"},"readme":"# File Watcher\n\nUse Claude Code's `FileChanged` and `CwdChanged` hooks to create reactive workflows that respond to file system changes.\n\n## Trigger\n\nUse when:\n- Setting up auto-reload for config changes\n- Watching for dependency updates\n- Monitoring build output\n- Creating reactive development workflows\n\n## How File Watching Works\n\nClaude Code's `SessionStart` and `CwdChanged` hooks support returning `watchPaths` to register file watchers. The current `cwd-changed.js` script focuses on env injection; to add watch registration, your hook script must output this JSON structure:\n\n```json\n{\n \"hookSpecificOutput\": {\n \"hookEventName\": \"SessionStart\",\n \"watchPaths\": [\n \"/absolute/path/to/.env\",\n \"/absolute/path/to/package.json\"\n ]\n }\n}\n```\n\nWhen watched files change, the `FileChanged` hook fires with:\n```json\n{\n \"hook_event_name\": \"FileChanged\",\n \"file_path\": \"/path/to/changed/file\",\n \"event\": \"change\"\n}\n```\n\n## Environment Injection\n\n`CwdChanged` and `FileChanged` hooks can write to `CLAUDE_ENV_FILE` to inject environment variables into subsequent Bash commands:\n\n```bash\necho \"export PROJECT_TYPE=node\" >> \"$CLAUDE_ENV_FILE\"\necho \"export TEST_CMD='npm test'\" >> \"$CLAUDE_ENV_FILE\"\n```\n\n## Common Watch Patterns\n\n### Watch .env for Changes\n```javascript\nconst envFile = path.join(projectRoot, '.env');\nif (fs.existsSync(envFile)) {\n output.hookSpecificOutput = {\n hookEventName: 'SessionStart',\n watchPaths: [envFile]\n };\n}\n```\n\n### Watch package.json for Dependency Changes\nDetect when dependencies change and remind to run `npm install`.\n\n### Watch tsconfig.json for Config Changes\nRemind to restart TypeScript checks when config changes.\n\n## Setup\n\nAdd to hooks.json:\n```json\n{\n \"FileChanged\": [{\n \"matcher\": \".env|package.json|tsconfig.json\",\n \"hooks\": [{\n \"type\": \"command\",\n \"command\": \"node scripts/file-changed.js\"\n }]\n }]\n}\n```\n\n## Rules\n\n- Use absolute paths for watchPaths (required by Claude Code)\n- Matcher uses pipe-separated filenames\n- Watcher uses 500ms stability threshold and 200ms poll interval\n- Keep file-changed handlers fast (<5s) to avoid blocking\n- Use `CLAUDE_ENV_FILE` for injecting env vars, not direct export","createdAt":"2026-09-25T11:52:09.882Z","updatedAt":"2026-09-25T11:52:09.882Z"},{"id":"cmugwi2li01phqu061y1rbvsy","slug":"rohitg00-pro-workflow-improve-architecture","name":"improve-architecture","description":"Audit an area of the codebase and propose the smallest structural moves that improve it - untangle boundaries, kill duplication, fix seams, break cycles. Produces a prioritized plan and decision records, not a rewrite. Use when a codebase feels tangled, hard to change, or is becoming a ball of mud, or when asked to improve or refactor architecture.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"improve-architecture","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Audit an area of the codebase and propose the smallest structural moves that improve it - untangle boundaries, kill duplication, fix seams, break cycles. Produces a prioritized plan and decision records, not a rewrite. Use when a codebase feels tangled, hard to change, or is becoming a ball of mud, or when asked to improve or refactor architecture.","permissions":[],"systemPrompt":"# improve-architecture\n\nInvest in the shape of the system a little at a time rather than paying for a\nrewrite later. This skill diagnoses and proposes; it does not rewrite on its own.\n\n## Method\n\n1. **Map first.** Get the current shape before judging it - entry points,\n modules, data flow, who calls whom. Reuse `module-map` for the one-screen\n view; do not skip to opinions.\n2. **Find the strain.** Look for the load-bearing problems, not style nits:\n - God modules that everything imports and nothing can change safely.\n - Leaky boundaries - a module reaching into another's internals instead of\n its surface.\n - Duplicated logic that drifts (the same rule implemented three ways).\n - Wrong seams - the code is split where it does not bend and fused where it\n does.\n - Cyclic dependencies.\n - A shape that fights the domain (see `domain-modeling` - boundaries in code\n should track boundaries in the language).\n3. **Propose the smallest move.** For each problem, the least change that\n relieves it: extract a boundary, collapse a duplicate, invert a dependency,\n move a seam. Prefer a sequence of safe steps over one big cut.\n4. **Rank by leverage.** Order the moves by pain relieved over effort. Say which\n are safe now and which need a test net first (pair with `tdd`).\n5. **Record the big calls.** For a structural change a future reader would\n question, write a decision record in `docs/decisions/NNNN-slug.md`: context,\n choice, alternatives rejected, why.\n\n## Guardrails\n\n- Diagnose, do not rewrite. The deliverable is a plan the user approves before\n any code moves.\n- No churn for taste. A move must relieve a named strain; \"cleaner\" is not a\n reason.\n- Three similar lines beat a premature abstraction - do not trade duplication\n for indirection unless the duplication actually drifts.\n- Keep behavior fixed. Structural moves are refactors; land them behind green\n tests.\n\n## Output\n\nA prioritized list: each item is the problem, the smallest move, the risk, and\nwhether it needs a test net first. Plus decision records for the big moves. No\ncode changes until the user picks what to do.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/improve-architecture","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/improve-architecture/SKILL.md","defaultBranch":"main"},"readme":"# improve-architecture\n\nInvest in the shape of the system a little at a time rather than paying for a\nrewrite later. This skill diagnoses and proposes; it does not rewrite on its own.\n\n## Method\n\n1. **Map first.** Get the current shape before judging it - entry points,\n modules, data flow, who calls whom. Reuse `module-map` for the one-screen\n view; do not skip to opinions.\n2. **Find the strain.** Look for the load-bearing problems, not style nits:\n - God modules that everything imports and nothing can change safely.\n - Leaky boundaries - a module reaching into another's internals instead of\n its surface.\n - Duplicated logic that drifts (the same rule implemented three ways).\n - Wrong seams - the code is split where it does not bend and fused where it\n does.\n - Cyclic dependencies.\n - A shape that fights the domain (see `domain-modeling` - boundaries in code\n should track boundaries in the language).\n3. **Propose the smallest move.** For each problem, the least change that\n relieves it: extract a boundary, collapse a duplicate, invert a dependency,\n move a seam. Prefer a sequence of safe steps over one big cut.\n4. **Rank by leverage.** Order the moves by pain relieved over effort. Say which\n are safe now and which need a test net first (pair with `tdd`).\n5. **Record the big calls.** For a structural change a future reader would\n question, write a decision record in `docs/decisions/NNNN-slug.md`: context,\n choice, alternatives rejected, why.\n\n## Guardrails\n\n- Diagnose, do not rewrite. The deliverable is a plan the user approves before\n any code moves.\n- No churn for taste. A move must relieve a named strain; \"cleaner\" is not a\n reason.\n- Three similar lines beat a premature abstraction - do not trade duplication\n for indirection unless the duplication actually drifts.\n- Keep behavior fixed. Structural moves are refactors; land them behind green\n tests.\n\n## Output\n\nA prioritized list: each item is the problem, the smallest move, the risk, and\nwhether it needs a test net first. Plus decision records for the big moves. No\ncode changes until the user picks what to do.","createdAt":"2026-09-25T11:52:09.895Z","updatedAt":"2026-09-25T11:52:09.895Z"},{"id":"cmugwi2lu01pkqu06syq7oou1","slug":"rohitg00-pro-workflow-insights","name":"insights","description":"Show session analytics, learning patterns, correction trends, heatmaps, and productivity metrics. Computes stats from project memory and session history. Use when asking for stats, statistics, progress, how am I doing, coding history, or dashboard.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"insights","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Show session analytics, learning patterns, correction trends, heatmaps, and productivity metrics. Computes stats from project memory and session history. Use when asking for stats, statistics, progress, how am I doing, coding history, or dashboard.","permissions":[],"systemPrompt":"# Session Insights\n\nSurface patterns from learnings and session history.\n\n## Trigger\n\nUse when asking \"show stats\", \"how am I doing\", \"analytics\", \"insights\", \"heatmap\", or \"correction rate\".\n\n## Data Sources\n\nGather data from these locations before computing metrics:\n\n```bash\n# Session history and learnings\ncat .claude/LEARNED.md 2>/dev/null || cat CLAUDE.md | grep -A999 \"LEARNED\"\ncat .claude/learning-log.md 2>/dev/null\n\n# Session activity\ngit log --oneline --since=\"today\" --author=\"$(git config user.name)\"\ngit diff --stat\n```\n\nA **correction** is any instance where the user redirected, fixed, or overrode agent output during a session. Count `[LEARN]` entries and explicit correction markers in session history.\n\n## What It Shows\n\n### Session Summary\n\n```\nSession Insights\n Duration: 47 min\n Edits: 23 files modified\n Corrections: 2 self-corrections applied\n Learnings: 3 new patterns captured\n Context: 62% used (safe)\n```\n\n### Learning Analytics\n\n```\nLearning Insights (42 total)\n\nTop categories:\n Testing 12 learnings (29%)\n Navigation 8 learnings (19%)\n Git 7 learnings (17%)\n Quality 6 learnings (14%)\n\nMost applied:\n #12 [Testing] Run tests before commit — 15 times\n #8 [Navigation] Confirm path for common names — 11 times\n\nStale learnings (never applied):\n #15 [Editing] Prefer named exports — 0 times (45 days old)\n```\n\n### Correction Heatmap\n\n```\nCorrection Heatmap\n\nBy category (all time):\n ████████████ Testing 34 corrections\n ████████ Navigation 22 corrections\n ██████ Git 18 corrections\n ████ Quality 12 corrections\n\nHot learnings (most corrected, least learned):\n - [Testing] Mock external deps — corrected 8x, learned 0x\n → Consider: /learn-rule to capture this permanently\n\nCold learnings (learned but never applied):\n - [Editing] Use named exports — learned 45 days ago, applied 0x\n → Consider removing if no longer relevant\n```\n\n### Productivity Metrics\n\n```\nProductivity (last 10 sessions)\n Avg session: 35 min\n Avg edits/session: 18\n Correction rate: 12% (improving)\n Learning capture: 2.1 per session\n```\n\n## Guardrails\n\n- Use actual data from project memory and session history.\n- Surface actionable suggestions, not just numbers.\n- Flag recurring corrections that should become permanent rules.\n- Identify stale learnings that may no longer be relevant.\n\n## Output\n\nFormatted analytics report with:\n- Current session stats\n- Category breakdown\n- Most/least applied learnings\n- Correction trends with suggestions\n- Productivity metrics over time","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/insights","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/insights/SKILL.md","defaultBranch":"main"},"readme":"# Session Insights\n\nSurface patterns from learnings and session history.\n\n## Trigger\n\nUse when asking \"show stats\", \"how am I doing\", \"analytics\", \"insights\", \"heatmap\", or \"correction rate\".\n\n## Data Sources\n\nGather data from these locations before computing metrics:\n\n```bash\n# Session history and learnings\ncat .claude/LEARNED.md 2>/dev/null || cat CLAUDE.md | grep -A999 \"LEARNED\"\ncat .claude/learning-log.md 2>/dev/null\n\n# Session activity\ngit log --oneline --since=\"today\" --author=\"$(git config user.name)\"\ngit diff --stat\n```\n\nA **correction** is any instance where the user redirected, fixed, or overrode agent output during a session. Count `[LEARN]` entries and explicit correction markers in session history.\n\n## What It Shows\n\n### Session Summary\n\n```\nSession Insights\n Duration: 47 min\n Edits: 23 files modified\n Corrections: 2 self-corrections applied\n Learnings: 3 new patterns captured\n Context: 62% used (safe)\n```\n\n### Learning Analytics\n\n```\nLearning Insights (42 total)\n\nTop categories:\n Testing 12 learnings (29%)\n Navigation 8 learnings (19%)\n Git 7 learnings (17%)\n Quality 6 learnings (14%)\n\nMost applied:\n #12 [Testing] Run tests before commit — 15 times\n #8 [Navigation] Confirm path for common names — 11 times\n\nStale learnings (never applied):\n #15 [Editing] Prefer named exports — 0 times (45 days old)\n```\n\n### Correction Heatmap\n\n```\nCorrection Heatmap\n\nBy category (all time):\n ████████████ Testing 34 corrections\n ████████ Navigation 22 corrections\n ██████ Git 18 corrections\n ████ Quality 12 corrections\n\nHot learnings (most corrected, least learned):\n - [Testing] Mock external deps — corrected 8x, learned 0x\n → Consider: /learn-rule to capture this permanently\n\nCold learnings (learned but never applied):\n - [Editing] Use named exports — learned 45 days ago, applied 0x\n → Consider removing if no longer relevant\n```\n\n### Productivity Metrics\n\n```\nProductivity (last 10 sessions)\n Avg session: 35 min\n Avg edits/session: 18\n Correction rate: 12% (improving)\n Learning capture: 2.1 per session\n```\n\n## Guardrails\n\n- Use actual data from project memory and session history.\n- Surface actionable suggestions, not just numbers.\n- Flag recurring corrections that should become permanent rules.\n- Identify stale learnings that may no longer be relevant.\n\n## Output\n\nFormatted analytics report with:\n- Current session stats\n- Category breakdown\n- Most/least applied learnings\n- Correction trends with suggestions\n- Productivity metrics over time","createdAt":"2026-09-25T11:52:09.906Z","updatedAt":"2026-09-25T11:52:09.906Z"},{"id":"cmugwi2m301pnqu0629zqo89z","slug":"rohitg00-pro-workflow-learn-rule","name":"learn-rule","description":"Capture a correction or lesson as a persistent learning rule with category, mistake, and correction. Stores, categorises, and retrieves rules for future sessions. Use after mistakes or when the user says \"remember this\", \"don't forget\", \"note this\", or \"learn from this\".","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"learn-rule","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Capture a correction or lesson as a persistent learning rule with category, mistake, and correction. Stores, categorises, and retrieves rules for future sessions. Use after mistakes or when the user says \"remember this\", \"don't forget\", \"note this\", or \"learn from this\".","permissions":[],"systemPrompt":"# Learn Rule\n\nCapture a lesson from the current session into permanent memory.\n\n## Trigger\n\nUse when the user says \"remember this\", \"add to rules\", \"don't do that again\", or after a mistake is identified.\n\n## Workflow\n\n1. Identify the lesson — what mistake was made? What should happen instead?\n2. Format the rule with full context.\n3. Propose the addition and wait for user approval.\n4. After approval, persist to LEARNED section or project memory.\n\n## Format\n\n```\n[LEARN] Category: One-line rule\nMistake: What went wrong\nCorrection: How it was fixed\n```\n\n### Wiki-scoped rules\n\nAppend `Wiki: ` to bind the rule to a single pro-workflow wiki. The rule loads only when that wiki is in scope, avoiding cross-project pollution:\n\n```\n[LEARN] Editing: Cite a sources.md row before adding any wiki claim.\nWiki: agent-memory\n```\n\nThe capture hook auto-detects `Wiki: ` and links the learning to that wiki via `learnings_wiki`.\n\n## Categories\n\n| Category | Examples |\n|----------|---------|\n| Navigation | File paths, finding code, wrong file edited |\n| Editing | Code changes, patterns, wrong approach |\n| Testing | Test approaches, coverage gaps, flaky tests |\n| Git | Commits, branches, merge issues |\n| Quality | Lint, types, style violations |\n| Context | When to clarify, missing requirements |\n| Architecture | Design decisions, wrong abstractions |\n| Performance | Optimization, O(n^2) loops, memory |\n\n## Example\n\n```\nRecent mistake: Edited wrong utils.ts file\n\n[LEARN] Navigation: Confirm full path when multiple files share a name.\n\nAdd to LEARNED section? (y/n)\n```\n\n## Guardrails\n\n- Always wait for user approval before persisting.\n- Keep rules to one line — specific and actionable.\n- Bad: \"Write good code\". Good: \"Always use snake_case for database columns\".\n- Include the mistake context so the rule makes sense later.\n\n## Output\n\n- The proposed `[LEARN]` rule with category\n- Confirmation after persisting","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/learn-rule","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/learn-rule/SKILL.md","defaultBranch":"main"},"readme":"# Learn Rule\n\nCapture a lesson from the current session into permanent memory.\n\n## Trigger\n\nUse when the user says \"remember this\", \"add to rules\", \"don't do that again\", or after a mistake is identified.\n\n## Workflow\n\n1. Identify the lesson — what mistake was made? What should happen instead?\n2. Format the rule with full context.\n3. Propose the addition and wait for user approval.\n4. After approval, persist to LEARNED section or project memory.\n\n## Format\n\n```\n[LEARN] Category: One-line rule\nMistake: What went wrong\nCorrection: How it was fixed\n```\n\n### Wiki-scoped rules\n\nAppend `Wiki: ` to bind the rule to a single pro-workflow wiki. The rule loads only when that wiki is in scope, avoiding cross-project pollution:\n\n```\n[LEARN] Editing: Cite a sources.md row before adding any wiki claim.\nWiki: agent-memory\n```\n\nThe capture hook auto-detects `Wiki: ` and links the learning to that wiki via `learnings_wiki`.\n\n## Categories\n\n| Category | Examples |\n|----------|---------|\n| Navigation | File paths, finding code, wrong file edited |\n| Editing | Code changes, patterns, wrong approach |\n| Testing | Test approaches, coverage gaps, flaky tests |\n| Git | Commits, branches, merge issues |\n| Quality | Lint, types, style violations |\n| Context | When to clarify, missing requirements |\n| Architecture | Design decisions, wrong abstractions |\n| Performance | Optimization, O(n^2) loops, memory |\n\n## Example\n\n```\nRecent mistake: Edited wrong utils.ts file\n\n[LEARN] Navigation: Confirm full path when multiple files share a name.\n\nAdd to LEARNED section? (y/n)\n```\n\n## Guardrails\n\n- Always wait for user approval before persisting.\n- Keep rules to one line — specific and actionable.\n- Bad: \"Write good code\". Good: \"Always use snake_case for database columns\".\n- Include the mistake context so the rule makes sense later.\n\n## Output\n\n- The proposed `[LEARN]` rule with category\n- Confirmation after persisting","createdAt":"2026-09-25T11:52:09.915Z","updatedAt":"2026-09-25T11:52:09.915Z"},{"id":"cmugwi2mm01pqqu06q6rflz6n","slug":"rohitg00-pro-workflow-llm-council","name":"llm-council","description":"Provider-agnostic multi-LLM deliberation. Three phases — independent responses, cross-model anonymized ranking, chairman synthesis. Provider config from env (OPENAI/ANTHROPIC/FIREWORKS/OPENROUTER/custom OpenAI-compatible base URL). Persists transcript to a wiki page when --wiki is passed. Use when the user wants multiple AI perspectives, consensus-building, or the \"LLM Council\" approach for high-stakes reviews, plan critique, or contested learning rules.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"llm-council","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Provider-agnostic multi-LLM deliberation. Three phases — independent responses, cross-model anonymized ranking, chairman synthesis. Provider config from env (OPENAI/ANTHROPIC/FIREWORKS/OPENROUTER/custom OpenAI-compatible base URL). Persists transcript to a wiki page when --wiki is passed. Use when the user wants multiple AI perspectives, consensus-building, or the \"LLM Council\" approach for high-stakes reviews, plan critique, or contested learning rules.","permissions":["shell"],"systemPrompt":"# LLM Council\n\nKarpathy's LLM Council pattern, provider-agnostic. dair-academy's version hardcoded Fireworks; ours reads any OpenAI-compatible endpoint via env.\n\n## When to use\n\n- High-stakes plan review (`/plan` crosses N-file threshold)\n- Conflicting learning-rules → re-resolve via vote\n- User invokes `/council \"\"` or `/wiki council`\n- Architecture decisions where you want multiple viewpoints captured\n- Persisting deliberation as a wiki page for future reference\n\n## Three phases\n\n1. **Independent**: each model answers in parallel\n2. **Ranking**: each model ranks anonymized peer responses\n3. **Synthesis**: chairman model reads all responses + rankings → final answer\n\n## Provider config\n\nProvider chosen via env. First-match wins:\n\n| Env var | Provider | Default base URL |\n|---------|----------|------------------|\n| `ANTHROPIC_API_KEY` | Anthropic | `https://api.anthropic.com` |\n| `OPENAI_API_KEY` | OpenAI | `https://api.openai.com/v1` |\n| `OPENROUTER_API_KEY` | OpenRouter | `https://openrouter.ai/api/v1` |\n| `FIREWORKS_API_KEY` | Fireworks | `https://api.fireworks.ai/inference/v1` |\n| `LLM_COUNCIL_BASE_URL` + `LLM_COUNCIL_API_KEY` | Custom OpenAI-compat | (user-supplied) |\n\nOverride per-run with `--provider openai|anthropic|openrouter|fireworks|custom`.\n\nDefault model rosters per provider live in `scripts/council.js` and can be overridden via `--models` CSV and `--chairman `.\n\n## Commands\n\n```\nnode $SKILL_ROOT/scripts/council.js run \"\" [--models id1,id2,id3] [--chairman id] [--provider ] [--wiki ]\nnode $SKILL_ROOT/scripts/council.js providers\nnode $SKILL_ROOT/scripts/council.js show \n```\n\n`--wiki ` writes the full transcript to `/derived/council/.md` and registers it via `wiki-cli.js page` so it shows in FTS5 search.\n\n## Output\n\nEach session writes:\n\n```\n~/.pro-workflow/council//\n├── config.json # query, models, chairman, provider\n├── phase1_responses.json # raw API responses per model\n├── phase2_rankings.json # anonymized ranking outputs\n├── phase3_synthesis.txt # chairman's final answer\n└── final_output.md # human-readable bundle\n```\n\nConsole prints the markdown bundle. Pipe to `pbcopy` / `tee` as needed.\n\n## Hard rules\n\n1. Never skip the ranking phase. It's the core of the council pattern.\n2. Save raw responses to disk verbatim. No summarization in storage.\n3. Anonymize responses for ranking — models see `Response A/B/C/...`, not peer names.\n4. The chairman sees both real names AND rankings.\n5. Display all three phases to the user. No phase elision.\n\n## Cost awareness\n\nThe script logs per-call latency + tokens on supported providers. Multiply by your provider rate to estimate. Council cost grows linearly with `len(models)^2` (each model ranks all others) plus the chairman.\n\nDefault council size: 3-5 models. More models = exponentially more ranking calls.\n\n## Use with wiki\n\n```\n/wiki council agent-memory \"should we adopt episodic memory in our agents?\"\n```\n\nLoads `agent-memory` wiki context as system prompt prefix, runs council, persists transcript as `wiki/derived/council/.md`. The transcript becomes searchable via `/wiki ask`.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/llm-council","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/llm-council/SKILL.md","defaultBranch":"main"},"readme":"# LLM Council\n\nKarpathy's LLM Council pattern, provider-agnostic. dair-academy's version hardcoded Fireworks; ours reads any OpenAI-compatible endpoint via env.\n\n## When to use\n\n- High-stakes plan review (`/plan` crosses N-file threshold)\n- Conflicting learning-rules → re-resolve via vote\n- User invokes `/council \"\"` or `/wiki council`\n- Architecture decisions where you want multiple viewpoints captured\n- Persisting deliberation as a wiki page for future reference\n\n## Three phases\n\n1. **Independent**: each model answers in parallel\n2. **Ranking**: each model ranks anonymized peer responses\n3. **Synthesis**: chairman model reads all responses + rankings → final answer\n\n## Provider config\n\nProvider chosen via env. First-match wins:\n\n| Env var | Provider | Default base URL |\n|---------|----------|------------------|\n| `ANTHROPIC_API_KEY` | Anthropic | `https://api.anthropic.com` |\n| `OPENAI_API_KEY` | OpenAI | `https://api.openai.com/v1` |\n| `OPENROUTER_API_KEY` | OpenRouter | `https://openrouter.ai/api/v1` |\n| `FIREWORKS_API_KEY` | Fireworks | `https://api.fireworks.ai/inference/v1` |\n| `LLM_COUNCIL_BASE_URL` + `LLM_COUNCIL_API_KEY` | Custom OpenAI-compat | (user-supplied) |\n\nOverride per-run with `--provider openai|anthropic|openrouter|fireworks|custom`.\n\nDefault model rosters per provider live in `scripts/council.js` and can be overridden via `--models` CSV and `--chairman `.\n\n## Commands\n\n```\nnode $SKILL_ROOT/scripts/council.js run \"\" [--models id1,id2,id3] [--chairman id] [--provider ] [--wiki ]\nnode $SKILL_ROOT/scripts/council.js providers\nnode $SKILL_ROOT/scripts/council.js show \n```\n\n`--wiki ` writes the full transcript to `/derived/council/.md` and registers it via `wiki-cli.js page` so it shows in FTS5 search.\n\n## Output\n\nEach session writes:\n\n```\n~/.pro-workflow/council//\n├── config.json # query, models, chairman, provider\n├── phase1_responses.json # raw API responses per model\n├── phase2_rankings.json # anonymized ranking outputs\n├── phase3_synthesis.txt # chairman's final answer\n└── final_output.md # human-readable bundle\n```\n\nConsole prints the markdown bundle. Pipe to `pbcopy` / `tee` as needed.\n\n## Hard rules\n\n1. Never skip the ranking phase. It's the core of the council pattern.\n2. Save raw responses to disk verbatim. No summarization in storage.\n3. Anonymize responses for ranking — models see `Response A/B/C/...`, not peer names.\n4. The chairman sees both real names AND rankings.\n5. Display all three phases to the user. No phase elision.\n\n## Cost awareness\n\nThe script logs per-call latency + tokens on supported providers. Multiply by your provider rate to estimate. Council cost grows linearly with `len(models)^2` (each model ranks all others) plus the chairman.\n\nDefault council size: 3-5 models. More models = exponentially more ranking calls.\n\n## Use with wiki\n\n```\n/wiki council agent-memory \"should we adopt episodic memory in our agents?\"\n```\n\nLoads `agent-memory` wiki context as system prompt prefix, runs council, persists transcript as `wiki/derived/council/.md`. The transcript becomes searchable via `/wiki ask`.","createdAt":"2026-09-25T11:52:09.934Z","updatedAt":"2026-09-25T11:52:09.934Z"},{"id":"cmugwi2n201ptqu06lyz1rl7t","slug":"rohitg00-pro-workflow-llm-gate","name":"llm-gate","description":"LLM-powered quality verification using prompt hooks. Validates commit messages, code patterns, and conventions using AI before allowing operations. Use to set up intelligent guardrails.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"llm-gate","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"LLM-powered quality verification using prompt hooks. Validates commit messages, code patterns, and conventions using AI before allowing operations. Use to set up intelligent guardrails.","permissions":[],"systemPrompt":"# LLM Gate\n\nUse Claude Code's `type: \"prompt\"` hooks to create intelligent quality gates that use AI to verify operations.\n\n## Trigger\n\nUse when:\n- Setting up commit message validation\n- Enforcing code conventions beyond what linters catch\n- Creating smart guardrails for specific operations\n\n## How Prompt Hooks Work\n\nClaude Code supports hooks with `type: \"prompt\"` that run a small LLM (Haiku by default) to verify conditions:\n\n```json\n{\n \"PreToolUse\": [{\n \"matcher\": \"Bash\",\n \"hooks\": [{\n \"type\": \"prompt\",\n \"if\": \"Bash(git commit*)\",\n \"prompt\": \"Check if this git commit follows conventional commit format ((): ). The commit command is: $ARGUMENTS. Return {\\\"ok\\\": true} if valid, {\\\"ok\\\": false, \\\"reason\\\": \\\"...\\\"} if not.\",\n \"model\": \"haiku\",\n \"timeout\": 15\n }]\n }]\n}\n```\n\nThe hook:\n1. Substitutes `$ARGUMENTS` with the JSON hook input\n2. Sends to Haiku (fast, cheap)\n3. Expects `{\"ok\": true}` or `{\"ok\": false, \"reason\": \"...\"}`\n4. If not ok → blocks the tool call with the reason\n\n## Example Gates\n\n### Conventional Commit Validator\n```json\n{\n \"type\": \"prompt\",\n \"if\": \"Bash(git commit*)\",\n \"prompt\": \"Verify this git commit follows conventional commits: type(scope): summary. Types: feat,fix,refactor,test,docs,chore,perf,ci. Summary under 72 chars. Input: $ARGUMENTS\",\n \"model\": \"haiku\"\n}\n```\n\n### Destructive Command Guard\n```json\n{\n \"type\": \"prompt\",\n \"if\": \"Bash(rm *)\",\n \"prompt\": \"Check if this rm command is safe. Flag if it uses -rf on important directories (src/, node_modules/, .git/). Input: $ARGUMENTS\",\n \"model\": \"haiku\"\n}\n```\n\n### API Key Leak Prevention\n```json\n{\n \"type\": \"prompt\",\n \"matcher\": \"Write\",\n \"prompt\": \"Check if this file write contains hardcoded API keys, secrets, passwords, or tokens. Input: $ARGUMENTS. Return ok:false if secrets found.\",\n \"model\": \"haiku\"\n}\n```\n\n## Agent Hooks\n\nFor complex verification, use `type: \"agent\"` (runs a full agent):\n\n```json\n{\n \"type\": \"agent\",\n \"if\": \"Bash(git push*)\",\n \"prompt\": \"Review all staged changes for security issues before pushing. Check for: hardcoded secrets, SQL injection, XSS vulnerabilities, exposed internal URLs.\",\n \"model\": \"haiku\",\n \"timeout\": 60\n}\n```\n\n## Setup Guide\n\n1. Choose which operations to gate\n2. Write the prompt (keep it focused, under 100 words)\n3. Pick the model (haiku for speed, sonnet for accuracy)\n4. Set timeout (15s for prompts, 60s for agents)\n5. Add to hooks.json under the appropriate event\n\n## Rules\n\n- Use Haiku for simple checks (fast, cheap)\n- Use Sonnet only for complex analysis\n- Keep prompts under 100 words for reliability\n- Always include `if` condition to avoid running on every tool call\n- Set reasonable timeouts (15s prompt, 60s agent)\n- Test hooks before deploying to avoid blocking workflows","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/llm-gate","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/llm-gate/SKILL.md","defaultBranch":"main"},"readme":"# LLM Gate\n\nUse Claude Code's `type: \"prompt\"` hooks to create intelligent quality gates that use AI to verify operations.\n\n## Trigger\n\nUse when:\n- Setting up commit message validation\n- Enforcing code conventions beyond what linters catch\n- Creating smart guardrails for specific operations\n\n## How Prompt Hooks Work\n\nClaude Code supports hooks with `type: \"prompt\"` that run a small LLM (Haiku by default) to verify conditions:\n\n```json\n{\n \"PreToolUse\": [{\n \"matcher\": \"Bash\",\n \"hooks\": [{\n \"type\": \"prompt\",\n \"if\": \"Bash(git commit*)\",\n \"prompt\": \"Check if this git commit follows conventional commit format ((): ). The commit command is: $ARGUMENTS. Return {\\\"ok\\\": true} if valid, {\\\"ok\\\": false, \\\"reason\\\": \\\"...\\\"} if not.\",\n \"model\": \"haiku\",\n \"timeout\": 15\n }]\n }]\n}\n```\n\nThe hook:\n1. Substitutes `$ARGUMENTS` with the JSON hook input\n2. Sends to Haiku (fast, cheap)\n3. Expects `{\"ok\": true}` or `{\"ok\": false, \"reason\": \"...\"}`\n4. If not ok → blocks the tool call with the reason\n\n## Example Gates\n\n### Conventional Commit Validator\n```json\n{\n \"type\": \"prompt\",\n \"if\": \"Bash(git commit*)\",\n \"prompt\": \"Verify this git commit follows conventional commits: type(scope): summary. Types: feat,fix,refactor,test,docs,chore,perf,ci. Summary under 72 chars. Input: $ARGUMENTS\",\n \"model\": \"haiku\"\n}\n```\n\n### Destructive Command Guard\n```json\n{\n \"type\": \"prompt\",\n \"if\": \"Bash(rm *)\",\n \"prompt\": \"Check if this rm command is safe. Flag if it uses -rf on important directories (src/, node_modules/, .git/). Input: $ARGUMENTS\",\n \"model\": \"haiku\"\n}\n```\n\n### API Key Leak Prevention\n```json\n{\n \"type\": \"prompt\",\n \"matcher\": \"Write\",\n \"prompt\": \"Check if this file write contains hardcoded API keys, secrets, passwords, or tokens. Input: $ARGUMENTS. Return ok:false if secrets found.\",\n \"model\": \"haiku\"\n}\n```\n\n## Agent Hooks\n\nFor complex verification, use `type: \"agent\"` (runs a full agent):\n\n```json\n{\n \"type\": \"agent\",\n \"if\": \"Bash(git push*)\",\n \"prompt\": \"Review all staged changes for security issues before pushing. Check for: hardcoded secrets, SQL injection, XSS vulnerabilities, exposed internal URLs.\",\n \"model\": \"haiku\",\n \"timeout\": 60\n}\n```\n\n## Setup Guide\n\n1. Choose which operations to gate\n2. Write the prompt (keep it focused, under 100 words)\n3. Pick the model (haiku for speed, sonnet for accuracy)\n4. Set timeout (15s for prompts, 60s for agents)\n5. Add to hooks.json under the appropriate event\n\n## Rules\n\n- Use Haiku for simple checks (fast, cheap)\n- Use Sonnet only for complex analysis\n- Keep prompts under 100 words for reliability\n- Always include `if` condition to avoid running on every tool call\n- Set reasonable timeouts (15s prompt, 60s agent)\n- Test hooks before deploying to avoid blocking workflows","createdAt":"2026-09-25T11:52:09.950Z","updatedAt":"2026-09-25T11:52:09.950Z"},{"id":"cmugwi2nc01pwqu06xpulak1m","slug":"rohitg00-pro-workflow-mcp-audit","name":"mcp-audit","description":"Audit connected MCP servers for token overhead, redundancy, and security. Use when sessions feel slow or before adding new MCPs.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"mcp-audit","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Audit connected MCP servers for token overhead, redundancy, and security. Use when sessions feel slow or before adding new MCPs.","permissions":[],"systemPrompt":"# MCP Audit\n\nAnalyze MCP server overhead and recommend cleanup.\n\n## Trigger\n\nUse when:\n- Sessions feel slow or expensive\n- Adding a new MCP server\n- Context fills up quickly\n- Reviewing project configuration\n\n## Key Insight\n\nEach MCP server adds ALL its tool descriptions to every API request. A server with 20 tools adds ~2K-4K tokens per request, regardless of whether you use those tools.\n\n## Audit Steps\n\n### Step 1: List Active Servers\n\nCheck all MCP configurations:\n```bash\ncat .claude/settings.json 2>/dev/null | grep -A 50 \"mcpServers\"\ncat ~/.claude/settings.json 2>/dev/null | grep -A 50 \"mcpServers\"\n```\n\n### Step 2: Count Tools Per Server\n\nFor each server, estimate token overhead:\n- 1-5 tools: ~200-500 tokens (low overhead)\n- 6-15 tools: ~500-1500 tokens (moderate)\n- 16-30 tools: ~1500-3000 tokens (high)\n- 30+ tools: ~3000+ tokens (excessive — consider tool filtering)\n\n### Step 3: Check Usage\n\nQuestions to ask:\n- Which servers were actually used this session?\n- Which servers haven't been used in 7+ days?\n- Are there servers with overlapping functionality?\n- Are there servers only needed for specific tasks?\n\n### Step 4: Recommend Actions\n\n**Disable** servers that:\n- Haven't been used in 7+ days\n- Overlap with another active server\n- Are project-specific but you're in a different project\n\n**Keep** servers that:\n- Are used every session (filesystem, git)\n- Provide unique capabilities needed for current work\n- Have low tool count (<5 tools)\n\n## Output\n\n```text\nMCP AUDIT\n Active servers: [N]\n Total tools: [N]\n Estimated overhead: ~[N]K tokens per request\n\n Server Analysis:\n [name] — [N] tools, ~[N] tokens\n Status: KEEP / DISABLE / REVIEW\n Reason: [why]\n\n Recommendations:\n Disable: [list]\n Keep: [list]\n Review: [list]\n\n Projected savings: ~[N]K tokens per request (~$X.XX per session)\n```\n\n## Thresholds\n\n- Total servers: <10 (ideal), 10-15 (monitor), >15 (reduce)\n- Total tools: <80 (ideal), 80-120 (monitor), >120 (reduce)\n- Per-server: <15 tools (ok), 15-30 (filter), >30 (split or disable)\n\n## Rules\n\n- Never disable servers without user confirmation\n- Estimate token savings for each recommendation\n- Consider task context — a server might be unused today but critical tomorrow\n- Check for `disabledMcpjsonServers` to avoid re-recommending already-disabled servers","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/mcp-audit","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/mcp-audit/SKILL.md","defaultBranch":"main"},"readme":"# MCP Audit\n\nAnalyze MCP server overhead and recommend cleanup.\n\n## Trigger\n\nUse when:\n- Sessions feel slow or expensive\n- Adding a new MCP server\n- Context fills up quickly\n- Reviewing project configuration\n\n## Key Insight\n\nEach MCP server adds ALL its tool descriptions to every API request. A server with 20 tools adds ~2K-4K tokens per request, regardless of whether you use those tools.\n\n## Audit Steps\n\n### Step 1: List Active Servers\n\nCheck all MCP configurations:\n```bash\ncat .claude/settings.json 2>/dev/null | grep -A 50 \"mcpServers\"\ncat ~/.claude/settings.json 2>/dev/null | grep -A 50 \"mcpServers\"\n```\n\n### Step 2: Count Tools Per Server\n\nFor each server, estimate token overhead:\n- 1-5 tools: ~200-500 tokens (low overhead)\n- 6-15 tools: ~500-1500 tokens (moderate)\n- 16-30 tools: ~1500-3000 tokens (high)\n- 30+ tools: ~3000+ tokens (excessive — consider tool filtering)\n\n### Step 3: Check Usage\n\nQuestions to ask:\n- Which servers were actually used this session?\n- Which servers haven't been used in 7+ days?\n- Are there servers with overlapping functionality?\n- Are there servers only needed for specific tasks?\n\n### Step 4: Recommend Actions\n\n**Disable** servers that:\n- Haven't been used in 7+ days\n- Overlap with another active server\n- Are project-specific but you're in a different project\n\n**Keep** servers that:\n- Are used every session (filesystem, git)\n- Provide unique capabilities needed for current work\n- Have low tool count (<5 tools)\n\n## Output\n\n```text\nMCP AUDIT\n Active servers: [N]\n Total tools: [N]\n Estimated overhead: ~[N]K tokens per request\n\n Server Analysis:\n [name] — [N] tools, ~[N] tokens\n Status: KEEP / DISABLE / REVIEW\n Reason: [why]\n\n Recommendations:\n Disable: [list]\n Keep: [list]\n Review: [list]\n\n Projected savings: ~[N]K tokens per request (~$X.XX per session)\n```\n\n## Thresholds\n\n- Total servers: <10 (ideal), 10-15 (monitor), >15 (reduce)\n- Total tools: <80 (ideal), 80-120 (monitor), >120 (reduce)\n- Per-server: <15 tools (ok), 15-30 (filter), >30 (split or disable)\n\n## Rules\n\n- Never disable servers without user confirmation\n- Estimate token savings for each recommendation\n- Consider task context — a server might be unused today but critical tomorrow\n- Check for `disabledMcpjsonServers` to avoid re-recommending already-disabled servers","createdAt":"2026-09-25T11:52:09.960Z","updatedAt":"2026-09-25T11:52:09.960Z"},{"id":"cmugwi2nl01pzqu06aydfijz1","slug":"rohitg00-pro-workflow-module-map","name":"module-map","description":"Produce a one-screen map of an unfamiliar area of the codebase: entry points, modules, data flow, callers. Designed to be read in fifteen seconds. Use when the user says \"I do not know this area\", \"give me the map\", \"zoom out\", \"orient me\".","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"module-map","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Produce a one-screen map of an unfamiliar area of the codebase: entry points, modules, data flow, callers. Designed to be read in fifteen seconds. Use when the user says \"I do not know this area\", \"give me the map\", \"zoom out\", \"orient me\".","permissions":[],"systemPrompt":"# module-map\n\nOrient fast in unfamiliar code. The deliverable is a map, not a tour.\n\n## Deliverable\n\nA single response containing, in this order:\n\n1. **One-line summary** of what the area does from a caller's point of view.\n2. **Entry points** — every function, route, CLI command, event handler,\n or cron that starts a call chain in this area. File path + symbol.\n3. **Core modules** — the two to five modules that contain the real\n logic. One line each describing their role.\n4. **Data flow** — ASCII arrows showing the dominant path for the most\n common input. Skip error paths unless they matter architecturally.\n5. **External callers** — who outside this area calls in, and through\n which entry points.\n6. **Hidden coupling** — anything that looks independent but is not\n (shared singletons, global state, implicit ordering, undocumented\n contracts between files).\n\n## Rules\n\n- Fifteen-second read target. If the map exceeds one screen, cut it.\n- Every claim must be backed by a file path. No remembered or inferred\n structure without a grep behind it.\n- Do not list every file. Curate. A good map omits deliberately.\n- Do not propose changes. Mapping is orientation; refactoring is a\n different skill.\n- If the area is too large to map in one screen, segment it and ask the\n user which segment to expand. Do not silently drop half the code.\n\n## Format\n\n```\nAREA: \n\nENTRY POINTS\n- : — \n\nCORE MODULES\n- — \n\nFLOW\n -> -> -> \n\nCALLERS\n- — uses \n\nHIDDEN COUPLING\n- ()\n```\n\nUse the exact headers. Consistency lets the user scan.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/module-map","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/module-map/SKILL.md","defaultBranch":"main"},"readme":"# module-map\n\nOrient fast in unfamiliar code. The deliverable is a map, not a tour.\n\n## Deliverable\n\nA single response containing, in this order:\n\n1. **One-line summary** of what the area does from a caller's point of view.\n2. **Entry points** — every function, route, CLI command, event handler,\n or cron that starts a call chain in this area. File path + symbol.\n3. **Core modules** — the two to five modules that contain the real\n logic. One line each describing their role.\n4. **Data flow** — ASCII arrows showing the dominant path for the most\n common input. Skip error paths unless they matter architecturally.\n5. **External callers** — who outside this area calls in, and through\n which entry points.\n6. **Hidden coupling** — anything that looks independent but is not\n (shared singletons, global state, implicit ordering, undocumented\n contracts between files).\n\n## Rules\n\n- Fifteen-second read target. If the map exceeds one screen, cut it.\n- Every claim must be backed by a file path. No remembered or inferred\n structure without a grep behind it.\n- Do not list every file. Curate. A good map omits deliberately.\n- Do not propose changes. Mapping is orientation; refactoring is a\n different skill.\n- If the area is too large to map in one screen, segment it and ask the\n user which segment to expand. Do not silently drop half the code.\n\n## Format\n\n```\nAREA: \n\nENTRY POINTS\n- : — \n\nCORE MODULES\n- — \n\nFLOW\n -> -> -> \n\nCALLERS\n- — uses \n\nHIDDEN COUPLING\n- ()\n```\n\nUse the exact headers. Consistency lets the user scan.","createdAt":"2026-09-25T11:52:09.969Z","updatedAt":"2026-09-25T11:52:09.969Z"},{"id":"cmugwi2nu01q2qu06o3nn7crg","slug":"rohitg00-pro-workflow-orchestrate","name":"orchestrate","description":"Wire Commands, Agents, and Skills together for complex features. Use when building features that need research, planning, and implementation phases.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"orchestrate","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Wire Commands, Agents, and Skills together for complex features. Use when building features that need research, planning, and implementation phases.","permissions":[],"systemPrompt":"# Orchestrate - Multi-Phase Feature Development\n\nBuild features through structured phases with validation gates.\n\n## The Pattern\n\n```text\n/develop \n │\n ├── Phase 1: Research (orchestrator agent)\n │ └── Score confidence → GO/HOLD\n │\n ├── Phase 2: Plan (orchestrator agent)\n │ └── Present plan → wait for approval\n │\n ├── Phase 3: Implement (orchestrator agent)\n │ └── Execute plan → quality gates\n │\n └── Phase 4: Review (reviewer agent)\n └── Code review → commit\n```\n\n## Usage\n\nWhen asked to build a feature:\n\n1. **Start with research**: Delegate to the orchestrator agent or scout agent to explore the codebase\n2. **Wait for GO/HOLD**: Don't proceed if confidence is below 70\n3. **Present a plan**: List all files to change, the approach, and risks\n4. **Get approval**: Never implement without explicit \"proceed\"\n5. **Implement step by step**: Quality gates every 5 edits\n6. **Review before commit**: Run the reviewer agent on changes\n\n## When to Use This\n\n- Feature touches >5 files\n- Architecture decisions needed\n- Requirements are unclear or complex\n- Cross-cutting concerns (auth, logging, error handling)\n- New patterns not yet established in the codebase\n\n## When NOT to Use This\n\n- Quick bug fixes (just fix it)\n- Single-file changes\n- Well-understood patterns (follow existing code)\n- Documentation-only changes\n\n## Agent Selection\n\n| Phase | Agent | Why |\n|-------|-------|-----|\n| Research | scout (background, worktree) | Non-blocking exploration |\n| Plan | orchestrator (opus, memory) | Deep reasoning, pattern recall |\n| Implement | orchestrator (opus, memory) | Full tool access |\n| Review | reviewer (read + bash) | Security and quality focus |\n| Debug | debugger (opus, memory) | Systematic investigation |\n\n## Integration with Pro-Workflow\n\n- Corrections during implementation trigger self-correction loop\n- Quality gates fire at checkpoints via hooks\n- Learnings are captured at the end of each phase\n- Session handoff works across phases","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/orchestrate","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/orchestrate/SKILL.md","defaultBranch":"main"},"readme":"# Orchestrate - Multi-Phase Feature Development\n\nBuild features through structured phases with validation gates.\n\n## The Pattern\n\n```text\n/develop \n │\n ├── Phase 1: Research (orchestrator agent)\n │ └── Score confidence → GO/HOLD\n │\n ├── Phase 2: Plan (orchestrator agent)\n │ └── Present plan → wait for approval\n │\n ├── Phase 3: Implement (orchestrator agent)\n │ └── Execute plan → quality gates\n │\n └── Phase 4: Review (reviewer agent)\n └── Code review → commit\n```\n\n## Usage\n\nWhen asked to build a feature:\n\n1. **Start with research**: Delegate to the orchestrator agent or scout agent to explore the codebase\n2. **Wait for GO/HOLD**: Don't proceed if confidence is below 70\n3. **Present a plan**: List all files to change, the approach, and risks\n4. **Get approval**: Never implement without explicit \"proceed\"\n5. **Implement step by step**: Quality gates every 5 edits\n6. **Review before commit**: Run the reviewer agent on changes\n\n## When to Use This\n\n- Feature touches >5 files\n- Architecture decisions needed\n- Requirements are unclear or complex\n- Cross-cutting concerns (auth, logging, error handling)\n- New patterns not yet established in the codebase\n\n## When NOT to Use This\n\n- Quick bug fixes (just fix it)\n- Single-file changes\n- Well-understood patterns (follow existing code)\n- Documentation-only changes\n\n## Agent Selection\n\n| Phase | Agent | Why |\n|-------|-------|-----|\n| Research | scout (background, worktree) | Non-blocking exploration |\n| Plan | orchestrator (opus, memory) | Deep reasoning, pattern recall |\n| Implement | orchestrator (opus, memory) | Full tool access |\n| Review | reviewer (read + bash) | Security and quality focus |\n| Debug | debugger (opus, memory) | Systematic investigation |\n\n## Integration with Pro-Workflow\n\n- Corrections during implementation trigger self-correction loop\n- Quality gates fire at checkpoints via hooks\n- Learnings are captured at the end of each phase\n- Session handoff works across phases","createdAt":"2026-09-25T11:52:09.978Z","updatedAt":"2026-09-25T11:52:09.978Z"},{"id":"cmugwi2o201q5qu06bjild4bt","slug":"rohitg00-pro-workflow-parallel-worktrees","name":"parallel-worktrees","description":"Create and manage git worktrees for parallel coding sessions with zero dead time. Use when blocked on tests, builds, wanting to work on multiple branches, context switching, or exploring multiple approaches simultaneously.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"parallel-worktrees","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Create and manage git worktrees for parallel coding sessions with zero dead time. Use when blocked on tests, builds, wanting to work on multiple branches, context switching, or exploring multiple approaches simultaneously.","permissions":[],"systemPrompt":"# Parallel Worktrees\n\nZero dead time. While one session runs tests, work on something else.\n\n## Trigger\n\nUse when waiting on tests, long builds, exploring approaches, or needing to review and develop simultaneously.\n\n## Quick Start\n\n**Claude Code:**\n```bash\nclaude --worktree # or claude -w (auto-creates isolated worktree)\n```\n\n**Cursor / Any editor:**\n```bash\ngit worktree add ../project-feat feature-branch\n# Open the new worktree folder in a second editor window\n```\n\nBoth approaches create an isolated working copy where changes don't interfere with your main session.\n\n## Claude Code Extras\n\nThese features are Claude Code-specific (skip if using Cursor):\n\n- `claude -w` auto-creates and cleans up worktrees\n- Subagents support `isolation: worktree` in agent frontmatter\n- `Ctrl+F` kills all background agents (two-press confirmation)\n- `Ctrl+B` sends a task to background\n\n## Workflow\n\n1. Show current worktrees: `git worktree list`\n2. Create a worktree for the parallel task.\n3. Open a new editor/terminal session in the worktree.\n4. When done, clean up the worktree.\n\n## Commands\n\n```bash\ngit worktree list\n\ngit worktree add ../project-feat feature-branch\ngit worktree add ../project-fix bugfix-branch\ngit worktree add ../project-exp -b experiment\n\ngit worktree remove ../project-feat\ngit worktree prune\n```\n\n## Usage Pattern\n\n```\nTerminal 1: ~/project → Main work\nTerminal 2: ~/project-feat → Feature development\nTerminal 3: ~/project-fix → Bug fixes\n```\n\nEach worktree runs its own AI session independently.\n\n## When to Parallelize\n\n| Scenario | Action |\n|----------|--------|\n| Tests running (2+ min) | Start new feature in worktree |\n| Long build | Debug issue in parallel |\n| Exploring approaches | Compare 2-3 simultaneously |\n| Review + new work | Reviewer in one, dev in other |\n| Waiting on CI | Start next task in worktree |\n\n## Guardrails\n\n- Each worktree is a full working copy — changes are isolated.\n- Before removing a worktree, verify changes are committed: `git -C ../project-feat status`\n- Don't forget to clean up worktrees when done (`git worktree prune`).\n- Avoid editing the same files in multiple worktrees simultaneously.\n\n## Output\n\n- Current worktree list\n- Created worktree path and branch\n- Instructions for opening a new session","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/parallel-worktrees","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/parallel-worktrees/SKILL.md","defaultBranch":"main"},"readme":"# Parallel Worktrees\n\nZero dead time. While one session runs tests, work on something else.\n\n## Trigger\n\nUse when waiting on tests, long builds, exploring approaches, or needing to review and develop simultaneously.\n\n## Quick Start\n\n**Claude Code:**\n```bash\nclaude --worktree # or claude -w (auto-creates isolated worktree)\n```\n\n**Cursor / Any editor:**\n```bash\ngit worktree add ../project-feat feature-branch\n# Open the new worktree folder in a second editor window\n```\n\nBoth approaches create an isolated working copy where changes don't interfere with your main session.\n\n## Claude Code Extras\n\nThese features are Claude Code-specific (skip if using Cursor):\n\n- `claude -w` auto-creates and cleans up worktrees\n- Subagents support `isolation: worktree` in agent frontmatter\n- `Ctrl+F` kills all background agents (two-press confirmation)\n- `Ctrl+B` sends a task to background\n\n## Workflow\n\n1. Show current worktrees: `git worktree list`\n2. Create a worktree for the parallel task.\n3. Open a new editor/terminal session in the worktree.\n4. When done, clean up the worktree.\n\n## Commands\n\n```bash\ngit worktree list\n\ngit worktree add ../project-feat feature-branch\ngit worktree add ../project-fix bugfix-branch\ngit worktree add ../project-exp -b experiment\n\ngit worktree remove ../project-feat\ngit worktree prune\n```\n\n## Usage Pattern\n\n```\nTerminal 1: ~/project → Main work\nTerminal 2: ~/project-feat → Feature development\nTerminal 3: ~/project-fix → Bug fixes\n```\n\nEach worktree runs its own AI session independently.\n\n## When to Parallelize\n\n| Scenario | Action |\n|----------|--------|\n| Tests running (2+ min) | Start new feature in worktree |\n| Long build | Debug issue in parallel |\n| Exploring approaches | Compare 2-3 simultaneously |\n| Review + new work | Reviewer in one, dev in other |\n| Waiting on CI | Start next task in worktree |\n\n## Guardrails\n\n- Each worktree is a full working copy — changes are isolated.\n- Before removing a worktree, verify changes are committed: `git -C ../project-feat status`\n- Don't forget to clean up worktrees when done (`git worktree prune`).\n- Avoid editing the same files in multiple worktrees simultaneously.\n\n## Output\n\n- Current worktree list\n- Created worktree path and branch\n- Instructions for opening a new session","createdAt":"2026-09-25T11:52:09.987Z","updatedAt":"2026-09-25T11:52:09.987Z"},{"id":"cmugwi2oa01q8qu06l53y5j2e","slug":"rohitg00-pro-workflow-permission-tuner","name":"permission-tuner","description":"Analyze permission denial patterns and generate optimized alwaysAllow and alwaysDeny rules. Use when permission prompts are slowing you down or after sessions with many denials.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"permission-tuner","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Analyze permission denial patterns and generate optimized alwaysAllow and alwaysDeny rules. Use when permission prompts are slowing you down or after sessions with many denials.","permissions":[],"systemPrompt":"# Permission Tuner\n\nReduce permission prompt fatigue by analyzing denial patterns and suggesting targeted rules.\n\n## Trigger\n\nUse when:\n- Permission prompts interrupt flow repeatedly\n- Starting a new project and want to configure permissions\n- After a session with many manual approvals\n\n## Workflow\n\n1. Scan recent session data for permission patterns\n2. Identify frequently-approved tools and patterns\n3. Generate safe `alwaysAllow` rules\n4. Present rules for approval before applying\n\n## Analysis\n\n### Step 1: Gather Permission Data\n\nCheck current permission rules:\n```bash\ncat .claude/settings.json 2>/dev/null | grep -A 20 \"permissions\"\ncat ~/.claude/settings.json 2>/dev/null | grep -A 20 \"permissions\"\n```\n\n### Step 2: Identify Safe Patterns\n\n**Allow-list candidates** (low risk):\n- `Read` — all file reads (read-only, no side effects)\n- `Glob` — file pattern matching (read-only)\n- `Grep` — content search (read-only)\n- `Bash(git status)` — read-only git commands\n- `Bash(git diff*)` — read-only git commands\n- `Bash(git log*)` — read-only git commands\n- `Bash(npm test*)` — test execution\n- `Bash(npm run lint*)` — linting\n- `Bash(npm run typecheck*)` — type checking\n\n**Ask candidates** (medium risk — prompt user every time):\n- `Edit` — file modifications\n- `Write` — new file creation\n- `Bash(git add*)` — staging changes\n- `Bash(git commit*)` — creating commits\n- `Bash(npm install*)` — dependency changes\n\n**Deny-list candidates** (high risk):\n- `Bash(git push*)` — affects remote\n- `Bash(git reset --hard*)` — destructive\n- `Bash(rm -rf*)` — destructive\n- `Bash(curl*POST*)` — external API calls\n- Any command with `--force` or `--no-verify`\n\n### Step 3: Generate Rules\n\n```json\n{\n \"permissions\": {\n \"allow\": [\n \"Read\",\n \"Glob\",\n \"Grep\",\n \"Bash(git status)\",\n \"Bash(git diff*)\",\n \"Bash(git log*)\",\n \"Bash(npm test*)\",\n \"Bash(npm run lint*)\",\n \"Bash(npm run typecheck*)\"\n ],\n \"deny\": [\n \"Bash(rm -rf *)\",\n \"Bash(git push --force*)\",\n \"Bash(git reset --hard*)\"\n ]\n }\n}\n```\n\n## Output\n\n```text\nPERMISSION TUNER REPORT\n\nCurrent rules: [X] allow, [Y] deny, [Z] ask\n\nRecommendations:\n Auto-approve (safe, read-only):\n + Read, Glob, Grep\n + Bash(git status), Bash(git diff*), Bash(git log*)\n\n Auto-approve (medium risk, frequently used):\n + Edit (approved X times this session)\n + Bash(npm test*) (approved X times)\n\n Keep asking:\n ~ Bash(git commit*) — verify commit messages\n ~ Write — verify new file creation\n\n Auto-deny (dangerous):\n - Bash(rm -rf *)\n - Bash(git push --force*)\n\nEstimated prompts saved per session: ~[N]\n```\n\n## Rules\n\n- Destructive operations must stay in the deny list\n- Always present rules for user approval before applying\n- Group rules by risk level (safe/medium/dangerous)\n- Include estimated prompt savings","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/permission-tuner","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/permission-tuner/SKILL.md","defaultBranch":"main"},"readme":"# Permission Tuner\n\nReduce permission prompt fatigue by analyzing denial patterns and suggesting targeted rules.\n\n## Trigger\n\nUse when:\n- Permission prompts interrupt flow repeatedly\n- Starting a new project and want to configure permissions\n- After a session with many manual approvals\n\n## Workflow\n\n1. Scan recent session data for permission patterns\n2. Identify frequently-approved tools and patterns\n3. Generate safe `alwaysAllow` rules\n4. Present rules for approval before applying\n\n## Analysis\n\n### Step 1: Gather Permission Data\n\nCheck current permission rules:\n```bash\ncat .claude/settings.json 2>/dev/null | grep -A 20 \"permissions\"\ncat ~/.claude/settings.json 2>/dev/null | grep -A 20 \"permissions\"\n```\n\n### Step 2: Identify Safe Patterns\n\n**Allow-list candidates** (low risk):\n- `Read` — all file reads (read-only, no side effects)\n- `Glob` — file pattern matching (read-only)\n- `Grep` — content search (read-only)\n- `Bash(git status)` — read-only git commands\n- `Bash(git diff*)` — read-only git commands\n- `Bash(git log*)` — read-only git commands\n- `Bash(npm test*)` — test execution\n- `Bash(npm run lint*)` — linting\n- `Bash(npm run typecheck*)` — type checking\n\n**Ask candidates** (medium risk — prompt user every time):\n- `Edit` — file modifications\n- `Write` — new file creation\n- `Bash(git add*)` — staging changes\n- `Bash(git commit*)` — creating commits\n- `Bash(npm install*)` — dependency changes\n\n**Deny-list candidates** (high risk):\n- `Bash(git push*)` — affects remote\n- `Bash(git reset --hard*)` — destructive\n- `Bash(rm -rf*)` — destructive\n- `Bash(curl*POST*)` — external API calls\n- Any command with `--force` or `--no-verify`\n\n### Step 3: Generate Rules\n\n```json\n{\n \"permissions\": {\n \"allow\": [\n \"Read\",\n \"Glob\",\n \"Grep\",\n \"Bash(git status)\",\n \"Bash(git diff*)\",\n \"Bash(git log*)\",\n \"Bash(npm test*)\",\n \"Bash(npm run lint*)\",\n \"Bash(npm run typecheck*)\"\n ],\n \"deny\": [\n \"Bash(rm -rf *)\",\n \"Bash(git push --force*)\",\n \"Bash(git reset --hard*)\"\n ]\n }\n}\n```\n\n## Output\n\n```text\nPERMISSION TUNER REPORT\n\nCurrent rules: [X] allow, [Y] deny, [Z] ask\n\nRecommendations:\n Auto-approve (safe, read-only):\n + Read, Glob, Grep\n + Bash(git status), Bash(git diff*), Bash(git log*)\n\n Auto-approve (medium risk, frequently used):\n + Edit (approved X times this session)\n + Bash(npm test*) (approved X times)\n\n Keep asking:\n ~ Bash(git commit*) — verify commit messages\n ~ Write — verify new file creation\n\n Auto-deny (dangerous):\n - Bash(rm -rf *)\n - Bash(git push --force*)\n\nEstimated prompts saved per session: ~[N]\n```\n\n## Rules\n\n- Destructive operations must stay in the deny list\n- Always present rules for user approval before applying\n- Group rules by risk level (safe/medium/dangerous)\n- Include estimated prompt savings","createdAt":"2026-09-25T11:52:09.995Z","updatedAt":"2026-09-25T11:52:09.995Z"},{"id":"cmugwi2oq01qbqu06vc4nydmc","slug":"rohitg00-pro-workflow-plan-interrogate","name":"plan-interrogate","description":"Stress-test a plan by walking its decision tree one question at a time. Use when the user wants to pressure-test a design before implementation.","authorId":"gh:rohitg00","authorName":"rohitg00","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":2879,"pricePerCall":0,"manifest":{"name":"plan-interrogate","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Stress-test a plan by walking its decision tree one question at a time. Use when the user wants to pressure-test a design before implementation.","permissions":[],"systemPrompt":"# plan-interrogate\n\nDrive a plan from sketch to commitment by resolving every open decision\nbefore any code is written.\n\n## Method\n\n1. Restate the plan in one paragraph. Confirm with the user that this is\n the plan being interrogated. Do not proceed on a mis-restatement.\n2. Extract the decision tree. Every branch point becomes a node. Mark\n each node as **open** (undecided) or **resolved**. A resolved node\n carries a source tag: `user` (the user answered), `inferred` (the\n codebase or an existing constraint settled it).\n3. Resolve in dependency order. A node is ready when every node it\n depends on is resolved.\n4. For each ready open node, ask exactly one question. Keep the question\n tight and binary or small-multiple-choice when possible.\n5. Pair every question with a **recommended answer** and one sentence of\n reasoning. The user can confirm, pick a different option, or push back.\n6. Before asking, check whether the answer already lives in the codebase,\n prior commits, or an existing doc. If so, skip the question and mark\n the node resolved with source `inferred: `.\n7. Exit only when zero nodes are open. Print the resolved tree as a flat\n list: `Decision - Choice - Source (user | inferred: )`.\n\n## Anti-patterns\n\n- Asking multiple questions at once. The user loses context and you lose\n the ability to react to each answer individually.\n- Asking before exploring. If a fifteen-second read would answer the\n question, read first.\n- Asking without a recommendation. A question without a stance is a\n survey; it offloads design onto the user.\n- Rolling past an unresolved node. If a dependency is not pinned, the\n downstream question is premature.\n\n## Outputs\n\nThe interrogation produces three artifacts, not just answers. Offer to write\neach; do not force it.\n\n1. **Decision ledger** (always). The resolved tree as a flat list:\n `Decision - Choice - Source (user | inferred: )`.\n\n2. **`CONTEXT.md`** (when the interrogation surfaced project-specific terms).\n A short shared-language file: every domain term you and the user had to\n pin down, with a one-line definition in the project's own words. This is\n what stops the agent from using twenty words where one will do next\n session, and keeps names in code consistent. One term per line:\n `term - what it means here`. Point future sessions at it. On re-run, merge\n new terms in place rather than overwriting existing ones.\n\n3. **Decision records** (for contested or hard-to-reverse nodes only). One\n short record per decision that a future reader would question: the\n context, the choice, the alternatives rejected, and why. Keep them in\n `docs/decisions/NNNN-slug.md`. Read the directory first and number from the\n highest existing record so two records never collide. Skip the obvious ones -\n a record for a trivial choice is noise.\n\n## Output contract\n\nThe decision ledger the user can paste into the plan doc. No prose summary.\nNo hedging. If the user declines to decide a node, mark it `DEFERRED` with\nthe reason the user gave - this is not the same as open. When you write\n`CONTEXT.md` or a decision record, keep it in the project's language, not a\ngeneric template.","schemaVersion":1},"repoUrl":"https://github.com/rohitg00/pro-workflow/tree/main/skills/plan-interrogate","tags":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"pro-workflow","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[],"packages":1,"auditedAt":"2026-09-25T11:52:09.680Z","lockfiles":["package-lock.json"]},"forks":290,"owner":"rohitg00","stars":2879,"topics":["agent-orchestration","ai-agents","ai-coding","ai-workflow","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","codex","context-engineering","cursor","developer-tools","gemini-cli","hooks","productivity","self-correction","workflow","worktrees"],"license":null,"fullName":"rohitg00/pro-workflow","homepage":"https://rohitg00.github.io/pro-workflow/infographic.html","language":"JavaScript","pushedAt":"2026-09-24T06:22:08Z","avatarUrl":"https://avatars.githubusercontent.com/u/48523873?v=4","crawledAt":"2026-09-25T11:51:58.631Z","openIssues":30,"manifestFile":"SKILL.md","manifestPath":"skills/plan-interrogate/SKILL.md","defaultBranch":"main"},"readme":"# plan-interrogate\n\nDrive a plan from sketch to commitment by resolving every open decision\nbefore any code is written.\n\n## Method\n\n1. Restate the plan in one paragraph. Confirm with the user that this is\n the plan being interrogated. Do not proceed on a mis-restatement.\n2. Extract the decision tree. Every branch point becomes a node. Mark\n each node as **open** (undecided) or **resolved**. A resolved node\n carries a source tag: `user` (the user answered), `inferred` (the\n codebase or an existing constraint settled it).\n3. Resolve in dependency order. A node is ready when every node it\n depends on is resolved.\n4. For each ready open node, ask exactly one question. Keep the question\n tight and binary or small-multiple-choice when possible.\n5. Pair every question with a **recommended answer** and one sentence of\n reasoning. The user can confirm, pick a different option, or push back.\n6. Before asking, check whether the answer already lives in the codebase,\n prior commits, or an existing doc. If so, skip the question and mark\n the node resolved with source `inferred: `.\n7. Exit only when zero nodes are open. Print the resolved tree as a flat\n list: `Decision - Choice - Source (user | inferred: )`.\n\n## Anti-patterns\n\n- Asking multiple questions at once. The user loses context and you lose\n the ability to react to each answer individually.\n- Asking before exploring. If a fifteen-second read would answer the\n question, read first.\n- Asking without a recommendation. A question without a stance is a\n survey; it offloads design onto the user.\n- Rolling past an unresolved node. If a dependency is not pinned, the\n downstream question is premature.\n\n## Outputs\n\nThe interrogation produces three artifacts, not just answers. Offer to write\neach; do not force it.\n\n1. **Decision ledger** (always). The resolved tree as a flat list:\n `Decision - Choice - Source (user | inferred: )`.\n\n2. **`CONTEXT.md`** (when the interrogation surfaced project-specific terms).\n A short shared-language file: every domain term you and the user had to\n pin down, with a one-line definition in the project's own words. This is\n what stops the agent from using twenty words where one will do next\n session, and keeps names in code consistent. One term per line:\n `term - what it means here`. Point future sessions at it. On re-run, merge\n new terms in place rather than overwriting existing ones.\n\n3. **Decision records** (for contested or hard-to-reverse nodes only). One\n short record per decision that a future reader would question: the\n context, the choice, the alternatives rejected, and why. Keep them in\n `docs/decisions/NNNN-slug.md`. Read the directory first and number from the\n highest existing record so two records never collide. Skip the obvious ones -\n a record for a trivial choice is noise.\n\n## Output contract\n\nThe decision ledger the user can paste into the plan doc. No prose summary.\nNo hedging. If the user declines to decide a node, mark it `DEFERRED` with\nthe reason the user gave - this is not the same as open. When you write\n`CONTEXT.md` or a decision record, keep it in the project's language, not a\ngeneric template.","createdAt":"2026-09-25T11:52:10.010Z","updatedAt":"2026-09-25T11:52:10.010Z"}],"total":52,"limit":24,"offset":0}