hotfix

Coco Hotfix Skill

Lightweight workflow for single-issue fixes and small changes that don't warrant full epic tracking.

When to Use

• Bug fixes that affect a single area
• Small enhancements (< 1 day of work)
• Quick changes where dependency tracking isn't needed
• Any work that maps to a single issue tracker entry

For multi-session features with dependencies, use the execute skill instead.

Workflow

1. Setup

Read .coco/config.yaml for issue tracker configuration.

If $ARGUMENTS contains an issue key/ID, load it. Otherwise, create a new issue:

If "linear":

Use: mcp__plugin_linear_linear__create_issue
Parameters:
  title: "{fix description}"
  team: {from config issue_tracker.linear.team}
  labels: {from config issue_tracker.linear.labels}
  state: "In Progress"

If "github":

gh issue create --title "{fix description}" --label "{comma-separated labels from issue_tracker.github.labels in config}"

If github.use_projects is true: check .coco/state/gh-projects.json for an active feature project. If one exists, add the issue to it and set status to "In Progress":

gh project item-add {project_number} --owner {github.owner} --url {issue_url}

gh project item-edit --project-id {project_id} --id {item_id} --field-id {status_field_id} --single-select-option-id {status_options["In Progress"]}

If "none": Skip issue creation.

2. Create Branch

git checkout -b fix/{short-name}

3. Implement Fix

• Understand the issue (read related code, reproduce if bug)
• For a bug: reproduce it in a failing test first. A bug that shipped once is proof the failure mode is real and undefended -- that is the highest-value test there is, and it is the one case where a test is always worth writing
• For a non-bug change (config, docs, a small refactor), write a test only if it defends a failure mode nothing else covers. Do not add a test purely to accompany the diff
• Implement the fix
• Run test suite to verify no regressions