Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
broomva avatar

P9

  • 7 installs
  • Updated June 12, 2026
  • broomva/p9

P9 is a Claude Code skill that converts blocking waits like PR CI checks into productive work, with a reference PR CI watcher that classifies and self-heals failures.

About

This skill is a productive-wait primitive that turns any blocking external operation, such as PR CI checks or deploys, into work on the next priority instead of sleeping. Its reference implementation is a PR CI watcher that runs gh pr checks in the background, classifies failures and self-heals known categories. A developer uses it after a git push so the agent drains a prioritized work queue while CI runs and only merges through the control metalayer.

  • Converts blocking waits (PR CI, deploys, builds) into work on the next priority
  • PR CI watcher classifies failures and self-heals known categories like lint
  • Merge authorization stays with the control metalayer; escalates unclassified failures

P9 by the numbers

  • 7 all-time installs (skills.sh)
  • Ranked #1,060 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
  • Data as of Jul 8, 2026 (Skillselion catalog sync)
At a glance

p9 capabilities & compatibility

Capabilities
ci monitoring · ci self heal · pr automation · productive wait
Works with
github · jira
Use cases
ci cd · code review · testing
Pricing
Free
From the docs

What p9 says it does

Never `sleep` on a blocking wait.
SKILL.md
The reference implementation is a PR CI watcher: drains a context-scoped deferred-work queue while `gh pr checks --watch` runs in the background, classifies failures, and self-heals known catego
SKILL.md
Merge authorization stays with the existing control metalayer (.control/policy.yaml).
SKILL.md
npx skills add https://github.com/broomva/p9 --skill p9

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs7
Last updatedJune 12, 2026
Repositorybroomva/p9

What it does

Use it after a git push to watch PR CI, self-heal known failures, and work the next priority instead of sleeping on the wait.

Who is it for?

Watching PR CI after a push, self-healing known CI failures, and doing next-priority work instead of sleeping on a wait

Skip if: Non-PR waits are only partially supported today (single direct check); it does not authorize merges itself

When should I use this skill?

After a git push opens or updates a PR, when a CI check fails, or whenever you are about to sleep on a wait

What you get

The wait becomes next-priority work while a background watcher classifies and self-heals CI failures toward merge-ready

  • background CI watcher
  • classified failure report
  • self-heal command

By the numbers

  • 5 wait-time work sources in priority order
  • ci_heal max_attempts default 5
  • 4 isolation tiers

Files

SKILL.mdMarkdownGitHub ↗

P9 — Productive Wait (Wait-Optimizer Skill)

Cardinal rule

Never `sleep` on a blocking wait. Whether you're waiting on PR CI,
a push-triggered deploy, a long build, or an index sync — convert the
wait into productive work on the next priority. For PR CI, p9 watch <pr>
spawns the observer in the background and the agent pulls work from the
wait-queue. For non-PR waits (today), do one direct check on completion
after kicking off next work. Sleep is a footgun — it burns clock time the
agent could be
using to validate definitions, refresh the knowledge graph, or draft the
next slice.

When to invoke

TriggerAction
git push opens or updates a PRp9 watch <pr> --background immediately
run_in_background task notification fires for the watcherp9 status --pr <n> to read terminal state
gh pr checks returned non-zerop9 heal <pr> --classify to inspect failure
About to sleepDon't. Pull from p9 wait-queue pop instead

Wait-time work selection (priority order)

When the watcher is running, drain work from these sources in priority order (higher = pulled first):

1. session — TODOs already on the agent's TaskList tagged wait_ok=true. 2. memory — items from ~/.claude/.../memory/MEMORY.md flagged "needs follow-up" within the last 24h. 3. graph — knowledge-graph entities adjacent to files-touched-in-PR (BFS depth 1 via bookkeeping.py query). 4. docs — cross-refs from the current PR's diff (mentioned files not yet updated). 5. linear — tickets in the current cycle, label-matched to PR's Linear ID.

Isolation tier (per spec §5.5)

Each pop returns the inferred isolation tier:

Work typeTierWhere it happens
research, docs, knowledge-graph mutations, Linear updatesnonecurrent worktree, no separate branch
code that's independent of the in-flight PRworktreenew P5 worktree off main
code that depends on the in-flight PRstacked_branchbranch off feat/X+1 from feat/X HEAD
anything touching CLAUDE.md / AGENTS.md / .control/blockednot auto-handled; surface to user

Wakeup protocol

When the bg task notification fires:

1. p9 status --pr <n> --json
2. parse `to_state`:
   - GREEN          → p9 merge-ready <n>; defer to control metalayer
   - RED_CLASSIFIED → p9 heal <n> --classify; if classified+evaluator-positive,
                      apply heal_command (in PR scope only); push amend; loop
   - RED_UNCLASSIFIED, ESCALATED → notify user via Linear ticket; stop healing,
                                    keep watcher alive in case human pushes a fix
   - ABANDONED      → surface failure to user; remove watcher; skip cleanup

Termination conditions

The agent exits the heal loop when any of:

  • to_state ∈ {MERGED, ESCALATED, ABANDONED} (terminal)
  • attempt ≥ ci_heal.max_attempts (default 5)
  • evaluator returned stalled=true for two consecutive cycles
  • user interrupt (Ctrl-C in terminal, or chat message)
  • session ends (the Stop hook leaves watchers running for next session pickup)

Examples

Example 1 — Green on first try (happy path)

$ git push origin feat/my-change
$ gh pr create ... ; PR=42
$ p9 watch $PR --background
watcher_id=ab12cd34ef56 pid=78901 pr=42 repo=broomva/workspace

# Run watcher in foreground/background; meanwhile drain queue
$ p9 wait-queue pop
{"id": "...", "source": "graph", "item": "verify entities adjacent to ...", "isolation_tier": "none"}

# ... agent does the work ...

# bg task notification fires; check terminal state
$ p9 status --pr 42 --json
{"open_prs": [{"pr": 42, "to_state": "GREEN", ...}]}

$ p9 merge-ready 42
PR #42 marked MERGE_READY (control metalayer authorizes merge)

# control-gate-hook authorizes; agent runs `gh pr merge`

Example 2 — Lint-failure self-heal

$ p9 status --pr 42 --json
{"open_prs": [{"pr": 42, "to_state": "RED_CLASSIFIED", "attempt": 0}]}

$ p9 heal 42 --classify
{"failure_type": "lint", "classified": true, "confidence": 0.8, "heal_command": "bun run lint:fix", "rationale": "matched lint at confidence 0.80"}

# agent runs heal_command, scoped to PR diff files
$ bun run lint:fix
$ git commit -am "fix(lint): heal CI"
$ git push --force-with-lease   # only if existing P6 policy permits
$ p9 watch 42 --background       # new WATCHING cycle; attempt=1

Example 3 — Unclassified-failure escalation

$ p9 heal 42 --classify
{"failure_type": "unclassified", "classified": false, "confidence": 0.0, "heal_command": null, "rationale": "no rubric pattern matched"}

# Agent does NOT attempt to heal. Creates a Linear ticket via MCP:
#   title: "[P9 ESCALATION] PR #42: feat/my-change"
#   body:  failure signature + log excerpt
#   label: ci-heal-escalation
# Watcher stays running — if a human pushes a fix, watcher resumes and
# the next green check transitions to MERGE_READY.

Cardinal invariant (hard rule)

P9 never silently drops state. Every failure produces (a) a
state.jsonl event, (b) a Linear ticket, or (c) both. If P9 cannot
write to state.jsonl AND cannot reach Linear, it crashes loudly
(exit 99) — degraded silent operation is forbidden.

See also

  • Spec: docs/superpowers/specs/2026-05-04-p9-ci-watcher-design.md
  • Rubric: references/scoring-rubric.md
  • CLI: scripts/p9.py (run python3 scripts/p9.py --help)
  • Related primitives: P1 (Conversation Bridge), P2 (Control Gate),

P3 (Linear Tickets), P4 (PR Pipeline), P5 (Parallel Agents), P6 (Knowledge Bookkeeping), P8 (Branch + Worktree Janitor), P10 (Worktree Hygiene Discipline), P11 (Empirical Feedback Loop).

Related skills

FAQ

What is the cardinal rule?

Never sleep on a blocking wait; convert the wait into productive work on the next priority, and for PR CI use p9 watch in the background.

How does it handle failures it cannot classify?

It does not attempt to heal; it creates a Linear escalation ticket and keeps the watcher running in case a human pushes a fix.

Does it authorize merges?

No. Merge authorization stays with the existing control metalayer (.control/policy.yaml); p9 only marks a PR merge-ready.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.