engineering-skills

Use when the user wants to add a roadmap item, submit a roadmap request, propose a product roadmap candidate, or log RO-team roadmap intake in Linear. Not for generic Linear issue creation, bug reports, or implementation tickets.

Use when the user asks for an adversarial review, opposing-model review, hostile review, red-team review, or extra critical review of a plan, branch, implementation, or large diff.

Use when reviewing a vd-studio pull request as the automated AI PR reviewer (OpenHands pr-review plugin) — judging test coverage for a diff, structuring the review report, or deciding merge readiness.

Use when the user says "close issue [ID]", "close [ID]", "finish closeout", or when a Linear issue already has a review-ready PR and this repository needs the merge, close, and cleanup phase

Use when code has just been written or modified and should be refined for clarity, consistency, maintainability, or reduced complexity without changing behavior.

Use when the user asks to create, file, log, open, draft, refine, decompose, or turn a request, bug, spike, or follow-up into a Linear issue or Linear ticket before work continues.

Use when the user asks how code works, requests a code walkthrough, wants a codebase explanation, or asks to explain a function, module, flow, architecture, or implementation.

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Compact the current conversation into a handoff document for another agent to pick up.

Use when asked to implement, fix, build, or work on an existing Linear issue in this repository, and coding should stop before PR creation

Use when a customer, operator, or support engineer wants to install, deploy, set up, run, update, restart, or tear down Studio with the vibedata CLI — local Docker on one machine or Kubernetes (Azure/AKS) for a team — including prerequisite checks, Azure secret and infra gap handling, sign-in (vibedata login vs az login vs gh auth login), and day-2 lifecycle.

Use when answering org-level or repo-level GitHub maintenance questions about repository inventory, branch health, PR backlog, or safe cleanup follow-up.

Use when adding, retiring, renaming, merging, splitting, or checking sync for a canonical user flow across the User-Flows-Details Sheet and Linear "User Flow" labels. Flow list maintenance only — does not author functional specs or track implementation.

Use when implementation is complete and the user asks to raise, create, open, prepare, or update a PR for an existing Linear issue in this repository

Use when a reported bug needs to be proven before anyone fixes it — a symptom seen in a customer or cloud environment, a report with no confirmed cause, an issue closed once as "not reproducible", a fix whose acceptance criteria were ticked without tests, or any bug that must end in a failing test rather than a write-up

Use when a user asks to review an existing GitHub PR end-to-end, including PR checkout, scope framing, acceptance-criteria verification, draft review preparation, and gated posting of a GitHub PR review event.

Use when test quality decisions are needed for new, changed, brittle, missing, or review-requested unit or component tests, including tests-first work, assertion choice, mock boundaries, lifecycle scenarios, or independent test-session handoff.

Use when the user wants to go from a feature description to an open PR in one uninterrupted flow, asks to yolo a change, says do it all, or requests a single-shot create-implement-PR workflow.