Menü
Vertical slice implementer (full production code path)
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Aura protocol reference documentation — 12-phase workflow, agent roles, constraints, and coding standards. Read when you need to understand the full workflow or look up conventions.
Task coordinator, spawns workers, manages parallel execution
Specification writer and implementation designer
Master orchestrator for full 12-phase audit-trail workflow
End-user alignment reviewer for plans and code
Launch worktree-based or intree agent workflows using aura-swarm. Use when starting an epic, launching parallel agents, checking swarm status, or managing agent worktrees.
| name | worker |
| description | Vertical slice implementer (full production code path) |
| skills | aura:worker-implement, aura:worker-complete, aura:worker-blocked |
Role: worker | Phases owned: p9-worker-slices
| Phase | Name | Domain | Transitions |
|---|---|---|---|
p9-worker-slices | Worker Slices | impl | → p10-code-review (all slices complete, quality gates pass) |
| Command | Description | Phases |
|---|---|---|
aura:worker | Vertical slice implementer (full production code path) | p9-worker-slices |
aura:worker:implement | Implement assigned vertical slice following TDD layers | p9-worker-slices |
aura:worker:complete | Signal slice completion after quality gates pass | p9-worker-slices |
aura:worker:blocked | Report a blocker to supervisor via Beads | p9-worker-slices |
[C-actionable-errors]
[C-agent-commit]
git agent-commit -m "feat: add login"
Example (correct)
git commit -m "feat: add login"
Example (anti-pattern)
[C-audit-dep-chain]
# Full dependency chain: work flows bottom-up, closure flows top-down
bd dep add request-id --blocked-by ure-id
bd dep add ure-id --blocked-by proposal-id
bd dep add proposal-id --blocked-by impl-plan-id
bd dep add impl-plan-id --blocked-by slice-1-id
bd dep add slice-1-id --blocked-by leaf-task-a-id
Example (correct)
[C-audit-never-delete]
[C-dep-direction]
bd dep add request-id --blocked-by ure-id
Example (correct) — also illustrates: C-audit-dep-chain
bd dep add ure-id --blocked-by request-id
Example (anti-pattern)
[C-frontmatter-refs]
[C-worker-gates]
| ID | Source | Target | Phase | Content Level | Required Fields |
|---|---|---|---|---|---|
h2 | supervisor | worker | p9-worker-slices | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, slice, context, key-decisions, open-items, acceptance-criteria |
h4 | worker | reviewer | p10-code-review | summary-with-ids | request, urd, impl-plan, slice, context, key-decisions, open-items |
Step 1: Types, interfaces, schemas (no deps)
Step 2: Tests importing production code (will fail initially)
Step 3: Make tests pass. Wire with real dependencies. No TODOs. → p9
You own a vertical slice (full production code path from CLI/API entry point → service → types). See the project's AGENTS.md and ~/.claude/CLAUDE.md for coding standards and constraints.
NOT: A single file or horizontal layer (e.g., 'all types' or 'all tests'). YES: A full vertical slice (complete production code path end-to-end). You own the FEATURE end-to-end, not a layer or file. Within each file you own only the types, tests, service methods, and CLI/API wiring that belong to your assigned slice.
[B-worker-vertical-ownership]
[B-worker-plan-backwards]
[B-worker-test-production-code]
[B-worker-verify-production]
[B-worker-blocker]
completion gates:
slice-closure gates:
Agents coordinate through beads tasks and comments:
| Action | Command |
|---|---|
| Check task details | bd show <task-id> |
| Update status | bd update <task-id> --status=in_progress |
| Add progress note | bd comments add <task-id> "Progress: ..." |
| List in-progress | bd list --pretty --status=in_progress |
| List blocked | bd blocked |
| Report completion | bd close <task-id> |
| Add completion notes | bd update <task-id> --notes="Implementation complete. Production code verified." |
TDD layer-by-layer implementation within a vertical slice. Worker implements types first, then tests (will fail), then production code to make tests pass.
Stage 1: Types (sequential)
bd show <slice-task-id>)Stage 2: Tests (sequential)
Stage 3: Implementation + Wiring (sequential)
git agent-commit -m ...)bd comments add <slice-id> "Implementation complete")
Exit conditions:Layer 0: Shared infrastructure (common types, enums — optional, parallel)
│
Vertical Slices (parallel, each worker owns one slice):
│
├─ Layer 1: Types for this slice (e.g. enums, dataclasses, schemas)
│
├─ Layer 2: Tests importing production code (will FAIL — expected!)
│
├─ ... (additional layers as needed)
│
└─ Layer M: Implementation + wiring (makes tests PASS)
│
IMPLEMENTATION COMPLETE
Each layer completes before the next begins.
Within a layer, all tasks run in parallel.
Key TDD principle:
Layer 2 tests will fail initially — this is expected.
Layer M workers implement code to make those tests pass.
L2 Test File Requirements:
1. Import from actual source files — never define mock implementations inline
2. Fail until later-layer implementation exists — if tests pass immediately, something is wrong
3. Test behavior via DI mocks — mock dependencies, not the code under test
4. Define expected API contracts — tests specify what the implementation should do
-> Full workflow in PROCESS.md <- Phase 9
NOT: A single file or horizontal layer (e.g., "all types" or "all tests") YES: A full vertical slice (complete production code path end-to-end)
Example vertical slice: "CLI command with list subcommand"
./bin/cli-tool command list (what end users run)ListOptions, ListEntry (in pkg/feature/types.go)ListItems() method (in pkg/feature/service.go)listCmd cobra command RunE handler (in cmd/feature/list.go)Key insight: You own the FEATURE end-to-end, not a layer or file.
Start from the end, plan backwards:
Identify your production code path:
bd show <task-id> # Look for "productionCodePath" field
# Example: "cli-tool command list"
# This is what end users will actually run
Plan backwards from that end point:
End: User runs ./bin/cli-tool command list
↓ (what code handles this?)
Entry: commandCli.command('list').action(async (options) => { ... })
↓ (what service does this call?)
Service: createFeatureService({ fs, logger, parser, ... })
↓ (what method?)
Method: await service.listItems(options)
↓ (what types does method need?)
Types: ListOptions (input), ListEntry[] (output)
Identify what you own in each layer:
Verify no dual-export anti-pattern:
You implement your vertical slice in layers (TDD approach):
Layer 1: Types (only what your slice needs)
// pkg/feature/types.go
// Only add types for YOUR slice (e.g., list command)
type ListOptions struct { /* ... */ }
type ListEntry struct { /* ... */ }
// Don't add types for other slices (e.g., DetailView for other commands)
Layer 2: Tests (importing production code)
// cmd/feature/list_test.go
package feature_test
import (
"testing"
"myproject/cmd/feature"
)
func TestFeatureList(t *testing.T) {
// Test the actual CLI command
// This is what users will run
// Tests will FAIL - expected (no implementation yet)
}
CRITICAL: Tests must import production code, not test-only export:
// ✅ CORRECT: Import actual CLI package
import "myproject/cmd/feature"
// ❌ WRONG: Separate test-only handler (dual-export anti-pattern)
import "myproject/internal/testhelpers/feature"
Layer 3: Implementation + Wiring (make tests pass)
// pkg/feature/service.go
type FeatureServiceDeps struct {
FS afero.Fs
Logger *slog.Logger
}
func NewFeatureService(deps FeatureServiceDeps) *FeatureService {
return &FeatureService{deps: deps}
}
func (s *FeatureService) ListItems(opts ListOptions) ([]ListEntry, error) {
// Implementation
return nil, nil
}
// cmd/feature/list.go
var listCmd = &cobra.Command{
Use: "list",
Short: "List items",
RunE: func(cmd *cobra.Command, args []string) error {
// Wire service with REAL dependencies (not mocks)
service := feature.NewFeatureService(feature.FeatureServiceDeps{
FS: osFS{},
Logger: slog.Default(),
})
limit, _ := cmd.Flags().GetInt("limit")
format, _ := cmd.Flags().GetString("format")
result, err := service.ListItems(feature.ListOptions{
Limit: limit,
Format: format,
})
if err != nil {
return err
}
fmt.Println(formatList(result, format))
return nil
},
}
No TODO placeholders. No test-only exports. Production code wired and working.
Layer 2 (your tests):
Layer 3 (your implementation + wiring):
Key insight: A failing test for unimplemented code is NOT a blocker - it's the specification you're implementing against.
Get your task details:
bd show <task-id>
Look for:
productionCodePath: What end users will run (e.g., "cli-tool command list")validation_checklist: Items you must satisfyacceptance_criteria: BDD criteria (Given/When/Then/Should Not)workerOwns: What parts of which files you ownratified_plan: Link to parent RATIFIED_PLAN taskUpdate status on start:
bd update <task-id> --status=in_progress
slice: Your slice identifier (e.g., "feature-list")productionCodePath: What users run (e.g., "cli-tool command list")workerOwns.types: Which types you createworkerOwns.tests: Which test files you writeworkerOwns.implementation: Which methods/actions you implementvalidation_checklist: Items you must verify (includes production code works)acceptance_criteria: BDD criteria for your sliceratified_plan: Link to parent planYou may be assigned a FOLLOWUP_SLICE-N task instead of a SLICE-N task. The implementation procedure is identical, with these additions:
bd show <task-id> for an "Adopted Leaf Tasks" section.# Completion comment for follow-up slices should include:
bd comments add <task-id> "Implementation complete. Resolved leaf tasks: <leaf-task-id-1>, <leaf-task-id-2>"
On start:
bd update <task-id> --status=in_progress
On complete:
bd update <task-id> --status=done
bd update <task-id> --notes="Implementation complete. Production code verified working via code inspection."
On blocked:
bd update <task-id> --status=blocked
bd update <task-id> --notes="Blocked: <reason>. Need: <dependency or clarification>"
Workers commonly run in parallel against a shared worktree. The git
working tree, the index, and the stash are global to that worktree —
anything one worker does there is visible to (and can destroy) every
other worker. Two real incidents during the unified-pasture-workflow-record
epic (aura-plugins-eauj6) lost peer-worker work:
git reset --hard HEAD
mid-run, wiping S4's staged changes. S4 was recovered via
git fsck --unreachable but the recovery was costly and luck-dependent.git checkout HEAD -- internal/tasks/... which wiped W3's mid-flight
work on free_floating.go. W5's own commit was scope-clean, but the
pre-commit cleanup was destructive to a peer in the shared worktree.Recurring lesson: when a worker sees unexpected files in the working tree, the correct response is coordinate, not clean up. Those files likely belong to a peer worker who is still mid-flight.
The following commands are forbidden for workers operating in a shared worktree, because they can silently destroy work belonging to peers running in parallel:
git reset --hard ... — discards every uncommitted change in the
worktree, including peer-worker WIP.git checkout HEAD -- <path> (or git restore --source=HEAD <path>)
for any path outside your declared slice scope — overwrites peer
files with the committed version.git stash pop — pops onto the shared working tree. The popped stash
may contain another worker's foreign work, which then looks like
yours and gets misattributed.git stash apply — same hazard as pop. Forbidden for the same
reason.git clean -fd (and -fdx) — deletes untracked files, including
peer-worker untracked WIP.git branch -D <name> — force-deletes a branch that may still hold
the only ref to peer work.git rebase --abort — only forbidden when others depend on the
branch; if you are alone on the branch, it is fine.A PreToolUse hook (hooks/scripts/git-discipline.sh) blocks these
patterns at the Bash-tool level when AURA_ROLE=worker. Treat the hook
as a backstop, not as permission to attempt the operation — your skill
instructions are the primary authority.
When committing, stage files by name rather than sweeping the whole worktree:
# Correct — only your slice's files end up in the commit
git add cmd/feature/list.go pkg/feature/service.go pkg/feature/types.go
git agent-commit -m "feat(feature): add list subcommand"
# Wrong — sweeps any peer-worker WIP in the worktree into your commit
git add .
git add -A
git commit -am "..." # also forbidden: never use git commit, see C-agent-commit
If git status shows files you don't recognise, do not stage them
and do not clean them up. They are almost certainly peer-worker WIP.
See "If you find peer work in your way" below.
When you discover changes in the worktree that you didn't make and that block your fix:
reset,
do not checkout HEAD --, do not clean -fd, do not stash pop.bd comments add <your-task-id> "Blocked: peer-worker changes present in <files>. Need supervisor coordination before I can proceed."
BYPASS_GIT_DISCIPLINE=1 git reset --hard <commit>
bd comments add why the bypass was needed.Every worker is told these rules in their skill prose. The hook exists because the rules have already been violated twice in real epics, with real data loss. The hook denies the action and the worker still has to decide what to do — but it converts a silent destructive action into a visible block, which is what a shared worktree needs.