Skip to main content

sage-checkpoints

Presenting work for approval and formatting the response footer. Use when reaching an approval gate, showing a spec, plan, brief, or finished deliverable, offering the user choices, or when unsure which zone footer a response should end with.

Ir para a instalação

Informações da origem

Repositório
xoai/sage
Última atividade na origem
11 de julho de 2026 às 18:22
Idioma detectado do SKILL.md
inglês
Estrelas
27
Forks
7

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
sage-checkpoints
description
Presenting work for approval and formatting the response footer. Use when reaching an approval gate, showing a spec, plan, brief, or finished deliverable, offering the user choices, or when unsure which zone footer a response should end with.
version
1.0.0
type
system
# Checkpoints and interaction zones The eager layer carries the contract: `[A]` approve, `[R]` revise, `[C]` continue — show the work, wait. This carries the detail. ## Checkpoints are sacred (Rule 4, in full) Never skip human approval on a brief, a spec, a plan, or a final deliverable. - **Show the work.** A checkpoint that summarizes instead of showing is asking for approval of a description, not of the thing. - **Wait.** Not "proceed unless told otherwise". Wait. - **Never change scope unilaterally.** Do not defer, skip, or deprioritize planned work without asking. - **Never mark an initiative complete while tasks remain unfinished.** If work cannot be completed, say what remains and let the user decide. The last one is the one that gets violated, and it never looks like a violation from the inside. It looks like judgment: the remaining task seemed unnecessary, or blocked, or the user seemed to want to be done. Scope is the user's to change. Surfacing an unfinished task costs a sentence; deciding it away for them costs their trust in every completion claim you make afterwards. ## The four zones Every response that expects input ends with **exactly one** zone footer. The footer tells the user what inputs are valid, so they never have to guess. **Zone 1 (Choice)** — picking a direction: ``` [1] [Option] — [skill → chain] ([N] steps) [2] [Alternative] — [chain] ([N] steps) Pick 1-N, type / for commands, or describe what you need. ``` **Zone 2 (Approval)** — reviewing a deliverable: ``` [A] Approve [R] Revise [N] New session → /[next] to continue Pick A/R/N, or tell me what to change. ``` **Zone 3 (Next step)** — the workflow is done, point at what follows: ``` /[command] — [chain] ([context]) /[command] — [chain] Type a command, or describe what you want to do next. ``` **Zone 4 (Open)** — waiting for the user to describe something: ``` Describe what you want to work on, or type / to see commands. ``` ### Rules - **One zone per response.** Never mix them. - The footer is **always the last line** when input is expected. - **No footer = informational only.** If you are not expecting a response, do not ask for one. - Zone 1 shows chains with `→` and step counts. No time estimates. - Zone 2's `[N]` always names the next slash command inline. ## Formatting **Never use code blocks for interaction.** Checkpoints, options, and transitions are plain text with bold emphasis. Code blocks are for code. A checkpoint rendered in a code block reads as output rather than as a question, and users scroll past it.
Ver no GitHub