Community skills
What you'll find here
Safe package shape and review expectations for community skills. Skills package reusable instructions, examples, and optional assets for a bounded workflow — they must be easy to inspect before use and safe to run under Craik policy.
Post-MVP scope.
Broad community distribution and marketplace workflows are post-MVP scope. This guide describes safe package shape and review expectations — it does not imply a supported public marketplace or automatic trust. See Post-MVP Scope.
Authoring
A community skill should include:
Clear SKILL.md entrypoint
Versioned skill package record
Input / output schemas
Context requirements
Required inputs, trust boundary, and missing-context behavior.
Docs
Intended use and limitations.
Provenance
For copied, generated, or externally sourced material.
Examples or fixtures
That can be validated locally.
Use craik.skill_package for
package metadata. Use
craik.skill_registry to record
whether a skill is project-local or global and how precedence is
resolved.
Each expected input schema needs a matching context requirement. The requirement records whether the input is required, which trust boundary is acceptable, and whether missing context should reject the run, be recorded as an omission, or allow a degraded run. This prevents community skills from depending on implicit agent state.
Scoping
Project-local skills
Live with the project · use a project trust boundary · take precedence over global skills with the same package.
Global skills
Treated as user-supplied defaults.
Registries must list every active entry in active_entry_ids, and
precedence_order must include only active entries. Project-scoped
entries outrank global entries for the same package, so a repository
can override a global default without silently inheriting it.
Skill invocation context is per-run state. Use
craik.skill_invocation_context
to record inputs, outputs, omissions, policy links, receipts, and
evidence for one invocation.
Review
Review community skills before adopting them:
- Confirm the package version and entrypoints.
- Inspect docs and examples.
- Verify expected input and output schemas.
- Verify context requirements cover every expected input schema.
- Check provenance links.
- Confirm registry scope and precedence match the project boundary.
- Confirm the skill does not claim runtime authority.
- Run local checks for linked fixtures or examples.
Reference integrations can document known-good skill examples. See
craik.reference_integration
for the fixture and check structure.
Security boundaries
Skills are instructions, not authority.
They do not grant shell, network, repository, memory, or GitHub authority. Runtime authority comes from policy and capability grants. Treat unreviewed community skills as untrusted input until provenance, docs, and expected outputs have been checked.
Do not place secrets in skill docs, fixtures, examples, or assets. Persisted skill invocation context must be redacted and evidence-linked.