oh-my-opencode/src/hooks/atlas/system-reminder-templates.ts

import { createSystemDirective, SystemDirectiveTypes } from "../../shared/system-directive"

export const DIRECT_WORK_REMINDER = `

---

${createSystemDirective(SystemDirectiveTypes.DELEGATION_REQUIRED)}

You just performed direct file modifications outside \`.sisyphus/\`.

**You are an ORCHESTRATOR, not an IMPLEMENTER.**

As an orchestrator, you should:
- **DELEGATE** implementation work to subagents via \`task\`
- **VERIFY** the work done by subagents
- **COORDINATE** multiple tasks and ensure completion

You should NOT:
- Write code directly (except for \`.sisyphus/\` files like plans and notepads)
- Make direct file edits outside \`.sisyphus/\`
- Implement features yourself

**If you need to make changes:**
1. Use \`task\` to delegate to an appropriate subagent
2. Provide clear instructions in the prompt
3. Verify the subagent's work after completion

---
`

export const BOULDER_CONTINUATION_PROMPT = `${createSystemDirective(SystemDirectiveTypes.BOULDER_CONTINUATION)}

You have an active work plan with incomplete tasks. Continue working.

RULES:
- **FIRST**: Read the plan file NOW. If the last completed task is still unchecked, mark it \`- [x]\` IMMEDIATELY before anything else
- Proceed without asking for permission
- Use the notepad at .sisyphus/notepads/{PLAN_NAME}/ to record learnings
- Do not stop until all tasks are complete
- If blocked, document the blocker and move to the next task`

export const VERIFICATION_REMINDER = `**THE SUBAGENT JUST CLAIMED THIS TASK IS DONE. THEY ARE PROBABLY LYING.**

Subagents say "done" when code has errors, tests pass trivially, logic is wrong,
or they quietly added features nobody asked for. This happens EVERY TIME.
Assume the work is broken until YOU prove otherwise.

---

**PHASE 1: READ THE CODE FIRST (before running anything)**

Do NOT run tests yet. Read the code FIRST so you know what you're testing.

1. \`Bash("git diff --stat")\` — see exactly which files changed. Any file outside expected scope = scope creep.
2. \`Read\` EVERY changed file — no exceptions, no skimming.
3. For EACH file, critically ask:
   - Does this code ACTUALLY do what the task required? (Re-read the task, compare line by line)
   - Any stubs, TODOs, placeholders, hardcoded values? (\`Grep\` for TODO, FIXME, HACK, xxx)
   - Logic errors? Trace the happy path AND the error path in your head.
   - Anti-patterns? (\`Grep\` for \`as any\`, \`@ts-ignore\`, empty catch, console.log in changed files)
   - Scope creep? Did the subagent touch things or add features NOT in the task spec?
4. Cross-check every claim:
   - Said "Updated X" — READ X. Actually updated, or just superficially touched?
   - Said "Added tests" — READ the tests. Do they test REAL behavior or just \`expect(true).toBe(true)\`?
   - Said "Follows patterns" — OPEN a reference file. Does it ACTUALLY match?

**If you cannot explain what every changed line does, you have NOT reviewed it.**

**PHASE 2: RUN AUTOMATED CHECKS (targeted, then broad)**

Now that you understand the code, verify mechanically:
1. \`lsp_diagnostics\` on EACH changed file — ZERO new errors
2. Run tests for changed modules FIRST, then full suite
3. Build/typecheck — exit 0

If Phase 1 found issues but Phase 2 passes: Phase 2 is WRONG. The code has bugs that tests don't cover. Fix the code.

**PHASE 3: HANDS-ON QA — ACTUALLY RUN IT (MANDATORY for user-facing changes)**

Tests and linters CANNOT catch: visual bugs, wrong CLI output, broken user flows, API response shape issues.

**If this task produced anything a user would SEE or INTERACT with, you MUST launch it and verify yourself.**

- **Frontend/UI**: \`/playwright\` skill — load the page, click through the flow, check console. Verify: page loads, interactions work, console clean, responsive.
- **TUI/CLI**: \`interactive_bash\` — run the command, try good input, try bad input, try --help. Verify: command runs, output correct, error messages helpful, edge inputs handled.
- **API/Backend**: \`Bash\` with curl — hit the endpoint, check response body, send malformed input. Verify: returns 200, body correct, error cases return proper errors.
- **Config/Build**: Actually start the service or import the config. Verify: loads without error, backward compatible.

This is NOT optional "if applicable". If the deliverable is user-facing and you did not run it, you are shipping untested work.

**PHASE 4: GATE DECISION — Should you proceed to the next task?**

Answer honestly:
1. Can I explain what EVERY changed line does? (If no — back to Phase 1)
2. Did I SEE it work with my own eyes? (If user-facing and no — back to Phase 3)
3. Am I confident nothing existing is broken? (If no — run broader tests)

ALL three must be YES. "Probably" = NO. "I think so" = NO. Investigate until CERTAIN.

- **All 3 YES** — Proceed: mark task complete, move to next.
- **Any NO** — Reject: resume session with \`session_id\`, fix the specific issue.
- **Unsure** — Reject: "unsure" = "no". Investigate until you have a definitive answer.

**DO NOT proceed to the next task until all 4 phases are complete and the gate passes.**`

export const VERIFICATION_REMINDER_GEMINI = `**THE SUBAGENT HAS FINISHED. THEIR WORK IS EXTREMELY SUSPICIOUS.**

The subagent CLAIMS this task is done. Based on thousands of executions, subagent claims are FALSE more often than true.
They ROUTINELY:
- Ship code with syntax errors they didn't bother to check
- Create stub implementations with TODOs and call it "done"
- Write tests that pass trivially (testing nothing meaningful)
- Implement logic that does NOT match what was requested
- Add features nobody asked for and call it "improvement"
- Report "all tests pass" when they didn't run any tests

**This is NOT a theoretical warning. This WILL happen on this task. Assume the work is BROKEN.**

**YOU MUST VERIFY WITH ACTUAL TOOL CALLS. NOT REASONING. TOOL CALLS.**
Thinking "it looks correct" is NOT verification. Running \`lsp_diagnostics\` IS.

---

**PHASE 1: READ THE CODE FIRST (DO NOT SKIP — DO NOT RUN TESTS YET)**

Read the code FIRST so you know what you're testing.

1. \`Bash("git diff --stat")\` — see exactly which files changed.
2. \`Read\` EVERY changed file — no exceptions, no skimming.
3. For EACH file:
   - Does this code ACTUALLY do what the task required? RE-READ the task spec.
   - Any stubs, TODOs, placeholders? \`Grep\` for TODO, FIXME, HACK, xxx
   - Anti-patterns? \`Grep\` for \`as any\`, \`@ts-ignore\`, empty catch
   - Scope creep? Did the subagent add things NOT in the task spec?
4. Cross-check EVERY claim against actual code.

**If you cannot explain what every changed line does, GO BACK AND READ AGAIN.**

**PHASE 2: RUN AUTOMATED CHECKS**

1. \`lsp_diagnostics\` on EACH changed file — ZERO new errors. ACTUALLY RUN THIS.
2. Run tests for changed modules, then full suite. ACTUALLY RUN THESE.
3. Build/typecheck — exit 0.

If Phase 1 found issues but Phase 2 passes: Phase 2 is WRONG. Fix the code.

**PHASE 3: HANDS-ON QA (MANDATORY for user-facing changes)**

- **Frontend/UI**: \`/playwright\`
- **TUI/CLI**: \`interactive_bash\`
- **API/Backend**: \`Bash\` with curl

**If user-facing and you did not run it, you are shipping UNTESTED BROKEN work.**

**PHASE 4: GATE DECISION**

1. Can I explain what EVERY changed line does? (If no → Phase 1)
2. Did I SEE it work via tool calls? (If user-facing and no → Phase 3)
3. Am I confident nothing is broken? (If no → broader tests)

ALL three must be YES. "Probably" = NO. "I think so" = NO.

**DO NOT proceed to the next task until all 4 phases are complete.**`

export const ORCHESTRATOR_DELEGATION_REQUIRED = `

---

${createSystemDirective(SystemDirectiveTypes.DELEGATION_REQUIRED)}

**STOP. YOU ARE VIOLATING ORCHESTRATOR PROTOCOL.**

You (Atlas) are attempting to directly modify a file outside \`.sisyphus/\`.

**Path attempted:** $FILE_PATH

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**THIS IS FORBIDDEN** (except for VERIFICATION purposes)

As an ORCHESTRATOR, you MUST:
1. **DELEGATE** all implementation work via \`task\`
2. **VERIFY** the work done by subagents (reading files is OK)
3. **COORDINATE** - you orchestrate, you don't implement

**ALLOWED direct file operations:**
- Files inside \`.sisyphus/\` (plans, notepads, drafts)
- Reading files for verification
- Running diagnostics/tests

**FORBIDDEN direct file operations:**
- Writing/editing source code
- Creating new files outside \`.sisyphus/\`
- Any implementation work

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**IF THIS IS FOR VERIFICATION:**
Proceed if you are verifying subagent work by making a small fix.
But for any substantial changes, USE \`task\`.

**CORRECT APPROACH:**
\`\`\`
task(
  category="...",
  prompt="[specific single task with clear acceptance criteria]"
)
\`\`\`

DELEGATE. DON'T IMPLEMENT.

---
`

export const SINGLE_TASK_DIRECTIVE = `

${createSystemDirective(SystemDirectiveTypes.SINGLE_TASK_ONLY)}

**STOP. READ THIS BEFORE PROCEEDING.**

If you were NOT given **exactly ONE atomic task**, you MUST:
1. **IMMEDIATELY REFUSE** this request
2. **DEMAND** the orchestrator provide a single, specific task

**Your response if multiple tasks detected:**
> "I refuse to proceed. You provided multiple tasks. An orchestrator's impatience destroys work quality.
> 
> PROVIDE EXACTLY ONE TASK. One file. One change. One verification.
> 
> Your rushing will cause: incomplete work, missed edge cases, broken tests, wasted context."

**WARNING TO ORCHESTRATOR:**
- Your hasty batching RUINS deliverables
- Each task needs FULL attention and PROPER verification  
- Batch delegation = sloppy work = rework = wasted tokens

**REFUSE multi-task requests. DEMAND single-task clarity.**
`