360 Secure SkillHub
360 安全技能中心

Ber Clawhub V060

仅在用户显式调用 /ber 时,把纠正和简单规则记入本地 .better-every-run/ 证据库,再通过本地 Node 命令的 card、promote、eval-fixture 流程,经人工审核升级为 memory 文件、SKILL.md 规则或评测用例,并在对话中说明持久化位置。

leostehlik
leostehlik
热度 65.37
最近更新 2026-09-01 09:09:39
分类:知识依赖:代码执行 / 读写文件应用场景:笔记整理 / 工作流 / 报告撰写

安装技能

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

执行命令安装此 skill: npx secure-skills-cli add better-every-run
Metadata
name
ber
description
Better Every Run: capture explicit /ber corrections, review them, and promote only the lessons that deserve durable memory, skill rules, or evals.
user-invocable
true
metadata
{"version":"0.6.0"}

Better Every Run

Use this skill only when the user explicitly invokes /ber, names Better Every Run, or directly asks to persist a lesson for future runs. BER turns deliberate corrections into reviewed lessons without silently converting ordinary chat into permanent memory. Do not auto-capture ordinary corrections, casual preferences, or words like "remember", "always", "never", or "next time" unless the user clearly wants durable learning.

The human path is deliberately small:

/ber fix bad outcome -> desired outcome
/ber remember simple rule
/ber report

The agent runs the bundled local helper and reports the result in chat. fix and remember record only to the local .better-every-run/ evidence store. Durable memory/skill changes require the reviewed card + promote flow; eval regression cases require eval-fixture.

When To Use

  • The user explicitly types /ber fix ... -> ....
  • The user explicitly types /ber remember ....
  • The user explicitly asks for a Better Every Run report.
  • The user asks the agent to record a reusable correction as durable memory.

Human Commands

/ber fix agent wrote vague status -> agent gives exact command output and next action
/ber remember use the approved development host for active code work
/ber report

Rules

  • Report CLI output back in chat; do not build web pages or dashboards.
  • Do not silently edit MEMORY.md, AGENTS.md, SOUL.md, or other durable instruction files.
  • Do not pass --target to /ber fix or /ber remember; direct durable writes are disabled and must refuse.
  • Only promote to durable memory or skill files after an explicit review decision using card then promote.
  • Memory promotions must target an existing memory/*.md file.
  • Skill promotions must target SKILL.md in the current skill project.
  • Eval fixtures must use eval-fixture and target .json or .jsonl under tests/ or evals/.
  • Scanner hard blocks and warnings both block promotion. Adjust, quarantine, or supersede the lesson instead of forcing it through.
  • Keep corrections factual: bad outcome, desired outcome, and scope.
  • Use scope metadata when it helps decide whether a lesson belongs only to this run, the project, the workspace, a skill, memory, or an eval.
  • Avoid private data unless the user explicitly wants it captured.
  • Keep the user-facing flow short, but disclose persistence: local store, durable target file if promoted, and how it was reviewed.
  • Design for the shortest path to the user's outcome.
  • Never publish .better-every-run/ state, local lessons, event logs, or private corrections.

Workflow

For normal chat use, keep the visible flow to one command:

/ber fix bad outcome -> desired outcome

For simple one-line preferences:

/ber remember simple rule

Use /ber report to show what was learned, including open proposals and promotion suggestions.

Agent Implementation

Keep low-level helper commands out of normal chat unless debugging, but never hide persistence. A normal answer should say whether the lesson was recorded only in .better-every-run/ or promoted to a named durable file through a lesson card.

Read references/workflow.md for the full workflow. Read references/report-template.md for expected chat output shape.

Before publishing or packaging, verify:

  • .better-every-run/ is excluded
  • make test passes
  • direct fix --target, remember --target, and apply-memory-patch attempts refuse without changing target files
  • lesson-card, lifecycle, and eval-fixture demos are generic and contain no private workspace paths, chat IDs, tokens, or hostnames
  • examples contain no private workspace paths, chat IDs, tokens, or hostnames
  • docs say activation is explicit-only and persistence is disclosed