Software Engineering Toolkit

View saved version →

---
name: codebase-design
description: Design deep modules with small interfaces, clear seams, and testable responsibilities.
---

# Codebase Design

Place behavior behind cohesive interfaces. Reduce coupling, hide implementation detail, name concepts consistently, and make important rules testable at a stable seam. Prefer a small number of deep modules over many shallow wrappers.

View saved version →

---
name: code-review
description: Review changes against both engineering standards and the originating specification.
---

# Code Review

Review a fixed diff range. Check correctness, edge cases, error handling, security, performance, maintainability, tests, and consistency with repository conventions. Separately check whether the implementation faithfully satisfies the spec. Report actionable findings with severity and evidence.

View saved version →

---
name: diagnosing-bugs
description: Diagnose bugs and regressions through reproduction, minimization, instrumentation, fixing, and regression testing.
---

# Diagnosing Bugs

Reproduce the issue, minimize the failing case, record expected versus actual behavior, form competing hypotheses, instrument the path, verify the root cause, implement the narrow fix, and add a regression test. Do not jump directly to a speculative patch.

View saved version →

---
name: domain-modeling
description: Build a shared vocabulary and test it against real scenarios before changing code.
---

# Domain Modeling

Extract domain terms, definitions, entities, states, events, invariants, ownership, and boundaries. Challenge ambiguous words with concrete examples and edge cases. Keep the glossary and decisions consistent with code, tests, and documentation.

View saved version →

---
name: grilling
description: Interview the user until a plan, design, or decision is specific enough to execute.
---

# Grilling

Ask focused questions about users, behavior, boundaries, edge cases, data, errors, constraints, rollout, and success. Resolve branches one at a time. Keep a decision log, state assumptions, and stop when remaining uncertainty no longer changes implementation.

View saved version →

---
name: handoff-and-context
description: Create compact handoffs and shared project context so another agent can continue accurately.
---

# Handoff and Context

Record goal, current state, decisions, terminology, changed files, evidence, tests, blockers, risks, and exact next action. Keep facts separate from assumptions. Prefer durable project documentation over relying on conversation memory.

View saved version →

---
name: implementation
description: Implement specs or tickets in small slices with tests, review, and a clear completion report.
---

# Implementation

Read the spec and repository first. Resolve blockers before editing. Implement one coherent slice at a time, drive tests at agreed seams, keep unrelated changes out, run proportionate checks, and finish with a diff review and evidence-based summary.

View saved version →

---
name: merge-conflicts
description: Resolve merge or rebase conflicts by tracing intent and preserving both sides where appropriate.
---

# Merge Conflicts

Inspect each hunk, understand the intent of both changes from their primary sources, resolve by behavior rather than proximity, run focused tests, inspect the final diff, and complete the merge or rebase only when the result is coherent. Never discard a side blindly.

View saved version →

---
name: prototyping
description: Build small throwaway prototypes to answer uncertain design, interaction, or technical questions.
---

# Prototyping

State the question the prototype must answer, keep scope intentionally disposable, explore materially different options when useful, measure the result, and document what was learned. Do not let a prototype silently become production architecture.

View saved version →

---
name: research
description: Investigate engineering questions with high-trust primary sources and cited findings.
---

# Engineering Research

Define the question, constraints, and decision. Prefer official documentation, standards, source code, issue trackers, papers, and first-party announcements. Capture findings, citations, alternatives, uncertainty, and the decision impact in a concise Markdown report.

View saved version →

---
name: software-engineering-toolkit
description: Route engineering work into disciplined alignment, design, testing, diagnosis, review, research, and delivery workflows.
---

# Software Engineering Toolkit

Use this plugin when software work needs stronger alignment, feedback loops, architecture, or delivery discipline. Route to focused skills under `skills/` and combine them when appropriate.

## Core loop

Align on intent → model the domain → write a testable spec → choose a clean seam → implement a small slice → verify with feedback → review the result → document decisions and hand off.

Never claim repository access, execution, testing, or deployment that did not occur. Keep user-invoked orchestration distinct from reusable model-invoked discipline.

View saved version →

---
name: tdd
description: Drive implementation with a red-green-refactor loop and meaningful behavior tests.
---

# Test-Driven Development

Choose a behavior seam, write a failing test that expresses the requirement, implement the smallest passing change, then refactor without losing coverage. Test failure states, boundaries, permissions, and regression cases—not only the happy path.

View saved version →

---
name: to-spec
description: Turn a conversation or request into a precise, testable engineering specification.
---

# To Spec

Produce context, problem, goals, non-goals, domain terms, user stories, behavior, edge cases, constraints, acceptance criteria, affected areas, test plan, rollout, and open decisions. Keep each requirement observable and avoid invented details.

View saved version →

---
name: to-tickets
description: Break a plan into small tracer-bullet tickets with dependencies and completion criteria.
---

# To Tickets

Split work into independently verifiable slices. Each ticket includes outcome, scope, non-goals, blocking edges, acceptance tests, and evidence required for completion. Prefer vertical value slices over layers of disconnected setup.

View saved version →

---
name: writing-for-agents
description: Write concise, discoverable instructions and project documents that agents can follow reliably.
---

# Writing for Agents

State scope, triggers, inputs, outputs, constraints, examples, verification, and failure behavior. Use precise terms from the project domain. Keep instructions composable, avoid conflicting rules, and link to deeper references instead of duplicating them.