# Staff Operating Modes

> Staff Operating Modes (drive the agent at a distinguished bar)

- Skill: `sanjeevrg89/staff-operating-modes` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add sanjeevrg89/staff-operating-modes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sanjeevrg89/staff-operating-modes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: sanjeevrg89 (https://skillmd.com/u/sanjeevrg89)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sanjeevrg89/staff-operating-modes

---


# Staff Operating Modes (drive the agent at a distinguished bar)

A capable coding agent is wasted two ways. Drive it like a **junior** — a stream of imperatives — and you
are the bottleneck. Drive it like a **senior** — "build the feature, make the test pass" — and you get
something that works and is quietly wrong at the level that matters: blast radius, simplicity, leverage,
what should have been built instead. Drive it at the **staff / distinguished** bar: give it a goal, the
*standard a principal engineer would hold in review*, and a way to verify — then let it run to that bar
and report. This is the *how-to-instruct* layer; it routes the work into `[[engineering-lifecycle]]` and
the stage skills, which own the gates, and applies the judgment in `[[staff-plus-engineering]]`.

## How to use this skill

1. Read `staff-operating-modes-guide.md` in this directory — the modes, the distinguished standard-of-
   done, the parallel/e2e pattern, and how each mode pairs with a verification + review gate. Apply it.
2. For copy-paste templates (the goal wrapper, the parallel dispatch, the six modes, and a senior-vs-
   distinguished before/after), read `examples.md`. Adapt the bracketed parts; don't paste blindly.
3. **Pick the mode and write the goal + the distinguished bar first.** Then let the agent run, validating
   the real end-to-end path after each meaningful step. Match the team's conventions; hold the bar.

## The essentials (full detail in `staff-operating-modes-guide.md`)

- **Three altitudes, not two.** Junior needs the steps. Senior does the task and stops at "it works."
  **Staff/distinguished** owns architecture, **blast radius**, simplicity, leverage, second-order
  effects, and *whether the thing should exist*. Instruct the agent at the third altitude.
- **Set goals, not imperatives.** "Do X" makes you the planner. "Achieve G to the bar below, verify it,
  keep going until it meets the bar" lets a capable model plan, build, and self-correct.
- **Define "done" at the distinguished bar, so the agent can self-check it.** Not "it compiles / a test
  passed." Done = correct, **simple**, minimal blast radius, observable, **reversible**, and the *right*
  thing to build — what a principal would approve in review. State it in the goal.
- **The run-to-done wrapper:** goal + "keep going until the architecture and result meet the bar, not
  just until it runs" + **real end-to-end validation after each meaningful step** + review + commit +
  **write progress somewhere sensible**. Don't hardcode the progress path; let the agent choose it.
- **Validate the REAL thing.** Exercise the full path — CLI, server, browser, clicks, keystrokes — not
  just unit tests → `[[verification-and-debugging]]`.
- **For large jobs, go parallel + e2e:** decompose into **independent** pieces; spawn concurrent sub-
  agents each with **its own goal, deliverable, verification, and bar**; synthesize and resolve conflicts
  → `[[task-planning-decomposition]]`, multi-agent patterns in `[[llm-app-agent-frameworks]]`.
- **Every mode pairs with a gate.** The mode is the *framing*; a verification pass + an independent,
  staff-level review (`[[code-review-discipline]]`) are what make running-to-done safe, not reckless.
- **Don't stop at partial progress** — unless blocked by **missing credentials/access, destructive
  ambiguity, or conflicting requirements.** Those three are the legitimate stops; "it compiled" is not.
- **The modes** (each a *standard*, not a magic word): run-to-done wrapper · parallel e2e · production-
  grade build (reqs→edge cases→architecture→MVP) · inherit + refactor · root-cause debugging · perf.
- **Composes with the lifecycle, doesn't replace it.** The mode sets the framing and bar;
  `[[engineering-lifecycle]]` runs Define→Plan→Build→Verify→Review→Ship with the gates between.

## Related skills

- `[[staff-plus-engineering]]` — the staff/principal/distinguished *judgment* (blast radius, leverage,
  simplicity, second-order effects) this skill instructs the agent to apply.
- `[[engineering-lifecycle]]` — the stages and gates a run-to-done goal actually moves through; this
  skill picks the framing, that one enforces the process.
- `[[spec-driven-development]]` · `[[task-planning-decomposition]]` — turn a goal into a spec with a
  distinguished standard-of-done, then into independent, parallelizable pieces.
- `[[verification-and-debugging]]` · `[[test-driven-development]]` — the real-end-to-end validation and
  test-first build the run-to-done loop depends on.
- `[[code-review-discipline]]` · `[[shipping-and-release]]` — the staff-level review and the safe
  commit/ship every mode must end on.
- `[[gpu-performance-engineering]]` · `[[inference-optimization]]` — where the performance mode routes
  for AI-infra work.