task-copilot

Task Copilot

tc is the execution record. Use it instead of stuffing long plans or implementation logs into chat.

Command rule

Use --json on commands that support it.

Preferred binary:

tc

Fallback:

./.venv-tc/bin/tc

Core loop

1. retrieve the task
2. do the work
3. store the work product
4. verify required delivery and lifecycle criteria through task-bound QA before completing the task

Commands:

tc task get <taskId> --json
tc wp store --task <taskId> --type <type> --title "..." --content "..." --json
tc task update <taskId> --status completed --json

Code-Execution Path

Prefer the importable APIs for batches:

python3 - <<'PY'
from tc.api import create_prd, create_task, transaction
from tc.db.connection import get_db, find_db_path

conn = get_db(find_db_path())
try:
    with transaction(conn):
        prd = create_prd(title="Example", conn=conn)
        task = create_task(prd=prd["id"], title="Example task", conn=conn)
finally:
    conn.close()
print(f"PRD-{prd['id']} TASK-{task['id']}")
PY

Use a separate cc.api block for memory or skill batches. Do not import tc.api and cc.api in the same Python block.

QA Metadata

Implementation tasks that require verification should use metadata like:

{"requiresQa": true, "qaStatus": "pending"}

For current tc 2.0.0 work, register a schemaVersion 2 acceptance contract before implementation with tc task contract <id> --file acceptance.json --json. Include observable criteria and source scopes covering implementation, dependencies and relevant authority. Capture tc task evidence-identity <id> before checks, compare a second capture afterwards, and preserve the exact identity in the same task's test work product with observed results for every criterion.

Use one verdict per result. Metadata alone, an artifact marker alone or stale source evidence cannot support approval. Completion also rejects unfinished dependencies. Historical completed records remain historical; pending work needs a current contract and fresh verification.