asana-to-harness

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.