skills/auto/SKILL.md
# Skill: auto Autonomous execution mode — runs CLARIFY → SPEC → PLAN → EXECUTE → VERIFY → BUILD → DEPLOY → E2E → DONE without user interrupts (low/medium risk only). ## Purpose For epics where risk is `low` or `medium` and requirements are clear, `/stage-harness:auto` allows the pipeline to run end-to-end with minimal user involvement. The Interrupt Budget still enforces hard limits, but stage gates are auto-approved. ## Eligibility Check Before entering auto mode: ``` 1. Read .harness/proj
npx skillsauth add LUAgam/stage-harness skills/autoInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Autonomous execution mode — runs CLARIFY → SPEC → PLAN → EXECUTE → VERIFY → BUILD → DEPLOY → E2E → DONE without user interrupts (low/medium risk only).
For epics where risk is low or medium and requirements are clear, /stage-harness:auto allows the pipeline to run end-to-end with minimal user involvement. The Interrupt Budget still enforces hard limits, but stage gates are auto-approved.
Before entering auto mode:
1. Read .harness/project-profile.yaml
2. Verify risk_level is "low" or "medium"
3. Verify epic state is IDEA or CLARIFY (not mid-execution)
4. Warn user: "Auto mode will proceed with minimal interrupts"
5. Get ONE explicit confirmation before starting
BLOCKED for high risk — auto mode cannot run for high-risk epics. User must use individual commands.
Stage 1: CLARIFY
→ Run clarify skill with interrupt budget = 1 (medium) or 0 (low)
→ If 0 budget: all decisions are assumable or deferrable
→ Write clarification-notes.md with assumption log
Stage 2: SPEC
→ Run /feature-planning (ShipSpec)
→ Auto-approve light_council if no CRITICAL verdict
→ If CRITICAL: pause and surface to user (consumes 1 interrupt if available)
Stage 3: PLAN
→ Run parallel scouts + plan skill
→ Auto-approve plan_council if verdict is APPROVED or APPROVED_WITH_WARNINGS
→ Log warnings in unknowns-ledger.json
Stage 4: EXECUTE
→ Run worker loop for each task
→ Workers never interrupt — BLOCKED tasks are deferred
→ Atomic commits per task
Stage 5: VERIFY (conditional skip in auto mode)
→ If risk_level = high: run acceptance_council normally
- If APPROVED / APPROVED_WITH_WARNINGS: proceed to BUILD
- If REJECTED: pause, surface to user (consumes a budget unit)
→ If risk_level in [low, medium] AND config auto_skip_verify != false:
- SKIP acceptance_council entirely
- state transition: EXECUTE → VERIFY → BUILD (status log preserved)
- export HARNESS_SKIP_VERIFY_GATE=1 so harness-build accepts EXECUTE receipts as proof
- Proceed directly to BUILD
Stage 6: BUILD
→ Resolve build command via build skill (profile → code-aware infer → ask user)
→ Auto-proceed if build-receipt.json status is PASS or SKIPPED
→ If FAIL: state transition to FIX, surface error, exit loop
Stage 7: DEPLOY
→ Run deploy skill (multi sub-project aware: scan → infer → confirm → deploy)
→ Auto-proceed if deploy-receipt.json status is PASS or SKIPPED
→ If FAIL: state transition to FIX, then resume from BUILD on next loop
Stage 8: E2E-TEST
→ Run /stage-harness:harness-e2e-test (user-value-driven: generate-test-cases → verify-and-fix-cases)
→ Result from verify-cases/verify-receipt.json (three states: PASS / PARTIAL / FAIL)
→ If PASS: auto-proceed to DONE
→ If PARTIAL (P0 all passed, some P1/P2/P3 failed): pause, surface failed cases, consume budget unit
- User accepts → proceed to DONE (record in delivery-summary.md known defects)
- User rejects → treat as FAIL
→ If FAIL: synthesize verification.json from failed cases, state transition to FIX
→ harness-fix → resume from BUILD → DEPLOY → harness-e2e-test (max 3 rounds)
Stage 9: DONE
→ Run release_council
→ If RELEASE_READY / RELEASE_WITH_CONDITIONS: emit delivery-summary.md & release-notes.md, mark epic DONE
→ If NOT_READY: pause, surface to user (consumes a budget unit)
Every assumed decision is written to .harness/features/<epic-id>/auto-assumptions.md:
## Assumed: JWT token expiry = 1h
Reason: industry standard, easily configurable
Risk: low
Reversible: yes (config change)
critical impactblocked when entering BUILD (skipping VERIFY removes the human gate, so blocked tasks must abort instead of pass through)On abort: write .harness/features/<epic-id>/auto-abort.md with reason and last safe state.
During auto mode, show real-time progress:
[AUTO] Epic: add-user-auth | Risk: medium
✓ CLARIFY complete (2 assumed, 1 deferred)
✓ SPEC complete (PRD: 5 req, SDD: 8 sections, TASKS: 7)
⟳ PLAN running... (scouts: 4/4 complete, council: reviewing)
○ EXECUTE pending
○ VERIFY pending
○ BUILD pending
○ DEPLOY pending
○ E2E-TEST pending
○ DONE pending
Invoke skill: auto
Epic: <epic-name>
Pre-conditions:
- risk_level in [low, medium]
- User has confirmed auto mode
- Epic in IDEA or CLARIFY state
development
在 generate-test-cases 阶段之后执行,逐个验证测试用例并在失败时修复项目代码、重新编译部署、再次验证, 直到通过或达到最大修复次数。覆盖 UI / API / API+UI / 性能测试四个维度,UI 测试通过浏览器真实模拟用户操作并截图, API 测试根据项目代码生成可执行的接口脚本,性能测试调用现有性能/质量技能全量执行。 涉及真实用户登录信息(如手机号+验证码、账号密码、JWT)时必须中断要求用户提供,禁止编造无效凭证。 所有 case 状态变更必须通过 e2e-case-tracker.sh 脚本持久化,确保中途崩溃可恢复、无 case 遗漏。
development
# SKILL: e2e > **核心原则**: > 1. 测试范围跟着本次变动走。后端接口改了,对应的前端流程必须做联调验证;与本次需求无关的功能不测。对于涉及算法、转换准确率等质量敏感型需求,需额外生成专项质量测试。 > 2. **覆盖完整性优先于执行便利性**。不得以"链路复杂"、"需要外部依赖"为由跳过本次变动相关的用例;凡是受变动影响的接口和 UI 流程,都必须生成真实调用/操作用例。 > 3. **UI 测试必须模拟真实用户操作**(定位元素、点击、键入、等待渲染、断言可见文本/状态)。**禁止**将 UI 套件退化为浏览器上下文里的 `page.evaluate(fetch(...))` API 验证——那只是把 API 测试换了执行环境,没有额外价值,不算 UI 测试。 > 4. **通用性**:本 skill 不假设具体业务域,所有规则均以抽象变动面(文件、接口、页面、用户动作)为单位组织,不针对任何特定项目的数据库/领域词汇。 > 5. **E2E 套件必须验证运行时行为**。严禁把"读取源码/配置文件并做字符串/结构匹配"的检查封装成独立 E2E 套件——这类检
tools
# SKILL: deploy ## CLI Bootstrap 在执行任何 `harnessctl` 命令前,先解析本地 CLI 路径: ```bash if [ -z "${HARNESSCTL:-}" ]; then candidates=( "./stage-harness/scripts/harnessctl" "../stage-harness/scripts/harnessctl" "$(git rev-parse --show-toplevel 2>/dev/null)/stage-harness/scripts/harnessctl" ) for candidate in "${candidates[@]}"; do if [ -n "$candidate" ] && [ -x "$candidate" ]; then HARNESSCTL="$candidate" break fi done fi test -n "${HARNESSCTL:-}" && test -x "$H
tools
# SKILL: build ## CLI Bootstrap 在执行任何 `harnessctl` 命令前,先解析本地 CLI 路径: ```bash if [ -z "${HARNESSCTL:-}" ]; then candidates=( "./stage-harness/scripts/harnessctl" "../stage-harness/scripts/harnessctl" "$(git rev-parse --show-toplevel 2>/dev/null)/stage-harness/scripts/harnessctl" ) for candidate in "${candidates[@]}"; do if [ -n "$candidate" ] && [ -x "$candidate" ]; then HARNESSCTL="$candidate" break fi done fi test -n "${HARNESSCTL:-}" && test -x "$HA