[Feature]: capture mode for command and prompt workflow steps
まだ誰も着手していません。
評価
調査の方向性
Start with src/specify_cli/workflows/steps/command/init.py and the existing ShellStep capture pattern, then inspect prompt/init.py, validators.py, and IntegrationBase.dispatch_command(). Add regression coverage in tests/test_workflows.py for opt-in command and prompt capture, validation, and timeout behavior; done means captured stdout/stderr reach downstream step outputs while default streaming remains unchanged.
索引モデルが issue の本文から書いたものです。
説明
Problem
Workflow command and prompt steps always stream output to the terminal. The stdout and stderr fields in the step output dict are always empty strings, making them inaccessible to downstream steps via {{ steps.<id>.output.stdout }}.
This limits workflow authors who need to:
- Parse AI agent output and branch on its content
- Pipe command output into a later step as structured data
- Conditionally act on specific output patterns (e.g. exit messages, generated file paths)
The command step docstring (line 26) notes this as a planned enhancement:
Full
stdout/stderrcapture is a planned enhancement.
Proposed Solution
Add an opt-in capture: true field to command and prompt step configs. When set, dispatch uses capture_output=True so stdout and stderr are returned in the step output dict and accessible to downstream steps.
# Before (streaming, stdout/stderr always empty):
- id: plan
type: command
config:
command: speckit.plan
integration: claude
# After (capture mode, stdout/stderr available):
- id: plan
type: command
config:
command: speckit.plan
integration: claude
capture: true
timeout: 300
Downstream steps can then reference:
- id: parse
type: shell
config:
command: "echo '{{ steps.plan.output.stdout | from_json }}'"
Design Notes
- Backward compatible:
capturedefaults tofalse; existing workflows are unaffected - Follows existing pattern:
ShellStepalready captures output withcapture_output=Trueand supportsoutput_format: json - Timeout support: A
timeoutfield (seconds, default 600) prevents hung commands from blocking the workflow, consistent withdispatch_command()default - Implementation: Requires forwarding
stream=not capturetoIntegrationBase.dispatch_command()which already supports both modes
Affected Files
src/specify_cli/workflows/steps/command/__init__.py- config schema, dispatch call, output assemblysrc/specify_cli/workflows/steps/prompt/__init__.py- same pattern for prompt stepssrc/specify_cli/workflows/validators.py-capture(bool) andtimeout(int) validationtests/test_workflows.py- capture mode regression tests
Questions
- Does this direction align with your roadmap for the workflow engine?
- Should capture mode also apply to the
promptstep, or onlycommandsteps? - Any preferences on the field name (
capturevscapture_outputvs something else)?
Happy to implement if this is something you'd like to move forward with.
- 主要言語
- Python
- スター
- 138k
- フォーク
- 12.4k
- 平均マージ
- 3日 6時間
- マージ済み PR(30日)
- 145
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/spec-kit のほかの issue
-
enhancement needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
enhancement needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
enhancement needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
enhancement needs-triage triage-can-wait
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
github/spec-kit の issue をすべて見る
似ている issue
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
canonical/paas-charm#368 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
tech debt
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
StevenBlack/hosts#3256 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
qualcomm/qai-appbuilder#275 ·