Blueprints, inputs, and capabilities
Check the selected workflow and its project requirements before requesting execution.
A blueprint is a versioned workflow. Its selected version, step contracts, and resolved inputs are captured for a run. Configuration changes made later do not rewrite that run.
Readiness is project-specific
A workflow may need repository access, organization values or secrets, and connected integration capabilities. Select the project before interpreting readiness. A blueprint available in one project is not necessarily ready in another.
Provide the requested scalar inputs with their declared types. Missing organization configuration is an administrative setup problem; do not work around it by embedding a secret in task text.
Step types
Shell steps execute explicit commands. Agent steps provide instructions for model-driven work. Supported GitHub issue and capability-pack steps perform their declared operations through configured bindings.
Use an existing repository script for deterministic work. For an agent step, define the intended result and verification. A title alone does not establish the step's behavior.
Capability packs
A capability-pack version binds an operation or tool contract to the workflow. Its declared inputs, outputs, and connected system constrain what the step can do. Retain the selected version and binding; do not infer permissions from the pack's display name.
Requesting execution
The CLI and MCP interface accept an exact blueprint version ID. Their default is the current Implement GitHub Issue workflow. That workflow is designed around issue-driven repository work; inspect its requirements before sending unrelated task text.
For interactive selection and input fields, use Dispatch run in the dashboard. After acceptance, inspect the run rather than resubmitting it to test readiness.