project-release-maintainer

Project overlay for release and packaging maintenance across install layout, shipped assets, automation, license and notice alignment, and release docs. Not for content-only documentation or publishing without explicit authorization.

Ir para a instalação

Repositório: n-n-code/n-n-code-skills
Última atividade na origem: 19 de agosto de 2026 às 08:08
Idioma detectado do SKILL.md: inglês
Estrelas: 4
Forks: 0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/n-n-code/n-n-code-skills --skill project-release-maintainer

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

Project Release Maintainer

This is a composable project overlay. Add matching implementation guidance when source, build, or automation code changes. Compose with documenter when the main artifact is durable release, install, or contributor documentation.

When to use

The change affects the shipped or published contract: package contents, install rules, release automation, shipped assets, license and notice files, release checklists, or documentation that must match those artifacts.

Not for

Use documenter alone for content-only edits that do not require reconciliation with shipped artifacts. For internal code changes with no release impact, use the matching principle skill and add project-core-dev only when repository- specific completion evidence is not concrete. Use project-config-and-tests for config contracts. Use project-vendor-boundary as primary for vendored source ownership, and compose both overlays when a vendor change also alters shipped metadata.

Workflow

Inventory the existing release contract from package manifests, install rules, shipped assets, release automation, license and notice files, checklists, and public documentation. Identify the source of truth before editing.

Trace the requested change across only the affected artifacts. Keep package contents, install behavior, public commands, examples, and release notes mutually consistent.

Use the repo's existing dry-run, package-listing, hygiene, and verification commands. When install behavior changes, validate in a temporary install tree and clean it up; smoke-test the installed artifact when practical.

Inspect the produced package or staged tree rather than inferring contents from build configuration alone. Report unavailable signing, platform, or publication checks instead of implying they passed.

Keep documentation concise and grounded in the shipped build. Do not invent CI, packaging, signing, publishing, or release workflows that the repo does not contain or the user did not request.

Treat tagging, publishing, uploading, signing, credential use, and creating an external release as separate consequential actions that require explicit authorization. Limit license work to keeping declared license and notice files consistent; do not make legal compatibility claims or change project licensing without explicit direction.