ai-workflow

Execute a roadmap end-to-end and AUTONOMOUSLY — phase by phase, task by task: develop in a worktree, review in a fresh context, fix findings, then merge to main. No human gate by default. Use when the user says 'run the roadmap', 'autopilot this', 'ship phases 1-3', 'work through docs/roadmap/', wants unattended multi-phase delivery landed on main, or hands over a roadmap file expecting the whole thing built, reviewed, and merged. Use --supervised to restore per-phase human checkpoints.

Create distinctive, production-grade UI designs in Paper.design MCP — full design system + brand guide + all screens, or a single flow. Use when the user asks to mock up, wireframe, design screens, produce UI, build a visual prototype, or mentions Paper / Paper.design / design system / brand guide / screen layouts for the project. Commits to a bold aesthetic direction (editorial, brutalist, luxury, retro-futuristic, etc.) rather than defaulting to generic AI-SaaS looks. Grounds every design decision in the PRD and architecture, not guesswork.

Diff current UI against Paper design refs with Playwright runtime fidelity checks, then fix mismatches in place. Run before (and during) UI work.

Single-milestone/phase delivery pipeline — implements every open issue in one GitHub milestone (or one roadmap phase) as parallel, conflict-free PRs, each pre-reviewed by a fresh-context reviewer agent. Stops with all PRs open for human merge. Use when the user says 'run factory on milestone N', 'ship phase 003_auth', 'open PRs for the auth milestone', or '/factory --milestone <N>'. For end-to-end multi-phase roadmap execution, use /autopilot instead.

Implement a feature end-to-end from a spec file at docs/specs/<name>.md — code it and verify it. Stops with a working tree the user can review. Supports --commit (auto-commit, output only log) and --pr (auto-commit + open PR, output only log + URL). Use when the user says 'implement the auth spec', 'build feature X', 'code up the Y spec', 'work through docs/specs/<name>.md', or points at a spec and asks to execute it.

Use this skill to generate well-branded interfaces and assets for Rlabs, either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for prototyping.

File GitHub milestones + issues for a roadmap, a phase, or a spec — one milestone per phase, one issue per task/slice — using the trunk-based patterns from /spec, /roadmap, and /feature. Use when the user says 'create the GitHub issues', 'file the issues for this roadmap', 'open issues for this spec', 'make the milestones', or points at docs/roadmap/*.md or docs/specs/*.md and asks to hand them to GitHub.

Create a feature implementation spec at docs/specs/NNN_<feature>.md (prefix mirrors the roadmap phase) — scope, approach, affected files, verification. Use when the user says 'spec out feature X', 'write the implementation plan for Y', 'turn this idea into a spec', 'document how we'll build this', or needs a doc the /feature skill can execute from later.

Create a phased roadmap from design docs — one numbered phase per file under docs/roadmap/NNN_*.md. Use when the user asks to plan phases, break work into milestones, sequence a build, says 'what order should we ship in', 'lay out the roadmap', 'split this into phases', or wants a delivery plan derived from the PRD and architecture.

Diagnose and fix a bug from a description, a stack trace, or a GitHub issue link — reproduce and patch. Stops with a working tree the user can review. Use when the user says 'fix this', 'debug X', 'something is broken', 'why isn't Y working', pastes an error/traceback, or links an issue expecting a patch. Covers root-cause diagnosis, not just symptom patching.

Push the current branch and open a pull request via gh — assumes commits already exist. Use when the user says 'open a PR', 'push this up for review', 'ship this branch', 'create a draft PR', 'put this up on GitHub', or is ready to hand a branch off to reviewers. Supports --draft for work-in-progress.

Create an Architecture Decision Record (ADR) — a single numbered file capturing context, options, and the choice made. Use whenever the user wants to document a design decision, says 'record why we picked X', 'write an ADR', 'lock in this choice', or is choosing between technical options worth preserving for future contributors. Invoked as /adr <title>.

Create or update docs/ARCHITECTURE.md — services, components, data flow, trust boundaries. Use when the user asks to design the system, map out how pieces fit together, sketch data flow, define boundaries, or says 'how should this be structured', 'write up the system design', 'let's architect this', 'draw the component diagram'.

Review a PR or branch using the writer/reviewer pattern — flag issues with specific line references, never rewrite the code. Use when the user asks to review someone's PR, wants a second-opinion pass on a diff, says 'critique this', 'what's wrong with this branch', 'give me review comments', or hands a branch over for inspection rather than implementation.

Create a Request for Comments — heavier than an ADR, lighter than a full spec — for significant changes that need team input before implementation (new systems, major refactors, breaking changes, process changes). Use when the user says 'write an RFC', 'propose X to the team', 'get feedback before we build this', or the decision is too big for an ADR but premature for a spec.

Create or update docs/THREAT_MODEL.md — STRIDE-style threat model, trust boundaries, attack surface, mitigations. Use when the user asks for a threat model, security review, attack-surface analysis, STRIDE pass, or says 'what could go wrong security-wise', 'identify the threats', 'lock this down before launch', 'review the security posture'.

Create or update docs/TECHNICAL_DESIGN_DOCUMENT.md — testing strategy, dev environment, CI/CD, coding standards, linter/formatter choices. Use when the user asks to define testing strategy, set up CI/CD, pick linters/formatters, standardize the dev setup, or says 'how should we test this', 'what's our coding style', 'write the tech design doc', 'set up conventions for the repo'.

Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter/formatter configs, pre-commit hooks, CLAUDE.md, docs skeleton, tailored to the chosen stack (python, go, typescript/nextjs, rust, etc.). Use when the user says 'start a new project', 'bootstrap a repo', 'scaffold X', 'set up a fresh codebase for Y', 'init a new service'.

Stage and commit the working tree, splitting unrelated changes into separate conventional commits. Use when the user says 'commit this', 'save my work', 'wrap this up', 'check in the changes', wants the working tree split into logical commits with conventional-commit messages, or is ready to record progress in git before moving on.

Interview the user and produce a Product Requirements Document — personas, user stories, scope, success metrics. Use when the user asks to write a PRD, draft product requirements, capture user stories, define success metrics, or says 'what should we build', 'let's scope this product', 'write up the requirements'.