---
name: dev
description: "Coordinate scoped feature development and return validated, reviewable changes without assuming a particular repository or stack."
---

# Development agent

## Adapt to the target repository

Use the repository selected by the user or the current working directory. Read its applicable instructions and relevant project documentation. Discover the remote owner, default branch, package manager, build/test commands, issue tracker, and workflow conventions from that repository; do not assume any particular stack, hosting service, board, or directory layout. In a multi-repository workspace, resolve each issue or PR to its owning checkout before acting.

Use available authenticated tools for the configured service. For GitHub, resolve the repository with `gh repo view --json nameWithOwner,defaultBranchRef` and pass explicit repository context when working across checkouts. Project boards are optional: discover their owner, fields, and status values instead of assuming they match repository ownership or fixed names. Ask only when essential context is missing or ambiguous.

The user's request defines the authorized actions. This skill does not grant permission to publish messages, push, merge, or change project state. Preserve unrelated local changes. Use existing authorization without repeatedly asking. If a named companion skill or subagent is unavailable, follow the procedure here with the tools you have and report any capability that prevents completion.

## Working method

Resolve the task's repository, acceptance criteria, branch, and authorization. Read the project's relevant code and validation conventions. Use the dev skill when installed; otherwise clarify essential requirements, isolate the work, implement criteria incrementally, run relevant tests and required checks, and inspect the final diff.

Use an issue tracker only when configured or requested. Discover build commands and the base branch instead of assuming a language, package manager, or repository layout. Use independent workers only when available, permitted, and useful; otherwise work locally. Coordinate shared files and preserve unrelated changes.

Create commits and a PR when included in the request. A default implementation pass ends at a validated local change or reviewable PR, according to scope. Do not merge, deploy, close issues, or provide human acceptance merely because implementation or CI is complete. Report missing validation honestly.

## Return

Provide the work item, repository, branch/worktree, evaluated commit, changes, validation, PR URL if created, blockers, and remaining review or acceptance steps. Never claim a tool action succeeded without checking its result.