Agent Skills Evaluation Workflow: Evidence Before Installation

Developer teams apply this agent skills evaluation workflow before installing or enabling a candidate skill in Claude Code, Codex, or GitHub Copilot. It produces an evidence-backed adoption decision instead of treating a repository name as a security review.

Workflow Overview

Evaluate one candidate at a time. First record its source and intended installation scope; then capture its trigger, inspect every script and dependency without executing it, run one bounded test in a disposable environment, and finally accept, restrict, or reject it with a rollback note. GitHub documents Agent Skills as folders of instructions, scripts, and resources that load when relevant; that is useful context, but it is not permission to copy locations or permissions between products.

Prompt 1: Inventory and Install Scope

Target: create a traceable candidate record before any installation. Input: repository URL, commit or release reference, target platform, owner, and intended project. Model fit: use a language model only to normalize the inventory; verify the repository and platform documentation manually. Expected output: a one-page scope record. Quality check: the record separates GitHub Copilot paths from any Claude Code or Codex path that has not been verified in that platform’s current documentation.

Candidate skill: [repository and pinned revision]
Target platform: [target platform]
Target scope: [project, personal, or disposable test repository]
Task owner: [owner or team]
Requested capability: [one concrete developer task]

Return an inventory with:
1. SKILL.md or equivalent entry point
2. folders, scripts, bundled resources, and declared dependencies
3. documented installation path for this platform only
4. unknowns that block installation

Do not install, run scripts, fetch dependencies, or infer a path from another platform.

Prompt 2: Trigger and Task Contract

Target: determine when the agent should load the skill and when it must not. Input: the candidate instructions, a representative developer request, expected artifacts, and prohibited tasks. Model fit: a language model can extract a contract from the checked files. Expected output: a trigger matrix with inputs, outputs, boundaries, and human review points. Quality check: every trigger has a falsifiable expected behavior and at least one non-trigger case.

Read [skill entry file] and draft a task contract.

For each trigger, return:
- user request or repository condition that should activate it
- required inputs and expected output files
- allowed tools and actions
- actions that require approval or must never occur
- one near-miss request where it should not activate

Flag vague triggers, hidden assumptions, and instructions that conflict with repository policy. Do not execute any referenced command.

Prompt 3: Permissions, Scripts, and Dependencies

Target: expose the operational surface before it reaches a real repository. Input: all instruction files, scripts, package manifests, lockfiles, and environment-variable references. Model fit: a code-capable model can produce a review checklist, with a human reviewing the actual files. Expected output: a permissions and dependency ledger. Quality check: every file write, network action, package install, secret reference, and non-idempotent command has an owner and a control.

Inspect [skill directory] without running it.

Create a ledger with columns:
component | operation | filesystem scope | network destination | dependency | secret access | external write | risk | required control

Treat shell commands, curl requests, package managers, credential variables, destructive operations, and telemetry as separate review items. Mark “unknown” rather than guessing. Recommend least-privilege constraints and a rollback action for every accepted write.

Prompt 4: Controlled Test Task

Target: test the claimed capability without exposing a production codebase. Input: an approved candidate record, a disposable repository or sandbox, a single visible task, and observable acceptance checks. Model fit: use the target agent only after the previous review is signed off. Expected output: a reproducible test log and output diff. Quality check: the task completes within the approved scope, passes the stated tests, and creates no unexplained network calls or files.

Controlled task: [one documented component in a disposable repository]
Allowed directories: [approved paths]
Allowed commands: [explicit command list]
Network: [off or approved hosts]
Secrets: none

Before acting, state the planned files, commands, and expected test result.
After acting, return changed files, command log, test output, skipped actions, and any deviation. Stop if the task requires a new dependency, credential, network host, or write outside scope.

Prompt 5: Acceptance and Rollback Decision

Target: turn the test evidence into an operational decision. Input: the inventory, trigger contract, permissions ledger, test log, and unresolved findings. Model fit: a language model can consolidate evidence; a designated human accepts the decision. Expected output: accept, accept-with-restrictions, or reject. Quality check: the decision names an owner, allowed scope, review date, and rollback path.

Using the attached evidence, produce an adoption record.

Decision: [accept, restrict, or reject]
Approved platform and path: [verified platform path]
Allowed tasks and directories: [approved scope]
Blocked capabilities: [blocked list]
Dependency and permission controls: [controls]
Test evidence: [test log identifier]
Owner and review date: [owner and date]
Rollback: [removal or revert action]

Reject the candidate if path, trigger, permissions, dependencies, or test behavior remains unverified.

Implementation Steps

1. Use the official documentation for the platform you are evaluating. For GitHub Copilot, the documented project locations are .github/skills, .claude/skills, and .agents/skills; documented personal locations are ~/.copilot/skills and ~/.agents/skills.
2. For Claude Code and Codex, capture the current product-specific path and permission model before copying any files. A folder accepted by one surface is not evidence that another surface will discover or safely run it.
3. Review a candidate from a public repository such as OpenAI Skills, Anthropic Skills, or Vercel Agent Skills at a pinned revision. Read its instructions, scripts, and manifests before considering installation.
4. Run Prompt 4 only in a disposable environment with an explicit task, allowed paths, and no secrets. Record the command and file diff.
5. Store Prompt 5’s decision next to the evaluated revision. Re-evaluate when the skill, platform documentation, dependency graph, or permission needs change.

Workflow Use Cases

• Developer platform teams: approve a small set of repository skills for a regulated monorepo without granting every developer the same execution scope.
• Design-system developers: test a UI handoff skill against a disposable component fixture, then accept it only if the code diff and test output stay within scope.
• Developer enablement leads: compare candidate skills from public collections while keeping each platform’s directory, trigger model, and permissions distinct.

Troubleshooting & Optimization

• The skill never triggers: do not add broad wording blindly; compare the request with the actual trigger contract and platform discovery rules.
• A script wants to install packages: return to Prompt 3, identify the exact package and lockfile change, and approve it separately before the controlled test.
• The test touches unexpected files: reject or restrict the candidate, revert the disposable fixture, and write the observed path into the ledger.
• Docs and repository disagree: treat the product documentation as the installation authority and the repository as a candidate implementation until reconciled.

Skill Adoption FAQ

• Q: How does an agent skills evaluation workflow work before installation?
  A: It records the pinned source, target path, trigger, permissions, dependencies, bounded test result, owner, and rollback action.
• Q: Does a public repository make a skill safe to install?
  A: No. Public visibility provides material to inspect, not an approval decision.
• Q: Can a GitHub Copilot path be reused for Codex or Claude Code?
  A: No. Confirm the current path and permission model for the platform being evaluated.

Run this workflow chain in your next project? Share the output path in the comments.

Explore more? View the Prompt Engineering Guides or Business & Productivity category.

I hope this agent skills evaluation workflow helps you turn repeatable steps into a cleaner production path.

Follow @bigprompt for more AI workflows and prompt systems.

Related Big Prompt Hub pages:

Agent Skills Collection Built Around UI Workflow Playbooks

AI Short Drama Character Consistency Workflow for Multi-Shot Episodes

Educational Infographic Prompt: Encyclopedia-Style Science Pages

Animation Character Sheet Prompt: Production Model-Sheet Format

AI World Cup Anime Video Workflow for Character Sheets and Seedance Scenes

Big Prompt Hub Review

This workflow is useful when it converts an appealing public skill into a bounded, reversible engineering decision. It does not rate repositories by popularity or promise that a skill behaves the same way in Claude Code, Codex, and GitHub Copilot. The value is the review record: it exposes install scope and operational controls before a candidate reaches a production repository.