av · August 10, 2026 17:58
diff --git a/prompts.yml b/prompts.yml
 matches:
  # --- Prefixes (before the task) ---

  # Deep planning before execution
  - trigger: ":pxp"
    replace: |-
      Before doing anything, describe what a perfect outcome looks like. What is the end state? What must be true when you are done? Then lay out a concrete plan to get there. Only after the plan is clear, begin executing step by step. If you cannot articulate the goal, you are not ready to start.

  # Thorough, no corners cut
  - trigger: ":pth"
    replace: |-
      Be thorough. Do not take shortcuts, do not leave loose ends, do not skip edge cases. If the scope turns out larger than expected, expand to cover it — do not punt. Partial work is worse than no work. Common failure modes to avoid: do not silently drop parts that seem hard, do not substitute a simpler version of what was asked, do not claim something is done without verifying it, do not stop at the first thing that seems to work. When you think you are done, re-read the original request and confirm every part is addressed — not just the parts that were easy.

  # Minimal, surgical
  - trigger: ":pmn"
    replace: |-
      Do the minimum necessary to accomplish what was asked. Do not reorganize, do not improve adjacent things, do not add anything beyond the stated scope. If you feel the urge to fix or enhance something nearby, resist — that is a separate task.

  # Challenge the premise
  - trigger: ":pch"
    replace: |-
      Before executing, challenge the premise. Is this the right approach? Is there a simpler way? Am I solving the right problem? State your concerns explicitly, then proceed with either the original plan or your better alternative. Do not silently comply with an approach you believe is wrong.

  # Research before acting
  - trigger: ":prs"
    replace: |-
      Do not act yet. First, research the problem thoroughly: read the relevant sources, understand the current state, and identify what would be affected. Present your findings and a proposed approach. I will confirm before you proceed.

  # Think like a senior expert
  - trigger: ":psr"
    replace: |-
      Approach this as a senior expert would: consider failure modes, second-order consequences, and long-term maintenance burden. Do not just make it work — make it right. If there is a tradeoff, state it explicitly and make a recommendation instead of asking me to choose.

  # Step-by-step reasoning, then re-decide
  - trigger: ":psp"
    replace: |-
      Do not commit to an approach yet. First, walk yourself step by step through every aspect of this problem: what is actually being asked, the current state, the constraints, the unknowns, the options and their tradeoffs, and what could go wrong. Write that reasoning out — do not do it silently. Then, with the full picture in front of you, make a fresh decision about what needs to be done and how, and justify it: why this over the alternatives you surfaced. If the reasoning changes your initial instinct, say so explicitly and follow the new conclusion.

  # --- Postfixes (after the task) ---

  # Verify your own work
  - trigger: ":pvf"
    replace: |-
      After completing the task, verify your work by spawning a separate subagent to check it. The subagent reads the result cold, with no knowledge of your intent — only the original request and what you produced. It should confirm the output fully satisfies what was asked without errors or omissions. Do not declare done until the subagent confirms. If it finds issues, fix them and re-verify.

  # Adversarial review
  - trigger: ":prv"
    replace: |-
      When done, spawn a subagent to review your output. The subagent acts as a hostile reviewer who has never seen this task — it reads your result cold and tries to find flaws. It looks for: missed requirements, incorrect claims, unnecessary complexity, and deviations from what was asked. Feed the subagent only the output and the original request, not your reasoning. If it finds problems, fix them and re-review. Do not present results until a review subagent passes clean.

  # Rewrite the last message as a 20-second read
  - trigger: ":prw"
    replace: "Rewrite your previous message so that it tells me everything I need to know including possible decision context, in a way that I can read it in 20s."

  # Concise output
  - trigger: ":pbr"
    replace: "Reply with a few sentences describing what I need to know, without any filler."

  # Efficient subagents
  - trigger: ":psub"
    replace: |-
      For subagents, please use Composer 2.5 Fast model for efficiency. Your job as an orchestrator is to ensure your changes are still delivered as expected according to the task at hand.

  # Orchestrator-only delegation
  - trigger: ":por"
    replace: |-
      Do this as an orchestrator only: dispatch subagents and integrate results — write no code, edit no files, explore nothing yourself. If you want to "just check something", dispatch instead. First write a state file to /tmp/orch-<slug>.md with the goal, hard constraints, the split into units, and a results log; pass every subagent its PATH, never its contents. Split into non-overlapping units and dispatch independent ones IN PARALLEL in one batch — sequential dispatch of independent work is a defect, and one subagent doing everything defeats the point. Give each subagent: the end state of ITS unit, the state file path, the constraints it must not violate, a definition of done someone else could run, and instructions to commit and to return what it did (file paths), what it committed (hash), what it could not do, and what remains. A plan or analysis instead of a commit is a failed unit — redispatch with a sharper end state. Subagent reports are claims, not evidence: verify with git log and the done-check before recording a unit done. Between batches, append results, reconcile overlapping edits, and redispatch anything incomplete — never rescue a failed unit by doing it yourself, and never shrink the goal to fit what came back.

  # --- Skill expansions (concise ports of lifeos skills) ---

  # discipline — failure-prevention operating protocol
  - trigger: ":pds"
    replace: |-
      Operating protocol, follow strictly. (1) Never fabricate: if you haven't read, run, or fetched it this session, it does not exist — no invented flags, URLs, packages, config keys, or UI paths; when caught, stop and find the real value, don't "correct" with another guess. (2) Track stated constraints: restate them before acting, treat specified technologies as hard requirements, never repeat a rejected suggestion, never re-ask what was already answered. (3) Verify before declaring done: run the code, render the visual, ls the files — a claim is not evidence, and subagent reports are claims too. (4) Investigate before blaming: read logs and actual state before hypothesizing; never suggest the user's setup is wrong without evidence. (5) Never retry blindly: on failure, read the full error, diagnose the root cause, change approach — never rerun the same attempt twice. (6) Stay exactly in scope: no adjacent fixes, no unrequested features, no new conventions; read every file before editing it, minimal diffs matching existing style. (7) Ship complete: no TODOs, stubs, or 80% deliveries; commit every change, leave zero temp files in the repo. (8) Write like a human: short sentences, active voice, no filler, no LLM slop. Meta-rule: when in doubt, look — don't guess.

  # timeboxed-iterating — run for the full duration, clock decides when to stop
  - trigger: ":ptb"
    replace: |-
      Run this iteratively for the FULL stated duration. You are only an orchestrator: record the start time with `date +%s`, compute the deadline, create a progress file in /tmp, then loop — check the clock BEFORE every dispatch, dispatch a subagent to do ONE meaningful unit of work that ends in a commit (give it the goal and the progress file PATH to read itself, never the deadline), append the result to the progress file, repeat. Do no work yourself — no edits, no exploration, no quick fixes; that all belongs in subagents. THE CLOCK DECIDES WHEN TO STOP, NOT YOU: "good progress", "diminishing returns", "essentially complete", "the user would be happy" are all traps — on any such thought, check the clock and dispatch again. If a subagent returns with nothing to do, reframe the angle, go deeper, or broaden scope — do not stop. Every iteration must produce a committed artifact, not a plan or analysis. Only after the deadline passes, append a final summary (iterations, accomplishments, remaining work) to the progress file and report its path.

  # bughunt — autonomous find/triage/fix/audit pipeline
  - trigger: ":pbh"
    replace: |-
      Run a fully autonomous bug hunt on the stated scope — no questions, no pauses between phases; log everything to a report the user reads at the end. (1) ORIENT: read the target code yourself, split it into sections along its natural structure, and check the output dir for prior-run reports — dedupe against previously fixed or disputed findings. (2) DISCOVER: parallel subagents, one per section, reporting only bugs a real user could hit — each with ID, severity, file:line, repro, and code evidence; no style nits, no hypotheticals. (3) TRIAGE: one independent skeptical subagent per finding, reading the code fresh with no discovery context, returning CONFIRMED / DISPUTED / DOWNGRADE; fix only findings that are Medium+ after triage; zero fixable bugs is a valid, successful result — never lower the bar to inflate the fix count, and keep disputed findings in a rejection table with reasons. (4) FIX: one subagent per confirmed bug returns a minimal exact edit WITHOUT applying it; you resolve overlaps, apply sequentially, and syntax-check every modified file. (5) AUDIT: check each fix against lint rules, target-platform portability (GNU vs BSD flags, bash-isms under /bin/sh, minimal environments), and surrounding-code conventions; correct violations directly and re-verify.

  # dark-factory — lights-out production in verified slices
  - trigger: ":pdf"
    replace: |-
      Turn this idea into working software by lights-out production: build depth-first in verified slices so the software runs correctly after EVERY change — never breadth-first, never "integrate at the end". Confirm name and constraints with the user once up front, then run fully autonomously. You are only an orchestrator and state machine: decompose, dispatch subagents, verify, gate — write no product code yourself. Maintain a manifest file as ground truth: build/run/shutdown commands, every slice with status (PENDING/BUILDING/VERIFIED), its spec as atomic testable statements, and its verification commands defined BEFORE building starts. Slice 0 is always a walking skeleton (builds, launches, handles one basic input, produces one basic output, shuts down cleanly) and is a HARD GATE — nothing proceeds until an independent verifier passes it. Then loop: one capability per slice, one slice BUILDING at a time, a fresh builder subagent per slice; the verifier is ALWAYS a separate agent that builds from scratch, launches, exercises the new capability, and re-runs every prior slice's verification commands as regression check, recording CHECK/COMMAND/EXPECTED/ACTUAL/RESULT for each — reading the source is not verification, running the software is. A regression blocks all forward progress until fixed. Spot-check every delivery yourself (git status, git log, one new + one old verification command) — subagent reports can hallucinate success. Max 3 build-verify cycles per slice, then escalate to the user with all evidence — never silently skip a slice or shrink scope. After all slices are VERIFIED: harden (runtime bugbash + static review, fix Critical/High with full regression reruns), run the entire verification suite clean one final time, then ship. Working beats complete: five verified features beat fifteen broken ones.

  # --- Combo (prefix + postfix in one) ---

  # Full rigor: plan, execute, verify
  - trigger: ":pfl"
    replace: "Follow this protocol strictly. (1) PLAN — Describe the perfect end state and your step-by-step plan to get there; do not start until the plan is clear. (2) EXECUTE — Carry out the plan completely, no loose ends, no shortcuts. (3) VERIFY — Check every part of the output against the original request and fix anything that does not match. (4) REPORT — State what you did and what you verified in 1-3 sentences, nothing more. Do not skip or compress any step."
	matches:
	# --- Prefixes (before the task) ---

	# Deep planning before execution
	- trigger: ":pxp"
	replace: \|-
	Before doing anything, describe what a perfect outcome looks like. What is the end state? What must be true when you are done? Then lay out a concrete plan to get there. Only after the plan is clear, begin executing step by step. If you cannot articulate the goal, you are not ready to start.

	# Thorough, no corners cut
	- trigger: ":pth"
	replace: \|-
	Be thorough. Do not take shortcuts, do not leave loose ends, do not skip edge cases. If the scope turns out larger than expected, expand to cover it — do not punt. Partial work is worse than no work. Common failure modes to avoid: do not silently drop parts that seem hard, do not substitute a simpler version of what was asked, do not claim something is done without verifying it, do not stop at the first thing that seems to work. When you think you are done, re-read the original request and confirm every part is addressed — not just the parts that were easy.

	# Minimal, surgical
	- trigger: ":pmn"
	replace: \|-
	Do the minimum necessary to accomplish what was asked. Do not reorganize, do not improve adjacent things, do not add anything beyond the stated scope. If you feel the urge to fix or enhance something nearby, resist — that is a separate task.

	# Challenge the premise
	- trigger: ":pch"
	replace: \|-
	Before executing, challenge the premise. Is this the right approach? Is there a simpler way? Am I solving the right problem? State your concerns explicitly, then proceed with either the original plan or your better alternative. Do not silently comply with an approach you believe is wrong.

	# Research before acting
	- trigger: ":prs"
	replace: \|-
	Do not act yet. First, research the problem thoroughly: read the relevant sources, understand the current state, and identify what would be affected. Present your findings and a proposed approach. I will confirm before you proceed.

	# Think like a senior expert
	- trigger: ":psr"
	replace: \|-
	Approach this as a senior expert would: consider failure modes, second-order consequences, and long-term maintenance burden. Do not just make it work — make it right. If there is a tradeoff, state it explicitly and make a recommendation instead of asking me to choose.

	# Step-by-step reasoning, then re-decide
	- trigger: ":psp"
	replace: \|-
	Do not commit to an approach yet. First, walk yourself step by step through every aspect of this problem: what is actually being asked, the current state, the constraints, the unknowns, the options and their tradeoffs, and what could go wrong. Write that reasoning out — do not do it silently. Then, with the full picture in front of you, make a fresh decision about what needs to be done and how, and justify it: why this over the alternatives you surfaced. If the reasoning changes your initial instinct, say so explicitly and follow the new conclusion.

	# --- Postfixes (after the task) ---

	# Verify your own work
	- trigger: ":pvf"
	replace: \|-
	After completing the task, verify your work by spawning a separate subagent to check it. The subagent reads the result cold, with no knowledge of your intent — only the original request and what you produced. It should confirm the output fully satisfies what was asked without errors or omissions. Do not declare done until the subagent confirms. If it finds issues, fix them and re-verify.

	# Adversarial review
	- trigger: ":prv"
	replace: \|-
	When done, spawn a subagent to review your output. The subagent acts as a hostile reviewer who has never seen this task — it reads your result cold and tries to find flaws. It looks for: missed requirements, incorrect claims, unnecessary complexity, and deviations from what was asked. Feed the subagent only the output and the original request, not your reasoning. If it finds problems, fix them and re-review. Do not present results until a review subagent passes clean.

	# Rewrite the last message as a 20-second read
	- trigger: ":prw"
	replace: "Rewrite your previous message so that it tells me everything I need to know including possible decision context, in a way that I can read it in 20s."

	# Concise output
	- trigger: ":pbr"
	replace: "Reply with a few sentences describing what I need to know, without any filler."

	# Efficient subagents
	- trigger: ":psub"
	replace: \|-
	For subagents, please use Composer 2.5 Fast model for efficiency. Your job as an orchestrator is to ensure your changes are still delivered as expected according to the task at hand.

	# Orchestrator-only delegation
	- trigger: ":por"
	replace: \|-
	Do this as an orchestrator only: dispatch subagents and integrate results — write no code, edit no files, explore nothing yourself. If you want to "just check something", dispatch instead. First write a state file to /tmp/orch-<slug>.md with the goal, hard constraints, the split into units, and a results log; pass every subagent its PATH, never its contents. Split into non-overlapping units and dispatch independent ones IN PARALLEL in one batch — sequential dispatch of independent work is a defect, and one subagent doing everything defeats the point. Give each subagent: the end state of ITS unit, the state file path, the constraints it must not violate, a definition of done someone else could run, and instructions to commit and to return what it did (file paths), what it committed (hash), what it could not do, and what remains. A plan or analysis instead of a commit is a failed unit — redispatch with a sharper end state. Subagent reports are claims, not evidence: verify with git log and the done-check before recording a unit done. Between batches, append results, reconcile overlapping edits, and redispatch anything incomplete — never rescue a failed unit by doing it yourself, and never shrink the goal to fit what came back.

	# --- Skill expansions (concise ports of lifeos skills) ---

	# discipline — failure-prevention operating protocol
	- trigger: ":pds"
	replace: \|-
	Operating protocol, follow strictly. (1) Never fabricate: if you haven't read, run, or fetched it this session, it does not exist — no invented flags, URLs, packages, config keys, or UI paths; when caught, stop and find the real value, don't "correct" with another guess. (2) Track stated constraints: restate them before acting, treat specified technologies as hard requirements, never repeat a rejected suggestion, never re-ask what was already answered. (3) Verify before declaring done: run the code, render the visual, ls the files — a claim is not evidence, and subagent reports are claims too. (4) Investigate before blaming: read logs and actual state before hypothesizing; never suggest the user's setup is wrong without evidence. (5) Never retry blindly: on failure, read the full error, diagnose the root cause, change approach — never rerun the same attempt twice. (6) Stay exactly in scope: no adjacent fixes, no unrequested features, no new conventions; read every file before editing it, minimal diffs matching existing style. (7) Ship complete: no TODOs, stubs, or 80% deliveries; commit every change, leave zero temp files in the repo. (8) Write like a human: short sentences, active voice, no filler, no LLM slop. Meta-rule: when in doubt, look — don't guess.

	# timeboxed-iterating — run for the full duration, clock decides when to stop
	- trigger: ":ptb"
	replace: \|-
	Run this iteratively for the FULL stated duration. You are only an orchestrator: record the start time with `date +%s`, compute the deadline, create a progress file in /tmp, then loop — check the clock BEFORE every dispatch, dispatch a subagent to do ONE meaningful unit of work that ends in a commit (give it the goal and the progress file PATH to read itself, never the deadline), append the result to the progress file, repeat. Do no work yourself — no edits, no exploration, no quick fixes; that all belongs in subagents. THE CLOCK DECIDES WHEN TO STOP, NOT YOU: "good progress", "diminishing returns", "essentially complete", "the user would be happy" are all traps — on any such thought, check the clock and dispatch again. If a subagent returns with nothing to do, reframe the angle, go deeper, or broaden scope — do not stop. Every iteration must produce a committed artifact, not a plan or analysis. Only after the deadline passes, append a final summary (iterations, accomplishments, remaining work) to the progress file and report its path.

	# bughunt — autonomous find/triage/fix/audit pipeline
	- trigger: ":pbh"
	replace: \|-
	Run a fully autonomous bug hunt on the stated scope — no questions, no pauses between phases; log everything to a report the user reads at the end. (1) ORIENT: read the target code yourself, split it into sections along its natural structure, and check the output dir for prior-run reports — dedupe against previously fixed or disputed findings. (2) DISCOVER: parallel subagents, one per section, reporting only bugs a real user could hit — each with ID, severity, file:line, repro, and code evidence; no style nits, no hypotheticals. (3) TRIAGE: one independent skeptical subagent per finding, reading the code fresh with no discovery context, returning CONFIRMED / DISPUTED / DOWNGRADE; fix only findings that are Medium+ after triage; zero fixable bugs is a valid, successful result — never lower the bar to inflate the fix count, and keep disputed findings in a rejection table with reasons. (4) FIX: one subagent per confirmed bug returns a minimal exact edit WITHOUT applying it; you resolve overlaps, apply sequentially, and syntax-check every modified file. (5) AUDIT: check each fix against lint rules, target-platform portability (GNU vs BSD flags, bash-isms under /bin/sh, minimal environments), and surrounding-code conventions; correct violations directly and re-verify.

	# dark-factory — lights-out production in verified slices
	- trigger: ":pdf"
	replace: \|-
	Turn this idea into working software by lights-out production: build depth-first in verified slices so the software runs correctly after EVERY change — never breadth-first, never "integrate at the end". Confirm name and constraints with the user once up front, then run fully autonomously. You are only an orchestrator and state machine: decompose, dispatch subagents, verify, gate — write no product code yourself. Maintain a manifest file as ground truth: build/run/shutdown commands, every slice with status (PENDING/BUILDING/VERIFIED), its spec as atomic testable statements, and its verification commands defined BEFORE building starts. Slice 0 is always a walking skeleton (builds, launches, handles one basic input, produces one basic output, shuts down cleanly) and is a HARD GATE — nothing proceeds until an independent verifier passes it. Then loop: one capability per slice, one slice BUILDING at a time, a fresh builder subagent per slice; the verifier is ALWAYS a separate agent that builds from scratch, launches, exercises the new capability, and re-runs every prior slice's verification commands as regression check, recording CHECK/COMMAND/EXPECTED/ACTUAL/RESULT for each — reading the source is not verification, running the software is. A regression blocks all forward progress until fixed. Spot-check every delivery yourself (git status, git log, one new + one old verification command) — subagent reports can hallucinate success. Max 3 build-verify cycles per slice, then escalate to the user with all evidence — never silently skip a slice or shrink scope. After all slices are VERIFIED: harden (runtime bugbash + static review, fix Critical/High with full regression reruns), run the entire verification suite clean one final time, then ship. Working beats complete: five verified features beat fifteen broken ones.

	# --- Combo (prefix + postfix in one) ---

	# Full rigor: plan, execute, verify
	- trigger: ":pfl"
	replace: "Follow this protocol strictly. (1) PLAN — Describe the perfect end state and your step-by-step plan to get there; do not start until the plan is clear. (2) EXECUTE — Carry out the plan completely, no loose ends, no shortcuts. (3) VERIFY — Check every part of the output against the original request and fix anything that does not match. (4) REPORT — State what you did and what you verified in 1-3 sentences, nothing more. Do not skip or compress any step."
No results found