os-whats-next
Answer "what do we do now" with the next move, not a map. The user does not
need the dependency graph - they need what got finished, what to take next,
and why, in plain words. This skill decides; os-step-by-step walks the user
through their part; os-done-or-not reports what came of it.
Language
Write in the language the user speaks in this session, detected from the
conversation. Commands, file names and identifiers stay English.
When to use
Triggers: the description above, plus a session just ended wanting a next move.
Step 1 - read the state, quickest first
Stop as soon as you can answer.
- The last report -
~/.claude/open-steps/reports/<project>/latest.md:
a handover written for exactly this moment.
- Local state - uncommitted changes, unpushed commits, current branch.
- Open pull requests - one call:
gh pr list --json number,title,mergeStateStatus,reviewDecision,isDraft.
- The backlog - always. The issue tracker when one is already connected
(never authenticate or install one), otherwise task files in the repo:
ROADMAP.md, PLAN.md, TODO.md, docs/plan*. Next work comes from the
backlog, not from imagination. No backlog anywhere → say so.
Say which sources you did not read: an unread source is not an empty source.
Step 2 - finish what is finished
A pull request with green checks and an approval is not a decision - it is
unfinished business. Verify it through os-check-work's accept rules and
merge it in this same pass. Two things stop the merge: a failed claim, and a
task instruction that merges happen on command only - an orchestrator may own
the merge. Report it as done, never as a question.
Step 3 - sort what remains into two lists
| List |
Belongs there when |
| I can do this alone |
everything needed is at hand: no decision, no secret, no approval, no device |
| Needs you |
a decision, an approval, a secret, a purchase, or a device only the user has |
Blocked work gets no section of its own. Fold it into the reasoning, in plain
words - "X waits on an outside check; I watch it" - the user trusts the
recommendation, not the graph.
The shape - ten lines, like every report in this pack
<Lead: one sentence on where things stand - including what this pass merged.>
**I can do alone:** <up to three items, five words of why each>
**Needs you:** <up to three items, one line each - or drop the list>
**Next I take: <the one task> - <plain words: what it closes or unblocks>.**
<One line: what was not checked.>
When a quick small win and a big item are both real candidates, offer the
choice with the native picker - two to four options, the recommended one first
and marked; where the picker is not available, one plain sentence. On the
pick, prepare the launch: a prompt complete enough to paste or a command
complete enough to run, one line saying what comes out - and never run it
yourself.
How many at once
Before offering to start several, prove they will not collide - all three:
| Check |
They collide when |
| Same files |
both touch the same files, module, or migration sequence |
| Same shared resource |
one working copy, branch, database, container project, port |
| One feeds the other |
the second needs the first one's output |
Any check failing → one at a time, saying which failed. All passing → say so.
Never claim parallel safety you did not verify - "I did not check" is honest;
a collision discovered mid-run is not. Where the project isolates parallel
work - a working copy per task, separate container projects or ports - name
that as the precondition instead of assuming it.
Hard rules
- Three items per list, maximum - more → say how many were left out and
on what basis you chose.
- Every item names its source - the report, a pull request, a backlog
entry, a failing check. Your own idea is marked a suggestion, and lists are
never padded: two real items beat five with filler.
- One recommendation, always - even when offering the small-versus-big
choice, one option carries the mark and one line of plain-words reasoning.
- Finish, then prepare - never start. Merging a verified-ready pull
request is finishing. New work is prepared as a ready-to-run launch and
waits for the pick.
- Say what you did not check - especially the backlog. Silence reads as
"nothing there".
- Plain words - no engineering identifiers except where they name an
action.
Known gotchas
- Deferred-until-Monday is not a task on Saturday: do not re-propose it early.
- A stale tracker is worse than none - say when you read it.
- Draft pull requests are yours to finish, not the user's to merge.
- A needs-you pick goes to
os-step-by-step, never explained inline.
- "Ready to merge" is still a claim: the verify step is what makes it true -
skipping it to move faster is how wrong work lands.
1---2name: os-whats-next3description: ALWAYS invoke this skill when the user asks what to do next, what is left, or what is blocked - "what's next", "what now", "what should we work on", "anything I can do" - in any language. This skill picks the next piece of work; when the user asks HOW to do a thing or says they do not understand what to do, that is os-step-by-step. Reads the last report, local changes, open pull requests and always the backlog. First finishes what is finished: verified-ready pull requests merge in the same pass. Then sorts the rest into doable-alone and needs-you, ending with one recommended next task in plain words - what it closes or unblocks. Never invents tasks.4---5
6# os-whats-next
7
8Answer "what do we do now" with the next move, not a map. The user does not
9need the dependency graph - they need what got finished, what to take next,
10and why, in plain words. This skill decides; `os-step-by-step` walks the user
11through their part; `os-done-or-not` reports what came of it.
12
13## Language
14
15Write in the language the user speaks in this session, detected from the
16conversation. Commands, file names and identifiers stay English.
17
18## When to use
19
20Triggers: the description above, plus a session just ended wanting a next move.
21
22## Step 1 - read the state, quickest first
23
24Stop as soon as you can answer.
25
261. **The last report** - `~/.claude/open-steps/reports/<project>/latest.md`:
27 a handover written for exactly this moment.
282. **Local state** - uncommitted changes, unpushed commits, current branch.
293. **Open pull requests** - one call:
30 `gh pr list --json number,title,mergeStateStatus,reviewDecision,isDraft`.
314. **The backlog - always.** The issue tracker when one is already connected
32 (never authenticate or install one), otherwise task files in the repo:
33 `ROADMAP.md`, `PLAN.md`, `TODO.md`, `docs/plan*`. Next work comes from the
34 backlog, not from imagination. No backlog anywhere → say so.
35
36Say which sources you did not read: an unread source is not an empty source.
37
38## Step 2 - finish what is finished
39
40A pull request with green checks and an approval is not a decision - it is
41unfinished business. Verify it through `os-check-work`'s accept rules and
42merge it in this same pass. Two things stop the merge: a failed claim, and a
43task instruction that merges happen on command only - an orchestrator may own
44the merge. Report it as done, never as a question.
45
46## Step 3 - sort what remains into two lists
47
48| List | Belongs there when |
49|---|---|
50| **I can do this alone** | everything needed is at hand: no decision, no secret, no approval, no device |
51| **Needs you** | a decision, an approval, a secret, a purchase, or a device only the user has |
52
53Blocked work gets no section of its own. Fold it into the reasoning, in plain
54words - "X waits on an outside check; I watch it" - the user trusts the
55recommendation, not the graph.
56
57## The shape - ten lines, like every report in this pack
58
59```
60<Lead: one sentence on where things stand - including what this pass merged.>
61
62**I can do alone:** <up to three items, five words of why each>
63**Needs you:** <up to three items, one line each - or drop the list>
64
65**Next I take: <the one task> - <plain words: what it closes or unblocks>.**
66<One line: what was not checked.>
67```
68
69When a quick small win and a big item are both real candidates, offer the
70choice with the native picker - two to four options, the recommended one first
71and marked; where the picker is not available, one plain sentence. On the
72pick, prepare the launch: a prompt complete enough to paste or a command
73complete enough to run, one line saying what comes out - and never run it
74yourself.
75
76## How many at once
77
78Before offering to start several, prove they will not collide - all three:
79
80| Check | They collide when |
81|---|---|
82| Same files | both touch the same files, module, or migration sequence |
83| Same shared resource | one working copy, branch, database, container project, port |
84| One feeds the other | the second needs the first one's output |
85
86Any check failing → one at a time, saying which failed. All passing → say so.
87Never claim parallel safety you did not verify - "I did not check" is honest;
88a collision discovered mid-run is not. Where the project isolates parallel
89work - a working copy per task, separate container projects or ports - name
90that as the precondition instead of assuming it.
91
92## Hard rules
93
941. **Three items per list, maximum** - more → say how many were left out and
95 on what basis you chose.
962. **Every item names its source** - the report, a pull request, a backlog
97 entry, a failing check. Your own idea is marked a suggestion, and lists are
98 never padded: two real items beat five with filler.
993. **One recommendation, always** - even when offering the small-versus-big
100 choice, one option carries the mark and one line of plain-words reasoning.
1014. **Finish, then prepare - never start.** Merging a verified-ready pull
102 request is finishing. New work is prepared as a ready-to-run launch and
103 waits for the pick.
1045. **Say what you did not check** - especially the backlog. Silence reads as
105 "nothing there".
1066. **Plain words** - no engineering identifiers except where they name an
107 action.
108
109## Known gotchas
110
111- Deferred-until-Monday is not a task on Saturday: do not re-propose it early.
112- A stale tracker is worse than none - say when you read it.
113- Draft pull requests are yours to finish, not the user's to merge.
114- A needs-you pick goes to `os-step-by-step`, never explained inline.
115- "Ready to merge" is still a claim: the verify step is what makes it true -
116 skipping it to move faster is how wrong work lands.
majiayu000