get in touch
Contact
Most of this happens in public, on GitHub, so that an answer is readable by the next person with the same question. Two things do not, and they are at the bottom.
A rule is wrong, or the model already does it
The most valuable thing you can send. Every rule here is a falsifiable claim that a model fails without it, so a control run where the model already does the right thing retires the rule. 17 have gone exactly that way.
What to include
- The task you gave it
- The model and the harness
- The output, with no skill loaded
A rule was right and has stopped being right
A rule cites platform behaviour, and platforms change. This is different from a rule that was never right, and it is triaged differently: the rule is not wrong so much as expired.
What to include
- The rule id
- What changed, and where that is documented
- The version it changed in
Something is not covered
A concern no existing skill owns. Worth reading the four admission tests first, because three of them are ways of saying no and most proposals fail on the first one.
What to include
- The concern, and which axis it belongs to
- Why an existing skill does not own it
- A failure a model actually produces
The CLI or this site is broken
Anything that is the tooling rather than the content: a command that fails, a page that renders wrong, a skill that installs into the wrong place.
What to include
- What you ran, and what it printed
- skyl --version, and your node version
- Your operating system and agent tool
Something unsafe
Two different things go here, and neither belongs in a public issue while it is still true.
- A rule that causes a defect. Not a rule that is merely wrong: one that, followed as written, produces code that loses data or leaks a credential. That is shipping in whoever installed it, so it is fixed before it is described.
- A vulnerability in the CLI. It runs in your repository and writes files into it, so it is worth reporting privately.
Use GitHub's private reporting on whichever repository it affects:the registry or the CLI and site. It reaches the maintainer without becoming public, and it gives you an advisory to be credited on.
Anything else
For what does not fit above: a question, something you are building on this, or a conversation that is not an issue yet. It reaches the maintainer.
If it is an issue, please open one instead. Not to deflect: an issue is searchable and an inbox is not, so the next person with your question finds the answer rather than asking it again. Blank issues are enabled for exactly that reason.
No form, and no mailing list. A form here would collect what an issue collects and put it somewhere nobody else can read or search.