agentleFS
Sign inStart free
Microsoft AzureKnown publisherAzure/odinforazurelocal/.github/skills/release-readiness/SKILL.md

release-readiness

Skill20 starsChanged 31 days agoMITView on GitHub

Complete ODIN release documentation and validation checks before declaring user-visible work complete, preparing a release, or opening the Release-to-main pull request.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 43 edited versions we read keep these.

  • 7

    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:

    Use this shared checklist alongside the relevant Designer, Sizer, and PowerPoint skills.

    line 8
  2. Very specific:

    Update the current entry in CHANGELOG.md.

    line 16
  3. Distinctive:

    If a surface needs no change, explain why in the PR checklist.

    line 21
  4. Very specific:

    Check ODIN_VERSION in js/version.js against all three release surfaces.

    line 23
  5. Distinctive:

    Only bump the version when preparing an application release.

    line 24
  6. Distinctive:

    Run from the repository root:

    line 34
  7. Distinctive:

    Do not commit generated artifacts.

    line 68
  8. Distinctive:

    Check public guidance and fixtures for credentials, personal paths, customer data, private URLs, and real environment identifiers.

    line 78
  9. Distinctive:

    Keep required manual validation explicit.

    line 81

“Common” is measured: kept by at least 6 in 10 of the 43 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

Release Readiness

Use this shared checklist alongside the relevant Designer, Sizer, and PowerPoint skills. It does not replace their scenario matrices.

Release documentation

For every user-visible change, including additions to an already-numbered unreleased version:

  1. Update the current entry in CHANGELOG.md.
  2. Review and update the current README What's New summary and the current in-app entry in js/changelog.js so their feature/fix coverage is accurate. Summaries can be shorter than the detailed changelog; do not require identical wording or duplicate historical entries.
  3. If a surface needs no change, explain why in the PR checklist. An unchanged version number is not a reason to omit newly added features.
  4. Check ODIN_VERSION in js/version.js against all three release surfaces. Only bump the version when preparing an application release.
  5. On a version bump, move the previous README summary to docs/version-history/README.md. Keep only the current release in the README.
  6. Review the rendered What's New dialog, not just its source text.

The release-history guard verifies version/rollover structure, not whether the summaries describe every meaningful change. Content coverage still needs review.

Validation gates

Run from the repository root:

npm run lint:js
npm run lint:html
npm run lint:css
npm run test:runner
node scripts/run-tests.js
npm run test:http
git diff --check

test:http starts an isolated loopback server on an available port and shuts it down afterward. The harness must signal completion of all enabled tests; a non-zero count, a loaded page, or a successful download is not completion. Unhandled browser errors, rejected promises, inconsistent counts, and completion timeouts fail validation.

The file-mode suite preserves offline coverage. HTTP integration checks add coverage; neither replaces real-control end-to-end scenarios.

For changed workflows, run the relevant smoke path and its inverse. Before a release, run both complete Designer and Sizer matrices. Rerun affected scenarios after subsequent changes, including changes to shared CSS or dialog helpers.

Evidence and failures

Record the tested revision/worktree, scenario, expected result, observed result, viewport/theme, and one status: passed, failed, blocked, or not run. Separate focused smoke coverage from complete release coverage. Include test counts, console/page errors, output checks, and unresolved limitations in the PR.

For failures, retain synthetic reproduction inputs and runner diagnostics and screenshots from test-results/ (HTTP artifacts are in test-results/http/). Do not commit generated artifacts. Add a focused automated regression for each UI defect; repeat the exact real-control reproduction after fixing it.

A blocked/manual check is not a pass. In particular, successful PPTX generation or XML checks do not prove that PowerPoint opens without repair or clipping.

Publication and privacy

  • Work on Release; the only release PR is Release to main.
  • Review status before committing and preserve other contributors' work.
  • Check public guidance and fixtures for credentials, personal paths, customer data, private URLs, and real environment identifiers. Use synthetic examples and repository-relative paths.
  • Keep required manual validation explicit. Do not describe the release as fully validated while required checks are failed, blocked, or not run.
  • Push only after the gates pass.
  • Only a human may merge a pull request. AI assistants and automation must never merge PRs, invoke merge commands or APIs, or enable auto-merge. Passing checks, approvals, or a request to prepare/finish a release do not authorize an agent to merge.
  • Agents may prepare commits, push Release, address reviews, record validation evidence, and mark a PR ready when authorized. Stop at the readiness handoff: report outstanding blockers or that the PR is ready for the human author's manual merge. Never treat "ready" as permission to merge.

Download now (ZIP)

  • Other versions44 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 44

    1. dotnet/maui★ 23ksame name
    2. AIEraDev/Clypra★ 3.3ksame name
    3. jordanhubbard/nanolang★ 628same name
    4. petrkindlmann/qa-skills★ 209same name
    5. colasama/MahoShojo-Generator★ 167same name
    6. MRCalderon3D/everything-game-dev-code★ 91same name
    7. jpantsjoha/ai-native-developer-experience★ 12same name
    8. strikersam/autonomous-ai-agency★ 10same name
    9. NotHarshhaa/devops-skills★ 8same name
    10. berntpopp/genefoundry-router★ 6same name

    34 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use dependency-cve-sweep, fleet-standard-adoption and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • berntpoppSkill

      dependency-cve-sweep

      Use when handling Dependabot PRs, CodeQL/Trivy alerts, or doing a routine dependency/CVE sweep for this repo.

      Also in 12 projects that use this

    • berntpoppSkill

      fleet-standard-adoption

      Use when bringing this repo into compliance with a GeneFoundry fleet standard (tool-naming, response-envelope, container-hardening, versioning, MCP transport, or logging) or closing its tracking issue.

      Also in 12 projects that use this

    • IgorGanapolskySkill

      ci-failure-triage

      Triage a CI / PR check failure by READING the failure body before forming any hypothesis. Triggered whenever a required check is red, a PR is BLOCKED, a merge won't land, or you're about to call a failure "transient", "flaky", "stale", or "orphaned". Prevents dismissing a real failure (e.g. real CodeQL security alerts) as noise.

      Also in 13 projects that use this

    • VersoXBTSkill

      code-quality-review

      Perform structured code reviews enforcing quality standards, naming conventions, architecture patterns, and team agreements. Use when the user says 'review this code', 'code review', 'check quality', 'review my PR', 'what's wrong with this', 'improve this code', 'review before merge', 'peer review', or 'audit this'. Also triggers on 'code quality', 'review standards', 'enforce conventions', 'tech debt check', 'lint review', or when user completes a significant code change.

      Also in 12 projects that use this

    • SentrySkill

      security-review

      Finds exploitable application security vulnerabilities in code changes. Use for Warden security scans, appsec review, OWASP-style checks, authentication or authorization bugs, injection, XSS, SSRF, path traversal, secrets, unsafe crypto, webhook verification, open redirects, or sensitive data exposure.

      Also in 16 projects that use this

    • jarosser06Skill

      test-strategy

      Plans pytest test strategies for Drift's 90%+ coverage requirement using coverage analysis, edge case identification, and test suite design. Use when determining what tests to write, analyzing coverage gaps, or planning test strategies.

      Also in 3 projects that use this

    • +2 more from berntpopp
  • In this repository4 other files it gives its agents.

Does it work?

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

Reviews can't be read right now.

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.

Check your setup, free