Agent审查

Name: Agent审查
Author: nyldn

工程开发社区

作者仓库星标 3,406
作者更新于实时读取
作者仓库 claude-octopus

流狐档案事实层信息：领域、Agent、信任分、运行环境、权限与网络

领域: 工程开发
兼容 Agent: Claude Code
Cursor
Cline
Codex
Windsurf
Gemini CLI

+20
信任分: 88 / 100 · 社区维护
作者 / 版本 / 许可: @nyldn · 未声明 license
Token 消耗评级: 低消耗
接入复杂程度: 需简单配置
是否需要外部 API Key: 不需要
兼容的系统: 未声明（默认跨平台）
底层运行要求: 无特殊要求
文件与系统权限: 只读
允许写入 / 修改
Shell 执行
网络行为: 仅限本地
安装命令数: 26 条

档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。

需要注意： 未限定 allowed-tools，默认拥有全部工具权限。

输出预览 skill-issues.preview

---
name: skill-issues
description: Track project blockers, bugs, and gaps across sessions — use when issues pile up or need triage…
category: 工程开发
runtime: 无特殊运行时
---

# skill-issues 输出预览

## PART A: 任务判断
- 适用问题：代码实现、重构、调试或代码审查。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“Overview / When to Use / Subcommands”读取原文规则，不把推断写成作者承诺。

## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于代码实现、重构、调试或代码审查，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“Overview / When to Use / Subcommands”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。

## Running Rules
- 读取文件、写入/修改文件、执行终端命令；主要在本地完成；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。

SKILL.md SKILL.md

---
name: skill-issues
description: Track project blockers, bugs, and gaps across sessions — use when issues pile up or need triage…
category: 工程开发
source: nyldn/claude-octopus
---

# skill-issues

## 什么时候使用
- 把工程方向的常用动作沉淀成 Agent 可调用的技能 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查，核心价值是把输入、判断、执行、验证和交付边界固定下来，避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代…
- 面向代码实现、重构、调试或代码审查，优先处理能明确输入、步骤和验收标准的工作。

## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。

## 执行规则
- 围绕「Overview / When to Use / Subcommands」组织步骤，不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令；主要在本地完成；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。

## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。

证据边界与执行链路

作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。

skill "skill-issues" {
  输入层     -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
  上下文层   -> Overview / When to Use / Subcommands
  规则层     -> SKILL.md 触发条件 / 执行顺序 / 输出格式
  运行层     -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
  安全层     -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
  输出层     -> 可复制结果 + 检查清单 + 下一步迭代
}

解读按原文结构重写，命令、链接、术语均保留；右侧可核对作者原始 SKILL.md

先判断是否适合

核心用途：把工程方向的常用动作沉淀成 Agent 可调用的技能适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查，核心价值是把输入、判断、执行、验证和交付边界固定下来，避免 Agent 泛泛回答。把任务拆成可执行、可检查、可继续迭代的步骤；通常不需要额…
适用任务：更适合工程开发场景下的代码实现、调试、重构、测试或代码审查，尤其是输入、步骤、验收口径可以反复复用的场景。
不宜硬套：如果任务只有一次性问答、来源材料很少，或需要作者没有说明的命令和外部服务，应先降级为普通对话。

作者设计意图

触发依据：使用时机、上下文收集、输出格式和失败处理共同决定它是否适合当前任务。
来源边界：作者原文负责事实，仓库文件负责命令和文件证据；Fluxly 只补充用途、限制和使用判断。

作者的方法与取舍

执行主线：任务围绕「Overview / When to Use / Subcommands」组织，把触发条件、必要上下文、执行规则和交付标准连成一条可复核的链路。
设计重点：重点不在重复教程，而在解释作者为什么规定这些步骤、哪些条件不可省略，以及结果偏离时应回到哪一层检查。
使用判断：先确认任务与原文边界一致，再决定是否启用；来源没有说明的命令、平台和依赖保持未知，不由 Fluxly 补写。

边界和复核

依赖条件：通常不需要额外 API Key，适合先用小任务验证触发是否稳定。
权限提醒：会涉及 read / write / shell-exec 权限，执行前要说明可读写范围、命令边界和回退方式。
质量标准：结果应包含明确产物、必要证据和下一步动作；如果只是泛泛解释，需要补充输入和验收条件后重跑。

Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than /octo:* slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, see skills/blocks/codex-host-adapter.md.

Issue Tracking

Overview

Cross-session issue tracking for persistent problem management. Issues are stored in .octo/ISSUES.md and survive across Claude Code sessions.

Core principle: Track → Resolve → Learn.

When to Use

Use this skill when user wants to:

Track a problem or blocker for later
Record issues discovered during development
Review open issues across sessions
Mark issues as resolved
View details of specific issues

Do NOT use for:

GitHub issue management (use gh CLI)
Git-tracked issues (use git commands)
Temporary todos (use task plan tool)

Subcommands

1. List Issues (Default)

Trigger: /octo:issues or /octo:issues list

Show all open issues in table format:

## Open Issues

| ID | Severity | Category | Description | Created | Phase |
|----|----------|----------|-------------|---------|-------|
| ISS-20260203-001 | high | integration | Auth not working | 2026-02-03 | Develop |
| ISS-20260203-002 | medium | performance | Slow query performance | 2026-02-03 | Deliver |

Pattern Detection: After listing, check if 3+ open issues share the same category. If so, alert:

⚠ Pattern detected: 3 open issues in category "integration" — may indicate a systemic problem.

Implementation:

Check if .octo/ISSUES.md exists
If not, initialize from template
Read and parse Open Issues section
Display in table format

2. Add Issue

Trigger: /octo:issues add <description>

Add new issue with auto-generated ID.

Flow:

Step 1: Gather Information

Use AskUserQuestion with two questions:

AskUserQuestion({
  questions: [
    {
      question: "What severity is this issue?",
      header: "Severity",
      multiSelect: false,
      options: [
        {label: "critical", description: "Blocks all progress"},
        {label: "high", description: "Significant impact"},
        {label: "medium", description: "Should address"},
        {label: "low", description: "Nice to fix"}
      ]
    },
    {
      question: "What category does this issue fall into?",
      header: "Category",
      multiSelect: false,
      options: [
        {label: "logic-error", description: "Incorrect behavior or wrong output"},
        {label: "integration", description: "Cross-component or API compatibility"},
        {label: "quality-gate", description: "Quality gate failures during workflows"},
        {label: "security", description: "Security vulnerabilities or concerns"},
        {label: "performance", description: "Speed, memory, or scalability issues"},
        {label: "ux", description: "User experience or usability problems"},
        {label: "architecture", description: "Structural or design pattern issues"}
      ]
    }
  ]
})

Step 2: Determine Current Phase

# Check if STATE.md exists
if [ -f .octo/STATE.md ]; then
  grep "current_phase:" .octo/STATE.md
else
  echo "Unknown"
fi

Step 3: Generate Issue ID

Format: ISS-YYYYMMDD-NNN

# Get today's date
TODAY=$(date +%Y%m%d)

# Find existing issues for today
grep "ISS-${TODAY}-" .octo/ISSUES.md | tail -1

# Increment sequence number
# If ISS-20260203-001 exists, next is ISS-20260203-002

Step 4: Append to ISSUES.md

Add new row to Open Issues table:

| ISS-20260203-003 | medium | performance | Slow query performance | 2026-02-03 | Develop |

Preserve existing issues - append only, don't overwrite.

Step 5: Confirm

✅ Issue created: ISS-20260203-003

**Severity:** medium
**Category:** performance
**Description:** Slow query performance
**Created:** 2026-02-03
**Phase:** Develop

View with: /octo:issues show ISS-20260203-003

3. Resolve Issue

Trigger: /octo:issues resolve <id>

Mark issue as resolved and move to Resolved section.

Flow:

Step 1: Validate Issue Exists

# Check if issue ID exists in Open Issues
grep "ISS-20260203-001" .octo/ISSUES.md

If not found, show error:

❌ Issue ISS-20260203-001 not found in open issues.

Use `/octo:issues list` to see all open issues.

Step 2: Ask for Resolution Notes

**Resolving issue:** ISS-20260203-001

Please provide resolution notes:

Step 3: Move to Resolved Section

Extract issue row from Open Issues table
Remove from Open Issues
Add to Resolved Issues with resolution date and notes

Resolved Issues format:

| ID | Severity | Category | Description | Created | Resolved | Resolution |
|----|----------|----------|-------------|---------|----------|------------|
| ISS-20260203-001 | high | integration | Auth not working | 2026-02-03 | 2026-02-04 | Fixed OAuth token refresh |

Step 4: Confirm

✅ Issue resolved: ISS-20260203-001

**Resolution date:** 2026-02-04
**Resolution notes:** Fixed OAuth token refresh

View with: /octo:issues show ISS-20260203-001

4. Show Issue Details

Trigger: /octo:issues show <id>

Display full details of specific issue.

Flow:

Step 1: Find Issue

Search both Open and Resolved sections for issue ID.

Step 2: Display Details

For open issue:

## Issue Details: ISS-20260203-001

**Status:** Open
**Severity:** high
**Category:** integration
**Description:** Auth not working
**Created:** 2026-02-03
**Phase:** Develop

**Actions:**
- Resolve: `/octo:issues resolve ISS-20260203-001`

For resolved issue:

## Issue Details: ISS-20260203-001

**Status:** Resolved
**Severity:** high
**Category:** integration
**Description:** Auth not working
**Created:** 2026-02-03
**Resolved:** 2026-02-04
**Resolution:** Fixed OAuth token refresh

Step 3: If Not Found

❌ Issue ISS-20260203-001 not found.

Use `/octo:issues list` to see all open issues.

File Management

Initialize ISSUES.md

When: First time skill is used or .octo/ISSUES.md doesn't exist.

Action:

# Create .octo directory if needed
mkdir -p .octo

# Copy template
cp ${HOME}/.claude-octopus/plugin/config/templates/ISSUES.md.template .octo/ISSUES.md

# Replace {{PROJECT_NAME}} with actual project name
PROJECT_NAME=$(basename $(pwd))
sed -i '' "s/{{PROJECT_NAME}}/$PROJECT_NAME/g" .octo/ISSUES.md

Preserve Existing Issues

CRITICAL: When adding or resolving issues, NEVER overwrite existing content.

Pattern:

# Read existing content
EXISTING=$(cat .octo/ISSUES.md)

# Modify specific section only
# Append new issue to Open Issues table
# OR move issue from Open to Resolved

# Write back with all content preserved
echo "$MODIFIED" > .octo/ISSUES.md

ID Generation Algorithm

Format: ISS-YYYYMMDD-NNN

Example: ISS-20260203-001

Implementation:

#!/bin/bash

# Get today's date in YYYYMMDD format
TODAY=$(date +%Y%m%d)

# Find all issues created today
TODAY_ISSUES=$(grep -o "ISS-${TODAY}-[0-9]\{3\}" .octo/ISSUES.md || echo "")

if [ -z "$TODAY_ISSUES" ]; then
  # No issues today, start at 001
  NEXT_NUM="001"
else
  # Get highest number for today
  HIGHEST=$(echo "$TODAY_ISSUES" | sed "s/ISS-${TODAY}-//" | sort -n | tail -1)
  
  # Increment
  NEXT_NUM=$(printf "%03d" $((10#$HIGHEST + 1)))
fi

# Generate ID
ISSUE_ID="ISS-${TODAY}-${NEXT_NUM}"
echo "$ISSUE_ID"

Severity Levels

Level	Meaning	Example
critical	Blocks all progress	Production down, data loss
high	Significant impact	Feature broken, security issue
medium	Should address	Performance degradation, UX issue
low	Nice to fix	Minor bug, cosmetic issue

Integration with Other Skills

With skill-debug

User: "track this bug for later"

1. Use skill-issues to create issue
2. Use skill-debug to investigate if time permits
3. Link issue ID in debug notes

With skill-task-management

User: "add fixing ISS-20260203-001 to todos"

1. Use skill-task-management to add todo
2. Reference issue ID in todo description
3. Mark issue as resolved when todo completes

With flow-develop

User: "implement fix for ISS-20260203-001"

1. Use flow-develop to implement fix
2. Use skill-issues to resolve issue after fix
3. Link commit SHA in resolution notes

Best Practices

1. Clear Descriptions

Good:

Auth token refresh fails after 15 minutes

Poor:

Auth broken

2. Appropriate Severity

Critical: Only for blockers that stop all work High: Significant but workarounds exist Medium: Should fix but not urgent Low: Nice to have

3. Resolution Notes

Good:

Fixed OAuth token refresh by updating expiration logic in auth.ts
Commit: abc123

Poor:

Fixed

Common Patterns

Pattern 1: Track During Development

User: "track this issue: API rate limiting not working"

Action:
1. Create issue with appropriate severity
2. Record current phase from STATE.md
3. Continue development

Pattern 2: Resolve After Fix

User: "resolve ISS-20260203-001, fixed in commit abc123"

Action:
1. Ask for resolution notes
2. Move to Resolved section
3. Record resolution date and notes

Pattern 3: Review Open Issues

User: "what issues do we have?"

Action:
1. List all open issues
2. Show severity and phase
3. Offer to show details or resolve

Red Flags - Don't Do This

Action	Why It's Wrong
Overwrite ISSUES.md	Lose all existing issues
Skip severity validation	Invalid data in file
Duplicate issue IDs	ID collision
Vague descriptions	Can't remember what issue was
Resolve without notes	No record of what was done

Quick Reference

User Intent	Skill Action	Output
"list issues"	Read and display Open Issues	Table of issues
"add issue X"	Generate ID, append to file	Issue created
"resolve ISS-X"	Move to Resolved section	Issue resolved
"show ISS-X"	Find and display details	Issue details

The Bottom Line

Issue tracking → Persistent memory across sessions
Otherwise → Forget problems, repeat mistakes

Track everything. Resolve systematically. Learn from history.

安装命令

一键复制安装选择包管理器,点击右侧复制,粘贴到终端回车即可

npx skills add nyldn/claude-octopus/skills/skill-issues -y

查看通用安装教程

查看 Skill 原文

兼容工具

Claude Code
Cursor
Cline
Codex
Windsurf
Gemini
OpenCode
Roo Code
AAide
+Augment
GitHub Copilot
OpenClaw
KKiro
Junie
WWarp
Goose
Trae
Kilo Code
OpenHands
Amp
Zencoder
CContinue
AIAider
CodeBuddy
CodeGeeX
Replit Agent

安全审计

88 / 100

社区

未声明 license/许可。
未声明 version。
未限定 allowed-tools，默认拥有全部工具权限。

元信息

来源: github
nyldn/claude-octopus
English

@nyldn 的其他技能

分类与标签

分类工程开发

先判断是否适合

作者设计意图

作者的方法与取舍

边界和复核

Issue Tracking

Overview

When to Use

Subcommands

1. List Issues (Default)

2. Add Issue

Step 1: Gather Information

Step 2: Determine Current Phase

Step 3: Generate Issue ID

Step 4: Append to ISSUES.md

Step 5: Confirm

3. Resolve Issue

Step 1: Validate Issue Exists

Step 2: Ask for Resolution Notes

Step 3: Move to Resolved Section

Step 4: Confirm

4. Show Issue Details

Step 1: Find Issue

Step 2: Display Details

Step 3: If Not Found

File Management

Initialize ISSUES.md

Preserve Existing Issues

ID Generation Algorithm

Severity Levels

Integration with Other Skills

With skill-debug

With skill-task-management

With flow-develop

Best Practices

1. Clear Descriptions

2. Appropriate Severity

3. Resolution Notes

Common Patterns

Pattern 1: Track During Development

Pattern 2: Resolve After Fix

Pattern 3: Review Open Issues

Red Flags - Don't Do This

Quick Reference

The Bottom Line

讨论