Your Team’s Skills Keep Growing. How Do You Make Them Useful?

Turn a one-time correction into something the team can reuse

Your team finishes a member-invitation feature and saves three Skills: release handoffs, documentation checks, and code reviews. Later, a question about release terminology starts a file-reading workflow. A link check opens sales notes. A code review changes the implementation. The issue is no longer whether a Skill exists. It is whether its instructions match the task.

This exercise produces three revised Skills, a stable set of acceptance criteria, and a record of actual runs. The project, inputs, and defects are original fictional examples. We supply an answer key you can inspect; you must run your own Onevium conversations to establish model behavior.

OpenAI’s September 11 article recommends revisiting Skill descriptions, how supporting material is loaded, and accumulated project instructions. It discusses GPT-6 Astra. We borrow a maintenance method here, not a promise that every provider selects Skills or follows instructions in the same way. Our examples share one small invitation project.

Identify the failing part before removing instructions

Think of a Skill as a reusable work instruction. Its description tells the assistant when it applies. Its body explains the workflow. Reference files hold details needed for particular tasks. Locate the failure in that structure first. Cutting the word count in half can remove an essential requirement just as easily as an obsolete one.

The aim is to make necessary material easy to find without loading unrelated instructions into every task. Keep the input requirements, output conventions, and acceptance criteria that still serve a purpose.

Prepare two disposable practice projects

Download and extract the starter, then open a terminal in team-skills-maintenance-starter. You need Node.js 20 or later. These commands install no dependencies and call no model. check.mjs checks package integrity, references, and cases. Each prepare command creates a new temporary directory and prints its full path.

In Onevium, choose Add project beside the Projects heading, then Open existing folder and select one printed directory. Each project contains only its selected variant in .claude/skills/name/SKILL.md. Do not install these examples as personal Skills. Temporary directories may be cleared by the operating system; copy them to an empty practice folder before opening if you want to retain them.

Keep cases.json and observation records outside the model’s project. Attaching the entire case file would expose the answer key. Prepare a fresh directory for each real case so both variants start with identical inputs. A new conversation does not copy or reset a directory.

node --version
node check.mjs
node prepare.mjs before
node prepare.mjs after

Repair one: replace broad relevance with a specific task

The original release-handoff description mentions any code, product, documentation, or team question. Those terms cover most of the project. The revision narrows the entry point to preparing a release or support handoff, excluding terminology questions and implementation work. The package includes both complete versions.

The body also preserves a factual contract. Read the version from inputs/release.json. invite-expiry and resend-invite have shipped; bulk-invite is planned. Clear selection rules are only useful if the resulting handoff remains accurate. Whether the model actually selects this Skill must be observed in the natural-language cases later.

Before:
Use for any release, code, product, documentation, or team question.

After:
Draft a handoff of shipped changes from this project's release record.
Use for a release summary or support handoff,
not terminology questions or implementation work.

Completion:
Version → shipped change IDs and summaries → separate plans.
No invented shipped features, file edits, or publication.

Repair two: load material for the task at hand

Checking relative links in docs/invite.md does not require sales notes or release plans. The revised entry file retains the scope, expected report, and a reference link. Path-resolution details live in references/local-links.md, loaded for the local-link workflow. Shorter instructions are a consequence; a clear purpose for each document is the goal.

Here, setup.md resolves to docs/setup.md, which exists. account-deletion.md resolves to docs/account-deletion.md, which is missing. Those two findings are easy to verify. This exercise does not validate fragment anchors or remote websites. Add a separate workflow and checks before claiming that coverage.

doc-link-review/
  SKILL.md
    Scope: local relative links in a requested Markdown file
    Read when needed: references/local-links.md
    Report: original link, resolved path, existence evidence
  references/
    local-links.md
      Resolve paths from the source document's directory
      Do not create missing pages
      State that fragment validation is outside this exercise

Repair three: resolve conflicting actions

The original invite-review says both “never modify files” and “immediately fix every issue.” Strong wording does not resolve the contradiction. The revision defines a review: cite the policy, identify the location, provide a failing input, and suggest a correction in the answer. Implementation belongs to a separately scoped editing task.

The policy says an invitation expires when now >= expiresAt. Line 2 of the example uses now > expiresAt. Setting both values to 1000 demonstrates why the returned false violates the policy. An acceptable review explains that mismatch and suggests >= while leaving the file unchanged.

This does not require asking again before every routine action. A Skill can clearly authorize reversible local steps. It needs to distinguish the work being requested: review or implementation. Skill text is not a sandbox. Inspect real tool operations; a blocked write attempt still deserves review even if the file remains unchanged.

Before:
This review is read-only: never modify files.
Immediately fix every issue before replying.

After:
Review the requested code against the invitation expiry policy.
Report file and line, violated rule, failing input, and suggested correction.
Suggest changes in the answer only; do not edit or claim a fix was applied.

Run the same cases in Onevium and inspect the evidence

Open Plugins → Skills, choose the practice project in the scope selector, and refresh. Inspect a Skill’s name, source path, and body. Use skill places its reference in an editable conversation draft. Add the task input and send to start execution. This first checks manual invocation. If it is missing, check the project and whether Skills and native Claude Skills are allowed in Scope settings.

For natural-language selection, start a new conversation for each case and paste only prompt.en or prompt.zh from cases.json. Do not add the Skill name or expected answer. Hold the provider, model, permissions, language, and inputs fixed across before and after. Check for same-named personal or plugin Skills. None of the three negative cases should enter any of these exercise Skills.

Save the answer, visible tool activity, and file changes outside the project. Record observations in a separate copy of observation-template.json. Mark selection unknown if the available evidence cannot establish it; mentioning a filename is insufficient. Review factual correctness and scope before comparing unnecessary reads. Repeat important boundary cases and retain failures.

Leave a maintenance decision the next task can use

We checked the starter’s file integrity, fixed inputs, relative references, and answer notes, and verified that prepare creates independent directories. We did not run real model evaluations. This cannot establish fewer false activations, lower token use, or faster work. Fill those fields from your actual runs.

Before adopting a revision, record why it changed, which part changed, the case that catches the old failure, and who reviewed the new result. Prioritize wrong selection, false facts, and out-of-scope actions; then address unnecessary reads and wording. Rerun the affected cases after a model change or a newly observed failure. Every small edit does not require rewriting the whole Skill library.

In this team-practice series, Team sessions turn a complex request into clear handoffs, and CI diagnosis finds the verification bottleneck. This article turns a working method into maintainable Skills. Next, record human review, rework, and runtime costs to judge whether the complete workflow is worth continuing.