메뉴
Use when a maintainer needs to cut, bump, or verify a repo release surface such as plugin versions, generated install manifests, and operator update instructions.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | release |
| description | Use when a maintainer needs to cut, bump, or verify a repo release surface such as plugin versions, generated install manifests, and operator update instructions. |
Use this when the task is to advance or verify a repo-owned release surface, not just to describe recent changes.
release is the maintainer-facing workflow for versioned plugin or package
surfaces that ship checked-in install metadata. It keeps release contracts
honest instead of improvising bumps, update advice, generated-file edits, or
publish completion claims. Every task-completing release slice records critique before closeout.
Resolve $SKILL_DIR per ../../shared/references/bootstrap-resolution.md, then
run the planner before mutation, broad verification, tag push, or publish:
python3 "$SKILL_DIR/scripts/plan_release_run.py" --repo-root . --detail
Read every planner required_reads entry and follow next_action. The planner
surfaces current release state, configured evidence packets, target-version
staleness, critique posture, and publish commands without mutating the repo.
If the planner reports scaffold_adapter or repair_adapter, run or repair the
adapter path first:
python3 "$SKILL_DIR/scripts/init_adapter.py" --repo-root .
python3 "$SKILL_DIR/scripts/resolve_adapter.py" --repo-root .
plan_release_run.py; read required refs before acting.references/critique-boundary.md for the exact artifact/blocked-host rule.references/publication-boundary.md.../issue/references/closeout-discipline.md is rendered.../../shared/references/fresh-eye-subagent-review.md for reviewer
tier policy when release critique or closeout review needs a fresh observer.target_unavailable disposition from
../../shared/references/closeout-discipline.md.Use the publish helper payload and release artifact as the output template. The final answer should summarize:
references/index.mdUse when a non-trivial design decision, code change, release, rename, deletion, spec, or workflow change needs a before-the-fact critique. Probe distinct failure angles, then run a counterweight pass that separates real blockers from over-worry before the change locks in.
Use after a meaningful work unit or when the user asks for a retrospective. Reviews what happened, what created waste, which decisions mattered, which named expert lens or direct counterfactual would have changed the next move, and which workflow/capability/memory improvements should make the next session better. Auto-selects `session` or `weekly` mode from context; ambiguous cases default to `session`.
Use when the goal is to understand and improve the repo's current quality bar. Detect existing gates, run the available ones, inspect concept integrity, test confidence, and security posture, then propose concrete quality moves instead of only complaining about what is missing.
Use when filing a GitHub issue from current context or resolving GitHub issues end-to-end through the adapter-resolved backend (`gh` by default, or a host-mediated capability such as `acme github`). Issue creation reports the observed problem before suggesting solutions; issue resolution treats GitHub as the source of truth, classifies the issue, runs a causal review for bug-class issues before designing the fix, and runs a resolution critique so the same class of issue does not recur.
Use when a repo needs its initial operating surface created or normalized. Bootstrap README, AGENTS.md, CLAUDE.md symlink policy, roadmap, and operator-acceptance docs from minimal ideation for greenfield repos, or realign those same surfaces for partially-initialized repos without pretending quality review or deep product ideation already happened.
Use when a concept needs to become a living implementation contract. Refine ideation artifacts or existing design docs into the current build contract, decide what must be fixed now versus probed during implementation, define testable success criteria, and keep the contract synchronized as `impl` learns new facts.