Skill | Added | Review |
|---|---|---|
subagent-driven-development Use when executing implementation plans with independent tasks in the current session | 61% | |
verification-before-completion Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always | 93% | |
removing-packages Use when removing a software package from the Bluefin image, deleting a .bst element, or unwiring a package from the build | 86% | |
packaging-zig-projects Use when packaging a project that uses the Zig build system, when an element needs zig fetch/build with offline dependency caching, or when adding Zig dependencies to an existing element | 80% | |
writing-skills Use when creating new skills, editing existing skills, or verifying skills work before deployment | 69% | |
packaging-rust-cargo-projects Use when packaging a Rust project with Cargo.toml, when an element needs cargo2 sources for offline builds, or when generating cargo dependency lists for BuildStream | 88% | |
receiving-code-review Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation | 81% | |
brainstorming You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. | 71% | |
using-superpowers Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions | 63% | |
patching-upstream-junctions Use when modifying upstream freedesktop-sdk or gnome-build-meta elements, when fixing bugs in junction dependencies, or when deciding between patching an element vs replacing it entirely | 76% | |
debugging-bst-build-failures Use when a BuildStream build fails, when diagnosing element errors, or when reading CI build logs to understand what went wrong | 80% | |
writing-justfiles Use when creating or modifying Justfiles in this repository, when adding new recipes, or when organizing just commands | 72% | |
finishing-a-development-branch Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup | 92% | |
packaging-pre-built-binaries Use when packaging a project that provides official pre-built static binaries, when building from source is impractical, or when you need a bootstrap compiler | 75% | |
packaging-gnome-shell-extensions Use when packaging a GNOME Shell extension for BuildStream, when adding a new extension to the image, or when debugging extension installation paths, UUID discovery, or GSettings schema compilation | 91% | |
local-e2e-testing Use when building the egg OCI image locally, testing changes end-to-end, verifying the image boots, or running any BuildStream commands against the project | 91% | |
dispatching-parallel-agents Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies | 60% | |
managing-bst-overrides Use when creating, evaluating, or removing BuildStream junction element overrides - ensures agents follow GNOME OS upstream-first principle and maintain recognizable patterns | 81% | |
requesting-code-review Use when completing tasks, implementing major features, or before merging to verify work meets requirements | 71% | |
oci-layer-composition Use when understanding how packages flow into the final OCI image, when modifying layer assembly, or when debugging why files appear or are missing from the built image | 64% | |
ci-pipeline-operations Use when debugging CI failures, understanding the build pipeline, modifying the GitHub Actions workflow, working with artifact caching, or troubleshooting why a build succeeded locally but fails in CI | 91% | |
using-git-worktrees Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification | 88% | |
buildstream-element-reference Use when writing, editing, or reviewing BuildStream .bst element files — provides variable names, element kinds, source kinds, command hooks, systemd paths, and layer structure | 94% | |
executing-plans Use when you have a written implementation plan to execute in a separate session with review checkpoints | 74% | |
packaging-go-projects Use when packaging a Go project with go.mod, when an element needs go_module sources for offline builds, or when setting up GOPATH vendoring in BuildStream | 80% | |
writing-plans Use when you have a spec or requirements for a multi-step task, before touching code | 69% | |
updating-upstream-refs Use when updating a package version, bumping upstream refs, wondering how dependency tracking works, or asking how to update Tailscale/Zig/junction refs in the Bluefin image | 78% | |
test-driven-development Use when implementing any feature or bugfix, before writing implementation code | 64% | |
systematic-debugging Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes | 64% | |
adding-a-package Use when adding a new software package to the bluefin-egg BuildStream build, creating a new .bst element, or asking how to package something for the image | 91% |