advance-work-from-plan

Claims, implements, and completes work packets from a shared plan ledger across distributed hosts.

5|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/8007342/tillandsias --skill advance-work-from-plan-8007342
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: advance-work-from-plan
Source: https://github.com/8007342/tillandsias/tree/main/skills/advance-work-from-plan
Command: npx skills add https://github.com/8007342/tillandsias --skill advance-work-from-plan-8007342

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Coordinating autonomous worker agents across multiple hosts leads to duplicated work, stale ledger reads, and unclaimed tasks. This Skill provides a recurring execution loop that lets any agent discover, claim, implement, checkpoint, and complete shaped work packets from a shared plan ledger without colliding with other hosts. ## Core Features & Use Cases - Batch Work Selection: Runs a minimax-scored batch selector that groups eligible packets by epic and release target, preventing priority-first starvation and cross-host collisions. - Lease-Based Claiming: Flips packet status to in_progress and pushes the claim before work begins, with cross-branch claim checks and timestamp-based collision arbitration. - Cycle Safety Guards: Enforces checkout locks, committable-branch guards, preflight instrument checks, and startup boundary snapshots so cycles are attested and never overlap. - Use Case: A scheduled worker agent on a Linux host wakes up, acquires the checkout lock, selects a budgeted batch of release-targeted packets, claims them with a pushed status change, implements the work, and finalizes the cycle with a verified commit. ## Quick Start Ask the agent to run an advance-work-from-plan cycle to select, claim, and complete the next eligible work packet for this host.

Frequently Asked Questions about advance-work-from-plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I claim a work packet from a shared plan ledger?▼

Claim a packet by flipping its status to in_progress with the plan CLI, committing only the claim fragment, and pushing it before starting work. The push makes the claim visible to other hosts, since unpushed claims separate nobody.

How does the batch selector choose which packets to work on?▼

The selector scores epics by residual using urgency, blocking count, and neglect, then picks a budgeted batch from one epic with score-weighted entropy over the top three. This prevents priority-first starvation and reduces collisions between concurrent hosts.

What happens when two hosts claim the same packet?▼

Collisions are arbitrated by timestamp, not push rejection, because the ledger is a CRDT where both pushes can succeed. The host with the earlier claim timestamp wins, and the loser releases its claim back to ready and takes the next batch item.

Why does the cycle refuse to start on the main branch?▼

The committable-branch guard blocks any cycle on main because main advances only via pull request. On a blocked verdict the agent must not claim, commit, or push anything and should switch to its host's canonical branch or run read-only.

Can a large packet be claimed if it cannot finish in one cycle?▼

Yes, large packets are eligible and size is never a skip reason. The cycle must end in a partial slice with progress notes, a split into smaller child packets, or an audit-dispose if the packet is stale or superseded.

What are the limitations of reading the plan ledger directly?▼

Direct file reads import tens of thousands of lines into context and reflect only the local fold, which can be hours stale on platform branches. The skill requires MCP-based cited queries first, falling back to filesystem reads only when tools are unavailable, unverified, or not exposed.