agentleFS
Sign inStart free
Microsoft AzureKnown publisherAzure/AzureLocal-LENS-Workbook/.github/skills/release-validation/SKILL.md

release-validation

Skill22 starsChanged 22 days agoMITView on GitHub

Prepare or review an Azure Local LENS release, version bump, release-readiness check or promotion from development to main. Use for release testing, development-branch JSON friendly-customer previews, validation evidence and release approval guardrails.

3 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. Mesh-LLM/mesh-llm★ 4ksame name
    2. michaelneale/mesh-llm★ 4ksame name
    3. Esonhugh/claude-code★ 65same name

    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.

  • In this repositoryOne other file it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read CONTRIBUTING.md, especially "Release validation and approval", before acting.

    line 10
  2. Distinctive:

    Use the PR template to record sanitized results.

    line 13
  3. Distinctive:

    Follow the guide's editing/versioning workflow.

    line 20
  4. Distinctive:

    Run the existing CI checks.

    line 22
  5. Distinctive:

    If DCR scripts/templates change, follow the guide's separately approved lifecycle plan.

    line 29
  6. Distinctive:

    Keep these evidence categories separate: offline regressions, live query execution, applicable workload/counter coverage, DCR …

    line 33
  7. Distinctive:

    If the candidate changes after sign-off, apply the guide's retest and identical-artifact rules.

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

LENS release validation

Authority and scope

Read CONTRIBUTING.md, especially "Release validation and approval", before acting. It is the maintained source of truth; private session memory and previous release outcomes are not release evidence. Use the PR template to record sanitized results.

Procedure

  1. Identify the candidate version, development branch and commit. Inspect the working tree and changed surfaces; preserve unrelated work. Agree acceptance expectations and any intentional metric, sampling or filtering changes.
  2. Follow the guide's editing/versioning workflow. Edit authoritative sources, synchronize shared parameters when applicable and rebuild the monolithic JSON.
  3. Run the existing CI checks. Report the actual commands, totals and outcomes; inspect proposed public content for private identifiers or credentials. Do not add tooling merely to restate existing checks.
  4. Plan applicable live tests under the guide's environment-confirmation rules. For Capacity/Hyper-V query, discovery or map-transport changes, run both full live cohorts. Do not reuse a stored environment ID as approval or replace full release cohorts with focused fixtures.
  5. If DCR scripts/templates change, follow the guide's separately approved lifecycle plan. Preflight host scope, overlap, agents, inherited locks and cleanup. Read-only approval is not write approval. Never silently remove locks or leave test resources behind; report blocked actions and verify preservation.
  6. Keep these evidence categories separate: offline regressions, live query execution, applicable workload/counter coverage, DCR lifecycle/cleanup, and manual portal/customer validation. Never infer fleet coverage from a successful query, fabricate zeroes for absent data or claim unique shared-workspace attribution.
  7. Require the mandatory friendly-customer preview for every new LENS version. A maintainer must arrange consent through trusted customer relationships and provide the generated JSON from the development branch, identified by version, commit and SHA-256 hash. Follow the guide's manual test scope and record the test date, sanitized outcomes/limitations and maintainer-confirmed result. Automated tests and validation of an older release do not satisfy this gate.
  8. If the candidate changes after sign-off, apply the guide's retest and identical-artifact rules. Missing, unavailable or failed customer confirmation blocks release to main; leave the candidate in development rather than waiving the gate or inventing evidence.
  9. Summarize current passes, failures, skipped checks and blockers in the PR. Obtain explicit authorization before committing, pushing, merging or publishing. Maintainer approval and customer evidence must precede the merge because the existing release workflow can publish a new version from main.

Completion

Report the candidate/artifact tested, checks actually run, customer preview status, unresolved blockers and authorization still needed. A checklist or skill invocation is not proof that a human performed the preview. Keep customer identities, environment values, correspondence and raw telemetry private.

Download now (ZIP)

Does it work?

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

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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