Agent测试
- 作者仓库星标 3,406
- 作者更新于 实时读取
- 作者仓库 claude-octopus
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @nyldn · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-context-detection
description: Auto-detect work context (Dev vs Knowledge) — use to tailor workflows based on current task type…
category: 通用
runtime: 无特殊运行时
---
# skill-context-detection 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Purpose / Detection Algorithm / Step 1: Check for Explicit Override”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Purpose / Detection Algorithm / Step 1: Check for Explicit Override”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/octo`、`/review`、`/security-review` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Purpose / Detection Algorithm / Step 1: Check for Explicit Override”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-context-detection
description: Auto-detect work context (Dev vs Knowledge) — use to tailor workflows based on current task type…
category: 通用
source: nyldn/claude-octopus
---
# skill-context-detection
## 什么时候使用
- 把通用方向的常用动作沉淀成 Agent 可调用的技能 适合处理通用任务拆解、检查、交付和复盘,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常不需要额外…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Purpose / Detection Algorithm / Step 1: Check for Explicit Override」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-context-detection" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Purpose / Detection Algorithm / Step 1: Check for Explicit Override
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} 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, seeskills/blocks/codex-host-adapter.md.
Context Detection - Internal Skill
Purpose
This skill provides automatic context detection to determine whether the user is working in a Development context (code-focused) or Knowledge context (research/strategy-focused). This replaces the manual /octo:km toggle with intelligent auto-detection.
Detection Algorithm
When a workflow skill activates, detect context using these signals:
Step 1: Check for Explicit Override
If user has explicitly set mode via /octo:km on or /octo:km off, respect that setting.
# Check if knowledge mode is explicitly set
if [[ -f ~/.claude-octopus/config/knowledge-mode ]]; then
EXPLICIT_MODE=$(cat ~/.claude-octopus/config/knowledge-mode)
if [[ "$EXPLICIT_MODE" == "on" ]]; then
echo "knowledge"
exit 0
elif [[ "$EXPLICIT_MODE" == "off" ]]; then
echo "dev"
exit 0
fi
fi
# If "auto" or not set, proceed with auto-detection
Step 2: Analyze Prompt Content (Strongest Signal)
Knowledge Context Indicators (check prompt for these terms):
- Business/strategy: "market", "ROI", "stakeholders", "strategy", "business case", "competitive"
- Research: "literature", "synthesis", "academic", "papers", "research question"
- UX: "personas", "user research", "journey map", "pain points", "interviews"
- Deliverables: "presentation", "report", "PRD", "proposal", "executive summary"
Dev Context Indicators (check prompt for these terms):
- Technical: "API", "endpoint", "database", "function", "class", "module"
- Actions: "implement", "debug", "refactor", "test", "deploy", "build"
- Artifacts: "code", "tests", "migration", "schema", "controller"
Scoring:
- Count knowledge indicators in prompt
- Count dev indicators in prompt
- Higher count wins
- If tied, check project context (Step 3)
Step 3: Analyze Project Context (Secondary Signal)
Dev Project Indicators:
- Has
package.json,Cargo.toml,go.mod,pyproject.toml,pom.xml - Has
src/,lib/,app/directories with code files - Recent files are
.ts,.js,.py,.go,.rs,.java
Knowledge Project Indicators:
- Has
docs/,research/,strategy/,reports/directories - Majority of files are
.md,.docx,.pdf,.pptx - No code package managers detected
Step 4: Default Fallback
If signals are ambiguous or equal:
- In a git repo with code files → Default to Dev Context
- No code files detected → Default to Knowledge Context
Context Output Format
Return detected context as a structured object for use by workflow skills:
{
"context": "dev" | "knowledge",
"confidence": "high" | "medium" | "low",
"signals": {
"prompt_indicators": ["API", "endpoint", "database"],
"project_type": "node_typescript",
"explicit_override": false
}
}
How Workflow Skills Use Context
flow-discover (Research)
| Aspect | Dev Context | Knowledge Context |
|---|---|---|
| Research Focus | Technical implementation, library comparison, code patterns | Market analysis, academic synthesis, competitive research |
| Primary Agents | Codex (implementation), Gemini (ecosystem) | Gemini (analysis), research-synthesizer |
| Output Format | Code examples, API comparisons, tech recommendations | Reports, frameworks, strategic recommendations |
| Visual Banner | 🔍 [Dev] Discover Phase: Technical research |
🔍 [Knowledge] Discover Phase: Strategic research |
flow-develop (Build)
| Aspect | Dev Context | Knowledge Context |
|---|---|---|
| Build Focus | Code generation, implementation, architecture | PRDs, strategy docs, presentations |
| Primary Agents | Codex (code), backend-architect, tdd-orchestrator | product-writer, strategy-analyst, exec-communicator |
| Output Format | Source files, tests, migrations | Documents, frameworks, action plans |
| Visual Banner | 🛠️ [Dev] Develop Phase: Building code |
🛠️ [Knowledge] Develop Phase: Building deliverables |
flow-deliver (Review)
| Aspect | Dev Context | Knowledge Context |
|---|---|---|
| Review Focus | Code quality, security, performance | Document quality, argument strength, completeness |
| Primary Agents | code-reviewer, security-auditor | exec-communicator, strategy-analyst |
| Quality Gates | OWASP, test coverage, maintainability | Evidence quality, clarity, actionability |
| Visual Banner | ✅ [Dev] Deliver Phase: Code review |
✅ [Knowledge] Deliver Phase: Document review |
Visual Indicator Update
When context is detected, update the visual banner to show context:
Dev Context:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider research mode
🔍 [Dev] Discover Phase: Researching OAuth implementation patterns
Providers:
🔴 Codex CLI - Technical implementation analysis
🟡 Gemini CLI - Ecosystem and library comparison
🔵 Claude - Strategic synthesis
Knowledge Context:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider research mode
🔍 [Knowledge] Discover Phase: Researching market entry strategies
Providers:
🔴 Codex CLI - Data analysis and modeling
🟡 Gemini CLI - Market and competitive research
🔵 Claude - Strategic synthesis
Implementation in Workflow Skills
Each flow skill should:
- Before executing workflow, run context detection
- Show detected context in visual banner
- Adjust behavior based on context:
- Agent selection
- Prompt framing for external CLIs
- Output format expectations
- Quality gate criteria
Example Integration (Pseudocode)
When this skill activates:
1. **Detect context**
- Analyze user's prompt for knowledge vs dev indicators
- Check project type (code repo vs doc-heavy)
- Check for explicit override (~/.claude-octopus/config/knowledge-mode)
- Determine: "dev" or "knowledge" with confidence level
2. **Show context-aware banner**
🐙 CLAUDE OCTOPUS ACTIVATED - Multi-provider [research|implementation|validation] mode [Phase Emoji] [Context] [Phase Name]: [Description]
Detected Context: [Dev|Knowledge] (confidence: [high|medium|low])
3. **Execute workflow with context-appropriate behavior**
- Frame prompts for Codex/Gemini based on context
- Select appropriate synthesis approach
- Apply context-specific quality gates
Override Mechanism
Users can still explicitly set context when auto-detection is wrong:
# Force knowledge mode
/octo:km on
# Force dev mode
/octo:km off
# Return to auto-detection
/octo:km auto
When explicit override is set, context detection respects it until user resets to "auto".
Confidence Levels
- High: Strong signals in prompt AND project context agree
- Medium: Signals in prompt OR project context (not both)
- Low: Ambiguous signals, using fallback default
When confidence is "low", consider briefly mentioning the detected context to user:
"I detected this as a [dev/knowledge] task. If that's wrong, you can use
/octo:kmto override."
Testing Context Detection
To verify context detection is working:
- In a code repository, ask "octo research caching patterns" → Should detect Dev Context
- In same repo, ask "octo research market opportunities" → Should detect Knowledge Context
- With
/octo:km onset, ask "octo research API patterns" → Should use Knowledge Context (explicit override)
Proactive Skill Suggestions
When detecting the user's work stage, surface relevant command suggestions:
| Detected Context | Suggestion |
|---|---|
| Brainstorming / exploring ideas | Consider /octo:brainstorm for structured ideation |
| Reviewing a plan or strategy | Consider /octo:plan for strategic planning |
| Debugging errors or failures | Consider /octo:debug for systematic investigation |
| Writing or running tests | Consider /octo:tdd for test-driven development |
| Code review before merge | Use Claude-native /review for ordinary review; suggest /octo:review for multi-AI escalation |
| Ready to deploy or ship | Consider /octo:deliver for quality-gated delivery |
| Researching a topic | Consider /octo:research for multi-source synthesis |
| Working on security | Use Claude-native /security-review for ordinary security review; suggest /octo:security for escalated OWASP or adversarial audit |
Suggestion Format
Suggestions should be non-intrusive, appended as a brief note:
💡 Tip: You appear to be debugging — `/octo:debug` provides systematic investigation with multi-AI support.
Persistent Opt-Out
- If user says "stop suggesting" or "no more tips": set
OCTO_PROACTIVE_SUGGESTIONS=offin.claude-octopus/preferences.json - If user says "be proactive" or "turn on tips": set
OCTO_PROACTIVE_SUGGESTIONS=on - Check preference at suggestion time — never suggest when opted out
- Respect current mode: dev mode suggestions differ from knowledge work suggestions
Re-Enable Suggestions
Users who previously opted out can re-enable suggestions at any time:
- Say "be proactive", "turn on tips", or "enable suggestions"
- Manually edit
~/.claude-octopus/preferences.jsonand setOCTO_PROACTIVE_SUGGESTIONStoon - Default state (no preference set) is suggestions enabled
Detection Signals
Detect work stage from:
- Recent tool usage (many Bash calls = likely implementing/debugging)
- File types being edited (.test.ts = testing, .md = documentation)
- Error patterns in recent output (stack traces = debugging)
- Git state (uncommitted changes = implementing, clean tree = ready to review/ship)
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核