Agent Skill Stack
Find, evaluate, and assemble the smallest compatible set of AI Agent Skills for an...
Install
npx skills add github/awesome-copilot --skill agent-skill-stack -g -a claude-code -y- Repository
- github/awesome-copilot40.7k
- Category
- AI and agents
- Updated
- 6d ago
- License
- MIT
- Context cost
- Mediumabout 2,400 tokens
- Runs scripts
- Yes, review before use
What it does
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 an Agent Skill Stack
Build the smallest useful stack for the user's actual outcome. Never force a domain example or a fixed lifecycle onto a different request.
1. Choose the user-facing depth
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:
- what the user is trying to accomplish;
- the steps in everyday language;
- which capabilities are already available;
- which Skills are recommended, optional, overlapping, or unsuitable;
- how widely each candidate is used;
- whether it passed an installation safety check and a safe trial;
- what account access or external actions it may require.
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.
2. Derive the workflow dynamically
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.
