Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/promptctl/laws --skill nextThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Based on SOC occupation classification
| name | next |
| description | Pull the next ticket |
Pick up the next ready ticket and start work.
Run lit quickstart if you haven't already. This provides instructions for using the work tracking system.
If the user provided specific information (e.g., a ticket id or area of the codebase to work on), SKIP THE REST OF THESE INSTRUCTIONS and follow the guidance from lit quickstart to follow the user instructions. The following information is for determining which work to pick when the user did not specify.
Take a look at the backlog (lit ready) so you understand what work is in-progress or up next. Now you need to decide whether you need to wrap up in-progress work or start new work.
If there are uncommitted changes or open PRs in the repo, we want to wrap these up before starting new work.
determine if these changes are related to a backlog item. If so, that is your current ticket. If not, stop and think to your self: Are these changes worthwhile? Accidential? Incidental? Should we commit or discard them? Use your brain to think about the right solution because there is no one size fits all rule.
Examples:
Before proceeding, confirm the uncommitted changes are now resolved (committed, stashed, or discarded per the above). If anything you did previously resulted in a reference to a specific ticket, THAT IS YOUR TICKET ID and you should skip the backlog scan and go straight to "Working the ticket".
Do NOT proceed without either:
Check for open PRs related to your current branch — gh pr list --head "$(git branch --show-current)" --state open (lit ready lists tickets, not GitHub PRs, so it won't surface one). If there are, THIS IS YOUR TICKET! Skip the backlog scan below and work that PR through the address-pr-reviews skill (that's the memento skill for taking a PR's review feedback to a clean, merged close-out), then pick up the working steps under "Working the ticket".
If there are no open PRs on the current branch: we'll proceed with pulling from the backlog. Open PRs are still relevant, though — you want to check whether older open PRs overlap with your work, since rebuilding on top of stale code risks significant merge conflicts. Check this after you pull a ticket; if an older PR touches the same files, surface it to the user with both the ticket and PR references before starting, rather than silently building over it.
Lit ready shows an overview of the epics and the top ticket in each epic, as well as any in-progress or orphaned tickets.
If there are any orphaned tickets, pull from those first — those tickets are abandoned and need someone to finish them. An orphan is your ticket; skip ahead to "Working the ticket".
Otherwise, take from the top of the ready queue.
However you arrived at a ticket — uncommitted work, an open PR, an orphan, or the ready queue — work it through these steps:
Read the ticket fully. Title, description, acceptance criteria, comments, linked PRs, linked tickets. If the ticket references a spec, doc, or prior PR, read that too. You are about to author code that claims to satisfy this ticket — earn the right to claim it.
Surface blockers before starting.
IN ALL CASES YOU MUST DO AS MUCH OBVIOUS PREPARATORY WORK AS YOU CAN BEFORE ASKING THE USER.
A mature engineer knows when to ask for help, and it isn't at the slightest hint of ambiguity and before they've put in a shred of effort to answer the question themselves. "What do I do with this uncommited work" is only a good question if it isn't obviously work that Directly corresponds to the ticket matching the branch name. "Acceptance criteria missing or vague?" It is only a good question if it's not clearly answerable via common sense or existing documentation or some other method. If there's real ambiguity, surface it. If it's just basic information about the repo, see if you can figure it out for yourself. In all cases, the user should be presented with The results of an Extremely quick Investigation rather than "Hey, I don't know what to do. Tell me what to do."
Set up the workspace.
git checkout -b <ticket id> or git checkout -b <ticket id>_slug — if that branch already exists (a previously-started ticket), check it out instead with git checkout <ticket id>.State the plan in one paragraph, then start. What the ticket asks for, how you'll verify it's done (the machine-verifiable criterion), and the first concrete step. Then begin.
To be honest, rarely. You should be capable of figuring this stuff out.
If you think that there's a chance that this could have negative impacts on other work, you can ask a quick question, but like I said, You need to make an attempt to answer the question yourself. (The one recurring case — a branch carrying uncommitted work that belongs to no current ticket — is already handled in "Uncommitted changes" above.)