Getting Started with Measured Skills

Update, September 23, 2026: This collection is now Measured Skills, maintained by Measured Studios. It was previously called JovaniPink Skills. The latest tagged release is still v0.16.0, which uses the old jovanipink-skills: names. The measured-skills: names apply to the 0.17.0 candidate on main, which has no release tag yet. The examples below give both forms. The migration guide explains how to switch. There are no compatibility aliases, so don't install both versions side by side.

Your coding assistant says the patch is complete and the tests passed. Before you merge, you want to know what that means. Which tests ran? Against which revision? Was anything left unchecked?

That is a useful first task for Measured Skills. I maintain this collection to give recurring work a more explicit process: check a claim, diagnose a failure, review a change, or preserve the information someone needs to continue. Start with one task you already recognize. You can explore the rest of the catalog after you have seen whether one workflow helps you inspect the work.

What you are installing#

A skill is a set of written instructions for a particular task. Its description helps an assistant decide when it applies; its full instructions explain how to approach the work. Some skills include linked notes that the assistant can read when needed.

A pack groups related skills for installation. You do not need every pack to try one workflow. The core pack, named jovanipink-skills in v0.16.0 and measured-skills in the 0.17.0 candidate, includes claim-verification, which asks the assistant to check completion claims against the evidence that could prove them.

The instructions do not independently grant permission to change files, merge code, or deploy a service. They also do not guarantee that an assistant will follow them. Your client's controls still govern its actions, and its response still needs checking.

Choose one pack and open a fresh task#

Use the maintained quickstart to select a reviewed release and install the core pack. Today that release is v0.16.0, the latest tag. Install the 0.17.0 candidate from main only if you want to try the new names before they are tagged. Follow the guide for your client: Codex, Claude Code, or Antigravity. Those pages carry the installation and update commands, so this article can concentrate on the first task. Antigravity is the exception to the tagged-release default: native Antigravity packs, including measured-skills, arrive with the 0.17.0 candidate, and v0.16.0 only builds a preview plugin from selected skills. To follow the current Antigravity guide, install the 0.17.0 candidate from main.

After installation, check your client's plugin list. Confirm that the core pack is present and enabled. Then open a fresh task. An existing conversation may retain earlier instructions, which makes it harder to tell what your new installation changed.

For this exercise, use the small evidence packet below. You do not need to connect a production system or let the assistant modify a repository.

Try a claim with incomplete evidence#

Everything in this packet is synthetic. The revisions, patch name, and test receipt are fictional teaching material, not captured client output or a report about this project.

Copy the entire packet into your fresh task:

Completion claim:
The retry fix is complete. Tests passed. It is ready to merge.
 
Evidence supplied for this exercise:
- Patch: retry-example.patch, preserved for review.
- Tested revision: revision A.
- Unit-test receipt at A: 12 tests passed, 0 failed.
- Required integration check: unavailable; it did not run.
- Receiving checkout: revision B.
- No comparison between A and B has been supplied.
- No test receipt for B has been supplied.
 
Authority:
Review this packet only. Do not modify files, apply the patch,
run commands, merge, or deploy. Do not treat these fictional
receipts as independently verified execution evidence.

Then select the skill explicitly, using the prefix for the version you installed. In Codex with v0.16.0, the tagged release, use:

$jovanipink-skills:claim-verification Check which completion claims
this synthetic packet supports. Keep failed or missing checks and
unfinished work visible. Review only; make no changes.

In Codex with the 0.17.0 candidate from main, use:

$measured-skills:claim-verification Check which completion claims
this synthetic packet supports. Keep failed or missing checks and
unfinished work visible. Review only; make no changes.

In Claude Code with v0.16.0, use:

/jovanipink-skills:claim-verification Check which completion claims
this synthetic packet supports. Keep failed or missing checks and
unfinished work visible. Review only; make no changes.

In Claude Code with the 0.17.0 candidate, use:

/measured-skills:claim-verification Check which completion claims
this synthetic packet supports. Keep failed or missing checks and
unfinished work visible. Review only; make no changes.

The $ and / prefixes are client invocation forms, and the pack name depends on the version you installed. Antigravity has packs only in the 0.17.0 candidate, where the expected form is also /measured-skills:claim-verification. That form has not yet been observed on Antigravity, so confirm that your client lists the skill before relying on it. All of them request the same workflow and the same bounded review.

Read the distinctions, not just the verdict#

A useful answer should preserve three facts. The packet reports passing unit tests at A. The required integration check never ran. The receiving checkout is B, and the packet supplies no evidence that the result at A applies there.

Those facts do not support an unqualified "ready to merge." They also do not erase the passing unit-test receipt. The assistant should identify the missing comparison and integration check as unfinished verification, while keeping its conclusion within the supplied fictional evidence.

This is an expected interpretation of the exercise, not a measured result from a client trial. If your assistant invents an integration result, treats B as tested, or starts applying the patch, the response has missed a material part of the task. Keep that failure visible when deciding whether to use the workflow again.

You can repeat the exercise with a real, non-sensitive task summary later. Supply actual receipts and authorize any additional reads explicitly. Do not substitute a polished summary for the underlying evidence you want checked.

Check whether the skill was used#

There are several separate questions to answer:

• Installed: does the client's inventory contain the intended pack?
• Enabled: can the client use it in this task?
• Selected: did the explicit invocation resolve to the intended skill?
• Loaded: does the client expose evidence that it read the instructions and any needed linked note?
• Followed: does the response preserve the evidence, missing checks, and limits of the request?

Use the inventory, invocation feedback, and visible execution details your client provides. A response with familiar headings is not independent proof that a file loaded. If loading is not observable, record that limit instead of inferring it from good prose.

The catalog record updated September 11, checked on September 12, reports checks covering fresh-session starts. Reliability later in a continued session remains unproved, and command-line observations do not establish app or IDE behavior. The 0.17.0 candidate record adds install-lifecycle checks on three command-line clients and Claude Code fresh-task checks from September 23. Codex and Antigravity fresh-task checks remain open. Treat this exercise as a focused trial, not a promise about every future task.

Choose the next recurring task#

Stay close to work you already do. Use claim-verification to inspect completion claims, systematic-diagnosis to investigate a failure before proposing a fix, or code-change-review to review a particular change. Check the selection guide before adding another pack.

The repository is the maintained starting point for setup and skill selection. For the reasoning behind evidence checks and resumable work, read Designing Agent Skills for Clearer Results and Resumable Work. Start with one recurring task, retain what you observed, and let that evidence guide what you try next.