Detalle del Skill
engineering-manager
Engineering-manager workflow for coordinating complex implementation through validation and review.
Revisar antes de usar
La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.
SKILL.md
Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.
--- 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, RLeer la fuente completa en GitHub (abre una página externa)