/chips

name: chips
description: "Run the project's suggested-task ledger, the chips. /chips alone brings every open task up to date: it applies what the ledger helper says, settles stale and split tasks, cards what can start and reports the board. Use for /chips, /chips offer, start or drop, \"what chips are open\", \"suggest a task for X\", \"update the chips\", \"clean up the chips\", \"which chips are stale\", and whenever pstack would file a tracked issue, a follow-up, a reflect Backlog item or an out-of-band PR."
argument-hint: '[offer <finding> | start <id> | drop <id>]'

Chips

Chips are a project's suggested tasks, the side work outside a run's target that the owner can start in a new session. They live as rows in one ledger per project, and a card in a suggest tool is only a view of one. The law is `.agents/pstack/rules/chips.md`, which sync-pstack renders into every project. Read it in full before this session's first ledger write. This skill runs its modes; it adds no rule of its own.

Every command below is `node .agents/pstack/decisions-check.mjs <command>`, run from the project's checkout, which a card session that opened in its own worktree names by the path its brief prints. Get this session's id from the runtime's session tool, such as Claude Code desktop's `get_session` with `self`, and pass `--session <id>` to every board read. A runtime with no session tool reads the board without it.

| Mode | Use it to | | --- | --- | | [Sweep](#sweep), `/chips` with no argument | bring every open task up to date, card what can start and report the board | | [Offer](#offer) | add a finding, the one way new work enters the ledger | | [Start](#start) | begin a task a card opened, in the card's session | | [Drop](#drop) | record the owner's word to drop a task |

pstack calls these modes too. Where a pstack step files a tracked issue, a follow-up or a reflect Backlog item, or puts an out-of-band fix in its own PR, the lead runs Offer instead. At each hand-back, after each compaction and at the close, it runs a quick sweep, which skips step 3. A question about open chips, such as "what's next" over side work, runs steps 1 and 6 and writes nothing.

Sweep

1. Run `chips --session <id>` and `chips stale`. The stale report lists each open task with its age, the paths it writes that were deleted since its offer or are missing, the commits on its paths since its offer, its closed PR waits and its card, the likeliest stale first. 2. Apply the pass the Do list shows, together with the run's own rows that chips.md's Sweep lists, in one `append --from <file>` batch:

• Withdrawal pass: call the dismiss tool on each card it names, then log the row the tool's report decides, as each item says.
• Ledger pass: log each row it names.
• Card pass: leave it to step 5.
• Check items: look each session up with the session tool. Log `uncarded` with a card item's `card:` when the tool reports its session archived or gone. For a started task whose rows name no session, find it as the item says and log `started` with its `session:`. When the tool reports a started task's session archived, read its last report with the tool, then log `landed` when a commit holds the change or that report says the session delivered it, with `patch:` when it names one. When that report hands back a patch it never applied, land the patch as chips.md's Landing says and log `landed` with `patch:`. Log `dismissed stopped` only when that report hands back no patch and neither this checkout nor the session's own worktree holds an uncommitted edit on the task's paths. Otherwise, or when the tool cannot find the session, the task stays started, and step 6 says why.

Run `chips --session <id>` again and repeat until the Do list shows only the card pass or nothing you can apply. When `append` refuses a batch, fix or drop the refused row as its message says and append the rest. 3. Judge each task the stale report gives a fact, from its brief, those facts and the code, and append the rows in one batch:

• When the tree already holds its fix, log `dismissed done`, citing the commit.
• When its target was deleted since its offer, log `dismissed superseded`. When a path only moved, log `updated` with the new `writes:`.
• A missing path is one the offer named wrongly or one the task will create. Find the real path with `git ls-files` and log `updated` with it, or leave a path the task creates. A carded task's `updated` only drops paths, so its session names the real one in its `started` row.
• When a PR it waits on closed without merging, log `updated` with the waits it has now.
• When two open tasks answer one question, log the topic move and `dismissed dup` that chips.md's Sweep gives. When the keeper holds a card or is started, log `waits: task:<keeper>` on the other instead.
• For a started task, log `landed` when a commit holds its change. Step 2's check item settles the rest from its session, so never ask the owner whether that session still runs.
• When the report marks a task possibly thin, find its finding in the plan, log or run its offer names, and log it as a `folded` row. When this session holds the task's card, withdraw it first. When another session holds it, fold the finding once that card leaves the queue. When no source holds the finding, leave the task as it is. Step 6 says which tasks stay thin.
• For each task that holds a card and whose Ready line says it shares paths with another open task, judge its dependencies as step 5 does, because it may have been carded before anyone judged them. When it needs another task's result, log `updated` with its waits plus `task:<that id>`, which a carded task takes.
• For each task that holds a card, check its effort against chips.md's Title rule as step 5 does, and log `updated` with the right `effort:` when they differ, which a carded task takes.

4. Repeat step 2 for what step 3 changed. 5. Card pass: before each card, judge whether the ta