메뉴
This skill should be used when the user asks to "analyze a task", "route a command", "what craft command should I use", or describes a development task that needs routing to the appropriate craft workflow. Analyzes natural language task descriptions and maps them to optimal craft command sequences.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
This skill should be used when the user asks to "pre-flight check", "validate before commit", "validate before PR", "validate before deploy", "is this ready to ship", "check readiness", "run pre-flight", "validate project state", or wants context-aware validation across commit/PR/release/deploy boundaries. Orchestrates universal validators (lint, tests, types, version sync, stale refs, docs, hook conflicts) and supports generating new custom validators.
This skill should be used when a command's --refine flag is set, or the user asks to "refine my prompt", "optimize this prompt", "make this request sharper" — rewrites a vague natural-language request into a specific, well-structured prompt using project context, shows before/after, and confirms before the caller proceeds. Replaces the deprecated /craft:refine command.
This skill should be used when the user asks to "release", "create a release", "ship it", "publish a new version", "bump version and release", "cut a release", or mentions releasing to GitHub/npm/PyPI. Orchestrates the full release pipeline from pre-flight checks through GitHub release creation.
ADHD-friendly session and task workflow for craft users — captures context at session end, restores it at session start, picks the next task, breaks through blockers, holds focus on one task, reviews a craft spec, or refines a vague craft prompt. Use when wrapping up or resuming a coding session, when deciding what to work on next (also "what's next", "pick a task for me", "give me something to do"), when stuck or in decision paralysis, when focusing on a single craft task, or when reviewing/refining a craft spec or prompt. The full intent-to-operation map is in the "When to Use" table below.
This skill should be used when the user asks to "init a repo", "set up git", "manage branches", "switch branch", "create a worktree", "list worktrees", "clean merged branches", "sync with remote", "git activity", "git recap", "protect main", "apply branch protection", "bypass protection", "undo a commit", "fix a git mistake", or mentions git lifecycle, worktrees, branch protection, GitHub-side baseline protection, safety rails, or learning git workflows. Covers craft's full git lifecycle — repo init, branch and worktree management, remote sync, status/recap, local and GitHub-side branch protection, and the learning/safety reference docs.
This skill should be used when the user asks "what's my friction", "session insights", "friction report", "what patterns am I hitting", "analyze my sessions", "generate insights report", "aggregate facets", or "show CLAUDE.md suggestions". Aggregates session facet history into a friction/goals report. Formerly bundled with the brainstorm skill (ideation); split out because the two operations share no input or output. Directory name kept as brainstorm-insights for path stability — tests and references/insights.md reference it.
| name | task-analyzer |
| description | This skill should be used when the user asks to "analyze a task", "route a command", "what craft command should I use", or describes a development task that needs routing to the appropriate craft workflow. Analyzes natural language task descriptions and maps them to optimal craft command sequences. |
Expert in analyzing natural language task descriptions and routing to appropriate craft commands.
This skill is automatically activated when:
/craft:do <task>/craft:do referencesthis table instead of duplicating it; see commands/do.md's Task Categories section)
Identifies task intent from natural language. Category names match /craft:do's
routing categories exactly (renamed 2026-07-04 to eliminate a naming drift where this
table used different labels — Create/Fix/Document/Refactor/Review — for the same 7
concepts /craft:do already routes on as Feature/Bug/Docs/Architecture, plus a
missing Quality category /craft:do has and this table didn't):
| Intent | Keywords | Example |
|---|---|---|
| Feature | add, create, implement, build, new | "add user authentication" |
| Bug | fix, debug, resolve, repair, issue, error | "fix the login bug" |
| Quality | lint, quality, clean, improve | "clean up the utils module" |
| Test | test, verify, check, validate, coverage | "test the api endpoints" |
| Docs | document, docs, readme, changelog, explain | "document the api" |
| Release | release, deploy, publish, ship | "prepare for release" |
| Architecture | design, refactor, restructure, review, audit, analyze | "refactor the utils module" |
Judgment call made here: the former standalone "Review" intent (review, audit,
analyze) had no corresponding category or command mapping in /craft:do at all — folded
its keywords into Architecture rather than inventing an 8th category /craft:do
would have no routing for.
Identifies affected domain from context:
| Domain | Indicators | Commands |
|---|---|---|
| API | api, endpoint, rest, graphql | arch:plan, code:test-gen |
| UI | ui, component, page, view | frontend-designer skill |
| Database | db, database, model, schema | backend-designer skill |
| Auth | auth, login, permission | arch:plan, code:test-gen |
| Testing | test, coverage, spec | test, test --coverage |
| Docs | docs, readme, changelog | docs:sync, docs:validate |
Maps intent + domain to optimal command sequence:
Feature Workflow:
1. /craft:arch:plan - Design the feature
2. /craft:code:test-gen - Generate tests (TDD)
3. dev/git skill - Create feature branch (ask naturally; folded from /craft:git:branch)
4. → Implementation - User implements
5. /craft:test - Verify tests pass
6. dev/git skill - Commit/sync changes (ask naturally; folded from /craft:git:sync)
Bug Fix Workflow:
1. /craft:code:debug - Analyze the issue
2. /craft:test debug - Isolate in tests
3. → Fix - User implements fix
4. /craft:test - Verify fix
5. /craft:git:sync - Commit fix
Release Workflow:
1. /craft:code:deps-audit - Security scan
2. /craft:test release - Full test suite
3. /craft:code:lint release - Comprehensive lint
4. /craft:docs:changelog - Update changelog
5. /craft:code:release - Release workflow
When a task description reads like a fixed coded shape —
decompose → cover N → verify M → synthesize — suggest
/craft:orch:workflow, do not silently switch to it.
Detect the shape conservatively (the helper
workflow_parse.detects_workflow_shape(text) fires only when ≥3 of the four
stage categories appear, or the explicit decompose…synthesize chain is
present):
| Stage category | Trigger words |
|---|---|
| decompose | decompose, break down, split into, dimensions, for each |
| fan-out | fan out, in parallel, one per, cover each, per finding, reviewers |
| verify | verify, verifier, double-check, confirm each |
| synthesize | synthesize, aggregate, summarize, combine, merge findings |
Suggest, never switch (routing-false-positive guard). A lone "verify" or
"in parallel" must NOT route anywhere — auto-hijacking a task better served by
improvised orchestrate is the accepted residual risk. On a match, present a
suggestion the user confirms:
This looks like a fixed decompose → cover → verify → synthesize shape.
Consider: /craft:orch:workflow (coded, schema-gated, resumable)
Or keep going with improvised orchestration. Which do you want?
| Input | Detected? | Action |
|---|---|---|
| "decompose into dimensions, review each in parallel, verify, synthesize" | yes | suggest :workflow |
| "fan out reviewers, verify findings, then summarize" | yes | suggest :workflow |
| "verify the login flow works" | no | route normally |
| "review the architecture" | no | route normally |
Determines task complexity for mode selection:
| Complexity | Indicators | Default Mode |
|---|---|---|
| Simple | Single file, quick fix | default |
| Medium | Few files, feature | default |
| Complex | Many files, architecture | debug |
| Critical | Release, security | release |
╭─ Task Analysis ─────────────────────────────────────╮
│ Input: "add user authentication" │
├─────────────────────────────────────────────────────┤
│ Intent: Feature │
│ Domain: Authentication │
│ Complexity: Medium │
│ Workflow: Feature Development │
├─────────────────────────────────────────────────────┤
│ Recommended Commands: │
│ 1. /craft:arch:plan Design auth system │
│ 2. /craft:code:test-gen Generate auth tests │
│ 3. dev/git skill Create feature/auth │
╰─────────────────────────────────────────────────────╯
Works with:
/craft:do - Primary entry point/craft:check - Validation after workflowsInput: "fix typo in readme"
Analysis:
- Intent: Bug
- Domain: Documentation
- Complexity: Simple
- Command: Direct edit (no routing needed)
Input: "implement oauth2 login with google"
Analysis:
- Intent: Feature
- Domain: Authentication + API
- Complexity: Complex
- Workflow: Feature Development
- Skills: backend-designer, devops-helper
- Commands: arch:plan → code:test-gen → git:branch