Create Project Skills

Create Project Skills

Generates one skill per detected convention area in the project's skill directory so future Claude or Codex sessions auto-load them when working in the repo.

Task Tracking

At the start, use update_plan to track each phase, restating any remaining steps of a parent workflow alongside them:

1. Survey codebase
2. Extract patterns in parallel
3. Evaluate patterns
4. Propose skill list
5. Run $create-skill skill

Step 1: Survey Codebase

If $ARGUMENTS specifies paths, scope the scan to those paths; otherwise scan the whole repository.

Build the extraction context:

1. Detect primary languages and frameworks from manifest files (package.json, Cargo.toml, pyproject.toml, go.mod, Package.swift, pom.xml, Gemfile, and others appropriate to the stack).
2. Map the top-level source directory structure and note test directory conventions.
3. Read the project's instruction files (at each level AGENTS.override.md when one is present, otherwise AGENTS.md, including nested ones) and any .cursor/rules or .cursorrules. Note the conventions already documented there. The generated skills must not duplicate them.
4. Determine the target skill directory:
   • Check candidate paths .agents/skills/, .claude/skills/, and a top-level skills/ directory (match case-insensitively so Skills/ or similar non-standard casing is detected too). Resolve symlinks so co-linked paths are treated as one logical location.
   • Use request_user_input to confirm where generated skills should live. Offer up to 3 options: the most likely target directory first, the next-most-likely if there is one, and a free-form path option. Note any symlink alias in the option description. If no Codex skill directory is detected, default the first option to ~/.agents/skills. The user can specify a custom path such as a project-specific directory via the free-form option.
5. In the chosen target directory, list existing skills. For each, record the skill name, the description from SKILL.md frontmatter, and the first ## section heading from the body. These signals feed rename-conflict detection in Step 3.

Output a short text summary of detected stack, top-level layout, chosen target directory, and existing skills before moving on.

When that summary shows no source code to extract conventions from, stop here rather than dispatching Step 2. Executable code in any language qualifies, including scripts no manifest declares, so judge from the directory map rather than the detected stack. Documentation, instruction files, and configuration alone do not: extraction run over prose returns that prose's assertions as observed conventions, and Step 3 scores them with no code sites to test them against.

State that as text first — what the survey found, and that conventions extracted from it would have nothing to verify against. Then use request_user_input to offer:

• Write the skills from what we know (Recommended) — build skills from what this session established, rather than from conventions read out of the repo
• Generate nothing yet — leave skills until the repo has code to have conventions about
• Extract anyway — generate skills from the documentation and configuration that are there

On the first option, run the $create-skill skill directly on that knowledge and skip the remaining steps. On either of the first two, call update_plan with the extraction phases removed so they no longer read as pending work.