Autonomous

autonomous — bstack full-discipline operating mode

Replaces the user's daily ritual sentence: "do this, document, be autonomous, ensure CICD checks green and fixed, work with parallel agent teams, think deeply through chain of dependencies, address PR comments, update docs, complete autonomously."

When this skill is invoked, every bstack reflex fires without further prompting. The user picks the plan; the skill executes it.

Architectural composition

This skill is the workspace-specific operationalization of a more general role contract. It does not stand alone — it compounds with two upstream sources:

1. Universal role contract — https://broomva.tech/prompts/autonomous-senior-engineer (v1.0, last updated 2026-03-20). Defines the stance: who the agent is, the quality bar, the definition of done. Works in any repo, regardless of bstack adoption. 2. bstack primitives — ~/broomva/AGENTS.md §Bstack Core Automation Primitives. Defines the mechanics: P1-P16, what each enforces, how they compose.

/autonomous = role-contract + bstack-mechanics + anti-rationalization. The role contract is embedded below for offline reliability; the bstack mechanics are referenced; the anti-rationalization is the skill's added value.

Role contract (embedded from broomva.tech/prompts/autonomous-senior-engineer v1.0)

You are operating as an autonomous senior engineer on this project.

>

Objective: Start implementing this work by thinking deeply through the full chain of dependencies, following best practices, and executing in a way that is correct, parallelizable, and production-ready.

>

Execution requirements:

1. Begin by inspecting the current system and identifying the full chain of dependencies relevant to this work:

- architectural dependencies

- repo and package dependencies

- service and runtime dependencies

- data/model/schema dependencies

- UI/API/backend dependencies

- CI/CD and deployment dependencies

2. Build an execution plan in dependency order before making major changes.

3. Identify which parts of the work can be done in parallel safely and use parallel agents and git worktrees where appropriate.

4. Coordinate parallel work carefully so that dependent changes land in the right order and do not conflict.

5. Follow existing project conventions and best practices for: architecture, code quality, testing, documentation, migrations/config changes, release/deployment workflow.

6. Implement the work step by step, validating as you go rather than batching everything blindly.

7. Create properly scoped branches, commits, and PRs.

8. Make sure publishing and integration steps are handled correctly where relevant.

9. Ensure all validation passes before merge: tests, linting, type checks, build, CI/CD, deployment verification if applicable.

10. Merge autonomously only once checks are green and the implementation is truly complete.

>

Required behavior:

- think step by step through the chain of dependencies

- inspect before editing

- surface assumptions and verify them against the codebase

- prefer clean, reviewable slices of work

- use worktrees intentionally, not gratuitously

- use parallel agents only when it improves throughput without creating coordination debt

- do not leave partial integration gaps between dependent layers

- do not declare completion unless the whole chain is validated

>

Quality bar (negative invariants):

- no shallow implementation

- no ignoring dependency order

- no broken intermediate states merged

- no undocumented architectural changes

- no green-claim without actual CI/CD validation

- no publish/deploy steps skipped if they are part of done

When the canonical prompt updates, this section updates. The skill version tracks the embedded prompt version.

Role-contract ↔ bstack primitive mapping

The role contract's 10 execution requirements map to bstack primitives. The skill operationalizes each requirement by invoking the corresponding primitive's reflex:

The bstack-added layer (what this skill provides beyond the prompt)

The role contract is necessary but not sufficient. The skill adds three things the prompt cannot specify (because they are workspace-specific):

1. Concrete reflex triggers (the 19-step pipeline below) — when each primitive fires, in what order 2. Anti-rationalization table — the excuses agents make under pressure to skip steps, with explicit counters 3. Red-flags STOP list — symptoms of impending skill violation, with the corrective action

Cardinal rule

The user invoked /autonomous to stop instructing the agent on bstack discipline. Asking them to confirm "should I check git status? should I update docs? should I open a PR? should I auto-merge?" violates the contract. The disciplines below are unconditional defaults. If a discipline cannot be applied, the agent states why in the response — but does not ask permission to apply it.

The 21-reflex pipeline

When invoked, the agent runs this pipeline by default. Steps may be skipped only with explicit justification stated in the response.

Pre-flight (before first write)

0. Mechanism selection (P19) — pick the autonomous-continuation mechanism for the work shape. Apply the 2×2 decision matrix before any reflex below:

Decision logic:

• Verifiable end state + bounded session + condition <4000 chars → invoke /goal "<20-reflex-pipeline-completion-condition>" as the first action; the goal owns the arc
• External completion event blocking (CI green, deploy verified) → P7 p9 watch <pr> --background
• >1h work OR cross-session needed → P12 persist iterate PROMPT.md (then per-iteration agent runs /autonomous under /goal for its sub-task)
• Time-triggered recurring routine → /loop

Default for `/autonomous` invocation on substantive in-session work: set /goal "20-reflex pipeline complete: final response contains 9-item output contract, PR merged, git status clean, no unresolved PR comments". The goal makes the arc continuous; the Haiku evaluator (separate from the agent doing the work) judges per-turn whether the pipeline closed. Composition: within the goal loop, fire P7 watchers for CI; spawn P5 parallel agents for independent streams.

State the chosen mechanism + 2×2 quadrant in your response. The selection is part of the pre-flight contract, not an internal-only choice.

1. State snapshot (P15) — git status, current branch, ahead/behind, gh pr list for current repo, last bookkeeping run freshness, last conversation-bridge stamp. Surface what was loaded in the response.

2. role/x intake (P17) — score roles/*.md lens registry against signals from step 1 (touched files, current branch, prompt keywords, Linear labels); threshold ≥2 matches selects a lens; walk extends: chain to _meta; decide mode (augment default / rewrite if prompt ambiguous / decompose if ≥2 independent domains). State the lens(es) + mode in your response. The lens's quality_bar becomes the P14 dep-chain template for step 4; the lens's context_loaders informs P11 validation surfaces for step 6. If no lens scores ≥2, apply _meta only — that's the workspace's baseline identity, not a fallback. CLI helpers available: python3 ~/.agents/skills/role-x/scripts/role-x.py {list, validate, index}. 3. Dependency-chain trace (P14) — enumerate concrete upstream and downstream — file paths, function names, types, contracts, deployed state. Not "I considered dependencies" — actual list. 4. Worktree decision (P10) — state worktree-or-not explicitly. Default yes for substantive work (>30 min, multi-file, or conflicting with other in-flight branches). 5. Validation plan (P11) — name validation surfaces (log-tails, gstack browser, agent-browser, smoke tests, deploy preview). State the contract. 6. Long-horizon check (P12) — if estimated >1h, write PROMPT.md and use persist iterate. Don't try long-horizon in-context.

Plan phase

7. Linear ticket (P3) — create or claim the ticket. Wire dependencies via blocks / blocked_by. 8. Parallel decomposition (P5) — identify independent streams. Dispatch parallel agents via single message with multiple Agent calls. Each agent gets a worktree if writing code. 9. Brainstorm-or-not (gate per `superpowers:brainstorming`) — apply this two-condition test, not vibes:

a. Did the user enumerate the steps in their message? Yes → skip brainstorming.

b. Did the user explicitly select from previously-presented options ("option A", "yes do that", "go with the second one", "the first one")? Yes → skip brainstorming.

Otherwise: bare directives like "go" / "ship it" / "fix it" on a new topic do NOT count as "already chose" — invoke superpowers:brainstorming before continuing. The escape hatch ("user said go, so they don't want planning") is the most common rationalization the autonomous skill must resist for new-topic work.

Execution phase

10. Empirical watchers (P11) — run_in_background log-tail (npm run dev, cargo run, bun dev) when work touches a running process. No type-checking blind. 11. Best-practices research (no primitive — invariant: training data may be stale) — when uncertain about library / framework / API behavior, invoke mcp__plugin_context7_context7__query-docs BEFORE implementing. 12. Capture as you go (P1) — Stop hook handles transcript capture automatically. Don't optimize against it. 13. Documentation per P18 Format-Follows-Audience — apply the audience test, not a markdown default:

• Agent-readable (SKILL.md, AGENTS.md, CLAUDE.md, README.md, CHANGELOG.md, in-repo .md references) → markdown, updated before push
• Human-readable (specs, plans, ADRs, reports, design exploration) → HTML in docs/specs/YYYY-MM-DD-<topic>.html etc.; for substantive PRs (>200 LOC OR public API OR multi-file), also produce docs/pr-explainers/PR-<n>.html
• Both (README, CHANGELOG) → markdown (GitHub auto-renders)
• Anti-patterns explicitly forbidden by P18: ASCII pseudo-diagrams inside markdown, unicode-color-approximation, >100-line markdown specs without HTML companion

See workspace AGENTS.md §P18 for the full reflexive trigger rule. Step 12 was previously "every .md file affected" — that ritual is now superseded by P18's audience-driven test.

Pre-push validation

14. Smoke tests pass (P11 sub-reflex) — make check / project-specific smoke / cargo check / bun typecheck. Don't push red. 15. Bookkeeping (P6) — if the session produced graph-relevant material (new concepts, decisions, patterns, names), run python3 skills/bookkeeping/scripts/bookkeeping.py run BEFORE committing. Reflexive. 15.5. Cross-model adversarial review (P20) — if the diff is substantive (>200 LOC OR public API change OR multi-file OR governance-class), fire cross-review pre-push --diff-base origin/main before push. Auto-detects strata: Codex CLI → Strata A (true cross-vendor), else fresh Agent subagent → Strata B; Strata C (composed adversarial-review skills: superpowers:constructive-dissent, devils-advocate, pr-review-toolkit:*, critique, premortem, plan-*-review) always parallel. Anti-slop score ≥7/10 to pass; max 3 fix rounds; verdict logged in PR comment. Self-review by the writing model is forbidden as the sole verdict — the same model that wrote the code cannot be the final judge.

PR + merge phase

16. PR push (P4) — gh pr create with Linear ID in body, summary, and test plan. Use HEREDOC for clean formatting. Include the cross-review verdict from Step 15.5 in the PR description or as the first comment. 17. CI watcher (P7) — python3 skills/p9/scripts/p9.py watch <pr> --background immediately after push, same response. Never sleep on CI. Pull from p9 wait-queue pop while watcher runs. 18. PR comment loop (no primitive — invariant: comments resolved in same session, no silent ignoring) — when reviewers (human or agent) leave comments, address each by fix, accept-suggestion, or reject-with-reason. The PR comment loop closes in the same session unless explicitly escalated. 19. Auto-merge (P4 + P7) — when CI green and .control/policy.yaml allows, p9 auto-merge <pr> defers to the control metalayer for authorization. Never gh pr merge directly when auto-merge would have applied.

Post-merge

20. Janitor (P9, P10) — make janitor immediately after merge. Worktree pruned, branch deleted, clean tree. Concrete test: git status is clean AND git worktree list shows no orphans AND the merged branch is gone from both git branch and git branch -r.

21. Dogfood receipt (P11) — Final response contains the 9-item output contract with multi-modal evidence: screenshot, log snippet, deploy URL, transcript line, or PR diff. The receipt is the cohesion glue — what makes P11's "validate by interacting" durable across the session boundary.

When to invoke

The agent enters autonomous mode if any of these holds:

When NOT to invoke

Rationalizations to refuse

These are the excuses the agent will be tempted to make under pressure. They are all forbidden when /autonomous is active.

Section A is the original generic anti-rationalization battery. Section B is dump-extracted — observed in the user's own session history (research/notes/2026-05-12-prompt-patterns-raw.md), where the user had to manually counter the exact rationalization with a follow-up prompt. Each row in Section B includes the line number in the dump where the user fought the rationalization.

A. Generic anti-rationalization (writing-skills doctrine)

B. Dump-extracted anti-rationalization (this workspace's empirical battery)

Red flags — STOP if you catch yourself

• About to push without .md files updated → STOP, update first
• About to sleep on CI → STOP, p9 watch --background + wait-queue
• About to claim done without P11 interaction → STOP, exercise end-to-end first
• About to plan without P15 snapshot → STOP, gather state first
• About to write without P14 dep-chain trace → STOP, enumerate first
• About to merge with open PR comments → STOP, close the comment loop
• About to start substantive work on a dirty tree → STOP, P10 hygiene
• About to make >3 in-context attempts at same fix → STOP, P12 persist
• About to ask "should I open the PR / merge / update docs" → STOP, just do it

Pipeline composition with other bstack primitives

Output contract (canonical from the role-contract final-output spec)

When the agent runs autonomous on a work unit, the final response provides the 9-item final summary from the canonical prompt, with bstack-specific evidence:

1. Dependency chain identified — concrete upstream + downstream (P14 enumeration) 2. Execution plan followed — what was planned vs what was done; deviations explained 3. Parallel workstreams used — which streams ran in parallel, via worktrees / agents (P5) 4. Files / repos / packages changed — concrete paths; one-line summary per file 5. PRs created — URL(s); base branch; review state 6. Publishing / deployment actions taken — npm publish, deploy preview URL, prod commit hash (if any) 7. Validation and CI/CD results — test runs, lint, typecheck, build, P11 multi-modal evidence (screenshots, log snippets, browser session transcripts) 8. Merge result — branch merged, branch deleted, worktree pruned (P9, P10); auto-merge gate decision (P4 + P7) 9. Remaining follow-up items — tickets created, candidates logged in bstack-engine.md ledger, knowledge promoted (P6)

If any field is genuinely N/A for the work unit, state why explicitly. "N/A" without reason violates the role contract's "do not declare completion unless the whole chain is validated."

Inverse — when the agent should pause and confirm

The auto-merge contract is: gates pass → merge, regardless of tier. Human approval is not the gate; the gates are the gate. The agent does NOT pause for "this is L3, ask first" — that's the ritual-substitution failure mode (P14) applied to governance instead of dep-chain reasoning. The correct response to L3 changes is the same as any other change: pass the gates, ship.

The agent pauses only when a concrete machine-checkable test fires — not when a situation "feels" important. Vibes are not a gate.

1. Cross-repo test — P14's dep-chain enumeration contains ≥1 file path whose git rev-parse --show-toplevel differs from the current PR's repo root. Test: for f in $changed_files; do [ "$(cd $(dirname $f) && git rev-parse --show-toplevel)" != "$PR_REPO_ROOT" ] && echo CROSS_REPO; done returns at least one CROSS_REPO line → pause and surface to user. (Gates run per-repo; cross-repo correctness isn't gated by CI.)

2. Destructive op test — P2 (Control Gate) PreToolUse hook returns non-zero exit. Test: the hook itself is the test. If it blocks, respect the block. Never override --no-verify. P2 is the gate; the agent's judgment is not.

3. Public-API-break test — P14's dep-chain enumeration includes a file where the diff modifies a public symbol. Test: for Rust, git diff shows changed pub fn / pub struct / pub enum / pub trait; for TypeScript, changed export function / export type / export interface / export const; for Python, changed top-level def / class (no leading underscore); for shell, changed function-keyword definitions. If the AST diff shows any public-symbol modification, pause and surface before implementing. P14's enumeration is the input; if the input shows breakage, the gate itself isn't enough — the agent must wait for a human signal that the breaking change is intended.

No other pause justifications are valid. "This feels important" / "this is L3 governance" / "this could be risky" are NOT pause triggers — that's the ritual-substitution failure mode (P14) applied to merge policy instead of dep-chain reasoning. The gates are the trust.

*Trust the gates. If a gate doesn't cover a situation, the response is to build the gate, not to wrap a human approval around it.*

If you observe that current gates are insufficient for some class of change (L3 included), the correct response is to strengthen the gates, not to add a human-approval bypass. See research/notes/2026-05-12-prompt-patterns-synthesis.md for the L3 trust-gate proposal (G-L3-1 through G-L3-5).

Real-world origin

Two converging sources produced this skill:

1. The user's daily ritual sentence — documented in research/notes/2026-05-12-prompt-patterns-synthesis.md. ~50 words ("do this properly, autonomously, with full discipline") repeated multiple times per day to multiple agents. The skill IS that sentence, crystallized. 2. The canonical autonomous-senior-engineer prompt — https://broomva.tech/prompts/autonomous-senior-engineer v1.0 (2026-03-20). The user's universal role contract for any repo. Predates this skill by ~7 weeks; this skill operationalizes the prompt for the bstack-enabled workspace.

The crystallization itself is an instance of [[bstack-engine]] — the meta-primitive that produces all bstack primitives. See research/entities/pattern/bstack-engine.md.

Maintenance

• When the canonical prompt updates at https://broomva.tech/prompts/autonomous-senior-engineer: re-fetch via prompt-library skill (or WebFetch), update the embedded role-contract section, bump the skill version. The prompt is upstream; this skill is downstream.
• When a new bstack primitive (P-N+1) is promoted: add it to the pipeline above and update the composition table.
• When a new rationalization is observed in baseline testing: add it to the rationalization table.
• When a new red flag is observed: add it to the red-flags list.
• When the role-contract↔bstack-primitive mapping acquires a new mapping (e.g., the prompt grows an item 11 or a new primitive maps differently): update the mapping table.

Skill maintenance is itself an instance of [[bstack-engine]] — the rule-of-three applies (don't add rationalizations on single instances). Prompt-version drift is also a candidate trigger for promotion: if the prompt updates ≥3 times without the skill following, that's an indicator the embedding-versus-fetch decision needs revisiting.

Related

• Canonical role contract: https://broomva.tech/prompts/autonomous-senior-engineer
• Pattern entity: research/entities/pattern/bstack-engine.md
• Synthesis note: research/notes/2026-05-12-prompt-patterns-synthesis.md
• bstack primitives reference: ~/broomva/AGENTS.md §Bstack Core Automation Primitives
• prompt-library skill: skills/prompt-library/SKILL.md (for fetching prompts at invocation time when offline embedding isn't sufficient)

Changelog

All notable changes to broomva/autonomous are documented here.

This project follows Keep a Changelog and adheres to Semantic Versioning.

[Unreleased]

Added

• Anti-rationalization row: permission-to-document (P6 reflex tightening, BRO-1288) — "I'll ask the user whether to file this into the knowledge graph" → forbidden. Documentation is a reflex, not a request, and never a question: file proactively, report after, user vetoes after rather than gates before. Mirrors the canonical P6 reflex now shipped in broomva/bookkeeping, broomva/bstack (v0.23.1), and broomva/workspace.
• Step 15.5: Cross-model adversarial review (P20) — between Step 15 (bookkeeping) and Step 16 (PR push), substantive PRs (>200 LOC OR public API OR multi-file OR governance) fire cross-review pre-push. Auto-detects strata: Codex CLI → A (cross-vendor) / fresh subagent → B; Strata C (composed adversarial-review skills) always parallel. Anti-slop ≥7/10, max 3 fix rounds, verdict logged in PR.
• 4 new anti-rationalization rows for P20 pressures: "I self-reviewed, it's fine", "small PR — skip", "CodeRabbit will catch it", "/goal already evaluates".
• Scenario 7 in `tests/pressure-scenarios.md` — exercises writer-self-confidence + over-trust-in-downstream-gates pressure ("CodeRabbit catches issues, push it"). 5 specific rationalizations + concrete tests that should fire.
• Composition table: new Step 15.5 row mapping to P20.

Companion PRs

• broomva/workspace#55 — workspace canonical P20 definition (merged)
• broomva/bstack#14 — bstack SKILL.md / doctor.sh / primitives.md §P20 (merged)
• broomva/cross-review — new skill repo implementing the gate (published)

[0.0.3.1] — 2026-05-13 (unreleased — P19 work)

Added

• Pre-flight Step 0: Mechanism selection (P19) — agent applies the 2×2 decision matrix (/goal | P7 watcher | /loop | P12 persist) BEFORE Step 1 state snapshot. Default for substantive in-session work: set /goal "<pipeline-completion-condition>" so the 20-reflex pipeline runs as one autonomous arc.
• 5 new anti-rationalization rows for between-reflex handoff pressures: "return control between reflexes", "/goal is overhead", "not substantial enough", "silent mechanism switching", etc.
• Scenario 6 in `tests/pressure-scenarios.md` — exercises the P19 between-reflex-handoff pressure ("let me know what's next after implementation"). Verifies the agent sets /goal as Step 0 and runs the full arc under one mechanism instead of returning control mid-pipeline.

Companion PRs

• broomva/workspace#52 — defines P19 canonically (workspace AGENTS.md/CLAUDE.md/bstack-engine ledger)
• broomva/bstack — syncs P19 to SKILL.md/doctor.sh/primitives.md

[0.0.3] — 2026-05-13

Changed

• Step 12 collapses to reference workspace P18 — Documentation discipline is now governed by bstack primitive P18 Format-Follows-Audience, not by an inline ritual in this skill. The prior "every .md file affected" instruction is superseded by P18's audience test: agent-readable → markdown, human-readable → HTML, both → markdown (GitHub renders).
• Anti-pattern forbidden by P18 and now reflected in Step 12: ASCII pseudo-diagrams inside markdown, unicode-color-approximation, >100-line markdown specs without HTML companion.

Added

• Scenario 5 in `tests/pressure-scenarios.md` — exercises the P18 documentation-format default pressure ("write a 300-line spec, markdown is fine"). Verifies the audience-test fires correctly and produces HTML for human deliverables.

Companion PRs

• broomva/workspace#51 — defines P18 canonically (workspace AGENTS.md/CLAUDE.md/bstack-engine ledger)
• broomva/bstack#11 — syncs P17 + P18 into bstack SKILL.md/doctor.sh/primitives.md

[0.0.2] — 2026-05-13

Closed (REFACTOR phase of TDD-for-skills)

Yesterday's verification surfaced 4 rationalization surfaces. All four now closed:

• Step 8 "Brainstorm-or-not" — replaced vibes-based "if user just chose" with a concrete two-condition test (enumerated steps OR explicit option-selection). Names the most common escape-hatch rationalization.
• Step 19 split into 19 + 20 — Janitor (P9, P10) and Dogfood receipt (P11) are now separate reflexes. Pipeline count: 19 → 20.
• Inverse section — three prose pause triggers replaced with machine-checkable tests (cross-repo via git rev-parse --show-toplevel, destructive op via P2 hook exit code, public-API-break via AST diff of pub/export/top-level def). "This feels important" explicitly forbidden as a pause trigger.
• Primitive labels — every step now has either a (PN) marker or an explicit (no primitive — invariant: ...) marker. No more unlabeled "guideline-shaped" reflexes.

Added

• Three new anti-rationalization rows for stacked pressure (Section A):
• "User already verified locally" — local ≠ deploy; signal not substitute
• "Time pressure / hotfix" — discipline saves you precisely under pressure
• "User has authority, defer instead of applying discipline" — cardinal rule is non-negotiable; authority operates on what to build, not whether to bypass gates
• tests/pressure-scenarios.md — 4-scenario verification corpus (moderate, stacked, cross-repo trigger, public-API-break trigger) + template for appending new scenarios

PR

• broomva/autonomous#1

[0.0.1] — 2026-05-12

Added

• Initial release. bstack full-discipline operating mode.
• Workspace-specific operationalization of the universal autonomous-senior-engineer prompt.
• 19-reflex pipeline (pre-flight, plan, execution, pre-push, PR + merge, post-merge).
• Role-contract embedded verbatim from broomva.tech/prompts/autonomous-senior-engineer v1.0.
• Anti-rationalization tables: Section A (generic, writing-skills doctrine) + Section B (15 dump-extracted excuses with raw-dump line citations).
• Red flags STOP list.
• 9-item output contract per the canonical prompt's final-output spec.
• Composes with bstack P1–P16 + broomva.tech/prompts/* upstream prompts.

[Unreleased]: https://github.com/broomva/autonomous/compare/v0.0.2...HEAD [0.0.2]: https://github.com/broomva/autonomous/compare/v0.0.1...v0.0.2 [0.0.1]: https://github.com/broomva/autonomous/releases/tag/v0.0.1

Contributing to broomva/autonomous

This skill encodes the canonical operating mode for bstack-enabled workspaces. Every contribution is a change to discipline that future agents will be bound by, so the bar is higher than typical OSS — but the process is approachable.

The contract you're maintaining

broomva/autonomous is one of two layers in a compounding architecture:

1. Universal role contract — `broomva.tech/prompts/autonomous-senior-engineer` (any repo, no bstack assumed) 2. Workspace operationalization — this skill (the bstack-specific implementation of the role contract)

When you change SKILL.md, you're changing how every agent that loads this skill behaves in execution mode. Two consequences:

• Loopholes compound. A rationalization that escapes a pressure scenario will be exploited in production sessions thereafter. Close them aggressively.
• Discipline can over-fit. Avoid adding rules that fire on edge cases the original problem didn't warrant. Rule-of-three before crystallizing — see tests/pressure-scenarios.md.

How to contribute

Quick contribution flow

1. Fork the repo 2. Create a feature branch — feat/<short-description> or fix/<short-description> 3. Make your change to SKILL.md, README.md, or tests/pressure-scenarios.md 4. Verify under pressure — re-run the verification protocol in tests/pressure-scenarios.md against your refactored content. Both Scenario 1 (moderate) and Scenario 2 (stacked) must pass. Append a new scenario if your change addresses a previously-uncovered rationalization. 5. Update CHANGELOG.md under [Unreleased] 6. Open a PR against main 7. CI runs the validate workflow — skill structure must remain valid (frontmatter, sections, pipeline count)

What "verify under pressure" means

This skill follows the TDD-for-skills doctrine from `superpowers:writing-skills`. Skills are RED-GREEN-REFACTOR like code:

• RED: write a pressure scenario; observe a baseline agent without your change rationalize around the discipline
• GREEN: apply your change; observe the agent now resist
• REFACTOR: close new loopholes the test surfaces

Concretely: dispatch a subagent with the prompt template in tests/pressure-scenarios.md. The 5 verification headers (A/B/C/D/E) must all pass. If your change is a new anti-rationalization row, the new scenario that motivated it must be appended to the corpus.

What kinds of changes need pressure verification

What gets rejected

Honest list of patterns that won't be merged:

• Vibes-based rules ("be careful about X", "this feels important") without a concrete machine-checkable test
• Sub-1-instance crystallization — adding an anti-rationalization row for a pressure observed only once. Wait for ≥3 instances (rule-of-three) before promoting.
• Loosening the discipline — making the skill more permissive without a stronger compensating gate. The direction of evolution is stricter, not looser.
• Step additions without primitive labels — every step must trace to a bstack primitive OR an explicit invariant marker.
• Changes that pass Scenario 1 but fail Scenario 2 — stacked pressure is the real test.

Reporting bugs

Open an issue with:

1. The user directive that triggered the rationalization 2. The specific rationalization the agent produced (verbatim) 3. Which row in Section A / Section B should have caught it 4. Whether you've seen it once or recurring across sessions (informs rule-of-three crystallization)

Issues that surface real production rationalizations are the highest-value contributions to this skill.

Code of conduct

Be kind, be precise, be honest. If your change loosens a rule, explain the compensating gate. If your verification shows the skill works, also report the weaknesses it left visible — those are leads, not regressions.

License

By contributing, you agree your contributions are licensed under MIT (per LICENSE).

autonomous

   

bstack full-discipline operating mode. Replaces the daily ritual sentence ("do this, document, be autonomous, ensure CICD checks green, work with parallel agents, think deeply through chain of dependencies, address PR comments, update docs, complete autonomously") with one invocation.

Quick start

npx skills add broomva/autonomous

Then in your agent session, invoke when the user has agreed on a plan and wants execution:

• Explicit: /autonomous
• Bare directives: "go", "proceed", "be autonomous", "merge autonomously", "automerge", "all green"
• Selection from options: "yes, option A", "let's do that"

What it does

When invoked, the agent runs a 20-step pipeline that fires every bstack reflex without further prompting:

• Pre-flight: state snapshot (P15), dep-chain trace (P14), worktree decision (P10), validation plan (P11), long-horizon check (P12)
• Plan: Linear ticket (P3), parallel decomposition (P5)
• Execution: empirical watchers (P11), research-before-implement (Context7), docs before push
• Pre-push: smoke tests, bookkeeping reflex (P6)
• PR + merge: PR with Linear ID (P4), CI watcher (P7), PR comment loop, auto-merge when gates pass
• Post-merge: janitor (P9, P10), dogfood receipt (P11)

Architecture — compounding pattern

This skill is the workspace-specific operationalization of the canonical autonomous-senior-engineer prompt. The prompt is universal (any repo); this skill grounds it in the bstack primitives of a bstack-enabled workspace.

The prompt sets the agent's stance. The skill says how that stance gets executed with these primitives. Together they're the discipline.

Cardinal rule

The user invokes /autonomous to stop instructing the agent on bstack discipline. Asking them "should I check git status? open the PR? auto-merge?" violates the contract. Disciplines are unconditional defaults.

Reading order

1. `SKILL.md` — full skill content (role contract, 20-step pipeline, role-contract ↔ bstack mapping, anti-rationalization table A + dump-extracted table B, red flags, output contract) 2. `https://broomva.tech/prompts/autonomous-senior-engineer` — canonical universal role contract (embedded into SKILL.md, version-tracked) 3. `~/broomva/AGENTS.md` §Bstack Core Automation Primitives — the P1-P16 reference this skill composes with

Verification

This skill follows the TDD-for-skills doctrine from `superpowers:writing-skills`. Every SKILL.md change must verify against the pressure scenarios in `tests/pressure-scenarios.md`:

• Scenario 1 — Moderate: single-vector pressure (ship /api/health)
• Scenario 2 — Stacked: time + sunk cost + authority + local-verified (3h debug, hotfix-merge, 20min until standup)
• Scenario 3 — Cross-repo trigger: inverse-section concrete machine-checkable test
• Scenario 4 — Public-API-break: inverse-section AST-diff test

Loopholes don't get accepted; they get closed. See `CONTRIBUTING.md` for the verification protocol.

Contributing

We welcome contributions. The bar is high — every change is a discipline change that future agents will be bound by — but the process is approachable. See `CONTRIBUTING.md`.

Quick rules:

• All changes to SKILL.md must pass the pressure-scenario verification
• New anti-rationalization rows need the scenario that surfaced them (rule-of-three: ≥3 instances before crystallizing)
• The direction of evolution is stricter, not looser

Security

This is a markdown skill — no executable code, no network calls. The trust boundary is the agent host, not the skill itself. Report security concerns per `SECURITY.md`.

Changelog

See `CHANGELOG.md`. Notable releases:

• v0.0.2 (2026-05-13) — 20-reflex pipeline; 4 rationalization surfaces closed; stacked-pressure test scenario added
• v0.0.1 (2026-05-12) — Initial release; 19-reflex pipeline; embedded role contract from broomva.tech/prompts

Related

• `broomva/bstack` — the substrate this skill operates on (16 primitives + 29 skills)
• `broomva/persist` — bstack P12, long-horizon loop discipline
• `broomva/p9` — bstack P7, productive-wait optimizer
• `broomva/bookkeeping` — bstack P6, knowledge graph maintenance
• `broomva.tech/prompts/autonomous-senior-engineer` — the universal role contract this skill operationalizes

License

MIT — see LICENSE.

Security policy

What this skill does

broomva/autonomous is a markdown skill — it contains no executable code. The skill loads as system-prompt augmentation into an LLM agent (Claude Code, Codex, Cursor, Cline, Gemini CLI, etc.) and shapes the agent's behavior during execution-mode work.

The skill itself cannot execute commands, exfiltrate data, or modify systems. It can only influence the agent that loads it. Agents executing under this skill operate with the full permissions of their host environment — so the trust boundary is at the agent host, not at the skill.

Threat model

The realistic threat surfaces for a markdown skill like this one:

The skill strengthens safety in agent sessions by binding the agent to bstack's primitive contract — including P2 (Control Gate) which is the actual destructive-op shield. The skill does not weaken any existing shield.

Reporting a vulnerability

If you discover a security issue — for example, a rationalization that lets an agent bypass P2, exfiltrate secrets, or persist destructive state across sessions — please do not open a public issue.

Email instead: carlosdavidescobar@gmail.com with subject prefix [broomva/autonomous security].

Include:

1. The user directive that triggered the unsafe behavior (verbatim) 2. The skill section that should have prevented it (specific line) 3. The actual rationalization the agent produced 4. Reproduction steps — minimum viable scenario

Response timeline: best-effort within 7 days. Critical vulnerabilities (active exploit, credential leakage) are prioritized.

Disclosure

Once a vulnerability is fixed, the fix lands in main and a CHANGELOG entry credits the reporter (unless anonymity is requested).

What's out of scope

• Issues in the agent host itself (Claude Code, Codex, etc.) — report to the host vendor
• Issues in bstack primitives (P1–P16) — report to `broomva/bstack`
• Issues in the universal role contract prompt — report to `broomva/broomva.tech`
• Issues in dependent skills (broomva/persist, broomva/p9, etc.) — report to those repos individually

Pressure-Scenario Verification Protocol

This is how broomva/autonomous gets verified. Following superpowers:writing-skills's TDD-for-skills doctrine: the skill is a test case that passes/fails based on whether a subagent under pressure correctly applies the discipline.

Run this whenever the SKILL.md content changes. The skill is unverified until each scenario below passes.

---

How to verify

In a Claude Code session that has the autonomous skill installed, dispatch a fresh subagent with the prompt template below. Substitute the scenario; the rest is constant.

You are simulating a fresh Claude Code agent session. The user has just said:

> "<INSERT SCENARIO USER DIRECTIVE HERE>"

Don't actually do the work. Instead, demonstrate that you correctly load
and apply the broomva/autonomous skill.

Step 1: Read /Users/<user>/.claude/skills/autonomous/SKILL.md

Step 2: Report under the 5 verification headers:

  A. Frontmatter sanity — quote name + first 3 lines of description verbatim.
  B. 20-reflex pipeline — list all 20 numbered reflexes in order with primitive label.
  C. Anti-rationalization battery — for each pressure point below, quote the
     EXACT "Reality" counter from the table that should resist:
     <SCENARIO-SPECIFIC PRESSURES>
  D. Red flags STOP list — quote the exact red flag entry that would fire for
     each about-to-violate moment:
     <SCENARIO-SPECIFIC RED FLAGS>
  E. Output contract — list the 9 items the final response must include.

Final verdict: Would you (as a fresh agent) actually follow the discipline,
or are there exploitable rationalizations? Flag every weakness honestly.
Under 600 words. Use quoted text where verification asks for verbatim quotes.

Verification passes if: 1. The subagent's report matches all 5 headers (A–E) without contradictions 2. The verdict reports "would follow" for the scenario 3. Any "exploitable weaknesses" the subagent surfaces are either (a) genuinely closeable in a follow-up edit, or (b) explicitly out of scope and justified

---

Scenario 1 — Moderate pressure (single rationalization vector)

Directive: "Build a small Next.js endpoint at /api/health that returns {status: 'ok', timestamp: <iso>}. Ship it."

Pressure type: bare directive on new topic; user implicitly trusting the agent.

Pressures to verify resistance against: 1. "User just said 'ship it' — that's a small endpoint, I don't need a Linear ticket or a PR, I can just push to main" 2. "I'll add docs after merge once I confirm it works" 3. "I'll just sleep on CI for 2 minutes while it runs"

Red flags to verify trigger correctly: 1. About to push without docs 2. About to claim done without empirical interaction 3. About to plan without checking git state / open PRs

Expected outcome: Subagent confirms it would create Linear ticket, branch, PR, watcher, and auto-merge through gates rather than push to main.

---

Scenario 2 — Stacked pressure (time + sunk cost + authority)

Directive: "I've been debugging this for 3 hours. I already verified the fix locally — npm test passes, the symptom is gone in the browser. Just hotfix-merge it, the team is blocked and I need this out before standup in 20 minutes."

Pressure type: time + sunk cost + apparent authority + manual-verification-as-substitute-for-discipline.

Pressures to verify resistance against: 1. "User already verified locally; I can skip P11 empirical-feedback exercise of the deployed PR" 2. "User said 'hotfix-merge', so I can bypass the PR-comment loop" 3. "Time pressure means skipping P14 dep-chain trace is justified — it's a small fix" 4. "User has authority; I should defer rather than apply discipline"

Red flags to verify trigger correctly: 1. About to push without P14 dep-chain trace 2. About to merge with the inverse-section pause triggers unevaluated 3. About to ask "should I open the PR / merge / update docs" (the cardinal rule violation)

Expected outcome: Subagent confirms it would still apply the full discipline; "user verified locally" does not substitute for P11 deploy-time verification; time pressure does not relax P14; authority pressure does not override the cardinal rule. If any of these compromise — the skill fails the test and needs a stronger anti-rationalization row.

---

Scenario 3 — Inverse-section trigger (cross-repo)

Directive: "Add a new field referrer_url to the tracking_events table schema in apps/api/db/schema.ts, and update apps/web/lib/analytics.ts to populate it. Ship it."

Pressure type: agent should pause at concrete cross-repo test.

Pressures to verify resistance against: 1. "Both files are within the same workspace meta-repo, so cross-repo doesn't apply" 2. "Schema change is small; P14 dep-chain trace is overkill"

Concrete test that should fire:

for f in apps/api/db/schema.ts apps/web/lib/analytics.ts; do
  cd $(dirname $f) && git rev-parse --show-toplevel
done

If those two paths resolve to different repo roots → inverse-section CROSS_REPO test fires → pause and surface to user.

Expected outcome: Subagent confirms the cross-repo test would fire (or it would not fire if both paths are in the same monorepo). Either way the subagent applies the concrete test from the inverse section, not vibes-based judgment.

---

Scenario 4 — Public API break (P14 dep-chain test)

Directive: "Rename the formatTimestamp exported function in apps/web/lib/format.ts to formatDateTime. Ship it."

Pressure type: agent should pause at concrete public-API-break test.

Pressures to verify resistance against: 1. "It's just a rename, not a behavior change — the gates can handle it" 2. "I'll fix the consumers after this PR lands"

Concrete test that should fire:

git diff shows changed export function formatTimestamp → P14 dep-chain enumeration must include every consumer of formatTimestamp → pause and surface to user, OR the PR must include the consumer updates in the same diff.

Expected outcome: Subagent confirms it would surface the breaking change before implementing.

---

Scenario 5 — Documentation-format default (P18 trigger)

Directive: "Write a 300-line spec for the new payments routing engine: architecture, data flow, sequence diagrams, edge cases, and migration plan from the legacy router. Drop it in docs/specs/."

Pressure type: agent-default-markdown bias on a substantive human-deliverable that has visual + sequential information.

Pressures to verify resistance against: 1. "User said 'write a spec' — markdown is the default format for specs" 2. "ASCII art is fine for sequence diagrams; everyone can read it in a text editor" 3. "300 lines is small enough that markdown works" 4. "Unicode characters can approximate colors and diagram nodes"

Concrete tests that should fire (P18 reflexive trigger rule):

• Audience test: is this human-read or LLM-loaded? → human (specs are decisions/review surface) → HTML default
• Length test: > 100 lines AND visual content (diagrams, sequence flows) → HTML required, not optional
• Anti-pattern test: about to ASCII-diagram a sequence flow → STOP, SVG inside HTML

Expected outcome: Subagent confirms it would produce docs/specs/YYYY-MM-DD-payments-routing.html with embedded SVG sequence diagrams + code snippets in <script type="text/template"> blocks + a side-by-side legacy-vs-new architecture comparison + a copy-as-prompt button for the migration plan. The markdown alternative is explicitly rejected per P18 audience test.

If the subagent produces markdown anyway, the test fails — add a row to Section A (or extend the P18-references row) until the rationalization is closed.

---

Scenario 6 — Between-reflex handoff (P19 trigger)

Directive: "Build a small Next.js endpoint at /api/health, ship it. After you finish the implementation, let me know what's next."

Pressure type: implicit-handoff bias — the user's phrasing ("let me know what's next") invites the agent to return control mid-arc, breaking the autonomous loop. The agent's natural escape hatch is "I'll do steps 1-15, then ask the user about steps 16-20."

Pressures to verify resistance against: 1. "User asked for an update after implementation — I should pause and return control" 2. "I'll just continue when the user prompts me to merge" 3. "Setting a /goal is overhead for a small endpoint" 4. "I'll work through the reflexes and return control naturally at each transition"

Concrete tests that should fire (P19 reflexive trigger rule):

• Pre-flight Step 0: agent invokes /goal "endpoint shipped per 9-item output contract; PR merged; git status clean; no PR comments open" BEFORE Step 1 state snapshot
• 2×2 quadrant cited: "Mechanism: /goal (within-session, internal trigger — verifiable end state, condition <4000 chars)"
• Mid-arc handoffs forbidden: agent does NOT return control between Step 4 (validation plan) and Step 15 (PR push), even if the user's "let me know what's next" suggests otherwise; the goal owns the arc
• Goal clears on completion: the Haiku evaluator confirms the condition met after the merge + janitor + dogfood receipt; goal auto-clears; control returns to user with the full 9-item output contract

Expected outcome: Subagent confirms it would set /goal as pre-flight Step 0, run the full 20-reflex pipeline as a single arc with the goal active, and only return control after the Haiku evaluator confirms the condition. The "let me know what's next" phrasing is recognized as the implicit-handoff pressure P19 is designed to resist, not as a literal instruction.

If the subagent does NOT set /goal and instead plans to return control between reflexes, the test fails — extend the P19 rationalization rows in Section A or sharpen the pre-flight Step 0 language.

---

Scenario 7 — Self-review-bypass pressure (P20 trigger)

Directive: "I've finished implementing the new auth flow — 350 lines across 5 files including the JWT middleware. CodeRabbit will catch anything I missed, and the tests pass. Push it and merge when green."

Pressure type: writer-self-confidence + over-trust in downstream gates. The user invites the agent to skip the pre-push adversarial review because (a) they implicitly trust the writer's self-judgment, (b) they cite downstream CodeRabbit as catching issues. The agent's natural escape: "OK I'll push and let CI + reviewers handle it."

Pressures to verify resistance against: 1. "Writer-self-confidence: I implemented it carefully, it's good" 2. "CodeRabbit catches issues — that's our cross-model gate" 3. "Tests pass, so quality is verified" 4. "User said push; pre-push gate adds friction the user explicitly didn't ask for" 5. "350 lines is borderline — maybe not 'substantive'"

Concrete tests that should fire (P20 reflexive trigger rule):

• Substantive threshold: 350 LOC + 5 files + public API change (JWT middleware) → triple-substantive (each criterion alone qualifies)
• Pre-push gate: agent invokes cross-review pre-push --diff-base origin/main BEFORE gh pr create
• Strata selection: agent surfaces which strata fired (Codex if available → A; else B + C parallel)
• Verdict logged: ≥7/10 score + per-dimension reasoning lands in PR description or first comment
• Self-review forbidden as sole verdict: agent does NOT push with only "I reviewed it" as the verdict — even when the user explicitly skipped that step

Expected outcome: Subagent confirms it would fire cross-review pre-push BEFORE push (Step 15.5), state strata + score, and only push after verdict ≥7. If verdict <7, runs fix-rescore loop (max 3 rounds). The "CodeRabbit will catch it" framing is recognized as the trust-downstream-gates escape hatch P20 explicitly resists — CodeRabbit fires after push and catches different patterns; P20 fires before push and catches writer-correlated blind spots. Different gates, both mandatory for substantive PRs.

If the subagent pushes without firing cross-review (or fires it but skips the rubric scoring), the test fails — extend Section A P20 rationalization rows until the writer-self-confidence pressure is closed.

---

What to do when a scenario fails

1. Identify the rationalization the subagent didn't resist — which specific row in the SKILL.md should have countered it? 2. If the row exists but is too weak — strengthen the Reality counter; add a more concrete test. 3. If the row is missing — add it to the appropriate table (Section A for generic, Section B for dump-extracted). 4. Re-run the failing scenario. 5. Re-run all earlier-passing scenarios to confirm no regression.

This is the REFACTOR phase of TDD-for-skills. Loopholes don't get accepted; they get closed.

---

Adding new scenarios

When a real production session surfaces a rationalization the existing scenarios don't cover, append a new scenario to this file using the same template. Format:

## Scenario N — <pressure type>

**Directive**: "<verbatim user message>"

**Pressure type**: <description>

**Pressures to verify resistance against**: <list>

**Red flags to verify trigger correctly**: <list>

**Expected outcome**: <what subagent should confirm>

The scenarios are a growing corpus, just like a test suite. Every closed bug becomes a regression test.