core/capabilities/orchestration/autonomous/SKILL.md
When --autonomous is active, skip user-facing elicitation rounds. The agent makes elicitation decisions from memory, codebase patterns, constitution principles, and prior cycle context. Every decision cites its source. Substantive decisions with no signal fall back to asking the user.
npx skillsauth add xoai/sage autonomousInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
When the workflow has autonomous_mode: true (set by --autonomous
flag, see flag-parser/SKILL.md), elicitation rounds are skipped in
favor of agent-driven decisions backed by explicit context sources.
The artifact structure is unchanged — brief.md, spec.md, plan.md still exist with the same sections. What changes is HOW their content is populated.
Before producing any artifact, gather context. This is not optional — the autonomous mode's quality depends entirely on the inputs.
Parameter types: query is a string, limit is an integer, filter_tags is an array of strings. Not JSON strings — actual types.
Activate codebase-scan skill at
sage/core/capabilities/elicitation/codebase-scan/SKILL.md.
.sage/conventions.md if present.sage/constitution.md (preset + project additions)sage/core/capabilities/execution/coding-principles/SKILL.md.sage/decisions.md.sage/work/*/manifest.md for active or recent related cycleshandoff fields from related artifactsFor each elicitation question the workflow would normally ask (framing, intent, scope, boundaries, constraints, criteria, risks, approach, task ordering, etc.), the agent:
rationale field citing the sourceA decision is "confident" when AT LEAST ONE of these holds:
| Signal | Example | |--------|---------| | Direct memory hit | Correction or convention exactly matching the question | | Strong codebase pattern | 3+ existing examples of the same approach | | Constitution principle | A principle directly speaks to this decision | | Prior decision | Same initiative/cycle has already decided this | | Single-option safety | Only one safe choice exists (e.g., "validate inputs") |
A decision is "unconfident" when:
"Substantive" means: affects behavior, API, architecture, or long-term maintenance. Examples: data model choices, auth approach, error handling strategy, API contract decisions.
"Cosmetic" means: doesn't affect behavior or maintenance. Examples: file naming within an established pattern, comment phrasing, ordering of internal helpers.
Every artifact produced under --autonomous includes a rationale
block at the top, after the frontmatter:
## Recommendation Rationale
This artifact was produced with `--autonomous`. Key decisions:
- **{Decision label}:** {Choice made} — {citation: memory entry,
codebase pattern, principle, or "default — no signal"}
- **{Decision label}:** {Choice made} — {citation}
- **{Decision label}:** {Choice made} — {citation}
**Tradeoffs accepted:**
- Short-term: {immediate cost or constraint}
- Long-term: {future risk or maintenance burden}
- Why this is the right balance: {1 sentence}
**Decisions asked back to user:** {list of questions, or "None"}
Keep the block to ≤10 bullet decisions. If more decisions were made,
group related ones. Detailed rationale goes in decisions.md, not in
the artifact.
When the agent hits unconfident substantive decisions, present them as a Zone 1 choice block BEFORE producing the artifact:
Sage: --autonomous hit 2 decisions I can't recommend confidently.
[Q1] {Question}
{Why I can't decide: no memory, no codebase pattern, etc.}
{Why it's substantive: affects security / API contract / etc.}
[Q2] {Question}
{Same reasoning}
Answer 1-2 inline, or pick [D] Default — I'll use my best guesses
and document them as project decisions.
If user picks [D], the agent documents the defaults in the rationale block AND prepends a decision to decisions.md so the choices are visible for review.
When BOTH --autonomous AND --quality-locked are active, the user
has signaled "decide the best approach yourself AND don't stop until
clean." Asking them to manually pick [A] Review at every approval
checkpoint contradicts both flags. At normal approval checkpoints
where the choices are [A] Review / [S] Skip review / [R] Revise / [N] New session, only [A] Review is consistent with both flags:
| Option | Consistent with --autonomous --quality-locked? |
|--------|-------------------------------------------------|
| [A] Review | ✅ Triggers quality-locked loop |
| [S] Skip review | ❌ Defeats --quality-locked |
| [R] Revise | ❌ Requires user input — contradicts --autonomous |
| [N] New session | ❌ Requires user input |
Auto-pick [A] Review at normal approval checkpoints when both
flags are active. This is not bypassing a decision — it's the
deterministic conclusion of the user's stated intent.
Print a clear notice in place of the prompt:
Sage: Auto-proceeding with [A] Review.
Reason: --autonomous --quality-locked both active. [A] is the only
option consistent with both flags.
Logged to: .sage/work/<cycle>/manifest.md (auto_picked_checkpoints)
Override: interrupt this session and re-run without one of the flags.
Then run the [A] Review path (sub-agent review → quality-locked loop) without waiting for input.
Exception checkpoints still require user input even with both flags active. These represent moments where automated continuation could hide a real problem:
[F] Force / [R] Revise manually / [E] Escalate / [A] Abort) — 10 iterations without convergence
means structural issues. User judgment required.[E] Escalate / [C] Continue / [R] Revise manually) — 3 iterations with no improvement.
Architecture-level question.[Q1]/[Q2] block
that surfaces when the agent can't recommend a substantive decision)
— by definition, the agent is asking because it doesn't know.For all of the above, present the full prompt and wait. Do NOT auto-pick.
Every auto-picked checkpoint is logged to TWO places:
1. manifest.md frontmatter — add the entry under
auto_picked_checkpoints. Each entry records the flag source so the
audit trail explains why each mode was on:
auto_picked_checkpoints:
- phase: spec
checkpoint: spec-approval
decision: A
timestamp: 2026-05-15T14:23:18Z
reason: "--autonomous --quality-locked both active"
flag_sources:
quality_locked: config # set in .sage/config.yaml
autonomous: flag # passed as --autonomous
- phase: plan
checkpoint: plan-approval
decision: A
timestamp: 2026-05-15T14:31:47Z
reason: "--autonomous --quality-locked both active"
flag_sources:
quality_locked: config
autonomous: flag
This is machine-readable and lets /continue understand exactly which
checkpoints proceeded without user interaction, and where the trigger
came from.
2. decisions.md — prepend a human-readable entry (per Rule 7). The "Flags active" line names each mode's source; the Override hint adapts per flag:
### 2026-05-15 14:23 — Auto-pick: [A] Review at spec checkpoint
Flags active: --autonomous (flag), --quality-locked (config)
Effect: Triggered quality-locked review loop (results in manifest
under quality_locked_history.spec).
Override: pass --no-quality-locked to opt out of the .sage/config.yaml
default for one run; omit --autonomous to disable the flag.
"config" → "pass --no-X to opt out of the .sage/config.yaml
default for one run""flag" (value on, came from --X) → "omit --X to disable
the flag""flag" (value off, came from --no-X) → no override hint
needed (mode already off; this case shouldn't occur in auto-pick
logging since the auto-pick path requires both modes ON)null → not in the override section (not active)Each active flag contributes one clause; join with semicolons.
Both writes happen BEFORE the [A] Review action runs. This way, if the review loop crashes or the user interrupts, the audit trail still shows the auto-pick happened and why.
The user trusted the flags to make decisions for them. The contract
back to the user is: every auto-pick is traceable, reviewable, and
reversible by inspecting .sage/work/<cycle>/. No hidden behavior.
If memory says X but codebase pattern says Y:
If the user later corrects the autonomous decision, the new correction
is stored as a learning ([LRN:correction]) so future autonomous runs
have better signal.
After each phase, the workflow updates the manifest:
autonomous_decisions:
- phase: brief
decided: 4
asked: 0
sources: { memory: 2, codebase: 1, principle: 1 }
- phase: spec
decided: 8
asked: 1
sources: { memory: 5, codebase: 2, principle: 1, default: 0 }
- phase: plan
decided: 12
asked: 0
sources: { memory: 3, codebase: 6, principle: 2, prior: 1 }
This makes the autonomy budget visible — high "asked" counts suggest the agent should defer to human elicitation, low counts suggest the context was rich enough.
[LRN:correction] so future runs avoid the
same pattern.Autonomous decisions cannot:
The agent's autonomy is over CONTENT, not PROCESS. Process rules (Rule 0-7, anti-deferral, memory-first, etc.) still apply.
development
Branch-per-initiative git discipline for all delivery workflows. Defines branch naming by workflow, the propose-confirm creation protocol, dirty-tree and detached-HEAD handling, the always user-gated merge protocol, worktree support for parallel sessions, and abandonment cleanup. Activates only in git repositories — silently inactive everywhere else. Use when starting /build, /fix, /architect, or /build-x at Standard+ scope, when resuming an initiative, when offering a merge at a completion checkpoint, or when the user wants a second concurrent initiative.
development
Drives task-by-task execution from an approved plan with quality gates between each task. Reads the plan, finds the next incomplete task, dispatches implementation, validates, updates progress, and continues. Use after a plan is approved and the user says "go", "start building", "execute the plan", or "implement the feature".
testing
Preserves and restores context across agent sessions using plan file checkboxes as source of truth. Use when starting a new session, resuming previous work, ending a session, or when the user says "continue from last time", "what was I doing", or "save progress".
tools
Captures agent mistakes, corrections, and discovered gotchas so they are not repeated. Use when: (1) a command or operation fails unexpectedly, (2) the user corrects the agent, (3) the agent discovers non-obvious behavior through debugging, (4) an API or tool behaves differently than expected, (5) a better approach is found for a recurring task. Also searches past learnings before starting tasks to avoid known pitfalls. Activate alongside the sage-memory skill — they share the same MCP backend but serve different purposes (sage-memory = codebase knowledge, sage-self-learning = agent mistakes and gotchas).