# Create Tasks

> Turn settled requirements into actionable engineering tasks, or record authorized status changes in an existing task index. Use for task decomposition and saved task maintenance. Not for implementation, unrelated trackers, or conversational progress questions.

- Skill: `rca32/create-tasks` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add rca32/create-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rca32/create-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: rca32 (https://skillmd.com/u/rca32)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rca32/create-tasks

---


# Make the work actionable

Produce the smallest useful set of tasks that another engineer can execute. Choose the detail and decomposition from the actual work, not a required number of tasks, sections, questions, or file reads.

## Author tasks

Use the brief, PRD, conversation, and relevant repository evidence to identify the outcome, dependencies, implementation anchors, and acceptance checks. Reuse existing investigation and decisions. Inspect uncertain interfaces or callers where they could change the plan; do not repeat a whole-repository survey.

Resolve routine choices from established conventions. Ask only about missing decisions that would materially change behavior, scope, security, or compatibility. If the requirements are sufficient, produce the tasks directly; there is no additional task-list approval ceremony. Follow any approval explicitly requested by the user.

Each task should make its outcome, relevant code, dependencies, and verification clear. Include risks, data/API changes, migration details, or QA steps when they affect execution. Group work that belongs together; split by dependency or independent deliverable when that makes execution easier. Do not invent adjacent features or fill irrelevant template sections.

Use the user's language and project terminology. Distinguish accepted requirements from proposals and unresolved assumptions. The result is ready when an implementer can act without rediscovering essential decisions; verbosity is not evidence of readiness.

## Save only requested artifacts

Return tasks in conversation unless saving was requested. Follow the requested path or repository convention, otherwise use `docs/tasks/<feature-slug>/` with an `INDEX.md` and task files where separate detail is useful. Preserve existing files and links; inspect a destination before creating it and do not overwrite another task set.

The index is the single delivery-status record; keep PRDs and task specifications free of duplicate mutable progress. A compact index can contain task details directly. Include task identifiers, outcomes or task links, dependencies, status, and evidence/blockers. Initialize new tasks as `Pending` and the summary as `0 / N done`; writing a task is not implementing it.

## Maintain an authorized index

For status-only maintenance, skip task authoring. Read the affected acceptance criteria, current index/diff, and available evidence, then update only the relevant rows and summary. A question such as “how far along are we?” asks for a conversational answer, not a file write.

Saving the initial task set does not by itself authorize ongoing updates. Once the user or repository authorizes maintaining delivery progress, reuse that permission across checkpoints and resumed turns. Honor later restrictions. During implementation, the orchestrator owns index writes; workers report results. No companion skill needs to be invoked for each update.

Use these meanings, or the consuming repository's equivalent:
- `Pending`: not started.
- `In Progress`: implementation or required verification/review remains.
- `Blocked`: advancement needs a named missing prerequisite or decision.
- `Done`: the item's acceptance criteria and required checks/review are satisfied for its current state.

Keep the summary equal to the Done count. Reopen completed items if a later change invalidates their evidence. A commit or focused pass alone does not prove completion; remaining delivery-wide gates still control overall completion.

At meaningful milestones or handoff, retain completed outcomes, remaining work, relevant verification, and next action. Add a brief checkpoint in the same index when resumption needs it; identify the tested code state only as precisely as needed to judge evidence reuse. Preserve existing columns, task specifications, and unrelated edits.

Re-read immediately before updating and check the result afterward. Preserve independent row changes; do not overwrite an ambiguous same-row change. Repair a partial update safely or report the index as unsynchronized, while continuing independent authorized work.

This skill does not implement code or mutate external trackers. Artifact/status authority is separate from commit or publication authority.