t1k:cocos:rushtank:task-framework

Field	Value
Module	`rushtank`
Version	`1.19.1`
Effort	`medium`
Tools	—

Keywords: backlog, create task, progress log, ready, task, task board, task management, task status, tasks, update task

How to invoke

/t1k:cocos:rushtank:task-framework
[operation or task reference]

Task Framework

User-facing entry to the tool-agnostic task-management framework. Applies the neutral policy in .claude/rules/t1k-cocos-rushtank-task-management.md through whichever provider is configured in .claude/task-config.json, by delegating to the t1k-cocos-rushtank-task-manager agent (isolated context, compact digests).

Setup (first use in a project)

task-config.json is not shipped to .claude/ — it holds per-project values (which list, which provider) and would clobber a consumer’s own config on every module update. Copy the template once:

cp .claude/skills/t1k-cocos-rushtank-task-framework/references/task-config.template.json \
   .claude/task-config.json

Then edit two fields in your active provider’s block: providers.<active>.scope.idEnv (name of the env var holding the target backlog id — a list, project, or board id depending on the tool) and statusMap (neutral state → your workspace’s real status names). Export the env var in your shell profile / local .env — never commit it. If .claude/task-config.json is missing, the operator agent stops and reports instead of guessing a provider. The template ships a full example provider plus a minimal one showing that a provider with no quirks needs no extra file at all.

When to use

“What can I pick up right now?” → ready-query (unblocked backlog tasks).
“Show the backlog / my open tasks” → list (scope-locked to the configured list).
“Create a task for X” → create (naming [ACTION-DOMAIN], guarded-write).
“Move task Y to review / mark it done” → transition (neutral state → tool status via statusMap).
“Log progress / add a note on task Z” → remember / comment.
“What is task W blocked by?” → dependency reasoning.

When NOT to use

A single read where you already know the exact provider tool → call it directly.
Conceptual questions about the provider product → answer from knowledge, no tool calls.
Non-task work (writing code, docs) → wrong skill.

How it works

Delegate to the t1k-cocos-rushtank-task-manager agent (spawn via the Agent tool, subagent_type: t1k-cocos-rushtank-task-manager).
The agent bootstraps from .claude/task-config.json — the active provider block carries everything: toolPrefix, scope, statusMap, statusReadMap, operations (neutral op → tool + arg template), fields, and an optional quirksRef. It loads those tools and applies the neutral policy.
Guarded-write: read ops (list / ready / fetch) run immediately; every mutating op (create / update / transition / comment) is bounced back and confirmed with the user via AskUserQuestion before it executes.

Neutral operations

list · ready · fetch · create · update · transition · depend · remember · comment — reached through the active provider’s operations map. ready and depend are derived from list + fetch, not separate tool calls. Reason in these terms; never hard-code a provider tool here.

References

Policy (SSOT): .claude/rules/t1k-cocos-rushtank-task-management.md
Write-shape convention (SSOT): .claude/rules/t1k-cocos-rushtank-task-conventions.md
Provider contract (the single switch): .claude/task-config.json
Tool quirks (optional): the document named by providers.<active>.quirksRef
Operator agent: .claude/agents/t1k-cocos-rushtank-task-manager.md

Switching providers

Add a provider block and set activeProvider in .claude/task-config.json. That is the only edit — do NOT touch this skill, the policy, the conventions, or the agent. They are tool-agnostic by design. A provider with no quirks needs no extra file; one with quirks points quirksRef at a prose document.