~/apexyard · skills

39 skillsThe apexyard slash-command surface

Every skill ships in .claude/skills/<name>/SKILL.md and is invoked from a Claude Code session as /<name>. Some take arguments, some are self-driven. The framework's mechanical hooks (in .claude/hooks/) gate their effects on the rest of the SDLC — for example, /approve-merge writes a marker that block-unreviewed-merge.sh then verifies before the merge actually runs.

If you're new, start with /setup on a fresh fork, then /feature or /idea to capture work, then /code-review + /approve-merge when a PR is ready to ship.

Setup & onboarding

Get a fresh fork running, adopt external repos into the portfolio, keep the framework in sync with upstream.

/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.

/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.

Daily ops

Where am I, what needs my attention, what should I do next.

/status

Snapshot 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.

/inbox

Every 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.

/projects

List all active projects under ApexYard management with their status, branch, open PRs, and open issue counts. Use when you need a portfolio-level view.

/tasks

A 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.

Tickets & ideas

Capture work — from a half-formed idea through a structured ticket the team can pick up.

/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.

/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.

/migration [<project>]

Create a structured database-migration ticket and its matching migration AgDR in one guided flow. Use BEFORE touching any migration files — the require-migration-ticket.sh hook blocks edits otherwise.

/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.

Specs & decisions

Turn validated ideas into PRDs; record technical decisions as durable artefacts.

/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.

/decide <what you're deciding>

Make a technical decision with structured reasoning, creating an Agent Decision Record (AgDR). Use when choosing between libraries, frameworks, implementation approaches, or architectural patterns.

Code review & merge

The mechanical merge gate — Rex review, security audit, CEO approval, design review, dependency audit. Each writes a marker the merge hook verifies.

/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 (Shield).

/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.

/audit-deps [project-path]

Audit dependencies for vulnerabilities, outdated packages, and license compliance.

Architecture & dev tools

Diagram the system; debug what's broken with structure rather than ad-hoc patching.

/c4 [project-name] [--level=1|2|both] [--force]

Generate C4 Level 1 (System Context) and Level 2 (Container) architecture diagrams for a project by reading its codebase. Detects external actors, deployable containers, and writes filled-in Mermaid diagrams using the apexyard templates.

/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.

Production-readiness audits

/launch-check runs the full sweep at milestone boundaries; the dimension-specific audits below are the deep-dive companions.

/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]

Full STRIDE threat-modelling exercise — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

/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.

Workflow primitives

Enable, parallelise, release.

/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.

/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.

/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.

Communications

Roadmap planning + stakeholder updates synthesised from the activity stream.

/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, AgDRs, and the roadmap into a narrative.

Deprecated

Kept for redirect-only behaviour while in-flight invocations migrate.

/onboard

Use /setup for framework configuration, /handover for adding a project to the portfolio. This skill redirects to the correct flow.