new-feature

New Feature

Process sovereignty declaration: This skill is a complete workflow explicitly invoked by the user and holds full-process control from requirements to implementation. During execution of this process, it is prohibited to invoke superpowers:brainstorming、superpowers:writing-plans or any external skill that would take over the design/implementation process. The design document must be written to .codex/tasks/, and must not be written to docs/superpowers/ or any other path. This declaration is based on superpowers' own priority rules: explicit user instructions > superpowers skills.

Use this skill when the user explicitly requests developing a new feature, fully advancing a feature, or mentions new-feature, or resuming an unfinished task.

If the user currently only wants to note down requirements, register progress, or mark "not started yet / interrupted / continue later", and does not request immediately entering implementation, prefer using cc-task-state。

Do not use for:

• Small-scope bug fixes
• Pure requirements documents or pure design documents
• One-off code review only

Core approach

1. When starting a run, you must first, in thecurrent project root directoryensure that .codex/tasks/ and .codex/tasks/archived/ exist; even if the directory already exists, you must first confirm that a write action to the project root directory is executable, and you must not skip the creation/move attempt just because it "looks like the skeleton is already there"; if the directory is missing, you must first execute mkdir -p .codex/tasks/archived to create it before continuing, and do not directly judge "directory does not exist" as "not writable".
2. Then check .codex/tasks/ the root directory, and when task files whose status is already "completed" are found, directly move them to .codex/tasks/archived/。
3. Then check whether .codex/tasks/ already has unfinished tasks, ignoring archived/during the check; when resumption is needed, prefer continuing the work rather than reopening the task.
4. When verifying that the current session has write permission for the project-local .codex/tasks/ , first judge based on the directory that has already been created; if mkdir -p .codex/tasks/archived hits a permission boundary, you must prioritize the platform approval prompt. Only if the project directory is still truly not writable after the directory has been created may you explain the constraint and clarify whether to fall back to ~/.codex/tasks/ to continue persistence; it is prohibited, before attempting project root directory initialization, to directly replace the write authorization process with a text prompt.
5. Before starting work, first determine the task status: if the user explicitly says "not started yet", "just note it down first", or "wait until the current main line is wrapped up before doing it", then only create or update the task file and mark the status as 需求中 or 待开始, and do not mistakenly write it as 进行中。
6. When confirming readiness to enter implementation, then ask 3-5 key clarification questions to fill in boundaries, exceptions, and dependencies.
7. Then produce the implementation scope, key decisions, and step plan; when there is obviously more than one direction, you must confirm first.
8. Once it is confirmed that actual implementation is entered, you must update the current main task status to 进行中; do not let a task explicitly started remain for a long time in 待开始。
9. Use templates/task.md to persist task status; you must preferentially write to the project-local .codex/tasks/. If under the project root directory .codex/tasks/ does not yet exist, first try mkdir -p .codex/tasks/archived; if that write triggers platform approval, you must have the user authorize it before continuing. Only after the project directory is confirmed still not writable after initialization is completed may you fall back to ~/.codex/tasks/. By default, do not treat ~/.codex/tasks/ as the preferred landing point.
10. Implement step by step; after each step is completed, update the status, changed files, and verification results.
11. After completion, do a self-check from a quick review perspective, update the task status to "Completed", then move the task file to the corresponding tasks/archived/。

Collaboration constraints

• When requirements need to be explored in depth, apply the requirement approach
• When technical design is needed, apply the design approach
• If currently only task status, recovery entry, or interruption point needs to be recorded, apply cc-task-state
• When interface additions or adjustments, frontend-backend integration, list pages, pagination, or filter pages are involved, apply the cc-api-contract-safety approach
• When self-reviewing before completion, apply the cc-review priority
• Language and framework details are delegated to the corresponding language skills

Output requirements

• Clearly distinguish requirements clarification, design decisions, implementation steps, and verification results
• If the current information is insufficient to start work safely, ask the key questions first
• If the user is not currently asking to start work, but is only registering or clarifying requirements, the task status should remain at 需求中 or 待开始
• If it has been confirmed to enter implementation, the main task status must be switched to 进行中
• The task file must always remain consistent with the current progress
• If a task directory fallback occurs, it must be clearly stated whether "the project directory is not writable" or "only the directory is missing and has been automatically created"; it is forbidden to directly phrase "the directory does not exist" as "not writable"
• If under the project root directory .codex/tasks/ / .codex/tasks/archived/ does not yet exist, prioritize executing initialization in the project root directory; if the current session does not have write permission for that directory, the platform approval should take over first, rather than directly falling back in text to the user-level directory
• If the current project already has .codex/tasks/ but the task file still cannot be written, first confirm whether the project root directory write action was actually executed; even if a skeleton already exists, the creation/move step must not be skipped
• At any one time, only one main task should be in 进行中; if there are other candidate features, they should remain at 需求中、待开始 or 待恢复
• If there is interface or integration work, the task file must record interface contract confirmation and temporary compatibility exit conditions
• After completion, explain residual risks and follow-up recommendations

Expand as needed

• Recovery strategy:references/resume-policy.md
• Orchestration approach:references/orchestration.md
• Task template:templates/task.md