# Ber

> Better Every Run: capture explicit /ber corrections, review them, and promote only the lessons that deserve durable memory, skill rules, or evals.

- Skill: `leostehlik/ber` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add leostehlik/ber`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leostehlik/ber/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: LeoStehlik (https://skillmd.com/u/leostehlik)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leostehlik/ber

---

# 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:

```text
/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

```text
/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:

```text
/ber fix bad outcome -> desired outcome
```

For simple one-line preferences:

```text
/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