By name: task-authoring description: "Create or update a single Task artifact in WORK_PATH (goal, scope, constraints, acceptance criteria, risks, open questions). Use when starting work, clarifying requirements, or when no task definition exists yet."
task-authoring
Purpose
Produce a clear, testable task definition without doing technical design or implementation. One iteration should result in exactly one updated/created task file in WORK_PATH.
Inputs (from Fabricator)
- WORK_PATH
- Context Map (constraints + known commands + existing artifacts)
- User intent / goal
Output (default)
- Create or update:
${WORK_PATH}/task.mdRules: - If a task file already exists in WORK_PATH, prefer updating it instead of creating a new one.
- If multiple “task-like” files exist, ask user to pick the canonical one.
Internal loop (keep going until completion)
1) Detect / choose target file
- Look for common candidates in WORK_PATH:
- task.md
- task.md
- intake.md
- issue.md
- If found exactly one strong candidate => use it.
- Else ask user for the exact filename (in WORK_PATH).
2) Ask minimal intake questions (skip anything already answered)
Required:
- What is the problem / user-visible outcome?
- Scope (in) and out-of-scope (out)
- 1–3 acceptance criteria (how to know “done”)
- Constraints (must / must-not)
- Unknowns / open questions
Recommended (if multi-platform):
- Platforms (list target platforms)
- Any public surfaces? (API/schema/persistence/deeplink)
- Risk level: low / medium / high
3) Draft Task content (preview in chat first)
Keep it concise and decidable. Suggested sections:
- Title
- Goal (why)
- Scope / Out of scope
- Constraints (can/can’t)
- Acceptance criteria
- Risks
- Open questions
- References (links to existing artifacts/docs)
Completion criteria
- Acceptance criteria are explicit and testable
- Scope and constraints are unambiguous
- Open questions are listed (even if unanswered)
Return control to Fabricator.