360 Secure SkillHub
360 安全技能中心

Engrm Delivery Review

该 Skill 用于会话交付复核:对照用户原始需求、代理承诺的计划与已记录的决策,结合交付证据判断实际完成情况,识别部分交付、范围漂移、以重构代替交付、决策链薄弱以及已完成事项被重新打开等模式,并把真实结果、主要差距和后续经验保存为记忆条目。仅在环境中已连接 Engrm 时使用,且不虚构任何命令行命令。

dr12hes
dr12hes
热度 47.17
最近更新 2026-05-11 17:33:34
分类:知识依赖:第三方 API应用场景:报告撰写 / 笔记整理 / 任务管理

安装技能

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

执行命令安装此 skill: npx secure-skills-cli add engrm-delivery-review
Metadata
name
engrm-delivery-review
description
Use Engrm to compare what was asked, what was promised, and what evidence suggests was actually delivered.

Engrm Delivery Review

Use this skill when the user wants to know whether the agent really delivered what it claimed, or when a session may have drifted from the original brief.

Before you start

Use Engrm only if it is already connected and available in the current environment.

If Engrm is not available, say that Delivery Review cannot use Engrm on this machine yet and continue without inventing setup or shell instructions.

Command guardrails

Do not invent Engrm CLI commands such as engrm search, engrm save, or engrm timeline.

Use Delivery Review as an Engrm workflow and memory discipline, not as a made-up shell command surface.

What this skill is for

  • Compare the brief, plan, and decisions against the session outcome.
  • Spot partial delivery, scope drift, or refactor-heavy sessions.
  • Surface weak decision trails and likely follow-up risk.
  • Turn sessions into accountable project history instead of vague timelines.

When to use it

Use this skill when:

  • the agent says work is done and confidence needs verifying
  • the user suspects partial delivery
  • the session touched many files but produced unclear outcome evidence
  • later work reopened an area that was supposedly finished
  • a refactor may have displaced the original goal

Delivery Review questions

  • What was the user actually asking for?
  • What plan did the agent commit to?
  • What decisions were captured?
  • What evidence of delivery exists?
  • What still looks missing, weak, or reopened?

Review lenses

Look for these patterns:

  • delivered as planned
  • partially delivered
  • scope drifted
  • refactor instead of delivery
  • built without a clear decision trail
  • reopened after completion

Strong evidence

Good evidence includes:

  • concrete implementation activity tied to the brief
  • decisions followed by matching changes
  • later sessions not needing to reopen the same work
  • clear memory entries that explain why the work was done

Weak evidence includes:

  • lots of movement with little outcome clarity
  • vague completion language
  • decisions with no matching implementation trail
  • later sessions repairing or redoing the same area

What to save after review

Save:

  • the real outcome
  • the main gap or drift
  • the lesson future sessions should know first

Do not save a flattering summary if the evidence is mixed. Prefer truthful, useful review over optimistic narration.