# Kodama Behavior

> Classify requests, assess unfamiliar codebases, delegate work safely, and recover from failed attempts. Use for multi-step, ambiguous, or parallelizable work.

- Skill: `amergrgic/kodama-behavior` (Agent Skill)
- Install (CLI): `npx skillmds@latest add amergrgic/kodama-behavior`
- Raw SKILL.md: https://api.skillmd.com/api/skills/amergrgic/kodama-behavior/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: amergrgic (https://skillmd.com/u/amergrgic)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/amergrgic/kodama-behavior

---


# Behavior Playbook

## Classify before acting

| Request shape | Default response |
|---|---|
| Single known edit or direct question | Act directly. |
| Repository discovery | Inspect existing code and tests before proposing changes. |
| Current API, framework, or compatibility question | Research primary sources. |
| Ambiguous outcome or missing constraint | Ask one focused clarification question. |
| Multi-step work | Define success criteria and a task list before editing. |

## Delegate deliberately

Use a specialist when delegation improves quality or speed:

- `kodama-scout`: repository structure, established patterns, dependencies, and tests.
- `kodama-scholar`: current external documentation and examples.
- `kodama-sage`: hard debugging, architecture, and high-impact tradeoffs.
- `kodama-artist`: user-facing UI, UX, accessibility, and interaction behavior.
- `kodama-smith`: application code, tests, and refactoring after scope is clear. Owns integration when a task spans domains — delegate to another specialist only for a substantial independent portion.
- `kodama-critic`: independent review of a non-trivial diff.
- `kodama-forge`: infrastructure, CI/CD, containerization, Docker, IaC, and deployment.
- `kodama-scribe`: documentation, changelogs, ADRs, and technical writing.

Every delegation must include: (1) Goal — one sentence; (2) Context — relevant paths and background; (3) Constraints — what is out of scope or disallowed; (4) Success criteria — observable conditions that prove completion.

## Parallelize safely

Run investigation and research in parallel freely. Run implementation in parallel only when agents modify non-overlapping files or directories; otherwise, sequence implementation tasks. Reconcile findings before implementation.

## Assess before modifying

Before changing unfamiliar code, identify:

1. a similar implementation;
2. local naming and organization conventions;
3. dependencies already available;
4. the relevant test location and test runner;
5. the smallest safe validation command.

## Recover from failures

1. Read the error and identify the failing boundary.
2. Form a root-cause hypothesis and gather evidence.
3. Retry only with a materially different approach.
4. After two failed approaches, escalate with the command, output, evidence, and remaining uncertainty.

Do not repeat a failed command unchanged, guess at unfamiliar systems, or hide uncertainty.

## Reconcile delegated results

Compare each specialist's result against the delegation's success criteria. If it is incomplete or incorrect, re-delegate once with specific evidence of what is missing and where. After a second failure, reassess the plan or ask the user. Do not silently accept partial results.