Sdk scenario generator
Skill jscraik/Agent-Skills/Skills/agent-ops/sdk-scenario-generator
Governed skill foundry and Skills SDK for Codex/AI coding agents: author, validate, evaluate, and sync runtime projections through ask.
npx -y skills add jscraik/Agent-Skills --skill sdk-scenario-generatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create, review, and maintain gold-standard Skills SDK eval scenarios before internal evals, dry Tessl staging, or live private Tessl scoring. Use when creating or updating a skill, writing skill tests, adding eval cases, importing KnowledgeOS or Tessl suggestions, checking scenario drift, or hardening evals that are too easy.
SKILL.md
7.6 KB, as published. Nobody here has run it
SDK Scenario Generator
Create gold-standard Skills SDK scenarios that survive internal checks, OSS lanes, and Tessl quality filtering without leaking the answer.
When To Use
- Create, import, repair, or retire
references/evals.yamlcases for a skill. - Turn KnowledgeOS, Tessl, or plugin-generated scenario drafts into canonical SDK evals.
- Diagnose low lift, baseline wins, Tessl quality-filter rejection, or oss-local/oss-cloud failures.
- Prepare dry Tessl or live private Tessl staging after internal gates pass.
Do not use this skill to make scenarios easier after a failed eval. Fix the skill, task, criteria, scorer, fixture, or runtime owner that the evidence names.
Inputs
- Target skill path, latest
SKILL.md,references/contract.yaml, andreferences/evals.yaml. - Selected
references/evals/*.mdfixture notes or KnowledgeOS capsule evidence only when routed by the task. - Latest internal, oss-local, oss-cloud, dry Tessl, live Tessl, or Plugin Eval receipt when diagnosing quality or readiness.
- Tessl
qualityFilterStatus, leakage, scenario-value, baseline, and with-context evidence when Tessl rejected or down-scored scenarios.
Outputs
- Scenario inventory with keep, rewrite, retire, or add decisions.
- Canonical eval patches or reviewed scenario drafts with
schema_version. - Owner classification for failures: skill, task, criteria, scorer, fixture, runtime, or pipeline guardrail.
- Tessl tile scenario assets when requested:
instructions.json,summary.json,summary_infeasible.json, andscenario-N/{task.md,criteria.json,capability.txt}. - Readiness summary that keeps internal proof, OSS proof, Tessl dry-run, live Tessl, Registry, and publication lanes separate.
Workflow
- Confirm the named gate in
references/sdk-pipeline-setup.md; load only the target skill, contract, eval YAML, selected fixtures, and latest relevant receipt. - Classify each failing case before editing: leakage, low scenario value, weak comparator, vague criteria, missing fixture, baseline tie, baseline win, stale task, hidden dependency, unsupported assertion, or runtime mismatch.
- Treat Tessl rejection as a pipeline defect until SDK scenario-quality also blocks that class. Patch the shared quality gate or generator contract before rerunning live Tessl.
- Feed repeat failures back to the start of the pipeline. Patch the source fixture, scenario adapter, scenario-quality gate, or skill package before
oss-local; do not spendoss-cloudor live Tessl runs rediscovering a shape defect. - Keep task text realistic and agent-facing. Do not include
Required behavior,Failure mode,Return these exact fields, copied criteria, long expected answers, or scoring mechanics in the visible task. - Keep criteria scorer-facing. Put expected behavior, failure modes, and rubric dimensions in acceptance criteria or hidden metadata, not in
promptor exportedtask.md. - For generated fixture scenarios that score a packaged skill, ask the runner to score package instructions and references, not a fresh chat response. Criteria must not expect
raw_response,final.json, or observable response text unless the runner actually creates that artifact. - Keep low-value unrelated negatives in local routing smoke only. Release/Tessl negatives must test realistic safety, authority, evidence, boundary, or should-not-trigger pressure.
- Use concrete fixtures for repo-audit scenarios. If the case asks for file-path evidence, command evidence, or repo state, inline the relevant files in
task.mdor provide a staged fixture artifact. - Import only reviewed cases into canonical eval assets; never copy raw generated scenarios into
references/evals.yaml. - Run package verify, scenario-quality, scorer-quality, and scorer-calibration before oss-local, oss-cloud, Tessl local proof, dry Tessl, or live Tessl.
- Use
oss-localbeforeoss-cloud;fastis smoke only. Treat Tessl as staged confirmation after internal gates and run-budget proof.
Failure Mode
Stop before the next gate when:
- Tessl rejects any scenario for leakage, low value, hidden dependency, or infeasibility while SDK scenario-quality still marks it promotion-ready.
- A task can be answered by copying the prompt, naming the skill, citing a fixture path, or repeating generic quality language.
- A scenario requires hidden files, credentials, process logs, tool traces, or side effects the runner cannot observe.
- A Bucket D regression shows context made the answer worse than baseline.
- Scenario-quality, scorer-quality, scorer-calibration, dry Tessl, or live Tessl evidence is missing for the claimed gate.
When blocked, classify the owner and patch only that surface before rerunning the same gate.
Gotchas
- Execution boundaries matter: internal SDK receipts, OSS runs, Tessl local proof, live Tessl scoring, Registry state, and publication are separate proof lanes.
- Do not make a scenario easier to pass when the named owner is the skill, fixture, runner, scorer, or quality gate.
Execution Boundaries
- Scenario authoring updates canonical eval assets; it does not prove OSS, Tessl, Registry, or publication state.
- Live Tessl work starts only after internal receipts and workspace identity are current, staged, and separated from publication proof.
Validation
./bin/ask skills package verify <skill-path> --json --robot./bin/ask sdk eval scenario-quality <skill-path> --preview --json --robot./bin/ask sdk eval scorer-quality <skill-path> --preview --json --robot./bin/ask sdk eval scorer-calibration <skill-path> --preview --json --robotcodex exec --profile oss-local, thencodex exec --profile oss-cloud, or SDK receipts provingcodex_exec_invoked=trueand the matching profile.codex exec --profile fastonly for quick smoke checks../bin/ask sdk eval tessl-local-proof --skill <skill-path> --workspace <workspace> --execute --json --robot./bin/ask sdk eval tessl-score --view-json <view-json> --skill <skill-path> --preview --json --robot./bin/plugin-eval analyze <skill-path> --format json
Do not run live Tessl until scenario-quality, scorer-quality, scorer-calibration, staged Tessl proof, run-budget proof, and project/workspace identity are current and separated from publication or Registry proof.
Completion evidence is the current gate receipt or command output with explicit pass, fail, or blocked status and the scenario ids affected.
References
references/gold-scenario-contract.mdreferences/eval-improvement-contract.mdreferences/tessl-tile-scenario-contract.mdreferences/tessl-registry-boundaries.mdreferences/sdk-pipeline-setup.mdreferences/knowledgeos-handoff-conversion.mdreferences/source-context.yamlreferences/knowledge-capsule-routing.mdreferences/knowledge-capsule.manifest.yamlreferences/contract.yamlreferences/evals.yaml