skills/resolve/SKILL.md
--- name: resolve description: Modular ticket resolution workflow orchestrator. Loads steps dynamically based on mode and current state. argument-hint: [ticket-id] [--auto] [--continue] [--refine-plan] [--plan-only] [--init] [--source youtrack|github] [--skip-simplify] [--skip-review] [--pr] [--draft] [--wait-for-ci [N]] allowed-tools: Read, Glob, Grep, Bash, Write, Edit, Agent, AskUserQuestion, mcp__youtrack__get_issue, mcp__youtrack__get_issue_comments, mcp__youtrack__get_issue_attachments, mc
npx skillsauth add nicolas-codemate/claudecodeconfig skills/resolveInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Arguments passed from command: $ARGUMENTS
<ticket_resolution>
If ticket_id is NOT provided in arguments (and NOT --init mode):
ls -1 .claude-work/ 2>/dev/null || echo ""
| Mode | 0 tickets | 1 ticket | Multiple tickets | |------|-----------|----------|------------------| | AUTO | ERROR: "Aucun ticket en cours. Specifiez un ticket-id." | Use that ticket automatically | ERROR: "Plusieurs tickets en cours: {list}. Specifiez le ticket-id." | | INTERACTIVE | Prompt for ticket ID | Ask to confirm or enter different | Ask user to choose from list |
AskUserQuestion:
questions:
- question: "Aucun ticket en cours. Quel ticket voulez-vous traiter ?"
header: "Ticket"
multiSelect: false
options:
- label: "Saisir le ticket ID"
description: "Entrer manuellement le numero de ticket"
AskUserQuestion:
questions:
- question: "Ticket en cours detecte: {ticket-id}. Continuer avec celui-ci ?"
header: "Ticket"
multiSelect: false
options:
- label: "Oui, continuer avec {ticket-id}"
description: "Reprendre le workflow existant"
- label: "Non, autre ticket"
description: "Saisir un autre ticket ID"
AskUserQuestion:
questions:
- question: "Plusieurs tickets en cours. Lequel traiter ?"
header: "Ticket"
multiSelect: false
options:
- label: "{ticket-1}"
description: "State: {state from status.json}"
- label: "{ticket-2}"
description: "State: {state from status.json}"
# ... up to 4 options, then "Autre" for more
</ticket_resolution>
<mode_detection>
| Flag | Mode | Starting Step |
|-------------------|-------------|--------------------------|
| --init | INIT | 00-initialization (config only) |
| --continue | CONTINUE | 06-implement |
| --refine-plan | REFINE | 05-plan-validation |
| --auto | AUTO | 00-initialization |
| (default) | INTERACTIVE | 00-initialization |
</mode_detection>
Implementation (step 06) is not the end. The full AUTO sequence is:
06-implement → 07-simplify → 08-review → 09-finalize
Each step's Transition section tells you exactly which step file to load next.
</workflow>
<critical_paths>
Feature directory structure — all workflow files are stored in .claude-work/{ticket-id}/:
status.json - Workflow state and optionsticket.md - Ticket contentplan.md - Implementation planimplementation-notes.md - Running notes maintained during step 06: design decisions, deviations, tradeoffs, open questions. Surfaced in INTERACTIVE mode after each phase, displayed in full at the end (step 09).The resolve directory (
.claude-work) is configurable viafeature_dirinticket-config.json.
Do not use docs/ for workflow files — always .claude-work/{ticket-id}/.
</critical_paths>
<base_branch_rule>
Base branch usage — all git diff operations should use the base branch from status.json:
# Read base branch from status
BASE_BRANCH=$(cat .claude-work/{ticket-id}/status.json | jq -r '.options.base_branch')
# Use it in all diff operations
git diff ${BASE_BRANCH}...HEAD
git diff --name-only ${BASE_BRANCH}...HEAD
Do not hardcode main, master, or develop in git diff commands. Do not use HEAD~1 to detect changes — always compare against the base branch.
Base Branch Lifecycle:
main)base_branch from the ticket's milestone/target
base_branch from status.jsonThe ticket's milestone takes precedence over default detection. </base_branch_rule>
<step_flow>
00-initialization → 01-fetch-ticket [AGENT] → 02-analyze-complexity
→ 03-exploration [AGENT] → 04-create-plan [AGENT] → 05-plan-validation
→ 06-implement [AGENT] → 07-simplify [AGENT] → 08-review [AGENT] → 09-finalize
| ^
+-- /resolve --continue -----------------------------+
00-initialization → 01-fetch-ticket [AGENT] → 02-analyze-complexity
→ 03-exploration [AGENT] → 04-create-plan [AGENT] → 05-plan-validation
→ 06-implement [AGENT] → 07-simplify [AGENT] → 08-review [AGENT] → 09-finalize
(verify status) → 06-implement [AGENT] → 07-simplify [AGENT] → 08-review [AGENT] → 09-finalize
(load context) → 05-plan-validation (refine loop) → 06-implement [AGENT] → ...
00-initialization (config only) → STOP
00-initialization → ... → 05-plan-validation → STOP (display plan + next steps)
</step_flow>
Subagent model and effort are determined by complexity (stored in status.json as model_config):
| Complexity | Model | Effort | Rationale | |------------|-------|--------|-----------| | SIMPLE | sonnet | medium | Cost-efficient for trivial changes | | MEDIUM | opus | high | Full reasoning for multi-component work | | COMPLEX | opus | max | Deepest reasoning, no token constraints (Opus 4.6 only) |
The model parameter is passed to all delegated agents (steps 03, 04, 06, 07).
Step 08 (review) always uses opus via the code-reviewer agent definition.
The effort level applies to the main orchestrator session (set via /effort or status context).
| Step | Execution | Reason |
|------|-----------|--------|
| 00-initialization | INLINE | Lightweight config |
| 01-fetch-ticket | DELEGATED | MCP responses (YouTrack, Figma) consume context |
| 02-analyze-complexity | INLINE | Lightweight scoring |
| 03-exploration | DELEGATED | Already uses Explore agents |
| 04-create-plan | DELEGATED | Reads ticket.md + analysis.md, generates plan |
| 05-plan-validation | INLINE | User interaction must stay in main thread |
| 06-implement | DELEGATED | Biggest context consumer - fresh context is critical |
| 07-simplify | DELEGATED | Invokes bundled /simplify skill (multi-angle technical review with auto-applied fixes) |
| 08-review | DELEGATED | Product-fit review via code-reviewer agent (ticket coverage, acceptance criteria) |
| 09-finalize | INLINE | Lightweight git push + PR |
Delegated step pattern: Each delegated step file has two sections:
This eliminates the need for /compact or session breaks between planning and implementation.
</delegation>
See ~/.claude/skills/resolve/references/modes.md for detailed mode behaviors.
See ~/.claude/skills/resolve/references/coding-guidelines.md for the three non-negotiable principles applied during implement (06): reuse before creating, readability over cleverness, comment frugality.
Step 07 (simplify) delegates to the bundled /simplify skill, which uses its own technical review taxonomy and does NOT read this file — accept that trade-off in exchange for broader multi-angle coverage. Step 08 (review) is scoped to product fit only and does not enforce these technical principles either; they are enforced upstream at implementation time and at the simplify pass.
| Step | File | Description |
|------|------|-------------|
| 00 | steps/00-initialization.md | Setup, config loading, feature directory |
| 01 | steps/01-fetch-ticket.md | Retrieve ticket, extract Figma URLs, user context |
| 02 | steps/02-analyze-complexity.md | Score complexity, determine workflow type |
| 03 | steps/03-exploration.md | Explore codebase based on complexity |
| 04 | steps/04-create-plan.md | Generate implementation plan |
| 05 | steps/05-plan-validation.md | Validate/refine plan interactively |
| 06 | steps/06-implement.md | Execute plan, visual verification |
| 07 | steps/07-simplify.md | Technical review + simplification via bundled /simplify |
| 08 | steps/08-review.md | Product-fit review (ticket coverage + acceptance criteria) |
| 09 | steps/09-finalize.md | Push and create PR |
All user communication in French. Technical output (git, code, files) in English.
Begin workflow for: $ARGUMENTS
tools
--- name: deep-review description: Performs deep code review via an isolated fresh agent (triple perspective, anti-bias). Use when the user asks for an in-depth review of current branch changes, or when invoked by /resolve step 08. Do NOT use for reviewing PRs from GitHub (use review-pr skill instead) or for a quick correctness scan with effort levels (use bundled /code-review instead). argument-hint: [--ticket <id>] [--base <branch>] [--fix] [--severity <level>] allowed-tools: Read, Glob, Grep,
tools
Resolve git rebase conflicts methodically. Classifies each conflict (imports/namespace cleanup vs real logic clash), analyzes the commit introducing the change against the current ticket context, auto-fixes only trivial cases with a per-file summary, and asks the user when ambiguous. Verifies static analysis tools pass at the end and optionally runs functional tests. Use after `git rebase` triggers conflicts, or when the user asks to "resolve conflicts", "fix rebase", "j'ai des conflits", "aide-moi sur ce rebase".
development
Synchronize the markdown test plan in docs/qa/ with the current state of the codebase. Use after adding or modifying features to keep the plan up to date, or to bootstrap a test plan for the first time. Do NOT use to execute tests (use /qa-run instead) and do NOT use to design product specs (use /express-need instead).
tools
Execute the markdown test plan in docs/qa/ via Playwright MCP and create a ticket on each failing scenario. Use after /qa-sync, before a release, or to validate a feature end-to-end. Do NOT use to design or update scenarios (use /qa-sync instead) and do NOT use for visual regression (use visual-verify agent instead).