Getting Started with JovaniPink Skills

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 JovaniPink 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, 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. Follow the guide for your client: Codex or Claude Code. Those pages carry the installation and update commands, so this article can concentrate on the first task.

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. In Codex, 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, 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.

The different prefixes are client invocation forms. They 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. 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.