# Building your own
The built-in packs get you running. Your **own** pack is where Valdr starts to compound — because it encodes the one thing no shipped pack can: how *your* team actually works.

Every serious AI workflow accretes the same scaffolding — a `CLAUDE.md` you keep editing, a folder of prompts you paste, review checklists, conventions you re-explain every session. It grows one frustration at a time, and you end up as the integration layer holding it together. A pack is where that scaffolding stops being something you maintain by hand and becomes infrastructure your agents load on demand.

## Why build your own pack

The built-in orchestrators and workflow agents are deliberately general. They know how Valdr works; they don't know your codebase conventions, your review bar, your release ritual, or the bug that always hides in the same seam. That knowledge is the expensive part — and right now it probably lives in your head, your chat history, and a pile of loose files.

Building your own pack turns that into a real artifact:

- **Encode it once, reuse it everywhere.** A correction you make twice becomes a capability. An orchestration step you do by hand three times becomes a workflow. Stop re-explaining — attach it.
- **Stop starting from zero.** Your agents inherit your conventions and review standards at launch instead of relearning them every session.
- **Make it portable.** Pack files are plain YAML and Markdown — version them in git, review changes like code, and share consistent agent behavior with the teams you work with. The same pack behaves the same on every machine.
- **Compose instead of copy-paste.** Write a capability once and attach it to many agents; it loads on demand based on intent, instead of being pasted into three prompts that quietly drift apart.

> Orchestration overhead doesn't compound — it just costs. A pack is how you turn that cost into leverage.

## You're already building this

If you use CLI agents or IDE copilots seriously, you're already assembling the pieces a pack is made of — agents, prompts, capabilities, workflows — scattered across skill files, `AGENTS.md`, prompt directories, and hand-rolled scripts. The primitives are inevitable. The only real question is whether they cohere into a system you can compose, or accrete as config you have to maintain.

Building a pack is choosing the first one — without spending six months getting there by hand.

## Start small

You don't design a pack up front. You grow one.

{{% steps %}}

### Port what you already have

Take your best prompt, your sharpest review checklist, your most-repeated convention, and write it as a capability — same content, in a form the system can reason about.

You don't have to do this by hand. Point **Nikol** at the scaffolding you've already built — skill files, a prompt directory, your `CLAUDE.md` or `AGENTS.md` — and let it port them into pack capabilities and prompts, collapsing duplicates as it goes:

```text
/valdr-orchestrator
Use nikol to port my .claude/skills and prompts/ directory into pack capabilities and prompts, and flag any duplicates to merge.
```

Nikol reads what you have, proposes the right capability and prompt boundaries, and writes the pack files for you to review and import. Porting same-content, different-form is the lowest-risk first move — it turns a pile of loose skills and prompts into reusable units you can compose, without redesigning anything yet.

### Let the duplicates surface

Patterns you've been pasting in three places collapse into one shared capability. The mess shrinks not because you deleted anything, but because you can finally compose.

### Add a frontier at a time

When a behavior earns its keep twice, give it a durable home — a capability, a prompt, or a new agent. The roster grows as a side effect of refusing to do the same thing twice.

### Keep the files as the source of truth

Edit the pack source, validate, regenerate, re-import. Your operating model improves in version control, not in chat history that scrolls away.

{{% /steps %}}

[Team capabilities](../what-comes-with-valdr/team-capabilities/) is the fastest first win: encode your codebase conventions and tribal knowledge so every agent inherits them.

## The fast path: let Nikol build it

You don't have to hand-write YAML and Markdown. **Nikol**, the registry orchestrator, is built to author packs for you: describe the behavior you want, and it inspects your registry, picks the right boundaries, and drafts the manifest, agents, capabilities, and prompts as real files you review and import. Minimal manual work — a working pack fast.

The [Authoring workflow](./workflow/) covers both the Nikol-driven path and the manual format underneath.

> **Local-first:** Valdr runs entirely on your machine. Pack source, agents, capabilities, prompts, and history live in your local workspace and remain until you delete them. Packs are the one thing built to travel — as files you choose to share.

## Build your own

{{< cards >}}
  {{< card link="./workflow/" title="Authoring workflow" subtitle="Author with Nikol or by hand: build, validate, generate, and import packs" icon="adjustments" >}}
  {{< card link="./prompt-ordering/" title="Prompt ordering" subtitle="How system prompts are composed from capabilities" icon="clipboard-list" >}}
  {{< card link="../what-comes-with-valdr/starter-packs/nikol/" title="Nikol orchestrator" subtitle="Let the registry orchestrator scaffold your pack for you" icon="server" >}}
  {{< card link="../what-comes-with-valdr/team-capabilities/" title="Team capabilities" subtitle="Encode your codebase conventions and tribal knowledge" icon="user-group" >}}
{{< /cards >}}

## Next steps

- **Start your first pack** — open [Nikol](../what-comes-with-valdr/starter-packs/nikol/) and have it scaffold a pack from a behavior you keep repeating.
- **See the format** — the [Authoring workflow](./workflow/) walks the full source-to-import path.
- **Understand composition** — [Prompt ordering](./prompt-ordering/) shows how capabilities become predictable system prompts.