Built-in skills
Fredrin ships skills for the work every project has:
- Ticket management - creating, updating and moving tickets, plus reading project connectors and notes.
- Changelog - turning shipped commits into a written release entry.
- Plan grilling - interrogating a plan before a Worker starts on it, one question at a time.
These are available to Workers with no setup.
Installing third-party skills
Settings → Skills. Point it at a skill source and it becomes available to your Workers.
This is worth saying plainly because the opposite is often assumed: you are not limited to what Fredrin ships. Skills from the wider ecosystem work here.
Writing your own
A skill is a directory with a markdown file describing when to use it and what to do. If your team has a procedure a Worker keeps getting almost right, that procedure is a skill.
Good candidates:
- A deploy or release runbook with real steps and real gotchas.
- A review checklist specific to your domain.
- A repo-specific workflow that is too long for AGENTS.md and too structured for a ticket description.
Skills versus project context
They overlap, and the line is worth drawing.
Project context is what is true about your codebase. Every Worker reads the relevant slice, always.
A skill is a procedure for a kind of task. A Worker loads it when the task matches, and ignores it otherwise.
"Sessions are validated in the auth middleware, not per route" is context. "How to cut a release" is a skill.
Next steps
- Project memory - the always-on half.
- MCP server - a different extension point.