Capabilities

Generic AI agents are impressive demos. Then you ask them to work with your codebase. They don’t know your custom component library exists. They use <select> instead of your CustomDropdown. They ignore your API conventions, naming patterns, and the architectural decisions that took your team years to establish.

Capabilities fix this permanently. Encode what your team knows into prompts that agents always follow. No more repeating “use our custom dropdown” in every conversation. No more fixing the same mistakes in review. Your institutional knowledge becomes agent infrastructure.

156 capabilities across 6 roles — your accumulated expertise, catalogued and enforced

What this section covers

• Capability List — Browse, filter, and search your capability registry
• Capability Detail — View definitions, prompt bindings, and agent assignments

Why capabilities matter

The problem with context-free agents

Every time you start a CLI session with Claude, Cursor, or any other AI coding assistant, you start from zero. The agent doesn’t know:

• Your custom component library exists
• That all dropdowns should use CustomDropdown, not native <select>
• Your API conventions, naming patterns, or architectural decisions
• The tribal knowledge your team repeats in every code review

You re-explain the same context. Fix the same mistakes. The knowledge lives in your head, not in the agent.

The Valdr difference

Capabilities persist. When you encode “always use our CustomDropdown” as a capability and assign it to your TypeScript agent, that knowledge survives every session. The agent knows before you ask.

The compound effect

Every capability you encode:

• Saves time on every future session
• Reduces review burden
• Improves consistency
• Captures knowledge that might otherwise be lost

Over time, you build a capability library that makes agents genuinely productive—not just impressive demos.

The capability layering model

Capabilities are designed to stack. Start with a generic foundation, then add team-specific overlays that encode your institutional knowledge.

┌─────────────────────────────────────────────┐
│  Team-specific capability                   │
│  "Always use custom-dropdown.tsx"           │
│  "Follow our API naming conventions"        │
├─────────────────────────────────────────────┤
│  Domain capability                          │
│  "TypeScript best practices"                │
│  "React component patterns"                 │
├─────────────────────────────────────────────┤
│  Base capability                            │
│  "Code review standards"                    │
│  "Testing requirements"                     │
└─────────────────────────────────────────────┘

Each layer adds specificity without replacing what’s below. The agent inherits general best practices and your team’s specific conventions.

Capabilities are applied deterministically based on their keys. See Prompt Ordering to understand how capability keys control instruction order.

Anatomy of a capability

Every capability has three components:

When you assign a capability to an agent, the agent receives the bound prompt as part of its system context. The instructions become part of who the agent is.

Example: TypeScript testing capability

Here’s what a real capability looks like:

# Capability: typescript.testing

You are the TypeScript testing specialist who designs high-signal
unit, integration, and contract tests so code stays deterministic
and regression-safe.

## Instructions

- Target ≥90% coverage on new or modified modules
- Use Vitest with deterministic data builders
- Guard against regressions by reproducing bugs with tests before patching
- Run tests before handoff and capture evidence in task comments

Assign this capability to your TypeScript agent, and it always follows these testing standards. No prompting required.

What to encode in capabilities

Codebase conventions

• Component libraries and when to use each component
• API patterns (REST conventions, error handling, pagination)
• File/folder structure expectations
• Naming conventions (variables, files, routes)

Architectural decisions

• State management patterns (Redux, Zustand, context usage)
• Data fetching strategies (React Query, SWR, custom hooks)
• Error boundary placement
• Feature flag conventions

Quality standards

• Testing requirements specific to your stack
• Accessibility standards beyond WCAG defaults
• Performance budgets and optimization patterns
• Security practices for your domain

Tribal knowledge

• “We tried X approach and it failed because Y”
• “Always check Z before deploying to production”
• “The legacy module requires special handling”
• Undocumented but critical integration points

Get started in 60 seconds

Local-first storage

Capabilities live in your local workspace. They persist across sessions and survive agent restarts—but they’re stored on your machine, not in the cloud. You control your capability library.

Next steps

Start building your capability library today. Audit your last 10 agent sessions—what context did you repeat? Pick one high-frequency pain point and encode it as a capability. That’s how institutional knowledge becomes agent infrastructure.