Transformation Instructions

Objective and default scope

Transform PRDs, plans, applications, codebases, Storybook, OpenAPI, Arazzo workflow documents, MCP servers, skills, API documentation, schemas, tests, and runbooks into capability documentation without inventing product truth.

Extract mode defaults to a specific/operational CRD set. Create a generic/reusable projection only when it is requested or a second real consumer is established or clearly imminent. A generic capability with no known realization is a hypothesis, not demonstrated reuse.

Non-negotiable evidence discipline

1. Do not invent product facts, policies, ownership, outcomes, or implementation details.
2. Preserve uncertainty as unknown/unresolved.
3. Distinguish facts, inferences, defaults, examples, implementation choices, and operational constraints.
4. Do not derive a reusable CRD solely from one realization without marking realization-specific facts.
5. Do not infer a priority or conflict order between independently stated facts.
6. Preserve source hedges: “preferably,” “should,” and “recommended” are not binding rules unless the source explicitly says so.
7. Do not carry over terminology or facts from any other source, project, or prior work not included in the assigned material—including other work handled earlier in the same session. Prefer a fresh, isolated subagent over one that shares session history with unrelated extractions.
8. When extracting from a codebase or structured configuration, do not assert a machine-checkable fact (build-target membership, a called route) as confirmed unless traced directly to the specific file and line. Otherwise mark it unknown.
9. A declared type, enum case, or schema value with no code path that constructs or reaches it must not be presented as a live outcome—omit it or mark it “declared but reachability not confirmed.”

1. Inventory sources and preserve shared context

Record each source’s type, scope, version/date when known, and whether it describes intent, rules, interaction, implementation, operations, or evidence.

For a substantial source that produces multiple capabilities, create a Source Context Reference. It preserves product/system intent, cross-cutting constraints, client/platform exposure, build sequencing, and shared verification material that no single capability should own. It adds no binding requirements: a constraint that governs a capability must also appear in that capability’s CRD.

2. Identify, combine, and decompose

Find candidate capabilities and test each one independently: can it be understood and invoked meaningfully; can success or failure be determined; and would splitting it further lose its purpose context?

A candidate that only passes these questions because its actor is "a developer manually running this for pre-release verification" — with no recurring operational role and no exposure beyond that developer — is presumptively a tool or test scaffolding, not a capability, however well-documented and well-tested it is.

Before combining elements, run that test on every element individually, not just the merged result. Combine only when every element fails alone. If an element has its own actor, command, state, and result, it is likely its own Capability MLE. This is not discretionary once an element passes alone: split it out. Recording the check in the decision log and combining anyway does not satisfy the rule—disclosure is not compliance.

When a generic projection is authorized, treat “or otherwise,” “or similar,” “any,” and “etc.” as evidence checkpoints—not permission to broaden the source requirement.

When an Arazzo workflow document accompanies an OpenAPI (or other API) description, treat each declared workflow as a candidate-capability hypothesis and each step as candidate-contract evidence — not an automatic boundary. Still run the MLE test on the workflow as a whole; a step’s referenced operation is evidence for a tool, not a capability by itself. Most API sources have no Arazzo document — a raw OpenAPI spec alone needs the same combine/decompose work with less structural evidence.

3. Define contracts and diagrams

Actor + Command + Current State
  -- subject to Policies/Invariants -->
New State + Result + Events/Effects

Do not infer a transition, policy, or effect from a name alone. Mermaid diagrams are optional illustrative views: every state, edge, and relationship must already appear in the CRD text. A retained or historical state is not a terminal [*] exit unless the source explicitly says it is final.

4. Separate meaning from current reality

Put general purpose, boundaries, and reusable rules in the CRD. Put current deployment, exposure, code references, organizational rationale, ownership, and operational restrictions in an Operational Capability Realization. Record execution mode when known, and map shared components, skills, and tools without assuming they are capability equivalents. Add a universal tag only for a dimension no other field already settles. Pick the tag whose dimension the statement is actually about, not the nearest-sounding one — the most common mistake is reaching for network-touching whenever something involves an API call or a network-triggered side effect like a notification, when network-touching/local-only is only meaningful for a local-first/hybrid system where some capabilities genuinely differ on this; inside a uniformly hosted product every capability is network-touching by construction, so the tag adds nothing and notification-triggering (or data-sensitive, identity-related) is very likely the real dimension. Keep implementation-specific groupings as prefixed implementation tags (e.g. "impl:inbox") in the realization instead, so the two kinds are never mistaken for each other. In an HTML showcase, keep the visual tag/badge convention exclusive to implementation tags — a universal tag becomes a grouping/section key or plain text instead.

Required output

1. One CRD per identified Capability MLE.
2. A statement-provenance table.
3. A combine/decompose decision log, including each individual MLE check used before combining.
4. An unresolved-questions list.
5. Where applicable, shared-element/reuse, agentic mapping, and audience-projection material.
6. A Source Context Reference for a substantial multi-capability source.

Quality checks

Use the installable CRD Author skill →