# Go task agent
The Go Task Agent is a starter executor for Go codebases. It is optimized for small, idiomatic changes: package boundaries, explicit error handling, `go.mod` hygiene, formatting, and focused tests.

Use it when you want an implementation agent that starts from Go defaults instead of generic software-engineering advice.

> [!NOTE]
> This is a starter agent. It is intentionally generic enough to work across many Go projects, so serious teams should add service-specific capabilities for their HTTP stack, persistence layer, observability conventions, and release checks.

## Agent shape

| Field | Value |
|-------|-------|
| Handle | `go-task-agent` |
| Name | Go Task Agent |
| Kind | `bot` |
| Default role | `executor` |
| Source pattern | `valdr-packs/valdr/vanguard/agents/go/` |

The starter definition mirrors the Java agent shape: one core capability, then hot-loaded domain guidance.

```yaml
schemaVersion: 1.0
agent:
  handle: go-task-agent
  name: Go Task Agent
  kind: bot
  defaultRole: executor
  tags:
    - go
    - valdr
    - task-agent
capabilities:
  - key: valdr.agents.go.go-task-agent.system
    role: core
  - key: valdr.agents.go.build
    role: constraints
    hot-load: true
  - key: valdr.agents.go.code.rules
    role: constraints
    hot-load: true
  - key: valdr.agents.go.design.solid
    role: workflow
    hot-load: true
  - key: valdr.agents.go.testing
    role: workflow
    hot-load: true
```

## What it is good at

| Need | Why this agent fits |
|------|---------------------|
| Package-level fixes | It is biased toward small Go packages, explicit imports, and clear boundaries |
| Error handling | It prefers contextual error wrapping with `%w` and tested error paths |
| Module hygiene | It keeps `go.mod` and `go.sum` consistent when dependencies change |
| Test updates | It can load testing guidance for table tests, mocks, and package-level validation |

The core capability sets practical rules: prefer standard library solutions unless the project already chose a dependency, run `gofmt`, keep module files consistent, avoid uncontrolled concurrency, and summarize validation evidence.

## How to use it

Launch the agent with `/valdr-agent` and pass the starter handle first:

```text
/valdr-agent go-task-agent fix the tenant lookup bug in the auth service.
Touch only the auth and repository packages unless the tests prove a wider change is needed.
Run go test ./internal/auth/... and summarize failures or evidence.
```

Good Go launch prompts include:

- package or module scope
- concurrency constraints
- expected error behavior
- test package scope
- whether dependency changes are allowed

## When not to use it

Do not use `go-task-agent` for PM navigation, sprint staffing, or broad architecture discovery. Use [Gunnar](../../starter-packs/gunnar/) for task context, [Mimir](../../starter-packs/mimir/) for source-backed discovery, and [Skadi](../../starter-packs/skadi/) when execution needs coordination across multiple tasks.

If the task is mostly security review, use [Security audit agent](../security/) instead. If the task is mostly dependency reachability or upgrade planning, route it to `dependency-audit-scout`.

## How to adapt it

Copy the shape and replace the generic Go rules with the conventions your services actually need:

```yaml
capabilities:
  - key: acme.go.service-agent.system
    role: core
  - key: acme.go.http-handlers
    role: constraints
    hot-load: true
  - key: acme.go.repository-patterns
    role: workflow
    hot-load: true
  - key: acme.go.observability
    role: validation
    hot-load: true
```

Add capabilities for your router, tracing library, migration strategy, API error shape, and test fixtures. That turns the starter into an executor that can work inside your service boundaries with less repeated instruction.

## Next step

Use [Build your own](../build-your-own/) when you are ready to convert these starter defaults into a project-specific Go agent.