Distribute approved project tasks to role owners

Why use this

1. An approved project plan can still stall when task owners must copy their assignments from a shared discussion into separate working pages. The copying step creates opportunities for missing dependencies, altered deadlines and ambiguity about which version was approved.

2. This job could preserve the owner’s reviewed breakdown while preparing an explicit placement map. Showing each task beside its destination lets the project lead catch responsibility gaps before a distribution pass changes several people’s workspaces.

Why an agent / simpler alternative

Useful judgment

Interpret project language and match responsibilities to named roles while exposing uncertain ownership.

Simpler alternative

Use a project template or bulk import when task fields and owners are already standardized.

Unsuitable when

Responsibility is contested or the project owner has not approved the breakdown.

Proposed inputs

1. Name

   Approved breakdown

   Owner

   Project owner

   Minimum scope

   Versioned task list, dependencies and approval reference

   Quality check

   Ensure review applies to this exact version.

2. Name

   Role-to-page map

   Owner

   Workspace owner

   Minimum scope

   Named owners and verified destination page identifiers

   Quality check

   Distinguish similarly named staff and shared role pages.

Access and setup — proposed or unknown

Proposed minimum

1. Read the approved plan and destination structure; prepare a placement preview before writes.

Compatibility unknowns

1. Unknown: current Slack/Notion permissions, page schemas and agent connector support.

External actions requiring approval

1. Creating or changing owner pages, assigning tasks or notifying participants.

Expected deliverable and review checks

Proposed artifact

Distribution manifest mapping each approved task to an owner, page and placement result.

Critical checks

1. Every approved task appears once, with dependencies preserved.

2. Unassigned tasks remain explicit rather than being guessed into a role.

Missing output evidence

This overlay adds no new output inspection or execution validation. Preserve the canonical implementation evidence and its outcome limits.

Failure signals and proposed responses

1. Signal

   A role name matches multiple destination pages.

   Why it matters

   The wrong person may receive sensitive or irrelevant work.

   Proposed response

   Hold that placement and ask the workspace owner to resolve the exact page.

2. Signal

   The breakdown changes after approval.

   Why it matters

   Distribution would silently expand the approved commitments.

   Proposed response

   Diff the versions and obtain review of changed tasks before continuing.

Effort and cost — unknown

Setup work

1. Create a verified ownership map and agree task-field conventions.

Ongoing review

1. Reconcile partial writes against the placement manifest.

Unknowns

1. Unknown: page limits, connector charges and review effort for changing roles.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A fictional approved plan contains four tasks, one dependency and an ambiguous designer role with two candidate pages.

Acceptance checks

1. Three unambiguous tasks map once; the ambiguous task stays pending.

2. The dependency and approval version survive the preview.

Stop conditions

1. Any real page write or unapproved task reassignment is requested.

Limits

1. The approved plan remains the authority for proposed placements; changed commitments need renewed owner review.