From coco
Import a tasks.md into the coco tracker as an epic with dependencies, and create matching issues in the configured issue tracker.
npx claudepluginhub skullninja/coco-workflow --plugin cocoThis skill uses the workspace's default tool permissions.
Import a tasks.md into the coco tracker and optionally create matching issues in the configured issue tracker.
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
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: