Skip to content

[colorful-type-pr] iteration-2 ベンチマークから得られた改善候補 #2

Description

@ryotamurakami2fb

Context

iteration-2 benchmark で colorful-type-pr スキルが with_skill 100% / without_skill 89% (Δ+11pp) のパスレートを出したが、
3 eval / 6 run の結果分析から 今後の改善候補 を洗い出した。優先度順に記録する。

改善候補

1. eval-3 が non-discriminator (優先度: 高)

eval-3-leave-out-of-scope-primitives は with_skill / without_skill ともに 100% pass。
「PR の diff 外を触らない」ルールはスキル無しでも強いモデルなら守れる → このテストでは差が出ない。

提案: eval-3 を差し替える。例えば:

  • src/types/* 配下での循環リスクのみを問うシナリオ (type-layer exception の判別)
  • CLAUDE.md §5 のような project-convention と衝突するケース (project-convention check の判別)

2. 「IA documentation value」の扱いをより強くする (優先度: 中)

baseline (without_skill) は DocumentFileFolder['id'] に置換しても number に解決するだけなので
「low ROI」扱いで止まるケースがあった。iteration-2 で skill 側に rationale 節を追加したが、
Phase 2 preamble だけでなく 優先順位ラダー Tier 1 の説明文内 に再掲すると抜けが減りそう。

3. zod → TS narrowing パターンの追加 (優先度: 中)

baseline は type NewDocumentFilesSchema = Omit<z.infer<typeof schema>, 'X'> & { X: Domain }
という優雅なパターンを提案していた。これは:

  • zod 実行時検証は z.number() のまま安全
  • TS 型だけドメインに narrow できる

という低リスク手法なので、Phase 2 の Tier 1 配下の zod サブパターン として SKILL.md に追加する価値あり。
z.custom<Domain['id']>() より安全な選択肢として紹介する。

4. 小規模 PR 向けの single-agent mode (優先度: 低)

現状 Phase 1 は Agent A / Agent B を常に並列起動するが、PR が <10 files の場合はオーバーヘッド。
eval-2 (7 files) の with_skill 実行で、2 agent 起動コストが大きめに見えた。
提案: 診断フェーズで CHANGED_FILES が小規模ならば inline で処理するモードを追加。

5. Phase 5 report の tier breakdown を必須化 (優先度: 低)

「各 primitive が Tier 1-4 のどこに落ちたか」のカウントが全 run で出るとレビュー効率が上がる。
iteration-2 の with_skill run では自然に出ていたが、スキル側で明示フォーマット化していない。
提案: Report テンプレに Tier 1: N件 / Tier 2: N件 / Tier 3: N件 / Tier 4: N件 を必須項目として追加。

6. Grading 自動化スクリプト (優先度: 中)

iteration-2 で grading.json を手書きしたが、eval_metadata.jsoncheck_type
(output_contains_any, output_contains_pattern, no_redefinition, new_types_count) は
パターン・カウント検査なのでスクリプト化可能。
提案: scripts/grade_output.py を追加し、iteration の立ち上げ時間を短縮する。

補足

iteration-2 benchmark raw data: ~/.claude/skills/colorful-type-pr-workspace/iteration-2/ (ローカル)

Signal は明確:

  • 2 failed assertions はすべて redundant type alias 作成import, don't redefine ルールが効く
  • baseline でも sort: string / baseFile type-layer の扱いは正しかった → これらは "差がつきにくい"
  • 強い差がつく領域は「スキーマ由来型の再定義を抑制する」部分 — ここをさらに強化すると iteration-3 で Δ が広がる余地あり

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions