Skip to main content الرئيسية المنشئون whyzsm tiny-agents harness-release
harness-release Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup.
الانتقال إلى التثبيت سوق المهارات اكتشف واستكشف مهارات الذكاء الاصطناعي التي بناها المجتمع.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
عرض تفاصيل Prompt يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/whyzsm/tiny-agents --skill harness-releaseيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
تحميل Zip جاري التحميل... المزيد من هذا المستودع tech-tmax-backend-architect-team Single-Agent T-MAX Java backend architecture and engineering rule package. Use when Codex must design, implement, review, or diagnose T-MAX backend services involving Java 8, Spring Boot, Kylin, MyBatis XML, TiDB/MySQL, Apollo/Nacos, Feign, AnePageHelper, ResponseResult/DataGridResult, UEP export, Redis, RabbitMQ, or Maven multi-module repositories. Routes one Agent through repository intake, architecture decisions, API/data contracts, implementation diagnosis, quality/security review, and bounded evidence loops while keeping builds, tests, live calls, commits, and pushes as separate authority boundaries.
Create polished consulting-style single-file HTML research reports from messy business notes, screenshots, metrics, and iterative user feedback. Use this skill whenever the user asks for a 咨询风/艾瑞咨询风/研究报告/汇报报告/HTML报告, wants business or AI landing-practice material turned into a management-facing report, asks to add charts/diagrams, or asks to update report metrics and keep the whole HTML report consistent.
harmonyos-app-store-self-check Audit HarmonyOS applications for AppGallery/AGC release readiness, including Huawei UX/HMI controls, system-feature integrations, and performance gates for multi-input interaction, latency, frame rate, content display, memory, and CPU. Use when users ask for 鸿蒙上架自检、应用市场审核、AGC发布前检查、控件/系统特性/人机交互/签名/隐私/权限/截图/性能核对或 release 包门禁, especially for Stage-model projects with module.json5, build-profile.json5, hvigorw, and local-first data constraints.
المهن ذات الصلة SOC
استنادا إلى تصنيف SOC المهني
name harness-release description Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup. description-en Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup. description-ja 汎用リリース自動化スキル。Keep a Changelog と GitHub を使うあらゆるプロジェクトで動作。単一確認ゲートで bump 判定・CHANGELOG 昇格・PR/main 反映・タグ・GitHub Release まで全自動実行する。リリース、バージョンバンプ、タグ作成、公開で起動。実装・コードレビュー・プランニング・セットアップには使わない。 kind workflow purpose Release projects through changelog, version, PR/main merge, tag, and GitHub Release gates trigger release, version bump, publish shape workflow role orchestrator pair harness-review owner harness-core since 2026-05-05 allowed-tools ["Read","Write","Edit","Bash","AskUserQuestion","Skill"] argument-hint [patch|minor|major|--dry-run] context fork effort high user-invocable true
Harness Release (汎用)
Keep a Changelog + GitHub を使うあらゆるプロジェクト向け の汎用リリース自動化スキル。
設計原則 : 単一確認ゲート。ユーザーは 1 回だけ全体計画を見て承認する。承認後はファイル書き換え → commit → branch push → PR 作成/更新 → default branch へ merge → default branch 上で tag → GitHub Release までを中断なく実行する。
Release complete の定義 : release は「tag と GitHub Release を作った」だけでは完了ではない。対象 work と release bump が default branch（通常 main）に merge 済みで、release tag が default branch 到達可能 commit を指し、GitHub Release がその tag を公開している状態を完了とする。
Literal invocation note : この skill の入口は harness-release, /release, /release patch, /release --dry-run のような literal command をそのまま使う。
CC runtime hard floor との関係
Claude Code 2.1.183+ の runtime hard floor は GitHub CLI release publish 系コマンドを構造的に deny する (Anthropic 製品仕様、settings.json の permissions.ask で覆せない)。本 skill は publish 自体を実行せず、.github/workflows/release.yml (tag push trigger) に委譲する。skill は tag push までで責務を完了し、その後 scripts/release-verify-publish.sh で workflow による公開を verify する。
Revert 条件 : CC が runtime hard floor に user explicit approval path を提供したら、Post-Gate に直接 publish step を戻すことを検討する。
Bare invocation contract
if $ARGUMENTS == "":
→ 「今までの作業をコミットし、PR/main 反映まで完了してリリースしたい」と解釈し、Review Gate 検出を実行する
→ 対象 work が 1 つに確定できる場合だけ Step 0 (Review Gate) へ自動進行する
→ 対象が不明または review state が無い場合は AskUserQuestion で選択肢を出してから進める
引数なし呼び出し時の最初の応答で必ず次の literal marker を出力する:
RELEASE_AUTOSTART: target=<work-summary>, base_ref=<ref>, mode=<patch|minor|major|auto>
「タスクが不明確」「指示を待ちます」「タスクがありません」「追加の指示をお待ちします」は禁止行動。
Output Contract (P35: 「止まったように見える」UX 対策)
skill 結論時の output の 最後の 1 行 は必ず P35 footer を含め、footer は本文 (user-facing prose) と同じ言語で出力する（言語解決は既存の言語ルールに従い、footer 契約は言語を再定義しない）。これは <local-command-stdout> 経由の表示で user が「止まった」と感じる UX 問題への明示的な instruction (patterns.md P35) で、意図は言語に依存しないため literal は言語ごとに切り替える (#208):
ja: ↑この結果は Claude が要約します。Enter キーで次へ進むか、新規 prompt で別の指示を出してください。
en: ↑Claude will summarize this result. Press Enter to continue, or send a new prompt for a different instruction.
その他の言語: 同じ意味の 1 行を本文と同じ言語で出力する
Language
User-facing prose follows the explicit session or project language.
If no language is configured, use English. Use Japanese only when
i18n.language: ja,
CLAUDE_CODE_HARNESS_LANG=ja
harness-release / /release だけが入力された場合、これは
「今までの作業をコミットし、PR/main 反映まで完了してリリースしたい」 という意味として扱う。
旧表現の 「今までの作業をコミットしてリリースしたい」 も同じ意図だが、完了条件には PR/main 反映を必ず含める。
「タスクがありません」「指示を待ちます」で止まってはいけない。
bare release では、通常の release preflight の前に Review Gate と Work Commit Gate を実行する。
git status --porcelain と git log @{upstream}..HEAD / main..HEAD を確認し、「今までの作業」の対象を特定する.claude/state/review-result.json と .claude/state/review-approved.json を確認し、対象 work に APPROVE 済み review があるか確認するAPPROVE 済み review が無い場合は AskUserQuestion で確認する
ユーザーが「レビューから開始」を選んだら、harness-review を起動し、APPROVE になるまで release へ進まない
harness-review が REQUEST_CHANGES を返した場合は release を保留し、harness-work で修正してから harness-review を再実行する。これを APPROVE までループするharness-review が APPROVE を返した後、working tree の作業 commit を作るworking tree clean になってから通常の release preflight / confirmation gate / PR merge / tag / GitHub Release へ進む
Review Gate AskUserQuestion harness-release 実行時に review approval が確認できない場合は、推測で release しない。
次の Ask を出す。
question: "harness-release は今までの作業をコミットしてリリースしますが、この作業の APPROVE review が見つかりません。どう進めますか？"
options:
- label: "レビューから開始 (Recommended)"
description: "harness-review を実行し、APPROVE になった場合だけ commit/release へ進みます。"
- label: "release dry-run"
description: "ファイルを書き換えず、release 計画と不足 gate だけ確認します。"
- label: "中止"
description: "review も release も行わず止めます。"
ユーザーが「レビューから開始」を選んだ場合は、同じセッション内で harness-review から始める。
harness-review の対象決定は harness-review 側の bare review contract に従う。
review が APPROVE なら、そのまま harness-release の Work Commit Gate へ戻る。
review が REQUEST_CHANGES なら release は保留し、harness-work で修正してから harness-review を再実行する。
この修正後再レビュー loop は APPROVE まで継続する。
Persist Verdict after Review Gate (required / #218 fix) harness-review 委譲後、必ず .claude/state/review-result.json に verdict が永続化されている
ことを確認する。harness-review 側の Persist Verdict step が踏まれていれば既に保存済みだが、
踏み忘れ時の 二段防御 として、Review Gate 側でも次の check + 補完保存を行う。これを欠かすと
Work Commit Gate (Step 6) の git commit が PreToolUse commit guard でブロックされる 。
if [ -f .claude/state/review-result.json ] \
&& [ "$(jq -r '.verdict // empty' .claude/state/review-result.json 2>/dev/null) " = "APPROVE" ]; then
echo "review-result.json already persisted with APPROVE"
else
mkdir -p .claude/state
cat > .claude/state/tmp-review-result.json <<'JSON'
{ "schema_version" : "review-result.v1" , "verdict" : "APPROVE" , ... }
JSON
bash "${HARNESS_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$PWD } } /scripts/write-review-result.sh" \
.claude/state/tmp-review-result.json \
"$(git rev-parse --short HEAD 2>/dev/null || true) "
rm -f .claude/state/tmp-review-result.json
fi
multi-commit セーフティ: Phase 94.1.3 で PostToolUse commit-cleanup が VERSION / .claude-plugin/plugin.json /
harness.toml / CHANGELOG.md のみの bookkeeping commit を認識し承認削除を skip するようになったため、
Post-Gate の version bump commit (Step 11) は harness-release の自動 commit でそのまま通過する。
それ以前のバージョン (4.15.0 以前) を使う場合は、Work Commit Gate と version bump commit の間に
再度 Persist Verdict を行うこと。
修正に仕様正本 / Plans.md / API / permission / migration / billing などの意思決定が必要で、AskUserQuestion が必要
修正方針が複数あり、どれを採るかでユーザー価値や互換性が変わる
ユーザーが Ask で release dry-run または 中止 を選んだ
REQUEST_CHANGES 単体を最終停止理由にしてはいけない。
Work Commit Gate bare release で working tree に未コミット変更がある場合、release version bump commit とは別に、
review 済み work commit を先に作る。
git status --short
git diff --stat
git add <reviewed files>
git commit -m "<type>: <summary>"
commit message は review summary / Plans.md task / branch name から短く生成する。
判断できない場合は AskUserQuestion で 2〜3 個の commit message 候補を出す。
work commit 作成後に .claude/state/review-result.json の commit_hash を確認または更新し、
release preflight へ進む。
通常の release preflight に入った後は、これまで通り working tree dirty を fail とする。
dirty tree のまま version bump / tag / GitHub Release に進まない。
Quick Reference /release
/release patch
/release minor
/release major
/release --dry-run
前提条件 このスキルが動くプロジェクトは以下を満たす必要があります:
CHANGELOG.md が Keep a Changelog 形式[Unreleased] セクションが存在する以下のいずれかの version file を持つ:
VERSION (単独ファイル)package.json (npm)pyproject.toml (Python, [project] または [tool.poetry])Cargo.toml (Rust, [package])
gh CLI がインストール済みで、認証済みgit リモート origin が GitHub を指す
Claude Code plugin project の場合は、claude CLI が plugin tag をサポートしている
これらが満たされない場合、Preflight で detect して abort します。
prUrlTemplate による multi-host review URL は将来候補として認識するが、
このスキルの release automation は今も gh CLI と GitHub remote を primary path とする。
owner / branch / release asset / CI metadata の自動取得は host ごとの差が大きいため、Phase 56.2.3 では docs-only に留める。
単一ゲートフロー [Bare release only: 作業 review/commit 前段]
↓
0. Review Gate (未レビューなら AskUserQuestion → harness-review)
0.5 Work Commit Gate (review APPROVE 済み work を release bump と分けて commit)
↓
[Pre-Gate: 情報収集のみ、ファイル未変更]
↓
1. Preflight (working tree clean / CHANGELOG / gh 等の確認)
2. Version file 自動検出
3. 現在バージョンの読み取り
4. Claude plugin tag preflight (plugin project の場合のみ)
5. [Unreleased] 内容の解析 → bump level 推定
6. 新バージョン算出
7. CHANGELOG 差分ドラフト作成 (メモリ上)
8. GitHub Release notes ドラフト作成 (メモリ上)
★━━━━━━ 単一確認ゲート ━━━━━━★
ユーザーに全計画を 1 回だけ提示:
- 検出された version file
- 現バージョン → 新バージョン
- bump 判定理由 ("[Unreleased] に ### Added があるため minor" 等)
- CHANGELOG 変更プレビュー
- GitHub Release notes ドラフト
- コミット対象ファイル一覧
- 最終アクション (branch push + PR merge + tag + release publish)
ユーザー応答:
"yes" → Post-Gate へ進む
"<修正指示>" → 指示に応じて draft を再生成、再確認
"cancel/no" → 何もせず終了
★━━━━━━━━━━━━━━━━━━━━━━━★
↓
[Post-Gate: 承認後、中断なし]
9. Version file 書き換え
10. CHANGELOG.md 書き換え ([Unreleased] → [X.Y.Z] 昇格 + compare link)
11. git add + commit
12. release branch push
13. PR 作成/更新
14. default branch へ merge
15. default branch を fetch/checkout し、release commit が到達可能であることを確認
16. Claude plugin tag validation + tag (plugin project の場合のみ)
17. GitHub Release 用 semver tag (必要な project のみ)
18. git push origin <default-branch> --tags
19. tag push 後、`.github/workflows/release.yml` が release を公開し、`release-verify-publish.sh` で verify
20. 完了報告
Pre-Gate 詳細
1. Preflight
command -v gh >/dev/null || { echo "gh CLI がありません" ; exit 1; }
command -v python3 >/dev/null || { echo "python3 が必要です" ; exit 1; }
if [ -n "$(git status --porcelain) " ]; then
echo "working tree に未コミット変更があります" ; exit 1;
fi
[ -f CHANGELOG.md ] || { echo "CHANGELOG.md がありません" ; exit 1; }
grep -q "^## \[Unreleased\]" CHANGELOG.md || { echo "[Unreleased] セクションがありません" ; exit 1; }
scripts/release-preflight.sh
この working tree clean check は通常 release preflight の gate である。
bare release で「今までの作業」を commit したい場合は、この check の前に Review Gate と Work Commit Gate を完了させる。
未レビューの dirty tree をこの check だけで abort して終わらせてはいけない。
scripts/release-preflight.sh は tag 作成前に opencode/, skills-codex/, codex/.codex/skills/ の mirror drift も検出する。node scripts/build-opencode.js が差分を生成した場合は release を止め、その差分を commit してから tag に進む。
2. Version File 自動検出 以下を優先順で探索。最初に見つかったものを正本とする:
import os, json, re
import tomllib
def detect_version_file ():
if os.path.exists("VERSION" ):
with open ("VERSION" ) as f:
return ("VERSION" , f.read().strip(), None )
if os.path.exists("package.json" ):
with open ("package.json" ) as f:
data = json.load(f)
return ("package.json" , data["version" ], None )
if os.path.exists("pyproject.toml" ):
with open ("pyproject.toml" , "rb" ) as f:
data = tomllib.load(f)
if "project" in data:
return ("pyproject.toml" , data["project" ]["version" ], "[project]" )
if "tool" in data and "poetry" in data["tool" ]:
return ("pyproject.toml" , data["tool" ]["poetry" ]["version" ], "[tool.poetry]" )
if os.path.exists("Cargo.toml" ):
with open ("Cargo.toml" , "rb" ) as f:
data = tomllib.load(f)
return ("Cargo.toml" , data["package" ]["version" ], "[package]" )
raise RuntimeError("No supported version file found" )
3. Claude Plugin Tag Preflight .claude-plugin/plugin.json が存在する project では、通常の GitHub Release tag とは別に Claude plugin release tag も作る。
ひとことで言うと、git tag -a を手で組み立てる前に、Claude Code 本体の plugin validation に通してから {plugin-name}--v{version} tag を作る。
Pre-Gate ではファイルを書き換えず、以下を確認する。
version sync は grep / sed で拾わず、JSON は structured parser で読む:
command -v claude >/dev/null || { echo "claude CLI がありません" ; exit 1; }
claude plugin validate .claude-plugin/plugin.json
HARNESS_PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-.} "
python3 "${HARNESS_PLUGIN_ROOT} /scripts/check-release-version-sync.py" --root .
claude plugin tag .claude-plugin --dry-run
${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py は、存在する release surface をすべて読み取り、canonical を VERSION > package.json > .claude-plugin/plugin.json > .codex-plugin/plugin.json の順で決める。
そのうえで、以下の不一致・欠落が 1 つでもあれば tag / release に進まない:
VERSIONpackage.json の .version.claude-plugin/plugin.json の .version.codex-plugin/plugin.json の .version.claude-plugin/marketplace.json の .metadata.version.claude-plugin/marketplace.json の .plugins[].version（配列内の各 plugin entry） 不一致時は、どの surface が canonical と違うか、またはどの field が missing / invalid かを表示する。
機械処理や CI で読む場合は --json を使う:
python3 "${HARNESS_PLUGIN_ROOT} /scripts/check-release-version-sync.py" --root . --json
この check は 3 つの事故を防ぐためにある:
VERSION と .claude-plugin/plugin.json の version がずれたまま tag を切る事故package.json / marketplace entry の version が古いまま release workflow に進む事故plugin manifest / marketplace entry の validation を通さず、あとで plugin install / update 側で詰まる事故
--dry-run では claude plugin tag が実際に作る tag 名と内部の git tag -a / push 相当コマンドが見える。ここで見えた command を Confirmation Gate の plan に含める。
4. Bump 自動推定 [Unreleased] 直下の見出しを解析して bump level を決定:
[Unreleased] 内の見出し 推定 bump ### Breaking Changes または ### Removed を含むmajor ### Added を含む (Removed/Breaking なし)minor ### Fixed / ### Changed / ### Security のみpatch 空セクション error: リリース対象なし
5. CHANGELOG ドラフト作成 (メモリ上)
## [Unreleased] の本文を切り出し## [Unreleased] と ## [<previous>] の間に ## [<new>] - YYYY-MM-DD を挿入した形を作成末尾 compare link:
[Unreleased]: .../compare/v<prev>...HEAD → v<new>...HEAD[<new>]: .../compare/v<prev>...v<new> を追加
repo URL は既存の [Unreleased]: 行から動的抽出
6. Release Notes ドラフト作成 (メモリ上) ## [<new>] セクションの内容を元に、GitHub Release 用のマークダウンを生成:
## What's Changed
**<リリーステーマ(1行)>**
### Before / After
<テーブル>
### Added / Changed / Fixed / Removed
<該当セクションをコピー>
---
🤖 Generated with [Claude Code ](https://claude.com/claude-code )
Confirmation Gate すべてのドラフトが揃ったら、ユーザーに 1 回だけ提示:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release Plan: v<old> → v<new> (<bump>)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Version file: <detected file>
Bump reason: <why this level was chosen>
CHANGELOG changes:
[Unreleased] に <N> 項目の変更を検出
[<new>] - YYYY-MM-DD として確定
Compare link を追加
GitHub Release notes preview:
<最初の 10 行>
...
Files to modify:
- <version file>
- CHANGELOG.md
Final actions:
- git commit -m "chore: release v<new>"
- git push origin <release-branch>
- gh pr create/update + gh pr merge into <default-branch>
- git fetch origin <default-branch> && git checkout <default-branch>
- claude plugin tag .claude-plugin --push --remote origin # plugin project の場合。default branch 上で実行
- git tag -a v<new> # GitHub Release 用 semver tag が必要な場合。default branch 上で作成
- git push origin <default-branch> --tags
- (tag push 後は GitHub Actions release workflow が自動で release 公開)
Proceed? [yes / cancel / <修正指示>]
Post-Gate 詳細 失敗箇所 復旧 ファイル書き換え失敗 そこで abort、ローカルは dirty なまま人間が判断 commit 失敗 hook 拒否等。ユーザーに原因を提示して修正を促す PR 作成/merge 失敗 release を未完了として停止。tag / GitHub Release には進まない plugin tag validation 失敗 VERSION / .claude-plugin/plugin.json / marketplace entry の不一致を修正し、tag 作成には進まないpush 失敗 リモート側の問題。ローカル commit/tag は残す
PR / Main Merge Gate Post-Gate の release commit 後は、tag を作る前に GitHub PR を default branch へ merge する。
release_branch="$(git branch --show-current) "
default_branch="${HARNESS_RELEASE_DEFAULT_BRANCH:-main} "
git push -u origin "$release_branch "
gh pr create --base "$default_branch " --head "$release_branch " --title "chore: release v<new>" --body "<release summary>"
gh pr merge --merge --delete-branch=false
git fetch origin "$default_branch " --tags
git checkout "$default_branch "
git pull --ff-only origin "$default_branch "
git merge-base --is-ancestor "<release-commit>" "origin/$default_branch "
既存 PR がある場合は新規作成せず、既存 PR の body を更新して merge する。repository policy が squash merge を要求する場合は、release commit hash ではなく release bump の内容（version files + CHANGELOG + source commits）が default branch に含まれることを確認する。
tag はこの Gate 完了後、default branch の HEAD もしくは release commit 到達可能な commit に対して作る。release branch 上だけに存在する commit を指す tag で GitHub Release を作ってはいけない。
Claude plugin project の tag 作成 .claude-plugin/plugin.json がある project では、PR/main merge 後に default branch 上でもう一度 version sync を確認してから plugin tag を作る:
HARNESS_PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-.} "
python3 "${HARNESS_PLUGIN_ROOT} /scripts/check-release-version-sync.py" --root .
claude plugin tag .claude-plugin --dry-run
claude plugin tag .claude-plugin --push --remote origin
claude plugin tag が作る tag は {plugin-name}--v{version} 形式。既存の GitHub Release workflow が vX.Y.Z tag を前提にしている project では、plugin tag とは別に git tag -a v<new> を作る。plugin 配布の tag は claude plugin tag に任せ、GitHub Release 用 semver tag は release automation の互換 surface として扱う。
Verify Workflow Publish Tag push 後、.github/workflows/release.yml が release を自動公開する。skill は以下で結果を verify する:
OWNER="$(git remote get-url origin | sed 's|.*github.com[:/]\([^/]*/[^/]*\)\.git|\1|') "
bash scripts/release-verify-publish.sh "v${NEW_VERSION} " "${OWNER} "
タイムアウト: 5 秒間隔 × 60 回 = 最大 5 分 polling。
exit 0: PASS — draft=false 且つ assets 4 platform 揃って公開済
exit 2: WARN — timeout (tag は push 済のため abort せず人間判断を促す)
exit 3: ERROR — API error (権限/認証問題、手動調査が必要)
Verify は gh api 経由 (gh release prefix は CC runtime hard floor で deny されるため)。
--dry-run モードPre-Gate 全てを実行し、Confirmation Gate までの内容を表示するが、gate で止まり Post-Gate に進まない 。
Claude plugin project の場合、dry-run でも python3 "${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py" --root . と claude plugin tag .claude-plugin --dry-run を実行し、実際に作られる plugin tag 名と push 対象を表示する。ここで VERSION / package.json / .claude-plugin/plugin.json / .codex-plugin/plugin.json / .claude-plugin/marketplace.json の version surface が不一致または欠落していれば、dry-run の時点で止める。
環境変数 変数 説明 HARNESS_RELEASE_PROJECT_ROOTリポジトリルート (デフォルト: $(pwd)) HARNESS_RELEASE_BRANCHpush 対象ブランチ (デフォルト: 現在のブランチ) HARNESS_RELEASE_DEFAULT_BRANCHPR merge 先 default branch (デフォルト: main) HARNESS_RELEASE_HEALTHCHECK_CMDPreflight で追加実行するコマンド HARNESS_RELEASE_SKIP_GH1 で GitHub Release 作成をスキップ
CHANGELOG 書き方ルール [Unreleased] セクションは必ず以下のいずれかのサブセクションを持つ:
## [Unreleased]
### Added ← minor
### Changed ← patch
### Deprecated ← minor
### Removed ← major
### Fixed ← patch
### Security ← patch
### Breaking Changes ← major (Keep a Changelog 非標準だが一般的)
このスキルはこれらの見出しを機械的に解析するため、見出しの表記揺れ（### Fix / ### Bug Fixes 等）は認識できません。KaCL 標準の見出しを使用してください。
関連スキル
harness-release-internal - 本体 claude-code-harness のリリース時に追加で走らせる harness 固有 preflight/finalization（配布対象外）harness-plan - Plans.md 管理harness-review - リリース前のコードレビュー
設計思想
単一ゲート : ユーザーの判断タイミングは 1 回だけ。mini-confirmation を挟むとラバースタンプ化して意味を失う事前に全て描く : Post-Gate に入ってからの「考え直し」を禁ずる。Gate 前に全 draft を揃えるmain 反映が完了条件 : release tag / GitHub Release は default branch 反映後にだけ作る。branch-only release は未完了として扱う失敗は transparent : 途中で失敗したら自動ロールバックは試みず、ユーザーに現状を提示して判断させるプロジェクト非依存 : VERSION file 形式、mirror、residue check など特定環境の前提を持たない。本体 harness 固有の処理は harness-release-internal に分離 