Menu
Use when bumping, removing, or reconciling nvchecker-tracked packages in locez-overlay, especially when deciding whether a package is release-managed, live-only, or no longer maintained
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when working on Gentoo ebuilds, overlays, eclasses, Manifest files, metadata.xml, pkgdev, pkgcheck, ebuild QA, version bumps, new packages, package reviews, or Gentoo package pull requests.
Unavailable archived skill. Do not use to initialize, continue, repair, or manage long-running projects across sessions; retained only for historical reference and postmortem analysis.
Evidence-backed visual repository analysis for understanding codebases, creating concise Mermaid architecture/flow diagrams, mapping components and runtime/data paths, identifying hotspots, and producing repository-informed improvement opportunities. Use when the user asks to analyze a repository, understand a codebase, generate architecture diagrams, create a visual repo report, find high-value improvement directions, or prepare context for later design/planning work.
Use across bugs, code changes, reviews, architecture, product decisions, writing, research, and general problem solving when the user presents a visible issue, example, proposal, or decision. MUST apply Locez Lens as a lightweight scope and judgment calibration before answering or changing anything.
Use when creating or refactoring a skill for a complex multi-step task, especially when an existing skill has an overloaded main prompt, unclear sub-agent responsibilities, repeated human confirmations, missing intermediate artifacts, weak validation, or a need to turn domain-specific work such as data cleaning into a structured workflow skill.
Use when handling Portage conflicts, @world upgrades, /etc/portage cleanup, binpkg tradeoffs, or deciding where Gentoo maintenance rules and local host preferences should live
| name | locez-overlay-bump-workflow |
| description | Use when bumping, removing, or reconciling nvchecker-tracked packages in locez-overlay, especially when deciding whether a package is release-managed, live-only, or no longer maintained |
Use this skill for package maintenance in /home/locez/locez-overlay.
The core rule is simple: only packages with at least one non-9999 ebuild are bump-managed. 9999-only packages may still exist, but they should not create or keep open nvchecker bump issues.
Use this skill when the user asks to:
locez-overlaynvchecker issues with the current repo state.github/workflows/nvchecker.toml.github/workflows/nvchecker.ymlDo not use this skill for:
locez-overlay9999 package development that does not affect bump trackingClassify the target package before changing anything:
release-managed: the package directory exists and has at least one non-9999 ebuildlive-only: the package exists, but every ebuild is 9999removed: the package directory or maintained release ebuilds are gone by intentThis classification drives both package edits and issue handling.
/home/locez/locez-overlay or its active worktree, not in the skill repository..github/workflows/nvchecker.toml.github/workflows/nvchecker.yml[nvchecker] issue staterelease-managed, live-only, or removed.release-managed: bump the release ebuild, regenerate Manifest, keep nvchecker trackinglive-only: allow functional ebuild edits, but do not create or keep bump issuesremoved: delete package files, remove the nvchecker.toml entry, and close stale bump issues.github/workflows/nvchecker.yml.nvchecker.toml may track maintained release packages and, only if intentionally useful, live-only packages for visibility.nvchecker.toml.For every meaningful ebuild change, run:
pkgdev manifestpkgcheck scanFor each new or bumped release ebuild, also run:
ebuild <target.ebuild> clean fetch unpack compile install clean
If the ebuild supports useful tests and the cost is justified, run:
ebuild <target.ebuild> test clean
The final clean is required. Do not leave build residue behind after local verification.
Default response structure:
ClassificationChangesVerificationOpen issue follow-upRisks9999 packages as normal bump targetsnvchecker.toml[nvchecker] issues open after a package is dropped