generate-asset-actions

Classify external assets into priority tiers and generate asset-actions.yaml from ASSETS.yaml.

657|419|Updated Oct 2, 2024
One-click install
npx skills add https://github.com/UKGovernmentBEIS/inspect_evals --skill generate-asset-actions
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: generate-asset-actions
Source: https://github.com/UKGovernmentBEIS/inspect_evals/tree/main/.claude/skills/generate-asset-actions
Command: npx skills add https://github.com/UKGovernmentBEIS/inspect_evals --skill generate-asset-actions

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Maintaining an audit of external evaluation assets requires manually reviewing every entry in ASSETS.yaml, deciding which assets need pinning or migration to controlled storage, and keeping the audit summary numbers consistent. This Skill automates that classification and regenerates the audit files.

Core Features & Use Cases

  • Priority Classification: Assigns each asset in ASSETS.yaml to urgent, high, medium, or low priority tiers based on host reliability and a registry of known-unstable sources.
  • Target Stage Determination: Applies ADR-0007 staging rules to decide whether each asset should be pinned (Stage 1) or moved to controlled storage (Stage 2).
  • Audit File Generation: Regenerates internal/audits/asset-actions.yaml and internal/audits/audit-summary.md with counts verified against the manifest summarizer tool.
  • Use Case: After a dataset upstream breaks or a new eval is added, regenerate the asset audit so every floating reference has a documented action and the summary totals match the manifest.

Quick Start

Regenerate the asset actions and audit summary from ASSETS.yaml, classifying each asset into its priority tier.

Frequently Asked Questions about generate-asset-actions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I regenerate asset-actions.yaml from ASSETS.yaml?

Run the manifest generator if ASSETS.yaml may be stale, then classify each asset by target stage and priority tier, writing entries with eval, source, type, state, target, action, and reason fields into internal/audits/asset-actions.yaml.

How are asset priority tiers determined in the audit?

Floating assets on reliable hosts are urgent, assets matching the known-unstable source registry are high, assets on unreliable hosts like Google Drive or .edu domains are medium, and pinned assets missing checksums are low.

What is the difference between pinned and controlled target stages?

Pinned (Stage 1) applies to assets on reliable version-controlled hosts like GitHub or HuggingFace with no breakage history. Controlled (Stage 2) applies to assets on unreliable hosts such as personal repos, Google Drive, or university servers, per ADR-0007.

How do I verify the generated asset audit is correct?

Check that asset-actions.yaml parses as valid YAML, every floating asset appears in a priority tier, floating plus checksum plus no-action counts equal total external assets, and audit-summary.md numbers match the summariser tool output.

When should the known-unstable sources registry be updated?

Update the registry whenever new upstream instability is discovered, such as removed files, deprecated repositories, broken tasks, or invalid data, recording the source, affected eval, and incident reference.