---
name: project-board-and-approval-operations
description: Scans a project board for stalled, duplicated, unowned and silently-abandoned work, classifies every open item, and produces an approval-ready cleanup batch. Also detects approval decisions and routes the next step. Use when the user asks what is stuck, to clean up the board, to run a hygiene scan, or to check whether something was approved.
metadata:
  version: "1.1.1"
---

# project-board-and-approval-operations

> **Client-neutral reusable package.** No client names, tenant or workspace identifiers, account or
> resource IDs, customer records, credentials, or internal paths. All examples are synthetic.

| | |
|---|---|
| Live catalog name | Project Board and Approval Operations |
| Live category | Agency Operations |
| Catalog entry | 21 |
| Internal capability ID | `CAP-AO-04` |
| Provider | Project management (provider-neutral) |
| Availability | Candidate; validate in the active Workspace |
| Deliverable type | `limited_pilot_package` |
| Validation status | Candidate; local package validation only |
| Version | 1.1.0 |


## OLLIE Runtime integration

Use this capability under the active OLLIE Operator. Read live Workspace Context and tenant
bindings for the required inputs below; this public package supplies no client facts or authority.
Consume `ask-ollie-authority-core` for authority, `outloop-access-fallback` for recovery and
resource verification, `email-lifecycle-core` for recipients, approvals and stored-copy delivery
verification, and the bootstrapper Runtime Contract for ownership, scheduling and completion.
These owners govern execution; this Skill does not implement a competing runtime.

Select the relevant expertise below for the requested outcome. Runtime governs combining Skills,
partial use and completing missing steps with other authorized capabilities. This Skill's domain
scope does not limit the Operator's wider authorized task. Preserve domain safety restrictions.
Verify findings against source evidence and read back any resulting artifact or authorized change.

## Business outcome

A board that reflects reality, and approvals that move work forward instead of sitting unnoticed.

## Operating modes

Read · Analyze · Draft · Write with approval

## Prerequisites — what must be true before this runs

- Workspace Context (project management)
- An approved project-management grant
- A documented approval convention

## Required inputs

| Input | Source |
|---|---|
| Approved projects and sections in scope | Workspace configuration |
| Staleness thresholds per class | Configuration |
| Team roster and the approval convention | Required — how a human signals approval on this board |
| Named approver for any mutation | Configuration |

## Read-only invariant on the scan

The scanning pass makes no comments, no closes, no reassignments and no section moves. This is what makes it safe to
run on a schedule across every project. Mutation is a separate, explicitly approved pass.

## Detect the approval, do not assume it

Approval on a real board is a human gesture — a reassignment, a comment, a status change — and the convention differs
per team. Read the convention from configuration. Parse conservatively: anything ambiguous is **not approved**. Record
a state marker so the same approval is never acted on twice.

## Waiting on a client is not stalled

An item blocked on a client decision is progressing normally. Classifying it as stale generates noise that trains
people to ignore the report. Separate *we are blocked* from *we forgot*.

## Action classification

| Action class | This workflow |
|---|---|
| Read | Tasks, descriptions, comments and stories, assignees, due dates, section placement, completion state |
| Analyze | Classification into stalled, duplicate, unowned, blocked, superseded, waiting-on-client and ready-to-close; approval detection; idempotency checks |
| Draft | A per-project report and a proposed cleanup batch, item by item |
| Write with approval | Applies the approved batch — comments, closes, reassignments and section moves |
| Destructive | Task deletion is **out of scope**. Closing is the strongest available action |

## Approval and delivery

The Operator applies Authority Core and the active Workspace approval policy to any requested
mutation. Email Lifecycle owns recipient classification, sending and stored-copy verification.
The action table defines this capability's domain scope; it grants no permission by itself.

## Expected output

A per-project hygiene report, a portfolio summary, and an itemized cleanup batch ready for selection — then an execution log with read-back per applied change.

## Synthetic placeholders used in this package

These are illustrative only. Real values come from the client's own workspace configuration and are
never written back into this package.

| Placeholder | Meaning |
|---|---|
| `PROJECT_PLACEHOLDER` | Approved project |
| `SECTION_PLACEHOLDER` | Scanned section |
| `APPROVER_PLACEHOLDER` | Named approver |