cc-new-feature

New Feature

Process sovereignty statement: This skill is a complete workflow explicitly invoked by the user, and holds full-process control from requirements to implementation. During the execution of this process, it is forbidden to call 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 statement 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 record requirements, log progress, or mark "not started yet / interrupted / continue later" without requesting immediate entry into implementation, prefer cc-task-state。

Do not use for:

• Small-scope bug fixes
• Requirements-only or design-only documents
• One-off code reviews only

Core approach

1. At the start of 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 in the project root directory is executable, and must not skip the create/move attempt just because it "looks like the skeleton already exists"; if the directory is missing, you must first run 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/ in the root directory; when task files whose status is already "completed" are found, move them directly to .codex/tasks/archived/。
3. Then check .codex/tasks/ whether there is already an unfinished task, ignoring archived/during the check; when resumption is needed, prioritize continuing the work rather than reopening the topic repeatedly.
4. When verifying that the current session has write permission for the project's .codex/tasks/ , first judge based on the already-created directory; if mkdir -p .codex/tasks/archived hits a permission boundary, you must prioritize going through 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 forbidden, before attempting initialization of the project root directory, to directly replace the write authorization process with a text prompt.
5. Before starting work, first determine the task status: if the user clearly states "not started yet", "just note it down", or "wait until the current mainline is wrapped up", 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 clarifying questions to fill in boundaries, exceptions, and dependencies.
7. Then produce the implementation scope, key decisions, and step plan; when there is clearly more than one direction, you must confirm first.
8. Once implementation is confirmed to begin, you must update the current main task status to 进行中; do not let a task with an explicit start remain in 待开始。
9. Use templates/task.md to persist task status; you must prioritize writing to the project's .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 if the project directory is still confirmed not writable after initialization is complete 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 completing each step, update the status, modified 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 in-depth requirements exploration is needed, apply the requirement approach
• When technical design is needed, apply the design approach
• If currently only task status, recovery entry point, or interruption point needs to be recorded, apply cc-task-state
• When involving interface additions or adjustments, frontend-backend integration, list pages, pagination, or filter pages, 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 requesting 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, it must first be confirmed whether the project root directory write action was actually executed; even if a skeleton already exists, the creation/move steps must not be skipped
• At any given 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 needs to record interface contract confirmation and temporary compatibility exit conditions
• After completion, explain residual risks and follow-up suggestions

Expand as needed

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