━━ failproof ai · publish
publish a pack
no submission form. no approval queue. no account. publish a github release, tag the repo, and your policies are on the marketplace — installable by anyone, on their terms.
start from something that works
writes a starter policy and stops — no network, no git, nothing published. what it writes is not a template with blanks: it is one policy that already blocks git push --force, so the first thing you edit is something that runs. it refuses rather than overwriting an existing file.
write your policies
one or more files that CALL customPolicies.add() at module scope — importing the file is what registers, so nothing is exported. each call passes a name, a description, a category, what it matches, whether it is on by default, and the fn that decides. several files in one directory are one pack; publish bundles them into a single artifact.
that enforces the file on THIS machine right now, before anyone else can see it. ask your agent to do the thing you blocked and watch it get refused.
ship it
no arguments needed. it finds your policy file by content, reads the repo from git remote get-url origin, versions it by the commit you are publishing from — the twelve-character short sha, read from the tree in front of you and never from the repo’s releases, so a fresh clone computes the same answer, creates the repo if it is missing, builds the three assets — manifest, entry module, and a SHA256SUMS that pins both — and uploads them to a release. the checks that can be made locally — the version, and whether your tree is clean — run before it touches github at all. --dry-run builds everything and publishes nothing, with no credential needed, and is the way to find out before a repo exists.
tag the repo
add the topic to your repository on github. that is the whole listing process — the crawler picks it up on its next pass and the pack appears on the marketplace. your pack’s own page works the moment you publish, with or without the topic; the topic is what puts it in the index.
repo topic
failproofai-policies
━━ what gets you listed
the topic puts your repo up for consideration. what actually lists it is a release carrying a manifest that verifies against its own SHA256SUMS and parses under the same rules the cli uses. a repo with the topic and no valid pack is not a pack, and is not listed.
any of these topics are read: failproofai-policies, failproofai-policy, failproofai, failproof-policies.
━━ one thing that refuses, one that warns
- a tag that disagrees with the version — refused. the install url is built from the tag while the version is read from the manifest, so a pack released under a tag that does not describe its version is a pack whose own two halves disagree. a leading
vis fine; anything else stops before a single request is made. separately, a version worked out from your commit needs a clean tree to name — with uncommitted changes it asks to commit them first rather than minting a version that points at bytes nobody else has. - a private repository — published, then warned. it does not refuse: all three assets go up and you get
WARNING: <repo> is PRIVATE, so nobody can install this. installs are anonymous https with no credential to offer, so every one of them 404s. a repo that publish creates is public for that reason.
━━ your entry file
write as many files as you like — one per category reads well. every file that registers policies is bundled into the single artifact a pack has to be: only the entry is digest-pinned, and a pack importing siblings could not honestly claim to be verified. bundling needs bun; without it, name one self-contained file.
publish reads GITHUB_TOKEN, GH_TOKEN, or your existing gh auth login. write access to releases on that repository is enough to publish — but creating a repository is a different permission, so if you want the cli to make one for you the token needs repo-creation scope too.
━━ what people see before they trust you
a pack page shows every policy you ship, its category, the events it matches and whether it is on by default — read from the manifest alone. neither this site nor policies show downloads your entry module to do it, so somebody can decide about your pack without first running your code.