skills/analyze-ticket/SKILL.md
Internal helper called by /resolve and /mentor. Analyzes ticket complexity (SIMPLE, MEDIUM, COMPLEX) to determine exploration depth and planning approach. Not intended for direct invocation.
npx skillsauth add nicolas-codemate/claudecodeconfig analyze-ticketInstall 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.
This skill analyzes a ticket's content to determine its complexity and decide which workflow phases are required.
| Level | Score | Exploration | Planning | AEP | Architect | |-------|-------|-------------|----------|-----|-----------| | SIMPLE | 0-2 | Skip | Basic | No | No | | MEDIUM | 3-5 | Light | Standard | Partial | Optional | | COMPLEX | 6+ | Full AEP | Detailed | Full | Yes |
Analyze the ticket content and assign points for each applicable factor:
| Factor | Points | Detection Signals | |--------|--------|-------------------| | Multi-component changes | +2 | Mentions multiple services, modules, or layers | | Database schema changes | +2 | Keywords: migration, schema, table, column, index | | API breaking changes | +3 | Keywords: breaking, deprecate, remove endpoint, change contract | | New external dependency | +2 | Keywords: integrate, new library, third-party, SDK | | Performance requirements | +2 | Keywords: optimize, performance, latency, throughput | | Security implications | +2 | Keywords: auth, permission, encryption, sensitive data |
| Factor | Points | Detection Signals | |--------|--------|-------------------| | Cross-team coordination | +2 | Mentions other teams, external dependencies | | Multiple file types | +1 | Backend + frontend, or multiple languages | | Test infrastructure changes | +1 | Keywords: test framework, CI/CD, pipeline | | Documentation required | +1 | Explicit doc requirements or public API changes |
| Factor | Points | Detection Signals | |--------|--------|-------------------| | Vague requirements | +2 | Ambiguous language, missing acceptance criteria | | Research needed | +2 | Keywords: investigate, explore, POC, spike | | Unknown impact | +2 | Cannot determine affected components | | No clear success criteria | +1 | Missing "done when" or validation steps |
| Factor | Points | Detection Signals | |--------|--------|-------------------| | Well-defined scope | -1 | Clear, specific requirements | | Single file change | -1 | Obvious single-file fix | | Existing pattern | -1 | Similar to existing code/feature | | Has acceptance criteria | -1 | Clear validation steps provided |
Certain labels can force complexity level:
quick-fix, typo, documentation, trivial, minorcomplexity.simple_labelsneeds-analysis, architecture, breaking-change, migration, epiccomplexity.complex_labelsParse ticket content for complexity signals:
Sum points from all applicable factors.
Check for forcing labels that override calculated score.
if has_simple_label:
level = SIMPLE
elif has_complex_label:
level = COMPLEX
elif score <= simple_threshold (default: 2):
level = SIMPLE
elif score >= complex_threshold (default: 6):
level = COMPLEX
else:
level = MEDIUM
Based on complexity level, recommend workflow phases:
## Complexity Analysis
### Score Breakdown
| Factor | Points | Reason |
|--------|--------|--------|
| Multi-component changes | +2 | Affects API and frontend |
| Database changes | +2 | Requires migration |
| Well-defined scope | -1 | Clear acceptance criteria |
| **Total** | **3** | |
### Classification
**Complexity Level**: MEDIUM (score: 3)
### Label Analysis
- Labels found: `feature`, `backend`
- No complexity-forcing labels detected
### Recommended Workflow
1. **Exploration**: Light (1 focused agent)
2. **Planning**: Standard approach
3. **AEP**: Partial (Analyse + Plan)
4. **Architect Skill**: Optional
### Key Concerns
- Database migration requires careful ordering
- Consider rollback strategy for schema changes
### Suggested Focus Areas
1. Existing migration patterns in codebase
2. Related API endpoints
3. Test coverage for affected components
This skill is invoked by:
/resolve command - after fetch, before workspace setup/analyze-ticket standalone commandReads from .claude/ticket-config.json:
{
"complexity": {
"auto_detect": true,
"simple_labels": ["quick-fix", "typo"],
"complex_labels": ["architecture", "migration"],
"simple_threshold": 2,
"complex_threshold": 6
}
}
Proceed directly to implementation planning.
Launch 1 explore agent to:
Launch up to 3 parallel explore agents:
Agent 1: Implementation Patterns
Agent 2: Impact Analysis
Agent 3: Test Coverage
Analysis output in French for user communication. Technical terms and factor names in English.
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).