一键在 Manus 中运行任何 Skill

fix-issues

星标1

分支0

更新时间2026年7月16日 21:01

Validate reported issues against the codebase and fix confirmed ones with minimal, safe changes. Use when the user provides a list of issues, bugs, or review findings to triage and fix.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Kestral-Team

Kestral-Team/kstack

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Fix Issues

Discuss each issue, validate whether it is real, then fix all real issues with minimal changes.

Workflow

Restate each reported issue and mark one of:
- Confirmed (real bug/risk)
- Not reproducible (explain why)
- Needs clarification (missing facts)
For confirmed issues, identify the smallest safe fix and apply changes sequentially.
After each fix, re-evaluate whether later planned fixes still make sense.
Run lint/typecheck on touched files.
Summarize:
- what was fixed
- what was rejected (and why)
- remaining risks or follow-ups

Required Validation Checks

Transaction scope: no network/LLM/GCS I/O inside long DB transactions unless intentional and justified.
Rollback ownership (TOCTOU guard): destructive cleanup must use authoritative write-path ownership signals (for example wasCreated), never stale pre-check state.
Atomicity: related writes that must commit together share the same transaction client.
Error masking: cleanup failures should be logged and should not hide the original business failure.

Project Context

Read context.md and apply it as additional project-specific constraints layered on top of this workflow. If it does not exist, skip this section.

同仓库更多 Skills

同仓库

acceptance-check

Kestral-Team/kstack

Validate the branch diff against the task's acceptance criteria before marking it done. Use when implementation looks complete, before a status update to done/awaiting_review, or when the user asks "did we cover everything?"

2026-07-241

code-review

Kestral-Team/kstack

One-pass AI code review of a PR or branch diff (tech-lead style). Use when the user asks for a code review, PR review, AI review, or wants code quality, architecture, bugs, and patterns reviewed.

2026-07-241

code-simplify

Kestral-Team/kstack

Simplify changed code in a PR or branch for readability while preserving behavior. Use when the user asks to simplify code, reduce complexity, clean up a PR, or improve readability of recent changes.

2026-07-241

context-evolve

Kestral-Team/kstack

Capture new project-specific learnings into context files. Runs during reviews or after debugging to evolve the project's skill knowledge base. Use when the thread reveals patterns, anti-patterns, conventions, or codebase gotchas that should be remembered.

2026-07-241

debug-pipeline

Kestral-Team/kstack

Debug pipeline: investigate (prod or local) → fix-issues → scoped polish (deslop + code-simplify) → pattern-check → kestral-sync retroactive capture. Only invoked by the kstack subagent.

2026-07-241

decision-capture

Kestral-Team/kstack

Capture the decision when a spike, prototype, or investigation concludes. Use when a prototype or spike wraps up, the user makes a go/no-go call after de-risking, or an investigation answers its question — prompts "what did you decide?" and writes the decision + rationale to the task tracker.

2026-07-241

name	fix-issues
kstack	true
description	Validate reported issues against the codebase and fix confirmed ones with minimal, safe changes. Use when the user provides a list of issues, bugs, or review findings to triage and fix.

Fix Issues

Discuss each issue, validate whether it is real, then fix all real issues with minimal changes.

Workflow

Restate each reported issue and mark one of:
- Confirmed (real bug/risk)
- Not reproducible (explain why)
- Needs clarification (missing facts)
For confirmed issues, identify the smallest safe fix and apply changes sequentially.
After each fix, re-evaluate whether later planned fixes still make sense.
Run lint/typecheck on touched files.
Summarize:
- what was fixed
- what was rejected (and why)
- remaining risks or follow-ups

Required Validation Checks

Transaction scope: no network/LLM/GCS I/O inside long DB transactions unless intentional and justified.
Rollback ownership (TOCTOU guard): destructive cleanup must use authoritative write-path ownership signals (for example wasCreated), never stale pre-check state.
Atomicity: related writes that must commit together share the same transaction client.
Error masking: cleanup failures should be logged and should not hide the original business failure.

Project Context

Read context.md and apply it as additional project-specific constraints layered on top of this workflow. If it does not exist, skip this section.