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.

설치로 이동

소스 정보

저장소
xoai/sage
최근 소스 활동
2026년 7월 11일 18:22
감지된 SKILL.md 언어
영어
스타
26
포크
7

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기