Self-learning example

A small Node.js project for drafting, verifying, and reusing a skill.

This example uses a dependency-free Node.js project to demonstrate skill drafting and reuse. The first task extends a small string-normalization function. The second task applies the same development procedure to a related function.

Download the starter project. The archive contains source, three passing tests, and the complete walkthrough. It does not contain an installed skill or a precomputed verification report.

Requirements#

Node 24+ and Git.
pi-kit desktop with a tool-capable model.
The bundled @pi-kit/learn package and a configured analysis model.

Use a separate directory for the example. Model calls may incur provider costs. Verification uses a scratch checkout but does not restrict tool access to that directory.

Initialize the project#

Extract the archive, then run inside self-learning:

git init -b main
git add .
git commit -m "Add self-learning starter"
npm test

There are no dependencies to install. Git requires a configured author name/email. Open this directory as a project in pi-kit.

Complete the first task#

Create a Local thread and send:

Extend slugify in src/slug.mjs. Lowercase and trim the input, replace each run of non-ASCII-alphanumeric characters with one hyphen, and remove leading/trailing hyphens. Add tests for repeated whitespace, punctuation, and an input containing only punctuation. Preserve the existing tests. Run npm test. Do not commit or install packages.

Review the diff and test output. Commit the result while pi-kit is running:

git add src test
git commit -m "Normalize punctuation and whitespace in slugs"

The thread needs a recorded outcome before verification can compare its base and result. Keep both commits available.

Completed normalization task with six passing tests and a skill draft card.

Draft and verify a skill#

Run /learn in the completed thread and accept the analysis consent if requested. Open the draft and read the procedure. It should describe actions that can be reused—inspect existing behavior, add edge-case tests, implement the change, and run checks—rather than only restating one expected output.

Use verification to replay the first prompt with the draft skill from the outcome's base commit. Inspect the reported files, hunks, and test results. A different but correct implementation may produce a partial comparison; the report is not a general evaluation of model quality.

Edit the draft if necessary, select project scope, and approve it. The installed file is .pi/skills/<name>/SKILL.md.

Learning workspace with the generated skill text, installation scope, and verification controls.

Reuse the approved skill#

Start another thread, select the skill through /, and send:

Add normalizeBranchName in src/branch.mjs. Normalize punctuation and whitespace into single hyphens, lowercase the result, remove leading/trailing hyphens, and prefix the result with feat/. Return feat/untitled when the normalized name is empty. Add tests and run npm test. Do not commit or install packages.

The skill is supplied as instructions to the new task. Model weights are unchanged. Inspect whether the procedure was followed and whether the tests cover the requested cases.

Recorded run#

The screenshots show a real local deepseek-v4-flash run of this project. The first task passed six tests and produced a skill draft. Verification returned Failed: it reproduced zero of two files at the comparison threshold, with 53% overall changed-line similarity. The recorded check was skipped because its command explicitly named the original project directory by absolute path.

Actual replay report showing a failed diff comparison and a skipped absolute-path check.

This is not a successful-verification demonstration. It shows why the report needs inspection: diff similarity and check execution are separate results. Prefer project-relative test commands so checks can run in the scratch checkout. The recording covers the first task, draft, and replay; approval and second-task reuse above are the next steps to try, not claimed recorded results.

Download the recorded-run summary. Temporary source-directory paths in that summary are redacted. The capture used a disposable project and pi profile.

Record the result#

Keep the first-task diff/tests, draft and manual edits, actual verification verdict, installed path, and second-task test output. These provide the evidence for a particular run. The starter project does not guarantee a specific draft or replay result across models.

See Skill drafting and verification for the underlying workflow and its limits.