skillci-guardrails

# skillci guardrails A `SKILL.md` is code: its frontmatter is an API, its body is an executable instruction set. It fails silently — a model just quietly does the wrong thing — rather than loudly, which makes both authoring it defensively and verifying it after the fact more important than for ordinary code, not less. ## Step 1 — Author defensively, don't just lint afterward These map directly to skillci's own static checks, so getting them right up front means Step 2 finds nothing instead of catching it after the fact: - **`description`** is the single field that decides whether this skill gets discovered and triggered at all — state what it does *and* when to use it, in language close to how a user would actually phrase the request. Keep it under 1024 characters (skillci flags longer — it eats into every caller's trigger-matching budget). - **Never instruct piping a downloaded script straight into a shell interpreter**, and never reference an unpinned `:latest`/`@latest` dependency — OWASP AST01/AST02, both real risk, not just lint noise. - **Don't request network access to non-localhost hosts** unless the skill's purpose requires it (AST03). - **Never fetch remote content and tell the model to treat it as authoritative instructions** (AST05) — use frontmatter's `pinned_sources` (a declared `sha256`, verifiable on request) instead. - **Keep the body lean**: under ~8000 characters, no exact-duplicate lines, no more than ~10 referenced files or ~100KB ...