/code-review
<pr-number> [repo]
Review a PR for quality, security, and standards compliance. Invokes the Code Reviewer agent (Rex). Writes the rex-approval marker on success.
In plain English: these are the commands you type into Claude Code to get ApexYard to do something. They're grouped by what you're trying to do — keep quality high, move work forward, see everything at once, onboard new code, run things — not by what's under the hood. If you'd rather see a real day with these, read how it works.
What is it? ApexYard ships 53 active slash commands grouped under outcome headings — Keep quality high, Move work forward, See everything at once, Onboard new code, Run things.
What can it do? Each /<name> is a structured workflow with safety rails — the right framework checks fire at the right moments, so /approve-merge writes a record that the merge gate verifies before the merge actually runs.
What's needed to start? Browse below; invoke any from a Claude Code session inside an apexyard fork. Every skill ships in .claude/skills/<name>/SKILL.md.
The skills that catch mistakes before they reach customers — reviews, audits, security checks. Run /launch-check at milestone boundaries for the full sweep; the individual audits below are the deep-dive companions.
/code-review
<pr-number> [repo]
Review a PR for quality, security, and standards compliance. Invokes the Code Reviewer agent (Rex). Writes the rex-approval marker on success.
/security-review
<pr-number> [repo]
Security-focused PR review for vulnerabilities and best practices. Invokes the Security Reviewer agent (Hakim).
/audit-deps
[project-path]
Audit dependencies for vulnerabilities, outdated packages, and license compliance.
/launch-check
[project-path]
Production readiness audit — multi-dimension sweep (security, accessibility, compliance, analytics, SEO, performance, monitoring, docs) with a scored go / conditional-go / no-go verdict. Use at milestone boundaries, not on every PR.
/threat-model
[project-path]
Threat-modelling exercise across six attack categories — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Surfaces where your system is exposed before someone finds out the hard way.
/accessibility-audit
[project-path]
Comprehensive WCAG 2.1 AA accessibility audit — perceivable, operable, understandable, and robust criteria across the codebase.
/compliance-check
[project-path]
GDPR and ePrivacy compliance audit — cookie consent, privacy policy, data handling, right to deletion, data processing agreements.
/analytics-audit
[project-path]
Analytics coverage and event taxonomy audit — SDK configuration, event naming, funnel completeness, dashboard existence.
/seo-audit
[project-path]
Technical SEO audit — meta tags, Open Graph, sitemap, robots.txt, structured data, mobile-friendliness, Core Web Vitals readiness.
/performance-audit
[project-path]
Performance analysis — bundle size, image optimization, lazy loading, code splitting, caching, Core Web Vitals readiness.
/monitoring-audit
[project-path]
Observability and incident readiness audit — logging, error tracking, health endpoints, alerting rules, runbooks, incident response.
/docs-audit
[project-path]
Documentation completeness audit using the Diataxis framework — tutorials, how-to guides, reference, explanation. Checks README quality, API docs, deployment guides, changelog, and staleness.
/geo-audit
[project-path]
GEO + AEO audit — checks llms.txt, AGENTS.md, AI-crawler robots directives, and JSON-LD citation grounding so your site is discoverable by LLMs and coding agents. Sibling to /seo-audit; /launch-check fans out to both at milestone boundaries.
/mutation-test
[project-path]
Mutation testing sensor — language-dispatched (Stryker / MutPy / go-mutesting / mutant) that injects small code changes and checks whether your tests catch them. Milestone cadence (not per-PR), exit-3 graceful-degrade if no mutation tool is installed for the language.
Capture an idea, file a ticket, record a decision, approve a merge — everything that turns half-formed thoughts into shipped software.
/start-ticket
<issue-number> | <owner/repo>#<number>
Declare an active ticket for this session so the ticket-first hook lets code edits through. Run this at the start of any coding work.
/approve-merge
<pr-number> [--no-merge]
Record per-PR CEO approval and merge the PR in a single turn. ONLY invoke on an explicit user message that names the PR and says "approved" / "merge" / "ship it" — never on an umbrella "go" / "continue". The marker is structured (sha=, approved_by=user, skill_version=2) so a raw echo bypass is mechanically rejected.
/approve-design
<pr-number>
Record per-PR design-review approval so the design-review merge gate lets the PR through. Same per-PR-naming discipline as /approve-merge.
/decide
<what you're deciding>
Make a technical decision with structured reasoning and record it permanently — what you considered, what you picked, and why. Use when choosing between libraries, frameworks, implementation approaches, or architectural patterns; the record means the next person (or future you) doesn't have to re-litigate the call.
/idea
<short title of the idea>
Submit a new product idea, feature concept, or internal tool proposal to the ideas backlog. Use when capturing a new product concept that hasn't been triaged yet.
/validate-idea
<IDEA-NNN | project-name | free-form description>
Lightweight 5-question idea validation. Sits between /idea and /write-spec as a 10-minute gate that catches "this isn't worth speccing" without heavyweight strategy ceremony.
/write-spec
<feature or problem statement>
Write a feature spec or PRD from a problem statement or feature idea. Use when creating product requirements documents.
/feature
<short title of the feature>
Create a structured feature request ticket with user story, acceptance criteria, and design notes. Use when proposing a new user-facing feature.
/bug
<short description of the bug>
Create a structured bug report with Given/When/Then scenario, repro steps, and severity. Use when reporting a bug or unexpected behavior.
/task
<short title of the task>
Create a structured technical task ticket with driver, scope, and acceptance criteria. Use for tech debt, infrastructure work, refactoring, or non-user-facing changes.
/spike
<short title>
Create a hypothesis-driven, time-boxed, throw-away spike ticket — Hypothesis, Budget, Kill Criteria, Disposition. Spike PRs are exempt from the decision-record + 80% coverage gates; Rex + security auditor still apply.
/spike-close
<ticket> --promote | --discard
Disposition gate for spikes. --promote files a follow-up [Feature] ticket with cross-references; --discard writes a memo to docs/spike-memos/<slug>.md. Closing without running this gate leaves no record of what was learned.
/migration
[<project>]
Create a structured database-migration ticket and its matching decision record (rollback plan, downtime estimate, who's affected) in one guided flow. Use BEFORE touching any migration files — the framework blocks edits otherwise.
/investigation
<short title>
Create a structured investigation ticket + live-doc for sustained root-cause work — incident retros, bug archaeology, regression hunts, performance mysteries, competitive analyses. Distinct from /spike (forward-looking hypothesis with a budget) and /bug (immediate-fix). Closes when every follow-up action lands, not on PR merge.
/tickets-batch
[<optional bulk description>]
File 5–20 structured GitHub Issues in one flow. Asks shared-context questions ONCE for the whole batch, then runs a 3-question micro-interview per ticket. Output conforms to .ticket.required_sections by construction.
/plan-initiative
[<initiative-name>]
Decompose a quarter-shape initiative into milestones and tasks with dependency-aware sequencing. Walks you from initiative-level goal through a per-milestone Socratic interview, computes a topo-sorted recommended sequence, and optionally files each milestone as a feature-shape ticket with blocks / blocked by cross-refs already wired.
When you have more than one product going at the same time, the question that costs you the most is "what's waiting on me right now?" These skills answer it without you opening five different GitHub tabs.
/projectsList all active projects under ApexYard management with their status, branch, open PRs, and open issue counts. Use when you need a portfolio-level view.
/inboxEvery item across managed projects that needs your attention — PRs to review, issues assigned to you, comments to respond to, blockers. Use to triage the day.
/statusSnapshot of the current project — git state, open PRs with CI, recent merges, in-progress issue. Multi-project aware. Use to orient yourself in a fresh session.
/tasksA flat actionable task list with direct URLs for everything needing your action — PRs to review, issues to triage, comments to respond to, failing CI. Multi-project aware.
/roadmap
[add | remove | reorder | show] [item]
Update, create, or reprioritise the product roadmap. Supports adding, removing, and reordering milestones, then renders a markdown table per milestone.
/stakeholder-update
weekly | monthly | launch
Generate a stakeholder update tailored to audience. Synthesises recent PRs, closed issues, decisions, and the roadmap into a narrative — written from real activity, not from what you remember.
/agdr
browse | search <term> | show <id> | stats
Searchable, categorised library of every technical decision ever recorded across your portfolio. Answers "have we decided this before?" without grepping every project.
Fresh fork, new project handed to you, codebase you want to understand. These skills get you oriented fast — generating diagrams, feature inventories, process flows from real code instead of from memory.
/setup
[--reset]
First-run framework bootstrap for a new ApexYard fork. Three exchanges — describe your stack, accept defaults, customize — and the fork is configured. Re-run anytime to update.
/handover
<project name> [path or url]
Onboard an external repo into ApexYard management. Reads the target, synthesises a structured handover assessment, and tells you which roles, workflows, and hooks should activate.
/c4
[project-name] [--level=1|2|both] [--force]
Generate architecture diagrams (Level 1 system context + Level 2 container detail) for a project by reading its codebase. Detects external actors, deployable containers, and writes filled-in Mermaid diagrams using the apexyard templates.
/dfd
[project-name | . | --scope-all] [--format=mermaid|dragon|all]
Extract a data-flow diagram from a codebase — what data moves where, what trust boundaries it crosses, what's sensitive. Renders on GitHub as a markdown diagram; feeds into /threat-model and /compliance-check automatically. Threat-Dragon JSON export available via --format=dragon.
/process
<process-slug> [--from-endpoint METHOD /path] [--from-machine ClassName] [--scope dir/]
Extract the business process actually implemented by your code — state machines, queue chains, cron jobs, API choreography — interview only on the gaps, then emit a standard business-process diagram file that opens in any process modeller.
/extract-features
[project-name | .]
Scan an existing codebase and produce a structured Feature Inventory — six discovery axes (HTTP routes, data models, async jobs, test names, UI screens, documented features) consolidated into a "what we must preserve" specification suitable for a greenfield rewrite.
/tech-vision
[project-slug | . | --framework]
Interactive section-by-section author for the technical / architecture vision template — Scope, Principles, Target-state, Current-vs-Target gap table, multi-quarter Migration path, explicit Anti-scope, Review cadence. Writes projects/<name>/architecture/vision.md.
/journey
<feature-slug> [--from-prd <path>]
Generate a single self-contained HTML user-journey map — boxes-and-arrows graph with a clickable modal per page. Sits between PRD and tech-design as a "preview before build" artifact, surfacing flow-level logic gaps before any implementation begins.
/feature-diagram
<feature-slug>
Per-feature Mermaid flowchart showing the routes, models, jobs, and screens that participate in one feature. Consumes the inventory from /extract-features — different lens (per-feature slice) on the same codebase as /c4 (system topology) and /dfd (data flows).
/codify-rule
[<pr-comment-url>]
Turn a human review comment that caught a Rex-miss into a draft handbook entry so the same miss doesn't happen again. Y/N gate, source-PR footer for traceability, auto-routes by file:line context to the right handbook bucket (architecture / general / language / domain).
Sync the framework when there's an update, parallelise independent work, cut a release, debug something hairy, share a PDF with a non-technical stakeholder.
/update
[--dry-run] [--rebase]
Sync the ApexYard fork with upstream. Previews pending commits, creates a sync branch (direct push to main is blocked), merges or rebases, walks per-file conflicts, leaves the branch ready to push as a PR.
/split-portfolio
[--verify | --dry-run]
Migrate a single-fork adopter to split-portfolio mode (public framework + private sibling portfolio). Automates the destructive recovery flow with explicit operator confirmation at every step.
/release
<optional explicit version, e.g. v1.2.0>
Cut a new apexyard release — diff dev against main, pick a semver bump, generate a CHANGELOG draft from conventional commits, open the release PR, and (after merge) tag + push. Framework-only.
/debug
[symptom summary]
Structured hypothesis-driven debugging for issues whose cause isn't immediately obvious. Forces architecture-first reading and evidence-before-fix to prevent ad-hoc patching loops. Invoke when a bug has resisted one or more naïve fix attempts.
/fan-out
<task1, task2, ...> | <path/to/tasks.md> | --from-tickets <ref1,ref2,...>
Spawn N parallel Agent calls in a single assistant message, optionally with worktree isolation for code-writing tasks and background mode for long runs. Use when the user's request decomposes into independent work items that share no files and have no sequential dependencies.
/pdf
<input-path>
Convert any framework-generated document (markdown, HTML, BPMN) to PDF for sharing with stakeholders, board members, or auditors. Destination-prompted at export time (per-project, ApexYard view, custom path, or next-to-source). Dispatches across pandoc / md-to-pdf / wkhtmltopdf / bpmn-to-image; graceful-degrades when no converter is installed.
Try these in your own fork.
Three quickstart steps and every skill above is ready to use in your next Claude Code session.