Agent Name
Docker Agent
Official Website
https://docs.docker.com/ai/docker-agent/
Agent Type
CLI tool (command-line interface)
CLI Command (if applicable)
docker agent or docker-agent
Installation Method
Docker Desktop (Pre-installed); brew install docker-agent; Download Binary Release
Command/Workflow Structure
Docker Agent uses YAML configuration files to define agents, their instructions, models, tools, sub-agents, and hooks.
A typical configuration is started with:
docker agent run ./agent.yaml
Spec Kit skills are installed in the project-local directory:
Each skill follows the Agent Skills layout:
.docker-agent/skills/speckit-<command>/SKILL.md
For example:
.docker-agent/skills/speckit-specify/SKILL.md
.docker-agent/skills/speckit-plan/SKILL.md
.docker-agent/skills/speckit-tasks/SKILL.md
.docker-agent/skills/speckit-implement/SKILL.md
Argument Passing Pattern
Docker Agent accepts the user message as a positional argument:
docker agent run ./agent.yaml "Read the Spec Kit instructions and create a specification"
For non-interactive execution, it supports:
docker agent run ./agent.yaml --exec "Read the Spec Kit instructions and create a specification"
For JSON output:
docker agent run ./agent.yaml --exec --json "Read the Spec Kit instructions and create a specification"
The resulting command includes the configured agent file:
docker agent run --exec --json ./agent.yaml "<prompt>"
Popularity/Usage
Growing adoption (hundreds of users)
Documentation Links
Use Case
Manual usage
Docker Agent provides a Docker-native way to run AI coding agents defined through version-controlled YAML configurations. Supporting it in Spec Kit allows users to install and use Spec Kit skills from .docker-agent/skills/ while preserving Docker Agent’s existing configuration and execution model.
The integration supports the standard Spec Kit workflow:
specify → plan → tasks → implement
Docker Agent can be launched from the project root and can access the repository’s .specify/ directory, generated specifications, plans, and task files.
Workflow automation usage
The workflow would start with:
specify workflow run speckit \
-i spec="Add a user authentication system" \
-i integration=docker-agent
Workflow automation usage with per-step configuration
See more details about of this type of usage in related issue #4275
The workflow would start with:
specify workflow run speckit \
-i spec="Add a user authentication system" \
-i integration=docker-agent
and configuration may look like this:
steps:
- id: specify
command: speckit.specify
integration: docker-agent
integration_args: [ ./requirements-agent.yaml ] # proposed changes
# integration_options: some opts # proposed changes
input:
args: "{{ inputs.spec }}"
- id: plan
command: speckit.plan
integration: docker-agent
integration_args: [ ./planning-agent.yaml ] # proposed changes
# integration_options: some opts # proposed changes
input:
args: "{{ inputs.spec }}"
- id: implement
command: speckit.implement
integration: docker-agent
integration_args: [ ./implementation-agent.yaml ] # proposed changes
# integration_options: some opts # proposed changes
input:
args: "{{ inputs.spec }}"
The corresponding executions would use different files:
docker agent run ./requirements-agent.yaml --exec --json "<specify prompt>"
docker agent run ./planning-agent.yaml --exec --json "<plan prompt>"
docker agent run ./implementation-agent.yaml --exec --json "<implement prompt>"
Example Command File
Contribution
Additional Context
No response
Agent Name
Docker Agent
Official Website
https://docs.docker.com/ai/docker-agent/
Agent Type
CLI tool (command-line interface)
CLI Command (if applicable)
docker agentordocker-agentInstallation Method
Docker Desktop (Pre-installed); brew install docker-agent; Download Binary Release
Command/Workflow Structure
Docker Agent uses YAML configuration files to define agents, their instructions, models, tools, sub-agents, and hooks.
A typical configuration is started with:
Spec Kit skills are installed in the project-local directory:
Each skill follows the Agent Skills layout:
For example:
Argument Passing Pattern
Docker Agent accepts the user message as a positional argument:
docker agent run ./agent.yaml "Read the Spec Kit instructions and create a specification"For non-interactive execution, it supports:
docker agent run ./agent.yaml --exec "Read the Spec Kit instructions and create a specification"For JSON output:
docker agent run ./agent.yaml --exec --json "Read the Spec Kit instructions and create a specification"The resulting command includes the configured agent file:
Popularity/Usage
Growing adoption (hundreds of users)
Documentation Links
https://docs.docker.com/ai/docker-agent/
https://docs.docker.com/ai/docker-agent/getting-started/installation/
https://docs.docker.com/ai/docker-agent/getting-started/quickstart/
https://docs.docker.com/ai/docker-agent/configuration/overview/
https://docs.docker.com/ai/docker-agent/configuration/hooks/
https://docs.docker.com/ai/docker-agent/features/skills/
https://github.com/docker/docker-agent
Use Case
Manual usage
Docker Agent provides a Docker-native way to run AI coding agents defined through version-controlled YAML configurations. Supporting it in Spec Kit allows users to install and use Spec Kit skills from
.docker-agent/skills/while preserving Docker Agent’s existing configuration and execution model.The integration supports the standard Spec Kit workflow:
Docker Agent can be launched from the project root and can access the repository’s
.specify/directory, generated specifications, plans, and task files.Workflow automation usage
The workflow would start with:
specify workflow run speckit \ -i spec="Add a user authentication system" \ -i integration=docker-agentWorkflow automation usage with per-step configuration
See more details about of this type of usage in related issue #4275
The workflow would start with:
specify workflow run speckit \ -i spec="Add a user authentication system" \ -i integration=docker-agentand configuration may look like this:
The corresponding executions would use different files:
Example Command File
Contribution
Additional Context
No response