indigoai-us/hq-packages/client-action-items

Client action items

A mutable tracker for action items assigned to a company's owner, ingested from that company's signals store.

Action items originate as action_item signals (see client-signals). Those signal files are immutable, content-addressed extraction records with no status. This skill maintains a separate mutable tracker that references each signal and carries a status through to completion.

Resolve context first

Read companies/{co}/client-management.yaml for the `owner` (whose items to track) and confirm the signals store companies/{co}/signals/ exists. The tracker lives at companies/{co}/action-items/.

The two core pieces (generic)

1. Ingest — copy action_item signals owned by the config owner into the

tracker as incomplete items. Idempotent: dedupe on signal_id, so it's safe to run repeatedly. This is the seam a post-sync hook or scheduled task can drive later.

1. Tracker — one Markdown file per item under

companies/{co}/action-items/<id>.md, carrying a status through a defined lifecycle. One file per item keeps cross-machine sync conflicts minimal.

Processing/dispatch is pluggable, not built in. Indigo drives an

autonomous per-item worker (cmux + headless Claude). That dispatch layer is

environment-specific and is not part of this generic skill — wire it as a

company extension if you want it. This skill owns ingest + the tracker + manual

status transitions, which are universal.

Tracker store

companies/{co}/action-items/<id>.md — <id> is the first 8 characters of the source signal_id. HQ-tracked and autosaved.

---
id: <signal_id[:8]>          # short, human-referenceable id
signal_id: <full sha256>     # source signal — dedupe key
status: incomplete
owner: "<owner name from config>"
owner_inferred: false        # true when ownership came from canonical_content
title: "<short title>"
priority: "<High|Medium|Low, or empty>"
source_meeting: "<meeting-id>"
artifacts: []                # paths to drafts / research produced
created_at: <iso8601 Z>
updated_at: <iso8601 Z>
---
# <title>
 
<canonical_content from the signal>
 
## Source                    # written by ingest — meeting + verbatim citation
- **Meeting** `<meeting-id>` — transcript: `sources/meetings/<meeting-id>.md`
- **Cited** (<timestamp>): "<verbatim transcript quote>"
 
## Progress log
- <iso> ingested from signal <signal_id>

Status lifecycle

Commands — /client-action-items [mode]

ingest

Pull new action_item signals owned by the config owner into the tracker as incomplete items. Dedupe on signal_id (idempotent). Use the same ownership logic as client-signals (Owner line, or leading-actor inference flagged owner_inferred: true). Preview with a dry run before writing.

list [status]

Show the tracker grouped by status (or filtered to one status).

update <id> <status>

Manual status change with a note, e.g. mark an item dismissed or completed. Set updated_at and append a ## Progress log line — don't hand-write the progress log out of band.

process (default)

1. Run ingest to pull any new signals.
2. list incomplete and show the items.
3. If a dispatch extension is wired for this company, confirm the set with the

user (AskUserQuestion) and hand off. Otherwise, present the incomplete items for the user to work manually and update as they go.

Autonomy boundary (if a dispatch extension is wired)

Any per-item worker must stay within local and reversible work only: write files, draft, research, make local code changes. It must NOT take external side-effect actions — send email/Slack, deploy, grant access, push a branch, open a PR, or spend money. If an item needs such an action, prepare it fully and set awaiting-approval; never perform it autonomously.

Related skills

• `client-signals` — reads the raw signals store (read-only). This skill

consumes its action_item output and adds mutable status.

• `/crm` — pipeline/account status. A different domain; unrelated to this

personal task tracker.