session-add-task
Skill3 starsChanged 5 months agoMITView on GitHub
Capture a new work item into the project's work root with its original request, interpretation and provenance. Use when something surfaces that should be done later — a bug, an optimization, a follow-up — and you want it recorded so it can be accepted and picked up. Produces a work item in the captured state, identity allocated by the runtime, and the regenerated sequence entry that shows it. Triggers on "/session-add-task" or when user says "add a task", "capture this for later", "put this on the backlog", or "remember to do X".
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- security-liability-auditSkill
- session-brainstormSkill
- session-debugSkill
- session-delegationSkill
- session-gatekeeperSkill
- session-groomSkill
- session-initSkill
- session-nextSkill
- session-post-implementationSkill
- session-releaseSkill
- session-repairSkill
- session-research-designSkill
- session-task-planningSkill
- session-verifySkill
- update-architectureSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
The runtime allocates identity: Never pick a SEQ-NNN yourself and never scan the sequence for the next free number.
- Very specific: line 18
The sequence is generated output: Never append to it, never edit it, never read it as the authority for what exists.
- Very specific: line 25
Read .session-flow.json for paths.work and paths.sequence.
- Distinctive: line 77
When unsure which mode, ask the user one question: "Quick capture, full instructions now, or is this big enough to plan as multiple tasks?"
- Very specific: line 81
Write the payload to a file and pass it with --input.
- Very specific: line 125
Run transition. Read result.reserved for the allocated identity and result.records[0].path for the record.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Session Add Task
Capture work into the work root so it can be accepted later and picked up with "implement the next task".
Open with one sentence saying what you are about to do and what it will produce.
Non-Negotiables
- Capture grants no implementation permission. A captured item is not executable, and neither a linked breakdown nor a written
Filesfield makes it so.selectrefuses acaptureditem by name; only an acceptance naming the current scope fingerprint makes it eligible. Never implement what you have just captured because you also happen to know how. - The runtime allocates identity. Never pick a
SEQ-NNNyourself and never scan the sequence for the next free number.transitionreserves the identity under the root lock against retained homes and tombstones, so a retired id stays taken and two concurrent captures cannot collide. - The originator's words are preserved verbatim, separately from your reading of them.
original_requestholds what was actually asked, unedited; the interpretation goes in the body under its own heading. A later session must be able to see that you misread the request. - Every capture carries provenance. Who asked, when, whether a skill enqueued it, and — when the work came from somewhere addressable — the source URL and the capture id that deduplicate it.
- The sequence is generated output. Never append to it, never edit it, never read it as the authority for what exists.
renderwrites it from the work root, and a line typed there is lost at the next render. - Keep it compact. A small clear item is
intent.mdand nothing else. Nospec.md, noplan.md, notasks/directory, no empty optional section. - Action verbs, and never cite a path that does not exist. "Create", "Add", "Extract" — not "Consider", "Look into". Existence-check every path you write into
FilesorTest(test -f, ortest -dfor a glob's root) before capturing it. The one exception is a path the item's own instructions create — say so inline (new file).
Path Resolution
- Resolve the runtime entrypoint by the one rule for this host —
${CLAUDE_PLUGIN_ROOT}natively, the discovered installed location under Codex, thesession-flow-runtime.jsondescriptor beside thisSKILL.mdfor a standalone copy (references/runtime-integration.md). Use absolute paths for both the interpreter and the entrypoint. - Read
.session-flow.jsonforpaths.workandpaths.sequence. The runtime resolves both itself from--project-root; you read them to find the records. Confirm the root answers before writing anything:
python3 -B "$ENTRYPOINT" --project-root "$PROJECT_ROOT" doctorA named error, a missing work root, or a missing
namespace.jsonmeans stop and report it. There is no hand-editing path: mutation fails closed.
The Generated Sequence
render writes one line per unfinished work item into paths.sequence, from the record's own fields:
- [ ] SEQ-007 P2: Add rate limiting to the API ⇄ https://github.com/owner/repo/issues/42 (needs breakdown)| Token | Rendered from |
[ ] open · [DEFERRED] retired; a done item is not listed | lifecycle |
SEQ-NNN | seq, allocated at capture |
P1/P2/P3 | priority |
[auto] after the priority | provenance.auto |
⇄ <url> before the trailing token | each entry of annotations |
trailing → <link> | links.breakdown, plus links.anchor |
trailing (needs breakdown) | needs_breakdown |
an <!-- … --> line below the entry | each entry of notes |
An entry ends in exactly one trailing status token — the link or the (needs breakdown) marker, never both — because external parsers strip exactly one, and an unknown trailing tag hides the annotations behind it. Anything that does not fit goes below the line as a notes comment. Full grammar and cross-writer contract: references/sequence-grammar.md. Record fields and lifecycle: references/work-item-contract.md.
Provenance
provenance.auto renders as [auto] and says a skill enqueued the entry on the user's behalf. It is off by default — a user invoking /session-add-task produces an unmarked entry — and set only when the caller is a skill enqueuing without the user having seen the item, /session-gatekeeper triage being the one shipped caller. [auto] records provenance and is the veto handle: a marked entry sits in the sequence and can be struck on sight. It is never authority, and it never makes an item eligible.
annotations renders as ⇄ <url> and says this item and that external item are the same work. Never invent one: it is the only key another writer can dedup on, because this skill rewrites raw issue titles into task phrasing and the titles never match. Store the same URL in source and a stable key in capture_id (github:owner/repo#42, notion:<page-id>), so a second importer can match on the record rather than on a rendered line.
Modes
Pick the mode based on the item's size and how ready it is.
Mode A — Compact (default)
The work is well-understood and session-sized (1-5 files). One record carries all of it: the request, your reading of it, and the instructions an agent will execute. The body carries Files, Instructions, Accept and Test; the scope region carries the acceptance-bearing behaviour. Set no needs_breakdown.
Mode B — Multi-task
The work spans many files or several independent outcomes. Capture the item here, then hand off to /session-task-planning, which attaches the expanded artifacts to this same identity. Do not cram it into one record and do not allocate a second one.
Mode C — Capture only
The user just wants it recorded; research comes later, via /session-groom. Capture the request and the provenance, set "needs_breakdown": true, and write no instructions you have not verified.
When unsure which mode, ask the user one question: "Quick capture, full instructions now, or is this big enough to plan as multiple tasks?"
The Capture Payload
Write the payload to a file and pass it with --input. No option accepts free text, and nothing in it is executed.
python3 -B "$ENTRYPOINT" --project-root "$PROJECT_ROOT" transition --input "$PAYLOAD"{
"operation": "add-task-<unique-token>",
"coordinator": "session-add-task",
"changes": [
{
"new": true,
"scope": "The behaviour that would make this done, in the requester's terms.",
"body": "## Original request\n\n> verbatim\n\n## Interpreted intent\n\nWhat you understood.\n\n**Files**: `path/to/file.ext`\n\n**Instructions**:\n- Step 1 (action verb)\n\n**Accept**: observable outcome\n\n**Test**: `exact command`\n",
"metadata": {
"title": "One line, task phrasing",
"lifecycle": "captured",
"priority": "P3",
"original_request": "verbatim, unedited",
"source": "https://github.com/owner/repo/issues/42",
"capture_id": "github:owner/repo#42",
"annotations": ["https://github.com/owner/repo/issues/42"],
"provenance": {"origin": "user", "actor": "<who asked>", "captured_at": "<ISO-8601 UTC>", "auto": false},
"needs_breakdown": true
}
}
]
}The runtime always creates the record as captured: the lifecycle key is ignored, and so are the helper-owned fields (claim, result, evidence, corrections, acceptance, scope_checks and a delivery receipt), which are dropped.
For the required and optional fields of any other payload, run python3 -B "$ENTRYPOINT" --project-root "$PROJECT_ROOT" schema <command>; it returns a minimal example.
operation is unique per capture: re-sending the same id with the same payload returns the first result instead of capturing twice, and re-sending it with a different payload is refused. Omit source, capture_id and annotations for something surfaced in conversation rather than filed anywhere — never invent a URL to fill the slot. Omit needs_breakdown in Mode A. Set "auto": true only when a skill is enqueuing on the user's behalf.
Files doubles as the dispatch write boundary — /session-delegation injects it as "you may only create or modify these paths" — so an incomplete field stalls the agent rather than widening its lane. It is a prompt-level constraint, not an enforced one.
Workflow
- Resolve the runtime and the paths; run
doctor. - If the item has a source URL, check it before capturing. Grep the work root's
intent.mdfiles for the URL and the capture id —grep -rl "<url>" "$WORK_ROOT"— not only the generated sequence, because records are the authority. On a hit, stop: report the existing item'sSEQ-NNNand capture nothing. This is the same exclusion session-scribe's/scribe-pullruns in the other direction, and the two checks together make the key symmetric between writers. - Pick the mode (A/B/C) and write the payload to a file.
- Run
transition. Readresult.reservedfor the allocated identity andresult.records[0].pathfor the record. - For Mode B, hand the allocated identity to
/session-task-planning. - Report: the allocated
SEQ-NNN, the record path, the item's state (captured), and that acceptance is a separate decision the item does not yet have.
Anti-Patterns
Treating capture as approval:
- BAD: "I've added SEQ-011 and started on it"
- GOOD: "Captured as SEQ-011. It is
captured, not accepted —selectwill refuse it until someone accepts the scope."
Choosing the id yourself:
- BAD: scanning
SEQUENCE.mdfor the highest number and adding one - GOOD: let
transitionreserve it; the sequence is a rendering and a retired id it no longer shows is still taken
Editing the sequence:
- BAD: appending the new entry to
SEQUENCE.mdso it shows up immediately - GOOD:
transitionre-renders it; a line typed there is lost at the next render
Paraphrasing the request into the record:
- BAD:
original_request: "user wants rate limiting" - GOOD:
original_request: "can we stop people hammering the API", with your reading of it under Interpreted intent — the gap between the two is the thing a later session needs to see
Deduping by title instead of URL:
- BAD: skipping the source check because "no existing item has this title"
- GOOD: grep the work root for the URL. This skill rewrites raw issue titles into task phrasing, so an item's title never matches its source's — and near-matches across unrelated items do. The URL is the only key.
Chain context: see references/workflow-overview.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

