agentleFS
gocronx-teamgocronx-team/gocron/.agents/skills/dependency-update/SKILL.md

dependency-update

Skill808 starsChanged 3 months agoMITView on GitHub

Review, apply, verify, or merge gocron dependency updates from Dependabot or manual requests. Use for Go modules, root/admin/docs pnpm packages, GitHub Actions, Docker base images, security advisories, lockfile conflicts, or dependency update pull requests.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 3

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Treat major updates, Go/toolchain changes, framework upgrades, database drivers, schedulers, RPC libraries, auth/crypto packages, and …

    line 22
  2. Distinctive:

    Never edit a lockfile by hand.

    line 26
  3. Distinctive:

    Use the narrowest ecosystem command that updates the requested package and its required peers.

    line 32
  4. Very specific:

    Run the relevant package tests even if the dependency is marked dev-only.

    line 58
  5. Very specific:

    If committing, use one single-line Conventional Commit subject under 100 characters and no Co-Authored-By, for example:

    line 68

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

Update gocron dependencies

Handle one dependency group and ecosystem at a time unless a security fix requires coordinated versions. A request to inspect a PR or alert is read-only; merge, dismiss, commit, and push only when explicitly requested.

Assess before changing

  • Inspect the manifest and lockfile diff, release notes, advisory, dependency graph, and current CI status. Use primary upstream documentation.
  • Classify the update as patch, minor, major, security, development-only, build tooling, GitHub Action, or runtime/container.
  • Determine whether the dependency is direct, transitive, bundled into the frontend, shipped in the image, or used only in tests.
  • For security alerts, record the vulnerable range, fixed version, severity, reachable code path, and whether every affected workspace is updated.
  • Treat major updates, Go/toolchain changes, framework upgrades, database drivers, schedulers, RPC libraries, auth/crypto packages, and container bases as high risk even when the diff is small.

Never edit a lockfile by hand. Use the repository package manager and preserve its existing lockfile format. Do not silence peer dependency failures or add blanket advisory ignores to make a check green.

Apply the smallest update

Use the narrowest ecosystem command that updates the requested package and its required peers. Review the resulting diff for unrelated upgrades, install scripts, new transitive packages, license changes, and unexpected engine or Go version changes. Revert unrelated generated churn without discarding pre-existing user changes.

For a Dependabot PR, prefer checking out or updating its branch rather than reconstructing a different lockfile locally. If the branch is stale, rebase or regenerate only when the user authorized changes to that PR.

Verify by ecosystem

  • Go runtime dependency: run go mod tidy, ensure go.mod and go.sum contain only expected changes, then run affected package tests with -race, go vet ./..., and govulncheck ./... when available.
  • Admin frontend: run pnpm --dir web/gocronx-admin build-only, pnpm --dir web/gocronx-admin exec vue-tsc --noEmit, and pnpm --dir web/gocronx-admin lint.
  • Docs: run pnpm --dir docs docs:build.
  • Root tooling: run the affected commit/lint hook command and verify the admin workspace lockfile was not unintentionally changed.
  • GitHub Action: validate YAML and inspect the referenced action's changelog and immutable tag/SHA policy.
  • Docker/base image: build Dockerfile.gocron and inspect architecture, runtime user, binary/library compatibility, and vulnerability scan results.

Run the relevant package tests even if the dependency is marked dev-only. Invoke $verify before merge for every code or lockfile update.

Decide and report

State the exact old/new versions, why the update is needed, runtime exposure, breaking-change review, manifest/lockfiles changed, audit result, checks run, and remaining risk. Recommend merge only when required checks are green and the diff contains no unexplained dependency churn.

If committing, use one single-line Conventional Commit subject under 100 characters and no Co-Authored-By, for example:

chore(deps): update vue to 3.6.0

Download now (ZIP)

  • Other versions8 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 8

    1. dotnet/aspire★ 6.4ksame name
    2. microsoft/aspire★ 6.4ksame name
    3. microsoft/haste★ 109same name
    4. turntuptechnologies-ai/skills★ 1same name
    5. Abdox-menara/guard-skills★ 0same name
    6. jars-demo/jars-skills★ 0same name
    7. lintangknitto/agent-skills★ 0same name
    8. MrCipherSmith/goodai-base★ 0same 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.

  • Used alongsideProjects with it also use api-design.

    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.
    • MicrosoftSkill

      api-design

      Guide for designing and documenting RESTful APIs. Use when asked to design an API, create endpoints, or document an API.

      Also in 3 projects that use this

  • In this repository9 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.

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.