capture-task

Capture the following as a Task in the binder knowledge graph.

$ARGUMENTS

If no input was given above, ask the user what to capture.

Key Convention

Format: {taskType}-{short-slug}, kebab-case. Must be usable as a git branch name. 2-7 words, max 70 chars.

Examples: fix-sync-null-values, feat-export-csv, tweak-sidebar-padding, docs-api-reference

Fields

Captured — taken directly from user input. Only include what the user actually said:

• title (required) — 2-7 words, max 70 chars, no verb prefix
• taskType (required) — fix, feat, tweak, refactor, perf, agent, build, docs, test
• description — 1-2 sentences with enough context
• details — steps to reproduce, useful context, skip obvious background
• priority — p0=Blocker, p1=Urgent, p2=High, p3=Medium (default), p4=Low
• sourceFiles — paths to relevant source files, when the user mentions them

Inferred — derived by the agent. Clearly marked so the user can correct. For acceptanceCriteria, constraints, and outOfScope: only propose when obvious from context. Better empty than hallucinated.

• key — generated from taskType + title slug
• module — which part of the codebase this belongs to
• size — small: few files, no design decisions. medium: several files, 1-2 decisions. large: multiple commits, non-trivial decisions
• priority — if user didn't specify, default p3
• acceptanceCriteria — optional, testable scenarios
• constraints — optional, what must hold or not change
• outOfScope — optional, what this task deliberately does not cover

Run binder schema --types Task for the full Task schema and available field values.

Flow

1. Parse and assemble

Extract fields from user input. Infer what you can. Check for duplicates against Context below.

If a duplicate is found:

• Exact duplicate — tell the user, don't create. Link to the existing task.
• Partial overlap — tell the user. They can merge into the existing task or keep both.
• Related but distinct — note it. If created, link with relatesTo.