Pluggable workflow input source adapters — start with gh-issue #4525

markuswondrak · 2026-09-11T12:53:39Z

markuswondrak
Sep 11, 2026

Problem

Workflow inputs today are inline strings only (--input key=value). #2405 proposes file references and PR #2420 implements --input key=@path + --input-file payload.json (CLI-side only). But many real specs start their life outside the repo — most commonly as GitHub Issues in this very project's workflow.

Proposal

Generalize input value resolution into a small source adapter layer, and ship one built-in remote adapter: GitHub Issues.

# current (#2420)
specify workflow run speckit --input spec=@docs/spec.md

# proposed addition
specify workflow run speckit --input spec=gh-issue:2405
specify workflow run speckit --input spec=gh-issue:github/spec-kit#2405   # explicit repo

Resolution: fetch issue title + body via the REST API, render as markdown (# <title>\n\n<body>), feed through the existing typed input coercion (_coerce_input) unchanged.

Why GitHub Issues first

Spec Kit is a GitHub project; its own dogfooding loop (issue → spec → PR) is the natural first consumer.
The auth machinery already exists: _github_http.py attaches GITHUB_TOKEN/GH_TOKEN and its GITHUB_HOSTS allowlist guarantees tokens never reach third-party hosts.
No new runtime dependency; mirrors what gh issue view --json title,body does.

Infrastructure (deliberately minimal)

A registry mapping URI schemes to resolver callables, consulted at CLI parse time only:

INPUT_SOURCE_ADAPTERS = {
    "file": resolve_file_adapter,       # absorbs @path from #2420
    "gh-issue": resolve_gh_issue_adapter,
}

Third-party sources (Jira, Slack, Linear…) would not go into core — they belong to extensions or custom step types, consistent with the extension system RFC ("external tools without bloating the core"). The registry merely defines the contract so community adapters can slot in later.

Security constraints (v1)

Sources are CLI-typed only — no YAML-declared remote sources, since catalog-installed workflows are untrusted and a YAML-declared URL plus ambient tokens is an exfiltration vector.
Token reuse follows the existing allowlist pattern; adapters get no raw credential access.

Questions for maintainers

Do you see input source adapters as in-scope for stock spec-kit at all, or should this live entirely in extensions/custom steps?
If in-scope: is CLI-time resolution (engine stays network-free) the right seam, per @mnriem's note on [Feature]: Support file references for workflow inputs #2405 that this "should logically map onto how information is now shared between steps"?
Should this build on PR feat(workflows): support file-backed inputs #2420's _parse_workflow_inputs, or wait until it lands?

Refs: #2405, PR #2420

AI assistance note: This proposal was drafted with AI assistance (GLM via opencode); I reviewed, edited, and approved the content before posting.

Navigation Menu

Uh oh!

Pluggable workflow input source adapters — start with gh-issue #4525

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Uh oh!

Pluggable workflow input source adapters — start with gh-issue #4525

Uh oh!

markuswondrak Sep 11, 2026

Problem

Proposal

Why GitHub Issues first

Infrastructure (deliberately minimal)

Security constraints (v1)

Questions for maintainers

Replies: 0 comments

markuswondrak
Sep 11, 2026