Package a Claude Code Workflow

August 25, 2026 - Build and score a local Claude Code onboarding plugin.

Introduction

30 Second Summary

Repeatedly working through the same nine onboarding actions can feel like obvious busywork. The real delay may come from human judgment, permission, or waiting.

In this project, you will time one manual nine-action onboarding before building a two-file local plugin for Claude Code. Exactly four runs will give you the evidence for an honest keep-or-delete decision.

What You'll Build

Released on 25 August 2026 with several plugin fixes, Claude Code v2.1.246 gives you a timely chance to watch whether a two-file local package removes enough practitioner work from a second onboarding to earn a keep decision.

By the end of this project, you'll have:

A measured timed baseline showing the untouched workflow at 9/9 with an observed wall-clock time in mm:ss.
A strictly validated local plugin that loads directly from nine-step-test. Its two files preserve all nine actions. No more than five actions receive the PACKAGED label.
An evidence-backed decision drawn from exactly four runs. The record shows the measured after as N/9 with a wall-clock time in mm:ss. A transfer result checks reuse. A predeclared expected-failure grade checks judgment.
Secret Mission: Audit the arithmetic behind your keep-or-delete decision. Confirm that all four run records agree without adding a fifth run.

Are there any prerequisites?

You need a working Claude Code client plus one exact nine-action onboarding sequence that normally completes manually in six minutes.

Your test set needs two equivalent valid targets plus one target with a predeclared domain reason to fail.

Before We Start

A fair verdict on packaging requires you to fix the workflow before any automation exists. This checkpoint commits you to the original nine actions, two equivalent valid targets, one legitimate expected failure, and the minimum reduction that would justify keeping the package.

Time the Manual Onboarding

A reliable packaging decision needs an untouched timed baseline. Once any plugin exists, it can influence the workflow and destroy the before measure.

Your existing Claude Code client is the setting for one fully manual run. The result is a measured count-and-time pair that the packaged run must beat.

In this step, get ready to:

Protect the untouched baseline by keeping every plugin artifact absent.
Time the exact nine onboarding actions on the first valid target.
Record the measured baseline as one count-and-time pair.

Protect the untouched baseline

The baseline is valid only while no packaging exists. Your current state provides that clean starting point.

Return to the existing Claude Code session from earlier.
Confirm that your current project still contains no plugin folder or plugin file.
Select the first valid target you committed to earlier.
Prepare a stopwatch that displays minutes and seconds.

You should now have one valid target ready while the project still has zero plugin artifacts.

Run all nine actions manually

All nine original actions remain practitioner work in this run. This gives the later package a fair comparison against the same sequence.

Before you start the timer, which original actions do you expect to consume the most elapsed time?

Start the stopwatch immediately before action 1.
Complete the exact nine-action onboarding on your first valid target in the committed order.
Perform every action manually without asking Claude Code to create any part of the onboarding.
Avoid asking Claude Code to save any part of the onboarding.
Avoid asking Claude Code to automate any part of the onboarding.
Stop the stopwatch immediately after action 9 completes.

That is the clean comparison point secured. Your stopwatch now shows the untouched effort for all nine actions.

Record the measured baseline

The count captures the practitioner work in the workflow. The clock captures the elapsed time needed to finish it.

Read the observed minutes and seconds from your stopwatch.
Record one line in your existing Claude Code session. Follow the format Before: 9/9 in mm:ss with your observed time in the final position.
Compare the observed time with the six-minute timebox.
Calculate the exact overrun if the observed time exceeds six minutes.
Reduce the next step's ten-minute authoring block by that exact overrun.
Plan to package fewer deterministic actions if you need to recover time.

Before the final check, do you expect this manual run to have created any plugin artifact?

Review the current session for one baseline line containing 9/9 plus your observed time in mm:ss.
Confirm that your current project still contains no plugin folder or plugin file.

You'll see a measured Before: 9/9 in mm:ss record with your observed time. The project should still contain zero plugin artifacts.

Your untouched baseline is protected. Next, you'll write the two-file plugin while keeping practitioner judgment visible.

Write the Plugin and Failure Rubric

Your untouched baseline is now safe in your Claude Code session. Creating the package after that measurement preserves the before comparison.

You have ten minutes minus any baseline overrun to build a two-file local plugin. The package can automate no more than five deterministic actions.

A prewritten expected-failure rubric ties each failure verdict to domain evidence. Practitioner input stays visible in the measured after count.

In this step, get ready to:

Create the plugin manifest with its identity metadata.
Preserve the fixed nine-action sequence with final action labels.
Define an evidence-based rubric that produces the required verdict output.

Create the plugin manifest

A plugin manifest is the JSON identity file for the package. Its name supplies the namespace used by the skill.

Create nine-step-test/.claude-plugin/plugin.json by asking Claude Code to write the content below:

{
  "name": "nine-step-test",
  "description": "Measures whether packaging removes practitioner work from one nine-step onboarding workflow.",
  "version": "1.0.0"
}

What Does the Manifest Define?

The name field gives the plugin its nine-step-test namespace.
The description field records the experiment's purpose.
The version field identifies this first test draft as 1.0.0.

Confirm Claude Code saved plugin.json inside nine-step-test/.claude-plugin.
Ask Claude Code to read plugin.json back without changing it.

You should see only the name, description, and version fields.

Good. Your plugin now has a stable identity without gaining an extra project file.

Manifest in the Wrong Location?

Check that plugin.json sits inside the hidden .claude-plugin directory. Remove any extra file that Claude Code created alongside it.

Help me fix the manifest without creating extra files.

✔️ Awesome, I've got everything!

Confirm nine-step-test/.claude-plugin/plugin.json matches the three-field manifest above.

ⓧ I'd like to double check the full code

{
  "name": "nine-step-test",
  "description": "Measures whether packaging removes practitioner work from one nine-step onboarding workflow.",
  "version": "1.0.0"
}

This complete manifest fixes the plugin namespace as nine-step-test.

Classify the fixed nine-action sequence

The Markdown skill is the experiment's comparison surface. It keeps all nine original actions visible after packaging.

How Should You Classify Each Action?

Use PACKAGED only for a short deterministic action that the skill can perform consistently. Keep the total at five or fewer.

Use PRACTITIONER for any action involving input, judgment, permission, waiting, or manual work. Those labels preserve the human cost in the after count.

Create nine-step-test/SKILL.md by giving Claude Code the scaffold below after substituting your nine actions plus one final label per entry:

---
name: run
description: Runs the packaged part of one fixed nine-step onboarding workflow and grades predeclared expected failures.
disable-model-invocation: true
---

# Nine-step onboarding decision

Target: $ARGUMENTS

## Fixed sequence

Use exactly nine entries. Mark no more than five deterministic entries `PACKAGED`. Mark input, judgment, permission, waiting, and manual work `PRACTITIONER`.

1. [PACKAGED or PRACTITIONER] [Original action 1]
2. [PACKAGED or PRACTITIONER] [Original action 2]
3. [PACKAGED or PRACTITIONER] [Original action 3]
4. [PACKAGED or PRACTITIONER] [Original action 4]
5. [PACKAGED or PRACTITIONER] [Original action 5]
6. [PACKAGED or PRACTITIONER] [Original action 6]
7. [PACKAGED or PRACTITIONER] [Original action 7]
8. [PACKAGED or PRACTITIONER] [Original action 8]
9. [PACKAGED or PRACTITIONER] [Original action 9]

What Does This Scaffold Control?

The name: run frontmatter gives the skill its invocation name.
The disable-model-invocation: true setting keeps the skill under direct user control.
The $ARGUMENTS value receives the target supplied with the skill invocation.
The numbered sequence preserves one direct comparison against the original nine actions.

Confirm Claude Code saved SKILL.md directly inside nine-step-test.
Ask Claude Code to count the numbered entries plus the final PACKAGED labels.

You should see exactly nine entries. The PACKAGED count should be five or fewer.

Unsure About an Action Label?

Classify an action as PRACTITIONER whenever a person must supply context or exercise judgment. This keeps the after measurement honest.

Help me classify my nine onboarding actions.

Add the failure rubric and output contract

The failure list grades legitimate domain outcomes that need no repair. Each entry needs a condition plus observable evidence plus the reason that stopping is correct.

Append the rubric below to SKILL.md after replacing its expected-failure entry with your precommitted domain condition:

## Expected-failure list

Each entry must name a legitimate domain condition, the evidence that proves it, and why no repair is correct. Command exit failures alone do not qualify.

- [Condition] -> EXPECTED FAILURE: [Required evidence and why no repair is correct]

## Run rules

1. If the expected-failure list contains placeholders, is empty, or merely restates command failures, stop with `NOT GRADED` and say: `This only sequences commands; for this test it is a shell alias, not a packaging win.`
2. If no target was supplied in `$ARGUMENTS`, return `UNEXPECTED FAILURE` without starting the sequence.
3. Check observed evidence against the expected-failure list before treating any failed action as a defect.
4. Work through all nine entries in order. Perform `PACKAGED` actions. Ask the practitioner to complete `PRACTITIONER` actions, and count each one as remaining human work.
5. If a listed expected-failure condition is proved, return `EXPECTED FAILURE`, cite its evidence, and do not repair the target.
6. If an unlisted failure prevents completion, return `UNEXPECTED FAILURE` with the action number and evidence.
7. If all nine actions complete, return `PASS`.

How Does the Rubric Protect the Experiment?

The NOT GRADED verdict rejects an empty rubric or one based only on command failures.
The EXPECTED FAILURE verdict requires a match against evidence written before loading.
The UNEXPECTED FAILURE verdict captures unlisted problems that block completion.
The PASS verdict records completion of all nine entries.

Confirm Claude Code saved the new rubric in SKILL.md.
Ask Claude Code to assess the expected-failure entry against its three evidence requirements.

The assessment should find a legitimate domain condition. It should also find observable evidence plus a reason that no repair is correct.

Rubric Still Looks Like a Command Check?

Replace command-status language with evidence from the onboarding domain. The condition should remain valid even when every command behaves normally.

Help me make my expected-failure entry evidence-based.

Finish the result contract by appending this section to SKILL.md.

## Required output

Verdict: [PASS | EXPECTED FAILURE | UNEXPECTED FAILURE | NOT GRADED]
Remaining practitioner actions: [action numbers]
Measured step count: [number]/9
Evidence: [brief observed evidence]
Failure classification: [matched expected-failure entry, unlisted failure, or none]

What Does the Output Measure?

The verdict records how the run finished.
The remaining action numbers expose the practitioner work left after packaging.
The measured step count keeps the after result on the same nine-action scale as the baseline.
The evidence plus failure classification make the verdict auditable.

Confirm the completed output contract is saved in SKILL.md.
Ask Claude Code to read the five required output fields back without invoking the skill.

You should see a verdict, remaining action numbers, a measured count out of nine, evidence, and a failure classification.

Missing an Output Field?

Compare the final section with the reference below. Keep every field because the later decision depends on both the measurement and its evidence.

Help me restore the required output contract.

✔️ Awesome, I've got everything!

Confirm SKILL.md contains your nine real actions plus the precommitted expected-failure evidence.

ⓧ I'd like to double check the full code

---
name: run
description: Runs the packaged part of one fixed nine-step onboarding workflow and grades predeclared expected failures.
disable-model-invocation: true
---

# Nine-step onboarding decision

Target: $ARGUMENTS

## Fixed sequence

Use exactly nine entries. Mark no more than five deterministic entries `PACKAGED`. Mark input, judgment, permission, waiting, and manual work `PRACTITIONER`.

1. [PACKAGED or PRACTITIONER] [Original action 1]
2. [PACKAGED or PRACTITIONER] [Original action 2]
3. [PACKAGED or PRACTITIONER] [Original action 3]
4. [PACKAGED or PRACTITIONER] [Original action 4]
5. [PACKAGED or PRACTITIONER] [Original action 5]
6. [PACKAGED or PRACTITIONER] [Original action 6]
7. [PACKAGED or PRACTITIONER] [Original action 7]
8. [PACKAGED or PRACTITIONER] [Original action 8]
9. [PACKAGED or PRACTITIONER] [Original action 9]

## Expected-failure list

Each entry must name a legitimate domain condition, the evidence that proves it, and why no repair is correct. Command exit failures alone do not qualify.

- [Condition] -> EXPECTED FAILURE: [Required evidence and why no repair is correct]

## Run rules

1. If the expected-failure list contains placeholders, is empty, or merely restates command failures, stop with `NOT GRADED` and say: `This only sequences commands; for this test it is a shell alias, not a packaging win.`
2. If no target was supplied in `$ARGUMENTS`, return `UNEXPECTED FAILURE` without starting the sequence.
3. Check observed evidence against the expected-failure list before treating any failed action as a defect.
4. Work through all nine entries in order. Perform `PACKAGED` actions. Ask the practitioner to complete `PRACTITIONER` actions, and count each one as remaining human work.
5. If a listed expected-failure condition is proved, return `EXPECTED FAILURE`, cite its evidence, and do not repair the target.
6. If an unlisted failure prevents completion, return `UNEXPECTED FAILURE` with the action number and evidence.
7. If all nine actions complete, return `PASS`.

## Required output

Verdict: [PASS | EXPECTED FAILURE | UNEXPECTED FAILURE | NOT GRADED]
Remaining practitioner actions: [action numbers]
Measured step count: [number]/9
Evidence: [brief observed evidence]
Failure classification: [matched expected-failure entry, unlisted failure, or none]

The bracketed entries show where your real workflow labels, actions, and evidence belong. Your working file should contain the precommitted values before the plugin is loaded.

Before the read-only audit, do you expect any scaffold marker or third file to remain?

Ask Claude Code for a read-only audit of nine-step-test against this step's requirements.

You should see exactly .claude-plugin/plugin.json plus SKILL.md inside nine-step-test.

The content audit should report nine real actions. It should find no more than five PACKAGED labels.

The audit should confirm one evidence-backed expected failure. It should find no scaffold markers.

That's the authoring done. Your measured baseline now has a two-file candidate package to compare against.

Audit Found Extra Files or Markers?

Remove any README, script, results file, executable, or third text file. Replace every remaining scaffold marker with the corresponding precommitted workflow detail.

Help me fix the two-file audit.

Your candidate package is ready. Next up, you will strictly validate its structure before loading it into a local session.

Validate and Load the Plugin

Your manual baseline is protected in the existing Claude Code session. Your two-file local plugin now captures the deterministic part of your onboarding workflow.

Those files remain a candidate package until Claude Code accepts their structure. This step validates the folder before loading its namespaced skill for local testing.

In this step, get ready to:

Validate the local plugin with warnings treated as errors.
Load the plugin directly from its local folder.
Confirm the namespaced skill appears without invoking it.

Validate the plugin strictly

Strict validation turns every warning into a blocker. A clean result proves that Claude Code accepts the plugin structure before you rely on it during the timed run.

Before you run the validator, do you think both files satisfy every structural requirement?

In a terminal positioned in the directory that contains nine-step-test, validate the local plugin by running this command:

claude plugin validate ./nine-step-test --strict

What Does Strict Validation Prove?

The claude plugin validate command checks the folder against Claude Code's plugin requirements.
The ./nine-step-test path points the validator at your two-file local plugin.
The --strict flag treats warnings as errors. This prevents a warning from slipping into the timed comparison.

You should see ✔ Validation passed with no warning. That is the first gate cleared: Claude Code accepts your package structure.

Validation Did Not Pass?

Confirm that your terminal is in the directory that directly contains nine-step-test.
Check that plugin.json remains inside .claude-plugin.
Check that SKILL.md remains directly inside nine-step-test.

Ask for help with the validator output.

Continue only after the validator prints ✔ Validation passed with no warning.

Load the local plugin

Local loading makes the folder available to one Claude Code session. It adds no marketplace installation or remote publication.

Load the local folder into a Claude Code session by running this command:

claude --plugin-dir ./nine-step-test

Why Load From the Folder?

The --plugin-dir option loads the plugin directly from ./nine-step-test for the current session. This keeps the experiment local.

The command starts an interactive Claude Code session in the current terminal. That session is where you check the skill before the timed onboarding.

You now have a Claude Code session using the local plugin folder. Keep this terminal focused on the experiment.

Local Session Did Not Start?

Confirm that the terminal is still in the directory containing nine-step-test.
Confirm that strict validation passed before retrying the local load.
Confirm that your existing Claude Code client is available from this terminal.

Ask for help loading the validated folder.

Keep the local Claude Code session running for the timed onboarding in the next step.

Confirm the namespaced skill

A plugin namespace combines the manifest identity with the skill invocation name. The available-skills list is the final proof that both files loaded together.

Before you check the list, what command name do you expect from the manifest name and the skill frontmatter?

Check the available skills in the local Claude Code session.
Locate /nine-step-test:run in the list.
Leave /nine-step-test:run uninvoked for the timed after run.

You should see /nine-step-test:run listed as an available skill. That clears the loading gate without adding another workflow run.

Your plugin is strictly validated and loaded from its local folder. Next, you will time the second onboarding before testing transfer and the predeclared failure.

Measure the After and Decide

Your two-file local plugin has passed strict validation in Claude Code. The client now accepts its structure.

The remaining question is whether the package removes real practitioner work on a second valid target. This measurement uses the same count plus mm:ss units as the baseline.

A keep decision also depends on transfer to another valid target. The predeclared failure must match the evidence rubric without repair.

In this step, get ready to:

Measure the remaining practitioner work on the second valid target.
Check transfer behavior plus the predeclared failure grade.
Make an evidence-based keep-or-delete decision.

Measure the timed after

The timed after measures the full experience of using the package on an equivalent valid target. Its count includes every original action that still depends on you.

Reset your stopwatch.
Predict whether Run 2 will reduce the practitioner count.
Start the stopwatch immediately before Run 2.
Invoke /nine-step-test:run with your second valid target as its argument.
Complete each PRACTITIONER action when prompted.
Track each original action number that still needs your involvement.
Stop the stopwatch when the onboarding is complete.

You should see a PASS verdict for the valid target. The output should also show the remaining practitioner action numbers plus a measured count out of nine.

What counts as remaining work?

Exclude each original action completed entirely by the package.
Count every original action that requires input, judgment, permission, waiting, or manual execution.
Count original actions only. Prompts within one original action do not create extra actions.

Capture the observed practitioner count here: your observed after count.
Capture the observed elapsed time here: your measured after time in mm:ss.
Record the measured pair in the current Claude Code session as After: your observed after count/9 in your measured after time in mm:ss.

You now have two comparable measurements from equivalent valid targets. The difference shows how much practitioner work the package actually removed.

Seeing a result other than PASS?

Preserve the Run 2 evidence if the valid target returns UNEXPECTED FAILURE.
Check the target against the equivalence criteria you set before the experiment.
Review the expected-failure list if the result is NOT GRADED.

Help me understand why the timed valid-target run did not return PASS.

Test transfer and expected failure

Run 3 tests whether the package behaves consistently on another equivalent valid input. Run 4 tests whether the prewritten rubric recognizes a legitimate domain failure.

Invoke /nine-step-test:run with another equivalent valid target as its argument.
Compare its remaining practitioner action numbers with Run 2.
Record whether the same original action numbers remained in the current session.

A successful transfer run should return PASS. The remaining practitioner action numbers should stay consistent across the equivalent targets.

Predict whether the prewritten rubric will recognize the failure target's domain evidence.
Invoke /nine-step-test:run with your predeclared failure target as its argument.

When the observed evidence matches the prewritten condition, the skill should return EXPECTED FAILURE. This result shows that the failure was graded as part of the domain rules.

Record the expected label from the prewritten rubric.
Record the observed label from Run 4.
Record the domain evidence that supports the observed label.
Leave the failure target unrepaired.
Stop invoking the skill after Run 4.

That completes exactly four runs. You now have a baseline, a timed after, a transfer result, plus an expected-failure grade.

Did the failure label miss the rubric?

Keep the observed label as the Run 4 record.
Compare the observed domain evidence with the condition written before loading the plugin.
Treat a mismatch as a failed keep criterion.

Help me compare the observed failure evidence with my prewritten rubric.

Compare the evidence and decide

The final decision uses the reduction you committed to before packaging. Transfer behavior plus the failure grade determine whether that reduction is trustworthy.

What earns a keep decision?

Keep the plugin only when the measured reduction meets your precommitted threshold. The same practitioner action numbers must transfer to the equivalent valid target.

The expected-failure verdict must also match the prewritten rubric. A failed criterion supports deleting the package.

Compare the measured baseline with the measured after in the same mm:ss units.
Calculate the reduction by subtracting your observed after count from nine.
Check whether the measured reduction meets your precommitted threshold.
Check whether Run 3 preserved the same practitioner action numbers.
Check whether Run 4 matched the prewritten expected-failure entry.
State one keep-or-delete decision in the current Claude Code session.
State that the cost was never the typing if the count barely moved.

Predict whether the four records support the decision you just stated.
Check the current session for exactly four run records.
Confirm that one keep-or-delete decision follows those records.

Run 1 shows Before: 9/9 in mm:ss. Run 2 shows After: N/9 in mm:ss.

Run 3 records whether the same action numbers transferred. Run 4 records the expected label.

Run 4 also records the observed label plus domain evidence. One evidence-based decision follows the four records.

That closes the experiment. Your keep-or-delete decision now has measured evidence behind it.

Secret mission

Audit the Thirty-Minute Decision

Your keep-or-delete verdict is already recorded. Now pressure-test its arithmetic, chronology, practitioner count, and failure grade without adding a fifth run. The result is one plain sentence that states what you built and whether it earned its place.

Clean Up Your Resources

Choose whether to keep your local plugin available, pause your work, or delete it entirely. This project is entirely local, so it has no ongoing costs.

Resources you used:

One local Claude Code plugin in the nine-step-test directory containing exactly .claude-plugin/plugin.json and SKILL.md.

Keep everything running

No action is needed. Choose this option if your measured decision says the plugin is worth reusing.

Retain the nine-step-test directory with both files unchanged.
Use the plugin again only while it meets your precommitted reduction threshold.

Pause - I'll come back to this later

Pausing preserves the two plugin files without keeping the plugin active in your current session.

End the current Claude Code session.
Leave .claude-plugin/plugin.json and SKILL.md unchanged.
Repeat the experiment only after the original nine-action onboarding changes.

Delete - I don't want to use this again

Deleting the directory removes the complete local package. Loading it with --plugin-dir created no marketplace installation.

No remote resource needs removal.

macOS

End the current Claude Code session.
Use your file manager to navigate to the parent directory containing nine-step-test.
Select the nine-step-test directory.
Delete the selected directory using your file manager's delete action.
Permanently remove the directory from your system's deleted-items area.
Confirm that the parent directory no longer lists nine-step-test.

Windows

End the current Claude Code session.
Use your file manager to navigate to the parent directory containing nine-step-test.
Select the nine-step-test directory.
Delete the selected directory using your file manager's delete action.
Permanently remove the directory from your system's deleted-items area.
Confirm that the parent directory no longer lists nine-step-test.

Linux

End the current Claude Code session.
Use your file manager to navigate to the parent directory containing nine-step-test.
Select the nine-step-test directory.
Delete the selected directory using your file manager's delete action.
Permanently remove the directory from your system's deleted-items area.
Confirm that the parent directory no longer lists nine-step-test.

Nice Work!

That's the experiment complete! Your two-file Claude Code plugin now has a keep-or-delete verdict backed by measured evidence.

What you learned:

Captured an untouched manual baseline of 9/9 with a wall-clock time in mm:ss before the plugin folder existed.
Built a two-file local plugin containing exactly .claude-plugin/plugin.json and SKILL.md. Preserved all nine original actions while marking no more than five deterministic actions as PACKAGED. Added an expected-failure rubric based on domain evidence.
Strictly validated the plugin before loading /nine-step-test:run in the local session. Compared the measured before with the measured after. Confirmed transfer on an equivalent target. Graded the predeclared expected failure from domain evidence. Used exactly four run records to reach one keep-or-delete decision.
Secret Mission: Audited the 9 - N arithmetic against the claimed reduction. Confirmed that the baseline predates the plugin folder. Checked that N includes every practitioner action. Verified the failure classification against the prewritten domain list without adding a fifth run.

Ready to quiz yourself?