skills

Create or update a GitHub PR for the current branch. It handles branch creation from main, rebases the full branch chain up to main, pushes with --force-with-lease, and generates a PR with a smart title and description focused on business rules and architecture changes. It can also screenshot the affected UI if the change touches frontend code.

Implement features and bugfixes using strict outside-in TDD. Each cycle traces back to requirements and design docs when available. It includes a deliberate refactoring phase and generates integration tests when a vertical slice is complete. It wires up BDD step definitions when feature files exist. It can receive a Linear issue as input, rebuilds docs (requirements, design, plan) from the issue into the repo before coding, and graduates them into permanent knowledge after the implementation is complete.

Create an implementation plan for an initiative. It references specific requirements and design decisions from docs/requirements/ and docs/design/, produces a plan in docs/plans/, and generates test cases traced back to requirements. It bridges "what to build" and "building it."

Record a "before/after" walkthrough video pair for a PR using Playwright. Trigger when the user asks to record a PR video, demo a fix, capture a UI walkthrough, or produce reviewer-facing media for a frontend or workflow change. Produces narrated mp4 (preferred for browser drag-drop into a PR description) and gif (committable to the repo so no browser is needed). Follows the team visual standard.

Split requirements, design specs, and plans into self-contained Linear issues targeting ~200-300 LOC each. It reads from the project's docs/requirements/, docs/design/, and docs/plans/, creates issues with the full spec embedded in the body, tags them with "agent issue", and creates an epic parent issue when more than two issues are generated. It deletes the repo docs files after the issues are created.

Review a PR or diff for architectural quality - SOLID principles, codebase consistency, dependency direction, error handling, data flow, test architecture, performance, and security. It reads the code review output for context, checks alignment with design docs, and produces actionable findings for the coding agent to fix.

Run the full issue-to-PR workflow autonomously across a list of Linear issues or a Linear filter. Orchestrates next-issue, code-tdd, code-review, architecture-review, implement-review, qa, and create-pr, plus a post-PR bot-comment polling window. After each issue it runs /compact and re-invokes itself from saved state until the queue drains.

Open-ended thinking partner for vague ideas, hunches, and "what if" questions. Challenges assumptions, explores the codebase for evidence, searches the web for prior art, and keeps pushing the conversation forward. Never concludes on its own.

Review a PR or diff for bugs, logic errors, security issues, edge cases, test quality, and requirements alignment. It uses an agentic approach (dynamically investigate suspicious patterns) backed by a checklist for completeness. It loads project-specific learnings from codebase-learnings.json filtered by area tags.

Review requirements and design specs for conceptual correctness. Analyzes whether the domain concepts, entities, categories, and boundaries expressed in docs are coherent, complete, and consistent with each other and with the codebase. Interactive - presents understanding before proposing changes.

Review code abstractions for conceptual correctness, completeness, and simplicity. Analyzes whether modules, classes, and variables represent coherent concepts - using ontological analysis (essential vs accidental properties, categorical division, four causes) to find misnamed, misplaced, or confused abstractions. Interactive - presents understanding before proposing changes.

Brainstorm and capture technical design decisions for a feature area. It takes user requirements from docs/requirements/ as input and produces a design spec in docs/design/ where every decision traces back to specific requirement numbers. It focuses on the "how" from an engineering perspective.

Audit a project's documentation (requirements, design specs, plans, index, glossary) for inconsistencies and produce a report with suggested fixes. For each finding, cross-checks Linear (source of truth), then the code (how the behavior is actually handled), then sibling docs that touch the same concept, to surface tensions you would otherwise only find at integration time. Never edits docs except `docs/glossary.md` when terminology is resolved. Trigger on explicit audit intent only ("audit the docs", "find contradictions", "are the docs consistent"); do **not** trigger on generic verbs like "check the docs" or "read the docs", which usually mean a lookup, not a consistency sweep.

Reduce a project's documentation to the minimum tokens needed for future agents to do their work. Finds duplicated content across files, obsolete files, dead cross-references, and verbose prose; proposes a numbered change plan (delete / merge / move / trim per file); applies it after the user approves. Operates on every file under docs/ including docs/map/. Trigger on explicit pruning intent ("simplify the docs", "shrink the docs", "dedupe the docs", "the docs are bloated"); do not trigger on lookups or on the existing docs-audit skill which only inspects.

Refresh the project's docs in three places, all keyed on per-folder SHAs that record what was last reconciled. (1) `docs/map/` - concept-first codebase digest the conceiving agents (requirements, design-spec, plan, issue-creation) read instead of grepping source. (2) `docs/requirements/index.md` - registry of requirement docs in `docs/requirements/`. (3) `docs/design/index.md` - registry of design docs in `docs/design/`. On refresh, each folder is diffed against its stored SHA; map leaves whose source files changed are regenerated, and requirements/design index entries are added/updated/removed for files added/modified/deleted in the diff. Run from the project root. First run bootstraps; subsequent runs diff-refresh.

Use when a bug is reported from any source - Sentry alert, Linear issue, pasted stacktrace, or plain description. Diagnoses root cause with three-level cause analysis, writes a regression test, and fixes using RED-GREEN-REFACTOR.

Use when PR review comments need to be analyzed for validity, evaluated for interest, and implemented with test-first approach where the change alters behavior

Extract long-term knowledge from a meeting transcript and persist it into docs/. Filters out ephemeral content and focuses on durable architectural, product, domain, and team knowledge.

Run QA on a PR or branch - execute tests, verify test quality, check requirements coverage, explore the UI with Playwright, and test API endpoints with curl. It is aggressive with edge cases and accessibility.

Brainstorm and capture user requirements for a feature area. It produces structured, numbered requirements in docs/requirements/ that serve as the foundation for design specs and test plans. It focuses on the "what and why" from the user's perspective, not on technology. It generates BDD feature files from the requirements.

Extract project knowledge from the current session into docs/. Keeps docs current, atomic, and indexed.

Capture session activity into a daily log file in logs/ for later review.

Scan a codebase for technical debt - outdated deps, test gaps, code churn hotspots, TODO/HACK markers, recurring Sentry errors, and missing Linear tickets. Produces a prioritized report and optionally creates issues.

Structured reasoning skill for working through tricky design decisions, trade-offs, and "something feels off" moments. Uses proven frameworks (pre-mortem, inversion, three-property tests) to surface hidden assumptions and edge cases before committing to a design.