mem commands

mem-commands adds two review commands to MEM, MEM REVIEW and MEM CHECK, and one authoring command, MEM DEFINE, that lets you write commands of your own for a project. It is pure Markdown: the agent reads the procedures and follows them, nothing is installed or run on its own. Use it when you want a structured, evidence-based second opinion on a plan before you build it, or on work an agent says is finished.

Version	1.0.0
Commands	MEM REVIEW <target>, MEM CHECK <target>, MEM DEFINE <COMMAND>
Executable content	No. Instruction text only
External actions	No
Requirements	A MEM knowledge base with extensions enabled. Nothing else

Why it exists

Agents are quick to say "done", and a plan that reads well is not the same as a plan that holds up. Two questions come up again and again in agent-assisted work:

• Is this plan any good, before we build it? Is it clear, complete, feasible, consistent with the decisions and conventions already in the knowledge base?
• Is this work really finished? Does the code that exists actually satisfy what the task asked for?

Both questions need the same machinery: find the right document, read the evidence, label what is confirmed and what is a guess, rate findings by severity, and end with a verdict. What differs is the assumption. REVIEW assumes nothing has been built yet, so it never treats unbuilt work as a defect. CHECK assumes someone claimed the work is complete, and it does not take that claim at face value. That is why the two live in one extension.

DEFINE exists for the other recurring need: a multi-step procedure your project repeats (a release checklist is the typical example) that is easy to get wrong when a step is skipped. Written down as a page, it has to be read and followed; defined as a command, it is executed.

How it works

Commands in the MEM namespace

MEM reserves a command grammar: a line on its own in the prompt, starting with MEM, with every keyword uppercase:

MEM <COMMAND> [<SUBCOMMAND>] [target]

The core provides a fixed set (MEM HELP, MEM STATUS, MEM INIT, MEM UPDATE, MEM LINT, MEM FORCE). Extensions add more in the same namespace, and mem-commands adds REVIEW, CHECK and DEFINE. A few rules from the core apply to all of them:

• A command fires only when it is genuinely an instruction. Mentioning one in a sentence, quoting it, or showing it in a code block (like the examples on this page) does not activate it. The agent announces an activation on the first line of its reply, so a wrong one is visible immediately.
• If you type MEM REVIEW and the extension is not installed, the agent checks the extension manifest, sees that mem-commands provides it, and offers to install it, once, and never without a confirmation naming the files and the source URL.
• Each extension declares a precedence. For mem-commands it is base wins: a project-specific command can never shadow REVIEW, CHECK, DEFINE or a core command. A command is behavior, so letting a local file replace a distributed one would be a hijack, not a customization. A custom command with a colliding name is refused and the collision is reported.

REVIEW and CHECK

Both commands need an explicit target, such as a plan under drafts/, a task under tasks/, a troubleshooting item, or any document you identify as a plan. The agent resolves it in a fixed order: exact path relative to the knowledge base, exact path relative to the repository, a link or identifier in a MEM index, an exact title, and finally a name search that returns candidates. If the target is missing, not found, or ambiguous, the verdict is BLOCKED. The agent never picks "the most recent task" on its own, and never judges a document it did not resolve.

Every claim in the report is labelled Confirmed, Inferred, Unverified or Not applicable, so guesses never pass as facts. Findings are rated on four levels:

Severity	Typical examples
Critical	Data loss, serious vulnerability, unusable feature, destructive or irreversible behavior
High	A main requirement unimplemented, a probable bug, a significant regression, a missing essential test
Medium	An unhandled edge case, a documentation inconsistency, an ambiguous acceptance criterion
Low	Clarity, small inconsistencies, non-blocking improvements

The verdict is exactly one of BLOCKED, NOT VERIFIABLE, CHANGES REQUIRED (at least one Critical or High finding), APPROVED WITH MINOR FINDINGS (only Medium or Low), or APPROVED, evaluated in that order. Passing tests alone never justify APPROVED. Style preferences are not reported as defects unless they break a documented convention.

The report follows a fixed layout (verdict, target, scope, evidence inspected, requirement coverage, findings by severity, discrepancies, build and test verification, unverified areas, recommended corrections, final assessment) and is returned in the conversation. It is saved under drafts/ only if you ask.

REVIEW reads the target, the documentation it links, and the architecture, conventions and decisions it depends on. It may look at existing code to judge feasibility or conflicts, but it does not judge completion and runs no build or test. It assesses the document itself, its acceptance criteria, its risks, and its fit with the project.

CHECK reads the target and its documentation, inspects git status and the diff, reads the source involved, runs the configured build and test commands (see below), and compares the outcome with the acceptance criteria. It also looks for documentation that claims behavior the code does not have, tasks marked complete too early, and troubleshooting marked resolved without a verifiable fix.

DEFINE and custom commands

MEM DEFINE <COMMAND> interviews you and writes a definition from the shipped template, COMMAND.template.md. The filename is the command: custom/ship.md defines MEM SHIP. Each definition declares a version, a status (active or disabled), a mode (read-only or may-write), the shell commands it may run, the external actions it performs, whether it takes a target, a one-line purpose (which MEM HELP shows), a procedure, its output, and what it must never do.

The agent does not invent the purpose, the procedure or the output; it asks. Permission fields start conservative (read-only, no shell, no external actions) unless you ask otherwise and your configuration allows it. You see the complete definition and confirm before anything is written.

You can also write a definition by hand from the template; that is equally valid.

Installing and first setup

You do not need to install it up front. The first time you use MEM REVIEW, MEM CHECK or MEM DEFINE in a project that does not have it, the agent offers to install it from the manifest. You can also pick it when MEM offers the extension catalogue at initialization. Installation writes these files under your knowledge base's extensions/mem-commands/ folder, after your confirmation:

• index.md, COMMAND.template.md
• commands/review.md, commands/check.md, commands/define.md

There is no setup step after that. The custom/ folder does not exist until you define your first command, and its absence is normal.

Commands

Command	What it does
MEM REVIEW <target>	Assesses a plan, task or troubleshooting document before or independently of its implementation. Read-only
MEM CHECK <target>	Assumes the work was declared complete and verifies it against the code, the diff, the tests and the documentation. Read-only with respect to the repository
MEM DEFINE <COMMAND>	Authors a project-specific command into custom/<command>.md and lists it in custom/index.md, with confirmation

Configuration

The extension has no options of its own. It follows these core settings in MEM.config.md:

Setting	Default	Effect on this extension
build_command	auto-detect	CHECK runs a build only if this is set explicitly. An auto-detected command is never run
test_command	auto-detect	Same rule for tests
extensions_require_confirmation	true	CHECK asks before running the configured build or test command
extensions_allow_external_side_effects	false	A custom command that changes state outside the repository needs confirmation unless this is true
extensions_enabled	true	When false, only core commands are available

Safety and permissions

• REVIEW and CHECK never change anything. They do not edit code, fix the target, change a task status, move items between current/ and done/, commit, apply patches or mark findings resolved. They report; you decide.
• CHECK runs only commands you configured. Running a build or a test is not a read: an auto-detected command could migrate a database, write artifacts or reach the network. So CHECK runs only build_command and test_command set explicitly in MEM.config.md, subject to confirmation. Anything it could not run is reported as Unverified, and it never claims a build or test passed without running it.
• DEFINE writes only two places: extensions/mem-commands/custom/<command>.md and extensions/mem-commands/custom/index.md, each write shown and confirmed first. It never touches source code, distributed files, EXT.md or other knowledge base areas.
• Definitions cannot grant themselves permissions. mode, shell and external are upper bounds set by MEM.config.md. A definition asking for more is written with the permitted value, and the reduction is stated. A definition never overrides your instructions, MEM.md or MEM.config.md.
• Definitions are reviewed content. A custom command is stored instruction text that fires on a short token, so treat it like code: review it in a pull request. It must never contain secrets, tokens or credentials (document a variable name, never its value), and never an install command.
• Writing a command name is not running it. Command tokens inside definitions, the template or documentation are never activations; otherwise these files would trigger themselves when read.
• The extension contains no executable content and performs no external actions, so extensions_allow_executable_content does not apply to it.

Where its files and data live

Path (under the knowledge base)	Content	Touched by updates
extensions/mem-commands/index.md	Shared procedure, precedence, command list	Yes
extensions/mem-commands/COMMAND.template.md	The definition schema	Yes
extensions/mem-commands/commands/*.md	The procedures of REVIEW, CHECK, DEFINE	Yes
extensions/mem-commands/custom/<command>.md	Your own commands	Never
extensions/mem-commands/custom/index.md	The catalogue of your own commands	Never

The distributed index.md deliberately does not list your custom commands: an update would overwrite those entries. The custom layer catalogues itself in custom/index.md. Reports are returned in the conversation and stored nowhere unless you ask.

Limits and known issues

• The quality of a review depends on the evidence available. When the evidence for the main requirements is missing, the verdict is NOT VERIFIABLE rather than a guess.
• Without an explicitly configured build or test command, the build and test part of CHECK is always Unverified.
• Custom command names cannot reuse REVIEW, CHECK, DEFINE or any core command name.
• DEFINE refuses a name whose definition already exists, unless you ask to revise it.
• Not every procedure deserves a command. A single operation, or something that amounts to running one shell command, is better kept as a reference page or a toolbox entry: a command for a trivial action is one more name to remember in exchange for a sentence saved.
• MEM LINT flags definitions written against a superseded template version.

See also

• Specification: https://github.com/Ryadel/MEM/blob/main/src/extensions/mem-commands/index.md
• Extensions
• mem-toolbox, where a single tool or one-off operation belongs instead of a custom command