aictrl.dev

Skills

• code-review

  Review the exact head revision of a pull request for actionable correctness, security, reliability, performance, and test findings without modifying code. Use when the user says "review this PR", "do a code review", "find defects in this change", or provides a pull or merge request identifier.

• create-bug

  Create an evidence-backed bug report with reproduction, expected and actual behavior, impact, code context, and a regression-test requirement. Use when the user says "file a bug", "report this defect", "turn these symptoms into a ticket", or describes broken or regressed behavior.

• create-issue

  Create a code-grounded engineering story or task with scope, acceptance criteria, test expectations, risks, and open questions. Use when the user says "create an issue", "open a ticket", "make a backlog item", or describes a feature or chore that should be tracked; delegate defects to create-bug.

• create-workflow

  Create and validate an AICtrl workflow v2 YAML file with typed parameters, inline task nodes, mappings, conditions, loops, retries, triggers, and approval gates. Use when the user says "create a workflow", "write workflow YAML", "automate this engineering process", or asks for a file under .aictrl/workflows/.

• design-review

  Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture, primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says "review this design", "review this screen", "review this dashboard", "critique this UI", "is this UI good", "review this mock", "design review", "roast my design", "roast my landing page", or drops an HTML file / screenshot for feedback.

• implement-code-change

  Implement an engineering issue through tests, code, review, and CI, with separate story and bug paths and an optional connected AICtrl workflow. Use when the user says "implement issue 123", "fix this bug", "make this code change", or "take this ticket to a merge-ready PR".

• judge-review-findings

  Judge untriaged code-review findings for the current pull-request head as TRUE, FALSE, or UNCERTAIN and choose FIX, DEFER, or IGNORE without changing code. Use when the user says "triage review findings", "judge these comments", "which findings are real", or "decide what to fix from this review".

• measurement-plan

  Create a measurement plan for a feature using the Goal-Question-Metric (GQM) structure — defines a measurement goal, learning objectives, metrics, and implementation (product analytics events, warehouse tables, event pipeline). Use when user says 'measurement plan', 'GQM', 'goal question metric', 'goal-question-metric', 'measurement goal', 'how do we measure this', 'what metrics for this feature', 'tracking plan', 'analytics requirements', 'how do we know if this works', 'define KPIs for', or when planning a new feature and analytics instrumentation is needed.

• recording-product-demo

  End-to-end pipeline for producing a narrated product demo video from any repo with a web UI — the agent discovers and boots the app locally, preps demo data and auth, writes the narration and a scripted browser journey, records a time-locked Playwright take synced to an ElevenLabs voiceover, assembles a 1080p MP4 with branded title/agenda/end cards, and builds a publish kit (faststart MP4, 720p, poster, SRT captions, embed snippet, optional GCS/S3/YouTube upload). Use when the user says 'record a demo video', 'make a product demo', 'demo video for this app/repo', or wants to re-record an existing demo after UI changes.

• reply-to-code-review

  Judge current-head review findings, fix accepted defects, run verification, post evidence-backed replies, and request bounded re-review. Use when the user says "address review comments", "reply to code review", "fix accepted findings", or "get this PR through review".

• spec-review

  Review an engineering issue or specification against repository evidence for ambiguity, missing acceptance criteria, hidden scope, test gaps, and implementation risk. Use when the user says "review this spec", "check issue 123", "is this ready to build", or "find gaps in this ticket".