t1k-cocos-rushtank-task-management

Task Management Framework (Tool-Agnostic)

This is the neutral policy (interface). It is the single source of truth for HOW tasks are managed, independent of WHICH tool stores them. The active tool is declared in .claude/task-config.json; tool-specific mechanics live in that provider’s adapter rule(s). Follows rules/library-third-party-decoupling.md (interface + provider from day one).

Model — neutral operation vocabulary

All task work is expressed through these tool-agnostic operations. Adapters translate each one into concrete tool calls; policy and the operator agent never name a specific tool.

list · ready · fetch · create · update · transition (status) · depend · remember · comment

1. Identity & Naming

SSOT: rules/t1k-cocos-rushtank-task-conventions.md — the full, tool-neutral convention: naming format [ACTION-DOMAIN] Short name, action set, domain inference, description template, effort/scheduling, subtask tree + ≤8h ceiling, tag prohibition, linked-spec handling.

Do not restate any of it here or in a provider adapter — cite the conventions file. Effort/due reach the tool via the active provider’s create operation ($EFFORT / $DUE).

2. Lifecycle (neutral state machine)

Neutral states are the SSOT; each tool maps them to its own status names via statusMap in config.

backlog → doing → review → qa → done
                 (blocked — orthogonal: entered from any active state
                            while a dependency or required input is missing)

Reason about state in neutral terms; resolve the tool’s real status name only at the provider boundary.

Reverse mapping (reading). statusMap is forward (neutral → tool); statusReadMap declares read-side aliases for any tool status statusMap does not produce (e.g. “reopened” → doing). Never surface a raw tool status in output — always resolve to a neutral state.

3. Dependency model

Relations between tasks: blocks · depends_on · relates.

A task is blocked when it has an unresolved depends_on (or is target of an incomplete blocks). The dependency graph drives the ready-query (§4) and execution ordering.

4. Ready-query

Ready = a task in backlog or doing AND not blocked (no open dependency). The ready set answers “what can be started right now”. It is derived from list + fetch — there is no separate ready tool call; the definition of “not blocked” is fixed here.

5. Memory / progress-log

Durable progress, decisions, and context are recorded on the task — persistent memory that survives across sessions and is visible to the whole team, via the provider’s comment operation. Prefer append (history) over overwrite.

6. Fetch-completeness

Always fetch a task’s full detail before reasoning or reporting: full description, any linked spec / related file, and the parent chain. Never conclude “no spec / no linked doc” from a child task alone — check its parent (and grandparent). The concrete include flags live in providers.<active>.operations.fetch.args; the spec-link field in providers.<active>.fields.specLink; tool quirks in the optional quirksRef document.

7. Scope-lock

Operate only within the configured scope (providers.<active>.scope) — the designated backlog/list. Never run a tool-wide / workspace-wide search for task discovery.

8. Guarded-write

Reads run freely. Every mutating operation (create / update / transition / comment / time-log / delete) MUST be confirmed with the user first. The operator agent bounces each mutation back to the main agent, which confirms via AskUserQuestion.

9. Tool precedence

Every task operation on this project’s backlog MUST go through this framework — the t1k-cocos-rushtank-task-framework skill and its operator agent. This is what guarantees the convention (§1), scope-lock (§7), and guarded-write (§8).

A kit-shipped generic MCP wrapper skill for the storage tool (names/keywords = the tool’s own) is for work outside the backlog only: docs, chat, time-tracking, workspace admin. Never use it to list/create/update backlog tasks — it bypasses guarded-write and the naming convention. Do not edit those skills to “fix” the keyword overlap — they are kit-owned and may be protected.

Config & adapters

Everything provider-specific lives in .claude/task-config.json: toolPrefix · scope · statusMap · statusReadMap · operations (list/fetch/create/transition/comment → tool name + arg template) · fields · optional quirksRef.
Optional affordances (opt-in; absent ⇒ unchanged baseline) — keys + effect: docs/cocos-rushtank-task-management.md § “Optional affordances”.
Arg templates use a fixed placeholder vocabulary — $SCOPE $ID $NAME $DESC $STATUS $STATUSES $BODY $EFFORT $DUE $PARENT. Empty ⇒ key omitted from the payload; non-$ values pass through verbatim.
Tool quirks (judgment that cannot be data) live in the doc named by quirksRef; no quirks ⇒ no file.
To switch tools: add a provider block, set activeProvider. That is the ONLY edit — do NOT touch this policy, the conventions file, the skill, or the operator agent.

Operator

The t1k-cocos-rushtank-task-manager agent applies this policy through the active provider block — detail in docs/cocos-rushtank-task-management.md § “Operator agent”.

rules/t1k-cocos-rushtank-task-conventions.md — the naming/effort/subtask convention (§1 in full).
rules/library-third-party-decoupling.md — interface + provider principle this follows.
.claude/task-config.json — the active provider block; quirksRef names the tool-quirks document.