gjalla-plugin

Add production-grade observability to code — structured logging, metrics, tracing, alerting, etc. Use this skill when the user is building or modifying a service that runs in prod. Triggers on phrases like "how will we know if this breaks", "production ready", or mentions of observability/metrics/etc. If you're building a new service, this skill should trigger.

Stop and analyze before writing any code. Review the problem space — trace what the change touches, estimate the blast radius, and mentally simulate the system with the change in place. Use this skill whene you're about to implement something that modifies existing behavior, touches shared components, or interacts with more than one part of the system. Triggers on implementation tasks (features, bugs, refactors). Even if the user says "just do it", take 60 seconds to load the context first.

Design error handling as a first-class concern, not an afterthought. Consider where failures get caught, what state they leave the system in, and what information flows to operators, callers, and users. Triggers on phrases related to errors, when you notice a critical piece of code without error handling, or when you're implementing a complex feature.

Analyze requirements for gaps, ambiguities, and unstated assumptions before implementing. This is "negative space analysis" — finding what the spec doesn't say that it should. Use this skill when you receive a task, ticket, user story, or feature request and need to identify specifics before implementing. Triggers on phrases like "build this feature", "implement this", "I want to...", or any time you're handed a task description that you need to start working from. The most expensive bugs come from building the wrong thing, not from building the right thing incorrectly — this skill prevents the former.

Conduct a blameless post-mortem analysis after an incident, outage, or significant bug. Use this skill when something went wrong in production and the team needs to understand what happened, why, and how to prevent it from happening again. Triggers on phrases like "post-mortem", "root cause analysis", "RCA", "what went wrong", "why did this break", or after resolving a production issue when the user wants to document learnings.

Design APIs with the discipline expected at companies known for great developer experiences. Use this skill when building new API endpoints, redesigning existing ones, or reviewing API contracts. Triggers on phrases like "design the API", "new endpoint", "API contract", "what should the API look like", any task that involves defining how systems communicate, or when building a feature that will expose an API. Good API design should happen before implementation, not after.

Design to accommodates the system's likely future, not just its present state. This is "temporal design" — reasoning about how today's implementation interacts with tomorrow's roadmap and evolving requirements. Use this skill when making decisions during implementation: where to place abstractions, how to structure interfaces, when to make something configurable vs. hardcoded. Triggers when you're choosing between approaches and the difference between them is how well they'll hold up over time.

Identify, catalog, and plan the resolution of technical debt in a codebase. Use this skill when the user wants to understand the health of their codebase, prioritize cleanup work, or plan a refactoring effort. Triggers on phrases like "tech debt", "code quality", "refactor", "cleanup", "code health", "maintainability", "this code is a mess", or when you notice code quality issues during implementation that should be tracked rather than fixed inline (which could result in a game of whack-a-mole).

Detect and match the conventions, patterns, and local idioms of an existing codebase before writing new code. Use this skill when adding an existing codebase, especially when you're unfamiliar with the project or haven't worked in this area of the code before. Triggers on any implementation task in an existing project, or when you notice your code doesn't look like surrounding code. Trigger when writing tests, config files, or documentation in an existing project, since conventions apply to those too.

Three-perspective code review from Senior Tech Lead, Product Manager, and QA Engineer. Use this skill when the user wants to be sure that their feature is complete, high quality, and bug free. Triggers when the user says things like "review this code", "is this done", "is this production ready", or any request for substantive code review beyond. If the user wants both cleanup and review, use prepare-for-review first. Also triggers when you are reviewing your own implementation to ensure completeness before reporting that you're done.

Plan safe migrations, deployments, and rollouts with rollback strategies, feature flags, and progressive delivery. Use this skill when the user is making changes that affect production systems — database schema changes, service deployments, data migrations, infrastructure changes, or any change where "just deploy it" is risky.

Cleanup and completeness gate to run before task completion in preparation for a code review. Use this skill when implementation is done and the code needs to be tidied up before handing off to reviewers. Triggers when the user says things like "clean this up for review", "prep for PR", "check the definition of done", "remove dead code", "is this complete", "ready to submit", "wrap this up", or when you are nearing completion of a plan.

Triage issues discovered during implementation — decide what to fix now, what to note for later, and what to leave alone. This is a "scope filtering" process that senior engineers do continuously while coding: they notice problems that aren't part of the current task and make disciplined decisions about each one. Use this skill whenever you encounter code quality issues, bugs, tech debt, or improvement opportunities while working. Also trigger when you feel the urge to refactor something you're reading or to "quickly fix" something unrelated to the task. Scope discipline is one of the most important and least taught engineering skills.

Write a technical design document (RFC, tech spec, design doc, or plan) before implementing a feature or system change. Use this skill whenever the task involves building something non-trivial — a new service, a significant refactor, a new API, a data model change, or any work that touches multiple components or teams.

Write operational runbooks for services and systems — the documented procedures that on-call engineers follow when something goes wrong. Use this skill when building or modifying a production service, after an incident reveals a gap in operational documentation, or when the user asks for docs. Triggers on phrases like "runbook", "how to debug this", or when deploying a new service that doesn't have operational documentation. If you build something that will run in production and there's no runbook, this skill should trigger.