A repeatable skill admission review

Establish the review target

Collect the exact package, source identity, revision, owner, intended use, and required host. Preserve the artifact under review. If the package cannot be identified consistently, do not claim to have assessed a reproducible state.

Start a review record in the workbench. The worksheet stores your entries in this browser; it does not scan a package or certify a result.

Review declared behavior

Read the metadata and instructions, then describe the legitimate workflow in your own words. List every supporting resource, code entry point, and destination. Compare those elements with the stated purpose.

Mark mismatches and unanswered questions explicitly. Requesting clarification from a maintainer can be more useful than turning an ambiguous instruction into an unsupported accusation.

Review executable behavior

Inspect scripts and dependency state with the same care as ordinary software. Test in an isolated environment using synthetic inputs. Observe side effects and failure paths. Keep runtime authority narrow until the review is complete.

For packages with learned artifacts or opaque components, record the additional uncertainty and the independent controls around their outputs.

Write the decision

Choose approved, approved with limits, or held for review. Document exactly which use case and permission profile the decision covers. A limited approval should identify the remaining gaps and the controls that compensate for them.

A blanket “safe” label makes the decision difficult to revisit. A scoped decision is easier to audit and revoke.

Promote and maintain

1. Deploy the reviewed artifact rather than rebuilding an unidentified package.
2. Link the inventory entry to evidence and tests.
3. Assign an update owner and review trigger.
4. Verify revocation and rollback before granting sensitive access.
5. Reassess when content, dependencies, or host authority changes.

Admission is a lifecycle control. It should create a record that remains useful after installation.

Worked example: a decision another reviewer can reproduce

A maintainer asks whether a reporting skill may enter a shared library. “Looks fine” is not a useful approval. A second reviewer needs to know the exact package, allowed task, evidence inspected, environment tested, and limits that made the decision acceptable.

Work through the evidence

Begin with the artifact inventory. Compare metadata, instructions, references, scripts, and dependencies with the declared purpose. Mark inaccessible or unsupported material. Test only after defining containment and synthetic inputs. Keep the legitimate task result, prohibited-effect tests, and review coverage separate; each answers a different question.

Decision criteria and a useful review record

Use a concrete decision: held for missing evidence, approved for a stated scope, approved with enforceable limits, or rejected with reasons. A conditional approval should identify the control and its owner. Set review triggers such as a new destination, dependency, artifact, or permission. The workbench records your judgment; it does not perform this investigation or validate checked boxes.