measure
Skill6 starsChanged 14 days agoApache-2.0View on GitHub
Quantify values with uncertainty bounds. Use when estimating metrics, calculating risk scores, assessing magnitude, or measuring any quantifiable property.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- BSSE23047/nauraiz-devtheir own version, first seen Nov 8, 2026
- ZoolCoder/findabletheir own version, first seen Nov 1, 2026
- dososo/blcaptain-measure-cjktheir own version, first seen Nov 1, 2026
- vivekschaudhary/compasstheir own version, first seen Oct 25, 2026
- link7373/agentic-sales-marketingtheir own version, first seen Aug 8, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- dososo/blcaptain-measure-cjk★ 18same name
- BSSE23047/nauraiz-dev★ 2same name
- vivekschaudhary/compass★ 2same name
- link7373/agentic-sales-marketing★ 1same name
- ZoolCoder/findable★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- attributeSkill
- auditSkill
- gap-analysis-workflowSkill
- checkpointSkill
- classifySkill
- compareSkill
- constrainSkill
- critiqueSkill
- debug-workflowSkill
- decomposeSkill
- delegateSkill
- detectSkill
- digital-twin-bootstrapSkill
- digital-twin-sync-workflowSkill
- discover-capabilitiesSkill
- discoverSkill
- executeSkill
- explainSkill
- generateSkill
- groundSkill
- inquireSkill
- integrateSkill
- invokeSkill
- mutateSkill
- observeSkill
- persistSkill
- perspective-validationSkill
- planSkill
- predictSkill
- recallSkill
- receiveSkill
- retrieveSkill
- rollbackSkill
- searchSkill
- sendSkill
- simulateSkill
- stateSkill
- synchronizeSkill
- transformSkill
- transitionSkill
- verifySkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 44
Read relevant files, logs, or data sources
- Distinctive: line 49
Use appropriate calculation for the metric type
- Distinctive: line 56
Consider data quality, method limitations
- Distinctive: line 59
Ground the measurement: Document evidence and method
- Distinctive: line 180
Verification tools: Read (to verify measurement inputs)
- Distinctive: line 190
Always provide uncertainty bounds, never claim false precision
- Distinctive: line 191
Document measurement methodology for reproducibility
- Distinctive: line 193
Do not extrapolate beyond available data without noting assumptions
- Very specific: line 208
Never use measure for binary detection (use detect)
- Very specific: line 209
Avoid measure for categorical assessment (use classify)
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Intent
Quantify a specific metric for a target, providing a numerical value with explicit uncertainty bounds. This capability consolidates all estimation tasks (risk, impact, effort, etc.) into a single parameterized operation.
Success criteria:
- Numerical value provided for requested metric
- Uncertainty bounds explicitly stated
- Measurement method documented
- Units clearly specified
Compatible schemas:
schemas/output_schema.yaml
Inputs
| Parameter | Required | Type | Description |
target | Yes | any | What to measure (system, code, entity, process) |
metric | Yes | string | The metric to quantify (risk, complexity, effort, size, etc.) |
unit | No | string | Unit of measurement (optional, inferred if not provided) |
Inputs not listed here are outside the capability's contract: a workflow step that binds them gets W604 (STANDARD v1.1 §5.5).
Procedure
- Define the metric: Clarify exactly what is being measured
- Establish clear definition of the metric
- Identify appropriate unit of measurement
- Determine measurement methodology
- Gather measurement inputs: Collect data needed for measurement
- Read relevant files, logs, or data sources
- Identify quantifiable indicators
- Note data quality and completeness
- Calculate measurement: Apply measurement method to inputs
- Use appropriate calculation for the metric type
- For risk: probability * impact assessment
- For complexity: cyclomatic, cognitive, or structural metrics
- For effort: decomposition and estimation techniques
- Establish uncertainty bounds: Quantify measurement confidence
- Calculate or estimate lower and upper bounds
- Consider data quality, method limitations
- Express as confidence interval or range
- Ground the measurement: Document evidence and method
- Reference specific data points used
- Note any assumptions in calculation
- Document measurement methodology
Output Contract
Return a structured object:
value: number # The measured value
uncertainty:
lower: number # Lower bound (confidence interval)
upper: number # Upper bound (confidence interval)
type: string # Type of uncertainty (confidence_interval, range, std_dev)
unit: string # Unit of measurement
metric: string # What was measured
method: string # How it was measured
breakdown: # Optional component breakdown
- component: string
value: number
confidence: 0..1 # Confidence in measurement accuracy
evidence_anchors: ["file:line", "data:source"]
assumptions: []Field Definitions
| Field | Type | Description |
value | number | Primary measurement value |
uncertainty | object | Bounds and type of uncertainty |
unit | string | Unit of measurement |
metric | string | Name of measured property |
method | string | Measurement methodology used |
breakdown | array | Optional decomposition of measurement |
confidence | number | 0.0-1.0 confidence in measurement accuracy |
evidence_anchors | array | References to the data the measurement was taken from |
assumptions | array | Explicit assumptions |
Examples
Example 1: Measure Code Complexity
Input:
target: "src/services/order_processor.rb"
metric: "complexity"
unit: "cyclomatic"Output:
value: 24
uncertainty:
lower: 22
upper: 26
type: "range"
unit: "cyclomatic complexity"
metric: "complexity"
method: "counted decision points (if, case, loops, &&, ||)"
breakdown:
- component: "process_order method"
value: 12
- component: "validate_items method"
value: 8
- component: "calculate_totals method"
value: 4
confidence: 0.9
evidence_anchors:
- "src/services/order_processor.rb:15-120"
assumptions:
- "Ruby control flow statements counted as decision points"
- "Exception handling counted as branches"Example 2: Measure Risk
Input:
target: "database migration: add user_preferences column"
metric: "risk"Output:
value: 0.35
uncertainty:
lower: 0.25
upper: 0.50
type: "confidence_interval_90"
unit: "risk score (0-1)"
metric: "risk"
method: "probability (0.5) * impact (0.7) normalized"
breakdown:
- component: "probability_of_failure"
value: 0.5
- component: "impact_if_failed"
value: 0.7
- component: "data_loss_risk"
value: 0.2
- component: "downtime_risk"
value: 0.4
confidence: 0.7
evidence_anchors:
- "migrations/20240115_add_preferences.rb:1-25"
- "tool:grep:similar_migrations"
assumptions:
- "Table has ~1M rows based on user count"
- "Migration will lock table during ALTER"
- "No concurrent deployments during migration"Verification
- Numerical value provided
- Uncertainty bounds are reasonable (lower < value < upper)
- Unit of measurement specified
- Method documented
- Evidence anchors reference measurement inputs
Verification tools: Read (to verify measurement inputs)
Safety Constraints
mutation: falserequires_checkpoint: falserequires_approval: falserisk: low
Capability-specific rules:
- Always provide uncertainty bounds, never claim false precision
- Document measurement methodology for reproducibility
- Flag when data is insufficient for reliable measurement
- Do not extrapolate beyond available data without noting assumptions
Composition Patterns
Commonly follows:
observe- Measure properties of observed statedetect- Measure characteristics of detected itemsretrieve- Measure retrieved data
Commonly precedes:
predict- Measurements feed into predictionscompare- Measurements enable quantitative comparisonplan- Measurements inform risk-aware planning
Anti-patterns:
- Never use measure for binary detection (use
detect) - Avoid measure for categorical assessment (use
classify)
Workflow references:
- See
reference/workflow_catalog.yaml#digital_twin_sync_loopfor risk measurement
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

