git
git
Most of git usage is what you already know, so depend on that. This skill is just a refinement.
Branch naming
Just name the branch a short sentence separated with dashes. Example: add-some-feature. Don't use feat/, hotfix/ etc. prefixes.
Commit messages
- Always enclose code identifiers with backticks. Example: "Add
html.UserPagecomponent" - Always refer to Go code identifiers including the package name, like in
html.UserPageabove. Fields and methods on structs can be referred withmodel.User.Name. - Ask me about any Github issues that should be referenced, and wait for my response before committing. Reference them at the end of the commit message like this: "See #123, #234". If the commit fixes one or more issues, use "Fixes #123, fixes #234" instead (the double "fixes" is important for Github to actually close the issue).
- Don't mention that you've updated tests, that's assumed.
Pull request descriptions
- Don't include sections that mirror what CI reports. Test Plan, Quality Gates, "ran build/lint/tests, all green" status -- skip them all. CI is the source of truth; freezing a snapshot into the PR body is noise.
- Skip the "## Summary" header too -- just write the bullet points directly.
More from maragudk/fabrik
diary
Write and maintain an implementation diary capturing what changed, why, what worked, what failed (with exact errors and commands), what was tricky, and how to review and validate. Activates proactively during non-trivial implementation work (new features, bug fixes, refactors, research spikes) and at natural session-end moments -- after a PR merges, a feature ships, or a work chunk wraps up -- to capture the narrative while it's still fresh. Does not activate for trivial tasks like one-line fixes, config tweaks, or quick questions.
3decisions
Guide for recording significant architectural and design decisions in docs/decisions.md. Use this skill when clearly significant architectural decisions are made (database choices, frameworks, core design patterns) or when explicitly asked to document a decision. Also suggest proactively at natural session-end moments -- after a PR merges, a feature ships, or a work chunk wraps up -- if a significant decision was made during the session and not yet recorded. Be conservative - only suggest for major decisions, not minor implementation details.
3unsloth
Guide for fine-tuning LLMs, embedding models, vision-language models, and TTS models efficiently with Unsloth. Covers LoRA/QLoRA SFT, reinforcement learning (GRPO, DPO, ORPO, KTO), embedding fine-tuning with sentence-transformers, continued pretraining, and saving/exporting to GGUF, Ollama, or vLLM. Use this skill whenever the user mentions Unsloth, FastLanguageModel, FastSentenceTransformer, FastVisionModel, FastModel, or wants memory-efficient fine-tuning of open LLMs or embedding models on a single GPU, even if they don't explicitly say "Unsloth".
2garden
Autonomous project gardening. Scans for maintenance issues (starting with documentation), picks one, fixes it in a worktree, self-reviews with competing agents, and opens a PR. Use when the user wants to tidy up the project, fix stale docs, or generally tend the codebase. Invoke with /garden.
2modal
Guide for running Python code on Modal, the serverless compute platform for AI workloads, batch jobs, scheduled tasks, web endpoints, and sandboxed code execution. Use this skill whenever the user is writing or modifying Modal code (anything importing `modal`, decorating with `@app.function`, `@app.cls`, `@modal.fastapi_endpoint`, etc.), running `modal run`/`modal deploy`/`modal serve`, configuring GPUs/images/volumes/secrets for Modal, or asking how to host inference, fine-tuning, or agent sandboxes on Modal.
2sql
Guide for working with SQL queries, in particular for SQLite. Use this skill when writing SQL queries, analyzing database schemas, designing migrations, or working with SQLite-related code.
2