sbtd-task

• SKILL.mdcore · 9,678 bytes
• SKILL.mdcore · 9,678 bytes
• SKILL.mdcore · 9,678 bytes
• references/handoff.mddoc · 8,044 bytes
• references/methods.mddoc · 7,261 bytes
• references/presentation.mddoc · 5,810 bytes
• references/state.mddoc · 14,665 bytes
• references/strict.mddoc · 6,269 bytes
• references/task-data.schema.jsonasset · 5,246 bytes
• references/tooling.mddoc · 10,562 bytes

# SBTD Task

Use host-native tools to carry out the user's task. This Skill supplies task rules, not a scheduler, daemon, hook system, or new CLI. Project rules and explicit delivery requirements remain binding. Do not invent commands or claim unavailable helpers ran.

## Route before work

1. Identify the task, authorized project root, branch, and read-only constraints using only necessary reads. An existing task's branch mismatch pauses business and metadata writes: offer its correct worktree, explicitly authorized rebinding, or read-only inspection. "Continue" or choosing a mode does not authorize rebinding.
2. Mode precedence: the user's current explicit choice; otherwise the same task's confirmed/effective record; otherwise `default` for a genuinely new task. A missing, invalid, or ambiguous old record is not a new task: ask which task or mode to use. Do not choose by mtime. A valid task outranks an old handoff.
3. Assess fit without implementing first. If another mode is preferable, explain the current mode, recommendation and reason, and the option to keep the current mode; pause substantive work for the user's decision. Upgrades and downgrades use the same confirmation rule. Never infer a mode from output compression, installed tools, task complexity, or an existing task directory.
4. Honor a refusal, preserve its reason where writing is allowed, and continue in the selected mode. Do not repeatedly recommend the same change without new substantive risk. Same-task continuation preserves its choice; a new unrelated task does not inherit it.
5. For a writable project task with no branch conflict, save the confirmed mode and source promptly using [task state](references/state.md). Do not wait for handoff. If saving fails, keep the current-session choice, report that it was not persisted, and do not promise reliable recovery. `default/lite` may continue unrelated safe work; required `strict` artifacts remain incomplete.
6. Then assess clarification. Read facts the project can answer. If requirements are clear, explain why full `grill-with-docs` was not needed and proceed. For consequential domain ambiguity, explain the unresolved point and ask about grill. Declining a method does not authorize guessing required answers.
7. After every completed full `grill-with-docs` session, invoke `book-ddd-distilled-modeling` and present its separate visible `DDD Boundary Review` in every mode. Follow that Skill's result and correction loop: advance requirement confirmation/design only at `confirmed`; `needs-clarification` returns to clarification and `blocked` stops the dependent step. An unavailable/unreadable reviewer or missing required evidence is blocked for default, lite and strict until the gate can run and pass. Interview-time modeling and informal substitute checks do not satisfy this post-grill gate. This gate has no default/lite substitute; it does not disable fallback for unrelated optional tools.