engineering-manager

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: engineering-manager
description: reusable engineering manager workflow for complex agentic or human-led engineering tasks that require coordinating specialists, auditing repositories, implementing changes, validating with project-native commands, opening pull requests, resolving review comments, and running an independent final audit. Use when the user asks an agent or engineering lead to coordinate multi-agent or multi-reviewer implementation, create a PR, install project rules or skills, perform large refactors, enforce validation gates, or manage a complex engineering issue from intake through merge readiness.
---

# Engineering Manager

Use this skill to turn a complex engineering request into a managed workflow with specialist agents or human reviewers, evidence gates, implementation, validation, PR handling, review resolution, and final independent audit.

It is tool-agnostic. Adapt it for any environment that supports local agent rules, skills, prompts, or reviewer playbooks, including `.agents`, `.devin`, `.cursor`, `.claude`, `.codex`, `.github`, or project docs.

## Core rule

Act as a manager first. Do not let implementation begin until the relevant discovery agents have produced written findings.

For every complex task:
1. Restate the objective and constraints.
2. Split the work into focused agents.
3. Require each agent to report files inspected, findings, risks, and proposed changes.
4. Merge findings into a concrete checklist.
5. Assign implementation work in small, reviewable slices.
6. Run the repo-native validation loop.
7. Open or update a pull request.
8. Resolve or explicitly dismiss review comments.
9. Run a fresh final audit by an agent that did not write the implementation.

## Default agent set

Use up to 10 agents or reviewers. Prefer fewer when the issue is small, but do not under-split ambiguous or high-risk work.

Suggested roles:
- Manager agent: coordinates, maintains checklist, decides sequencing, owns final response.
- Product/reference audit agent: inspects source-of-truth behavior, docs, designs, APIs, or web implementation.
- Current implementation audit agent: inspects the target app/repo and identifies gaps.
- Architecture agent: proposes state, data, routing, component, or system design changes.
- Performance agent: profiles or reasons about render cost, data flow, recomputation, subscriptions, and latency.
- Design agent: inspects Figma or design references and extracts implementable requirements.
- Implementation agent: makes focused code changes.
- Validation agent: runs typecheck, lint, format, tests, builds, or other project-native checks.
- Review agent: handles PR comments and CI failures.
- Final independent audit agent: re-checks the finished work against requirements and source-of-truth inputs.

## Required findings format

Every non-manager audit agent must report:

```text
Agent: <role>
Files or sources inspected:
- <path or source>

Findings:
- <specific finding>

Proposed changes:
- <specific change>

Risks:
- <risk or none>

Validation needed:
- <command, manual check, CI check, or review>
```

The manager must convert findings into a checklist before implementation.

## Implementation rules

- Prefer small, reviewable commits or batches.
- Keep behavior correctness ahead of visual polish unless the task is primarily visual.
- Do not copy source-of-truth code blindly when adapting across platforms or architectures.
- Preserve project conventions unless a refactor is required for correctness, performance, or maintainability.
- Centralize reusable logic where the project convention expects it.
- Avoid global state for temporary form/session state unless required.
- Break large providers and screens into smaller components that subscribe only to required state.
- Name temporary/scoped state clearly so lifecycle and ownership are obvious.
- Add comments only for non-obvious decisions.

## Validation loop

Inspect the repo before choosing commands. Use package.json, R