project-init

Project Init

Use this skill when the user explicitly requests project-init、cc-project-init, initializing a new repository, generating project-level AGENTS.md, or supplementing basic scaffolding according to the tech stack.

Do not use for:

• Large-scale rewrites on mature projects
• Replacing feature development or bug fixing
• Overwriting existing AGENTS.md、Dockerfile or scripts without confirmation
• Generating dedicated configuration files for Claude/Gemini
• Generating by default README.md such scanning-type project documentation; when README needs to be generated or refreshed, use project-scan

Core approach

1. First read the current repository state to determine whether it is an empty repository, a boilerplate repository, or already has partial scaffolding.
2. Prefer inferring the tech stack from existing files, then ask only for the missing key information: project description, startup method, database migrations, additional conventions, and whether scaffold files are needed.
3. When project-level documentation is needed, use assets/AGENTS.project.md as the starting point to generate the repository root AGENTS.md, with content focused on project-specific conventions and not repeating user-level global rules; the template's AUTO:* block can be used for subsequent project-scan incremental refreshes. If the project contains Java code, the project attribution convention must be followed: documentation and code attribution uniformly use wwj, and when adding Java files or completing file header comments, use @author wwj。
4. By default, also initialize the project-level .codex/ minimal skeleton:.codex/tasks/、.codex/tasks/archived/、.codex/templates/, ensuring that subsequent new-feature can directly persist tasks; if these directories already exist, only fill in missing items and do not overwrite the entire directory. If the project root directory itself does not have write permission, the platform's native approval process must first be triggered; only if it still fails after approval should it be stated that the current session cannot initialize the skeleton in that project.
5. Only when the user explicitly wants to create or supplement additional scaffolding should the corresponding template be selected from assets/ ; do not write all templates into the repository by default.
6. If the target file already exists, first compare the differences and explain the retention/merge strategy to avoid overwriting the entire file.
7. If the user expects generation of README.md, tech stack summary, directory structure, or quick start instructions, clearly state that this is the responsibility of project-scan , and suggest continuing to execute $project-scan。
8. After completion, explain which files were created, which templates were not used, and follow-up recommendations.

Resource selection

• Project-level documentation template:assets/AGENTS.project.md
• Project-level .codex skeleton:assets/codex-skeleton/
• Go/Docker/compose/restart script templates: select from assets/ as needed
• Specific selection rules:references/template-selection.md

Output requirements

• First explain the identified project form and tech stack assumptions
• Only write files to disk that the user has confirmed
• New files should be directly usable by default, but retain the minimum necessary placeholders
• Clearly indicate what content still needs to be supplemented or replaced by the user
• If the user has executed tools/sync-config.sh, it must be clearly stated that the project-level .codex skeleton still needs to be actually written to disk within the target project root directory by project-init or new-feature , and do not treat the user-level ~/.codex/project-template/.codex/ as completed project initialization