Maintain badges
Agent skill packs under .agents/skills for README and changelog maintenance, Semantic Versioning, and private/public publish-boundary hygiene. MIT.
npx -y skills add eunai/skills --skill maintain-badgesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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
Maintains manually updated static Shields.io badges and their repository rules using authoritative local evidence. Use when checking, adding, adopting, updating, removing, or designing README badges, or when repository changes may affect a managed badge.
SKILL.md
4.2 KB, as published. Nobody here has run it
Maintain Badges
Quick start
Inspect root README.md unless the user or repository instructions name other
documents. Read root AGENTS.md when present. Reconcile only approved, managed
static Shields.io badges against their declared local checks.
Use REFERENCE.md for badge variants, Shields.io escaping,
proposal content, and the complete AGENTS.md maintenance-rule template.
Modes
- Normal: inspect and automatically reconcile managed badges when their checks select one approved state.
- Audit only: when asked to check, audit, review, or report only, make no edits and return the same findings as proposed changes.
Workflow
- Stop if the in-scope document does not exist. Do not substitute another README unless the user names it.
- Inspect rendered Markdown image badges. Ignore code, inline code, and HTML comments. Report rendered HTML badges as unsupported.
- Classify badges:
- Managed: a static Shields.io
/badge/<label>-<value>-<color>image with a matching approved rule in rootAGENTS.md. - Unmanaged: a static badge without an approved rule.
- Dynamic: a service, endpoint, JSON, GitHub, package, coverage, build, or other live-data route.
- Unsupported: a rendered non-Shields static badge or HTML badge.
- Unknown: classification is uncertain.
- Managed: a static Shields.io
- Leave dynamic, unsupported, unknown, and unmanaged badges unchanged.
- For each managed badge, read only the rule's named local files and run only its named read-only local checks. Follow declared evidence precedence.
- If checks are decisive, update state drift, malformed markup, style drift, and clear accidental duplicates. If evidence conflicts or is ambiguous, leave the badge unchanged.
- Validate the edited badge, its rule, file scope, unchanged dynamic badges, and repository-defined documentation checks.
- Return a concise chat summary of managed, unmanaged, dynamic, unsupported, suggested, and blocked findings, omitting empty groups.
Approval gates
- When no manageable static badges exist, suggest only locally supportable
status,visibility, andversionbadges. Do not add them. - Before adding or adopting a badge, show its exact Markdown, complete rule, initial state, color, repository-wide style, evidence, checks, triggers, and affected files.
- Add or adopt a badge and its rule atomically after approval. If root
AGENTS.mdis missing, ask before creating it. - Require approval to remove a badge, change its contract, change the shared style, migrate an unsupported badge, relocate an existing badge, or create supporting evidence.
- Automatic runs may select only among already approved states.
- Report orphaned rules. Do not restore their badges or remove the rules without approval.
Editing rules
- New badges are plain Markdown images with lowercase alt text, label, value, state name, and named color.
- Place new badges on one line immediately below the first H1:
status,visibility,version, then user-requested badges in approval order. - Use one approved repository-wide style for managed static Shields.io badges. Preserve all unrelated badge formatting.
- Keep badge checks local, read-only, and side-effect free by default.
- Preserve dirty-worktree changes. Stop on conflicts in the same badge row or maintenance subsection. Never revert unrelated work.
- Edit and validate only. Do not stage, commit, or push.
Boundaries
- Do not infer status from activity, tests, issues, or unfinished work.
- Do not infer visibility from README wording or a remote URL alone.
- Do not display planned or unreleased versions.
- Do not browse, query hosting APIs, install dependencies, or mutate supporting sources without explicit approval.
- Do not rewrite existing README instructions when integrating the invocation rule. Add the smallest compatible rule nearby; report conflicts.
Source: eunai/skills (MIT).