The Shape of a ccxp-skills Week

We wrote previously about where ccxp-skills comes from — the Pivotal Labs lineage, pair programming, the practice that outlived the company that made it famous. That post was about the “why.” This one starts a seven-part series about the “how”: the actual shape of an engineering week run on ccxp-skills, the public, config-driven Claude Code skill set we use internally. ccxp-skills is public on GitHub — a “generic ccxp-family Claude Code workflow skill set, no company-specific dependencies,” per its own description — so everything below is something you can go verify against the source yourself.

This post stays at a glance. Six companion posts, publishing weekly after this one, go deep on each piece: the Monday IPM, the daily standup and its unattended cron mode, the claim mechanism that keeps concurrent sessions safe, /drive’s full phase chain, the Friday retro, and why the backlog is plain markdown files instead of a ticket in an external tracker.

The shape of a week

A week has three fixed rituals and one continuous loop running underneath them:

• Monday — the Iteration Planning Meeting (/ipm) commits the week’s focused work.
• Every day — a standup (/ccxp Phase 1) reviews what shipped, checks overnight CI, and posts a summary.
• Friday — a retrospective (/retro) grades the week against what Monday committed to, and files action items.
• In between — /drive does the actual implementation: pick a task, design it, build it, ship it, close it.

An orchestrator skill, /ccxp, ties these together and can run two ways: interactively, with a human at the keyboard, or unattended, via a cron wrapper (dev/daily-ccxp.sh) that sets CCXP_CRON_MODE=1. That one environment variable is most of the line between what the system will do on its own and what it reserves for a human. Standup, the nightly health check, the Monday budget-cut, and the Friday retro all run the same way in both modes — they’re process bookkeeping, not product judgment calls. The pre-IPM design pass (deciding whether a candidate task is actually ready, and how big it really is) and the hands-on implementation loop are reserved for a human to kick off interactively; the cron wrapper runs the week’s rituals and stops rather than inventing new work on its own.

The cron doesn’t run on a fixed schedule so much as an hourly check for whether there’s anything worth waking up for: a due task, PR activity, a CI failure, or the daily floor. When it does wake up and finds every candidate gated — a task claimed by someone else, waiting on an external console, whatever — it doesn’t burn a full standup regenerating a summary that says nothing new. A short-circuit called the “cheap-hold” posts one compact status update and exits instead. It’s a small detail, but it’s the difference between an unattended loop that’s actually cheap to run continuously and one that racks up a real bill doing nothing.

What the six deep-dive posts cover

Full mechanics live in their own posts, not here:

• The Monday IPM — the Tier 1 (in-flight carry-forward) / Tier 2 (new work) split, the weekly capacity budget cut into product, infrastructure, and slack lines, and the hard gate that keeps the previous iteration from quietly going undrained.
• The daily standup and the unattended cron loop — what a standup actually checks and reports, and how the cron wrapper decides whether a given hour is worth waking up for at all.
• The claim mechanism — how dev/TODO/*.md frontmatter and a plain git merge keep a human working interactively and an hourly cron from ever quietly colliding on the same task.
• /drive’s phase chain — the pick → claim → design → implement → review → merge → close sequence that turns one task into one shipped PR, and what happens when a task turns out to be blocked by another.
• The Friday retro — how the week gets graded against what Monday committed to, and what happens to a task that keeps losing the coin flip.
• Why the backlog is markdown files, not a ticket in Jira — the deliberate choice to make the file itself the single source of truth, with no external tracker to keep in sync by hand.

That’s the shape of the system, at a glance: three fixed rituals, one continuous build loop, and an orchestrator that knows the difference between bookkeeping it can do alone and work that needs a human to say “go.” None of it is proprietary to us — it’s on GitHub, config-driven, and built to be adopted by any team running Claude Code, not just ours. The next post in this series, on the Monday IPM, publishes the following week.