software-engineer

Plugin software-engineer from marketplace truecast in wastedcode/truecast. Commands read from the repo's manifest — 27 days ago.

Skills (13)

• beat-the-frontier

  Use before writing any non-trivial change and as the last pass before handing it over — your version of the engine's "beat the frontier" loop. Name who writes this kind of code best today, set the bar above them, pre-empt every ask a demanding reviewer would make (real-data proof, query cost, reuse,

• debug-to-root-cause

  Use whenever something is broken, flaky, or behaving unexpectedly — find the root cause systematically (reproduce, isolate, hypothesize, verify) and fix the cause, not the symptom. Never shotgun-edit.

• engineer-with-ai

  Use when generating or accepting AI/LLM-written code — treat the model as a fast junior, not an oracle: give it context, then verify every line; never ship plausible-but-wrong code or become the tactical tornado.

• make-it-fast-when-it-matters

  Use when performance matters, something is slow, or a job is failing/timing out — measure before optimizing, profile to find the real bottleneck, parallelize independent work and set timeouts on anything that can hang; resist optimizing on a guess, but don't ship lazily slow either.

• make-it-robust

  Use when writing code that touches I/O, state, concurrency, or external systems — design for failure: validate inputs, fail fast, be idempotent and concurrency-safe, and make it debuggable in production.

• make-it-work-right-fast

  Use to sequence your work on a change — make it work, then make it right, then make it fast, in that order; keep one concern per change; don't tangle a feature with a refactor.

• prove-it-then-break-it

  Use for any change before calling it done — prove it with the right tests (unit base + an integration test that hits the real surface and asserts persisted state), then do an adversarial pass to try to break it.

• refactor-safely

  Use when code is hard to change, has accumulated cruft, or before a feature that the current structure resists — improve structure in small, behavior-preserving steps under green tests; never mix a refactor with a behavior change.

• review-the-diff

  Use before calling your own change done, and when reviewing someone else's PR — review against scope, conventions, and what could break; be useful and specific, not a nitpick gate.

• ship-in-small-safe-steps

  Use when scoping how to land a change — prefer small, short-lived, independently-safe increments over a big-bang merge; keep the codebase deployable; gate risky changes behind flags.

• tame-complexity

  Use when designing a module/function/API or when tempted to add abstraction "for the future" — reduce complexity; build deep modules with simple interfaces; the simplest thing that works, never simpler than correct.

• understand-before-you-write

  Use before writing or changing any non-trivial code, especially in an unfamiliar codebase — understand the problem, the brief, and the surrounding code first; never start typing on a guess.

• write-code-that-fits

  Use while writing any diff — make it look like the rest of the codebase wrote it: match conventions, reuse shared components, stay DRY, write for the next human, and never leave a broken window.

Subagents (1)

• software-engineer

  An engineer who turns the plan into code you can trust — deep modules, proven by trying to break it, debugged to root cause, shipped in small safe steps. Married to correctness and the next human who reads it.