A quality guardrail to prevent "just wrote it in the Feature Table" when integrating Claude Code / OpenAI Codex updates. It classifies whether additions to the Feature Table are accompanied by implementation, verification, or explicit designation as a future task, and if anything is missing, it forcibly outputs an implementation proposal.
Quick Reference
This skill is triggered in the following situations:
- When reviewing a Claude Code / Codex upstream update integration PR
docs/CLAUDE-feature-table.mdWhen a diff is detected in which a new line has been added to/harness-reviewInternal invocation when it determines that this is an upstream update integration PRclaude-codex-upstream-updateWhen reviewing a skill update
Situations in which it is not triggered:
- Normal implementation work
- Changes unrelated to the Feature Table / upstream tracking
- Setup / initialization work
Obtaining the diff input
Because this skill is exclusively for diff-aware review, the diff to be reviewed must always be determined by one of the following.
- The caller's
/harness-reviewpasses the PR diff / changed files / Feature Table added lines - This skill itself uses read-only Bash to run
git status --short,git diff --name-only,git diff -- docs/CLAUDE-feature-table.md,git show --stat --name-onlyetc. and verify
Bash is used only for read-only git inspection. Do not run commands that involve test execution, formatting, generation, network access, or file modification.
If the diff cannot be obtained, do not assume B: 書いただけ 0 件 and stop the review as "unclassifiable because no diff was provided".
Prerequisite checks
Always confirm at the beginning of the review:
- Whether the diff source is determined either by being provided by the caller or by read-only git inspection
skills/やhooks/For a PR that edited/reload-plugins, whether it was followed immediately by running{skills,hooks}/**guideline compliance)- Whether there is a version-by-version breakdown table for upstream
- Whether the primary source URL for Claude Code is
anthropics/claude-codeor official docs - Whether the primary source URL for Codex is
openai/codex/releasesor an official OpenAI article B: 書いただけremains- If touching the skill mirror,
skills/,codex/.codex/skills/,.agents/skills/whether the diff is as intended
Prohibited old references:
- Old TypeScript guardrail path
- Old TypeScript implementation glob
- Old Codex feature-table path
- Old Codex plugin directory
- Descriptions that treat the old Codex state directory as the current source of truth
- Nonexistent Anthropic-side Codex repo URL
A/B/C/P classification
Classify each item added to the Feature Table as one of the following: A/B/C/P.
(A) Implemented
Definition: Changes to hooks / settings / Go / scripts / agents / skills / tests corresponding to the Feature Table addition are included in the same PR.
Criteria:
- Files related to the feature mentioned in the Feature Table row have been changed
hooks/hooks.json,.claude-plugin/hooks.json,.claude-plugin/settings.json,go/internal/guardrail/,go/internal/hookhandler/,scripts/,agents/,skills/,tests/There is a substantive diff in any of- Locked by the target test or verification script
Example:
| Add Feature Table | Corresponding implementation changes | Verdict |
|---|---|---|
AskUserQuestion updatedInput |
Go handler + hooks wiring + upstream integration test | A |
sandbox.network.deniedDomains |
.claude-plugin/settings.json + jq test |
A |
find -delete hardening |
go/internal/guardrail/ + unit test |
A |
Result: OK. No additional action needed.
(B) Just written
Definition: A row is added only to the Feature Table, and there are no Harness-side implementation changes or Plans conversion. Also, it does not fall under upstream automatic inheritance.
Verdict criteria:
- There is a new row in the Feature Table
- There are no related implementation / test / skill / Plans changes within the same PR
- It is a feature for which Harness should provide its own added value
Example:
| Add Feature Table | Corresponding implementation changes | Verdict |
|---|---|---|
PreCompact hook |
None | B |
permission hardening |
No confirmation of settings / guardrail / tests | B |
Codex marketplace |
No extraction into Plans | B |
Result: NG. Block the PR and require an implementation proposal or Plans conversion.
(C) upstream automatic inheritance
Definition: Items such as performance improvements, bug fixes, and internal optimizations in Claude Code / Codex itself that require no Harness-side changes.
Verdict criteria:
- It is a fix in upstream itself, and there is no room for Harness to wrap or extend it
- It does not affect Harness settings / hooks / guardrail / workflow / tests
- The Feature Table explicitly states "upstream automatic inheritance" or "CC automatic inheritance / Codex-side automatic inheritance"
Caution:
- Do not easily classify permission / sandbox / security / Bash allowlist / MCP trust boundary as C
- After confirming that the item does not affect Harness's own guardrails or settings, classify it as C
- Claude Code 2.1.113 の hardening は、
sandbox.network.deniedDomains, wrapper Bash deny,find -exec/-delete, do not make a C verdict until the macOS dangerous rm paths are confirmed
Example:
| Add Feature Table | Reason | Verdict |
|---|---|---|
Agent Teams permission dialog crash fix |
Crash fix in CC itself. No Harness-side changes needed | C |
Codex Guardian timeout wording |
Codex-side UX fix. No Harness surface | C |
Result: OK. However, state the reason explicitly.
(P) Plans conversion
Definition: Items that will not be implemented directly this time, but that are worth incorporating into Harness, so they are Plans.md left as explicit tasks in .
Verdict criteria:
- The added-value column of the Feature Table can be read as
A: 将来タスク化orP: Plans 化can be read as Plans.mdThere is a corresponding task in , and the implementation aspects such as setup / guardrails / memory / Codex workflow are specified- The reason for not implementing immediately, such as alpha release or a large-scale design change, is written
Example:
| Add Feature Table | Extraction into Plans | Verdict |
|---|---|---|
Codex marketplace / MCP Apps |
Codex workflow comparison-axis task | P |
Codex 0.122.0-alpha |
Compare investigation task after stabilization | P |
Result: OK. It can be picked up in the next cycle.
Upstream update PR checklist
## Claude/Codex update 統合チェックリスト
### 1. 一次情報と分解表
- [ ] diff source が呼び出し元提供または read-only git inspection のどちらかで確定している
- [ ] Claude / Codex の公式 URL を確認した
- [ ] Version / Upstream item / Category / Harness surface / Action の表がある
- [ ] alpha / stable / docs-only の区別がある
### 2. Feature Table 差分
- [ ] `docs/CLAUDE-feature-table.md` の追加行を列挙した
- [ ] 各行に A / C / P のいずれかが付いている
- [ ] B が 0 件である
### 3. カテゴリ別の確認
- [ ] (A) 実装あり: 対応する実装ファイルとテストがある
- [ ] (B) 書いただけ: 0 件。残る場合は PR ブロック
- [ ] (C) 自動継承: permission / sandbox / security / workflow 影響を確認済み
- [ ] (P) Plans 化: `Plans.md` に将来タスクがある
### 4. Mirror と stale path
- [ ] `skills/` と `codex/.codex/skills/` の意図しない drift がない
- [ ] `.agents/skills/` が存在する場合、Claude/Codex 表記が壊れていない
- [ ] 旧 TypeScript guardrail path、旧 Codex plugin directory、旧 Codex feature-table path などの旧参照がない
### 5. CHANGELOG / tests
- [ ] CHANGELOG に「今まで / 今後」または相当する user-facing 説明がある
- [ ] upstream integration test または対象 unit test が追加 / 更新されている
Output format when Category B is detected
If one or more Category B items are detected, output the implementation proposal in the following format. Output in this format is mandatory and omission is not permitted.
## カテゴリ B 検出: 実装案
### B-{番号}. {Feature Table の項目名}
**現状**: Feature Table に記載のみ。Harness 側の実装 / 検証 / Plans 化なし。
**Harness ならではの付加価値**:
{この機能を Harness がどう活用すべきかの具体的な説明}
**実装案**:
| 対象ファイル | 変更内容 |
|------------|---------|
| `{ファイルパス}` | {具体的な変更内容} |
| `{ファイルパス}` | {具体的な変更内容} |
**ユーザー体験の改善**:
- 今まで: {現在のユーザー体験}
- 今後: {実装後のユーザー体験}
**実装の優先度**: {高 / 中 / 低}
**推定工数**: {小 / 中 / 大}
Related skills
claude-codex-upstream-update- upstream diff investigation and implementation cycleharness-review- code reviewharness-work- implementation of Category B / Pmemory- making classification criteria the SSOT