cortex

Use when the user wants a product one-pager, brief, or short feature spec — drafting one from raw material (idea notes, a feature request, meeting/Slack notes, research snippets), or reviewing and strengthening an existing one (Markdown file or pasted text). Not for long-form PRDs, technical specs (architecture/API/RFC), or non-product docs.

Use when the operator wants to confirm a backend change is adequately tested before it ships — triggers include "QA this branch", "QA this PR", "is this tested enough", "do we have enough tests", "verify test coverage", "confirm the tests pass", "/backend-qa", or any request to audit/gate the unit + integration coverage of a backend change. Verifies an existing test suite; to author missing tests, use [backend-testing](../backend-testing/SKILL.md).

Use when writing, reviewing, or improving tests in a backend / API / service project — triggers include "write tests", "add tests", "test this endpoint", "test this service", "improve test coverage", "/backend-testing", or any request to create or fix backend tests. Also triggered when TDD is active in a backend codebase to provide the testing context and patterns. Covers HTTP APIs, services, workers, and data layers across languages (Python, Node, JVM, Go, Ruby).

This skill should be used when the user says "create a PR", "open a pull request", "make a PR", "push and create PR", "open PR for this", "submit a PR", "PR this branch", "let's get this reviewed", or wants to update an existing PR's description or reviewers. Handles the full PR lifecycle: pre-checks, branch pushing, structured descriptions, reviewer assignment, and task linking. Works standalone or as a step in the ship-it orchestrator.

Creates a Product Requirements Document from one or more content sources. Sources can be passed as arguments — task URL, Jira URL, Notion URL, Google Drive URL, Figma URL, Loom URL, any web URL, a local file or folder path, free-text problem statement, or left empty to read the current folder. Use this skill whenever the user wants to draft, write, or generate a PRD — "/create-prd", "write a PRD", "draft a PRD for X", "create a product requirements doc", "spec this out", "turn this one-pager into a PRD", or pastes a source URL (task manager / Notion / Figma / Drive / Loom / any web link) and asks for a PRD. Also triggers when the user describes a feature in free text and asks for a structured spec.

Use when the operator wants a design or mockup challenged against requirements — triggers include "challenge this design", "review these designs", "do the designs cover all the use cases / states", "verify the mockups match the spec", "audit the screens", "/design-review". Inputs are tool-agnostic: requirements can be PRDs, specs, tickets, Notion/Confluence pages, or pasted text; designs can be in Figma, an HTML page, exported images, or Photoshop. Produces a state-coverage gap report.

Handles bug-fix investigation and testing when start-task routes a Bug category task. Orchestrates root cause investigation (DIAGNOSE_AND_FIX_BUG capability) and a TDD hard gate to prevent recurrence (APPLY_TDD capability), resolved via the runtime-bindings table. Returns to start-task for QA verification and shipping. Always called from start-task; never invoked directly.

Use when writing, reviewing, or improving tests in a frontend project — triggers include "write tests", "add tests", "test this component", "improve test coverage", "/frontend-testing", or any request to create or fix frontend tests. Also triggered when TDD is active in a frontend codebase to provide the testing context and patterns.

This skill should be used when the user says "check git status", "is my branch clean", "git check", "any uncommitted changes", "check before commit", or when another skill needs to validate git state before proceeding. Validates branch, conflicts, uncommitted changes, untracked files, debug artifacts, and push status. Used by pre-ship-check and create-pr as a foundational git state validation step.

Routes non-bug implementation work to the right development skill for the current runtime. Detects an available implementation plan, resolves capabilities (CREATE_PLAN, EXECUTE_PLAN, EXECUTE_INLINE) via the runtime-bindings table, and asks the operator when more than one binding applies. Works standalone — "implement this task", "route this implementation", "/implement-feature" — or as a routing step inside a larger workflow, in which case it returns control to the invoking workflow when implementation completes.

Use when the user wants to create a new task in the task manager from the current conversation — before or after doing the work. Triggers: "log this as a task", "create a ticket for this", "capture this as a task", "I want to track this", "let's create a ticket for what we just found", "add this to the backlog", "log this bug", "create a task before we start", "quick ticket", "log this task", "task for this", or after discovering and fixing an issue together. Do NOT trigger on generic logging requests ("log this error", "console.log", "log to Sentry") or on requests that reference an existing task URL (those go to start-task or ship-it).

Use when the operator asks to investigate a specific question or problem in a running mobile application — triggers include "/mobile-qa", "QA this app", "test this on mobile", or any specific question about a mobile app's behavior. Requires a running app on an iOS simulator or Android emulator and mobile-mcp.

Use when writing, reviewing, or improving tests in a mobile project — triggers include "write tests", "add tests", "test this ViewModel", "test this Presenter", "test this use case", "/mobile-testing", or any request to create or fix mobile tests. Also triggered when TDD is active in a mobile codebase to provide the testing context and patterns. Scoped to native iOS, native Android, and Kotlin Multiplatform. Currently covers unit + integration only.

This skill should be used when the user says "am I ready to ship", "pre-flight check", "check before PR", "ready to merge", "pre-ship check", "can I ship this", "is this ready", or "run checks". Validates that code is in a shippable state: enforces the QA verification gate (blocks bugs without verification, prompts the operator on non-bug tasks without verification), runs git-check for branch and working tree validation, then verifies lint, build, and tests pass. Works standalone or as the first step in the ship-it orchestrator.

Turns Refinement-status tasks into one-shotters. Given any input that resolves to a deterministic set of tasks (task URLs, a milestone/grouping in a project, a project URL, or a user-described filter), reads the codebase, resolves ambiguities, composes a detailed implementation plan per task, attaches it as implementation-plan.md, and transitions the task from Refinement to Unassigned. Triggers: "refine these tasks", "/refine-tasks", "refine M1", "refine milestone X", or providing one or more task URLs alongside a request to detail / spec / plan them. Do NOT trigger to create new tasks, or to start implementing / executing a task.

This skill should be used when development is complete and the work needs to be shipped: the user says "ship it", "we're done", "ready to ship", "done with this feature", "let's wrap up", "mark as in review", "create the PR", "link this to the task manager", "create a PR and update the task", or "push this and close the ticket". Also triggered automatically by `start-task` once the downstream development workflow (feature-dev, fix-bug, brainstorm) signals completion — in that case all session context (task GID, branch, draft PR URL) is already available and must not be re-requested.

This skill should be used when the user provides a task URL and wants to begin working on it — "start task", "work on this", "pick up this ticket", "let's start on [task-id]", "jump on this", "begin this task", or pastes a task URL with intent to start development. Orchestrates the full lifecycle: validates sprint-readiness, sets up the branch and draft PR, routes to the right development workflow (feature-dev, fix-bug, or brainstorm), and ships via ship-it when done. Every run writes a step-by-step checkpoint file so work can be resumed after any interruption ("resume task", "pick up where I left off", "continue [task-id]"). For a shortcut that runs the full task orchestration and ship-it but skips sub-skill routing (feature-dev, brainstorming, fix-bug) and implements inline instead, add "fast" to the arguments — "start task fast", "fast mode", "just start coding".

Pushes a task breakdown to the task manager by faithfully replicating the breakdown markdown into tasks. Use this skill whenever the user wants to submit, push, upload, publish, or create tasks from a task-breakdown file — "submit this breakdown", "upload this task-breakdown file", "push these tasks", "create tasks from the breakdown", "submit breakdown", "publish this plan", or after completing a task-breakdown and the user says "let's push it". Also triggers when the user provides a breakdown file path and a project URL together. Do NOT trigger on requests to create a single task, or to start working on an existing task.

Decomposes product work into a milestone-based roadmap of implementation tasks. Use this skill whenever the user wants to plan, organize, or structure implementation work — "break down this spec", "plan this project", "create a task breakdown", "roadmap this", "/task-breakdown", or provides a spec document (markdown, PDF, task/project URL, Figma link) and wants to figure out how to organize the implementation. Also use when the user wants to restructure, revise, or extend an existing task breakdown. Works for both greenfield projects (new spec to full breakdown) AND incremental work on existing projects (change requests, new features, bug batches slotted into existing milestones).

Asana implementation of the task-manager interface. Maps neutral task operations (create/read/update tasks, statuses, fields, comments, attachments, boards) onto the Asana REST API. Invoked by the task-manager seam when the project's provider is Asana; not called directly by workflow skills.

Jira implementation of the task-manager interface. Maps neutral task operations (create/read/update tasks, statuses, fields, comments, attachments, boards) onto Jira via the `acli` CLI (+ Atlassian MCP fallback). Invoked by the task-manager seam when the project's provider is Jira; not called directly by workflow skills.

Neutral interface to the project's task manager (Asana, Jira, etc.). Other skills perform all task operations through this seam — create/read/update tasks, statuses, fields, comments, and attachments — without naming a specific provider. Use whenever a workflow needs to read or write a task, ticket, or issue.

Use when the operator asks to investigate a specific question or problem in a running web application — triggers include "QA this", "why is X broken", "test this flow", "/qa", "/web-qa", or any specific question about a web app's behavior. Requires a running web app (local or remote) and Chrome DevTools MCP.

This skill should be used when the user says "summarize my work", "what did I do", "session recap", "standup notes", "handoff", "write a summary", "what changed", "wrap up summary", "give me a recap", or "work report". Produces a concise, reusable work summary that other skills (ship-it, create-pr, task-manager) can consume. Standalone use cases include standups, handoffs, Slack posts, and task comments without running the full ship-it flow.

Use when asked to run a security audit, security review, threat model, pentest-style review, find vulnerabilities, check for leaked secrets, run an OWASP Top 10 or STRIDE assessment, or assess a codebase's security posture. Infrastructure-first audit covering secrets archaeology, dependency supply chain, CI/CD, infrastructure, webhooks, LLM/AI security, skill supply chain, OWASP Top 10, STRIDE, and data classification.

Use when the user wants to sync their PR branch with its base branch — "update my PR", "merge main into my branch", "my PR is behind", "pull in base branch changes", "sync with main", "rebase on main", "resolve conflicts with base". Fetches the base, rebases or merges it in, resolves conflicts if needed, and pushes.