# Write a Weekly Project Status From Asana

An agent reads Asana project tasks, writes a weekly status report and posts the requested project updates without changing the tasks themselves.

[Run this on Rush](https://cloud.getrush.ai/run/weekly-project-status/asana/).

## What the agent does

The agent reads the projects visible through your selected Asana connection, then collects tasks completed in the last seven days, unfinished tasks overdue at the cutoff and unfinished tasks due in the next seven days. The catalog entry in rush/shared/connectors/integrations.ts describes Asana tools to "search work" and "report on project status" at https://mcp.asana.com/mcp. The first step checks the tools and permissions actually available. Every project means every project the connection can read, not projects hidden from that account.

The summary separates completion time from due date. A task completed this week belongs in accomplishments even if its original due date was older; an unfinished task belongs in overdue work only when its due date has passed. The agent includes task links, assignees and dates, and identifies unassigned work without inventing an owner. A task shared between projects is considered in each project's context but is not silently counted as several distinct accomplishments in an overall total. Date boundaries and the chosen timezone are stated in the report.

It writes status.md with one section per project: completed work, overdue items, upcoming commitments and missing information that affects the summary. A missed due date is a fact; a claim that a project is blocked needs supporting task content. The prompt does not authorize reassignment, new due dates or marking work complete. This keeps the status update from becoming an unrequested project-management intervention. A project with no qualifying tasks gets an explicit no-change note instead of disappearing.

This version of the task also asks the agent to post the same summary as a status update on each project. That is an intentional write, separate from task reads. The minimal request shown below does not itself select Asana access: add your connected MCP server's id through connections before dispatch, as the developer API quickstart describes. If status-posting tools are unavailable, return the report and name that limitation. If a post fails, preserve the report and record which project update was not confirmed.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Use the explicitly selected Asana connection. If its tools are unavailable, stop and explain the missing access. For every accessible project, read tasks completed in the last seven days, unfinished overdue tasks and unfinished tasks due in the next seven days. State exact windows and timezone. Write status.md with a section per project, task links, assignees, dates, accomplishments, overdue work and upcoming work; do not invent blockers or owners. Post the same project-specific summary as a status update on each project only if that tool and permission are available. Record confirmed update links or failures in status.md. Do not change any task, assignee, due date or completion state."
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

status.md contains the project-by-project weekly report and a posting log. Each project section links to the underlying tasks and, where a post succeeds, the corresponding Asana status update. Unreadable projects, missing due dates and unsupported posting operations appear as limitations. A generated paragraph is not evidence that an update was published; the posting log distinguishes a confirmed result from an unverified attempt.

Before relying on the report, check the cutoff dates, a completed task and an overdue task against Asana. Confirm that posted updates contain only the intended project's summary and do not expose information from another project. For a read-only workflow, remove the posting instruction before starting the run. The returned file remains useful even when the account can read tasks but lacks permission to publish a project status.

## Run it on every weekly status deadline

A weekly job in your own scheduler submits a session with exact report dates and the selected Asana connection. Use an Idempotency-Key for retries of that same request, and keep the session id for follow-up. Since this task includes posting, do not blindly start a second run after a client timeout: read the original session and its posting log first. The completion webhook gives your server a point to retrieve status.md and check any failed updates.

## Why run it on Rush?

Weekly status work mixes repeated task reads with a synthesis people need to understand quickly. Rush gives the agent its own sandbox to gather the records and produce a report while your laptop is closed. The request makes the distinction between reading tasks and publishing project summaries explicit, so the scope stays inspectable rather than buried in a recurring manual routine.

The transcript retains the calls and their results, including the difference between an update drafted locally and one accepted by Asana. Separate workspaces or reporting windows can be processed as separate runs within concurrency limits. Your reviewer gets the written summary and its source task links, instead of a status color with no explanation of what changed.

## Frequently asked questions

### Will the agent change overdue tasks to make the report look better?

No. The request forbids changing tasks, assignees, dates or completion states. Overdue work appears in the report with its existing owner and due date.

### Can I review the summary before it posts?

Yes, remove the posting sentence and request status.md only. After reviewing the file, you can explicitly ask for the approved summaries to be posted in a follow-up once the turn finishes. The displayed request authorizes posting immediately.

### What if the connection cannot publish project status updates?

The agent returns the report and explains that publishing is unavailable. It must not claim the update was posted or substitute task comments without permission. Read access and status-writing access are checked separately.

### Does retrying the API request duplicate Asana updates?

Use the same Idempotency-Key and body when retrying session creation so Rush returns the original run. That protects the start request, not every possible external write. Inspect the session and posting log before asking another run to publish the same weekly update.