Work continuity efficiency
Skill nevitonsantana/adaptive-skills/skills/work-continuity-efficiency
Make oversized or interrupted work smaller, resumable, reviewable, and clear to hand off through selective use of continuity building blocks.From its SKILL.md
npx -y skills add nevitonsantana/adaptive-skills --skill work-continuity-efficiencyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.2 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Overview
Use this optional family entrypoint when work is too large, interrupted, context-heavy, or
crosses operators and the right continuity building block is not yet clear. It selects the
smallest sufficient path through task-chunking, checkpoint-review, handoff-summary, and
communication.
Use a building block directly when the need is already specific. This family does not manage tasks, persist state, schedule agents, or replace project governance.
When to Use
- A large request needs a safe first slice and explicit stop condition.
- Work may be resumed by another session, person, or agent.
- The task changed shape and needs a continue, stop, or handoff decision.
- A status, decision, failure, or handoff needs to become legible without carrying full context.
When NOT to Use
- The task is already a small, obvious execution pass.
- The work needs product, architecture, policy, or macro-gate judgment instead.
- The requester expects task tracking, scheduling, automatic persistence, or external actions.
- A direct building block already matches the question.
Core Moves
- Frame the continuity need. Identify the work state, current round, intended outcome, next owner, unresolved uncertainty, and minimum proof.
- Classify the dominant need. Choose chunking, checkpointing, handoff, or communication; do not treat all continuity concerns as the same problem.
- Select the smallest path. Activate one primary building block and add another only when its output is necessary for safe continuation.
- Produce a bounded artifact. State what changed, what is proved, what remains open, and the explicit stop, continue, or handoff condition.
- Verify resumability. Confirm that another operator can continue without reconstructing the original context and without confusing assumptions with proof.
Building Blocks
task-chunking— smallest useful slice, dependencies, boundaries, and stop condition.checkpoint-review— continue, stop, or handoff decision after a meaningful round.handoff-summary— compact verified context for another round or owner.communication— clear status, decision, failure, or handoff explanation.
Use only the blocks justified by the continuity need. Family membership does not load all four contracts by default.
Optional Modules
- Continuity need framing — Bound the current round, intended outcome, next owner, and minimum proof before selecting a path.
- Dominant need classification — Distinguish slicing, checkpointing, handoff, and communication needs.
- Selective composition — Add a supporting building block only when its output is needed for safe continuation.
- Resumability check — Test whether another operator can act without reconstructing the original context.
Activation Triggers
- Activate
task-chunkingwhen the task is oversized, fuzzy, or entangled. - Activate
checkpoint-reviewwhen the task changed shape or continuation is uncertain. - Activate
handoff-summarywhen another round, owner, or agent must resume the work. - Activate
communicationwhen the result must be made legible as status, decision, failure, or handoff information.
Expected Output
work_continuity_review:
work_state: <current state>
intended_outcome: <outcome>
dominant_need: chunk | checkpoint | handoff | communication
primary_building_block: <skill>
supporting_building_blocks: [<only necessary skills>]
proved: [<validated facts or artifacts>]
open_items: [<unresolved items>]
decision: continue | stop | handoff
stop_condition: <condition>
next_step: <bounded next action>
handoff_owner: <owner or unknown>
risks_or_blockers: [<visible risks>]
Verification
- The current state and dominant continuity need are explicit.
- One primary building block is selected and justified.
- Supporting blocks are necessary rather than merely adjacent.
- Proven work is separated from assumptions and open items.
- Stop, continue, or handoff is explicit.
- The artifact is smaller than the context it replaces and sufficient to resume safely.
- No task tracking, scheduling, persistence, or external action is claimed.
Handoff Signals
- Product or feature scope is unresolved →
intent-clarificationorfeature-planning. - A macro gate, authorization, or ownership decision is required → AletheIA or consumer governance.
- The next work needs a different specialty → hand off with
handoff-summary. - The work is clear but only needs a direct slice → use the matching building block directly.
Pairs Well With
workflowfeature-planningcheckpoint-reviewhandoff-summarycommunication
Anti-patterns
- Loading all continuity skills for every task.
- Calling a large task a slice without reducing it.
- Continuing only because the round has momentum.
- Writing a handoff that hides missing proof or unresolved ownership.
- Turning continuity guidance into a project-management runtime.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most performance cost skills give in ~1.1k tokens
Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07
- Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
- Use imperative form in instructionsin 80 of 803, across 9 files
- Draft assertions while test runs are in progressin 75 of 803, across 9 files
- Create two to three realistic test promptsin 74 of 803, across 9 files
- Write skill descriptions to be pushyin 72 of 803, across 7 files
- Save test cases to evals JSONin 72 of 803, across 6 files
- Ask questions about edge cases and input formatsin 72 of 803, across 7 files
- Save timing data immediately when runs completein 70 of 803, across 5 files
- Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
- Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
- Capture intent before writing a skillin 67 of 803, across 1 file
- Import directly instead of barrel filesin 52 of 803, across 15 files
Said here and by no other author read
- frame the work state and intended outcome
- classify the dominant continuity need
- select the smallest sufficient path
- activate one primary building block
- produce a bounded resumability artifact
- state an explicit continue stop or handoff condition
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.