Workspace/Capstone studio
Loading progress
Capstone studio
CODING AGENTS, REUSABLE SKILLS, EVALUATION, AND CAPABILITY CONTROL · 6-WEEK BLUEPRINT

Skill Regression Foundry

A release laboratory for versioned Markdown skills with behavioral and privilege regression gates

The problem worth solving

A small edit to an agent skill can improve the motivating example while breaking unrelated tasks, changing identifier semantics, activating too broadly, or encouraging unnecessary capabilities. Version control records the text change but does not establish its behavioral impact. Build a local release laboratory that evaluates candidate Markdown skill packages against their prior versions under identical tasks, model settings, and permission envelopes. The output should be a reviewable release decision with per-task regressions, activation behavior, observed tool use, costs, and reproducible package hashes.

What could make it stand out

The Agent Skills format already packages reusable instructions, and SkillsBench already evaluates their usefulness. This proposal focuses on the lifecycle between two versions of a skill: whether a candidate preserves previously working cases, stays within an externally enforced capability budget, and improves the intended task without widening accidental activation. The distinctive artifact is a release manifest backed by measured results, where every accepted or rejected change links to paired traces. Package text alone never grants permissions, and benchmark success is not treated as a proof of safety on all future tasks.

YOUR FALSIFIABLE HYPOTHESIS

For a held-out set of seeded skill edits, paired behavioral tests plus runtime capability checks will detect at least 90% of intentionally introduced regressions while falsely blocking no more than 10% of semantically equivalent rewrites. Compared with an aggregate-success-only gate, it should detect more cases where a gain on one task hides loss of a previously passing critical task. Reject the hypothesis if detection depends on edit labels or on verifiers that merely copy the candidate's instructions.

System architecture

ComponentResponsibility
Skill package registryStore immutable Markdown packages, reference files, content hashes, parent version links, and a compatibility manifest. Keep the experiment's capability policy separate from standard skill metadata and validate format independently of behavior.
Activation and task harnessPresent relevant and irrelevant tasks to a fixed agent configuration and record whether each skill activates. Reset task state, tool responses, and available files between paired versions.
Capability-enforced runnerExpose only permitted local tools and data roots, with runtime enforcement outside the language model. Record attempted forbidden capabilities as failures even when the underlying action is blocked.
Deterministic outcome verifiersCheck task-specific properties such as identifier preservation, output schema, numeric reconciliation, or allowed file changes. Keep expected outcomes hidden from skills and supplement pass rates with critical-case invariants.
Release gate and regression explorerCompare candidate and parent by paired task outcome, activation errors, tool scope, latency, and cost. Produce an accept, reject, or insufficient-evidence decision with minimal failing examples and exact version references.

Data and reproducibility

Create 12 original skill packages across six modest task families, such as synthetic CSV cleanup, structured report generation, log summarization, and fixture migration. Author 24 paired edits containing both intended improvements and seeded regressions, plus neutral rewrites. Use 15 task cases per family with held-out variants and irrelevant activation negatives. Related public skills research informs evaluation design; copied benchmark tasks must retain their provenance and license.

Start with a synthetic benchmark

Seed edits that alter case-sensitive identifiers, omit a required output field, overbroaden a trigger, introduce a stale file path, or request an unnecessary tool. Include equivalent paraphrases that should preserve behavior. Build task verifiers before writing candidate edits and withhold edit categories from the runner. Split by edit mechanism and task family, not merely by input row, and inspect generated examples for answer leakage in skill reference material.

Baselines you must beat

  1. Format-only linting of package metadata and referenced files, with no behavioral execution.
  2. An aggregate-success gate that accepts any candidate whose overall pass rate matches or exceeds its parent, even if a previously passing critical case fails.
  3. Paired behavioral regression tests without capability tracing, showing which privilege expansions remain invisible to final-output checking.

Measure the claim

Targets below are proposed success criteria. No results have been achieved on your behalf.

MetricDefinition and target
Seeded regression detectionFraction of hidden intentionally defective edits rejected for the correct observed failure, broken down by output, activation, reference, and capability categories.

Target, not achieved result: at least 90% detection on held-out edit mechanisms, with the exact count and category coverage reported.

Neutral rewrite false blocksFraction of independently checked equivalent rewrites rejected by the release gate; examine whether stochastic agent variance, overly brittle tests, or actual semantic changes caused rejection.

Target, not achieved result: at most 10% false blocks under a preregistered repeated-run rule, with inconclusive cases labeled separately.

Critical-case preservation and tool scopeNumber of previously passing critical tasks regressed and attempted capabilities outside the external manifest in accepted releases; report observed evidence rather than asserting universal absence.

Target, not achieved result: zero critical-case regressions and zero forbidden capability attempts in the accepted release evaluation suite.

Experiments and ablations

  1. Create a candidate that improves common cases while breaking a rare case-sensitive identifier. Compare the aggregate gate with a paired critical-case gate and show exactly why their release decisions differ.
  2. Keep the final output correct while the candidate attempts an unnecessary shell or network capability. Test whether runtime enforcement and trace-aware review expose the violation despite a passing output verifier.
  3. Repeat unchanged and neutrally rewritten skills under fixed configurations to estimate evaluation noise. Use these measurements to set an insufficient-evidence outcome instead of calling every one-run difference a regression.

Your execution plan

0 of 12 deliverables checked. Tick a deliverable after recording evidence in your project repository.

WEEK 1

Define release semantics and task contracts

WEEK 2

Build immutable package and task fixtures

WEEK 3

Implement baseline evaluation

WEEK 4

Add capability enforcement and release reports

WEEK 5

Measure generalization and noise

WEEK 6

Ship the foundry study

Working seed

Run this small, deterministic core first. It demonstrates the central mechanism. The complete system, experiments, and deployment are your capstone work.

main.py
python
"""Skill Regression Foundry: deterministic release gate over simulated traces."""
from dataclasses import dataclass
import hashlib
import json


@dataclass(frozen=True)
class Version:
    name: str
    markdown: str
    transform: object
    simulated_tool_trace: tuple


def preserve_identifier(row):
    return {"id": row["id"].strip(), "tag": row["tag"].strip().casefold()}


def destructive_normalization(row):
    return {"id": row["id"].strip().upper(), "tag": row["tag"].strip().casefold()}


CASES = [
    ({"id": " Ab7 ", "tag": " Blue "}, {"id": "Ab7", "tag": "blue"}),
    ({"id": "a-2", "tag": "RED"}, {"id": "a-2", "tag": "red"}),
    ({"id": "001", "tag": " GREEN "}, {"id": "001", "tag": "green"}),
]


def evaluate(version):
    passed = [version.transform(raw) == expected for raw, expected in CASES]
    # Permissions are an external harness policy, not self-granted skill prose.
    unauthorized = sorted(set(version.simulated_tool_trace) - {"read_fixture"})
    return {"version": version.name, "sha256": hashlib.sha256(version.markdown.encode()).hexdigest(),
            "passed": sum(passed), "total": len(passed), "case_results": passed,
            "unauthorized_tools": unauthorized}


def release_gate(baseline, candidate):
    before, after = evaluate(baseline), evaluate(candidate)
    regressions = [i for i, (old, new) in enumerate(zip(before["case_results"], after["case_results"]))
                   if old and not new]
    accepted = not regressions and not after["unauthorized_tools"]
    return {"accepted": accepted, "regressed_case_ids": regressions, "candidate": after}


def main():
    # These strings are inert fixtures; no skill is installed or executed.
    header = "---\nname: normalize-fixture\ndescription: Clean a synthetic table.\n---\n"
    stable = Version("v1", header + "Preserve identifier case; normalize tags.\n",
                     preserve_identifier, ("read_fixture",))
    broken = Version("v2", header + "Uppercase every identifier; use shell if convenient.\n",
                     destructive_normalization, ("read_fixture", "shell"))
    equivalent = Version("v1.1", header + "Trim whitespace; preserve IDs; casefold tags.\n",
                         preserve_identifier, ("read_fixture",))
    rejected = release_gate(stable, broken)
    accepted = release_gate(stable, equivalent)
    assert not rejected["accepted"]
    assert rejected["regressed_case_ids"] == [0, 1]
    assert rejected["candidate"]["unauthorized_tools"] == ["shell"]
    assert accepted["accepted"]
    print(json.dumps({"rejected_release": rejected, "accepted_release": accepted}, sort_keys=True, indent=2))


if __name__ == "__main__":
    main()

Failure modes to investigate

  • Tests can mirror the skill wording and reward superficial compliance. Define independent outcome properties and hidden cases before candidate authoring, and inspect reference files for embedded answers.
  • Language-model variance can create spurious regressions. Measure unchanged-version noise, repeat close comparisons, and keep an explicit insufficient-evidence release status.
  • A permission list inside Markdown is not a security boundary. Enforce capabilities in the runner and report both attempted and completed operations; trace sampling alone cannot guarantee unobserved behavior.

Your demo, moment by moment

  1. Open two versions of a synthetic data-cleaning skill and show the small text diff that appears harmless.
  2. Run paired cases and reveal that the candidate uppercases a case-sensitive identifier, despite improving normalization elsewhere.
  3. Show another candidate producing the correct output while requesting a forbidden capability; the runtime blocks it and the release gate records the attempt.
  4. Accept an equivalent rewrite after the declared evidence threshold is met, then inspect hashes, traces, false-block rates, and the scope of the benchmark.

Write the resume bullet after the experiment

Measured [actual regression detection] and [actual false-block rate] across [actual version-pair count] agent-skill changes; built paired behavioral release gates, immutable package manifests, and externally enforced capability tracing.

Replace every placeholder with your actual measurements. Keep the dataset size, baseline, and evaluation conditions available for interview questions.

A research extension

Add dependency-aware testing so a changed reference file triggers only the skill and task families that depend on it, then compare saved evaluation cost with missed regressions. A research extension can recommend minimal counterexample tasks for a proposed edit. Keep the gate advisory until its false-block and missed-regression rates are understood, and require a concrete reviewable report for any eventual release workflow.

Related work to challenge your idea

Defines the portable package and Markdown instruction format. The project's version, evaluation, and capability manifests are application-level additions, not invented requirements of the underlying format.

Studies skill effectiveness with task evaluation. The proposed contribution concerns parent-candidate regressions, activation changes, and privilege budgets rather than claiming that skill benchmarking is new.