К основному содержанию
скилл CX Codex

fix · parcadei — скилл для Claude Code: оркестратор исправления багов

Скилл-оркестратор: разбирает баг по цепочке от диагностики до коммита. Пригодится, когда непонятно, с чего начать починку.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add parcadei/Continuous-Claude-v3 --skill fix -a claude-code
Открыть на GitHub

Что делает fix

fix — мета-скилл, который сам выбирает маршрут для починки. Он разбивает работу на цепочки специализированных скиллов и ведёт по ним. Для обычного бага это debug → implement_task → test-driven-development → commit. Для хуков Claude — debug-hooks → hook-developer → implement_task → тест хука. Для проблем с зависимостями — dependency-preflight → oracle → plan-agent → implement_plan → qlty-check. Для комментариев в PR — github-search → research-codebase → plan-agent → implement_plan → commit.

Если запустить /fix без аргументов, скилл задаёт вопросы через AskUserQuestion: что чинить, в чём суть проблемы, насколько глубоко копать, писать ли регрессионный тест и делать ли коммит. Есть флаги: --no-test пропускает создание теста, --dry-run только диагностирует без правок, --no-commit не коммитит автоматически. На этапе диагностики скилл запускает субагента sleuth параллельно — тот смотрит логи, состояние базы, git и запущенные процессы — и показывает отчёт с гипотезой и списком файлов на правку.

Перед реализацией скилл ждёт подтверждения: без ответа пользователя правки не начинаются. Это значит, что автопилота здесь нет — придётся прочитать диагноз и согласиться. Скилл работает в Claude, Codex, Cursor, GitHub Copilot, Gemini CLI и OpenCode.

Какие задачи решает

  • разобрать баг по цепочке от диагностики до коммита
  • понять причину падения по логам, состоянию базы и git
  • починить хук Claude, который не срабатывает
  • разрулить ошибки импортов и зависимостей
  • закрыть замечания ревьюера из комментариев в PR

Примеры запросов агенту

  • /fix bug кнопка логина не реагирует в Safari
  • /fix hook хук не срабатывает при сохранении файла
  • /fix deps ошибка импорта пакета при сборке

Как установить fix

1Через Skills CLI (Vercel)

npx skills add parcadei/Continuous-Claude-v3 --skill fix -a claude-code

2Вручную: положить файлы

~/.claude/skills/fix/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/fix/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о fix

Как установить fix в Claude?

Выполните npx skills add parcadei/Continuous-Claude-v3 --skill fix -a claude-code. После установки файл скилла лежит в ~/.claude/skills/fix/SKILL.md.

Что делает fix?

Это мета-скилл-оркестратор: он выбирает цепочку скиллов под тип проблемы — баг, хук, зависимости или комментарии в PR — и проводит по ней от диагностики до теста и коммита.

Можно ли запустить fix без правок кода?

Да, с флагом --dry-run: скилл только диагностирует и показывает отчёт, код не меняет.

Исходный текст

SKILL.md · MIT
---
name: fix
description: Meta-skill workflow orchestrator for bug investigation and resolution. Routes to debug, implement, test, and commit based on scope.
allowed-tools: [Bash, Read, Grep, Write, Edit, Task]
---

# Fix

Workflow orchestrator for bug investigation and resolution. Chains specialized skills based on issue scope.

## Usage

```
/fix <scope> [options] [description]
```

## Question Flow (No Arguments)

If the user types just `/fix` with no or partial arguments, guide them through this question flow. Use AskUserQuestion for each phase.

### Phase 0: Workflow Selection

```yaml
question: "What would you like to fix?"
header: "Fix type"
options:
  - label: "Help me choose (Recommended)"
    description: "I'll ask questions to pick the right fix workflow"
  - label: "Bug - something is broken"
    description: "Chain: investigate → diagnose → implement → test → commit"
  - label: "Hook - Claude Code hook issue"
    description: "Chain: debug-hooks → hook-developer → implement → test"
  - label: "Dependencies - import/package errors"
    description: "Chain: preflight → research → plan → implement → qlty-check"
  - label: "PR Comments - address reviewer feedback"
    description: "Chain: github-search → research → plan → implement → commit"
```

**Mapping:**
- "Help me choose" → Continue to Phase 1-4 questions
- "Bug" → Set scope=bug, skip to Phase 2 (issue details)
- "Hook" → Set scope=hook, skip to Phase 2 (issue details)
- "Dependencies" → Set scope=deps, skip to Phase 2 (issue details)
- "PR Comments" → Set scope=pr-comments, skip to Phase 2 (issue details)

**If Answer is Unclear (via "Other"):**
```yaml
question: "I want to understand what kind of fix you need. Did you mean..."
header: "Clarify"
options:
  - label: "Help me choose"
    description: "Not sure - guide me through questions"
  - label: "Bug - something is broken"
    description: "Code isn't working as expected"
  - label: "Hook - Claude Code hook issue"
    description: "Hooks not firing or producing wrong output"
  - label: "Neither - let me explain differently"
    description: "I'll describe my issue"
```

### Phase 1: Issue Type

```yaml
question: "What kind of issue are you dealing with?"
header: "Issue type"
options:
  - label: "Something is broken/not working"
    description: "Bug in the code"
  - label: "Claude Code hook not firing"
    description: "Hook-specific debugging"
  - label: "Import/dependency errors"
    description: "Package or module issues"
  - label: "Need to address PR feedback"
    description: "Reviewer comments to fix"
```

**Mapping:**
- "Something broken" → bug scope
- "Hook not firing" → hook scope
- "Import errors" → deps scope
- "PR feedback" → pr-comments scope

### Phase 2: Issue Details

```yaml
question: "Can you describe the issue?"
header: "Details"
options: []  # Free text - user describes the problem
```

Capture the error message, unexpected behavior, or PR link.

### Phase 3: Investigation Depth

```yaml
question: "How should I investigate?"
header: "Investigation"
options:
  - label: "Diagnose and fix"
    description: "Find the problem and implement a fix"
  - label: "Diagnose only (dry run)"
    description: "Just tell me what's wrong, don't change code"
  - label: "Quick fix"
    description: "I know the issue, just fix it fast"
```

**Mapping:**
- "Diagnose only" → --dry-run
- "Quick fix" → skip investigation, go straight to spark agent

### Phase 4: Testing & Commit

```yaml
question: "After fixing, should I..."
header: "After fix"
multiSelect: true
options:
  - label: "Write a regression test"
    description: "Prevent this bug from recurring"
  - label: "Commit the fix"
    description: "Create a git commit"
  - label: "Just fix, nothing else"
    description: "I'll handle tests and git"
```

**Mapping:**
- No "regression test" → --no-test
- No "commit" → --no-commit

### Summary Before Execution

```
Based on your answers, I'll run:

**Scope:** bug
**Issue:** "Login button not responding on Safari"
**Chain:** sleuth (investigate) → spark (fix) → arbiter (test) → commit
**Options:** (none)

Proceed? [Yes / Adjust settings]
```

## Scopes

| Scope | Chain | Description |
|-------|-------|-------------|
| `bug` | debug -> implement_task -> test-driven-development -> commit | General bug fix workflow |
| `hook` | debug-hooks -> hook-developer -> implement_task -> test hook | Hook-specific debugging |
| `deps` | dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check | Dependency issues |
| `pr-comments` | github-search -> research-codebase -> plan-agent -> implement_plan -> commit | Address PR feedback |

## Options

| Option | Effect |
|--------|--------|
| `--no-test` | Skip regression test creation |
| `--dry-run` | Diagnose only, don't implement fix |
| `--no-commit` | Don't auto-commit the fix |

## Workflow

### Phase 1: Parse Arguments

```bash
# Parse scope and options
SCOPE="${1:-bug}"
NO_TEST=false
DRY_RUN=false
NO_COMMIT=false

for arg in "$@"; do
  case $arg in
    --no-test) NO_TEST=true ;;
    --dry-run) DRY_RUN=true ;;
    --no-commit) NO_COMMIT=true ;;
  esac
done
```

### Phase 2: Investigation (Parallel)

Spawn sleuth agent for parallel investigation:

```
Task(
  subagent_type="sleuth",
  prompt="""
  Investigate this issue in parallel:

  1. **Logs**: Check recent logs for errors
     - Application logs
     - System logs if relevant
     - Build/test output

  2. **Database State** (if applicable):
     - Check for stuck/invalid records
     - Verify schema matches expectations

  3. **Git State**:
     - Recent commits that might relate
     - Uncommitted changes
     - Current branch context

  4. **Runtime State**:
     - Running processes
     - Port conflicts
     - Environment variables

  Issue description: {user_description}

  Return structured findings with evidence.
  """
)
```

### Phase 3: Diagnosis Report

Present findings to user:

```markdown
## Diagnosis Report

### Scope: {scope}

### Evidence Found

**Logs:**
- [Finding with timestamp/line reference]

**Database:**
- [Finding with table/query reference]

**Git State:**
- [Recent relevant commits]
- [Uncommitted changes]

**Runtime:**
- [Process/port findings]

### Root Cause Analysis

**Primary Hypothesis:** [Most likely cause based on evidence]

**Supporting Evidence:**
1. [Evidence 1]
2. [Evidence 2]

**Alternative Hypotheses:**
- [Alternative 1]: [Why less likely]

### Proposed Fix

**Approach:** [How to fix]

**Files to Modify:**
- `path/to/file.ts:123` - [Change description]

**Risk Assessment:** [Low/Medium/High] - [Why]

---

**Proceed with fix?** (yes/no/modify approach)
```

### Phase 4: Human Checkpoint (Diagnosis)

**REQUIRED:** Wait for user confirmation before implementing.

```
AskUserQuestion(
  question="Proceed with the proposed fix?",
  options=["yes", "no", "modify"]
)
```

If user says "modify", gather new requirements and update approach.
If user says "no", create diagnostic handoff and exit.
If `--dry-run`, create diagnostic handoff and exit here.

### Phase 4.5: Risk Assessment (Premortem)

**After diagnosis approval, before implementation:**

Run a quick premortem on the proposed fix to catch risks:

```
/premortem quick
```

**Context for premortem:**
```yaml
premortem:
  mode: quick
  context: "Bug fix for {diagnosis.root_cause}"

  check_for:
    - Will this fix break other functionality?
    - Is rollback possible if fix causes issues?
    - Are there related edge cases not covered?
    - Does the fix match codebase patterns?
    - Any external dependencies affected?
```

**Risk Decision:**
- **No HIGH tigers**: Proceed to implementation
- **HIGH tigers found**: Present to user with options:
  - Accept risks and proceed
  - Modify approach to address risks
  - Research mitigation strategies

```
AskUserQuestion(
  question="Pre-mortem found {n} risks in the proposed fix. Proceed?",
  options=[
    "Accept risks and implement",
    "Modify fix approach",
    "Research mitigations first"
  ]
)
```

If "Research mitigations", spawn scout + oracle in parallel per risk, then re-present options.

### Phase 5: Implementation

Route to appropriate implementation skill based on scope:

#### bug scope:
```
Task(
  subagent_type="kraken",
  prompt="""
  Implement fix with TDD approach.

  Root cause: {diagnosis.root_cause}
  Files: {diagnosis.files_to_modify}
  Approach: {diagnosis.approach}

  Follow implement_task workflow:
  1. Write failing test that reproduces the bug
  2. Implement minimal fix to pass test
  3. Refactor if needed
  4. Run full test suite
  """
)
```

#### hook scope:
```
Task(
  subagent_type="kraken",
  prompt="""
  Fix hook issue.

  Root cause: {diagnosis.root_cause}

  Follow hook-developer patterns:
  1. Check hook registration in settings.json
  2. Verify shell wrapper exists and is executable
  3. Test hook manually with mock input
  4. Rebuild if TypeScript source was modified
  5. Verify hook fires correctly
  """
)
```

#### deps scope:
```
Task(
  subagent_type="kraken",
  prompt="""
  Fix dependency issue.

  Root cause: {diagnosis.root_cause}

  Follow plan-agent workflow:
  1. Research correct dependency versions
  2. Create implementation plan
  3. Update lockfiles
  4. Run dependency-preflight
  5. Run qlty-check
  """
)
```

#### pr-comments scope:
```
Task(
  subagent_type="kraken",
  prompt="""
  Address PR feedback.

  Comments: {diagnosis.pr_comments}

  Follow plan-agent workflow:
  1. Research codebase for context
  2. Create implementation plan for each comment
  3. Implement changes
  4. Commit with reference to comment
  """
)
```

### Phase 6: Regression Test (unless --no-test)

```
Task(
  subagent_type="kraken",
  prompt="""
  Create regression test for the fix.

  Bug: {original_issue}
  Fix: {implementation_summary}

  Follow test-driven-development:
  1. Write test that would have caught this bug
  2. Verify test fails against pre-fix code (mentally)
  3. Verify test passes against fixed code
  4. Test should be minimal and focused
  """
)
```

### Phase 7: Human Checkpoint (Verification)

```
AskUserQuestion(
  question="Fix implemented. Please verify and confirm.",
  options=["looks good", "needs adjustment", "revert"]
)
```

If "needs adjustment", gather feedback and return to Phase 5.
If "revert", run rollback command and exit.

### Phase 8: Commit (unless --no-commit)

```
Task(
  subagent_type="general-purpose",
  prompt="""
  Follow commit skill:

  1. Review changes with git diff
  2. Create descriptive commit message
  3. Reference issue/ticket if applicable
  4. Present plan and await confirmation
  5. Execute commit
  """
)
```

## Chain Details by Scope

### bug

```
sleuth (investigation)
  |
  v
[HUMAN CHECKPOINT: diagnosis]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_task + TDD)
  |
  v
kraken (regression test)
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit
```

### hook

```
debug-hooks (structured investigation)
  |
  v
[HUMAN CHECKPOINT: diagnosis]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_task + hook-developer patterns)
  |
  v
test hook manually
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit
```

### deps

```
dependency-preflight (check current state)
  |
  v
oracle (find correct versions/alternatives)
  |
  v
plan-agent (create fix plan)
  |
  v
[HUMAN CHECKPOINT: diagnosis + plan review]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_plan)
  |
  v
qlty-check
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit
```

### pr-comments

```
github-search (fetch PR context)
  |
  v
research-codebase (understand context)
  |
  v
plan-agent (plan for each comment)
  |
  v
[HUMAN CHECKPOINT: plan review]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_plan)
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit (reference PR comments)
```

## Handoff Creation

**Always create a handoff**, even with `--dry-run`:

```yaml
---
session: fix-{scope}-{short-description}
ts: {ISO timestamp}
commit: {git commit hash}
branch: {git branch}
status: {complete|partial|blocked|diagnosis-only}
---

scope: {bug|hook|deps|pr-comments}
options: {flags used}

issue:
  description: {original user description}
  evidence: {key findings from investigation}

diagnosis:
  root_cause: {identified cause}
  hypothesis: {why we think this}
  files: [{affected files}]

fix:
  approach: {what was done}
  files_modified: [{files changed}]
  test_added: {test file if created}

verification:
  test_command: {command to verify}
  human_confirmed: {true|false}

next:
  - {any follow-up needed}
```

**Location:** `thoughts/shared/handoffs/fix/{scope}/{timestamp}_{description}.yaml`

## Examples

### Basic Bug Fix
```
/fix bug
# -> Investigates, diagnoses, implements, tests, commits
```

### Diagnose Only
```
/fix bug --dry-run
# -> Investigates, creates diagnosis handoff, stops
```

### Fix Without Auto-Commit
```
/fix hook --no-commit
# -> Full fix workflow but stops before commit
```

### Quick Fix (No Regression Test)
```
/fix bug --no-test
# -> Implements fix, commits, no regression test
```

### Address PR Comments
```
/fix pr-comments
# -> Fetches PR, creates plan, implements, commits
```

## Error Handling

| Error | Action |
|-------|--------|
| Investigation finds nothing | Ask user for more context |
| User rejects diagnosis | Refine hypothesis with user input |
| Fix breaks other tests | Rollback, refine approach |
| User rejects verification | Offer to revert or adjust |
| Commit fails | Present error, offer retry |

## Integration with Other Skills

This skill orchestrates:
- `debug` / `debug-hooks`: Initial investigation
- `sleuth`: Parallel investigation agent
- `kraken`: TDD implementation agent
- `implement_task`: Single task implementation
- `test-driven-development`: Test creation
- `plan-agent`: Complex fix planning
- `dependency-preflight`: Dependency checks
- `oracle` / `research-codebase`: Context gathering
- `github-search`: PR context fetching
- `qlty-check`: Quality verification
- `premortem`: Risk assessment before implementation
- `commit`: Git commit workflow
- `create_handoff`: Session handoff

## Checkpoints Summary

| Checkpoint | Purpose | Skip Condition |
|------------|---------|----------------|
| After diagnosis | Confirm root cause | Never skip |
| After premortem | Accept or mitigate risks | No HIGH tigers |
| After fix | Verify resolution | Never skip |
| Before commit | Review changes | `--no-commit` |

The human checkpoints are critical for:
1. Preventing wrong fixes from being implemented
2. Ensuring user understands what changed
3. Catching edge cases only humans notice

© parcadei · MIT · parcadei/Continuous-Claude-v3

Похожие скиллы

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →

Сначала — fix от других авторов.

fix react Скилл запускает форматирование и проверку lint перед коммитом. Пригодится, когда нужно подготовить изменённые файлы к CI. CX Codex +1 2 300установок fix Alireza Rezvani Разбирает падающий или нестабильный Playwright-тест по категориям и доводит его до стабильного прохождения. Пригодится, когда тест падает в CI, а локально проходит. 1 638установок fix-sentry-issues brianlovin Скилл находит сбои через Sentry MCP, сортирует их и устраняет первопричину в кодовой базе. Помогает при разборе аварийных всплесков и очистке логов от шума. CX Codex +1 2 700установок sentry-fix-issues getsentry Ищет ошибки в Sentry через MCP-сервер, разбирает трейсы и готовит исправления в коде. Пригодится при разборе инцидентов и багов в продакшене. CX Codex +1 10 000установок reproduce-and-fix-issues cursor Автоматизирует воспроизведение багов из тредов Slack через управление UI приложения и готовит черновой пуллреквест при наличии подтверждения. Работает в связке с системой Benny. CX Codex +1 822установок fix-agent-issue mlflow Скилл ведёт агента по циклу EXPLORE → PLAN → IMPLEMENT → VERIFY, чтобы правка поведения опиралась на трейс и тест, а не на догадку. CX Codex +1 365установок focused-fix Alireza Rezvani Скилл для сквозного ремонта сломанных модулей и фич по строгому протоколу из пяти фаз. Пригодится, когда одиночные правки не помогают и сбоит вся функциональность. 600установок fix-merge-conflicts cursor Разрешает конфликты слияния в ветке, проверяет сборку и тесты перед завершением работы. Нужен, когда конфликтов несколько и их надо разобрать без рефакторинга. CX Codex +1 2 700установок

Из того же набора69

loogle-search Ищет леммы в Mathlib по форме типа, когда имя забыто, а сигнатура примерно известна. Пригодится в доказательствах на Lean. CX Codex +1 485установок tldr-overview Скилл собирает карту незнакомого проекта через стек TLDR: дерево файлов, структуру кода, граф вызовов и сложные функции. CX Codex +1 485установок research Исследует кодовую базу и описывает текущую архитектуру без критики и рефакторинга. Запускает субагентов для анализа файлов и сохраняет отчёт в каталог thoughts. CX Codex +1 485установок search-router Подсказывает агенту, каким инструментом искать код: TLDR, AST-grep, семантикой или Grep. Экономит токены на разведке по репозиторию. CX Codex +1 485установок qlty-check Скилл гоняет qlty CLI по вашему коду: линтеры, автофикс, форматирование и метрики сложности. Пригодится перед коммитом или передачей работы. CX Codex +1 484установок braintrust-analyze Скилл анализирует трейсы сессий Claude Code через Braintrust. Находит зацикливания инструментов, оценивает расход токенов и показывает статистику по вызовам агентов. CX Codex +1 484установок pint-compute Считает величины с единицами через Pint: переводит меры, проверяет размерности и упрощает составные единицы. Нужен для расчётов, где нельзя смешивать несовместимые величины. CX Codex +1 482установок release Прогоняет релиз через пять субагентов: аудит безопасности, E2E-тесты, финальное ревью, бамп версии и релизные заметки. Пригодится перед выкладкой в прод. CX Codex +1 481установок

Спонсоры проекта

Компании, которые помогают держать аналитику открытой