scrum-task-create

Files (1)

• SKILL.md

SKILL.md (first lines)

Use the scrum-studio MCP. Reuse the intended project ID; otherwise resolve it with `projects`, clarifying ambiguous matches. Write task content in English. Apply [scrum-rules](../scrum-rules/SKILL.md) before decomposition: register or reuse the entire known authorized TODO set before any implementation/claim; never alternate creating each already-known deliverable with executing it. Explain justified grouping briefly; creation alone does not authorize execution.

- Translate the requested outcome into concrete tasks with concise titles. Put scope/context in description and explicit outcome checks in acceptance_criteria in the same initial write. Avoid speculative work and redundant tiny tasks.
- Call `task_create(project, title, description, acceptance_criteria, priority, checklist, category, dependencies, actor)` as needed. Category is a concise English label (default General, max 80 characters), such as Feature, Bug, Design or Testing. Reuse an appropriate known category. Priority is 1 High, 2 Normal (default), 3 Low. Every new task starts in TODO.
- Use checklist items for steps within one deliverable: `[{"text":"Verify the acceptance criteria","done":false}]`. Use separate tasks for independently trackable deliverables. Limits: 100 items per checklist; 500 characters per item.
- Set known dependencies on creation to save a call; for later edits use `task_update(project, id, dependencies=[...])`. Resolve a known code with `task_get(project,code)`. Use IDs from this project only; no self-dependencies or cycles. Dependencies and checklist fields replace their entire existing list when supplied. See [scrum-blockers](../scrum-blockers/SKILL.md) only for dependency maintenance.
- If a known backlog is available, avoid duplicates using that context. Use task_search(project,query|code|file|status,limit,after) for overlap checks; paginate only as needed. Reserve snapshots for explicit broad audits. After an uncertain create result, inspect the backlog before retrying.
- Return created IDs, titles and priorities compactly. Creation does not imply permission to start implementation or move tasks In Progress.
- Include optional `files` as the minimal known edit plan (relative to the configured workspace_root) to let next_work skip file conflicts and the later claim reserve paths atomically. An empty plan is allowed when the files are not yet known; acquire discovered files before editing.

The server assigns `code` automatically: first three project letters plus a project-local number starting at 1, for example `WEB-1`. Include this code in user-facing summaries. Keep the returned internal numeric `id` for updates/dependencies; the code suffix is not that ID. Always retain the project context because prefixes can repeat.

Apply cached task_sizing from project settings (default Small), using scrum-rules: each task has one independently verifiable outcome. Split broad independent results, preserve justified dependencies and avoid creating one task per trivial file edit or speculative backlog. No repeated settings reads when already cached.

Every initial task_create MUST include a nonempty description and acceptance_criteria (1..100 explicit, verifiable outcome strings), together with title. Never create a title-only placeholder to fill later. A checklist records implementation steps; it is not a substitute for acceptance criteria. Describe scope and exclusions concisely before the write.

Optional scope_size=Small|Large requires a concise scope_reason; Unknown is default. Assess independent outcome/verification, not only file count. A justified Small estimate can allow Light across several files, but never overrides dependencies, blockers, concurrency or policy. Avoid invented estimates solely to get Light.

For a small related set, prefer task_plan(project,actor,items): one atomic call for 1..10 outcomes, without claims. Each item has key/title/description/acceptance_criteria, optional id to refine an unlocked unfinished task while preserving its history/state/evidence, and optional priority/category/files/scope_size/scope_reason. dependencies accepts numeric IDs or batch keys, including forward references. No partial plan commits on validation/cycle failure. Keep independent work unclaimed and selectable by another authorized worker. Apply scrum-rules examples in this same planning turn; no extra model call, worker spawn or per-item ceremony. A backlog-only request still does not authorize execution.

Task model routing: fixed task model (human-only) overrides the human agent-profile model; otherwise automatic model_tier selects economy/standard/advanced. AI may set model_tier with concise model_reason during existing planning or task_update with normal ownership. Auto defaults to standard regardless of scope size. Size is not difficulty: choose economy only for mechanical low-risk work, standard for implementation/debugging/Unity integration, and advanced for demonstrated difficult reasoning. Set the tier and concise reason during existing planning or a necessary task update; never launch a separate selector model. No separate model call makes this decision. Manual model IDs are never replaced automatically. Human task_update(id,actor,model) alone can queue an override during an active claim, applying on the next launch without editing another worker’s code. Managed workers execute only their offered task, close, then exit; the supervisor re-evaluates the next task. For an automatic tier change during work, preserve task continuity and close safely; at most two routing relaunches occur. The desktop chat itself cannot change its own model through this field. No Claude account probe or paid test run is authorized by implementation.

Choose optional verification_level (auto/minimal/targeted/full) and verification_reason (max 500 characters; required for explicit levels) during ordinary task planning/create/update, without a separate model call. Auto adds no default compact AI context. Minimal uses justified inspection or manual checks for low-risk changes; targeted checks affected behavior and regressions; full runs broad regressions for shared contracts, storage or unresolved risk. These record intent, not successful evidence or permission to skip mandatory checks. If automated tests are skipped, record the reason and actual manual/inspection result. Acceptance criteria and required evidence still apply; scripts/verify.py keeps its conservative safe check selection and reuse rules.

From martiin3d/scrumstudio, MIT.

More from martiin3d/scrumstudio