mcpField
S
skill-factory

skill-factory

github.com/nyldn开发4.3k50 次安装今天更新
代码仓库

关于 skill-factory

skill-factory 是面向 Codex CLI 的技能,用于按自然语言规范运行多阶段验证流程,涵盖场景生成、留出测试、满意度评分和报告。

主要功能

  1. 01八步工厂执行流程
  2. 02NLSpec 验证关卡
  3. 03场景覆盖审查
  4. 04留出测试与评分
  5. 05工厂报告核验

适用场景

  1. 01按 NLSpec 评估实现
  2. 02检查边缘场景覆盖情况
  3. 03查看留出测试结果与满意度评分

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/nyldn/claude-octopus --skill skill-factory

安装后在 Claude Code 中输入/skill-factory确认已加载。

附带文件agents/openai.yaml

详细介绍

宿主:Codex CLI — 此技能最初为 Claude Code 设计,后适配到 Codex。 交叉引用命令在 Codex 中使用已安装的技能名称,而非 /octo:* 斜杠命令。 使用当前启用的 Codex shell 和子 Agent 工具。在当前会话尚未提供相关能力前,不要声称有可用的提供方、模型或宿主子 Agent。 宿主工具的对应项请参阅 skills/blocks/codex-host-adapter.md。

停止——技能已加载

不要再次调用 Skill()。直接执行。

执行约定(强制——8 步顺序,不可跳过)

步骤 1:澄清问题(强制)

在采取任何其他操作前,通过 AskUserQuestion 询问:

  1. 规格位置——NLSpec 文件的路径,或直接粘贴内容
  2. 满意度目标是否覆盖默认值(使用规格默认值 / 自定义 0.80-0.99)
  3. 费用批准——约 20-30 次 Agent 调用需约 0.50-2.00 USD(批准 / 批准 --ci / 拒绝)

如果命令中已附带规格路径,请使用该路径,但仍须询问其余问题。 如果用户说“跳过”,则使用默认值并继续。 用户回答前,不得进入步骤 2。

步骤 2:显示视觉指示器(强制——阻塞)

检查提供方:

command -v codex &> /dev/null && codex_status="Available" || codex_status="Not installed"
command -v agy &> /dev/null && agy_status="Available" || agy_status="Not installed"

显示横幅:

🐙 CLAUDE OCTOPUS ACTIVATED - Dark Factory Mode
Pipeline: Parse → Scenarios → Embrace → Holdout → Score → Report

Providers:
  Codex CLI - <status> — Scenario generation + holdout evaluation
  Antigravity CLI - <status> — Additional external-model challenge
  Claude - Orchestration + satisfaction scoring

Spec: <path>
Estimated: 0.50-2.00 USD / 15-45 min

验证:如果所有外部提供方都不可用,则继续仅使用 Claude(提醒用户多样性会降低)。如果至少有一个提供方可用,则正常继续。

步骤 3:验证规格文件(强制——验证关卡)
if [[ ! -f "<spec_path>" ]]; then
    echo "ERROR: Spec file not found at <spec_path>"
    exit 1
fi
# Check minimum content
word_count=$(wc -w < "<spec_path>")
if [[ $word_count -lt 20 ]]; then
    echo "WARNING: Spec is very thin ($word_count words). Results may be limited."
fi

如果规格文件不存在,则停止并询问用户正确的路径。 如果规格内容过少(少于 50 个单词),则发出警告,但继续。 文件不存在时,不得通过此关卡。

步骤 4:读取先前状态(可选)
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state 2>/dev/null || true
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "factory" "factory" 2>/dev/null || true

如果失败,则在不使用状态的情况下继续,并提醒用户。

步骤 4.5:对抗性场景覆盖率关卡(建议)

在开始成本较高的 embrace 阶段(约 0.50-2.00 USD)之前,请确认生成的场景确实覆盖了规格中的边缘情况。 在此处快速进行跨提供方审查,可避免因场景覆盖不全而浪费整次工厂运行。

在 orchestrate.sh 解析规格后(阶段 1-2)、执行 embrace 前(阶段 4),分派场景覆盖率审查:

如果有第二个提供方可用,则通过 Octopus 路由分派挑战:

# Read the spec to extract behaviors and constraints
SPEC_CONTENT=$(<"<spec_path>")
review_provider=""
command -v codex >/dev/null 2>&1 && review_provider="codex"
[[ -z "$review_provider" ]] && command -v agy >/dev/null 2>&1 && review_provider="agy"

if [[ -n "$review_provider" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh" spawn "$review_provider" \
    "You are a QA adversary. Given this specification and generated scenarios, identify coverage gaps.

SPECIFICATION:
${SPEC_CONTENT}

Answer:
1. Which spec BEHAVIORS have no scenario testing them?
2. Which EDGE CASES from the spec constraints are untested?
3. Which FAILURE MODES are not covered (network failures, invalid input, concurrent access)?
4. Rate overall coverage: SUFFICIENT / GAPS-FOUND / CRITICAL-GAPS

Be specific — cite the behavior or constraint ID that lacks coverage." 2>/dev/null || true
fi

收到挑战响应后:

  • 如果发现 CRITICAL-GAPS:提醒用户,并建议先使用 /octo:spec 完善规格
  • 如果发现 GAPS-FOUND:指出这些缺口,但继续执行——保留集阶段(阶段 5)会捕获其中一部分
  • 如果结果为 SUFFICIENT:放心继续

这是一个轻量级关卡——大约增加 30 秒,但对于场景覆盖率较差的规格,可避免浪费一次 2.00 USD 的工厂运行。

可通过 --fast 跳过,或在用户明确要求优先速度而非全面性时跳过。

步骤 5:执行 orchestrate.sh 工厂流程(强制——Bash 工具)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh factory --spec "<spec_path>"

根据步骤 1 的回答,可添加以下可选标志:

  • 如果请求自定义比例,则使用 --holdout-ratio <value>
  • 如果请求自定义重试次数,则使用 --max-retries <value>
  • 如果用户批准非交互模式,则使用 --ci
禁止: - 直接运行 embrace(必须使用封装了它的工厂命令) - 模拟或伪造保留集测试 - 用直接的 Claude 分析代替多提供方评分 - 跳过工厂流水线 - 在插件目录中创建工作文件或进度文件
步骤 6:验证工厂报告(强制——验证关卡)
REPORT_FILE=$(find .octo/factory -name "factory-report.md" -mmin -60 2>/dev/null | sort -r | head -1)
if [[ -z "$REPORT_FILE" ]]; then
    echo "ERROR: Factory report not found"
    exit 1
fi
cat "$REPORT_FILE"

如果验证失败:报告错误,显示 ~/.claude-octopus/logs/ 中的日志;不要继续,也不要替代执行。

步骤 7:读取评分并呈现结果(强制)
SCORES_FILE=$(find .octo/factory -name "satisfaction-scores.json" -mmin -60 2>/dev/null | sort -r | head -1)
if [[ -n "$SCORES_FILE" ]]; then
    cat "$SCORES_FILE"
fi

向用户呈现:

  1. 结论,附带表情符号(PASS/WARN/FAIL)
  2. 综合评分及其与满意度目标的对比
  3. 维度明细(行为、约束、保留集、质量)
  4. 保留集要点——哪些盲测场景通过或失败
  5. 产物目录路径,供深入审查
步骤 8:更新状态并说明后续步骤(必需)
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" record_decision "factory" "Factory run completed: <verdict> (<score>/<target>)" 2>/dev/null || true

根据评估结果提供后续步骤建议:

  • PASS: 实现符合规范。检查产物,进行手动测试,然后发布。
  • WARN: 接近目标。检查留出集中的失败项,并考虑针对性修复。
  • FAIL: 未达到目标。查看 holdout-results.md 了解具体失败项。可考虑:
    • 使用 /octo:spec 优化 NLSpec
    • 手动修复后使用 --max-retries 2 重新运行
    • 将规范拆分成更小、更清晰的部分

添加署名页脚:

Dark Factory Mode powered by Claude Octopus v8.25.0
Pipeline: Spec → Scenarios → Embrace → Holdout → Score → Report
Providers: Codex | Antigravity | Claude

错误处理(按步骤)

  • 步骤 1(问题):如果用户全部拒绝,则使用默认值继续
  • 步骤 2(提供方):两个外部提供方都不可用时,切换为仅使用 Claude 的模式(警告)
  • 步骤 3(规范):文件缺失 → 停止。规范过于简单 → 发出警告并继续。
  • 步骤 4(状态):失败 → 不使用状态继续
  • 步骤 5(orchestrate.sh):显示 bash 错误,检查日志 — 不要替代执行
  • 步骤 6(报告):缺失 → 显示日志,不要继续
  • 步骤 7(评分):JSON 缺失 → 从报告 Markdown 中提取
  • 步骤 8(状态):失败 → 跳过状态更新,仍然呈现结果

禁止操作

  • 不得跳过 orchestrate.sh 工厂执行
  • 不得模拟或伪造工厂流水线
  • 不得用直接的 Claude 分析替代多提供方评分
  • 不得跳过规范验证关卡
  • 验证关卡失败后不得继续
  • 不得在插件目录中创建工作/进度文件

评论

支持 Markdown