agentleFS
MicrosoftKnown publishermicrosoft/skills-for-copilot-studio/skills/create-eval/SKILL.md

create-eval

Skill486 starsChanged 8 months agoMITView on GitHub

Create plugin development eval scenarios (JSON files with natural prompts and deterministic checks for testing plugin skills). NOT for Copilot Studio in-product evaluation — use /copilot-studio:create-eval-set for that.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the scenario needs a richer agent (e.g., existing topics to modify, knowledge sources, actions), note that the fixture would need to be …

    line 53
  2. Very specific:

    Identify the target scenario: If $ARGUMENTS is provided, use it as the scenario name.

    line 57
  3. Distinctive:

    If yes, read them and offer to add more test cases.

    line 69
  4. Distinctive:

    Keep prompts specific enough that checks can be deterministic (mention exact names, values, counts)

    line 169
  5. Very specific:

    Use schema_validate: true for ALL scenarios that produce YAML — it's the most powerful check

    line 170
  6. Distinctive:

    Don't create evals for deprecated skills (chat-with-agent, directline-chat)

    line 172

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Create Scenario Eval

Guide the user through creating eval test cases for a Copilot Studio plugin scenario. Evals test end-to-end scenarios with natural prompts — the request routes through sub-agents (e.g., Author agent) which invoke skills internally.

How the eval system works

The eval harness (evals/evaluate.py) works by:

  1. Copying a fixture agent into a temp workspace
  2. Running claude -p "<prompt>" with a PreToolUse hook that traces skill invocations inside sub-agents
  3. Checking routing (which agents and skills were invoked), output files, and response text against deterministic checks
  4. Producing a JSON results file and HTML report

What can be tested right now

Authoring scenarios that produce YAML files (topics, agents, knowledge sources, etc.) are the best candidates. The harness supports these check types:

CheckWhat it validatesUse for
agent_invokedExpected sub-agent was dispatched (e.g., Author agent)Routing verification
agent_not_invokedUnwanted sub-agents were NOT dispatchedRouting verification
skill_invokedExpected skill was invoked (traced inside sub-agents via hook)Skill routing
skill_not_invokedUnwanted skills were NOT invokedSkill routing
files_createdExpected files were created/modified (glob pattern)All authoring scenarios
schema_validateFull Copilot Studio schema validation (kind, required fields, IDs, Power Fx, scopes)All YAML-producing scenarios
yaml_structureSpecific YAML path has expected value, min array length, or contains stringStructural assertions
content_containsKeywords from prompt appear in output filesDomain relevance
no_placeholdersNo _REPLACE, TODO, or FIXME markers leftTemplate completion
stdout_containsCLI response text contains expected stringsReference/info scenarios
stdout_not_containsCLI response does NOT contain error stringsError absence
exit_codeCLI exited with expected codeAll scenarios
yaml_unchangedSpecific file or YAML path was NOT modifiedPreservation testing

Note: no_placeholders runs automatically when any .mcs.yml file is changed, unless explicitly set to false.

Not yet testable: Integration scenarios that call external APIs (chat-directline, manage-agent) — these need script mocking which isn't implemented yet.

Available fixtures

Fixtures are pre-built agent directories in evals/fixtures/:

  • basic-agent — Minimal agent with GenerativeActionsEnabled: false, one Greeting topic. Use for most authoring evals.
  • agent-with-mcp-action — Same as basic-agent plus two MCP action files. Use for action-editing evals.
  • empty-workspace — No agent files. Use for negative-path testing.

If the scenario needs a richer agent (e.g., existing topics to modify, knowledge sources, actions), note that the fixture would need to be created first.

Instructions

  1. Identify the target scenario. If $ARGUMENTS is provided, use it as the scenario name. Otherwise ask the user what scenario they want to test (e.g., "topic creation", "agent settings", "knowledge sources").
  2. Read relevant skill SKILL.md files to understand what the scenario covers:
    Glob: skills/*/SKILL.md
    Understand: What skills are involved? What YAML kinds? What files get created/modified?
  3. Check if evals already exist:
    Glob: evals/scenarios/<scenario-name>.json
    If yes, read them and offer to add more test cases. Note the highest existing eval ID.
  4. Guide the user through creating test cases. For each eval, gather:

    • name: Short descriptive title (e.g., "IT support topic with OnRecognizedIntent trigger")
    • prompt: A natural language prompt — what a real user would say. Do NOT prefix with "Use the X skill to...".
    • fixture: Which fixture agent to use (default: basic-agent)
    • checks: What to validate about the routing and output
  5. Help the user define checks. Based on the scenario type:

    For topic-creation scenarios:

    {
      "agent_invoked": "copilot-studio:Copilot Studio Author",
      "skill_invoked": "copilot-studio:new-topic",
      "files_created": [{"pattern": "topics/*.topic.mcs.yml", "min_count": 1}],
      "schema_validate": true,
      "yaml_structure": [
        {"path": "kind", "equals": "AdaptiveDialog"},
        {"path": "beginDialog.kind", "equals": "<trigger-type>"}
      ],
      "content_contains": ["<domain keywords>"],
      "no_placeholders": true
    }

    For agent-settings scenarios:

    {
      "agent_invoked": "copilot-studio:Copilot Studio Author",
      "skill_invoked": "copilot-studio:edit-agent",
      "files_created": [{"pattern": "agent.mcs.yml", "min_count": 1}],
      "schema_validate": true,
      "yaml_structure": [
        {"path": "kind", "equals": "GptComponentMetadata"}
      ],
      "content_contains": ["<expected content>"],
      "no_placeholders": true
    }

    For knowledge-source scenarios:

    {
      "agent_invoked": "copilot-studio:Copilot Studio Author",
      "skill_invoked": "copilot-studio:add-knowledge",
      "files_created": [{"pattern": "knowledge/*.knowledge.mcs.yml", "min_count": 1}],
      "schema_validate": true,
      "no_placeholders": true
    }

    For reference/query scenarios:

    {
      "stdout_contains": ["<expected content in response>"],
      "exit_code": 0
    }
  6. Recommend at least 3 test cases that cover different possibilities within the scenario. For example, for topic-creation:
    • Different trigger types (OnRecognizedIntent, OnConversationStart, OnUnknownIntent)
    • Different complexity levels (simple message, multi-step with questions, branching)
    • Edge cases (empty workspace refusal)
  7. Write the scenario JSON file:

    Write: evals/scenarios/<scenario-name>.json

    Format:

    {
      "scenario_name": "<scenario-name>",
      "evals": [
        {
          "id": 1,
          "name": "<short descriptive title>",
          "prompt": "<natural language request — what a user would say>",
          "fixture": "basic-agent",
          "mock_scripts": [],
          "checks": { ... }
        }
      ]
    }
  8. Tell the user how to run the evals:

    python3 evals/evaluate.py --scenario <scenario-name> --verbose

    Or for all scenarios: node evals/run.js

    To generate the HTML report: python3 evals/report.py evals/results/<timestamp>/

Important guidelines

  • Prompts must be natural language — write what a real user would say, not "Use the X skill to..."
  • Include agent_invoked and skill_invoked checks to verify correct routing
  • Keep prompts specific enough that checks can be deterministic (mention exact names, values, counts)
  • Use schema_validate: true for ALL scenarios that produce YAML — it's the most powerful check
  • content_contains keywords should come directly from the prompt to verify domain relevance
  • Don't create evals for deprecated skills (chat-with-agent, directline-chat)
  • Eval IDs must be unique integers within a scenario's JSON

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.