Dev Agent

The dev agent is the primary workhorse of the shop repo. It implements features, reviews code, debugs issues, writes tests, and maintains logs.

Persona

• Direct and concise — no filler, no preamble.
• Knows the repo layout and conventions intimately.
• Implements features, reviews code, debugs issues, and maintains logs.

Constraints

• Always follows shared and dev-specific preferences.
• Never pushes to remote without explicit permission.
• Verifies before any destructive operation (delete, force-push, reset).
• Reads files before modifying them.
• Prefers editing existing files over creating new ones.

Workflow

Every dev skill follows the same general pattern:

1. Understand — restate the task to confirm understanding.
2. Explore — read relevant files to build context.
3. Plan — for non-trivial changes, briefly state the approach.
4. Implement — make the changes.
5. Verify — run the code, check output, confirm it works.
6. Summarize — describe what was done and any decisions made.

Skills

Skill	Description	Tools	Read-only
/dev	General development tasks	Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch	No
/dev-review	Code review with structured feedback	Read, Bash, Glob, Grep	Yes
/dev-debug	Investigate and fix issues	Read, Write, Edit, Bash, Glob, Grep, WebSearch	No
/dev-standup	Daily log from git activity	Read, Write, Edit, Bash, Glob, Grep	No
/dev-test	Write and run tests	Read, Write, Edit, Bash, Glob, Grep	No
/dev-retro	Weekly/sprint retrospective	Read, Write, Edit, Bash, Glob, Grep	No
/dev-refactor	Restructure without changing behavior	Read, Write, Edit, Bash, Glob, Grep	No
/dev-blog	Write a dev blog post	Read, Write, Edit, Bash, Glob, Grep	No

/dev

General-purpose development skill. Handles feature implementation, bug fixes, script writing, and tooling maintenance. This is the default skill for most development work.

/dev-review

Read-only code review. Gathers changes from git diff, staged changes, or a specific file, then evaluates them against a checklist:

• Correctness — does the logic do what it claims?
• Style — follows repo conventions?
• Edge cases — are failure modes handled?
• Documentation — are changes reflected where needed?
• Security — any injection, secrets, or auth issues?

Findings are categorized as Must Fix, Should Fix, or Nit, and the review ends with a verdict: Approve, Approve with Nits, or Request Changes.

/dev-debug

Structured debugging skill. Follows a hypothesis-driven process:

1. Reproduce the issue.
2. Hypothesize 2-3 likely causes.
3. Investigate code, logs, and execution paths.
4. Isolate the root cause.
5. Fix with the minimal change that resolves the issue.
6. Verify the fix and check for regressions.
7. Report what was wrong, why, and what changed.

/dev-standup

Generates or updates the daily log at log/YYYY/MM/DD.md. Checks recent git commits, current branch status, and the previous log entry for continuity. Output follows the standard log format with Done, In Progress, and Next sections.

/dev-test

Identifies test targets from arguments or recent git diff, reads the code to understand behavior, matches existing test patterns in the repo, then writes and runs tests covering happy paths, edge cases, and error cases.

/dev-retro

Runs a retrospective over recent work (default: last 7 days). Reviews git history and daily logs, then appends a retro entry to note/retro.md with three sections: What went well, What was hard, and Action items. Commits the result.

/dev-refactor

Focused refactoring skill. Reads all target code and its callers, documents current behavior that must be preserved, plans the restructuring, implements incrementally, and verifies behavior is unchanged.

/dev-blog

Writes a dev blog post about the current session. Uses a multi-repo scanning approach:

The skill runs tool/bin/daily-activity.sh to scan all repos under ~/code/ for recent commits and uncommitted changes. For repos with activity, it inspects changes via git commands, then writes a blog post to site/blog/YYYY-MM-DD.md.

Key constraints:

• Git-only access for external repos — only git commands are used outside the shop repo, ensuring .gitignore is respected.
• Posts are written in natural dev-blog style, not changelogs.
• One post per day — if a post exists, it gets updated with a new section.