Skip to main content

​
Contributor Skills

This repository carries local skills to keep agent-driven work aligned with the same standards expected from human contributors. The goal is not automation for its own sake. The goal is to preserve:
  • narrow reviewable change sets
  • truthful docs
  • deliberate semver
  • clean worktree isolation

​
Current repo-local skills

​
gb-worktree-feature-flow

Use this when a change should move into its own branch and checkout. It standardizes:
  • one worktree per coherent concern
  • one branch per worktree
  • reviewable slices instead of stacked unrelated edits
Default entrypoint:

​
gb-oss-release-discipline

Use this when a change touches:
  • package.json versioning
  • release tags
  • contributor docs
  • public-facing repo hygiene
It enforces the split between:
  • semver as release identity
  • buildVersion as runtime deployment identity
It also standardizes post-push CI discipline:
  • check recent GitHub Actions runs with gh
  • read out failed jobs or steps instead of only saying CI failed
  • propose the next fix when a workflow is red

​
next-forge

Use this when a task touches monorepo structure, shared package ownership, design-system work, Storybook, feature flags, or deployment conventions inherited from the template. In this repo, it should be read as a structural reference, not a command to activate every dormant scaffold surface. The active workspace boundary in README.md remains the source of truth. It standardizes:
  • self-contained apps and shared packages
  • Storybook as the review surface for shared UI
  • packages/design-system as the only supported shadcn CLI target in this repo
  • pnpm dlx shadcn@latest info -c packages/design-system --json before shared UI work
  • radix-nova plus olive semantic tokens as the current shared UI baseline
  • Mintlify as a first-class docs surface
  • boundary-aware structural changes
  • maintenance commands such as pnpm boundaries, pnpm bump-deps, and pnpm bump-ui
  • dependency maintenance as a dedicated root-level slice rather than scattered package-by-package updates
  • Biome via pnpm lint and pnpm format as the repo formatting/lint path
  • pnpm build:tracked <target> and pnpm typecheck:tracked <target> for long-running Storybook, Next.js, and validation tasks
  • @repo/database as the only supported data-plane boundary
  • @repo/auth as the only supported Supabase auth/session boundary
  • no app-level direct @supabase/supabase-js data access without an explicit boundary change

​
gb-linear-execution

Use this when a task touches roadmap organization, project planning, issue slicing, milestones, or Linear sync. It standardizes:
  • planning/linear/* as the canonical planning pack
  • initiatives, projects, milestones, and issues instead of parallel roadmap docs
  • pnpm linear:sync for preview and pnpm linear:sync:apply for import
  • the current Linear workspace shape anchored on the GB team
  • creation or update of a Linear issue when implementation work uncovers a substantial blocker, parity gap, or architectural gap

​
Repository fit

These skills are intentionally shaped around the same repository posture used in gb-travio-webhooks, while preserving the structural discipline inherited from next-forge:
  • direct documentation
  • small PRs
  • repo-led deployment
  • explicit operational behavior
  • clear app/package boundaries
  • first-class docs and Storybook surfaces

​
Adding more skills

When adding a new skill for this repo:
  1. keep the scope narrow
  2. write the skill around a repeated workflow, not a one-off task
  3. point to existing docs instead of duplicating them
  4. add metadata so future sessions can discover it quickly

​
Current locations

  • .agents/skills/shadcn
  • skills/gb-worktree-feature-flow
  • skills/gb-oss-release-discipline
  • skills/gb-linear-execution
  • skills/next-forge