Author a shaped slice's measure lens as an MD grounding doc — the delivery-measurement focus, a table of metrics (metric / baseline / target / proof, triangle-primary speed/tokens/cognition), and what is out of scope — from the slice's hub (its functionalities' grounding docs + the spine profile). Every metric is concrete (a baseline, a target, a proof), never a vague claim. Writes measure.md STRAIGHT to the live model (per-node doc only, conforming to the Measure lens template) and emits the...
Scanned 9/10/2026
Install to Claude Code
npx -y skills add kapilvirenahuja/garura --skill author-measure-lens --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Author Measure Lens?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/kapilvirenahuja-author-measure-lens)More formats (shields.io, HTML) on the badges page.
---
name: author-measure-lens
description: Author a shaped slice's measure lens as an MD grounding doc — the delivery-measurement focus, a table of metrics (metric / baseline / target / proof, triangle-primary speed/tokens/cognition), and what is out of scope — from the slice's hub (its functionalities' grounding docs + the spine profile). Every metric is concrete (a baseline, a target, a proof), never a vague claim. Writes measure.md STRAIGHT to the live model (per-node doc only, conforming to the Measure lens template) and emits the shared-file deltas — the grounding map, any material decision, and the doc record — as structured data in an STM measure-manifest.yaml; never writes _spine.yaml, the profile, or a decision record (the keyed persist writes the decisions and the lines-up-gated realized stamp). Generative artifact production for the /measure play.
version: 0.4.0
user-invocable: false
model: opus
allowed-tools: Read, Write, Bash, Glob
---
# author-measure-lens
Turns a shaped slice's **hub** — the grounding docs of the functionalities it bundles, plus the
product profile — into the slice's **measure lens**, written as the grounding doc `measure.md`: what
delivery the slice is proving, the metrics that prove it, and what is deliberately not measured. The
metrics are concrete (each a baseline, a target, and how it is proven), triangle-primary on
speed/tokens/cognition where it applies — never a vague claim. It reads the hub and writes the lens
doc in place on the live model; /measure's keyed persist then applies the shared-file deltas after the
checkpoint. This is the seam /learn later harvests.
## Write discipline (ADR 026, direct-model-write)
This skill writes ONLY the per-node grounding doc — the slice's `lens/measure.md` — **straight to the
live model** under `<product_base>/product-os/…`. It NEVER writes any shared model file: not
`_spine.yaml`, not the `profile` block, not a `decisions/` record. Every shared-file mutation is
emitted as **structured data in the STM `measure-manifest.yaml`** — the grounding map in
`measure.grounds`, any material choices in `measure.choices`, the material decision records in
`decisions:`, and the record of the doc it wrote in `docs:` — for /measure's deterministic keyed
persist (`persist_measure.py`) to apply in place after the human checkpoint. /measure runs the shape
linter and the content-quality eval over the live doc, then the scoped-write guard over the full
delta, before the checkpoint; nothing is committed until the gate resolves.
## What it produces (against the locked template)
`measure.md` (at its live path) conforms to `standards/schemas/product-os/grounding/lens/measure.md` —
H1 `# Measure Lens`, sections **Focus** (the one outcome whose movement tells you the slice worked),
**Metrics** (a table: metric | baseline | target | proof), and **Out of scope** (what is not measured
yet, with the reason). It must clear the linter (shape) and the content-quality eval (the play runs
both). Alongside it, the STM `measure-manifest.yaml` carries the machine-checkable grounding — which
functionality or profile outcome each metric traces to, any material choice, and the decision records
as structured data (the keyed persist writes the decision files).
## Inputs
| Field | Required | Description |
|-------|----------|-------------|
| `slice_ref` | yes | `{domain}/{slice-id}` — display reference. |
| `slice_file` | yes | Path to the live slice record (read-only — for the functionalities it bundles). |
| `functionality_groundings` | yes | Paths to each functionality's `functionality.md` grounding doc (the hub, resolved by `check_ready_slice`). Read these for the acceptance/outcomes — NOT `ice.yaml` (retired). |
| `profile` | yes | The product profile (from the spine) — its NFR gates and conditions. Read-only. |
| `product_base` | yes | Product model root — to READ the hub and reuse an existing material decision, and to WRITE the `measure.md` grounding doc in place under `product-os/…`. |
| `lens_rel` | yes | Relative path the lens mirrors (also its live path): `product-os/{domain}/slices/{slice}/lens/measure.md`. |
| `manifest_path` | yes | Output path under STM for the `measure-manifest.yaml` (grounds + choices + decision records + the doc record). |
| `proposals_dir` | no | STM folder for any `propose-kb-node` proposal a measurement frame needs when the KB does not cover it — each choice's `grounds` then references it. `/measure` runs `check_kb_grounding.py --proposals-dir` against this same folder. |
| `stm_base` | yes | From config. |
## Procedure
Reasoning (which metrics prove delivery, the baselines/targets, the proof) is yours. Template
conformance, grounding, and concreteness are non-negotiable.
1. **Read the hub.** Load each functionality's `functionality.md` (its acceptance criteria, behavior)
and the profile (its NFR gates + conditions). The functional lenses may inform the metrics if
present, but the hub is the anchor.
2. **State the focus.** What delivery this slice is proving in a short paragraph — the one outcome
whose movement tells you it worked.
3. **Derive the metrics.** Build the metric table: for each thing worth measuring, a baseline, a
target, and how it is proven. Triangle-primary (speed / tokens / cognition) where it applies. Each
metric traces to a functionality's acceptance or a profile outcome. Concrete numbers, not adjectives.
Ground every measurement-frame choice (the triangle, any industry translation) in the KB; for a
frame the KB does not cover, write a `propose-kb-node` proposal to `proposals_dir` and reference it
in that choice's `grounds` — never invent a frame.
4. **Name what's out of scope.** What this slice deliberately does not measure yet, each with its
reason — so a missing metric reads as a choice.
5. **Write the doc in place; emit the deltas as manifest data.** Write `measure.md` to its LIVE path
(`<product_base>/{lens_rel}`) per the template. Then write `measure-manifest.yaml` under STM: the
`measure.grounds` (the functionality or profile each metric traces to), `measure.choices` (any
material choice), the `decisions:` records (structured — the keyed persist writes the files), and
the `docs:` record of the doc you wrote. Write NO `_spine.yaml`, NO profile, NO decision file.
## Output — the live doc + the STM manifest
The `measure.md` grounding doc is written IN PLACE on the live model:
```
<product_base>/product-os/{domain}/slices/{slice}/lens/measure.md # the Measure lens grounding doc (live)
```
The `measure-manifest.yaml` is written under STM (a non-model artifact) — the shared-file deltas as
structured data:
```yaml
measure:
slice_ref: token-dash/slice-trusted-coverage
grounds: # every metric traces to a functionality or profile outcome
- { source_type: functionality, source: "func-source-coverage-freshness", functionality_ref: func-source-coverage-freshness }
- { source_type: profile, source: "nfr.performance" }
choices: [] # material measurement choices (each → a decision), if any
docs: # the per-node docs written in place on the live model
- { rel: "product-os/token-dash/slices/slice-trusted-coverage/lens/measure.md" }
decisions: [] # material decision records (structured); keyed persist writes each file
# - { id: dec-measure-..., rel: "product-os/token-dash/slices/slice-trusted-coverage/decisions/dec-measure-....yaml",
# level: product, title: "...", reason: "...", alternatives: [...] }
```
Return the enriched contract with the live `measure.md` path and the `measure-manifest.yaml` path —
paths, never inline content.
## Rules
- **Hub-anchored.** Derive from the functionalities' grounding docs + the profile; the metrics measure
what the slice actually delivers.
- **Template-true.** `measure.md` conforms to the Measure lens template (Focus / Metrics / Out of
scope) and must clear the linter + the content eval — every item self-explaining.
- **Concrete.** Every metric has a baseline, a target, and a proof — never a vague claim. A metric
that cannot be proven is not a metric.
- **Cover the hub.** The metrics consider every functionality the slice bundles, recorded in the
manifest grounds.
- **Per-node doc to live; shared files as manifest data.** Write ONLY `measure.md` in place on the
live model; emit the grounds, choices, decision records, and the doc record into
`measure-manifest.yaml`. Never write `_spine.yaml`, the profile, or a decision file — the keyed
persist owns every shared file (ADR 026).
```
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!