$npx -y skills add tobihagemann/turbo --skill create-project-skillsScans an existing codebase and generates project-specific skills that capture inferred conventions such as naming, file organization, framework usage, data access, error handling, and testing style. Writes into the project's chosen skill directory (e.g., .claude/skills/, `.agen
| 1 | # Create Project Skills |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## Task Tracking |
| 6 | |
| 7 | At the start, use `TaskCreate` to create a task for each phase: |
| 8 | |
| 9 | 1. Survey codebase |
| 10 | 2. Extract patterns in parallel |
| 11 | 3. Evaluate patterns |
| 12 | 4. Propose skill list |
| 13 | 5. Run `/create-skill` skill |
| 14 | |
| 15 | ## Step 1: Survey Codebase |
| 16 | |
| 17 | If `$ARGUMENTS` specifies paths, scope the scan to those paths; otherwise scan the whole repository. |
| 18 | |
| 19 | Build the extraction context: |
| 20 | |
| 21 | 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). |
| 22 | 2. Map the top-level source directory structure and note test directory conventions. |
| 23 | 3. Read `CLAUDE.md`, `.claude/rules/`, `AGENTS.md`, and any `.cursor/rules` or `.cursorrules`. Note the conventions already documented there. The generated skills must not duplicate them. |
| 24 | 4. Determine the target skill directory: |
| 25 | - Check candidate paths `.claude/skills/` (Claude Code), `.agents/skills/` (Codex), 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. |
| 26 | - Use `AskUserQuestion` to confirm where generated skills should live. List each distinct resolved location as an option, noting any symlink alias in the option description. If `.claude/skills/` is not among the detected locations, include it as a default option. The auto-added "Other" option lets users specify a custom path such as a project-specific directory. |
| 27 | 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. |
| 28 | |
| 29 | Output a short text summary of detected stack, top-level layout, chosen target directory, and existing skills before moving on. |
| 30 | |
| 31 | ## Step 2: Extract Patterns in Parallel |
| 32 | |
| 33 | Read [references/pattern-extractor.md](references/pattern-extractor.md) to see the full taxonomy of pattern categories. Decide which categories apply to the detected stack (e.g., drop "Styling and UI" for a backend service, drop "State management" for a static-analysis tool). |
| 34 | |
| 35 | Use the Agent tool to launch all extraction agents below in a single assistant message so they run concurrently. Run them in the foreground so all their results return in this turn. Each Agent call uses `model: "opus"`. Launch one Agent per applicable category and state the total count explicitly when emitting the calls. Each agent's prompt must: |
| 36 | |
| 37 | - Name its assigned category |
| 38 | - Include the stack summary and directory map from Step 1 |
| 39 | - Include the list of conventions already documented in `CLAUDE.md` and `.claude/rules/` so duplicates are skipped |
| 40 | - Instruct the agent to read [references/pattern-extractor.md](references/pattern-extractor.md) as its role brief and return findings in the format defined at the end of that file |
| 41 | |
| 42 | ## Step 3: Evaluate Patterns |
| 43 | |
| 44 | Aggregate findings from all agents. For each finding, score three axes: |
| 45 | |
| 46 | - **Consistency**: what share of eligible sites follow the pattern? Drop findings below 30%. Flag findings between 30–70% as "mixed" for Step 4 review. |
| 47 | - **Intentionality**: does the pattern appear across multiple subsystems and recent commits, or is it isolated? Drop findings confined to a single legacy module unless docs or lint config explicitly mark them as the desired convention. |
| 48 | - **Modernity**: does the pattern align with current best practices for the stack? Flag patterns that contradict current idioms (e.g., pre-hooks class components in a React codebase also using hooks elsewhere) as "legacy" for Step 4 review. |
| 49 | |
| 50 | Group the surviving findings by topic into candidate skills. Each candidate typically covers one category, but related categories may merge if the patterns are tightly coupled. Split a candidate into two skills if its patterns cover clearly distinct sub-topics. |
| 51 | |
| 52 | For each candidate skill, produce: |
| 53 | |
| 54 | - A proposed `name` (kebab-case, narrow to the topic, e.g., `swift-naming`, `react-state`, `api-clients`) |
| 55 | - A one-line description with trigger phrases (e.g., "Use when writing or reviewing <topic>...") |
| 56 | - 3–8 concrete convention statements with evidence citation |