LUAgam/skills/re-spec
skills/re-spec/SKILL.md
# Skill: re-spec ## CLI Bootstrap 在执行任何 `harnessctl` 命令前，校验环境变量 `HARNESSCTL` 是否已配置： ```bash test -n "${HARNESSCTL:-}" && test -x "$HARNESSCTL" || { echo "ERROR: HARNESSCTL 环境变量未设置或不可执行。请先执行: export HARNESSCTL=/path/to/stage-harness/scripts/harnessctl" >&2 exit 1 } ``` Incremental SPEC revision — amends epic specification based on upstream CLARIFY changes. ## Purpose When re-clarify produces new requirements or surfaces, the SPEC must be updated to include acceptance criteria, constrain
tools
Updated May 22, 2026
$ install --global
skillsauthnpx skillsauth add LUAgam/stage-harness skills/re-specInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 22, 2026, 4:06 AM132.6s1 file scanned
SKILL.md
Skill: re-spec
CLI Bootstrap
在执行任何 harnessctl 命令前，校验环境变量 HARNESSCTL 是否已配置：
test -n "${HARNESSCTL:-}" && test -x "$HARNESSCTL" || {
echo "ERROR: HARNESSCTL 环境变量未设置或不可执行。请先执行: export HARNESSCTL=/path/to/stage-harness/scripts/harnessctl" >&2
exit 1
}
Incremental SPEC revision — amends epic specification based on upstream CLARIFY changes.
Purpose
When re-clarify produces new requirements or surfaces, the SPEC must be updated to include acceptance criteria, constraints, and scope changes. This skill performs incremental spec amendment without rewriting the entire specification.
Trigger
Invoked when:
- CLARIFY stage re-amendment is complete
- SPEC artifacts are marked
staleinartifact-status.json - Epic stage has been advanced from CLARIFY to SPEC (or re-opened to SPEC)
Input
- Amended CLARIFY artifacts (impact-scan.md, surface-routing.json, requirements-draft.md)
- Existing spec:
.harness/specs/<epic-id>.mdor.harness/features/<epic-id>/epic-spec.md - Feedback context:
HFB-*.json,HFB-*.triage.json,revision-diff-HFB-*.md artifact-status.jsonshowing which spec artifacts are stale
Flow
Step 1 — Identify Spec Gaps
Compare amended CLARIFY output against existing spec:
- New requirements in
requirements-draft.mdnot covered by spec - New surfaces in
surface-routing.jsonwithout acceptance criteria - Changed scope items
Step 2 — Amend Spec
For each new requirement/surface:
- Add acceptance criteria section
- Add constraints/non-functional requirements if applicable
- Mark amendment clearly:
<!-- Amendment: HFB-001 | 2026-05-12 -->
### AC-12: PostgreSQL Frontend Endpoint (Added)
- Given: User navigates to endpoint creation
- When: User selects PostgreSQL type
- Then: Form shows Host, Port, Username, Password, DB Name, Schema fields
- Verification: Already supported in the existing frontend, no code change needed
<!-- /Amendment -->
Step 3 — Update Coverage Matrix
If new acceptance criteria added:
$HARNESSCTL coverage map --epic-id <epic-id> --reset
Step 4 — Artifact Status Update
$HARNESSCTL artifact-status set --epic-id <epic-id> \
--path "specs/<epic-id>.md" \
--status current --reason "Amended via re-spec for HFB-001"
Step 5 — Downstream Assessment
Determine if PLAN/tasks need changes:
- New acceptance criteria that require new tasks → leave PLAN as
stale - Existing tasks already cover the new criteria → waiver
Step 6 — Completion Marker
# Mark re-spec as completed (REQUIRED — guard will block EXECUTE without this)
$HARNESSCTL feedback re-complete --epic-id <epic-id> \
--feedback-id <HFB-xxx> --stage SPEC \
--artifacts "specs/<epic-id>.md,coverage-matrix.json"
Step 7 — Stage Gate
$HARNESSCTL stage-gate check SPEC --epic-id <epic-id>
Output
| Artifact | Action |
|----------|--------|
| specs/<epic-id>.md or epic-spec.md | Amended with new ACs |
| coverage-matrix.json | Updated mappings |
| artifact-status.json | SPEC artifacts → current |
| revision-diff-HFB-*.md | Updated with spec changes |
Exit Criteria
- All new requirements have corresponding acceptance criteria
- Coverage matrix updated
- SPEC stage gate passes
- Downstream impact stated (needs re-plan OR waiver)
Related Skills
LUAgam/verify-and-fix-cases
development
VerifiedTrustedCommunity
在 generate-test-cases 阶段之后执行，逐个验证测试用例并在失败时修复项目代码、重新编译部署、再次验证， 直到通过或达到最大修复次数。覆盖 UI / API / API+UI / 性能测试四个维度，UI 测试通过浏览器真实模拟用户操作并截图， API 测试根据项目代码生成可执行的接口脚本，性能测试调用现有性能/质量技能全量执行。 涉及真实用户登录信息（如手机号+验证码、账号密码、JWT）时必须中断要求用户提供，禁止编造无效凭证。 所有 case 状态变更必须通过 e2e-case-tracker.sh 脚本持久化，确保中途崩溃可恢复、无 case 遗漏。
SKILL.mdUpdated May 22, 2026
LUAgam/skills/e2e
development
VerifiedTrustedCommunity
# SKILL: e2e > **核心原则**： > 1. 测试范围跟着本次变动走。后端接口改了，对应的前端流程必须做联调验证；与本次需求无关的功能不测。对于涉及算法、转换准确率等质量敏感型需求，需额外生成专项质量测试。 > 2. **覆盖完整性优先于执行便利性**。不得以"链路复杂"、"需要外部依赖"为由跳过本次变动相关的用例；凡是受变动影响的接口和 UI 流程，都必须生成真实调用/操作用例。 > 3. **UI 测试必须模拟真实用户操作**（定位元素、点击、键入、等待渲染、断言可见文本/状态）。**禁止**将 UI 套件退化为浏览器上下文里的 `page.evaluate(fetch(...))` API 验证——那只是把 API 测试换了执行环境，没有额外价值，不算 UI 测试。 > 4. **通用性**：本 skill 不假设具体业务域，所有规则均以抽象变动面（文件、接口、页面、用户动作）为单位组织，不针对任何特定项目的数据库/领域词汇。 > 5. **E2E 套件必须验证运行时行为**。严禁把"读取源码/配置文件并做字符串/结构匹配"的检查封装成独立 E2E 套件——这类检
SKILL.mdUpdated May 22, 2026
LUAgam/skills/deploy
tools
VerifiedTrustedCommunity
# 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
SKILL.mdUpdated May 22, 2026
LUAgam/skills/build
tools
VerifiedTrustedCommunity
# 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
SKILL.mdUpdated May 19, 2026