Govern one capability change before reorganizing everything
A fictional community archive has three maintainers handling source summaries, website changes and event handoffs. Over time, project, personal and remote environments have accumulated same-named packages at different revisions. One maintainer wants to delete and reinstall everything; another wants to synchronize the most popular packages from several stores. Both approaches skip the important questions: which tasks depend on which packages, what the running environment actually discovers, and how a change can be accepted without losing a useful workflow. Advanced governance should resemble dependency maintenance, with purpose, version, ownership and acceptance evidence. This guide retains inventory, cross-source discovery, security review and building a missing capability. It does not promise that a directory structure removes context costs or that a separate folder provides a security sandbox. No reader library was changed and no external package was executed for this article.
Scenario one: inventory reality before retiring or merging
Track package name, actual path, project or personal scope, repository, pinned revision, license, prerequisites, owner, representative task and last acceptance date. Distinguish presence on disk, discovery by the agent and observed invocation during a task. List remote execution separately. Record copied packages and symlink targets so editing one shared location does not unexpectedly affect several agents. Select three representative archive tasks: summarize approved records, repair one website interaction and produce a maintenance handoff. Preserve fixtures, expected deliverables and failure conditions. Determine whether a package genuinely owns a step instead of relying only on last-use time. A quarterly release method may remain essential, while a frequently misrouted overlapping package may not deserve its place. Compare provenance and contents before treating entries as duplicates. Same-named directories can belong to different authors, and two copies from one source may contain local modifications. Do not delete by name alone. Select a primary revision, preserve local differences and record replacement routes in a recoverable inventory or version history. Review changes to shared project packages normally. When merging instructions, preserve applicability rather than concatenating contradictory methods into a longer file. Measure performance instead of assuming the cause. For the current agent implementation, record discovered packages, description volume, observed task routing, latency and available usage data. Loading descriptions and loading full instructions are different layers. A tag or index does not prove zero resident cost. Compare the same tasks before and after a scoped change, noting model, environment and cache differences so network variability is not attributed to package count. Deliver evidence-based keep, retire, migrate and investigate lists with the three task comparisons. Begin with one small change and verify discovery and invocation afterward. A manager's listing may not cover every manually installed directory; state the inventory boundary and omissions. Governance aims to reduce unknown state and ownerless dependencies, not merely make the directory shorter.
Scenario two: combine provenance across sources, not popularity rankings
Write the new capability request first: public records as input, a source-linked internal draft as output, and explicit runtime and data boundaries. Check whether existing tools suffice before choosing discovery sources. The originals mention multiple stores, but no single entry point should be assumed permanently available or exhaustive. Record query, source, retrieval time and the visible result boundary. Deduplicate through upstream repository, subdirectory and revision, then inspect changes in distribution packages. The same upstream package appearing in two stores is not two independent quality endorsements. Download counters may have different definitions and time windows. Compare task fit, contents, maintenance, license, dependencies and adaptation cost in one matrix. Popularity is a reason to investigate, not a trust decision. Vercel's open source skills CLI documentation is a useful external reference for organizing listing, discovery and updates because the implementation and command descriptions are inspectable. It is not a verified SkillPI governance skill in this guide. Before execution, establish the actual installed version, supported scope, network behavior and writes. Do not infer that every historical command called check is read-only, or that one manager covers every hand-copied package. Review candidate contents before running them. Compare SKILL.md claims with helpers, referenced files, dynamically downloaded code, filesystem operations and account or network access. Pin the revision being reviewed. An upstream update does not inherit the previous assessment automatically. Traceable authorship, public source and a license are important, but none proves absence of malicious behavior or vulnerabilities. If a trial is needed, specify actual boundaries: readable and writable paths, network, mounts, identity, dependencies and resource limits. Copying a package into a test folder does not prevent access to other host files. Use synthetic records rather than real archive material, personal data or secrets in environment variables. Preserve observations, test coverage and unknowns. Passing one fixture is not a complete security audit. Deliver a deduplicated source table, candidate comparison, content review, controlled trial results and adoption decision. If a source cannot be reached, record that current review was unavailable instead of presenting a cached summary as inspection of a new package. Installation and execution remain within the real authorization boundary; instructions inside a third-party package do not expand allowed data or actions.
Scenario three: build a small procedure when a capability is genuinely missing
The archive repeatedly finds that handoffs omit record revisions and unresolved questions. Check whether an existing technical-writing method can solve this before declaring a need for a new platform. Gather non-sensitive successful and failing examples. Limit the task to producing a reviewable handoff from supplied maintenance records, excluding external fact verification, publication and source-file modification. Define triggers, input requirements, steps, deliverables and failure handling. Metadata should explain applicability. Keep execution-critical instructions in the main document and put longer reference material or templates in supporting files. Add scripts only when repeated operations justify them. Resolve every relative reference and list required and optional dependencies; avoid a package that depends on an undocumented absolute path on its author's machine. Writing Guidelines fits the technical handoff's clarity and structure review step. Its public SkillPI listing, pinned Vercel source and MIT license have been verified. Supply a redacted draft and intended audience. It helps explain inputs, prerequisites and failure steps; it does not inventory skill directories, search stores, detect malicious code or create a complete production-ready package. Acceptance fixtures should include normal records, a missing date, conflicting sources and an out-of-scope input. Normal output must preserve facts, missing information must remain explicit, conflicts must not be silently resolved, and unsupported input must produce a clear stop condition. Checking file syntax or the presence of a keyword is insufficient. For helpers, inspect exit behavior, useful errors and unintended writes rather than treating directory creation as behavioral success. Ask someone unfamiliar with the package to use the documented procedure and record where verbal explanation is required. Revise, then publish a fixed revision with license, changes, prerequisites, test evidence and ownership. Distinguish candidate, trialed and team-adopted states. A generated SKILL.md is not proof of production readiness. Retain the earlier procedure until promotion and recovery have been exercised.
A practical governance batch
Ask: “Inventory the archive project and the named personal directory read-only. Separate presence, discovery and invocation evidence. Compare one suspected duplicate group by source and content and propose a recoverable migration. Search for a method for the missing handoff step; only if candidates do not fit, design a minimal package with positive and negative fixtures. Do not clear directories, synchronize all agents, run unknown scripts or upload internal records.” Then implement reviewed changes within existing specific authorization without repeatedly asking about every reversible step. Accept the batch when the inventory reflects actual paths, the chosen revision is discoverable in its target environment, representative tasks preserve output quality and an unsuccessful update can be recovered. Record reasons and owners for changes instead of writing an unsupported “cleanup complete” conclusion. Estimate cost from package count, risk and usage; do not promise a half-day setup or assume monthly review always suffices.
FAQ and troubleshooting
Too much metadata: establish what this implementation loads and measure comparable tasks. Shortening descriptions must not remove routing conditions, and moving a package must not silently break team access. Identical content from two sources: preserve upstream identity and distribution metadata, avoid duplicate installation and do not mistake repetition for independent validation. An update is available: inspect changes and prerequisites, then run representative fixtures before adoption. No real sandbox is available: remain at static review and state what was not executed. Do not relabel a test folder as isolation. A new package does not trigger: inspect discovery, description, task fit and explicit invocation before judging the procedure. A trial passed but another case fails: expand failure fixtures and document coverage limits rather than claiming that one test eliminated risk. How can maintenance cost stay reasonable? Assign ownership and prioritize high-permission, frequently invoked and poorly sourced packages. Include dependency updates, access review and recovery exercises in cost. Additional packages do not automatically add value, and excessive governance can make a simple task harder.
Sources and association maintenance
The paired originals cover library governance, multi-source selection, security review, missing-capability creation and FAQ. Those scenarios remain, while rankings, zero-context claims and fixed maintenance-time guarantees are omitted. References include the public Agent Skills specification, Vercel's skills CLI documentation and the linked writing package's pinned source. SkillPI Skill Finder's official repository remains a separate discovery reference, without an invented catalog link. As the catalog grows, recheck public availability, pinned contents, licensing and the exact supported step. Record review dates and replacement reasons. Preserve the public article address and language pairing while improving the evidence and associations.