원클릭으로
import
Import a tasks.md into the coco tracker as an epic with dependencies, and create matching issues in the configured issue tracker.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Import a tasks.md into the coco tracker as an epic with dependencies, and create matching issues in the configured issue tracker.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Execute the next available tracked task with TDD, pre-commit validation, PR workflow, AI code review, and issue tracker bridge sync. Primary execution interface for multi-session feature work.
Single-issue workflow for quick fixes and small changes that don't need full epic tracking. Creates a branch, implements the fix, commits with issue tracking, and closes.
Generate a feature design (design.md) in specs/{feature}/ with user stories, acceptance criteria, technical approach, API contracts, and research decisions.
Pre-design discovery interview that gathers deep user intent through structured questioning. Produces a discovery brief (discovery.md) consumed by the design skill.
Generate a dependency-ordered task list (tasks.md) with sub-phases and cross-artifact consistency analysis from design.md in specs/{feature}/.
SOC 직업 분류 기준
| name | import |
| description | Import a tasks.md into the coco tracker as an epic with dependencies, and create matching issues in the configured issue tracker. |
Import a tasks.md into the coco tracker and optionally create matching issues in the configured issue tracker.
/coco:phase (Step D) or /coco:planning-session tacticalspecs/{feature}/ and needs to be loaded into the trackerPrerequisites: tasks.md must exist. If missing, use the tasks skill first.
specs/{feature}/tasks.md with sub-phases and dependency info.coco/config.yaml exists with project configuration.coco/config.yaml for project.specs_dir and issue_tracker config.feature/ prefix (or whatever pr.branch.feature_prefix is) from the branch name{specs_dir}/{stripped-name}/{specs_dir}/{feature}/tasks.md (required). If missing, instruct user to use the tasks skill first.coco-tracker <command> [args]Extract:
# Tasks: header## Sub-Phase N: section becomes a tracker task[P] tasks within a sub-phasecoco-tracker epic-create "{feature-name}"
IMPORTANT: All coco-tracker create arguments MUST be single-line. Never put literal newlines inside --description, --title, or --metadata values. Use semicolons or commas to separate items within a description. Put each command on one line (no \ continuations).
For each sub-phase:
coco-tracker create --epic "{epic-id}" --title "Sub-Phase {N}: {title}" --description "{single-line summary; task list}" --priority {priority} --metadata '{"sub_phase": N, "issue_key": null, "feature_branch": "{current-branch-name}"}'
If tasks.md includes owns_files annotations (file ownership per sub-phase), include them in metadata:
coco-tracker create --epic "{epic-id}" --title "Sub-Phase {N}: {title}" --description "{single-line summary; task list}" --priority {priority} --metadata '{"sub_phase": N, "issue_key": null, "feature_branch": "{current-branch-name}", "owns_files": ["src/auth/**", "tests/auth/**"]}'
For each dependency (one Bash tool call per dep-add):
coco-tracker dep-add {phase-1-id} --blocks {phase-2-id}
coco-tracker dep-add {phase-2-id} --blocks {phase-3-id}
Repeat for all user stories blocking Polish, etc.
Read .coco/config.yaml issue_tracker.provider:
If "linear":
Create project:
Use: mcp__plugin_linear_linear__create_project
Parameters:
name: "{feature-name}"
team: {from config issue_tracker.linear.team}
summary: "{feature description from design.md}"
labels: {from config issue_tracker.linear.labels}
Create one issue per sub-phase:
Use: mcp__plugin_linear_linear__create_issue
Parameters:
title: "Sub-Phase {N}: {title}"
description: "{purpose}\n\n## Tasks\n- [ ] {task_1}\n- [ ] {task_2}"
team: {from config issue_tracker.linear.team}
project: "{project-id from step 1}"
labels: {from config issue_tracker.linear.labels}
Store issue keys in tracker metadata:
coco-tracker update {task-id} --metadata '{"issue_key": "{ISSUE-KEY}"}'
If "github":
Read issue_tracker.github.use_projects from config (default: true).
If Projects V2 enabled (use_projects: true):
Create a GitHub Project for the feature:
gh project create --owner {github.owner} --title "{feature-name}" --format json
Capture the project number from output.
Link the project to the repository:
gh project link {project_number} --owner {github.owner} --repo {github.repo}
Resolve Status field and option IDs:
gh project field-list {project_number} --owner {github.owner} --format json
Find the "Status" field. Extract field_id and option IDs for each status value (Todo, In Progress, In Review, Done).
Cache project metadata to .coco/state/gh-projects.json:
{
"features": {
"{feature-name}": {
"project_number": {N},
"project_id": "PVT_...",
"status_field_id": "PVTSSF_...",
"status_options": {
"Todo": "opt-id-1", "In Progress": "opt-id-2",
"In Review": "opt-id-3", "Done": "opt-id-4"
}
}
}
}
Ensure .coco/state/ directory exists. If gh-projects.json already exists, merge into the features key.
Create issues and add to project. Run each sub-phase as separate Bash tool calls (no loops).
IMPORTANT gh issue create rules:
--body-file - <<'EOF' for issue bodies (NOT --body "$(cat <<'EOF'...)" which triggers permission prompts)--repo — gh detects the repo automatically when run from within it--label takes comma-separated values: --label "spec-driven,enhancement". Read label names from issue_tracker.github.labels in config. Do NOT invent labels — only use labels that exist in the repo.a. Create the issue (capture the URL from output):
gh issue create --title "Sub-Phase {N}: {title}" --label "{comma-separated labels from issue_tracker.github.labels in config}" --body-file - <<'EOF'
{description}
EOF
b. Add issue to project using the URL printed by gh issue create:
gh project item-add {project_number} --owner {github.owner} --url {issue_url from step a}
c. Set initial status to "Todo":
gh project item-edit --project-id {project_id} --id {item_id} --field-id {status_field_id} --single-select-option-id {status_options["Todo"]}
d. Store issue number and project item ID in tracker metadata:
coco-tracker update {task-id} --metadata '{"issue_key": "#{N}", "gh_project_item_id": "{item_id}", "gh_project_number": {project_number}}'
Repeat steps a-d for each sub-phase. Steps a-d for a single sub-phase depend on each other (run sequentially), but separate sub-phases are independent.
If Projects V2 disabled (use_projects: false):
Create issues using gh (use labels from issue_tracker.github.labels in config):
gh issue create --title "Sub-Phase {N}: {title}" --label "{comma-separated labels from issue_tracker.github.labels in config}" --body-file - <<'EOF'
{description}
EOF
Store issue numbers in tracker metadata:
coco-tracker update {task-id} --metadata '{"issue_key": "#{N}"}'
If "none":
Skip issue creation. Log "Issue tracker bridge skipped."
coco-tracker epic-status {epic-id}
coco-tracker list --json --epic {epic-id}
All must pass:
issue_key in metadataOutput:
coco-tracker ready --json --epic {epic-id}/coco:execute -- Runs one task at a time, pausing after each for you to review. Best when you want to stay hands-on, inspect changes between tasks, or are working on something unfamiliar./coco:loop -- Runs all tasks autonomously in sequence with circuit-breaker protection (stops after repeated failures). Best when you're confident in the design and want to let Claude work through the epic unattended.When tasks.md doesn't exist but design.md does (light-tier feature):
{specs_dir}/{feature}/design.md (legacy fallback: spec.md)coco-tracker epic-create "{feature-name}"
coco-tracker create --epic "{epic-id}" --title "{feature-name}: {design overview}" --description "{single-line acceptance criteria}" --metadata '{"issue_key": null, "feature_branch": "{current-branch-name}", "light_tier": true}'
Design-only mode is triggered by:
/coco:planning-session tactical routing to Light tier/coco:phase classifying the feature as Light tierIf the conversation context indicates a dry run is desired: