sage

Plugin sage from marketplace sage in erickb336/sage-stack. Commands read from the repo's manifest — yesterday.

Skills (33)

• dictionary

  The sage dictionary: sage's approved words, one meaning each, and the words not to say. Apply to any text an agent writes for a person in sage mode: briefs, reports, findings, pages and the README.

• presentation

  Present to the owner: each kind of message, its parts in order, the pictures, the pages and the message command. Apply to every message that the chief sends to the owner in sage mode: a progress note, a question, a report, a catch-up, a design, and the other kinds below.

• principle-attack-the-premise

  Attack the premise. Apply when two or more fixes that share one premise have failed the same check or review.

• principle-boundary-discipline

  Boundary discipline. Apply when reviewing or writing validation, error handling or framework adapters.

• principle-build-the-lever

  Build the lever. Apply when the work is not trivial: edits, migrations, analyses or checks.

• principle-contextualize-and-write-for-the-reader

  Contextualize and write for the reader. Apply when writing anything someone else will read later: a design, a handoff, findings, a report, a verification, a brief, a reply.

• principle-encode-lessons-in-structure

  Encode lessons in structure. Apply when writing the same instruction a second time, or noticing a correction that keeps recurring.

• principle-exhaust-the-design-space

  Exhaust the design space. Apply when a new interaction or an architectural choice has no precedent in the code.

• principle-experience-first

  Experience first. Apply when a product, UX or scope trade-off comes up.

• principle-explain-the-number

  Explain the number. Apply when you plan a measurement, or you trust, report or act on a number that you measured: a speedup, a regression, a throughput, a latency or an eval result.

• principle-fix-root-causes

  Fix root causes. Apply when debugging a failure or repairing a finding.

• principle-foundational-thinking

  Foundational thinking. Apply when before writing logic, when choosing core types and data structures or ordering scaffold against features.

• principle-guard-the-context-window

  Guard the context window. Apply when the context fills up: large outputs, long files, repeated reads or planning a fan-out.

• principle-laziness-protocol

  Laziness protocol. Apply when refactoring, judging a diff's size, or tempted to add an abstraction, a layer or a threaded signal.

• principle-make-operations-idempotent

  Make operations idempotent. Apply when you design commands, lifecycle steps or processing loops that run among crashes, restarts and retries.

• principle-migrate-callers-then-delete-legacy-apis

  Migrate callers, then delete legacy APIs. Apply when a change introduces a new internal API while callers of the old one still exist.

• principle-minimize-reader-load

  Minimise reader load. Apply when reviewing or shaping code that is hard to follow.

• principle-model-the-domain

  Model the domain. Apply when you write stateful logic, or code branches a lot or repeats an assumption about a shape across files.

• principle-never-block-on-the-human

  Never block on the human. Apply when tempted to ask \"should I do X?\" about reversible work.

• principle-outcome-oriented-execution

  Outcome-oriented execution. Apply when a planned rewrite or migration has explicit phase boundaries.

• principle-prove-it-works

  Prove it works. Apply when before declaring a task done, or when judging a claim that something works.

• principle-redesign-from-first-principles

  Redesign from first principles. Apply when you add a new requirement to an existing design.

• principle-separate-before-serializing-shared-state

  Separate before serializing shared state. Apply when concurrent actors might write to the same file, branch, key or state object.

• principle-sequence-verifiable-units

  Sequence verifiable units. Apply when multi-step work (a sweep, a migration, a run of similar edits) or the order of commits in a change.

• principle-subtract-before-you-add

  Subtract before you add. Apply when ordering an addition, a refactor or a rewrite.

• principle-test-behavior-not-implementation

  Test behaviour, not implementation. Apply when writing, changing or keeping a test.

• principle-type-system-discipline

  Type system discipline. Apply when you design types, review a function signature or write code in a statically typed language.

• readme-guide

  Write a project README. Apply when you write, change or review a README of any project, in any language.

• remote-control

  Set up Remote Control, so that the user can follow, steer and start Claude Code sessions from the Claude app on a phone. It turns Remote Control on for every new session, and it can run a server in a folder (such as ~/workspace) that starts at each login. Use when the user asks to reach sessions or

• report

  The report that every sage agent ends with: STATUS, RESULT, EVIDENCE, FINDINGS, QUESTIONS, NOT VERIFIED, BRANCH. Use at the end of any task that the sage chief of staff gave you. Claude Code only.

• sage-help

  Help with sage: how to set it up, switch sage mode and autopilot, read the board, answer the chief's questions, pick a skill or a principle, fix a run that went wrong, and find where sage keeps its files. The user types /sage:sage-help (or /sage-help) with a question. Load it only when the user type

• sage

  The state tool of sage mode: records tasks, routes, agent runs, findings, verdicts by head SHA and the user's gates in ~/.claude/sage/<project>/. Use in sage mode for every change of a task's state, and before any merge. Claude Code only.

• writing-standard

  Write at 80% of Simplified Technical English. Apply to any text an agent writes for a person: messages, reports, specs, findings, reviews, plans.

Subagents (12)

• arena-judge

  Judges an arena in sage mode: scores each candidate against the rubric, picks the base, grafts the best parts of the others into it on its own new branch, and checks the result. Use after all arena candidates have reported.

• chief-of-staff

  The user's chief of staff (sage mode). Routes each task through specialist agents (sage:lead, one for each pull request, and pe, designer, implementer, code-reviewer, security-reviewer, ux-reviewer, qa, arena-judge), keeps the state in the sage logbook, asks the user only product questions and irrev

• code-reviewer

  Reviews one change independently: correctness, data safety, regressions and test evidence. Reports findings with locations and steps to reproduce. Never changes files. Use on each change in sage mode, beside the security review.

• designer

  Designs the experience before the build: screens, states and copy, as a clickable prototype with sample data. Use for new screens, flows or copy in sage mode.

• evidence-review

  Reviews an investigation independently: checks each claim against its command output or source, and reports CLEAN or FINDINGS with evidence. Never changes files. Use for the evidence-review step of an investigation in sage mode, as a different agent from the investigator.

• implementer

  Builds one task from the chief of staff in its own git worktree, runs the checks, and opens a pull request. Also repairs the findings of reviews and QA on the same branch. Use for each change to a project in sage mode.

• investigate

  Investigates one question for the chief of staff: gathers evidence with read commands, tests each explanation, and writes its research page in the task's pages folder. Changes no project files. Use for the investigate step of an investigation in sage mode.

• lead

  Runs one task's pull request for the sage, from the build to its clean cycles: briefs the implementer, runs the reviews and QA in cycles and the repair rounds, records its own task's runs, findings and verdicts, and reports once. The sage records the checks and merges. Never merges, never asks the u

• pe

  Principal engineer. Before the build, checks that a plan or a design can be built: feasibility, data, scale, security and cost. Separates the changes it needs from the product questions for the user. Read-only. Use for large tasks and milestones in sage mode.

• qa

  Checks one result as a user would: runs the checks, runs the app, and tries to break the change. Reports pass or fail with evidence. Never changes files. Use as the last step of each flow in sage mode.

• security-reviewer

  Reviews one change for security: input at the boundaries, injection, secrets, access control and data exposure. Reports findings with locations and an attack scenario. Never changes files. Use on each change in sage mode, beside the code review.

• ux-reviewer

  Compares a built or designed experience with the intended flow: steps, states, copy and accessibility, with screenshots. Never changes files. Use on screens, flows and copy in sage mode.

Similar plugins