What you’ll learn: Construct a handoff that preserves evidence and unfinished work, then distinguish package validation, client loading, and observed behavior when checking whether it can be trusted.
agent skillscodexclaude codedeveloper workflowsecurity
On this page
A task can be easy to finish and difficult to resume.
Imagine an agent preparing a patch at revision A. Unit tests pass, but an integration environment is unavailable. By the time another person or agent picks up the work, the repository is at revision B. A short update says the patch is complete and the tests passed.
The next reader now has to reconstruct what was tested, which check never ran, and whether the evidence still applies. The update saved words by discarding the information needed to continue.
That is the practical problem behind my recent changes to JovaniPink Skills. I want recurring workflows to produce clear results while preserving decisions, failed checks, uncertainty, and unfinished work. I revised 13 public workflows toward that aim. The changes are implemented; whether they reliably improve work remains a separate question.
A handoff someone can continue#
The following pair is an original synthetic example. It illustrates the intended behavior; neither version is captured client output or evidence of a measured improvement.
A handoff that loses the continuation point:
Patch complete; tests passed; ready to merge.
A handoff that preserves it:
Continuation point: The local patch is preserved as
retry-fix.patchand was unit-tested against revision A. The receiving checkout is at revision B; the patch has not been checked against B.Evidence: Unit tests passed at A. The required integration check could not run because its environment was unavailable. That requirement remains unfinished.
Decision retained: Keep the existing retry policy. Only the duplicate-request fix is in scope.
Authority: Local implementation and validation are authorized. Merge and deployment are not authorized by this handoff.
Next verification: Compare the patch with B before applying it. If the relevant code changed, reconcile the change and rerun affected checks. Complete the integration check before claiming the required validation is finished. Stop if the patch would change the agreed retry policy.
The second version is longer because there is more state to carry. It does not require repeating a whole conversation. It preserves the small set of facts that determine the next correct action.
Evidence also has a scope. A test result at A remains a valid historical observation at A. It becomes insufficient support for a claim about B until the relevant differences are checked. Keeping the old receipt and checking its applicability are compatible actions.
What I changed in the workflows#
The dated continuity audit records which public workflows changed and which were retained. Four changes show the intended pattern:
task-handoffleads with the continuation point and next verification. It retains the objective, exact revision, artifacts, decisions, unresolved work, evidence freshness, and existing authority. The receiving task should verify stale evidence without repeating work already proved current.claim-verificationleads with the supported result. If the requested claims are confirmed, it should report that confirmation and its evidence without inventing a repair or an approval request. If a check failed, a shorter answer must still retain the failure.alignment-interviewpreserves decisions already made. If the user selected a storage approach and only retention remains undecided, the next question should address retention instead of restarting the architecture discussion.cross-stack-quality-gatesdistinguishes passing checks from complete validation. Passing unit tests with an unavailable required integration check means the gate is incomplete. The passing result remains useful, and the missing check remains visible.
The other revisions apply the same care to planning execution, writing, configuration, publication, evaluation, and acceptance records. They do not impose a universal short-answer template. A simple confirmation can stay short; a consequential handoff may need a fuller record.
These are instructions for behavior. They are not proof that a client followed them.
Routing, instructions, and enforcement#
A workflow helps only if the agent finds it at the right time and loads the context it needs.
The Agent Skills specification separates discovery metadata from the full instructions and supporting resources. A description tells the client what the skill does and when it is relevant. The body can load on activation; a focused reference can load when the task needs it.
Diagram source (text)
flowchart LR
Prompt["User request"] --> Metadata["Name and routing description"]
Metadata --> Decision{"Relevant?"}
Decision -->|No| Normal["Normal agent behavior"]
Decision -->|Yes| Body["Load SKILL.md workflow"]
Body --> Need{"Need focused detail?"}
Need -->|No| Work["Perform bounded work"]
Need -->|Yes| Reference["Load one focused reference"]
Reference --> Work
“Helps with engineering” gives the router little to work with. “Review API, event, schema, and client changes when producers and consumers may upgrade independently” names a task and the condition that makes it useful.
This is also why a handoff example belongs beside a focused workflow. It can help evaluate a specific behavior without adding a long example to every task's discovery context.
The catalog keeps canonical SKILL.md sources and generates native Codex and Claude packages. Those projections carry client-specific invocation controls. Individual Claude.ai ZIPs are another distribution surface. An offline Antigravity preview is narrower: it excludes explicit-only workflows while that surface's controls remain unverified.
Diagram source (text)
flowchart TD Canonical["Canonical SKILL.md sources"] --> Metadata["Portable metadata and provenance"] Metadata --> Generator["Standard-library generator"] Generator --> Codex["Codex plugin projection"] Generator --> Claude["Claude plugin projection"] Claude --> Zip["Individual Claude.ai ZIPs"] Codex --> Validators["Open spec and client validators"] Claude --> Validators Zip --> Validators Validators --> Evals["Trigger, near-miss, conflict, and output evals"] Evals --> Observed["Per-surface observed evidence"]
The diagram shows the Codex and Claude generation path. It is not a claim that every receiving surface loads or uses those artifacts successfully.
As of September 8, 2026, the public catalog snapshot contains 77 skills across seven optional plugins:
| Plugin | Skills | Main purpose |
|---|---|---|
Core (jovanipink-skills) | 11 | Evidence, diagnosis, authority, research, and publication boundaries |
| Engineering | 24 | Planning, implementation, review, testing, and delivery workflows |
| Stack profiles | 11 | Guidance for particular languages and platforms |
| Operations | 11 | Requirements, governance, measurement, and operational decisions |
| Reasoning | 11 | Alignment, explanation, writing, and handoffs |
| AI systems | 3 | Evaluation, context reliability, and source-to-output checks |
| Agent platforms | 6 | Agent architecture, protocols, tools, security, and grounding |
The counts describe the public source catalog, not proof that all 77 skills are active in a given client. Focused selection keeps the discovery surface relevant to the work.
The repository also has controls that prose cannot supply: schema checks, deterministic generation and packaging checks, invocation-policy tests, and public-boundary validation. These establish properties of the files and tooling. A client observation establishes something different: whether particular instructions or references were discovered and used in a particular session.
The security model explains the boundaries. A handoff transfers context, not new authority. Workflow instructions do not grant tool permissions, and a passing package check does not establish useful behavior.
What the client checks showed#
The September 8 observation record preserves setup checks, failed attempts, retries, and quality findings separately. These were limited manual diagnostics against the 0.11.0 files, not completed controlled-study episodes.
Codex: package consistency, with behavior still to test#
Codex CLI 0.153.2 had two stale packs refreshed. All seven installed public packs matched the generated files. Existing-task behavior was not retested for the continuity changes.
Earlier v0.6 observations on August 21 recorded implicit activation, explicit invocation, and focused-reference loading. Those results remain historical evidence for that tested setup. They do not establish the same behavior for the current package or a fresh desktop task.
Claude Code: authentication recovered, with a verdict finding#
The first September 8 synthetic attempt stopped on expired authentication. After sign-in was refreshed, Claude Code 2.1.220 read the evidence file and the generated claim-verification skill's linked continuity example.
The response preserved failed checks, uncertainty, and unfinished work. Its opening verdict was PARTIAL, though both component claims were REFUTED. The retry therefore supports successful invocation and reference loading, with a specific output-quality finding. It does not support a clean behavioral-acceptance claim.
The old authentication failure is still part of the record. It is no longer an accurate description of the final CLI result.
Web and desktop: useful observations with separate boundaries#
In ChatGPT Work through Safari, one account skill was replaced with the complete canonical ZIP. After reload, the revised instructions and reference were readable. A synthetic response retained the failed check, unfinished fix, missing revision and timestamps, and synthetic-evidence boundary.
However, the built-in trial prompt had run before the fixed case. This was not a controlled baseline. The response reported file reads, but independent tool-read evidence was not captured.
Claude.ai Chat through Chrome visibly read both files. Its first response overstated that prior passing checks did not need re-verification. A changed-revision follow-up corrected that advice while preserving the history and no-change scope. The correction is useful evidence; it does not erase the initial overstatement.
Claude's desktop plugin pages and account library showed refreshed entries. That verifies visibility in those libraries, not instruction use or continuity in a fresh desktop task. The plugin and account copies remain separate surfaces.
Later Claude account repair#
A later September 8 account check found a separate problem: Claude Code's current plugins did not mean Claude Chat had current uploads. The account library was repaired to 63 current enabled skills, with 14 explicit-only workflows held. A fresh web Chat matched all 99 skill files. Result-file downloads still failed, and fresh desktop task checks remained open.
The dated account repair record keeps the passed file checks, failed download, and untested app modes separate. This later result does not erase the earlier authentication and response-quality findings. It also does not establish a measured workflow benefit.
Antigravity: success status did not establish a successful read#
The Antigravity CLI preview passed native package validation and appeared in a fresh skill menu. Lifecycle observations on 1.1.26 and repeated validation/discovery checks on 1.1.27 retain their separate version scopes.
In 1.1.27 print mode, a relative fixture path resolved in the client's scratch folder. An exact-path retry was denied. The process nevertheless exited 0 and reported success with an empty response.
An inline synthetic case returned REFUTED and preserved the failed check and unfinished fix. That supports a limited observation about a response to supplied facts. It does not repair the failed external read. Exact model identity was not captured, so this remains a setup diagnostic.
The running desktop composer did not find the installed CLI preview. That observation does not establish universal incompatibility; it establishes that loading was not demonstrated in that desktop process.
What remains unproved#
These checks found real differences between package visibility, reference loading, and response quality. They did not measure productivity gains or establish full client parity.
I have prepared a communication study with 12 independent synthetic cases, three comparison arms, and three repetitions: 108 planned episodes. It has not been registered or run. Repetitions would measure stability, not create additional independent cases. The comparison is intended to separate the effect of revised workflows from a writing preference; no improvement result exists yet.
The public validation record keeps deterministic checks and incomplete behavioral acceptance distinct. A controlled comparison would need fixed source and instruction versions, preserved failures, and independent review of whether important facts survived. A clearer-looking answer that drops a failed check would not be an improvement.
Start with one recurring task#
Choose a task you already repeat: reviewing a change, checking a completion claim, or passing unfinished work to another session. Use the quickstart and selection guide to find the relevant workflow. The client support checklist explains the receiving surfaces and their remaining checks.
For a handoff, name the continuation point, preserve the evidence and unfinished work, and state the next verification. Then inspect what the receiving client actually loaded and whether its response retained the facts that matter.
That is the standard I want the catalog to earn: work that another person or agent can continue without guessing what “done” meant.