svallejo-dev/engineering

Reviews code changes in any language, either a local diff from a fixed point (commit, branch, tag) or a GitHub pull request (number, URL or branch), with parallel reviewers (Cross-cutting, one per language via the language plugins, and Spec) and findings with severity. Posts to GitHub only if asked and never approves. Triggers: "code review", "review since main", "review this branch", "review this PR", "review PR #123", "PR review".

Shared, language-agnostic vocabulary for designing deep modules. Use it when the user wants to design or improve the interface of a module, package or type, find deepening opportunities, decide where a seam goes, make the code more testable or easier for agents to navigate, or when another skill needs this vocabulary.

Drafts or opens a GitHub pull request for the current branch, following the repo's template, title style and language; if there are none, it uses a Conventional Commits title and a template with a visual summary, before/after evidence and merge risk. Draft only, no push: "write a PR description", "draft the PR". It pushes and runs gh pr create only when asked to open it: "open a PR", "make a PR", "send this to review". It commits only the task's files, handles forks and never merges. Without a shell or gh, it drafts the text and the commands.

Diagnosis cycle for hard bugs and performance regressions, in any language. Use it when the user says "diagnose", "debug this" or reports something broken, throwing errors, failing, giving inconsistent results or running slow.

Builds and sharpens a project's domain model. Use it when the terminology of the code or the business is being discussed, when writing or editing a GLOSSARY.md, or when recording or editing an ADR.

Sets this repo up for the engineering skills: where the local specs and tickets live and where the domain documentation (glossary and ADRs) lives. Run it once per repo before using to-spec, to-tickets or code-review. Use it only when the user explicitly asks for it.

Write commit messages and create atomic git commits that follow the repo's own conventions (commitlint, CONTRIBUTING, git log style), falling back to Conventional Commits. Drafting only, nothing executed: "write a commit message", "suggest a commit message", "redacta el mensaje de commit", or a pasted diff. Runs git commit only when asked to commit: "commit this", "haz commit", "commitea", "split into atomic commits". Stages only the current task's files, leaves other changes alone, never pushes unless asked. Without a shell it drafts the text plus the commands.

Relentless questioning to sharpen a plan or design that, along the way, writes the domain glossary and the ADRs. Use it only when the user explicitly asks for it.

Test-driven development in any language. Use it when the user wants to build a feature or fix a bug test-first, mentions "TDD", "red-green-refactor" or "test first", or asks for integration tests.

Turns the current conversation into a spec (PRD) and saves it to the local tracker, without an interview, only synthesizing what was already discussed. Use it only when the user explicitly asks for it.

Splits a plan, a spec or the current conversation into tracer-bullet tickets (vertical slices), each with its blockers declared, and saves them as one file per ticket in the local tracker. Use it only when the user explicitly asks for it.