Token导航 LogoToken导航

Agent Skill · 研究检索

fix-issue(解决问题)

用于围绕 GitHub 仓库、Issue、Pull Request、分支、提交和代码协作流程提供辅助能力。它适合让 Agent 查询项目状态、整理变更、辅助创建或检查协作事项,并把仓库中的信息转成可执行的下一步。使用时需要区分只读查询和写入操作;涉及创建 PR、修改 Issue、推送分支或访问私有仓库时,应确认 token 权限、目标仓库范围和用户授权。

fix-issue 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描有未通过项,按安装量在研究检索类的 73,675 个 Skill 里排第 46,976。

总安装 753周安装 32GitHub Stars 6下载 264核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:fix-issue(解决问题)
来源仓库:https://github.com/duc01226/easyplatform
仓库路径:skills/fix-issue
安装命令:
npx skills add https://github.com/duc01226/easyplatform --skill fix-issue
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/duc01226/easyplatform --skill fix-issue

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

fix-issue 用于围绕 GitHub 仓库、Issue 和 PR 提供协作辅助,查询状态、整理变更或创建事项。适用于只读查询与写入操作,需确认 token 权限和仓库范围。通过 npx skills add 命令从指定 GitHub 仓库安装使用。涉及推送分支或修改 Issue 时应获得用户授权。

fix-issue 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/fix-issue

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/duc01226/easyplatform --skill fix-issue;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

fix-issue 怎么安装?

在终端执行 npx skills add https://github.com/duc01226/easyplatform --skill fix-issue。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

fix-issue 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

fix-issue 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

fix-issue 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

fix-issue 用的人多吗?

公开数据是累计安装 753 次,近一周安装 32 次,下载 264 次,GitHub 6 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

fix-issue 安全吗?

第三方扫描有未通过项,风险较高。除非你确认过源码,否则不建议直接安装到常用环境。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
fix-issue

解决问题 · 本页

7536需要联网未明确未通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.
Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code. 1. Search 3+ similar patterns (grep/glob) — cite file:line evidence 2. Read existing files in target area — understand structure, base classes, conventions 3. Run python.claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists 4. Map dependencies via connections or callers_of — know what depends on your target 5. Write investigation to .ai/workspace/analysis/ for non-trivial tasks (3+ files) 6. Re-read analysis file before implementing — never work from memory alone 7. NEVER invent new patterns when existing ones work — match exactly or document deviation BLOCKED until: - [] Read target files - [] Grep 3+ patterns - [] Graph trace (if graph.db exists) - [] Assumptions verified with evidence
Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof. 1. Cite file:line, grep results, or framework docs for EVERY claim 2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend 3. Cross-service validation required for architectural changes 4. "I don't have enough evidence" is valid and expected output BLOCKED until: - [] Evidence file path (file:line) - [] Grep search performed - [] 3+ similar patterns found - [] Confidence level stated Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."
  • docs/project-reference/domain-entities-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models) (content auto-injected by hook — check for [Injected:...] header before reading)
Estimation — Modified Fibonacci: 1(trivial) → 2(small) → 3(medium) → 5(large) → 8(very large) → 13(epic, SHOULD split) → 21(MUST ATTENTION split). Output story_points and complexity in plan frontmatter. Complexity auto-derived: 1-2=Low, 3-5=Medium, 8=High, 13+=Critical.
Skill Variant: Variant of /fix — debug and fix GitHub issues with systematic investigation.

Quick Summary

Goal: Investigate and fix bugs reported as GitHub issues with full traceability.

Workflow:

  1. Fetch — Read GitHub issue details (title, description, reproduction steps)
  2. Reproduce — Trace the reported behavior in code
  3. Fix — Apply fix with root cause evidence

Key Rules:

  • Debug Mindset: every claim needs file:line evidence
  • Link fix back to the GitHub issue for traceability
  • Verify fix addresses the specific reproduction steps from the issue
Root Cause Debugging — Systematic approach, never guess-and-check. 1. Reproduce — Confirm the issue exists with evidence (error message, stack trace, screenshot) 2. Isolate — Narrow to specific file/function/line using binary search + graph trace 3. Trace — Follow data flow from input to failure point. Read actual code, don't infer. 4. Hypothesize — Form theory with confidence %. State what evidence supports/contradicts it 5. Verify — Test hypothesis with targeted grep/read. One variable at a time. 6. Fix — Address root cause, not symptoms. Verify fix doesn't break callers via graph connections NEVER: Guess without evidence. Fix symptoms instead of cause. Skip reproduction step.

$ARGUMENTS

Debug Mindset (NON-NEGOTIABLE)

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

  • Do NOT assume the first hypothesis is correct — verify with actual code traces
  • Every root cause claim must include file:line evidence
  • If you cannot prove a root cause with a code trace, state "hypothesis, not confirmed"
  • Question assumptions: "Is this really the cause?" → trace the actual execution path
  • Challenge completeness: "Are there other contributing factors?" → check related code paths
  • No "should fix it" without proof — verify the fix addresses the traced root cause

⚠️ MANDATORY: Confidence & Evidence Gate

MANDATORY IMPORTANT MUST ATTENTION declare Confidence: X% with evidence list + file:line proof for EVERY claim. 95%+ recommend freely | 80-94% with caveats | 60-79% list unknowns | <60% STOP — gather more evidence.

⚠️ Validate Before Fix (NON-NEGOTIABLE): After root cause analysis, MUST ATTENTION present findings + proposed fix to user via AskUserQuestion and get explicit approval BEFORE any code changes. No silent fixes.

Activate debug-investigate skill and follow its workflow.

IMPORTANT: Always use external memory at .ai/workspace/analysis/issue-[number].analysis.md for structured analysis. Re-read ENTIRE analysis file before proposing any fix — this prevents knowledge loss.

🛑 Present root cause + proposed fix → AskUserQuestion → wait for user approval before implementing.

See .claude/docs/AI-DEBUGGING-PROTOCOL.md for comprehensive guidelines.

⚠️ MANDATORY: Post-Fix Verification

After applying the fix, MUST ATTENTION run /prove-fix — build code proof traces per change with confidence scores. Never skip.


Standalone Review Gate (Non-Workflow Only)

MANDATORY IMPORTANT MUST ATTENTION: If this skill is called outside a workflow (standalone /fix-issue), you MUST ATTENTION create a TaskCreate todo task for /review-changes as the last task in your task list. This ensures all changes are reviewed before commit even without a workflow enforcing it. If already running inside a workflow (e.g., bugfix), skip this — the workflow sequence handles /review-changes at the appropriate step.

Closing Reminders

MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting. MANDATORY IMPORTANT MUST ATTENTION validate decisions with user via AskUserQuestion — never auto-decide. MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality. MANDATORY IMPORTANT MUST ATTENTION READ the following files before starting:

  • MANDATORY IMPORTANT MUST ATTENTION search 3+ existing patterns and read code BEFORE any modification. Run graph trace when graph.db exists.
  • MANDATORY IMPORTANT MUST ATTENTION cite file:line evidence for every claim. Confidence >80% to act, <60% = do NOT recommend.
  • MANDATORY IMPORTANT MUST ATTENTION include story_points and complexity in plan frontmatter. SP > 8 = split.

平台分布

Codex

33.83%
按下载量换算89

Claude

28.93%
按下载量换算76

Cursor

19.13%
按下载量换算51

Gemini CLI

8.45%
按下载量换算22

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

未通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills