From 861bab677b4632e9d30e6318bc2a35c36ee77105 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 29 Mar 2026 16:25:05 -0500 Subject: Add general-purpose skills and rules from DeepSat coding-rulesets Skills (adapted from DeepSat, stripped of project-specific references): - /review-pr: PR review against engineering standards - /fix-issue: issue-to-merge TDD workflow - /security-check: secrets, OWASP, and dependency audit - /debug: systematic 4-phase debugging - /add-tests: test coverage analysis and generation - /respond-to-review: evaluate and implement code review feedback Rules (general-purpose, copied as-is): - testing.md: universal TDD standards and anti-patterns - verification.md: proof over assumption Makefile updated to install both skills and rules via symlinks. Co-Authored-By: Claude Opus 4.6 (1M context) --- fix-issue/SKILL.md | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 fix-issue/SKILL.md (limited to 'fix-issue/SKILL.md') diff --git a/fix-issue/SKILL.md b/fix-issue/SKILL.md new file mode 100644 index 0000000..adfed14 --- /dev/null +++ b/fix-issue/SKILL.md @@ -0,0 +1,54 @@ +# /fix-issue — Pick Up and Implement an Issue + +Create a branch, implement the fix, test, and commit. + +## Usage + +``` +/fix-issue [ISSUE_ID] +``` + +If no issue ID is given, prompt the user to provide one or describe the issue. + +## Instructions + +1. **Fetch the issue** from the project's issue tracker (Linear, GitHub Issues, Jira, etc.) or ask the user for the issue details (title, description, acceptance criteria). + +2. **Create a branch** following the naming convention: + - Bug: `fix/ISSUE_ID-short-description` + - Feature: `feature/ISSUE_ID-short-description` + - Chore: `chore/ISSUE_ID-short-description` + +3. **Explore the codebase and find the root cause**: + - Do NOT jump to a fix. Read the relevant modules, trace the data flow, and understand how the system works around the issue. + - Identify the **root cause**, not just the surface symptom. If a value is wrong in a handler, trace it back through the service, model, schema, or migration — wherever the real problem lives. + - Read callers, callees, and related tests to understand the full context of the change. + - Follow the project's coding standards and conventions + - Keep changes focused — only what the issue requires + - If the change involves data flow, confirm API contracts (schemas, typed clients) exist or create them first + - No drive-by refactoring or scope creep + +4. **Write failing test first (TDD)** — before any implementation code: + - Create a test file if one doesn't exist for the module + - Write a test that demonstrates the bug or defines the desired behavior — this proves you understand the root cause + - Run the test — confirm it **fails** + - Commit: `test: Add failing test for [issue]` + +5. **Implement the fix**: + - Write the minimal code to make the failing test pass + - Run the test — confirm it **passes** + - Commit: `fix: [description]` + +6. **Add edge case tests — be thorough**: + - Add boundary and error case tests (normal, boundary, and error categories) + - Think through all edge cases: empty inputs, nulls, concurrent access, large data, permission boundaries, and interactions with adjacent modules + - Run the full test suite to confirm nothing is broken + - Commit: `test: Add edge cases for [issue]` + +7. **Refactor if needed**: + - Clean up the implementation while all tests stay green + - Commit: `refactor: [description]` + +All commits must use conventional messages (`feat:`, `fix:`, `chore:`, `test:`, `refactor:`), reference the issue ID in the body, and contain no AI attribution. + +8. **Report** what was done: files changed, tests added, and any open questions. -- cgit v1.2.3