wf

Plugin wf from marketplace ai-workflow in rafagomes/ai-workflow. Commands read from the repo's manifest — yesterday.

Skills (16)

• rlabs-design

  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.

• adr

  Write an Architecture Decision Record — one numbered file in docs/adr/ with context, options considered and the choice. Use when the user says 'write an ADR', 'record why we picked X', 'document this decision', or has just made a technical choice future contributors will question. Not for whole-syst

• architecture

  Create or update docs/ARCHITECTURE.md — the system (components, data flow, stack, deployment, key decisions) and how it is engineered (testing strategy, dev environment, CI/CD, coding standards). Use when the user wants to design or document the system, map how the pieces fit, define a testing strat

• autopilot

  Deliver a roadmap, one phase, or one GitHub milestone end-to-end: develop each task in a worktree, review it in a fresh context, fix findings, and merge to the trunk branch. Autonomous by default, except T2 (high-risk) PRs, which are parked for a human merge; --supervised stops with every PR open fo

• commit

  Stage and commit the working tree as one or more conventional commits, split by logical concern. Use when the user says 'commit this', 'save my work', 'check in the changes', or is ready to record progress in git before moving on. Local only: never pushes (use /wf:pr for that). Not for fixing a bug

• design

  Design a product's UI in Paper: a design system and brand guide (docs/design/DESIGN_SYSTEM.md plus Paper artboards), then light and dark screens for each flow, grounded in the PRD and specs. Use when the user asks to mock up or design screens, make a design system or brand guide, or mentions Paper /

• feature

  Implement a feature from a spec (docs/specs/NNN_<name>.md), a spec slice, or a GitHub issue: write the code and tests, run the checks, and stop with a working tree to review. --commit also commits; --pr also opens the PR and runs its review. Use for 'implement the auth spec', 'build feature X', 'cod

• fix

  Diagnose the root cause of a bug and fix it with a regression test, from a description, a stack trace or error output, or a GitHub issue link. Stops with a working tree to review. Use for 'fix this', 'this is broken', a pasted traceback, or an issue link where a patch is expected. For a feature use

• issues

  File GitHub milestones and issues from a roadmap, a phase file or a spec — one milestone per phase, one issue per task or slice — then write the issue numbers back into the docs so /wf:feature and /wf:autopilot can name branches and close issues. Safe to re-run: reconciles issues already filed. Use

• new-project

  Scaffold a new project directory for a chosen stack: git init, an AGENTS.md (plus a one-line CLAUDE.md importing it) with the real build and test commands, a Makefile with test and lint targets, a lint-on-edit hook, a .gitignore, secret scanning, a free GitHub Actions CI workflow and the docs/ skele

• pr

  Push the current branch and open a pull request with gh (commits must already exist). Use when the user says 'open a PR', 'push this up for review', 'ship this branch', or 'create a draft PR'. Opens a draft, has the fresh-context wf:reviewer review it, fixes HIGH/MED findings (max 2 rounds), then ma

• prd

  Interview the user and write a Product Requirements Document at docs/PRD.md (or docs/prd/<name>.md for a feature) — problem, scope, user types, key flows, success criteria, risks. Use when the user wants to write a PRD, scope a product or feature, capture requirements or success metrics, or says 'wh

• roadmap

  Turn the PRD and architecture into a phased delivery plan: docs/roadmap/README.md plus one numbered phase file per phase (docs/roadmap/NNN_<phase>.md), each with sized, ordered tasks that name their spec, flag, files and verification command. Use when the user wants to plan phases, sequence a build,

• spec

  Write the implementation spec for one feature or roadmap task at docs/specs/NNN_<feature>.md — problem, design, affected files, flag, and verification criteria with concrete inputs and outputs — and slice it into independently mergeable pieces when it is more than one concern. Use when the user says

• threat-model

  Create or update docs/THREAT_MODEL.md — a STRIDE-style design-level threat model with trust boundaries, attack surface, threats and mitigations. Use when the user asks for a threat model, an attack-surface analysis or a STRIDE pass, or says 'what could go wrong security-wise', 'identify the threats'

• verify-design

  Compare the running UI with its Paper artboards in a real browser (Playwright, desktop and mobile) and fix the mismatches in the code. Use when the user says 'verify the design', 'does this match Paper', 'check design fidelity', 'the UI drifted from the mock', or after building a page that has a Pap

Subagents (1)

• reviewer

  Fresh-context code reviewer for a branch or PR diff. Read-only — checks spec compliance, correctness, security at boundaries, and test quality, then returns a structured PASS / FIX_REQUIRED verdict. Dispatched by /wf:pr and /wf:autopilot after the writer has committed; never use it from the context

Hooks (1)

• PreToolUse

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/guard.sh"

Similar plugins