Skip to content
Back to skills

Author Measure Lens

ASecurity

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...

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 10, 2026
toolsrustgobashnodeperformance

Security analysis

A100/100

Scanned September 10, 2026

npx -y skills add kapilvirenahuja/garura --skill author-measure-lens --agent claude-code

Installs 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 with every re-scan.

Security grade badge for Author Measure Lens
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/kapilvirenahuja-author-measure-lens/badge)](https://www.skillsdirectory.com/skills/kapilvirenahuja-author-measure-lens)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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).
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…