Skip to content

Skill Eval v1.1: automated evaluation for skill additions and updates #88

Closed
3 of 3 issues completed
Closed

Description

@Dong1017

Help an agent answer: what did this skill change fix, what did it break, and what remains untested?

This is a bounded delivery plan under the InferRSI roadmap, with three implementation issues. This parent tracks the overall outcome and closes after end-to-end acceptance; it adds no fourth implementation workstream.

Starting point and goal

Skill Eval v1 (#40) is accepted and closed. It provides real-agent execution, prepare/execute separation, deterministic task grading, controlled ordering and revision-bound evidence for a bounded pilot. That pilot did not establish incremental skill benefit.

v1.1 turns that foundation into a reusable, agent-operated workflow for skill PRs. It does not rebuild the runner or create a skill-version platform.

Change Comparison Question
Add a skill Without target skill vs new skill Does it help on the covered tasks, and can it mislead?
Update a skill Old skill vs new skill What improves, regresses or remains unchanged?
flowchart LR
    A[Skill change] --> B[Plan]
    B --> C[Authorize]
    C --> D[Compare]
    D --> E[PR report]
Loading

Planning makes no model calls. Execution needs explicit, revision-bound budget authorization. The report is generated and posted automatically, not manually copied by a maintainer.

Three implementation issues

Order / implementation issue Increment beyond v1 Acceptance
1. Strengthen deterministic grading (#99, completed) Independent expected answers, negative/boundary cases and offline failure-path tests for the existing verifier and execution flow Known bad outputs are rejected; incomplete evidence and execution errors cannot become task passes. Expected answers are not generated by the implementation being tested.
2. Add a configurable comparison command (#100, completed) Replace pilot-specific wiring with small skill/task configuration; support both comparison modes and generated JSON + Markdown reports An addition and an update use the same entry point. Independent cases detect a deliberately degraded candidate; reports distinguish observed fixes, regressions, unchanged results and inconclusive outcomes.
3. Automate PR planning and feedback (#101, completed) Map changed skills/resources to tests, run with authorization, and update a revision-bound PR summary with evidence links Uncovered changes are visible; a new revision invalidates old results; duplicate triggers do not duplicate paid execution; publishing can retry without rerunning evaluation.

1 → 2 delivers a local tool; 3 integrates it into PR work. Detailed code changes and test inventories belong in the implementation issues.

What the report should tell us

Illustrative update report below: invented values, not measured results.

Outcome Example count Review action
Fail → pass 1 Inspect the apparent fix and its evidence
Pass → fail 1 Investigate the observed regression before acceptance
Pass → pass 3 Covered behavior remains correct in these runs
Fail → fail 1 The case still fails; inspect whether the failure changed
Uncovered 1 Add a case or explicitly accept the evidence gap
Execution/grader error 1 Fix the evaluation; do not call this a skill failure or pass

Each result links to its case, outputs and grading evidence. Discovery tests and tests that explicitly provide the skill are reported separately. Model/settings, revisions, coverage and usage accompany the report; timing is an observation, not an automatic performance claim. No single aggregate score hides regressions or missing evidence.

For additions, the same paired outcomes apply to without vs with the new skill. Passing both sides is not proof of added benefit. Any conclusion is bounded by the tested tasks and model configuration.

Keep maintenance small

  • Reuse Git and existing reader revisions. No new skill version fields, version registry or checked-in old/new copies. Run metadata is generated automatically.
  • Maintain tests, not paperwork. Keep the minimal skill/resource-to-task mapping with evaluation configuration. New task families may need new fixtures and correctness rules; unmapped changes are uncovered, not passed.
  • Keep comparisons controlled. Freeze skill snapshots and relevant resources; use the same tasks, grader, model/settings and environment, with fresh sessions and balanced ordering. Show changes to tests/grading explicitly rather than silently changing the exam.
  • Reuse existing tooling. No second model runner, dashboard, generalized resume service or plugin platform. Results and raw outputs are run artifacts with a documented retention window, not routine commits to main.
  • Separate execution from publication. Untrusted PR content must not execute with publication credentials. Report-only PR integration does not create a required efficacy gate.

Authorship admission remains separate. This work does not automatically approve, merge, promote or rewrite skills, and does not add automatic evaluation to local Create/Update operations.

References and actual reuse

Updated 2026-10-23. Code reuse ≠ workflow inspiration ≠ an evaluated alternative. See #40 §9 for the original pinned readsets and limitations. No upstream benchmark score is an acceptance threshold here.

Source Concrete reuse / relevance Status
InferRSI v1 + #94 #109 imports CodexClient, export_bundle, run_trial, summarize, KnowledgeReader/safe_path, artifact helpers, and pilot PROMPT/SCHEMA/observed_tokens; command execution and process cleanup remain on the existing infra path. Actual internal code reuse; inspected imports. #109 was accepted under #100; see the closure evidence above.
Sibling pilot / npu-skill-factory Fresh-session, frozen-verifier, event and cost-reporting methods informed v1. The old fixed no-skill/human/distilled controller was not imported. Workflow adaptation; recorded reuse decision, retained plan. No external evaluation-platform source was copied according to that record.
Anthropic skill-creator Paired comparisons, assertion-level evidence and separate discovery/trigger assessment. Design reference, not imported runner code. Triggering is not task correctness.
SkillsBench paper / code; SkillLearnBench Matched skill/no-skill tasks, artifact verification, and development versus further/held-out instances. Methodology references; their task suites, containers and platforms were not imported.
Harness-aware plugin evals Evaluate the actual agent harness and outputs, not just a model response or tool selection. Workflow reference; no copied adapter or production dataset claimed.
Promptfoo Codex skill comparison Configuration, comparison and report layer considered during design. Discussed, not integrated; no verified integration proof recorded. #109 extends the existing Python path.
pytest / Hypothesis Independent expected outcomes and negative/boundary/property-oriented tests. pytest used; Hypothesis proposed, not adopted in the inspected dependency configuration.
agent-skills-eval @ f10ae2b Declarative cases, deterministic tool assertions, per-assertion evidence; experimental artifact/verifier isolation. Inspected design reference, no integration or copied code. MIT attribution must be preserved if code is reused.

Bounded role of agent-skills-eval

Its stable path also uses with/without A/B. Borrow test authoring and evidence presentation, not another runner:

References do not authorize new dependencies, paid trials or automatic promotion.

Close when

  • All three implementation issues are accepted.
  • One addition and one update complete the agent-operated path from plan to PR report, with explicitly authorized real-agent execution.
  • Offline controls validate the specified grading rules and failure paths; a controlled degradation demonstrates that the end-to-end system can flag a regression, not merely finish execution.
  • Missing coverage, incomplete runs and runner/grader errors are visible and cannot be counted as passes.
  • Reports retain both evaluated revisions and configuration; stale publication and duplicate paid execution are covered by tests.
  • Usage guidance explains how to run, interpret results and add a test without adding skill-version metadata.
  • Closure includes a concise change diagram, evidence links and remaining limitations.

Success means reliable evaluation evidence and less manual coordination—not a guarantee that every skill improves every agent. New commits require renewed execution authorization; acceptance never depends on manufacturing a positive skill effect.

Consolidated acceptance

Completed 2026-10-27: v1.1 acceptance, change diagram, verification receipts and limitations. This supersedes historical readiness statements saying #101/#88 remain open or a usable hosted provider is not yet available. The bounded workflow is accepted; wider task-family coverage, private benchmarks, skill promotion and subject-PR merges are not implied.

Activity

  1. added
    kind:trackingTracking umbrella that follows child work
    area:knowledgeKnowledge line: packs, skill library, knowledge admission
    on Oct 22, 2026
  2. Dong1017 commented on Oct 27, 2026

    @Dong1017
    CollaboratorAuthor

    Skill Eval v1.1 accepted: bounded end-to-end workflow complete

    All three implementation deliveries are accepted: #99 grading, #100 configurable comparisons, and #101 automatic PR integration.

    flowchart LR
        G["Independent grading: #99"] --> C["Configured addition and update: #100"]
        C --> P["Plan and explicit finite authorization: #101"]
        P --> E["Real agent comparison"]
        E --> R["Retained evidence and automatic PR feedback"]
        R --> A["Addition: wrong to correct"]
        R --> U["Update: correct to correct"]
    
    Loading

    Acceptance evidence

    • Real addition: run 40487687090, automatic #159 feedback: fix=1. Retained bytes and receipt hashes were independently inspected as recorded in Skill Eval: automate PR evaluation planning and feedback #101.
    • Real update: run 40499987048, automatic #160 feedback: unchanged_correct=1, with no missing pair or inconclusive outcome. This neutral result satisfies the workflow goal; no improvement is claimed.
    • Controlled degradation: comparison tests deliberately supply a wrong candidate and assert a regression with failed retained grading. PR integration control carries outcome categories through retained packaging and trusted publication; retry makes no new client calls. This is offline pipeline control, not real-model efficacy evidence.
    • Integrity/freshness: exact revisions, full budget/plan approval, duplicate consumed-attempt rejection, stale publication, archive/provenance/forged-grade rejection and credential separation are covered by the delivered tests. Final software CI passed all four full-check/installed-package jobs. fix: bind explicit token-stop headroom for paid pairs #192's narrowly scoped token-headroom fix preserves default limits and monetary controls.
    • Use and extension: comparison guide, maintained mapping and configuration/examples document preparation, interpretation, uncovered cases and 30-day retained evidence. No skill-version registry was introduced.

    Limits retained

    Only one fixed holdout case was exercised per real comparison mode. The mapping currently covers two skills; 70 addition and 65 update snapshot paths are explicitly uncovered. This is not full-library capability coverage, discovery effectiveness, hardware optimization acceptance or automatic skill promotion. Historical incomplete update execution remains recorded and was not counted as a pass. Final update artifact bytes were not independently downloaded in this acceptance pass; trusted publisher/job receipts were verified. Actual provider billing is not asserted; reservations are not invoices. Evidence expiry and new-revision authorization rules remain in force.

    Decision: all seven parent closure criteria are satisfied within the agreed v1.1 scope. Close #88 as completed. Broader task-family/private benchmark coverage is future work, not an added prerequisite or an implied delivered feature. Subject PR merge readiness and #190's retrieval-performance campaign remain separate.

  3. Dong1017 commented on Oct 29, 2026

    @Dong1017
    CollaboratorAuthor

    Skill evaluation references: follow-up reading (2026-10-29)

    This supplements the references above. It does not reopen the accepted v1.1 scope or claim that these projects have been integrated or run in InferRSI.

    1. NVIDIA SkillEvaluator / ACES: closest reference for the evaluation workflow

    • Repository, paper: Evaluating Skills, Not Just Agents.
    • Combines structural checks, semantic analysis and paired live-agent trials with/without a target skill. Live traces and task outcomes expose effects that reviewing SKILL.md alone cannot establish.
    • Concrete reading: live evaluation, custom graders, dataset generation.
    • Useful design reference: bring existing tasks/custom graders, keep runtime evidence, separate skill discovery/use from successful task completion. For an InferRSI update PR, the corresponding experiment is base vs head with other inputs fixed, not merely head vs no skill.
    • Limit: generating tasks/answers from the same skill does not establish an independent oracle. Process metrics and composite Skill Lift must not replace domain correctness/performance evidence. This is not a ready-made GPU/NPU validation suite.

    2. SkillsBench: reference for a separately maintained minimal benchmark

    • Paper, repository, task contribution contract.
    • Reusable idea: a task package owns the task statement, environment, reference solution and executable verification. InferRSI can select/adapt a small relevant subset rather than reproduce a large general-purpose task bank.
    • Keep paper-version results separate from the repository's evolving runner/layout. A public task or reference solution still needs applicability and contamination checks.
    • Proposed separation: benchmark work owns what to test and what counts as success; SkillEval owns controlled comparisons, execution coordination, retained evidence and PR feedback. They share versioned task/environment/grader identifiers. No matching task means uncovered, not passed.

    3. Hardware-oriented task and oracle reuse

    • KernelBench, paper, evaluation implementation: reference computation, generated inputs, correctness and runtime measurement. Borrow these checks for matching kernel tasks, not a text-only judge of claimed speedups.
    • BackendBench, evaluation implementation: existing operator/input workloads can reduce task-authoring work.
    • Limits: unsupported/skipped operators must remain in the coverage denominator; an empty result is not success. Device/backend compatibility, numerical tolerance and timing isolation need validation locally. CUDA support is not evidence of Ascend support.

    4. Historical engineering tasks and measurement validity

    • AGENTbench, paper: historical repository tasks and executable tests are a possible source; base failure/reference-fix success is a useful sanity check, not a guarantee against overfitted tests.
    • SWE-Perf task collection, cross-machine validity audit: reuse real optimization tasks, but revalidate the performance oracle on the actual measurement environment.
    • Downstream utility of agent skills: useful caution that skill utility depends on task, model and harness. Report that configuration rather than assigning a universal skill score.

    Relationship to current proposals

    Reuse status: literature/source inspection only. No external dependency adoption, model execution, hardware experiment, new acceptance gate or upstream benchmark-score threshold is implied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:knowledgeKnowledge line: packs, skill library, knowledge admissionkind:trackingTracking umbrella that follows child work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions