coyote/assets/agents/coder/graph.yaml

name: coder
description: |
  Implementation agent. Plans, implements, and runs build + tests in a
  bounded fix-loop until verified. Designed to be delegated to by sisyphus.
version: '1.0'
global_tools:
  - ast_grep.sh
  - fs_cat.sh
  - fs_ls.sh
  - fs_write.sh
  - fs_patch.sh
  - execute_command.sh

skills_enabled: true
enabled_skills:
  - ai-slop-remover
  - code-review
  - comment-discipline
  - diagnosing-bugs
  - logging-discipline
  - git-master
  - frontend-ui-ux
  - verification-gates

variables:
  - name: project_dir
    description: |
      Absolute path to the project directory. Defaults to "." which is the
      directory you invoked `coyote` from. Override at runtime with
      `coyote -a coder --agent-variable project_dir /abs/path "..."`.
    default: '.'

settings:
  max_loop_iterations: 20
  log_state_snapshots: true
  validate_before_run: true
  timeout: 14400

initial_state:
  project_dir: ''
  fix_attempts: 0
  max_fix_attempts: 3
  fix_instructions: ''
  build_output: ''
  tests_output: ''
  last_node_output: ''
  plan_summary: ''
  files_to_modify: []
  files_to_create: []
  risks: []
  complexity_score: 0
  review_attempts: 0
  max_review_attempts: 1
  review_clean: true
  review_notes: ''

start: resolve_paths

nodes:
  resolve_paths:
    id: resolve_paths
    type: script
    description: Resolve project_dir to an absolute path from the agent variable
    script: scripts/resolve_paths.sh
    timeout: 5
    fallback: end_failure

  analyze_request:
    id: analyze_request
    type: llm
    description: Extract a structured plan and complexity score from the orchestrator's prompt
    instructions: |
      You are a senior engineer's planning assistant. Read the orchestrator's
      request and emit a structured plan. You only plan. You never edit files.

      Score complexity from 1 to 10:
        1-3: trivial - single file, <=20 lines changed, obvious approach
        4-6: moderate - 2-5 files, clear approach, some pattern matching
        7-10: complex - multi-component, ambiguous tradeoffs, refactoring,
              or wide blast radius

      Be specific in `files_to_modify` and `files_to_create`. All paths
      MUST be absolute. The project root is {{project_dir}}. Prefer paths
      like "{{project_dir}}/src/foo.rs" over "src/foo.rs". The implementer
      uses these paths directly with fs_write and fs_patch tools, which
      resolve relative paths against the coyote invocation directory (NOT
      the project dir). Empty arrays are fine if no files in that category.

      `risks` is a list of short strings. Anything that could derail the
      implementation: unknown dependencies, brittle tests, blast radius,
      etc. Empty list is fine.

      Project directory: {{project_dir}}
    prompt: '{{initial_prompt}}'
    tools: []
    timeout: 300
    output_schema:
      type: object
      properties:
        plan_summary:
          type: string
          description: 1-3 sentences summarizing what will be done
        files_to_modify:
          type: array
          items: { type: string }
        files_to_create:
          type: array
          items: { type: string }
        complexity_score:
          type: integer
          minimum: 1
          maximum: 10
        risks:
          type: array
          items: { type: string }
      required:
        [
          plan_summary,
          files_to_modify,
          files_to_create,
          complexity_score,
          risks,
        ]
    state_updates:
      last_node_output: '{{output}}'
    fallback: end_failure
    next: route_complexity

  route_complexity:
    id: route_complexity
    type: script
    description: Route to approval gate for complex plans; skip otherwise
    script: scripts/route_complexity.sh
    timeout: 5
    fallback: implement

  gate_approval:
    id: gate_approval
    type: approval
    description: Optional human checkpoint for high-complexity plans
    question: |
      ## Plan
      {{plan_summary}}

      ## Files to modify
      {{files_to_modify}}

      ## Files to create
      {{files_to_create}}

      ## Risks
      {{risks}}

      Complexity: {{complexity_score}}/10

      Approve this plan?
    options:
      - 'yes'
      - 'no'
    routes:
      'yes': implement
      'no': end_rejected
    on_other: end_rejected

  implement:
    id: implement
    type: llm
    description: Write code via fs tools. Bounded tool-call loop.
    skills_enabled: true
    enabled_skills:
      - ai-slop-remover
      - code-review
      - comment-discipline
      - diagnosing-bugs
      - logging-discipline
      - git-master
      - frontend-ui-ux
      - verification-gates
    instructions: |
      You are a senior engineer. Implement the plan by writing code via
      tools. Follow existing patterns in the codebase.

      ## Skills

      Use `skill__list` to see what's available, then `skill__load` the ones
      that fit the work: `ai-slop-remover` and `comment-discipline` always,
      `frontend-ui-ux` when touching UI, `git-master` when touching history,
      `verification-gates` to remember what evidence is required. Unload when
      a phase ends.

      ## Writing code

      1. Use `fs_patch` for surgical edits to existing files.
      2. Use `fs_write` for new files or full rewrites.
      3. NEVER write files via `execute_command`. Do not use `cat >`,
         `cat >>`, `echo >`, `printf >`, `tee`, heredocs (`<<EOF`), or
         `python3 -c "open(...).write(...)"`. Shell-based file writes
         break on multi-line content, special characters, quoted strings,
         and nested language blocks. `fs_write` and `fs_patch` handle
         these correctly because they don't go through shell parsing.
      4. NEVER output code to chat. Always use tools.
      5. ALWAYS pass ABSOLUTE paths to fs_write and fs_patch. Relative
         paths resolve against the coyote invocation directory (not the
         project dir), which is rarely what you want. The project root
         is {{project_dir}}.

      ## File reading

      1. Use `execute_command` to grep/find:
         `execute_command --command "grep -rn 'fn handle_request' --include='*.rs' ."`
         `execute_command --command "find . -name '*.rs' -not -path '*/target/*'"`
      2. Read only what you need:
         `fs_cat --path "src/main.rs" --offset 50 --limit 30`
      3. Never read entire large files. Use offset/limit.
      4. Use `fs_ls` to list directory contents.

      ## Pattern matching

      Before writing ANY file:
      1. Find a similar existing file (grep, then read).
      2. Match its style: imports, naming, structure, error handling.
      3. While reading it, note the repo's comment register per
         `comment-discipline` (self-documenting / api-documented /
         comment-heavy) and write comments to match. When the signal is
         weak, write NO comment.
      4. If the change touches boundaries, error paths, jobs, or state
         transitions, also note the logging register per
         `logging-discipline` (logger, message style, payload vs IDs,
         level semantics) and match it; with no signal, use its
         best-judgment defaults.
      5. Follow the same patterns exactly. Do not invent new ones.

      ## Fix loop

      If the "Fix loop status" section in your user prompt is non-empty,
      the previous attempt failed verification. Read the error, identify
      the minimal fix, apply it. Do not refactor while fixing.

      If the fix is not obvious from the error, or a previous fix attempt
      for the SAME failure did not stick, `skill__load` `diagnosing-bugs`
      and follow it: build a red-capable reproduction loop before forming
      any hypothesis. Do not spend a second attempt on a blind retry.

      ## Rules

      1. Match existing patterns - read examples first.
      2. Minimal changes - implement only what's asked.
      3. Never suppress errors (`as any`, `@ts-ignore`, `#[allow(...)]`
         on unfamiliar lints, etc.).
      4. No dead code, no commented-out blocks, no premature abstractions.
      5. End your turn when editing is done. The graph runs verification next.
      6. VERIFICATION HONESTY: never state that a check, lint, build, or test
         passed unless you paste its literal command and exit code. A gate
         that did not run is UNVERIFIED — say so. An honest failure report
         always beats a success-shaped one; a false "passed" poisons every
         downstream consumer of your report.

      Project directory: {{project_dir}}
    prompt: |
      ## Plan summary
      {{plan_summary}}

      ## Files involved
      - Modify: {{files_to_modify}}
      - Create: {{files_to_create}}

      ## Original request from the orchestrator
      {{initial_prompt}}

      ## Fix loop status
      {{fix_instructions}}
    tools:
      - fs_cat
      - fs_ls
      - fs_write
      - fs_patch
      - execute_command
    max_iterations: 100
    timeout: 1800
    state_updates:
      last_node_output: '{{output}}'
    fallback: end_failure
    next: verify_build

  verify_build:
    id: verify_build
    type: script
    description: Run the project's check/build command. Routes to verify_tests on success, fix_loop_gate on failure.
    script: scripts/verify_build.sh
    timeout: 300
    fallback: fix_loop_gate

  verify_tests:
    id: verify_tests
    type: script
    description: Run the project's test command. Routes to end_success on pass, fix_loop_gate on failure.
    script: scripts/verify_tests.sh
    timeout: 600
    fallback: fix_loop_gate

  fix_loop_gate:
    id: fix_loop_gate
    type: script
    description: Budget gate. Loops back to implement with fix_instructions populated, or terminates as end_failure.
    script: scripts/fix_loop_gate.sh
    timeout: 5
    fallback: end_failure

  self_review:
    id: self_review
    type: llm
    description: Skill-driven self-review of the diff. Catches AI slop, dishonest naming, suppressed errors. Bounded to max_review_attempts.
    skills_enabled: true
    enabled_skills:
      - code-review
      - ai-slop-remover
    instructions: |
      You are reviewing the diff you just produced. Load `code-review` and
      `ai-slop-remover` via `skill__load` and apply their checklists STRICTLY.

      Flag ONLY concrete issues:
        - Correctness bugs or uncovered edge cases
        - Suppressed errors (as any, @ts-ignore, #[allow(...)] on unfamiliar
          lints, empty catch blocks)
        - Dishonest naming (get_X that mutates, returns wrong type, etc.)
        - Useless comments that restate the code
        - AI slop (filler prose, multi-paragraph docstrings, defensive
          handling of impossible cases)

      Do NOT flag:
        - Style preferences if the pattern matches existing code in the repo
        - Things the build/tests already verified
        - "Could be more elegant" without a concrete bug

      Be terse. The orchestrator wants signal, not noise. If you find nothing
      blocking, set review_clean=true and leave review_notes empty.

      Project directory: {{project_dir}}
    prompt: |
      ## Files to review
      Modified: {{files_to_modify}}
      Created: {{files_to_create}}

      ## What the implementation was supposed to do
      {{plan_summary}}

      Read each file's changed region. Apply the review skills. Output your verdict.
    tools:
      - fs_cat
      - fs_ls
      - execute_command
    max_iterations: 15
    timeout: 600
    output_schema:
      type: object
      properties:
        review_clean:
          type: boolean
          description: True if no blocker issues were found.
        review_notes:
          type: string
          description: Concrete issues found, one per line as file:line - description. Empty when review_clean is true.
      required: [review_clean, review_notes]
    state_updates:
      last_node_output: '{{output}}'
    fallback: end_success
    next: route_review_result

  route_review_result:
    id: route_review_result
    type: script
    description: Routes based on review_clean and review_attempts budget. End on clean or budget exhausted; loop to implement otherwise.
    script: scripts/route_review_result.sh
    timeout: 5
    fallback: end_success

  end_success:
    id: end_success
    type: end
    output: |
      CODER_COMPLETE
      Plan: {{plan_summary}}
      Files modified: {{files_to_modify}}
      Files created: {{files_to_create}}
      Build: passed
      Tests: passed

  end_rejected:
    id: end_rejected
    type: end
    output: |
      CODER_REJECTED
      Plan was rejected at the approval gate.
      Plan: {{plan_summary}}

  end_failure:
    id: end_failure
    type: end
    output: |
      CODER_FAILED
      Plan: {{plan_summary}}
      Attempts: {{fix_attempts}}/{{max_fix_attempts}}

      Last node output:
      {{last_node_output}}

      Last build output:
      {{build_output}}

      Last tests output:
      {{tests_output}}