菜单
Create exactly one new task file for one upcoming work item. Use when the user asks to make, add, file, write, or capture a single task or todo. Use task for listing, querying, updating, archiving, linting, or multi task backlog work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Close one completed or parked task. Use when the user asks to finish, mark done, defer, park, drop, or archive a task. Set finished or deferred, move the file to archive, update links, and relint.
Manage the project task backlog as plain markdown files in tasks. Use for broad backlog work including create, list, query, update, triage, implement, audit, finish, defer, archive, lint, split, or repair tasks.
Implement one existing task file end to end. Use when the user asks to build, do, or implement the work described by a task. Edit code and tests, run verification, stamp implemented, and leave audit and finish to sibling skills.
Select and rank eligible live tasks from the project backlog. Use when the user asks what task to work on next, asks Codex to pick or prioritize backlog work, rank open tasks, choose from tasks/, or recommend the next task/action without editing task files.
Create one structured git commit covering the full current working-tree state. Use when the user explicitly asks to commit in the current turn — "commit", "commit this", "commit changes", "make a commit", "write a commit message", "git commit", or an equally direct ask to put the current repo state into git history. Invoke only on that explicit request; a turn that merely finishes other work, saves files, or wraps up without a commit ask leaves committing to the user.
Autonomously drive one task from open or checked to ready through task_check, verifier-approved body repairs, and final mechanical task-lint cleanup. Use when a user asks to auto-fix readiness issues, make a task ready, refresh a stale task against the current codebase, or run an autonomous readiness loop without implementing the task. A task whose premise the code invalidates stops the loop and surfaces deferral as the user's option.
| name | task_create |
| description | Create exactly one new task file for one upcoming work item. Use when the user asks to make, add, file, write, or capture a single task or todo. Use task for listing, querying, updating, archiving, linting, or multi task backlog work. |
| version | 1.1.6 |
| author | Andreas F. Hoffmann |
| license | MIT |
<task_create_skill>
task_create is the focused on-ramp for adding a single item to the project's `tasks/` backlog. Its one job is to turn a single request into one conformant, lint-clean task file with no surrounding workflow. It is a thin, trigger-precise front end over the `task` skill: the `task` skill stays the authority for the file format and the create mechanics, and task_create lets a one-shot "make a task for X" load a narrow surface instead of the whole backlog-management skill.<when_to_activate> Activate when the user wants exactly one task file written:
Route to the task skill instead when the user wants to list, query, update, refine, finish, implement, defer, archive, or lint tasks, or to derive several tasks from a larger document in one pass — those are the broader backlog workflows. Route to task_auto_check when the user wants an existing task repaired until task_check reports ready. Route to task_select when the user wants a recommendation about what backlog item to work on next.
</when_to_activate>
<file_format> — <naming>, <frontmatter> (including the date-stamped created / updated), <markdown_policy>, and the <body> sections.<discover> — locate or scaffold tasks/ through the bundled discover_tasks.sh / init_tasks.sh.<create>'s <prior_art> — the two-tier duplicate / already-done gate run before writing.<create>'s <lossless_conversion> — the source-fidelity contract that fires whenever a task is derived from source material. This single-task on-ramp is the single-task-from-a-source path that contract names, so apply it verbatim from the base skill rather than restating it here, keeping the two in step.<readiness_checklist> — the lens the drafted body is self-checked against before the file is written.<lint> — the bundled lint.py and what each finding means.These assets ship in the same plugin as task_create, so they are present wherever task_create is.
<path_resolution>
The bundled scripts (discover_tasks.sh, init_tasks.sh, lint.py) ship in scripts/ next to the base task skill's SKILL.md, not next to this one. After reading that base SKILL.md (per <authority>), resolve each script's absolute path by combining the directory you loaded it from with scripts/<script-name> and invoke that absolute path — never a bare scripts/..., which resolves against the current working directory (the target project) rather than the skill, and so finds the project's own scripts/ or nothing. If the first invocation reports a missing file, re-resolve the absolute path once before treating the script as failed.
</path_resolution>
task skill's <discover> step to resolve tasks/, scaffolding it when it is missing.<body> sections to the base skill's self-sufficiency bar: the file on its own is enough to implement, with everything actually available at implementation time — the codebase, the project's standing instructions, the user — staying in play. When the context is too thin for that, ask one sharp clarifying question, then proceed.task skill's <prior_art> step: a fast rg scan of tasks/ + tasks/archive/ that escalates to an in-depth project analysis only when the scan hits. When a match shows the work is already an open task, partially covered, already implemented, or already deferred, surface it with evidence and let the user decide how to proceed before writing — never auto-resolve.<scope> from the groupings already present in tasks/, and a compact <name> that is unique across both tasks/ and tasks/archive/. List both directories once to keep the name collision-free.date +%Y-%m-%dT%H:%M:%S once and use its output verbatim for both created and updated.task skill's <readiness_checklist> and resolve every finding derivable from the authoring-time material before writing. When the Ambiguity / under-specification lens finds one genuinely-open decision the material cannot settle, carry it forward as the single labeled "Open decision:" permitted by the base Decide or label rule, so the file written already passes the lens task_check will apply.<tasks>/<scope>_<name>.md with status: open and reported-by resolved via the base skill's <user_name_chain>, then write a body that opens with a single # Title and fills Goal / Context / Approach / Acceptance per the task skill's <body>. When filling ## Context and any cross-references, apply the cross-link discipline and the soft-pointer rule from the task skill's <markdown_policy>, so each link to another task earns its place and each pointer to file content survives edits to its target.task skill's <lint> step (lint.py --quiet) and resolve every blocking finding before reporting the file as created.<update> Applying check findings flow: per-number accept / reject / modify, one update round, one updated bump, and one re-lint. Defer leaves the decision in the file for task_check. When the self-check carried no open-decision residue, say so in one line and finish without prompting. Keep this step opt-in and non-blocking: record the user's choice while keeping the created file available either way.When this one task is derived from source material — a pasted note, a chat turn, a todo.md, a PDF, any pre-existing body of meaning — apply the task skill's <lossless_conversion> contract on your own before reporting done: confirm the single task carries every relevant unit of meaning from that source, propagate source-wide content into it, and leave the source's keep/drop disposition to the user. A single task does not exempt the check — one source can hold more meaning than it captures.
Keep this to one atomic task file. When the request actually carries several independent items, or a single item would run past 300 lines, hand the multi-task split to the task skill rather than expanding the work here. A request that fits the base skill's Scope sizing rule stays eligible for this single-file path even when it touches multiple related parts.
<output_contract> Report the relative path of the one task file created, confirm the linter came back clean, and surface any assumption you made about scope, name, or body so the user can correct it. Report the surfaced open decision, the user's resolve-now or defer choice, and the clean re-lint when a resolve-now fix was applied; when the draft carried no open decision, report that one-line result. When the prior-art gate found a match, report the classification and evidence and reflect the user's decision instead of silently creating a duplicate. </output_contract>
The `task_*` family — each sibling does one job, then points to the next; the base `task` skill is the hub that can do all of it:task_create — write one task file (this skill)task_check — readiness gate before building (read-only)task_auto_check — autonomously repair one task until task_check reports readytask_explain — explain one task at a high level (read-only)task_select — choose and rank the next eligible task/action (read-only)task_implement — do the worktask_audit — verify a believed-done task against the codebase (read-only)task_finish — close out: set status, bump updated, archivetask_fix — audit and repair the whole tasks treeThese ship together as a family; any sibling may be absent if a deployment excluded it. The default manual chain is create → check → select → implement → audit → finish, with task_auto_check as an opt-in readiness repair loop and fix maintaining the tree.
</task_create_skill>