fabrik

ALWAYS invoke this skill as your FIRST action — before any Read, Write, Edit, or Bash — whenever a task involves Go in any way — creating or editing any `.go` file, `go.mod`, or `go test`; adding or changing handlers, structs, methods, interfaces, error handling, goroutines, channels, sqlc/database code, or gomponents views; or refactoring, reviewing, debugging, or testing Go. This is a hard requirement, not a suggestion — the user develops all Go through this skill, which encodes project-specific conventions (structure, error handling, testing, naming) that default Go habits violate. Do not start editing Go and consult it later — load it first. Skip only when no Go code is read or written (pure Python, shell, SQL, Dockerfiles, CI config, or conceptual Go questions with no code).

Use when you write or revise a long-form document an audience will read—documentation, a README, a how-to or user guide, a spec, a design or decision doc, a blog post, a proposal, an announcement, or a standalone report or summary written for a person. Such writing should be clear, concrete, and tight, so draft it from the start by Strunk's Elements of Style (active voice; definite, specific, concrete words; omit needless words) instead of first-draft sprawl. Do NOT fire for short or code-adjacent text—commit messages, PR descriptions, release notes or changelogs, error messages, UI strings, code comments, config, version bumps, quick internal scratch notes, or the implementation diary. These exclusions win even when the text reaches an audience: a release note, changelog, or PR description is a working artifact, not a document drafted for readers.

Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill.

Present output one unit at a time instead of dumping a list or wall of text. Use when the user says "one at a time", "/one-at-a-time", "one thing at a time", "go one at a time", asks you to slow down, to stop the wall of text, or to stop dumping everything at once -- either to redo output you just gave, or to pace the rest of a task.

Guide for instrumenting and operating observable software systems. Use this skill whenever the user is adding or reviewing telemetry, instrumenting code with OpenTelemetry, working with traces/spans/metrics/logs/structured events, debugging production behavior, designing SLOs or alerts, setting up sampling or telemetry pipelines, choosing observability storage, or making code observable for humans or AI agents -- even if they don't say the word "observability". Triggers include "add tracing", "instrument this", "OTel/OpenTelemetry", "why is this slow in prod", "set up an SLO", "alert fatigue", "high cardinality", "structured logging", "wide events", and observability for LLM/agent applications.

Building, rendering, or editing any HTML or UI in a Go application means using gomponents — ALWAYS invoke this skill as your FIRST action, before any Read, Write, Edit, or Bash. This fires for any view, page, layout, component, form, table, navbar, footer, or list that renders to HTML; any function returning a `Node`; anything in the `html` package; and converting HTML or templates into Go. It is a hard requirement — the user writes all HTML through gomponents, a pure-Go component library whose conventions (dot imports, `Node` composition, `Map`/`If`/`Iff`, `Group`, HTML5 documents) ordinary Go and HTML habits get wrong. Load it even when the Go skill also applies. Skip only when no HTML or view code is touched (pure database, handler, or business logic; plain `.css`/`.js`/`.html` files; conceptual questions with no code).

Distill a long book into a concise, structured set of learnings by processing it chapter by chapter with parallel subagents, then synthesizing the result -- optionally into a Claude Code skill. Works for any format the book comes in -- PDF, EPUB, Markdown, HTML, plain text. Use this skill whenever the user wants to summarize, distill, extract the core ideas from, or "turn into a skill" a book, ebook, manual, or other long-form document that is too large to read in one pass. Triggers include "distill this book", "summarize this book chapter by chapter", "extract the key principles from this PDF/ebook", "make a skill out of this book", or handing over a large multi-chapter document and asking what to learn from it.

Guide for posting content to the Bluesky social network using the bsky terminal app. This skill should be used proactively when working in public repositories and there is interesting, shareable content (new features, insights, achievements, or announcements worth sharing with the community). Use it when asked to post to Bluesky, or when content seems worth sharing publicly.

Write and iterate on a project spec (docs/spec.md) that defines what the product is and why it exists. Use this skill when the user asks to create or update a spec, says "let's spec this out", or when a product decision comes up in conversation that should be captured in the spec. Also use proactively when the user is about to start building something that doesn't have a spec yet.

Address code review feedback by walking through comments one at a time with the user. Use when the user has received code review comments — on a GitHub PR, in a document in the repo, in review.jsonl, or directly in conversation — and wants to work through them methodically. Also trigger when the user mentions "address review", "review comments", "PR feedback", "review.jsonl", or wants to respond to code review feedback.

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.

Guide for building on the AT Protocol (the "atmosphere") -- authoring Lexicons, building app views, consuming the firehose, working with identity (DIDs, handles), repositories, records, XRPC endpoints, and OAuth. Use this skill whenever the user is building anything on atproto/Bluesky/the atmosphere -- writing Lexicon JSON, calling com.atproto.* or app.bsky.* endpoints, parsing AT URIs (`at://...`), DIDs (`did:plc:...`, `did:web:...`), handles, TIDs, the indigo Go SDK (`github.com/bluesky-social/indigo`), the firehose / `subscribeRepos`, MSTs, CAR files, DAG-CBOR/DRISL, app views, feed generators, labelers, or PDS interactions. Triggers even if the user doesn't say "atproto" -- words like "lexicon", "PDS", "app view", "firehose", "did:plc", or `at://` URIs are enough.

Guide for how to brainstorm an idea and turn it into a fully formed design.

Review the current conversation for fabrik skills that could be improved (corrections, friction the user had to manually flag, missed triggers, anything else worth flagging) and ship the improvements back to the fabrik repo as a PR (concrete fixes) or issue (fuzzy observations / redesigns). Use when the user invokes /improve-skill or asks to make a skill better, smarter, or less friction-prone. May also be suggested at end of session if there's concrete signal that a skill underperformed; otherwise stay silent.

Dispatch a team of two competing reviewers to critique a diff, challenge each other's findings, and produce a high-signal report. Use this when the user asks for a thorough code review, wants a second opinion before committing, or wants findings that have survived adversarial scrutiny. Prefer this over the solo `code-review` skill when rigour matters more than speed. Invoke with /code-reviewers.

Guide for making code reviews. Use this when asked to make code reviews, or ask to use it before committing changes.

Interview the user about a new blog post before writing it. Use this skill whenever the user wants to write a blog post, says "let's write a post about X", "I want to blog about Y", "help me draft a post on Z", or otherwise asks for help producing a blog post. The skill conducts the interview; you write the post afterward based on what you learn.

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".

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.

Guide for using Observable Plot, a JavaScript library for exploratory data visualization built on D3. Use this skill when creating charts, exploring data, or building visualizations with marks, scales, and transforms.

Guide for building interactive web UIs with Datastar and gomponents-datastar. Use this skill when adding frontend interactivity to Go web applications with Datastar attributes.

Tell the user a dad joke. Use this skill when the user asks for a dad joke, wants to hear something funny, needs cheering up, or says /dad-joke.

Autonomous project gardening by a coordinated team of agents. Spawns a team of gardeners that each run the `garden` skill in parallel, coordinating via a shared task list to avoid duplicate work. Use when the user wants to tend multiple small issues in one pass. Invoke with /gardeners.

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.

Perform a thorough security review of the project, starting from a randomly selected file. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check the codebase for security issues. Also trigger when the user mentions "check for vulnerabilities", "find security bugs", "OWASP", or any request related to assessing the security posture of the project.

Guide for generating and editing images using generative AI with the nanobanana CLI