Setup Project Skills

Set up project skills

Use this when starting a repository or revisiting its skill preset. The skill map routes to relevant fields; read only fields that match the repository. It is a starting index, not a technology or provider allowlist: include any stack used by the project, whether or not it already has a map entry.

1. Inspect all parts of the repository: applications, libraries, services, data pipelines, native targets, infrastructure, and build/test tooling. Identify their stacks, versions, recurring work, existing project and global skills, AGENTS.md, and working agreements. A matching technology alone does not justify adding a skill.
2. Build the candidate pool by source before shortlisting. When one skill from a source looks relevant, run npx skills@latest add <source> --list once and inspect every sibling name and description in that source that falls within the repository's relevant fields. Do not treat a multi-skill repository as a single provider entry or stop at the first search result. Search beyond mapped providers whenever a relevant stack or recurring task is missing or existing candidates fit poorly. Check the technology maintainer's repositories, ecosystem specialists, and broad collections; use npx skills@latest find <technology or task> and primary-source search to discover sources, then enumerate each discovered source in the same way. Inspect actual skill paths and exclude test fixtures and contributor-only material. For version-specific skills hidden by root discovery or sharing a name, use the exact GitHub subtree URL and verify its --list output.
3. Compare overlapping candidates across all enumerated sources. Read the full SKILL.md and the referenced material needed to judge finalists. Judge the actual content, not official status or popularity. Prefer accurate version handling, focused activation, progressive references, actionable verification, and minimal external prerequisites; use maintainer or ecosystem-specialist provenance as supporting evidence when content quality is comparable. Reject or narrow candidates with duplicated scope, stale version assumptions, blanket rules, unsafe commands, forced unrelated workflows, shallow content, or vendor recommendations unrelated to the target project. Keep multiple skills only when their responsibilities are distinct and state that distinction in the proposal. Recommending none is valid.
4. Before changing the target project, present a concrete proposal: each proposed skill's exact name and source, why the project's recurring work needs it, and the files or configuration setup will change. Keep the proposal focused on proposed additions and their project fit; include comparisons with alternative candidates only if the user asks. Ask the user to approve those specific additions, unless they already explicitly approved them in this session. Wait for approval before writing; a general interest in a technology does not approve an unreviewed skill or a larger install set.
5. After approval, install only the approved additions using the method in their field reference. For npx skills sources, run npx skills@latest add <source> --skill <name> --agent codex --yes from the target repository root without --global. For workflow skills from my-workflow-skills, resolve that separate repository's local path or GitHub source; this repository contains the setup skill and its maps. Preserve existing customizations; compare same-named local skills and agent guidance before changing them. If the comparison changes the proposed additions or write scope, seek approval for the revised proposal.
6. Verify that the agent can reach each added skill. Record installed sources and versions in the installer's project record, report what changed, and review local edits before later updates.

This setup does not choose skills for individual Task Graph nodes. Set up project agent roles separately with setup-project-agents.