| name | tp-inflight |
| description | Print the in-flight design registry — every origin/tp/* design branch with its owner, phase, branch, age, and staleness — built live from the remote. Read-only, fail-open, no lock, no side effects. Use to see what other designs are in flight before you start work. |
| argument-hint | [--json] |
In-Flight Design Registry
Show what design work is currently in flight across the team. The registry is built live from origin/tp/* branches and each branch's committed three-pillars-docs/tp-designs/{name}/lock.json — the same source of truth the collaboration preflight uses, surfaced on demand.
This skill is read-only: it acquires no lock, writes nothing, and never blocks. If origin is unreachable it reports the registry as unavailable (it cannot list in-flight designs — there is no local-listing fallback) and still exits cleanly; your local work is unaffected.
Arguments:
--json (optional) — emit the registry as structured JSON instead of the human table (for piping into other tooling).
Steps
-
Run first-run preflight per skills/_shared/first-run.md.
-
*Refresh tp/ refs (fail-open)**: the registry reads lock blobs out of objects already present locally, so fetch the in-flight branches first:
git fetch --quiet origin 'refs/heads/tp/*:refs/remotes/origin/tp/*' || true
The trailing || true is load-bearing — if there is no remote, you are offline, or auth fails, continue anyway. A fetch failure must never block the skill; the helper reports the registry as unavailable (origin unreachable) on its own and still exits 0.
-
Build and print the registry by running the shared helper:
python3 "$TP_ROOT"/skills/_shared/inflight_registry.py
python3 "$TP_ROOT"/skills/_shared/inflight_registry.py --json
Pass --json through when the user asked for it. The helper lists origin/tp/* via git ls-remote (always live — no cache), reads each branch's lock.json, and renders one row per in-flight design with owner, phase, branch, age, and a flag column (⚠ stale when older than the 30-day staleness threshold, · unreadable when the lock blob couldn't be read).
-
Relay the output to the user verbatim. If the registry is degraded (origin unreachable), say so plainly — the table/JSON already carries a degraded banner/flag, so just surface it rather than retrying the fetch.
-
Point stale designs at graceful handoff: if any row is flagged ⚠ stale (likely abandoned, last_touched > 30 days), mention that the design can be claimed cleanly via /tp-design-release {name} by its current owner — or taken over with --force-takeover on the next lock-enforcing skill. Never act on staleness automatically — surface it only.
Rules
- Read-only, no side effects: this skill never writes a lock, never commits, never pushes. It only reads refs/objects and prints.
- Fail-open always: the
git fetch is best-effort (|| true) and the helper itself always exits 0. A remote/network problem makes the registry unavailable; it never errors out.
- Always live, no cache: the branch list comes from
git ls-remote every invocation. There is no TTL or stored snapshot.
- Staleness is informational: a
⚠ stale flag is a likely-abandoned hint (30-day threshold), never an instruction to auto-release or auto-take-over.
- Do not interpret different design names as collisions here —
/tp-inflight is awareness-only. The same-name collision gate lives in the collaboration preflight (skills/_shared/collaboration.md), not in this skill.
Owner column semantics
The owner column in the printed table is rendered by display_label in
skills/_shared/orchestrator_identity.py (inherited from inflight_registry.format_table).
An orchestrator-held lock (owner: "orchestrator:<email>") renders as <email> (orchestrator);
a human-held lock renders verbatim; a released lock renders -. The (orchestrator) marker
signals that the lock was written by an autonomous runner, not a human developer.
