Finalize Task

Finalizes an Asana task end-to-end: updates the description with structured documentation, summarizes decisions from comments, captures act…

Maxwell EleyTriumph TechUpdated 19h ago0 installsCodeCowork
AI summary

Need a quick read on Finalize Task?

Skim the gist, what it's good for, a real prompt to try, and the gotchas — all distilled from SKILL.md. Cached after the first run.

Details

About this skill

--- name: finalize-task title: Finalize Task version: 1.0.0 description: >- Finalizes an Asana task end-to-end: updates the description with structured documentation, summarizes decisions from comments, captures actual time, sets custom fields, moves to the correct board status, reassigns if needed, and optionally creates a consulting note in Rock RMS. Use this skill whenever Brad says "finalize this task", "wrap up this Asana task", "finish documenting", or shares an Asana task URL and asks to finalize or finish it. Also trigger when Brad says "let's finalize this one" or similar end-of-task language pointing at an Asana URL or task name. tagline: >- Finalizes an Asana task end-to-end: updates the description with structured documentation, summarizes decisions from comments, captures act… runtimes: - code - cowork tags: - review triggers: [] ---

# Finalize Task

Finalizing a task means leaving it fully documented and in the correct state — ready for billing review, client communication, and future reference. This skill walks through the full process: documentation, time, fields, status, assignment, and consulting note.

Work through steps in order. The user will be interviewed along the way. Do not write any changes to Asana until Step 9, where the user reviews and confirms everything.

---

## Step 0: Identify the Task

If the user provided a task URL or GID in their message, use that and skip ahead to Step 1.

Otherwise, pull their recent Asana tasks to surface likely candidates. Call `get_my_tasks` (or `search_tasks_preview` with relevant filters) and focus on tasks in "In Progress" or "Ready for Review" sections. Present a short list — no more than 8–10 — and let the user pick.

If the user provides context (client name, topic keyword), filter before presenting.

---

## Step 1: Fetch the Task and Project

Extract the task GID from the URL or context. From a URL like `...task/1212865135047722...`, the GID is `1212865135047722`.

Call `get_task` with `include_comments: true` and `include_subtasks: true`.

From the response, find `memberships` and identify the **primary project** — this is the client retainer project (not the PS Team Project Board). Call `get_project` on that project GID with `include_sections: true` to get the board columns.

Hold all this data in context — you'll need field GIDs, section GIDs, and enum option GIDs throughout.

---

## Step 2: Draft the Structured Description

Read the current `notes` and all comments. Draft an updated task description using this template:

``` ## Problem Statement [What was the original problem or request? Be specific — name the report, workflow, field, or process. 2–4 sentences.]

## Solution [What was built or changed? Use a bulleted list for distinct changes. Be technical enough for a future developer to understand without re-reading the comments.]

## Deliverables [What was actually handed over? Report names, Rock page URLs, workflow IDs, SQL links, etc.]

## Testing [How was the solution validated? Who tested it, what scenarios, any known limitations.]

## Consulting Note [Leave blank — fill in after Step 8 if a note is created.] ```

Pull from both the task notes and the comment thread. The solution details often live in comments — synthesize rather than quote. If the existing description already has structured content, preserve what's useful and reshape it into this format.

Hold this draft. Do not show it to the user yet.

---

## Step 3: Summarize Decisions from Comments

Read through all comments. Identify decisions — moments where a question was asked and answered, a tradeoff was accepted, or a known limitation was acknowledged by the client.

Format each as: > **Decision (Month Day, Year):** [Person] agreed to [what], noting [why or context].

If there are no meaningful decisions, skip this section. A back-and-forth without a clear resolution is not a decision.

---

## Step 4: Interview — Actual Time

Show the user the current logged time from `actual_time_minutes`. Ask how much additional time, if any, should be added.

Example: "The task currently shows **1h 45m** logged. How much additional time should be added, if any?"

Accept input in minutes or hours/minutes. Convert to total minutes for the update.

---

## Step 5: Interview — Custom Fields

Interview the user about fields that are unset or that may need updating. Pull the available values and current values directly from the task data fetched in Step 1.

Fields to ask about (skip any the user has clearly already addressed, or that seem irrelevant):

- **Ministry** — Which ministry area does this task serve? - **Task Status** — What is the task's current status? - **Percent Complete** — How complete is this task? - **Priority Level** — Should the current priority change? - **Peer Review** — Does anyone need to be listed? - **Issue Classification** — Is there an issue classification to set? - **PS Budget Hours / PS Goal Hours / PS Approved Hours** — Any PS hours to record?

Batch related fields together using `AskUserQuestion` (max 4 questions per call). Show enum options as they appear in the task data. Show current values for fields that are already set.

---

## Step 6: Interview — Board Status

Show the user the sections available on the board (from the project data). Show the current section. Ask which section the task should move to.

Present each section name as an option. Common final states are "Ready for Review," "Highlands Action Required," "Complete," or staying "In Progress" if more work remains.

---

## Step 7: Interview — Reassignment

Show the current assignee. Ask if the task should be reassigned.

Options to offer: - Keep current assignee - Reassign to Brad (brad@triumph.tech) - Someone else (free text)

---

## Step 8: Interview — Consulting Note

First, check whether the Rock RMS MCP is available by looking for `ListContentChannels` in the available tools. If it is not installed or accessible, skip the "needs to be created" path entirely — just ask whether an existing link should be recorded, and move on.

Ask whether a consulting note needs to be created.

Options: - Needs to be created *(only show this if Rock MCP is available)* - Already exists (ask for the URL or reference) - Not needed for this task

**If already exists:** Ask the user to provide the link. That link goes into the `Consulting Note` custom field and into the description's Consulting Note section.

**If needs to be created (Rock MCP available):**

1. Call `ListContentChannels` with search term `"consulting"` to find the right channel. 2. Call `AddContentChannelItem` with: - `contentChannelIdKey`: the channel ID from step 1 - `title`: the task name, stripping the client prefix (e.g., `"[Church of the Highlands] Update: SGLT Registration report"` → `"Update: SGLT Registration report"`) - `content`: the structured description from Step 2, followed by the decisions summary from Step 3 - `status`: `"Approved"` (or the channel's standard published status if different) 3. Retrieve the URL of the newly created item from the response. Present it to the user and confirm it's correct. 4. Use this URL in the description's Consulting Note section and in the `Consulting Note` custom field.

If the Rock MCP call fails or returns an error, tell the user clearly and ask how to proceed before continuing.

---

## Step 9: Confirm and Apply

Present a full summary of everything that will change before touching Asana:

``` ## Planned Updates — [Task Name]

**Description:** Structured format applied (Problem Statement / Solution / Deliverables / Testing / Consulting Note)

**Decisions documented:** [N decisions found in comments, or "none"]

**Actual time:** [current total] → [new total] minutes

**Custom fields:** - Ministry: [value or "unchanged"] - Task Status: [value or "unchanged"] - Percent Complete: [value or "unchanged"] - [any other changed fields]

**Board status:** [current section] → [new section]

**Assignee:** [current] → [new] (or "unchanged")

**Consulting Note:** [URL or "none"] ```

Wait for explicit confirmation before writing anything.

Once confirmed, call `update_tasks` with a single task object containing all changes:

- `notes`: the structured description (plain text) - `actual_time_minutes`: updated total (if changed) - `custom_fields`: object mapping field GIDs to values — use enum option GIDs for enum fields, raw strings for text fields, raw numbers for number fields. All field and option GIDs come from the task data fetched in Step 1. - `assignee`: updated assignee email or GID (if changed) - To move to a new board section: use `add_projects` with the project GID and the target `section_id`

After the update succeeds, confirm to the user that everything has been applied and share the Asana task URL.

---

## Technical Notes

- All field and option GIDs are available in the task data from Step 1 — never guess them. - Section moves use `add_projects` with the target `section_id`. This repositions the task within the existing project rather than adding it to a new one. - If the task is in multiple projects, apply section changes only to the client retainer project (the one in the provided URL). - `update_tasks` takes an array — always wrap the single task object in `[ ]`. - The Consulting Note custom field GID on Triumph tasks is `1206443504160513`.