360 Secure SkillHub
360 安全技能中心

Verification Before Completion

该 Skill 是通用工作方法指导：在报告任务完成前，先确认用户真正关心的结果或系统行为。内容包括适用场景、五步验证流程、证据优先顺序、正反示例与常见误区。优先观察实际行为、工具输出或状态，仅在无更强手段时才依赖文本检查。

jisang1000
jisang1000
热度 48.40
最近更新 2026-09-23 15:54:24
分类：开发依赖：纯提示词应用场景：工作流 / 调试排错 / 代码审查

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add jisang1000-verification-before-completion
Metadata
name
verification-before-completion
description
Verify real outcomes before saying work is complete. Use when implementing, fixing, configuring, or automating something where behavior must be confirmed, not just command success or edited text.

Verification Before Completion

Before reporting that work is done, confirm the real outcome the user cares about.

Core Rule

A successful command is not proof that the task is complete. Always verify the user-visible result, system behavior, or intended effect.

When to Apply

Use this skill when:

  • code was changed
  • config was edited
  • automation was updated
  • a bug was supposedly fixed
  • a reminder/job was created or changed
  • a browser/script flow was updated
  • a migration or setup task was performed

Workflow

  1. Identify the actual outcome to verify.
  2. Choose the cheapest realistic verification method.
  3. Run the verification.
  4. Report completion only if the real outcome is confirmed.
  5. If partially verified, explicitly say what was verified and what was not.

Verification Order

Prefer evidence in this order:

  1. Actual behavior observed
  2. Tool output proving the behavior
  3. State inspection that strongly implies behavior
  4. Text/config inspection only when no stronger method exists

Examples

Good

  • Not just “calendar event created” → confirm returned event fields match date/title
  • Not just “script updated” → run a smoke test
  • Not just “page changed” → open page and inspect result

Bad

  • “Done” because file was edited
  • “Fixed” because command exited 0
  • “Configured” because text now looks correct

Reporting Style

Prefer:

  • what was changed
  • how it was verified
  • what remains uncertain, if anything

Example:

  • "수정했고, dry-run으로 실제 동작 확인했어. 실 API 호출은 키가 없어서 아직 미검증이야."

Common Traps

  • confusing command success with task success
  • verifying text instead of behavior
  • skipping verification because result seems obvious
  • claiming full completion when only partial verification happened

Practical Examples

Example: Reminder setup

  • Weak: "리마인드 등록했어" because the add command returned success
  • Strong: confirm the scheduled timestamp, payload text, and next run time

Example: Script fix

  • Weak: "수정했어" because the file changed
  • Strong: run the script in dry-run or smoke-test mode and confirm output

Example: Browser automation

  • Weak: "페이지 열리게 했어" because navigation command ran
  • Strong: confirm the target page title, key visible text, or expected element state