anthropics / anthropics/skills

How do you keep a per-skill portability label honest?

Open
#1,156 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
176k
Forks
20.8k
Avg merge
7h 21m
Merged PRs (30d)
5

Description

This is a design question rather than a bug, so apologies if the tracker isn't the right place for it, and I'm happy to take it elsewhere if so.

We bundle skills written in the SKILL.md format, and we've hit a problem: some of the skills we bundle are genuinely universal and work in any project, but others quietly assume our own paths, our own scripts, our own internal terminology, and only really work for us, so what we want is a flag in the bundle manifest that marks each skill one way or the other, so that anyone vendoring the bundle can see what they're actually getting before they pull it in.

The part we can't work out is what stops an author from simply marking everything universal and shipping it anyway, and that's really what I'm hoping someone here has run into before, because if you've shipped a per-component portability label, or any kind of scope or tier marker, we'd genuinely value hearing whether it survived contact with real authors, and if it did, what kept it honest, whether that was a lint pass, a score, a review gate, plain social pressure, or nothing at all and it simply worked out.

We're drafting a manifest format called tome.yaml that bundles AI instruction files and skills together, and before we settle the draft we're trying to ask people who've actually shipped systems like this in production, rather than guess at it ourselves.

The full request for comment, with the other open questions, is here: https://github.com/tomevault-io/companyos/discussions/1

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.