ワンクリックで
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 ページを確認してインストールできます。
SOC 職業分類に基づく
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}/.
| 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: