bug-fix

Étoiles0

Forks0

Mis à jour15 avril 2026 à 13:57

Reproduce and fix reported bugs with test-first verification and root-cause analysis. Use when debugging a defect, investigating unexpected behavior, triaging a regression, or implementing a minimal corrective fix.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

alkampfergit

alkampfergit/lucifer

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	bug-fix
description	Reproduce and fix reported bugs with test-first verification and root-cause analysis. Use when debugging a defect, investigating unexpected behavior, triaging a regression, or implementing a minimal corrective fix.
metadata	{"author":"ai-landscape","version":"1.0.0","category":"workflow"}

Skill: Bug Fix

Use this skill when fixing a reported bug.

Core Rule

Reproduce before you fix. Do not guess at the cause or patch the symptom first.

Repository Context

Review these docs if you need context about the affected area:

docs/architecture/ARCHITECTURE.md
docs/quality/QUALITY-GRADES.md
docs/specs/USER-JOURNEYS.md
docs/workflows/REVIEW-CHECKLIST.md

Workflow

Step 1: Understand the Bug Report

Extract from the report:

Expected behavior: What should happen?
Actual behavior: What happens instead?
Reproduction steps: How do you trigger the bug?
Context: Which domain, endpoint, input, or workflow is affected?
Journey mapping: Which existing user journey or story should cover this behavior?

If any of these are missing, ask for clarification before proceeding.

Step 2: Reproduce

Write a failing test first.

The test must:

Exercise the exact scenario described in the report.
Fail with the current code, proving the bug exists.
Use a descriptive name such as [unit]_[bugScenario]_[expectedCorrectBehavior].

If you cannot reproduce the bug with a test, investigate using logs, metrics, traces, or other observability tools if available. Do not implement a fix until the failure mode is understood.

Step 3: Locate the Root Cause

Trace execution from the reproduction test.
Identify the exact line, condition, or boundary where behavior diverges.
Classify the problem: logic error, missing validation, data-shape mismatch, or integration issue.

Fix the root cause, not the symptom. If the real problem is missing boundary validation and the symptom is a null reference, fix the validation instead of adding a defensive null check in the wrong place.

Step 4: Implement the Fix

Make the smallest change that fixes the root cause.
Do not refactor unrelated code in the same change. Use the refactor skill separately.
Verify the failing test now passes.
Check for similar patterns elsewhere and record follow-up tasks if needed.

Step 5: Add Regression Coverage

Beyond the reproduction test, add:

Tests for related edge cases the bug exposed.
A linter rule or structural test when the bug came from a missing invariant that should be enforced mechanically.
A documentation update to the matching file under docs/specs/journeys/ and docs/specs/USER-JOURNEYS.md if the bug exposed missing or inaccurate journey coverage.

Step 6: Validate and Submit

All existing and new tests pass.
Linter and CI are green.
Review the change against docs/workflows/REVIEW-CHECKLIST.md.
PR title: fix: [brief description of what was broken]
PR description includes:
- Root cause analysis in one or two sentences.
- What the fix does.
- Any follow-up tasks identified.

Examples

Example 1: Missing validation at a boundary

Bug report: invalid input crashes a service method.

Action:

Add a failing test with the invalid input.
Trace the failure to the missing validation layer.
Add validation at the boundary.
Add one or two edge-case tests.

Example 2: Regression in existing behavior

Bug report: a previously supported workflow now returns the wrong result.

Action:

Add a reproduction test that models the old working behavior.
Identify the code path that changed.
Restore the intended behavior with the smallest change.
Add regression coverage for neighboring cases.

Troubleshooting

Question: I cannot reproduce the bug.

Stop and gather more context. Confirm environment, inputs, and timing, then use available observability data before changing code.

Question: Several fixes look plausible.

Use the failing test and execution trace to eliminate hypotheses. Do not pick a fix based on intuition alone.

Question: The reproduction test passes after my change, but other tests fail.

Treat that as evidence that the fix was incomplete or targeted the wrong layer. Re-check the root-cause analysis.

Guardrails

Do not skip the reproduction step.
Do not mix unrelated refactors into the fix.
Do not close the task without regression coverage.

Plus depuis ce dépôt

même dépôt

gstack-gh

alkampfergit/lucifer

Take a single GitHub issue (by number or URL) and drive it through an end-to-end flow (branch → plan → build → test → PR) using the `gh` CLI. All user interaction happens through issue comments, never the console. Use when the user says "implement issue

2026-04-210

gh-security-and-quality

alkampfergit/lucifer

Triage and fix GitHub-reported security and quality findings — Dependabot alerts, code-scanning (CodeQL) alerts, and secret / malware scanning alerts — for this repository using `gh`, `npm`, and language-specific toolchains. Use when the user asks to review the Security tab, clear open alerts across any of the three surfaces, merge Dependabot PRs, or explain why an alert is safe to dismiss. Pairs with the `gh-cli-guide` skill for the underlying API calls. Does NOT auto-invoke `github-pr-fixer` — once a fix PR is opened, this skill stops and the owner chooses whether to run `/github-pr-fixer` manually.

2026-04-200

gstack-full

alkampfergit/lucifer

Poll GitHub for open issues carrying a user-specified label and drive each one through gstack's end-to-end flow (plan → build → test → ship) via the `gstack-gh` skill. Use when the user says "watch GH for issues with label X and implement them", "auto-process the backlog", or "poll for ready stories". Supports three scheduling modes — in-session loop, self-paced loop, or cron (remote trigger).

2026-04-200

doc-gardening

alkampfergit/lucifer

Scan the repository for stale, broken, or missing documentation and repair the highest-priority issues. Use when auditing docs, checking AGENTS links, reconciling docs with code, or running periodic documentation maintenance.

2026-04-150

new-feature

alkampfergit/lucifer

End-to-end workflow for adding a new feature from a task or prompt description. Use when implementing a new capability, adding an endpoint, introducing a new service method, or building a new UI component.

2026-04-150

refactor

alkampfergit/lucifer

Improve code structure without changing behavior using safe, test-preserving refactoring steps. Use when extracting helpers, splitting files, reducing duplication, aligning with repository patterns, or cleaning up code.

2026-04-150

name	bug-fix
description	Reproduce and fix reported bugs with test-first verification and root-cause analysis. Use when debugging a defect, investigating unexpected behavior, triaging a regression, or implementing a minimal corrective fix.
metadata	{"author":"ai-landscape","version":"1.0.0","category":"workflow"}

Skill: Bug Fix

Use this skill when fixing a reported bug.

Core Rule

Reproduce before you fix. Do not guess at the cause or patch the symptom first.

Repository Context

Review these docs if you need context about the affected area:

docs/architecture/ARCHITECTURE.md
docs/quality/QUALITY-GRADES.md
docs/specs/USER-JOURNEYS.md
docs/workflows/REVIEW-CHECKLIST.md

Workflow

Step 1: Understand the Bug Report

Extract from the report:

Expected behavior: What should happen?
Actual behavior: What happens instead?
Reproduction steps: How do you trigger the bug?
Context: Which domain, endpoint, input, or workflow is affected?
Journey mapping: Which existing user journey or story should cover this behavior?

If any of these are missing, ask for clarification before proceeding.

Step 2: Reproduce

Write a failing test first.

The test must:

Exercise the exact scenario described in the report.
Fail with the current code, proving the bug exists.
Use a descriptive name such as [unit]_[bugScenario]_[expectedCorrectBehavior].

If you cannot reproduce the bug with a test, investigate using logs, metrics, traces, or other observability tools if available. Do not implement a fix until the failure mode is understood.

Step 3: Locate the Root Cause

Trace execution from the reproduction test.
Identify the exact line, condition, or boundary where behavior diverges.
Classify the problem: logic error, missing validation, data-shape mismatch, or integration issue.

Step 4: Implement the Fix

Make the smallest change that fixes the root cause.
Do not refactor unrelated code in the same change. Use the refactor skill separately.
Verify the failing test now passes.
Check for similar patterns elsewhere and record follow-up tasks if needed.

Step 5: Add Regression Coverage

Beyond the reproduction test, add:

Tests for related edge cases the bug exposed.
A linter rule or structural test when the bug came from a missing invariant that should be enforced mechanically.
A documentation update to the matching file under docs/specs/journeys/ and docs/specs/USER-JOURNEYS.md if the bug exposed missing or inaccurate journey coverage.

Step 6: Validate and Submit

All existing and new tests pass.
Linter and CI are green.
Review the change against docs/workflows/REVIEW-CHECKLIST.md.
PR title: fix: [brief description of what was broken]
PR description includes:
- Root cause analysis in one or two sentences.
- What the fix does.
- Any follow-up tasks identified.

Examples

Example 1: Missing validation at a boundary

Bug report: invalid input crashes a service method.

Action:

Add a failing test with the invalid input.
Trace the failure to the missing validation layer.
Add validation at the boundary.
Add one or two edge-case tests.

Example 2: Regression in existing behavior

Bug report: a previously supported workflow now returns the wrong result.

Action:

Add a reproduction test that models the old working behavior.
Identify the code path that changed.
Restore the intended behavior with the smallest change.
Add regression coverage for neighboring cases.

Troubleshooting

Question: I cannot reproduce the bug.

Stop and gather more context. Confirm environment, inputs, and timing, then use available observability data before changing code.

Question: Several fixes look plausible.

Use the failing test and execution trace to eliminate hypotheses. Do not pick a fix based on intuition alone.

Question: The reproduction test passes after my change, but other tests fail.

Treat that as evidence that the fix was incomplete or targeted the wrong layer. Re-check the root-cause analysis.

Guardrails

Do not skip the reproduction step.
Do not mix unrelated refactors into the fix.
Do not close the task without regression coverage.