Loading
Find, evaluate, and assemble the smallest compatible set of AI Agent Skills for an end-to-end natural-language goal. Use when a user wants Skills for a multi-step workflow, asks which Skills fit a pro
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add github/awesome-copilot --skill agent-skill-stack -a cursor -y
Find, evaluate, and assemble the smallest compatible set of AI Agent Skills for an end-to-end natural-language goal. Use when a user wants Skills for a multi-step workflow, asks which Skills fit a project, needs an installed-Skill audit or conflict check, has low Skill recall, wants indirect helpers such as humanizers or compliance checks, or wants a project-specific Skill Stack with controlled installation. Search local Skills, registries, GitHub, and OpenCLI; compare adoption, verified fit, safety, and overlap. Do not use for locating one known or common Skill; use the generic find-skills workflow.
Find, evaluate, and assemble the smallest compatible set of AI Agent Skills for an end-to-end natural-language goal. Use when a user wants Skills for a multi-step workflow, asks which Skills fit a project, needs an installed-Skill audit or conflict check, has low Skill recall, wants indirect helpers such as humanizers or compliance checks, or wants a project-specific Skill Stack with controlled installation. Search local Skills, registries, GitHub, and OpenCLI; compare adoption, verified fit, safety, and overlap. Do not use for locating one known or common Skill; use the generic find-skills workflow.
Build the smallest useful stack for the user's actual outcome. Never force a domain example or a fixed lifecycle onto a different request.
Default to plain-language mode. Assume the user does not need to understand paths, revisions, hashes, manifests, static analysis, or runtime details.
In plain-language mode, show:
Keep source paths, revisions, file fingerprints, raw scores, audit evidence, and dependency details in the internal record. Show them only when the user asks for technical details or when a specific technical fact is necessary for informed consent.
Read references/workflow-model.md. Begin with the final result the user wants, not the domain words in the request.
Ask only questions whose answers materially change the result, access boundary, cost, or stack. Derive the workflow backward from success, then validate it forward from the available starting point.
Do not reuse a previous numbered flow. Do not assume that every request needs research, content creation, publishing, analytics, storage, or automation. Add a step only when the user's outcome requires it.
Stop decomposing when a step has one understandable action, one main result, one access boundary, and one observable success condition. Keep the technical capability cards internal; show the user a short plain-language flow.
Read references/local-index-and-profiles.md.
If a current local Skill index exists, search it before the filesystem or internet. If it is missing or stale, rebuild it from the relevant Skill roots:
python3 scripts/skill_index.py build \
--root ~/.codex/skills \
--root ~/.codex/plugins/cache \
--root .codex/skills \
--root ~/.agents/skills \
--root ~/.hermes/skills \
--output ~/.codex/skill-index.json
The index stores names, summaries, aliases, scope, capability terms, update time, and internal file fingerprints. It never executes a Skill and stores no usage history.
If the current project has .codex/skill-stack.json, treat its active Skills and routing rules as the first-choice stack. Search outside the profile only for an uncovered capability or when the user asks for alternatives. Treat same-name entries from different local roots as a review item; do not silently merge them.
For every necessary step, record internally:
Then consider cross-cutting needs only where relevant: quality/style, accuracy, compliance, privacy, localization, data quality, orchestration, and observability.
Match Skills by input -> operation -> output, not by title similarity. This allows a Humanizer to match a natural-writing requirement even when the user's domain never appears in its name.
Do not force one Skill per step. A Skill may cover several steps; a step may need a tool, MCP, connector, or general agent capability rather than another Skill.
Read references/discovery-ranking.md. Search each uncovered capability through:
Expand Chinese/English aliases, verbs, nouns, outputs, and adjacent terminology. Search titles, descriptions, headings, and full SKILL.md content when possible.
Use multiple sources because no registry is complete:
npx skills find <query> and skills.sh;Run browser-backed OpenCLI searches sequentially. Do not log in, add credentials, or enable a connector without user approval.
Treat every search hit as a candidate, not a recommendation. Identify the canonical repository and exact Skill path. Read the full Skill and every executable file that installation would make reachable.
Reject or quarantine a candidate when:
Rank candidates that pass these gates with the rubric in references/discovery-ranking.md. Real-world adoption and community evidence account for 25% of the score. Preserve unknown values as unknown.
Prefer the smallest stack that meets all required success conditions. Classify candidates as:
Read references/security-installation.md. Check identity, activation, instruction, resource, dependency, data-format, permission, and compliance conflicts.
Resolve overlap by selecting one primary Skill, defining a narrow handoff to helpers, keeping alternatives mutually exclusive, or not installing the redundant candidate.
Prefer project-local Skills and a project Skill Stack Profile for task-specific capabilities. Use global installation only for capabilities that should be available broadly.
Default output:
Use labels such as 已具备, 推荐, 可选, 不建议, 安全检查通过, 安全试跑通过, and 最近确认可用. Do not show a hash or local path in the default response.
Offer 查看技术详情 when useful. The technical view may include canonical source, revision, file fingerprint, exact destination, raw evidence, dependencies, permissions, and rollback details.
When the user wants a reusable artifact, create a shareable recommendation card from structured JSON:
python3 scripts/render_stack_card.py \
--input /path/to/stack-card.json \
--output /path/to/stack-card.svg
Keep the card understandable without technical paths or raw hashes. Include the goal, selected Skills, each role and status, safety boundary, and verification date.
Recommendation does not authorize installation. Follow references/security-installation.md after the user chooses.
Default to staged installation. Allow a one-click batch only when every selected Skill passed the hard gates, has an exact pinned identity, has no unresolved conflict, will not overwrite an existing destination, and the user explicitly approves the batch.
For already downloaded and checked Skill directories, preview first:
python3 scripts/stage_install.py \
--source /path/to/skill-a \
--dest ~/.codex/skills \
--manifest ./skill-stack-lock.json
Repeat with --apply only after approval. Never silently add credentials, accept new permissions, overwrite an installed Skill, or publish/send/delete external data.
After the user selects the stack, offer to create a project profile in dry-run mode:
python3 scripts/project_profile.py \
--project /path/to/project \
--name project-stack \
--skill skill-a \
--skill skill-b
Use --apply only after the user confirms the profile.
After installation or profile changes, run a recall check, not a performance benchmark:
Confirm that the correct primary and supporting Skills are selected and unrelated Skills stay out. Report a simple result such as 3/3 种说法都能正确识别; keep raw prompts and routing details in the technical view.
Do not collect or store user prompt history, hit/miss logs, or routing feedback.