Asana To Harness

---
name: asana-to-harness
description: Turn one Asana task into an implementation plan for an AI coding harness, open a GitLab issue with the plan as its description, and leave a trigger comment (e.g. @claude). Used standalone ("turn this Asana task into a harness issue") or invoked by the asana-sweep skill.
---

# Asana task → harness plan → issue + trigger comment

Convert a single Asana task into a plan an AI coding harness can execute directly, then open a GitLab issue and trigger the harness. Usually invoked with a task number/keyword (interactive) or a resolved spec (from asana-sweep).

## Configuration

Read `asana-sweep.config.json` in the repository root (same file the sweep skill uses):

- `gitlab.project` — GitLab project path for issues.
- `gitlab.base_branch` — branch new work starts from; state it in the plan.
- `harness.trigger_comment` — the comment text that wakes the harness (e.g. `@claude please implement per the issue description above`). **Know your harness's trigger rule**: many harnesses (including GitLab webhook-based ones) only fire on **comments (notes)** — a mention inside the issue *description* does nothing. So the flow is always "create issue (description = plan) → post a separate trigger comment".
- `plans_dir` — where local plan drafts are stored.

## Flow

### 1. Read the Asana task
- Find the task by number/keyword and get its `gid` (on free workspaces use `asana_get_my_tasks` + filtering; search endpoints require a paid workspace).
- Fetch it with `notes,html_notes,permalink_url` **plus its stories/comments** — client clarifications and links to prior MRs often live in comments, not the description.
- Also fetch image attachments for the task (and its parent) with the plugin's bundled helper, then Read every path it prints: `asana-fetch-attachments <task_gid>` — screenshots and annotated printouts frequently carry the real spec (exact dimensions, layouts). The helper reads `ASANA_PAT` internally; don't probe the environment and don't hand-roll curl with `$VAR` expansion (both get denied in headless allowlists). If it exits non-zero (PAT missing / command not found), proceed without images. Quote image-derived values explicitly in the plan so reviewers can verify them.

### 2. Write the plan
- If the user has a dedicated planner agent, delegate to it; otherwise draft the plan yourself. Either way the plan must contain:
  - **Goal** — what the change does, in one paragraph, traceable to the Asana text.
  - **Scope** — files/modules expected to change; explicitly list anything that must NOT change.
  - **Base** — the `gitlab.base_branch` to branch from, plus any numbering/sequence caveats.
  - **Definition of Done** — verifiable checks a reviewer can run.
- Useful lead: if this is a "same series, one more of X" task, find the precedent commit (`git log --all --oneline -S '<keyword>'` or `--grep`) and tell the planner/harness to copy its shape. Not every task has a precedent — plan normally when there isn't one.
- Save a local draft under `plans_dir` for the record.

### 3. Open the GitLab issue (description = the FULL plan)
- `create_issue` on `gitlab.project`: title = the Asana task title, description = **the full plan text pasted inline**. Never link a local file path as the plan — the harness runs elsewhere and cannot read your machine. Write any repo paths in the plan as full repo-relative paths.

### 4. Post the trigger comment
- `create_issue_note` with `harness.trigger_comment` first, then 2–3 bullet reminders: the base branch, the precedent commit if any, and the do-not-touch list.

### 5. Report back
- Give the user the issue URL and remind them what happens next (harness picks it up → opens an MR → they review the diff, especially the do-not-touch items, before merging).

## Guardrails
- Opening an issue is an external action. Research + plan-writing can proceed freely; **if the task number, base branch, or requirements are ambiguous, ask before creating the issue** — unless the user (or the sweep skill's triage) already said to go end-to-end.
- Never embellish requirements. When unsure, quote the Asana text and mark the point as "to confirm" inside the plan.