vibe

Plugin vibe from marketplace groundwork in Tradebaas/Groundwork. Commands read from the repo's manifest — 5 days ago.

Skills (13)

• architect

  Design the system before building it: module boundaries, data model, integration contracts, environments, threat model. Use after stack choice and before the first build session, and again when a change would cross or move a boundary. Produces docs/product/ARCHITECTURE.md and decision records.

• begin

  Lay the governance layer over a project, only when the owner asks for it: the interview (or the PRD, idea text or existing code as its input), BRIEF, STATE.md, the first decision, checks, CI and the first governed commit. Use when the owner says "begin", "nieuw project" or "adopt" for a client, gove

• code-review

  Review the diff of substantial work after `verify` and before the commit: Claude Code's bundled /code-review for the bugs, then a gate-weakening scan and fresh-eyes axes for standards and for spec plus commit-message fidelity, plus a security axis on auth, payments, PII, external input, crypto or up

• comply

  Compliance review against Dutch and EU law: GDPR/AVG, EU AI Act, accessibility (EAA/WCAG), NIS2, CRA, licensing. Use at project start (begin flags it), before first delivery, when new personal-data or AI processing is added, and at the quarterly audit. Verifies current rules against authoritative so

• debug

  Systematic debugging when a failure's cause is unknown: reproduce first, isolate, fix the root cause once, prove it with a regression test. Use when a bug, crash, failing test or wrong output has no obvious cause, when a fix attempt did not work, or before claiming a stubborn bug fixed. For producti

• deliver

  Release, deploy, or hand over a milestone in a disciplined, repeatable way. Use when shipping to users, deploying to an environment, tagging a release, or closing out a milestone. Nothing ships that verify hasn't passed.

• design

  Stand up the design system and the voice, then make interfaces and user-facing output that look and sound like nobody's default. Use after the stack choice and before the first UI work, when the owner wants the look or the voice defined or changed, and before delivering anything a user sees (a scree

• maintain

  Keep a shipped product healthy: monitoring, updates, incidents, debt, periodic audits, retirement. Use after first production release, on a maintenance session, when dependencies need updating, when something broke in production, to harvest defer: markers into the debt ledger, or when a product, env

• scope

  Define, sharpen, or change project scope, and triage docs/state/INTAKE.md. Use when scope is unclear or contested, when new wishes/feedback arrive, when the owner asks for "more" mid-build, or when work doesn't trace to BRIEF.md. Scope changes only happen here, never silently during a build task.

• spec

  Right-size and write the spec before building any change. Use before starting non-trivial work, when the user requests a feature, or when deciding whether something needs a spec at all. Prevents both drift (building unspecified things) and ceremony (specs for bugfixes).

• stack

  Choose the tech stack or target platform (own servers, Power Platform, ServiceNow, Salesforce, Google, whatever exists by then) and make the project idiomatic for it: docs/standards/<stack>.md and the stack's own gates in CI and hooks. Use when the platform must be decided or those gates wired. Live

• start

  Open a work session the cheap way: read the handoff, pin the ticket, and pick the session shape (plan mode, goal, loop, routine, advisor, subagent, model) from one table so the owner never has to. Run as the first command of a session with /vibe:start, or when the owner asks which Claude feature to

• verify

  Prove a change actually works before it counts as done. Use after building any non-trivial change, before deliver, and whenever claiming something works. Predicts per acceptance criterion, runs the change end to end through Claude Code's bundled /verify, names what could not be verified, and records

Subagents (3)

• review-fidelity

  Axis B of a code review: does the diff do exactly what the spec says, no less and no more, and does the commit message describe the diff that is there. Spawned by the code-review skill with the diff, the spec and the message as its only inputs.

• review-security

  Axis C of a code review, only when the diff touches auth, payments, personal data, external input, crypto or uploads: does it hold the security floor and avoid the classic breaks. Spawned by the code-review skill with the diff and the floor as its only inputs.

• review-standards

  Axis A of a code review: does the diff meet the written standards and is it free of the classic smells. Spawned by the code-review skill with the diff and the standards files as its only inputs; returns findings by severity.

Hooks (2)

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/checks/guard.mjs"

• SessionStart

  [ -f "$CLAUDE_PROJECT_DIR/docs/state/STATE.md" ] && sed -n '/^## Handoff/,/^## Log/p' "$CLAUDE_PROJECT_DIR/docs/state/STATE.md" || true

Similar plugins