ワンクリックでManusで任意のスキルを実行

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 リポジトリを開く Creator のリポジトリを見る

ダウンロード

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.