# Shape Capability

> Use when a project-authorized structural Rust architecture claim cannot be expressed by the supported Tianheng observation surface, or when forge-law, amend-law, or review-law reports capability pressure; verifies that the gap is real, designs a bounded observation and reaction contract with feasibility evidence, and produces an upstream-ready capability pressure without writing pretend adopter law. Do not use when an existing recipe fits, the claim is non-structural or cross-language, compatibility is merely unknown, the user asks to implement Tianheng itself, or no concrete observation source exists.

- Skill: `tacticaldoll/shape-capability` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add tacticaldoll/shape-capability`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tacticaldoll/shape-capability/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tacticaldoll (https://skillmd.com/u/tacticaldoll)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tacticaldoll/shape-capability

---


# Shape Tianheng Capability

Turn a demonstrated observation gap into a bounded upstream capability candidate. Preserve the
adopter's intent as evidence; do not grant the missing reaction imaginary teeth.

## Load References Deliberately

- Read [gap-classification.md](references/gap-classification.md) before declaring a capability gap.
- Read [observation-contract.md](references/observation-contract.md) when shaping the measure and
  reaction.
- Read [feasibility-and-risk.md](references/feasibility-and-risk.md) before recommending upstream
  work.
- Read [upstream-handoff.md](references/upstream-handoff.md) before persisting or routing the
  candidate.

These references target Tianheng `0.5.x`. Inspect the adopter's resolved version and Tianheng's
actual public surface before concluding that an observation is absent.

## Phase 0: Gate Capability Pressure

Require:

- a discovered Cargo workspace;
- existing Tianheng use or an explicit adoption effort;
- an exact project-authorized structural claim;
- the contradiction that should react; and
- evidence that a supported Tianheng recipe was considered and rejected honestly.

In a mixed-language repository, narrow the claim to its Rust-observable portion. A constraint whose
meaning depends on non-Rust code is not automatically a Tianheng capability gap.

Do not write adopter Constitution code, placeholder modules, baselines, or generated projection
during this workflow.

## Phase 1: Prove The Gap Is Real

Use `gap-classification.md`.

1. Resolve the adopter's Tianheng version from Cargo metadata or lockfile.
2. Inspect that version's public boundary surface, docs, recipe index, and relevant source.
3. Restate the claim as one contradicted structural fact.
4. Test whether an existing static, semantic, runtime, or composed observation already sees it.
5. Record why the nearest recipes fail without overstating their non-observations.

Classify:

- `EXISTING_RECIPE`: route back to `forge-law`;
- `COMPATIBILITY_UNKNOWN`: investigate the resolved/newer Tianheng line first;
- `NON_STRUCTURAL`: keep the claim in process, judgment, history, or API prose;
- `CROSS_LANGUAGE`: narrow to Rust or route to another governance system;
- `TRUE_GAP`: continue.

Do not name a new boundary merely because no remembered recipe comes to mind.

## Phase 2: Preserve Intent Authority

Cite the exact direct instruction or durable project claim. Separate:

- the adopter's authority to state its architectural intent;
- evidence that current Tianheng cannot observe it; and
- upstream Tianheng authority to accept a new public capability.

The first two justify capability pressure, not upstream acceptance. Generic best practice and
repository shape remain insufficient.

## Phase 3: Design The Observation Contract

Use `observation-contract.md`. Produce:

```markdown
## Observation Contract

**Intent authority**: <source>
**Governed target**: <crate, module, type seam, or runtime seam>
**Contradicting fact**: <one concrete fact>
**Observation source**: <Cargo metadata | Rust source tokens | syn AST | runtime probe>
**Observation owner**: <static | semantic | runtime | shared core>
**Scan perimeter**: <anchor and depth>
**Finding identity**: <stable target, rule key, structured fact>
**Actionable location**: <derivable file or faithful null>
**Repair polarity**: <deny_breach | allowlist_gap | null>
**Reason perimeter**: <what a future reason may honestly claim>
**Non-observations**: <important exclusions>
```

One pressure candidate describes one observation family. Split claims that require unrelated
sources or repair directions.

## Phase 4: Pressure-Test Feasibility

Use `feasibility-and-risk.md`. Determine:

- whether the source is available without executing arbitrary project code;
- whether facts can be canonicalized across formatting and aliases;
- whether target/rule/fact identity remains stable across diagnostic wording changes;
- whether an actionable file is a faithful byproduct rather than guessed;
- false-positive and false-negative boundaries;
- macro, conditional compilation, workspace, and platform limits;
- likely scan cost and cacheability; and
- whether the capability belongs in an existing dimension.

No concrete source or no honest precision boundary means `DEFER_OBSERVATION`, not a speculative API.
Do not pre-create a crate or dimension to hold a future idea.

## Phase 5: Specify The Reaction Proof

Design upstream-ready scenarios before API shape:

- one positive fixture containing the exact contradicting fact;
- one clean adjacent fixture that must not react;
- target/depth edge cases;
- identity stability under presentation-only changes;
- severity, baseline, and composed exit behavior;
- JSON projection fields including file/polarity when applicable; and
- constitution/scan error directions for invalid targets or unsupported source states.

State expected exit `0`, `1`, or `2` explicitly. A possible parser implementation is not evidence
that the reaction contract is coherent.

## Phase 6: Form The Capability Pressure

Return:

```markdown
## Tianheng Capability Pressure

**Gap verdict**: TRUE_GAP
**Adopter evidence**: <claim and affected code>
**Nearest existing capability**: <recipe and exact mismatch>
**Observation contract**: <bounded measure>
**Reaction contract**: <target, rule, identity, severity, baseline, projection>
**Fixture matrix**: <positive, precision, error, composition>
**Feasibility**: <source, cost, limitations>
**Compatibility effect**: <public API / projection / baseline implications>
**Upstream owner**: Tianheng maintainers; candidate not accepted or implemented.
```

If the classification stops earlier, report `ROUTE_FORGE`, `COMPATIBILITY_REQUIRED`,
`DOCUMENT_ONLY`, `CROSS_LANGUAGE`, `DEFER_OBSERVATION`, or `DEFER_FEASIBILITY`.

## Phase 7: Hand Off Upstream Deliberately

Follow `upstream-handoff.md`. By default, leave the pressure as a reviewable report. When the user
explicitly asks to persist it in a Tianheng checkout, follow that repository's current governance
and proposal workflow. Do not implement the capability, edit Tianheng law, open a remote issue, or
publish anything unless separately requested and authorized.

## Hard Stops

- Do not declare a gap without inspecting the resolved supported Tianheng surface.
- Do not turn non-structural or cross-language intent into a Rust observation.
- Do not invent policy authority from code shape or best practice.
- Do not name a target, rule, boundary, or dimension without a concrete observation source.
- Do not claim precision without a clean adjacent fixture.
- Do not copy Tianheng's cookbook or pre-design an entire public API.
- Do not write a no-op adopter boundary, warning-only substitute, or permanent baseline.
- Do not implement or submit upstream changes as part of capability shaping.