tasks

tasks — the workflow and co-working control center

What this skill does

This is the control center for the team's work. It is an application you operate by talking to Claude in this project (Cowork or the CLI). It reads the configured paths.outputs.tasks folder from ${CLAUDE_PROJECT_DIR}/.strategy-skills/config.json; if that config does not exist, stop and run the setup skill first. Three jobs:

1. Manage the work. A single register of items and actions, with owner, due date, status, and what each is blocked on. Answers "what do I have", "what is due", "what is next", "what does have".
2. Run the work. Each item names the skill that assists it (north-star, brainstorm, pain-point, wwwh, or none). When someone works an item, this skill runs that skill for them, then marks the item done and links the output. It ensures the right skill is executed, not just listed.
3. Co-work with other people. This is how the team works together, not just in parallel. One person asks another to review a document, review a session or decision, give input that is missing, validate a line of thinking, or sign something off. Each request records who asked (requested_by), who must act (owner), what is under review (target), what came back (response and outcome), and the item a returned answer feeds back into (feeds). A request mid-session can park a thread until the answer returns, then fold it in. See "The co-working loop" below.

It needs no GitHub and no other tool. Everyone on the team uses it the same way, by asking Claude. Some team members are not on GitHub, and that is fine.

The pieces

The helper is code and ships in the plugin; the register and people files are data and live in the project. The data folder is the configured paths.outputs.tasks (written <tasks> below), seeded by the setup skill.

• Helper (in the plugin): ${PLUGIN_ROOT}/scripts/tasks.py (list, due, mine, next, add, set, render, remind, gh-create). ${PLUGIN_ROOT} is ${CLAUDE_PLUGIN_ROOT} when set, else ${CLAUDE_PROJECT_DIR}/<paths.pluginRoot>. It locates the data folder from the config automatically; pass --data-dir only to override.
• Register, the source of truth (data): ${CLAUDE_PROJECT_DIR}/<tasks>/register.json.
• People (data): ${CLAUDE_PROJECT_DIR}/<tasks>/people.json (names, optional GitHub handles).
• Operator identity (per-user, outside the project): ~/.claude/strategy-skills/identity.json (honouring CLAUDE_CONFIG_DIR), keyed by project, holding the operator's own people key. It is the one piece that is NOT shared, because the register is — and it lives in the user's home so it survives both git and folder-sync sharing (Dropbox/OneDrive sync the whole folder and ignore .gitignore).
• Human view (generated): ${CLAUDE_PROJECT_DIR}/<tasks>/register.md plus brand-styled register.html.

Run the helper from the project root, e.g. python "${PLUGIN_ROOT}/scripts/tasks.py" next. If .strategy-skills/config.json does not exist, stop and run the setup skill first.

Who is operating (you must know the requester)

The register is shared by the whole team, but who is using it right now is local to this checkout. Know who the operator is before you raise a request on their behalf or answer "what do I have", because the requester is part of the permanent record and must never be guessed. Resolve it at the start of any session that will create requests or answer mine / inbox / awaiting:

1. Run tasks.py whoami. If it returns an identity, use it.
2. If not, work out who the operator is from what is evident — the name or email you already hold for this user — and match it to a key in people.json.
3. If you still cannot confirm it, ask: "This project is shared, so I record work against the right person. Who are you here?" Add them to people.json if new, then persist with tasks.py whoami --set <key>.

Identity is stored per-user, outside the project, in ~/.claude/strategy-skills/identity.json (keyed by project; honours CLAUDE_CONFIG_DIR), never in register.json. The home location matters: a project shared by Dropbox or OneDrive syncs the whole folder and ignores .gitignore, so a project-local file would leak one person's identity to everyone. STRATEGY_TASKS_ME is the per-shell override. A project-local .strategy-skills/identity.local.json is still read for back-compat but is unsafe inside a shared folder, so the helper warns whenever it finds one — if you see that warning, run whoami --set and delete the project copy. With identity set, request defaults --by to the operator, and mine / inbox / awaiting default to them. Do not hardcode a name: a different teammate on a different machine is a different operator.

Item schema

Every item carries the work fields: id, title, detail, owner (a key in people.json; for a request this is the person asked to act), skill (north-star | brainstorm | pain-point | wwwh | empty), created, due (YYYY-MM-DD or null), status (open | in-progress | blocked | done | cancelled), blocked_on, source (where it came from), output (the artefact the skill produced), priority.

A request to another person adds the co-working fields:

• kind — task (a plain work item, the default) or one of the request kinds: review-document, review-session, review-decision, input, validate, approve.
• requested_by — the person asking (a people key). owner is the person asked. This is what makes it co-working, not just an assignment.
• target — what is under review: a document path, a session or decision reference, or an item id. Distinct from output (which is what this item produces).
• response — what the asked person returned: the feedback, the input, or the verdict. Free text or a path.
• outcome — pending until they respond, then answered (for input) or approved | changes-requested | rejected (for the review/validate/approve kinds).
• feeds — the item id a returned answer flows back into (e.g. the brainstorm a piece of input unblocks). Creating the request parks that item as blocked; a positive response unblocks it.

How it is operated (by talking to Claude)

Below, tasks.py is shorthand for python "${PLUGIN_ROOT}/scripts/tasks.py", run from the project root.

• See the work: "what are my tasks" runs tasks.py mine (defaults to the operator; pass a key for someone else). "What is due" runs tasks.py due. "What is next" runs tasks.py next. "What have I been asked to do" runs tasks.py inbox. "What am I waiting on" runs tasks.py awaiting. The bare forms rely on the operator identity being set.
• Add work: when someone describes a task, add it with tasks.py add --title ... --owner ... --skill ... --due .... Ask for the owner and the due date, do not guess them. Tag the skill that will assist it.
• Ask a colleague: when the user wants someone else to review, give input, validate or sign off, raise a request with tasks.py request --kind ... --to ... --by ... --target ... --due .... Record what comes back with tasks.py respond <id> --outcome ... --response .... See "The co-working loop" below.
• Run the next task: take the next actionable item, tell the user which skill it needs, set it in-progress (tasks.py set <id> --status in-progress), then invoke that skill (the Skill tool) with the item's context. When the skill locks its output, set the item done and record the artefact (tasks.py set <id> --status done --output <path>).
• Update: tasks.py set <id> --status ... --due ... --blocked_on ....
• Refresh the view: tasks.py render, then render the brand HTML with the strategy-skills renderer.

The co-working loop (asking other people)

This is the heart of working with the team. The loop is ask → it lands with them → they respond → it returns to you, and the register holds every step so nothing is lost and the rules engine can chase it.

Ask. When the user wants someone else to look at something, give input, validate, or sign off, raise a request. Confirm who is asked, what they are reviewing, and the due date — do not guess them. Who is asking defaults to the operator identity (see "Who is operating" above), so resolve that first; pass --by only to override it. --to and --by are people keys; if a named colleague is not yet in people.json, add them there first (a <key>: {"name": "<Name>"} entry, with an optional github handle) so they read back as a name everywhere. Then:

tasks.py request --kind <kind> --to <asked> --by <asker> --target "<what>" --due <YYYY-MM-DD> [--feeds <id>]

Pick the --kind from the intent:

• review-document — "have Sarah review the pricing doc". --target is the document path.
• review-session / review-decision — "get Sam to review the brainstorm outcome / the wwwh decision". --target names the session or decision.
• input — "I am missing the AWS cost figures, ask Priya". Use this for the I do not have adequate information case. --target is the question.
• validate — "ask Dana to validate my thinking on the managed-service direction". --target is the reasoning under test.
• approve — "this decision needs the lead's sign-off". --target is the decision. See the approval gate below.

If the request unblocks a piece of work you are mid-way through, pass --feeds <that item id>. The helper parks that item as blocked until the answer returns. This is the mechanism behind a mid-session bring-in (e.g. a brainstorm pausing on a colleague's input).

See what is asked of whom.

• tasks.py inbox <key> — requests awaiting that person's response ("what has been asked of me").
• tasks.py awaiting <key> — requests that person raised that are still pending ("what am I waiting on from others").

Respond. When the asked person comes back, record it from the source of truth:

tasks.py respond <id> --outcome <answered | approved | changes-requested | rejected> --response "<what they said, or a path>"

This marks the request done, stores the verdict in outcome, and — if the request had --feeds — unblocks the fed item on a positive outcome (answered/approved) so you can fold the answer in and resume, or leaves it blocked on changes-requested/rejected so it gets revised and re-asked. When the returned content is a fact that flows into a strategy artefact, carry it in attributed and tagged: <their input> [User-asserted: <Name>]. It is their assertion, not yours, and the renderer highlights the attribution.

The approval gate (hard). An approve request is a real gate. Before a decision or artefact that requires sign-off is locked as Trusted or carried into a downstream skill, check:

tasks.py list --kind approve --target "<the decision>" --pending

If that returns anything, the sign-off is still outstanding: do not lock, and do not carry it downstream. Only once the approver has recorded --outcome approved is the gate open. changes-requested and rejected do not open it.

Reminders, and reaching people who are not here

In-project reminders only reach someone who is in the project. To reach a team member when they are not, the mechanism is an external production rules engine (if the team has one), which reads register.json and sends reminders or escalates overdue items. A pending request is exactly what the engine routes: it knows who was asked, by whom, for what, and by when. register.json is structured for exactly this. Wiring it needs the engine's API (endpoints, auth, the fields it expects). Until then, tasks.py remind <owner> shows what is due, tasks.py inbox <owner> shows what they have been asked to do, and GitHub Issues (gh-create, remind --post) is an optional extra for whoever is on GitHub.

Hard rules

• The register is the source of truth. Everything else (GitHub, the rules engine, the rendered view) reads from it.
• Know who is operating. The requester is recorded against every request, so it must be the real person, never a guess. Resolve identity first (whoami); if it is not set or evident, ask, then persist it with whoami --set. Identity is per-user and stored in the home dir, never in the shared register or the project folder, so folder-sync tools cannot leak it.
• Do not invent owners, askers or due dates. Ask. An item with no owner is a wish, not a task. A request with no asker has lost half its point.
• Close the loop. When a skill finishes an item's work, mark the item done and link the output. When a colleague responds to a request, record it with respond so outcome reflects reality and any fed thread unblocks.
• A returned fact is the colleague's assertion. Carry input back in tagged and attributed ([User-asserted: <Name>]), never silently absorbed as your own.
• Respect the approval gate. Never lock a sign-off-required decision, or carry it downstream, while a pending approve request stands against it.
• Every item links to its source and, once done, its output; every request links to its target and, once answered, its response.

Red flags

• Listing tasks but never running the skill that does them. The point is execution.
• Recording a request with only an owner, losing who asked and what they are reviewing. A request is from someone, to someone, about something.
• Proceeding past a gap you have flagged for a colleague's input or validation as if it were already answered.
• Folding a colleague's returned input into a document untagged, as if it were your own finding.
• Locking or carrying forward a decision while its approve request is still pending, changes-requested or rejected.
• Treating GitHub as required. It is optional, and not everyone on the team is on it.
• Inventing a due date or an owner instead of asking.
• Leaving an item open after its skill has locked the output, or a request open after the colleague has responded.