Skill Tracer
Skills › Compound Engineering › lfg › next-work-handoff.md

next-work-handoff.md

96 lines · skills/lfg/references/next-work-handoff.md at 3449230

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1# Next-work handoff
2
3Use this only at LFG closeout, after the current pipeline has finished or
4stopped for good. Its purpose is to offer continuity into a separately planned
5area without silently extending the completed plan or current session.
6

Next-work handoff

Use this only at LFG closeout, after the current pipeline has finished or stopped for good. Its purpose is to offer continuity into a separately planned area without silently extending the completed plan or current session.

Raw lines 1 to 6
7## Establish whether an offer is warranted
8
9Start from the canonical plan path retained from LFG step 1. Locate a Product
10Contract section carrying the semantic role `work-relationships`:
12- Markdown: `<!-- ce-section: work-relationships -->`
13- HTML: `data-ce-section="work-relationships"`
15The visible heading is not part of this protocol. For an older unmarked plan,
16use a semantic fallback only when one Product Contract section clearly names
17the area this plan covers, one or more future areas intended for separate
18planning, and their relationships. Do not infer eligibility from an exact
19heading, a generic list of non-goals, or a roadmap-like wish list. If the
20section's meaning is ambiguous, make no offer.
22An offer is warranted only when the completed work is explicitly one part of a
23larger body of separately planned work and at least one future area remains
24unplanned. Exclude an area that is already planned, completed, absorbed into
25the just-finished work, or no longer supported by current evidence. A residual
26implementation, review, PR, or merge task belongs to the current run's remaining
27shipping work; it is not a next brainstorm candidate and does not by itself
28suppress a valid future-area offer.

Establish whether an offer is warranted

Start from the canonical plan path retained from LFG step 1. Locate a Product Contract section carrying the semantic role work-relationships:

  • Markdown: <!-- ce-section: work-relationships -->
  • HTML: data-ce-section="work-relationships"

The visible heading is not part of this protocol. For an older unmarked plan, use a semantic fallback only when one Product Contract section clearly names the area this plan covers, one or more future areas intended for separate planning, and their relationships. Do not infer eligibility from an exact heading, a generic list of non-goals, or a roadmap-like wish list. If the section's meaning is ambiguous, make no offer.

An offer is warranted only when the completed work is explicitly one part of a larger body of separately planned work and at least one future area remains unplanned. Exclude an area that is already planned, completed, absorbed into the just-finished work, or no longer supported by current evidence. A residual implementation, review, PR, or merge task belongs to the current run's remaining shipping work; it is not a next brainstorm candidate and does not by itself suppress a valid future-area offer.

Raw lines 7 to 29
30## Recommend the next area
32Reason over the remaining candidates instead of taking the first bullet. Prefer
33the area that, based on the plan and what the pipeline learned:
351. has explicit user or plan priority;
362. can be meaningfully brainstormed now;
373. is enabled by the completed work;
384. unlocks the most downstream work;
395. reduces foundational uncertainty; or
406. especially benefits from fresh implementation knowledge.
42These are judgment criteria, not a points system. Do not choose by document
43order, apparent ease, wording similarity, or a dependency the plan does not
44support. Recheck the candidate against the current delivery result before
45offering it.
47- **One justified winner:** name it and give the shortest concrete reason it is
48 next.
49- **Real tie:** say current evidence does not justify choosing between the tied
50 areas. Offer a selection-focused handoff whose next session decides which one
51 coherent area to brainstorm.
52- **No ready candidate:** make no offer.

Recommend the next area

Reason over the remaining candidates instead of taking the first bullet. Prefer the area that, based on the plan and what the pipeline learned:

  1. has explicit user or plan priority;
  2. can be meaningfully brainstormed now;
  3. is enabled by the completed work;
  4. unlocks the most downstream work;
  5. reduces foundational uncertainty; or
  6. especially benefits from fresh implementation knowledge.

These are judgment criteria, not a points system. Do not choose by document order, apparent ease, wording similarity, or a dependency the plan does not support. Recheck the candidate against the current delivery result before offering it.

  • One justified winner: name it and give the shortest concrete reason it is next.
  • Real tie: say current evidence does not justify choosing between the tied areas. Offer a selection-focused handoff whose next session decides which one coherent area to brainstorm.
  • No ready candidate: make no offer.
Raw lines 30 to 53
54## Offer, then stop
56Place the offer before LFG's `<promise>DONE</promise>`. Keep it non-blocking and
57do not invoke `ce-handoff` yet.
59For one winner, use this shape in natural prose:
61> The clearest next area is **<area>** because <reason>. If you want to continue
62> it in a fresh agent session, I can create a `ce-handoff` for that brainstorm.
64For a real tie, name the tied areas and offer a fresh-session handoff focused on
65choosing the next coherent area. The pipeline still ends with the DONE promise;
66the offer is optional continuity, not another LFG step.

Offer, then stop

Place the offer before LFG's <promise>DONE</promise>. Keep it non-blocking and do not invoke ce-handoff yet.

For one winner, use this shape in natural prose:

The clearest next area is <area> because <reason>. If you want to continue it in a fresh agent session, I can create a ce-handoff for that brainstorm.

For a real tie, name the tied areas and offer a fresh-session handoff focused on choosing the next coherent area. The pipeline still ends with the DONE promise; the offer is optional continuity, not another LFG step.

Raw lines 54 to 67
Names a skill ce-handoff :57
68## If the user later accepts
70Only after explicit acceptance, resolve `ce-handoff` against the host's
71available-skills list and invoke `create` with a compact, labeled next-work
72brief. LFG owns the recommendation: it has already chosen, so do not ask
73`ce-handoff` to rediscover or rank candidates. Include:
75- **Next-session objective:** brainstorm one coherent next area and produce a
76 requirements-only unified plan.
77- **Recommended area:** the winner, or the tied candidate set when the session
78 must choose.
79- **Why next:** the evidence-based selection rationale.
80- **Authoritative prior plan:** the repo-relative canonical plan path.
81- **Relationship to completed work:** the explicit depends-on, enables, shares,
82 or independent relationship.
83- **Actual delivery state:** what finished and what remains in the current run's
84 shipping steps, such as implemented, PR open, CI decided, or not merged.
85- **Carry-forward decisions:** only prior decisions that constrain the next
86 area.
87- **Assumptions to revalidate:** provisional relationships or facts that the
88 fresh brainstorm must not inherit as settled.
89- **Other candidates not selected:** each alternative and why it was not chosen,
90 when that context prevents repeated selection work.
91- **Artifact boundary:** create a separate requirements-only unified plan for
92 the next area, cite the prior plan, and do not extend or edit the prior plan.
94Keep the brief short, and point at files rather than copying them. Do not paste
95the prior Product Contract into it; the plan remains authoritative and the
96handoff explains what the next session needs to decide.

If the user later accepts

Only after explicit acceptance, resolve ce-handoff against the host's available-skills list and invoke create with a compact, labeled next-work brief. LFG owns the recommendation: it has already chosen, so do not ask ce-handoff to rediscover or rank candidates. Include:

  • Next-session objective: brainstorm one coherent next area and produce a requirements-only unified plan.
  • Recommended area: the winner, or the tied candidate set when the session must choose.
  • Why next: the evidence-based selection rationale.
  • Authoritative prior plan: the repo-relative canonical plan path.
  • Relationship to completed work: the explicit depends-on, enables, shares, or independent relationship.
  • Actual delivery state: what finished and what remains in the current run's shipping steps, such as implemented, PR open, CI decided, or not merged.
  • Carry-forward decisions: only prior decisions that constrain the next area.
  • Assumptions to revalidate: provisional relationships or facts that the fresh brainstorm must not inherit as settled.
  • Other candidates not selected: each alternative and why it was not chosen, when that context prevents repeated selection work.
  • Artifact boundary: create a separate requirements-only unified plan for the next area, cite the prior plan, and do not extend or edit the prior plan.

Keep the brief short, and point at files rather than copying them. Do not paste the prior Product Contract into it; the plan remains authoritative and the handoff explains what the next session needs to decide.

Raw lines 68 to 96
Names a skill ce-handoff :70