Engineering
Streamline engineering workflows — standups, code review, architecture decisions, incident response, and technical documentation. Works with your existing tools or standalone.
10 skills · version 1.2.0
Install
hrida-agent-sdk plugin install engineering@knowledge-work-skillsOr, inside a session: /plugin install engineering@knowledge-work-skills. See Installation for scopes and updates.
Connectors
Skills work on their own with files you share, and get more useful when these tools are connected (configured in the plugin's .mcp.json):
Slack, Linear, Asana, Atlassian, Notion, GitHub, PagerDuty, Datadog, Google Calendar, Gmail.
Skills
| Skill | What it does | Use case | How to use |
|---|---|---|---|
| architecture | Create or evaluate an architecture decision record (ADR). | When choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints. | /engineering:architecture <decision or system to design> |
| code-review | Review code changes for security, performance, and correctness. | Trigger with a PR URL or diff, "review this before I merge", "is this code safe?", or when checking a change for N+1 queries, injection risks, missing edge cases, or error handling gaps. | /engineering:code-review <PR URL, diff, or file path> |
| debug | Structured debugging session — reproduce, isolate, diagnose, and fix. | Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious. | /engineering:debug <error message or problem description> |
| deploy-checklist | Pre-deployment verification checklist. | When about to ship a release, deploying a change with database migrations or feature flags, verifying CI status and approvals before going to production, or documenting rollback triggers ahead of time. | /engineering:deploy-checklist [service or release name] |
| documentation | Write and maintain technical documentation. | Trigger with "write docs for", "document this", "create a README", "write a runbook", "onboarding guide", or when the user needs help with any form of technical writing — API docs, architecture docs, or operational runbooks. | /engineering:documentation |
| incident-response | Run an incident response workflow — triage, communicate, and write postmortem. | Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution. | /engineering:incident-response <incident description or alert> |
| standup | Generate a standup update from recent activity. | When preparing for daily standup, summarizing yesterday's commits and PRs and ticket moves, formatting work into yesterday/today/blockers, or structuring a few rough notes into a shareable update. | /engineering:standup [yesterday | today | blockers] |
| system-design | Design systems, services, and architectures. | Trigger with "design a system for", "how should we architect", "system design for", "what's the right architecture for", or when the user needs help with API design, data modeling, or service boundaries. | /engineering:system-design |
| tech-debt | Identify, categorize, and prioritize technical debt. | Trigger with "tech debt", "technical debt audit", "what should we refactor", "code health", or when the user asks about code quality, refactoring priorities, or maintenance backlog. | /engineering:tech-debt |
| testing-strategy | Design test strategies and test plans. | Trigger with "how should we test", "test strategy for", "write tests for", "test plan", "what tests do we need", or when the user needs help with testing approaches, coverage, or test architecture. | /engineering:testing-strategy |
Example
Ask in plain language and the right skill loads automatically, or call one directly:
/engineering:architecture <decision or system to design>