القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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"} |
Use this skill when fixing a reported bug.
Reproduce before you fix. Do not guess at the cause or patch the symptom first.
Review these docs if you need context about the affected area:
docs/architecture/ARCHITECTURE.mddocs/quality/QUALITY-GRADES.mddocs/specs/USER-JOURNEYS.mddocs/workflows/REVIEW-CHECKLIST.mdExtract from the report:
If any of these are missing, ask for clarification before proceeding.
Write a failing test first.
The test must:
[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.
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.
refactor skill separately.Beyond the reproduction test, add:
docs/specs/journeys/
and docs/specs/USER-JOURNEYS.md if the bug exposed missing or inaccurate
journey coverage.docs/workflows/REVIEW-CHECKLIST.md.fix: [brief description of what was broken]Example 1: Missing validation at a boundary
Bug report: invalid input crashes a service method.
Action:
Example 2: Regression in existing behavior
Bug report: a previously supported workflow now returns the wrong result.
Action:
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.
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
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.
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).
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.
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.
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.