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-resume.preview

---
name: skill-resume
description: Pick up where you left off from a previous session — use after context resets, compaction, or ne…
category: 工程开发
runtime: 无特殊运行时
---

# skill-resume 输出预览

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

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

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

SKILL.md SKILL.md

---
name: skill-resume
description: Pick up where you left off from a previous session — use after context resets, compaction, or ne…
category: 工程开发
source: nyldn/claude-octopus
---

# skill-resume

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

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

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

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

证据边界与执行链路

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

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

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

先判断是否适合

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

作者设计意图

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

作者的方法与取舍

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

Session Restoration

Overview

Restore context from a previous session and seamlessly continue the workflow where you left off.

Core principle: Check state → Load adaptive context → Display restoration summary → Route to appropriate action.

When to Use

Use this skill when user says:

"Resume" or "continue working"
"Pick up where I left off"
"What was I doing?"
"Restore session"
"Continue from last time"

Do NOT use for:

Starting new projects (use /octo:embrace)
Checking current status only (use /octo:status)
Modifying state directly (use octo-state.sh)

The Process

Phase 0: Check Session Handoff File (v9.6.0)

Step 0: Check for .octo-continue.md

Before checking .octo/, look for a session handoff file. This is written automatically by PreCompact and SessionEnd hooks and contains a human-readable summary of the last session.

if [[ -f ".octo-continue.md" ]]; then
    cat ".octo-continue.md"
fi

If .octo-continue.md exists, read it and display its contents to the user as context. Then continue to Phase 1 to load the full state. The handoff file provides a quick overview; .octo/STATE.md provides the authoritative state.

Phase 1: Check Project Initialization

Step 1: Verify .octo/ Directory Exists

if [[ ! -d ".octo" ]]; then
    echo "No project state found"
    exit 1
fi

If .octo/ does not exist but .octo-continue.md exists, display the handoff file contents and offer to start a new session based on that context.

If neither exists, display:

## Session Restoration Failed

**No project state found.**

There is no `.octo/` directory in this project, which means no previous session state exists.

### Get Started

Run `/octo:embrace [your project description]` to start a new project.

**Example:**

/octo:embrace build a REST API with user authentication


This will:
1. Initialize .octo/ directory with STATE.md, PROJECT.md, ROADMAP.md
2. Begin the Double Diamond workflow
3. Create session state you can resume later

Stop here - do not proceed to Phase 2.

Phase 2: Read Current State

Step 1: Execute octo-state.sh read_state

./scripts/octo-state.sh read_state

Expected output format:

schema=2.0
last_updated=2026-02-02T10:30:00Z
current_phase=2
current_position=define-requirements
status=in_progress

Step 2: Parse State Variables

Extract these key values:

current_phase - Phase number (1-4)
current_position - Description of current position within phase
status - Workflow status (in_progress, blocked, complete, paused, etc.)
last_updated - Timestamp of last state modification

Phase 3: Load Adaptive Context

Step 1: Get Context Tier (Auto Mode)

./scripts/octo-state.sh get_context_tier auto

This automatically selects the appropriate context tier based on current status:

Status	Tier Selected	Context Loaded
ready, planned, planning, complete, shipped	planning	STATE.md + PROJECT.md + ROADMAP.md
building, in_progress	execution	+ phase plans + recent summaries
blocked, paused	execution	+ phase plans + recent summaries

Step 2: Store Context for Reference

The context returned includes:

Current state details
Project vision and requirements
Phase-specific plans and summaries
Codebase analysis (if brownfield project)

Phase 4: Extract History and Blockers

Step 1: Read Last 3 History Entries from STATE.md

# Extract history section from STATE.md
grep -A 4 "^## History" .octo/STATE.md | tail -n 3

Expected format:

- [2026-02-02T10:30:00Z] Phase 2: Completed requirements review (complete)
- [2026-02-02T09:15:00Z] Phase 2: Started define phase (in_progress)
- [2026-02-01T16:45:00Z] Phase 1: Completed discovery (complete)

Step 2: Extract Blockers from STATE.md

# Extract blockers section
sed -n '/^## Blockers/,/^## /p' .octo/STATE.md | head -n -1 | tail -n +2

Expected format:

If blockers exist: List of blocker items
If no blockers: (none)

Step 3: Read Project Title from PROJECT.md

# Get project title (first H1)
head -n 5 .octo/PROJECT.md | grep "^# " | head -1 | sed 's/^# //'

Phase 5: Display Restoration Summary

Step 1: Build and Display Summary

## Session Restored

**Project:** {project_title from PROJECT.md}
**Last Active:** {last_updated from STATE.md}
**Phase:** {current_phase} - {phase_name}
**Position:** {current_position}
**Status:** {status}

### Where You Left Off

{Last 3 entries from STATE.md history}

### Current Blockers

{Blockers from STATE.md or "None"}

### Ready to Continue

{Intelligent suggestion based on status - see routing table below}

Step 2: Map Phase Number to Name

Phase	Name
1	Discover
2	Define
3	Develop
4	Deliver

Phase 6: Intelligent Routing

Step 1: Route Based on Status

Status	Action	Message
`in_progress`	Continue current phase	"Continue with current phase. Context loaded."
`blocked`	Review blockers	"Review blockers first: `/octo:issues`"
`complete`	Ready for next phase	"Phase complete. Ready for `/octo:ship`"
`paused`	Resume project	"Project paused. Resume with `/octo:embrace`"
`ready`	Begin workflow	"Ready to begin. Run `/octo:embrace` to start."
`planning`	Continue planning	"Continue planning. Use `/octo:define` to refine."
`building`	Continue building	"Continue implementation. Use `/octo:develop`."
`shipped`	Project delivered	"Project delivered! Review lessons in LESSONS.md."
`complete_with_gaps`	Review gaps	"Phase complete with gaps. Review ISSUES.md before proceeding."

Step 2: Phase-Specific Guidance (for in_progress status)

Phase 1 (Discover):

Continue research and exploration.
- Use `/octo:research [topic]` for multi-AI research
- Use `/octo:debate [question]` for decision support
- Check `.octo/phases/phase1/` for research notes

Phase 2 (Define):

Continue requirements clarification.
- Use `/octo:prd` to write product requirements
- Use `/octo:define` to refine scope
- Check `.octo/phases/phase2/` for requirements docs

Phase 3 (Develop):

Continue implementation.
- Use `/octo:develop` to build features
- Use `/octo:tdd` for test-driven development
- Check `.octo/phases/phase3/` for implementation plan

Phase 4 (Deliver):

Continue validation and delivery.
- Use `/octo:deliver` for final review
- Use `/octo:security` for security audit
- Use `/octo:ship` to finalize delivery

Example Outputs

Example 1: No Project State Found

## Session Restoration Failed

**No project state found.**

There is no `.octo/` directory in this project, which means no previous session state exists.

### Get Started

Run `/octo:embrace [your project description]` to start a new project.

Example 2: Successful Restoration (In Progress)

## Session Restored

**Project:** User Authentication System
**Last Active:** 2026-02-02T10:30:00Z
**Phase:** 2 - Define
**Position:** define-requirements
**Status:** in_progress

### Where You Left Off

- [2026-02-02T10:30:00Z] Phase 2: Started requirements review (in_progress)
- [2026-02-01T16:45:00Z] Phase 1: Completed discovery (complete)
- [2026-02-01T14:20:00Z] Phase 1: Research synthesis complete (in_progress)

### Current Blockers

None

### Ready to Continue

Continue with current phase. Context loaded.

Continue requirements clarification.
- Use `/octo:prd` to write product requirements
- Use `/octo:define` to refine scope
- Check `.octo/phases/phase2/` for requirements docs

Example 3: Blocked Project Restoration

## Session Restored

**Project:** E-commerce Platform
**Last Active:** 2026-02-01T18:00:00Z
**Phase:** 3 - Develop
**Position:** implement-payment-gateway
**Status:** blocked

### Where You Left Off

- [2026-02-01T18:00:00Z] Phase 3: Payment integration blocked (blocked)
- [2026-02-01T15:30:00Z] Phase 3: Started payment gateway integration (in_progress)
- [2026-02-01T12:00:00Z] Phase 3: Completed user auth implementation (complete)

### Current Blockers

- Missing Stripe API credentials
- Payment webhook endpoint not configured
- SSL certificate pending for payment domain

### Ready to Continue

Review blockers first: `/octo:issues`

**To unblock:**
1. Configure Stripe API credentials in environment
2. Set up webhook endpoint at /api/webhooks/stripe
3. Complete SSL certificate setup for payments subdomain

Example 4: Paused Project Restoration

## Session Restored

**Project:** Data Analytics Dashboard
**Last Active:** 2026-01-28T09:00:00Z
**Phase:** 2 - Define
**Position:** requirements-gathering
**Status:** paused

### Where You Left Off

- [2026-01-28T09:00:00Z] Phase 2: Project paused by user (paused)
- [2026-01-27T16:00:00Z] Phase 2: Stakeholder feedback pending (in_progress)
- [2026-01-27T10:00:00Z] Phase 1: Discovery complete (complete)

### Current Blockers

- Waiting for stakeholder availability

### Ready to Continue

Project paused. Resume with `/octo:embrace`

When ready to continue:
1. Review `.octo/PROJECT.md` for project context
2. Check `.octo/STATE.md` for pause reason
3. Run `/octo:embrace` to resume workflow

Best Practices

1. Always Use octo-state.sh for State Reading

Good:

./scripts/octo-state.sh read_state
./scripts/octo-state.sh get_context_tier auto

Poor:

# Parse STATE.md manually
grep "Current Phase" .octo/STATE.md

2. Provide Full Context Restoration

Good:

Load adaptive context tier
Show last 3 history entries
Display any blockers
Give phase-specific guidance

Poor:

Only show current phase
Ignore history
No next steps

3. Route Intelligently Based on Status

Good:

Status: blocked → "Review blockers first: /octo:issues"

Poor:

Status: blocked → "Continue working"

Red Flags - Don't Do This

Action	Why It's Wrong
Skip .octo/ existence check	Will fail with confusing errors
Ignore blockers on resume	User won't know why they stopped
Restart from beginning	Loses all previous context and progress
Skip history display	User loses continuity of what was done
Use hardcoded context tier	Should adapt based on current status

Integration with Other Skills

With /octo:status

/octo:resume → Full restoration with context
/octo:status → Quick dashboard without restoration

With /octo:embrace

No .octo/ exists → /octo:resume suggests /octo:embrace
.octo/ exists but paused → /octo:resume suggests resuming with /octo:embrace

With flow-* skills

User runs /octo:resume
→ Context restored
→ User continues with /octo:develop (or appropriate phase skill)

Quick Reference

User Input	Action Required
"resume"	Check .octo/ → Read state → Load context → Display summary → Route
"continue"	Same as resume
"pick up where I left off"	Same as resume
"what was I doing"	Same as resume, emphasize history
"restore session"	Same as resume

The Bottom Line

Check .octo/ → Read state → Load adaptive context → Show history + blockers → Route intelligently
Otherwise → User loses previous context and wastes time re-discovering where they were

Never restart from beginning if state exists. Restore context, show history, route intelligently.

Context Recovery After Compaction

When context is cleared (compaction, plan mode exit, new session), detect and reload automatically:

# Auto-detect context loss
if [[ -f .claude-octopus/state.json ]] && [[ -z "${WORKFLOW_CONTEXT_LOADED}" ]]; then
    echo "⚠️  Context was cleared — reloading from persistent state..."
    NEEDS_RESUME=true
fi

What survives context clearing:

.claude-octopus/state.json (decisions, context, metrics)
.claude-octopus/context/*.md (phase outputs)
Native tasks (TaskList still works)
Git commits and WIP checkpoints
Multi-AI synthesis files in ~/.claude-octopus/results/

After resume completes, set export WORKFLOW_CONTEXT_LOADED=true to prevent duplicate reloads.

State persists in files. Context clearing is not a problem. Files outlive memory.

安装命令

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

npx skills add nyldn/claude-octopus/skills/skill-resume -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 的其他技能

分类与标签

分类工程开发

先判断是否适合

作者设计意图

作者的方法与取舍

边界和复核

Session Restoration

Overview

When to Use

The Process

Phase 0: Check Session Handoff File (v9.6.0)

Step 0: Check for .octo-continue.md

Phase 1: Check Project Initialization

Step 1: Verify .octo/ Directory Exists

Phase 2: Read Current State

Step 1: Execute octo-state.sh read_state

Step 2: Parse State Variables

Phase 3: Load Adaptive Context

Step 1: Get Context Tier (Auto Mode)

Step 2: Store Context for Reference

Phase 4: Extract History and Blockers

Step 1: Read Last 3 History Entries from STATE.md

Step 2: Extract Blockers from STATE.md

Step 3: Read Project Title from PROJECT.md

Phase 5: Display Restoration Summary

Step 1: Build and Display Summary

Step 2: Map Phase Number to Name

Phase 6: Intelligent Routing

Step 1: Route Based on Status

Step 2: Phase-Specific Guidance (for in_progress status)

Example Outputs

Example 1: No Project State Found

Example 2: Successful Restoration (In Progress)

Example 3: Blocked Project Restoration

Example 4: Paused Project Restoration

Best Practices

1. Always Use octo-state.sh for State Reading

2. Provide Full Context Restoration

3. Route Intelligently Based on Status

Red Flags - Don't Do This

Integration with Other Skills

With /octo:status

With /octo:embrace

With flow-* skills

Quick Reference

The Bottom Line

Context Recovery After Compaction

讨论