Skip to Content
Learn

How Dotpack Works

Dotpack makes you faster by providing a prebuilt “pack” of workflows and expertise for your codebase:

  • Commands: the workflows you run (/build, @fix)
  • Agents: the specialists that execute the workflow (planner, engineer, QA, reviewer)
  • Skills: stack-aware conventions that shape output automatically

Core concepts: Commands vs Agents vs Skills

ConceptWhat it isHow you use itWhere it lives
CommandsNamed workflows (the “thing you run”)You invoke explicitly (/build, @fix).dotpack/commands/
AgentsSpecialized roles (the “who does the work”)Selected by the workflow (or referenced by name).dotpack/agents/
SkillsStack knowledge + conventions (the “how it should be done”)Activates from context (files/frameworks).dotpack/skills/

How commands produce outcomes

A typical “build” workflow looks like:

  1. Plan the work
  2. Implement changes
  3. Add/adjust tests when relevant
  4. Review and verify

The point is to ship working changes with less back-and-forth.

What ships by default (keep this factual)

  • Start here: /build, /fix, /plan
  • Common agent roles: Planner, Engineer, QA, Reviewer
  • Common skills: conventions for frameworks/tools you’re using (e.g. Next.js/React/TypeScript/Tailwind)

The mechanism (supporting detail)

Dotpack keeps these workflows consistent across tools by generating tool-specific outputs from a single source:

  1. Source (.dotpack/): where commands/agents/skills live
  2. Build (dotpack build): generates tool configs
  3. Execution: you run commands in your AI tool

Source vs generated files

Edit these:

.dotpack/
├── commands/
├── agents/
└── skills/

Don’t hand-edit these (regenerate instead):

.gemini/
.cursor/
.claude/

Regenerating output

dotpack build

What to commit

  • Solo: commit everything or just .dotpack/ (either works)
  • Team: commit .dotpack/ always; commit generated outputs if not everyone installs the CLI
Last updated on
QuickstartUsing Commands