Activity

1. mnriem

   added

   feature-assessRun the Spec Kit idea-assessment pipeline on this feature requestRun the Spec Kit idea-assessment pipeline on this feature request

   triage-nice-to-haveVerdict: evidence-backed fix or greenlit feature — land after reviewVerdict: evidence-backed fix or greenlit feature — land after review

   on Oct 12, 2026
2. github-actions commented on Oct 12, 2026

   

   github-actionsbot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — per-step-reasoning-context · Stage 1/5: Intake

   Idea Intake: Per-step reasoning effort and context size

   • Slug: per-step-reasoning-context
   • Created: 2026-10-12T12:31:37Z
   • Source: GitHub issue [Feature]: Per-step reasoning effort and context size for command steps, passed through like model #4916 ([Feature]: Per-step reasoning effort and context size for command steps, passed through like model #4916)
   • Type: improvement

   Idea (as captured)

   A workflow author cannot set reasoning effort or context size per command step. Different steps need different settings: speckit.plan may warrant high effort while speckit.tasks does not, and a step analyzing a large spec may need an extended context window.

   Proposed solution: add optional command-step fields reasoning_effort and context_size, with analogous workflow defaults, step-to-workflow resolution, expression support, string validation, explicit unsupported-integration failures, step-output recording, resume re-resolution, and integration mappings. At least Codex, Copilot, and Claude (effort only) should implement mappings, with positive and negative deterministic tests. Update workflow documentation and document that command-step options: is not forwarded to the CLI.

   Use cases include high effort for specify and plan and low effort for tasks, selecting effort through a workflow input, requesting a long context window for a large spec, and keeping per-step settings reproducible and reviewable in YAML rather than process-wide environment variables.

   Restated

   The workflow system would expose reasoning-effort and context-size settings at command-step and workflow-default scope, passing resolved values through to integrations that support them and failing explicitly for integrations that do not. The proposal aims to make per-step behavior reproducible, configurable, and visible in workflow definitions.

   Origin & Context

   • Raised by: markuswondrak (issue author; contributor)
   • Trigger: The issue reports that current command-step options: values are recorded but not dispatched, runtime integration configuration is rejected by most integrations, and the extra-arguments environment variable is process-wide rather than per-step.

   First-Glance Unknowns

   • [NEEDS CLARIFICATION: Should the public field be named context_size, context_window, or another term, given that integrations use different units and tiers?]
   • [NEEDS CLARIFICATION: Which exact integration versions and value vocabularies must be supported at launch, and how should version drift be handled?]
   • [NEEDS CLARIFICATION: What is the expected behavior when a workflow default is set but a particular step or integration cannot support it?]
   • [NEEDS CLARIFICATION: Are there existing workflow compatibility or migration constraints for adding new top-level fields and defaults?]
   • [NEEDS CLARIFICATION: What measurable cost, latency, quality, or reproducibility improvement is expected from per-step settings?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4916 · copilot · gpt52codex · 4.07 AIC · ⌖ 0.793 AIC · ⊞ 24.3K · ◷
3. github-actions commented on Oct 12, 2026

   

   github-actionsbot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — per-step-reasoning-context · Stage 2/5: Research

   Idea Research: Per-step reasoning effort and context size

   • Slug: per-step-reasoning-context
   • Created: 2026-10-12T12:31:37Z
   • Evidence confidence (overall): medium

   Users & Demand

   • The direct user signal is a contributor-submitted feature request describing workflow authors who need different effort and context settings for different commands, including plan versus tasks, large-spec analysis, and workflow-input-driven configuration — source: GitHub issue #4916 (confidence: medium, cited).
   • The repository does not provide usage telemetry, support-ticket counts, or interview evidence quantifying how many workflow authors encounter this limitation — [source: repository inspection] (confidence: high, cited gap).

   Prior Art

   • model is already resolved per command step with a workflow default and expression evaluation in src/specify_cli/workflows/step/command/__init__.py; this is the closest internal precedent for first-class per-step execution settings — [source: src/specify_cli/workflows/step/command/__init__.py, lines 84-114] (confidence: high, cited).
   • Command dispatch currently passes model to dispatch_command, but no reasoning or context keywords are present in the dispatch path — [source: src/specify_cli/workflows/step/command/__init__.py, lines 245-268] (confidence: high, cited).
   • options is merged for the step and recorded, but the inspected command dispatch path does not pass it to the integration; the issue explicitly identifies this as a current limitation — [source: src/specify_cli/workflows/step/command/__init__.py, lines 116-130; GitHub issue [Feature]: Per-step reasoning effort and context size for command steps, passed through like model #4916] (confidence: high, cited).
   • Runtime integration_args and integration_options are deliberately opt-in: the base integration rejects non-empty values unless an integration overrides validation — [source: src/specify_cli/integrations/base.py, validate_runtime_config] (confidence: high, cited).
   • Existing integration tests cover build_exec_args and model handling, but repository search found no reasoning_effort or context_size implementation or test symbols — [source: tests/integrations/ and tests/test_workflows.py] (confidence: high, cited).

   Market & Context

   • The current workaround described by the issue is SPECKIT_INTEGRATION__EXTRA_ARGS, which is process-wide, CLI-specific, and not visible in workflow YAML — source: GitHub issue #4916 (confidence: medium, cited).
   • The proposal cites different mappings across Claude, Codex, Copilot, opencode, Antigravity, Kiro, Cursor, and Gemini, with context-size support narrower than effort support. Those CLI-version observations were supplied by the issue author and were not independently verified in this run — source: GitHub issue #4916 (confidence: low, cited but unverified).
   • If nothing changes, workflow authors must continue using process-wide arguments, integration-specific configuration, or separate workflows/steps without per-step control — source: GitHub issue #4916 (confidence: medium, cited).

   Data & Constraints

   • The current integration host signature accepts model, output_json, integration_args, integration_options, and project_root; adding new settings would affect integration contracts and installer signature validation — [source: src/specify_cli/integrations/base.py; src/specify_cli/integrations/installer.py] (confidence: high, cited).
   • The base class intentionally fails on unsupported runtime options rather than silently ignoring them, which supplies an existing error-handling pattern for opt-in support — [source: src/specify_cli/integrations/base.py, validate_runtime_config] (confidence: high, cited).
   • Workflow state already records resolved command-step values such as model, and resume behavior re-resolves runtime fields according to the issue's cited existing behavior; exact resume coverage for the proposed fields is not yet established — source: src/specify_cli/workflows/step/command/__init__.py; GitHub issue #4916 (confidence: medium, cited).
   • No repository metric establishes acceptable added latency, token cost, context-window size, or quality change; target thresholds remain [NEEDS CLARIFICATION: measurable success thresholds].

   Evidence Against the Idea

   • Cross-integration semantics are not uniform: the issue reports that context size maps to a token count for one CLI and a tier for another, while several integrations have no direct flag. Opaque pass-through preserves flexibility but can make workflows less portable and harder to validate — source: GitHub issue #4916 (confidence: medium, cited).
   • Supporting new keywords touches command validation, workflow defaults, dispatch contracts, multiple integrations, resume state, and documentation; the implementation and maintenance cost may exceed the value for users of integrations without mappings — source: repository inspection; GitHub issue #4916 (confidence: medium, cited).
   • Demand is currently represented by one feature request and lacks quantified adoption or impact evidence — source: GitHub issue #4916 (confidence: high, cited).

   Gaps & Open Questions

   • [NEEDS CLARIFICATION: Which integrations are release-critical, and what exact values should each accept?]
   • [NEEDS CLARIFICATION: Should context be supported only where a direct mapping exists, or should an integration-specific model alias remain the recommended path elsewhere?]
   • [NEEDS CLARIFICATION: What compatibility promise is required when CLI flags or accepted values change between versions?]
   • [NEEDS CLARIFICATION: What measurable reductions in cost/latency or improvements in quality/reproducibility justify the cross-integration work?]
   • [NEEDS CLARIFICATION: What exact workflow schema and resume-state compatibility guarantees must be preserved?]

   Sources

   • [Feature]: Per-step reasoning effort and context size for command steps, passed through like model #4916 (host: github.com, policy: allowlisted)
   • src/specify_cli/workflows/step/command/__init__.py (repository source)
   • src/specify_cli/integrations/base.py (repository source)
   • src/specify_cli/integrations/installer.py (repository source)
   • tests/integrations/ and tests/test_workflows.py (repository source)

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4916 · copilot · gpt52codex · 4.07 AIC · ⌖ 0.793 AIC · ⊞ 24.3K · ◷
4. github-actions commented on Oct 12, 2026

   

   github-actionsbot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — per-step-reasoning-context · Stage 3/5: Problem

   Problem Definition: Per-step reasoning effort and context size

   • Slug: per-step-reasoning-context
   • Created: 2026-10-12T12:31:37Z
   • Inputs used: intake.md, research.md

   Problem Statement

   Workflow authors cannot reliably express different reasoning-effort or context-capacity needs for individual command steps. As a result, settings are either unavailable, process-wide, integration-specific, or hidden outside the workflow definition, reducing control and reproducibility when steps have different cost, latency, or context requirements.

   Affected Users & Stakeholders

   • Users: Workflow authors — cannot declare or review per-step execution preferences in the workflow language.
   • Users: Teams operating multi-step workflows — may pay unnecessary cost or latency for simple steps, or lack sufficient context for large-spec steps; the magnitude is [NEEDS CLARIFICATION].
   • Stakeholders: Integration maintainers — would need to define support and failure behavior for settings whose meanings differ across CLIs.
   • Stakeholders: Spec Kit maintainers — own workflow compatibility, dispatch contracts, resume behavior, tests, and documentation.

   Goals

   • Make step-specific execution preferences expressible and reviewable in workflow definitions.
   • Preserve predictable fallback and expression behavior consistent with existing workflow settings.
   • Ensure unsupported settings are surfaced explicitly rather than silently ignored.
   • Enable teams to choose an appropriate cost/latency/context trade-off per step when their integration supports it.

   Non-Goals

   • Standardizing the meaning or allowed values of effort and context across all external CLIs.
   • Designing detailed integration adapters, command-line mappings, schemas, or implementation tasks at this stage.
   • Making every integration support every setting.
   • Replacing model selection or solving unrelated workflow configuration gaps.

   Success Metrics

   • A workflow author can represent distinct settings for at least two command steps and inspect the resolved values in step state (target behavior; baseline: unavailable).
   • Invalid non-string values and unsupported integration settings produce actionable step failures rather than silent success (target: 100% of covered negative cases; baseline: fields are not available).
   • Supported integrations pass the resolved values to their CLI without changing existing behavior when fields are unset (target: positive and regression test coverage; baseline: no such fields).
   • [NEEDS CLARIFICATION: target reduction in unnecessary cost/latency or target quality improvement for large-context steps.]
   • [NEEDS CLARIFICATION: adoption or workflow-count threshold that would demonstrate meaningful user value.]

   Cost of Inaction

   Authors continue to rely on process-wide extra arguments, integration-specific workarounds, or settings that are recorded but not dispatched. Workflows remain less portable and less self-documenting, while the project has no measured evidence of the resulting cost, latency, or quality impact.

   Open Questions

   • [NEEDS CLARIFICATION: Which integrations and CLI versions are required for the first supported release?]
   • [NEEDS CLARIFICATION: What field name and value contract best represent context settings across token-count and tier-based CLIs?]
   • [NEEDS CLARIFICATION: What compatibility behavior is required when a workflow default targets an integration that cannot support it?]
   • [NEEDS CLARIFICATION: What measurable cost, latency, quality, and adoption thresholds define success?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4916 · copilot · gpt52codex · 4.07 AIC · ⌖ 0.793 AIC · ⊞ 24.3K · ◷
5. github-actions commented on Oct 12, 2026

   

   github-actionsbot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — per-step-reasoning-context · Stage 4/5: Concept

   Concept: Per-step reasoning effort and context size

   • Slug: per-step-reasoning-context
   • Created: 2026-10-12T12:31:37Z
   • Recommended option: Option A — Effort-first foundation

   Options

   Option A — Effort-first foundation

   • Sketch: Make reasoning effort a first-class workflow setting for command steps, with inherited defaults and explicit unsupported-integration behavior. Defer context-size control until its cross-CLI semantics and user thresholds are clearer.
   • Appetite: medium
   • Trade-offs: Addresses the broader directly mappable use case while limiting the first release's semantic variance. It does not help workflows whose primary need is a larger context window, and it still requires integration-specific support and compatibility decisions.
   • Rabbit holes: CLI version drift, value vocabulary differences, resume behavior, and deciding whether unsupported defaults fail at validation time or execution time.

   Option B — Full opaque pass-through

   • Sketch: Expose both reasoning effort and context size as opaque per-step settings and let each integration decide whether and how to interpret them, while surfacing unsupported settings.
   • Appetite: large
   • Trade-offs: Delivers the complete requested workflow author experience and preserves integration flexibility. It has the highest contract, documentation, testing, and maintenance burden, and workflows may be less portable because identical values can have different meanings.
   • Rabbit holes: Supporting many integrations, documenting version-specific mappings, preserving resume semantics, and reconciling token-count versus tier-based context values.

   Option C — Keep the current workaround

   • Sketch: Do not add new workflow fields; document the process-wide extra-arguments workaround and recommend integration-specific configuration or model aliases where applicable.
   • Appetite: small
   • Trade-offs: Lowest maintenance cost and no schema or dispatch compatibility risk. It leaves per-step reproducibility and mixed-step cost/context control unresolved.
   • Rabbit holes: Documentation can become a catalog of unstable CLI flags and may imply support the workflow system does not actually provide.

   Recommendation

   Recommend Option A. The problem and internal precedent for per-step model settings are credible, and effort has more direct mappings in the evidence than context size. A narrower first slice can test whether workflow authors use and benefit from explicit per-step controls while avoiding an early commitment to a cross-CLI context abstraction. Proceed only with explicit support boundaries and measurable cost, latency, or quality targets resolved during specification.

   Out of Scope (for the recommended option)

   • Context-size controls in the first slice.
   • A universal effort vocabulary or normalization layer across integrations.
   • Detailed adapter architecture, CLI argument design, data models, or task breakdown.
   • Making unsupported integrations silently accept or ignore the setting.
   • Solving process-wide extra-argument behavior for unrelated settings.

   Assumptions to Validate

   • [NEEDS CLARIFICATION: At least one supported integration has enough demand and a stable effort mapping to justify the work.]
   • [NEEDS CLARIFICATION: Workflow authors value reviewable per-step effort settings more than the simplicity of current workarounds.]
   • [NEEDS CLARIFICATION: The project can define compatibility behavior for CLI version drift without promising universal portability.]
   • [NEEDS CLARIFICATION: Positive and negative deterministic tests can establish no behavior change when the setting is unset.]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4916 · copilot · gpt52codex · 4.07 AIC · ⌖ 0.793 AIC · ⊞ 24.3K · ◷
6. github-actions commented on Oct 12, 2026

   

   github-actionsbot

   on Oct 12, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — per-step-reasoning-context · Stage 5/5: Decision — verdict needs-clarification

   Decision: Per-step reasoning effort and context size

   • Slug: per-step-reasoning-context
   • Decided: 2026-10-12T12:31:37Z
   • Verdict: needs-clarification
   • Artifacts reviewed: intake.md, research.md, problem.md, concept.md

   Scorecard

   Criterion	Rating	Justification
   Problem validity	adequate	The issue identifies a concrete mismatch between workflow authors' per-step needs and the currently process-wide or non-dispatched configuration paths; quantified impact is missing.
   Evidence strength	adequate	The repository provides strong evidence of the existing model precedent and dispatch boundaries, but demand is represented by one request and external CLI claims were not independently verified.
   Value vs. inaction	adequate	Reviewable per-step control could improve cost, latency, and reproducibility, while current workarounds remain process-wide; no measured baseline establishes the size of the benefit.
   Feasibility / appetite	adequate	An effort-first concept fits a medium appetite and narrows semantic variance, but integration mappings, version drift, and resume behavior remain to be bounded.
   Strategic fit	adequate	The proposal aligns with existing workflow configuration patterns and the project's integration architecture; explicit constitutional guidance for this feature was not identified.
   Risk posture	weak	Cross-CLI semantics, support/version policy, compatibility behavior, and success thresholds are not yet resolved.

   Verdict & Rationale

   Needs clarification. The problem is plausible and an effort-first option is shaped, but the evidence is not sufficient for a confident handoff: the request lacks quantified user impact, independently verified integration/version requirements, and measurable success thresholds. The unresolved context-size naming and support contract also materially affect scope. Clarify these points and revisit research and shape before deciding whether to specify.

   If needs-clarification

   • Blocking questions:
     • [NEEDS CLARIFICATION: Which integrations and CLI versions are release-critical, and what exact effort values must be supported?]
     • [NEEDS CLARIFICATION: What measured cost, latency, quality, or reproducibility improvement would justify the work?]
     • [NEEDS CLARIFICATION: Is context size part of the first release, and what field/value semantics are acceptable across token-count and tier-based CLIs?]
     • [NEEDS CLARIFICATION: What compatibility and failure behavior is required for unsupported integrations, defaults, and CLI version drift?]
     • [NEEDS CLARIFICATION: Can a maintainer or user provide additional demand evidence beyond this single issue?]
       +- Revisit stage: research, shape

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4916 · copilot · gpt52codex · 4.07 AIC · ⌖ 0.793 AIC · ⊞ 24.3K · ◷
7. github-actions

   added

   feature-needs-clarificationFeature assessment verdict: needs clarificationFeature assessment verdict: needs clarification

   on Oct 12, 2026
8. mnriem

   added

   feature-goFeature assessment verdict: go — ready to hand off to /speckit.specifyFeature assessment verdict: go — ready to hand off to /speckit.specify

   and removed

   feature-needs-clarificationFeature assessment verdict: needs clarificationFeature assessment verdict: needs clarification

   on Oct 12, 2026
9. mnriem commented on Oct 12, 2026

   

   mnriem

   on Oct 12, 2026

   Collaborator

   More actions

   I have marked it as a "Go", but please do address some of the clarification questions. Thanks!