Skip to content

[#381] github-issue-381-feat-movement#383

Draft
nrslib wants to merge 1 commit intomainfrom
takt/381/github-issue-381-feat-movement
Draft

[#381] github-issue-381-feat-movement#383
nrslib wants to merge 1 commit intomainfrom
takt/381/github-issue-381-feat-movement

Conversation

@nrslib
Copy link
Owner

@nrslib nrslib commented Feb 25, 2026

Summary

背景

共有インストラクション(facets/instructions/*.md)内で {report:filename} を使うと、ピースごとにレポート名が異なる場合に破綻する。

例: review-test.md{report:test-plan.md} を参照しているが、default ピースでは test-scope.md というレポート名を使う。

現状の回避策として汎用記述(「Report Directory 内のレポートを参照」)に書き換えたが、これだとエージェントが関係ないファイルを見に行くリスクがある。{report:filename} の明示的な契約(どのファイルに依存するか)を維持したまま、共有インストラクションの再利用性を両立させたい。

提案

ピース YAML の movement に vars フィールドを追加し、共有インストラクション内のプレースホルダーにピース固有の値をインジェクションする。

ピース YAML 側

movements:
  - name: testing-review
    instruction: review-test
    vars:
      test_report: test-scope.md

インストラクション側

1. テスト計画レポート({report:{test_report}})と実装されたテストを突合する

展開の流れ

  1. {test_report}test-scope.md(vars によるインジェクション)
  2. {report:test-scope.md}${reportDir}/test-scope.md(既存の report 展開)

処理順序

vars の展開を {report:} の展開より先に実行する。これにより {report:{var}} のネストが自然に解決される。

スコープ

  • varsRecord<string, string> 型(キー・値ともに文字列)
  • プレースホルダー構文: {key} (既存の予約語 task, iteration, previous_response 等と衝突しないよう、vars の展開は予約語チェック後に行う)
  • instruction_template 内でも instruction ファイル内でも使用可能
  • vars が未定義の場合、プレースホルダーはそのまま残る(既存動作と同じ)

関連ファイル

  • src/core/piece/instruction/escape.tsreplaceTemplatePlaceholders()
  • src/core/models/schemas.tsPieceMovementSchema
  • src/infra/config/loaders/pieceParser.ts — YAML パース

Execution Report

Piece default completed successfully.

Closes #381

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: movement-level vars でインストラクションにピース固有の値をインジェクション

1 participant