Privacy notice
This notice covers the website and the API at skillhub.fyi, and the skillhub command-line tool. It sets out what the service collects, why it collects it, who else sees it, how long it stays and what you can ask for. The documentation site at docs.skillhub.fyi is a separate deployment and is not covered here yet.
- Last updated
- 26 July 2026
Contents
Who is responsible
The service is operated by legal_entity_name_here at registered_address_here. Both are unfilled. Until they are filled, this page cannot tell you which company holds your data or whose law it answers to.
No data protection officer has been appointed, so a privacy question is meant to reach a person rather than a role. No mailbox has been stood up for it to reach — the domain this service runs on accepts no mail — so there is no address to print here yet: privacy_contact_address_here.
What is collected
Each item below comes from one place in the running code:
- Your email address and password, when you create an account with a password and each time you sign in with one. Your browser posts both to our server, which passes them to the authentication provider. No password is stored here — no table this service defines has a column to hold one.
- Your GitHub identity, when you sign in with GitHub: your numeric GitHub id, your login, your display name and your avatar URL. Your email address is taken only when the provider reports it as confirmed.
- Your account record: a handle, a display name, an email address, an avatar URL, a GitHub id, and the date the record was created.
- What you publish: skill files and their contents, version numbers, changelog text, review comments, and the names of the registries and organizations you create.
- Who you invite: the email address or GitHub handle you type into an invite, with a single-use token. That is personal data about someone who has not signed up.
- Your API tokens, stored as a SHA-256 hash. The first 12 characters stay in the clear so a presented token can be found. The rest is never stored, which is why a lost token can only be replaced.
- Your network address and browser, read from request headers. This happens on API calls and on ordinary page views, including pages you view without signing in.
- Install reports from the command-line tool: which version was installed, into which scope, for which agent, and two 16-character hashes standing for the machine and the project. Both hashes derive from a random identifier the tool writes on first use. Neither derives from your hostname, your username or any path. The report is stored against your account and against the API token that sent it, so it is attributed to you. What the hashes keep out of the record is the name of your machine and the name of your project, not the fact that the install was yours.
- A record of every change that succeeds: who made it, what they did, what they did it to, the network address they did it from, and when.
Your avatar URL is stored and never fetched. Avatars across the site are drawn from initials, so viewing a profile does not make your browser contact an image host.
No analytics script, advertising script or third-party tag runs on the site, and fonts are served from this domain. One exception is worth naming: a published skill is Markdown, and Markdown can embed an image hosted elsewhere. Viewing a skill that does so makes your browser fetch that image, which tells the host serving it your address.
Why it is collected
Each purpose below is paired with the basis we consider it to rest on. That pairing is a working position, not advice, and no lawyer has reviewed it. Which data protection regime applies at all depends on where the operating entity is established, which is still legal_entity_name_here.
- Running your account and your registries, which covers signing you in, working out what you may see, and serving what you publish: performing the agreement you entered into by signing up.
- Sending the sign-up confirmation email: the same agreement. The authentication provider sends it.
- Mailing an invitation: a legitimate interest in letting whoever runs a registry or an organization reach the people they want in it. The person invited has no agreement with us to perform, so the message stays to what the invitation is: who invited them, what they are invited to, when it expires, and the single-use link.
- Rate limiting by network address: a legitimate interest in keeping a shared service available when one caller sends far more traffic than the rest.
- The audit record: a legitimate interest in letting a registry’s administrators see who changed what, and in being able to investigate abuse.
- Install reports: a legitimate interest in knowing which versions are in use, so a version can be retired without breaking the installs that depend on it, and in showing the people who share a set of skills which of them are running which version of it.
Who else sees it
Running the service takes other companies. They appear below by the job they do rather than by name, because the terms agreed with each have not been reviewed for publication. A named list belongs here before launch: subprocessor_list_here.
- The hosting provider serves every request, so it sees your address, your browser and which pages you visit.
- The authentication provider receives your email address and password from our server, which passes on what you typed into the form. It holds the sign-in record, sends the confirmation email, and issues the session token your browser stores.
- The mail provider sends invitations, so it receives the address typed into an invite and the message carrying its single-use link. An invitation addressed to a GitHub handle is never mailed: nothing here can map a handle to an address, so that link only travels the way the inviter sends it.
- GitHub sees the attempt when you choose to sign in with GitHub, and returns your id, login, display name and avatar URL.
- The database provider holds everything listed under what is collected.
- The object storage provider holds published skill archives. Uploads and downloads run from your machine to that provider directly over a short-lived signed URL, so it sees the address of whoever uploads or installs.
- An external skill index receives the text of a search when a signed-in user searches beyond this registry. Our server makes that request, so the index sees our address rather than yours. Signed-out visitors cannot reach it at all.
- GitHub again, when you import a skill from a repository. Our server makes that request too.
Other people using the service see part of it too, and install reports are the part that travels furthest. Anyone who can open a set of skills that contains a skill you have installed is shown your handle, your display name and your avatar URL, a label built from the reporting agent and the first half of your machine hash, the exact version you are on, and how long ago you last synced. That view is keyed on the skill rather than on a team, so it is not confined to the people you share an organization with: installing a public skill can put your row in front of anyone who has listed the same skill in a set of their own.
Personal data is not sold, and nothing here is shared for advertising.
Where it is held
The server code that renders pages and answers API calls is pinned to the hosting provider’s Dublin region, because that is where the database sits. Where each provider stores and replicates data is set in that provider’s own console rather than in this repository, so this page does not state it yet: data_locations_here.
How long it is kept
A scheduled job runs once a day and removes four kinds of short-lived operational record: abandoned publish attempts, idle rate-limit counters, spent command-line login codes, and cached answers from external sources.
Nothing else is deleted on a schedule. Account records, the audit record, install reports, notifications, review comments, invites and import provenance stay until somebody removes them.
The audit record only grows. No row is ever rewritten to change who acted, what they did, or when. One edit does reach rows already written: deleting a registry clears the reference each of its audit rows holds to it, and leaves the rest of the row standing. That is the only case, and the deletion section below says what it leaves behind. A paid plan caps how far back an administrator may read the record, but that cap limits reading rather than storage, and the older rows are still there.
No retention period has been decided for anything on that second list. That is an open decision rather than a policy: retention_periods_here.
Deleting things
Some deletion you can do yourself, from the app or the command line:
- Unpublish a version within 72 hours of publishing it, which removes its files and its tags. The version number stays reserved and cannot be reused, so an install that pinned it fails loudly instead of resolving to different code.
- Yank a version at any time, including after that window has closed. Ranges and tags skip a yanked version, and an exact pin still installs it.
- Delete a registry, which removes its skills, versions and files and cannot be undone. Copies already installed on other machines keep working and are no longer connected to anything here. Audit rows survive with their registry reference cleared.
There is no self-service account deletion, and no address to ask for one at: privacy_contact_address_here. Removing an account and the personal data attached to it is done by hand, by a person, and the request that starts it has nowhere to arrive until a mailbox exists. When one does, saying what you want removed will get back a list of what can go and what has to stay.
Two things usually have to stay. Versions you published into a registry someone else administers are immutable, and removing them would break installs that owner did not agree to break. Audit rows are the record of what happened to other people’s registries, so they outlive the account named in them.
Your rights
Depending on where you live, data protection law may give you the right to ask for a copy of your data, to have it corrected, to have it deleted, to object to a use that rests on a legitimate interest, and to complain to a regulator.
Every one of those requests is meant to be handled by hand: there is no self-service export and no request form. Where to send one is the part this notice cannot answer, since the domain accepts no mail and no other channel has been opened: privacy_contact_address_here. Complaining to a regulator does not go through us, but which one depends on where the operating entity is established, which is still supervisory_authority_here.
What this notice does not answer yet
Publishing the gaps is more useful than papering over them. These are unresolved:
- the operating entity, its address, and the law that governs this notice
- where to send a request — the domain has no mailbox behind it, so access, correction, objection and deletion have no working route today
- how long account records, audit rows and install reports are kept
- the named list of providers, and the terms agreed with each
- a minimum age for holding an account
- whether a self-service export and account deletion exist before launch