# Example manifest: claude-code

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | cap-protocol |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | CAP agent manifest for claude-code |
| Source URL | https://github.com/rsclaw-ai/cap-protocol/blob/main/examples/claude-code.toml |
| Source type | example config |
| Source date (published) | Unknown, not stated (repo living file) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct raw-file fetch, read in full (57 lines) |
| Confidence | High |
| Status | Active |

## Summary

The canonical full manifest: probe via `--version`, stream-json fast-path, PTY fallback with `❯`/`>` idle patterns, `◉ tool(args)` tool-call patterns, yes/no + select prompts, error lines, full capabilities, metered cost.

## Key findings

- `stream_json = ["claude", "-p", "--input-format=stream-json", "--output-format=stream-json"]` is the reference fast-path shape tai's stream-json driver must spawn.
- Uses `(?P<tool>...)` named groups in tool patterns, again contradicting the §5.4 ERE-only rule (third occurrence: spec example, claude manifest, openclaude manifest).
- `cost.metered = true`: drivers MUST surface `cap.usage` for this agent.

## Pros / strengths

- The one manifest exercising every section; ideal fixture for tai's manifest parser tests.

## Cons / limitations / caveats

- Example, not normative; `version_match`/`probe` shapes may not match real claude releases.

## Relevance to tai

Becomes a parser test fixture and the template for tai's own `--cap-manifest` output shape.

## Changelog

| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |