Stats
Actions
Tags
Create and manage work items in the top-level Work/ folder — each a multi-session effort with a Spec (what to build), a Tasks checklist (one task ≈ one session), and a Progress log. This is the project's execution state, separate from the Wiki knowledge base. Use for: "new work item", "start a work item", "spec out X", "plan for X", "break X into tasks", "track this across sessions", "add a task", "update the spec", or the /work command. Creates Work/Backlog/<Name>.md, bootstrapping the folder if missing. A work item's status is its folder (Active/Backlog/Done/Dropped), not a field. Specs follow the revise protocol. Do NOT trigger on casual uses of the word "work".
How this skill is triggered — by the user, by Claude, or both
Slash command
/computational-research:workThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
`Work/` is the project's execution state — what we're building right now.
Work/ is the project's execution state — what we're building right now.
Each file is one work item: a Spec (what to build), Tasks (one ≈ one session), and a Progress log.
Durable knowledge goes in Wiki/; planning and progress go here.
Work items follow the revise protocol — the LLM drafts the Spec, presents it, and waits for approval before work begins.
An item's status is which folder it lives in — there is no status field.
State is encoded once, in the filesystem; changing state is a git mv.
Work/
├── README.md — index: active items + their next task; buckets are linked, not re-listed
├── Active/ — in progress <Name>.md
├── Backlog/ — proposed / not started <Name>.md (drafts live here)
├── Done/ — completed YYYY-MM-DD-<Name>.md (by completion date)
└── Dropped/ — abandoned / superseded YYYY-MM-DD-<Name>.md (by drop date)
Names are clean (<Name>.md, CamelCase) while an item is live in Active/ or Backlog/ — that is what you reference it by.
On archival the file is git mv'd into Done/ or Dropped/ and prefixed with that day's date (date +%F), so the archives read chronologically.
Resolve an item by name with an exact path in Active/ then Backlog/; glob Done/*-<Name>.md and Dropped/*-<Name>.md for archived ones.
If Work/ does not exist, create it and seed Work/README.md from ${CLAUDE_PLUGIN_ROOT}/skills/new-project/assets/work_readme_template.md (substitute the project name).
The folder is tracked in git — do not gitignore it.
Create each bucket (Active/, Backlog/, Done/, Dropped/) lazily the first time an item lands in it.
Ask for a CamelCase name and a one-line goal.
Copy ${CLAUDE_PLUGIN_ROOT}/skills/new-project/assets/work_item_template.md to Work/Backlog/<Name>.md, set the heading, and draft the ## Spec — for a quick item the one-paragraph goal is enough; for a heavy one fill Requirements / Design / Edge cases.
Fill the Origin: line in the Spec with the user's originating request.
If the project has prompt tracking on (see the provenance skill), also append a Wiki/Prompts.md ledger entry for the new item.
When CLAUDE.md has Semantic line breaks: on (the default — see its Source formatting rule), write the Spec and other prose in this item one sentence per source line.
Show the Spec and wait (revise loop).
A spec in Backlog/ is still a malleable draft; approval is the gate to starting work, not a field to flip.
Derive ## Tasks from the approved Spec — each unchecked box should be one focused session.
To start work now, git mv the file into Active/ (it is now the approved contract) and add it to the index in Work/README.md.
To queue it for later, leave it in Backlog/.
Work/README.md lists the Active items and each one's next unchecked task — the one thing the folders can't show.
It does not re-list Backlog/, Done/, or Dropped/; those are just linked, since the folder is already the record.
Update an active item's line when its next task changes; drop the line when the item leaves Active/.
git mv into Active/, clean name).git mv into Done/, prefix with today's date.git mv into Dropped/, prefix with today's date.After any move, fix Work/README.md (it tracks only Active/).
The Spec is the contract.
If the user edited it, it is protected content: describe the proposed change, wait for approval, edit, then add a row to ## Decisions.
If it is LLM-drafted and unapproved, edit directly.
next-session executes one task per fresh session against an item created here.
In a paclet-dev repo, an item that changes paclet code is developed on a work/<item> branch in a gitignored <Paclet>--<item>/ worktree and lands as a PR on that paclet's repo (the dev repo stays on main) — name the target paclet in the Spec.update-wiki records durable knowledge in Wiki/ — this skill does not touch the Wiki; it manages execution state only.revise protocol governs every Spec and task-list interaction.lean creates a Type: formalization item here.npx claudepluginhub wolframinstitute/claudepluginmarketplace --plugin computational-researchGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.