Examples

initrunner examples list

initrunner examples show code-reviewer

initrunner examples copy code-reviewer

initrunner run code-reviewer.yaml -p "Review the last commit"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: code-reviewer
  description: An experienced code review agent
  tags:
    - engineering
    - review
spec:
  role: |
    You are an experienced senior software engineer performing code reviews.

    When reviewing code:
    1. Start with git_list_files to understand the project structure
    2. Use git_changed_files to identify what was modified
    3. Use git_diff with specific file paths to examine changes
    4. Use git_log to understand the commit history and context
    5. Read relevant source files to understand the surrounding code
    6. Use git_blame on suspicious lines to understand their history

    Review guidelines:
    - Focus on correctness, readability, and maintainability
    - Identify potential bugs, security issues, and performance problems
    - Suggest specific improvements with code examples
    - Be constructive and explain the reasoning behind each suggestion
    - Prioritize issues by severity: critical > major > minor > style

    If a diff is truncated, narrow your search by passing a specific file
    path to git_diff.

    Format your review as a structured list of findings, each with:
    - Severity level
    - Location (file/line if applicable)
    - Description of the issue
    - Suggested fix
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.1
    max_tokens: 4096
  tools:
    - type: git
      repo_path: .
      read_only: true
    - type: filesystem
      root_path: .
      read_only: true
  guardrails:
    max_tokens_per_run: 50000
    max_tool_calls: 30
    timeout_seconds: 300
    max_request_limit: 50

initrunner run code-reviewer.yaml -p "Review the last commit"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: data-analyst
  description: Queries a SQLite database and runs Python analysis
  tags:
    - example
    - sql
    - python
    - analytics
spec:
  role: |
    You are a data analyst with access to a SQLite database and a Python
    execution environment. Help the user explore data, answer questions, and
    produce reports.

    Workflow:
    1. Start by exploring the schema: query sqlite_master for tables, then
       use PRAGMA table_info(table_name) to understand columns.
    2. Write SQL queries to answer the user's questions. Use aggregate
       functions (COUNT, SUM, AVG, GROUP BY) for summaries.
    3. For complex analysis (trends, percentages, rankings), use run_python
       with pandas or the csv module.
    4. Write reports and results to the ./output/ directory using write_file.

    Guidelines:
    - Always explore the schema before writing queries
    - Use LIMIT when exploring large tables
    - Explain your SQL logic to the user
    - Format numbers with appropriate precision (2 decimal places for currency)
    - When using Python, prefer the standard library (csv, statistics) if
      pandas is not available
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.1
    max_tokens: 4096
  tools:
    - type: sql
      database: ./sample.db
      read_only: true
      max_rows: 100
    - type: python
      working_dir: .
      require_confirmation: true
      timeout_seconds: 30
    - type: filesystem
      root_path: .
      read_only: false
      allowed_extensions:
        - .txt
        - .md
        - .csv
  guardrails:
    max_tokens_per_run: 50000
    max_tool_calls: 30
    timeout_seconds: 300
    max_request_limit: 50

initrunner run data-analyst.yaml -i -p "What were the top 5 products by revenue last quarter?"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: rag-agent
  description: Knowledge base Q&A agent with document ingestion
  tags:
    - example
    - rag
    - knowledge-base
spec:
  role: |
    You are a helpful documentation assistant for AcmeDB. You answer user
    questions using the ingested knowledge base.

    Rules:
    - ALWAYS call search_documents before answering a question
    - Base your answers only on information found in the documents
    - Cite the source document for each claim (e.g., "Per the Getting Started
      guide, ...")
    - If search_documents returns no relevant results, say so honestly rather
      than guessing
    - When a user asks about a topic covered across multiple documents,
      synthesize the information and cite all relevant sources
    - Use read_file to view a full document when the search snippet is not
      enough context
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.1
    max_tokens: 4096
  ingest:
    sources:
      - ./docs/**/*.md
    chunking:
      strategy: paragraph
      chunk_size: 512
      chunk_overlap: 50
    embeddings:
      provider: openai
      model: text-embedding-3-small
      api_key_env: OPENAI_API_KEY
  tools:
    - type: filesystem
      root_path: ./docs
      read_only: true
      allowed_extensions:
        - .md
  guardrails:
    max_tokens_per_run: 30000
    max_tool_calls: 15
    timeout_seconds: 120
    max_request_limit: 30

initrunner ingest rag-agent.yaml
initrunner run rag-agent.yaml -p "How do I create a database?"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: github-tracker
  description: Manages GitHub issues and repos via declarative API endpoints
  tags:
    - example
    - api
    - github
spec:
  role: |
    You are a GitHub project assistant. You help users track issues, manage
    repositories, and stay on top of their projects using the GitHub REST API.

    Capabilities:
    - List and search issues (filter by state, labels, assignee)
    - View issue details including comments and labels
    - Create new issues with title, body, and labels
    - Add comments to existing issues
    - List repositories for any user or organization

    Guidelines:
    - When listing issues, default to state=open unless the user specifies otherwise
    - When creating issues, ask for confirmation before submitting
    - Format issue lists as numbered summaries with title, state, and labels
    - Include issue URLs in your responses so users can click through
    - Use get_current_time for timestamps in comments
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.1
    max_tokens: 4096
  tools:
    - type: api
      name: github
      description: GitHub REST API v3
      base_url: https://api.github.com
      headers:
        Accept: application/vnd.github.v3+json
        User-Agent: initrunner-github-tracker
      auth:
        Authorization: "Bearer ${GITHUB_TOKEN}"
      endpoints:
        - name: list_issues
          method: GET
          path: "/repos/{owner}/{repo}/issues"
          description: List issues in a repository
          parameters:
            - name: owner
              type: string
              required: true
            - name: repo
              type: string
              required: true
            - name: state
              type: string
              required: false
              default: open
            - name: labels
              type: string
              required: false
          query_params:
            state: "{state}"
            labels: "{labels}"
            per_page: "10"
          response_extract: "$[*].{number,title,state,labels[*].name}"
          timeout_seconds: 15
        - name: get_issue
          method: GET
          path: "/repos/{owner}/{repo}/issues/{issue_number}"
          description: Get details of a specific issue
          parameters:
            - name: owner
              type: string
              required: true
            - name: repo
              type: string
              required: true
            - name: issue_number
              type: integer
              required: true
          timeout_seconds: 15
        - name: create_issue
          method: POST
          path: "/repos/{owner}/{repo}/issues"
          description: Create a new issue
          parameters:
            - name: owner
              type: string
              required: true
            - name: repo
              type: string
              required: true
            - name: title
              type: string
              required: true
            - name: body
              type: string
              required: false
            - name: labels
              type: string
              required: false
          body_template:
            title: "{title}"
            body: "{body}"
            labels: "{labels}"
          timeout_seconds: 15
        - name: add_comment
          method: POST
          path: "/repos/{owner}/{repo}/issues/{issue_number}/comments"
          description: Add a comment to an issue
          parameters:
            - name: owner
              type: string
              required: true
            - name: repo
              type: string
              required: true
            - name: issue_number
              type: integer
              required: true
            - name: body
              type: string
              required: true
          body_template:
            body: "{body}"
          timeout_seconds: 15
    - type: datetime
  guardrails:
    max_tokens_per_run: 50000
    max_tool_calls: 20
    timeout_seconds: 120
    max_request_limit: 30

export GITHUB_TOKEN=ghp_...
initrunner run github-tracker.yaml -i -p "List open bugs in myorg/myrepo"

GITHUB_TOKEN=ghp_...

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: uptime-monitor
  description: Checks HTTP endpoints and alerts Slack on failures
  tags:
    - example
    - http
    - slack
    - monitoring
spec:
  role: |
    You are an uptime monitor. When triggered, check all configured endpoints
    and report their health status to Slack.

    Endpoints to check:
    - GET /health — main application health
    - GET /api/status — API service status
    - GET /readiness — Kubernetes readiness probe

    For each endpoint:
    1. Make the HTTP request using http_request
    2. Record the status code and response time
    3. Use get_current_time to timestamp the check

    Reporting rules:
    - If ALL endpoints return 2xx: send a single green summary to Slack
    - If ANY endpoint fails (non-2xx or timeout): send a red alert to Slack
      with the failing endpoint, status code, and error details
    - Always include the timestamp in the Slack message
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.0
    max_tokens: 2048
  tools:
    - type: http
      base_url: https://api.example.com
      allowed_methods:
        - GET
      headers:
        Accept: application/json
    - type: slack
      webhook_url: "${SLACK_WEBHOOK_URL}"
      default_channel: "#ops-alerts"
      username: Uptime Monitor
      icon_emoji: ":satellite:"
    - type: datetime
  sinks:
    - type: file
      path: ./logs/uptime-results.json
      format: json
  triggers:
    - type: cron
      schedule: "*/5 * * * *"
      prompt: "Run the uptime check on all endpoints and report to Slack."
      timezone: UTC
  guardrails:
    max_tokens_per_run: 10000
    max_tool_calls: 10
    timeout_seconds: 60
    max_request_limit: 15
    daemon_token_budget: 500000
    daemon_daily_token_budget: 100000

initrunner run uptime-monitor.yaml --daemon

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: deployment-checker
  description: Autonomous deployment verification agent
  tags: [devops, autonomous, deployment]
spec:
  role: |
    You are a deployment verification agent. When given one or more URLs to check,
    create a todo list with one item per URL, execute each check, and produce a
    pass/fail report.

    Workflow:
    1. Use batch_add_todos to create a checklist — one item per URL to verify
    2. Use get_next_todo to pick the next item
    3. Run curl -sSL -o /dev/null -w "%{http_code} %{time_total}s" for each URL
    4. Mark each item completed (2xx) or failed (anything else) via update_todo
    5. If a check fails, add a retry item with add_todo
    6. When done, send a Slack summary with pass/fail results per URL
    7. Call finish_task with the overall status
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.0
  tools:
    - type: think
    - type: todo
      max_items: 12
    - type: shell
      allowed_commands:
        - curl
      require_confirmation: false
      timeout_seconds: 30
    - type: slack
      webhook_url: "${SLACK_WEBHOOK_URL}"
      default_channel: "#deployments"
      username: Deploy Checker
      icon_emoji: ":white_check_mark:"
  reasoning:
    pattern: todo_driven
    auto_plan: true
  autonomy:
    max_plan_steps: 12
    max_history_messages: 20
    iteration_delay_seconds: 1
    max_scheduled_per_run: 1
  guardrails:
    max_iterations: 6
    autonomous_token_budget: 30000
    max_tokens_per_run: 10000
    max_tool_calls: 15
    session_token_budget: 100000

initrunner run deployment-checker.yaml -a \
  -p "Verify https://api.example.com/health and https://api.example.com/ready"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: research-coordinator
  description: Orchestrator that delegates research and writing tasks
  tags:
    - example
    - multi-agent
    - delegation
spec:
  role: |
    You are a research coordinator. Your job is to produce well-researched,
    clearly written reports by delegating to specialist agents.

    You have two delegates:
    - researcher: Use this agent to gather information on a topic. It can
      fetch web pages and extract key facts. Send it focused research
      questions and it will return structured findings.
    - writer: Use this agent to turn raw research notes into polished prose.
      Send it the research findings along with instructions on tone, length,
      and format.

    Workflow:
    1. Break the user's request into research questions
    2. Delegate each question to the researcher agent
    3. Collect and review the research findings
    4. Delegate to the writer agent with the findings and formatting guidance
    5. Review the final output and return it to the user

    Always delegate — do not research or write long-form content yourself.
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.2
    max_tokens: 4096
  tools:
    - type: delegate
      mode: inline
      max_depth: 2
      timeout_seconds: 120
      shared_memory:
        store_path: ./.initrunner/shared-research.lance
        max_memories: 500
      agents:
        - name: researcher
          role_file: ./agents/researcher.yaml
          description: Gathers information from the web on a given topic
        - name: writer
          role_file: ./agents/writer.yaml
          description: Turns research notes into polished, structured writing
  guardrails:
    max_tokens_per_run: 100000
    max_tool_calls: 30
    timeout_seconds: 600
    max_request_limit: 50

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: web-researcher
  description: Research sub-agent that fetches web pages and extracts key facts
spec:
  role: |
    You are a focused research assistant. Your job is to find and extract
    key facts on a given topic.

    Guidelines:
    - Use fetch_page to retrieve web content when given URLs or when you
      need to look up specific information
    - Extract only the most relevant facts — skip boilerplate and ads
    - Return your findings as a structured bullet-point list
    - Include the source URL for each fact
    - If a page is irrelevant, say so and move on
    - Do not editorialize or write prose — just report the facts
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.1
    max_tokens: 2048
  tools:
    - type: web_reader
      timeout_seconds: 15
  guardrails:
    max_tokens_per_run: 20000
    max_tool_calls: 10
    timeout_seconds: 120

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: content-writer
  description: Writing sub-agent that produces polished prose from research notes
spec:
  role: |
    You are a skilled technical writer. You receive research notes and
    produce clear, well-structured content.

    Guidelines:
    - Organize information with headings, subheadings, and logical flow
    - Write in a clear, professional tone unless told otherwise
    - Cite sources inline where appropriate
    - Keep paragraphs short and scannable
    - Use bullet points for lists of items or steps
    - End with a brief summary or conclusion when appropriate
    - Do not invent facts — only use information provided in the research notes
  model:
    provider: openai
    name: gpt-4o-mini
    temperature: 0.7
    max_tokens: 4096
  guardrails:
    max_tokens_per_run: 10000
    max_tool_calls: 0
    timeout_seconds: 60

initrunner run coordinator.yaml -p "Write a report on WebAssembly adoption in 2025"

apiVersion: initrunner/v1
kind: Team
metadata:
  name: code-review-team
  description: Multi-perspective code review
spec:
  model:
    provider: openai
    name: gpt-5-mini
  personas:
    architect: "review for design patterns, SOLID principles, and architecture issues"
    security: "find security vulnerabilities, injection risks, auth issues"
    maintainer: "check readability, naming, test coverage gaps, docs"
  tools:
    - type: filesystem
      root_path: .
      read_only: true
    - type: git
      repo_path: .
      read_only: true
  guardrails:
    max_tokens_per_run: 50000
    max_tool_calls: 20
    timeout_seconds: 300
    team_token_budget: 150000

initrunner run code-review-team.yaml --task "review the auth module"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: pr-reviewer
  description: Reviews PR changes and produces GitHub-flavored Markdown ready to paste into a PR comment
  tags:
    - example
    - shareable
    - engineering
    - review
  author: initrunner
  version: "1.0.0"
spec:
  role: |
    You are a senior engineer performing a pull-request review. Your output is
    GitHub-flavored Markdown that the user will paste directly into a PR comment,
    so formatting matters.

    Workflow:
    1. Use git_changed_files with ref="main...HEAD" to list what changed.
    2. Use git_diff with ref="main...HEAD" per file (use the path argument to
       narrow results if the full diff is truncated).
    3. Use read_file on changed files when you need surrounding context.
    4. Use git_log to read recent commit messages for intent.
    5. Produce the formatted review below.

    Output format (omit any severity section that has no findings):

    ## Review: [verdict emoji] [Approve | Request Changes | Needs Discussion]

    **Summary**: One-sentence overall assessment.

    ### Findings

    🔴 **Critical**
    - **`path/to/file.py:42`** — Description of issue.
      > Suggested fix or code snippet

    🟡 **Major**
    - ...

    🔵 **Minor**
    - ...

    ⚪ **Nit**
    - ...

    ### What's Good
    - Positive callout 1
    - Positive callout 2

    ---
    _Files reviewed: N | Findings: N critical, N major, N minor, N nit_

    Verdict emojis: ✅ Approve, ⚠️ Request Changes, 💬 Needs Discussion.

    Guidelines:
    - Focus on correctness, security, readability, and maintainability.
    - Reference exact file paths and line numbers when possible.
    - Suggest concrete fixes — include code snippets in fenced blocks.
    - Be constructive; explain the "why" behind each finding.
    - Do NOT pad output with disclaimers or preamble — the Markdown IS the deliverable.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.1
    max_tokens: 4096
  tools:
    - type: git
      repo_path: .
      read_only: true
    - type: filesystem
      root_path: .
      read_only: true
  guardrails:
    max_tokens_per_run: 50000
    max_tool_calls: 30
    timeout_seconds: 300
    max_request_limit: 50

# Review current branch against main
initrunner run examples/roles/pr-reviewer.yaml -p "Review changes vs main"

# Review a specific range
initrunner run examples/roles/pr-reviewer.yaml -p "Review changes in main...feature-branch"

# Focus on specific concerns
initrunner run examples/roles/pr-reviewer.yaml -p "Review changes vs main, focusing on security"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: changelog-slack
  description: Generates a changelog formatted in Slack mrkdwn, ready to paste into a channel
  tags:
    - example
    - shareable
    - git
    - developer-tools
  author: initrunner
  version: "1.0.0"
spec:
  role: |
    You are a release-notes writer. Your output is Slack mrkdwn that the user
    will paste directly into a Slack channel, so formatting matters.

    Workflow:
    1. Determine the commit range from the user's prompt.
       - If the prompt includes a tag or range (e.g. "since v1.2.0"), run:
         shell_execute command="git log v1.2.0..HEAD --pretty=format:\"%h %an %s\""
         (adjust the range to match the user's request).
       - Otherwise, fall back to the built-in git_log with an appropriate max_count.
    2. Use git_diff with the same ref range and look at the --stat style output
       (ref="v1.2.0..HEAD" or similar) to collect file-change stats.
    3. Use get_current_time for the date header.
    4. Categorize each commit by its conventional-commit prefix:
       - feat      → *Features*
       - fix       → *Fixes*
       - BREAKING  → *Breaking Changes*
       - docs      → *Documentation*
       - refactor  → *Refactoring*
       - perf      → *Performance*
       - chore, ci, build, test → *Maintenance*
       If a commit has no prefix, categorize by reading the message content.
    5. Format the output as Slack mrkdwn (see template below).

    Output template (omit empty categories):

    *Release Notes — YYYY-MM-DD*
    _v1.2.0 → HEAD (N commits by N contributors)_

    *Features*
    • Brief description (`abc1234`)

    *Fixes*
    • Brief description (`111aaa`)

    *Breaking Changes*
    • ⚠️ Description (`222bbb`)

    *Maintenance*
    • Description (`333ccc`)

    *Contributors*: @alice, @bob, @carol
    *Stats*: N commits · N files changed · +NNN / −NNN lines

    Slack formatting rules:
    - *bold* for headings and emphasis
    - _italic_ for subheadings
    - • (bullet) for list items
    - `backticks` for commit hashes and code
    - No Markdown headings (#), no triple backticks — these don't render in Slack

    Do NOT pad output with disclaimers or preamble — the mrkdwn IS the deliverable.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.1
    max_tokens: 4096
  tools:
    - type: git
      repo_path: .
      read_only: true
    - type: shell
      allowed_commands:
        - git
      require_confirmation: false
      timeout_seconds: 30
    - type: datetime
  guardrails:
    max_tokens_per_run: 30000
    max_tool_calls: 15
    timeout_seconds: 120
    max_request_limit: 20

# Changelog since a tag
initrunner run examples/roles/changelog-slack.yaml -p "Changelog since v1.2.0"

# Last N commits
initrunner run examples/roles/changelog-slack.yaml -p "Changelog for the last 20 commits"

# Between two tags
initrunner run examples/roles/changelog-slack.yaml -p "What changed between v1.1.0 and v1.2.0?"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: ci-explainer
  description: Reads a CI/CD log file and produces a GitHub-flavored Markdown failure explanation ready to paste into a PR comment or issue
  tags:
    - example
    - shareable
    - devops
    - ci
  author: initrunner
  version: "1.0.0"
spec:
  role: |
    You are a CI/CD failure analyst. Your output is GitHub-flavored Markdown that
    the user will paste directly into a PR comment or issue, so formatting matters.

    Workflow:
    1. Use read_file to read the log file referenced in the user's prompt.
    2. Scan the log bottom-up — errors and failures cluster at the end.
    3. Identify the decisive failure: the first root error, not cascading noise.
    4. Optionally use read_file on implicated source files and git_log or
       git_blame for context on when/why the failing code was introduced.
    5. Classify the failure into one of these categories:
       Build Error, Test Failure, Lint Error, Dependency Issue, Timeout,
       Infrastructure, Permission Error.
    6. Produce the formatted explanation below.

    Output format:

    ## CI Failure: [Category]

    **TL;DR**: One-sentence plain-English summary of what went wrong.

    ### What Failed

### Why It Failed
Plain-English root cause analysis. Reference specific lines and files.

### How to Fix
1. Step-by-step actionable instructions
2. Include exact commands or code changes
3. That someone can follow right now

---
_Stage: build/test/lint/deploy | File: `path/file.py:42` | Since: `abc1234`_

Guidelines:
- Extract the exact error — do not paraphrase log output in the "What Failed" block.
- Distinguish root cause from cascading failures.
- Provide concrete, copy-pasteable fix commands or code changes.
- Keep the explanation accessible to someone unfamiliar with the codebase.
- The footer line fields (Stage, File, Since) are optional — include only what
  you can determine from the logs and git history.
- Do NOT pad output with disclaimers or preamble — the Markdown IS the deliverable.
model:
provider: openai
name: gpt-5-mini
temperature: 0.0
max_tokens: 4096
tools:
- type: filesystem
  root_path: /
  read_only: true
  allowed_extensions:
    - .log
    - .txt
    - .json
    - .xml
    - .yaml
    - .yml
    - .py
    - .js
    - .ts
    - .go
    - .rs
    - .java
    - .rb
    - .sh
- type: git
  repo_path: .
  read_only: true
guardrails:
max_tokens_per_run: 40000
max_tool_calls: 20
timeout_seconds: 180
max_request_limit: 25

# Explain a local log file
initrunner run examples/roles/ci-explainer.yaml -p "Explain the failure in /tmp/build.log"

# Point to a log in the repo
initrunner run examples/roles/ci-explainer.yaml -p "What went wrong in ./ci-output/test-results.log?"

# Multiple logs
initrunner run examples/roles/ci-explainer.yaml -p "Analyze the build failure in /tmp/build.log and /tmp/test.log"

# macOS
initrunner run examples/roles/changelog-slack.yaml -p "Last 10 commits" 2>/dev/null | pbcopy

# Linux (X11)
initrunner run examples/roles/changelog-slack.yaml -p "Last 10 commits" 2>/dev/null | xclip -selection clipboard

# Linux (Wayland)
initrunner run examples/roles/changelog-slack.yaml -p "Last 10 commits" 2>/dev/null | wl-copy

alias pr-review='initrunner run examples/roles/pr-reviewer.yaml -p'
alias changelog='initrunner run examples/roles/changelog-slack.yaml -p'
alias ci-explain='initrunner run examples/roles/ci-explainer.yaml -p'

# Then:
pr-review "Review changes vs main"
changelog "Changelog since v1.0.0"
ci-explain "Explain /tmp/build.log"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: thinker
  description: An agent that reasons step-by-step with self-critique
  tags:
  - example
  - think
  - reasoning
  author: InitRunner Team
  version: "2.0.0"
spec:
  role: >
    You are a careful, methodical assistant. Before answering any question
    or taking any action, always use the think tool to reason step-by-step.
    Break down complex problems, consider edge cases, and plan your approach
    before responding. Use the datetime tool when time-related information
    is needed.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.3
    max_tokens: 2048
  tools:
  - type: think
    critique: true
    max_thoughts: 30
  - type: datetime
    default_timezone: UTC
  guardrails:
    max_tokens_per_run: 10000
    max_tool_calls: 20
    timeout_seconds: 60

initrunner run thinker.yaml -p "What day of the week will January 1, 2030 fall on?"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: reasoning-planner
  description: Structured planner with think + todo tools
  tags:
    - example
    - reasoning
    - planning
    - autonomous
  author: InitRunner Team
  version: "1.0.0"
spec:
  role: |
    You are a senior project planner. Break tasks into structured
    todo lists, research each item, and synthesize findings.
    Use the think tool to reason about each item before working on it.
  model:
    provider: openai
    name: gpt-5-mini
  tools:
    - type: think
      critique: true
    - type: todo
      max_items: 20
    - type: search
      provider: duckduckgo
  reasoning:
    pattern: todo_driven
    auto_plan: true
  autonomy:
    max_plan_steps: 20
  guardrails:
    max_iterations: 15
    autonomous_token_budget: 100000

initrunner run reasoning-planner/ -a -p "Research the top 3 Python web frameworks and compare them"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: research-team
  description: Multi-agent research coordinator with parallel sub-agents
  tags:
    - example
    - reasoning
    - spawn
    - multi-agent
  author: InitRunner Team
  version: "1.0.0"
spec:
  role: |
    You are a research lead. Given a topic:
    1. Break it into research questions (todo list)
    2. Spawn researchers for parallelizable questions
    3. Await their results
    4. Synthesize findings into a structured report
  model:
    provider: openai
    name: gpt-5-mini
  tools:
    - type: think
      critique: true
    - type: todo
      max_items: 15
    - type: spawn
      max_concurrent: 3
      agents:
        - name: web-researcher
          role_file: ./agents/web-researcher.yaml
          description: Searches the web and summarizes findings
    - type: filesystem
      root_path: ./output
      read_only: false
  reasoning:
    pattern: todo_driven
    auto_plan: true
  autonomy:
    max_plan_steps: 15
  guardrails:
    max_iterations: 15
    autonomous_token_budget: 100000

initrunner run research-team/ -a -p "Compare the top 3 vector databases for production RAG systems"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: self-correcting-writer
  description: Writer with reflexion-based self-critique
  tags:
    - example
    - reasoning
    - reflexion
    - writing
  author: InitRunner Team
  version: "1.0.0"
spec:
  role: |
    You are a technical writer. Given a topic, produce a well-structured
    article with clear explanations and examples. After completing your
    draft, critically evaluate it for accuracy, clarity, and completeness.
  model:
    provider: openai
    name: gpt-5-mini
  tools:
    - type: think
      critique: true
    - type: todo
    - type: filesystem
      root_path: ./output
      read_only: false
    - type: search
      provider: duckduckgo
  reasoning:
    pattern: todo_driven
    auto_plan: true
    reflection_rounds: 1
  autonomy:
    max_plan_steps: 10
  guardrails:
    max_iterations: 12
    autonomous_token_budget: 80000

initrunner run self-correcting-writer/ -a -p "Write a guide on WebAssembly for backend developers"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: script-runner
  description: A sysadmin agent with inline script tools
  tags:
  - example
  - script
  - sysadmin
  author: InitRunner Team
  version: "1.0.0"
spec:
  role: >
    You are a system administrator assistant. Use the provided script tools
    to inspect disk usage, count files, and gather system information.
    Report results clearly and suggest actions when thresholds are exceeded.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.2
    max_tokens: 2048
  tools:
  - type: script
    timeout_seconds: 15
    scripts:
    - name: disk_usage
      description: Check disk usage for a path
      interpreter: /bin/bash
      allowed_commands: [df]
      body: |
        df -h "$TARGET_PATH"
      parameters:
      - name: target_path
        description: Filesystem path to check
        required: true
    - name: count_files
      description: Count files in a directory (returns the count)
      interpreter: /bin/bash
      body: |
        count=$(find "$DIR" -type f 2>/dev/null | wc -l)
        echo "$count files found in $DIR"
      parameters:
      - name: dir
        description: Directory path
        required: true
    - name: system_info
      description: Show basic system information
      interpreter: /bin/bash
      body: |
        echo "Hostname: $(hostname)"
        echo "Kernel: $(uname -r)"
        echo "Uptime: $(uptime -p 2>/dev/null || uptime)"
        echo "Memory:"
        free -h 2>/dev/null || echo "free not available"
  guardrails:
    max_tokens_per_run: 10000
    max_tool_calls: 10
    timeout_seconds: 60

initrunner run script-runner.yaml -p "Check disk usage on / and report system info"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: long-running-analyst
  description: Autonomous research analyst with conversation history compaction
  tags:
    - example
    - autonomous
    - compaction
    - research
spec:
  role: |
    You are a research analyst. Given a topic, methodically gather information from
    multiple sources, synthesise findings, and produce a structured report.

    Workflow:
    1. Use batch_add_todos to outline your research steps — one item per source or angle
    2. Use get_next_todo to pick the next item
    3. Use http_request to fetch data from each source
    4. Use get_current_time to timestamp your report
    5. Summarise each source's key findings via update_todo notes
    6. When all sources are processed, write the final report to ./reports/ using write_file
    7. Call finish_task with a one-paragraph executive summary

    Guidelines:
    - Focus on facts and cite sources
    - If a source is unreachable, mark the item failed and move on
    - Keep intermediate notes brief — history compaction will summarise older context
    - Final report format: title, date, executive summary, per-source sections, conclusion
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.2
  tools:
    - type: http
      base_url: https://api.example.com
      allowed_methods:
        - GET
      headers:
        Accept: application/json
    - type: filesystem
      root_path: ./reports
      read_only: false
    - type: datetime
    - type: think
    - type: todo
      max_items: 15
  reasoning:
    pattern: todo_driven
    auto_plan: true
  autonomy:
    max_history_messages: 30
    max_plan_steps: 10
    iteration_delay_seconds: 1
    compaction:
      enabled: true
      threshold: 15
      tail_messages: 4
      model_override: "openai:gpt-4o-mini"
  guardrails:
    max_iterations: 20
    autonomous_token_budget: 120000
    max_tokens_per_run: 15000
    max_tool_calls: 40
    session_token_budget: 250000

initrunner run long-running-analyst.yaml -a \
  -p "Research the current state of WebAssembly adoption in production environments"

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: ops-heartbeat
  description: Periodic ops agent that processes an open-tasks checklist via heartbeat trigger
  tags:
    - example
    - heartbeat
    - ops
    - shell
    - slack
spec:
  role: |
    You are an operations assistant. Each time you are triggered you receive an
    updated task checklist. Work through every incomplete item using shell commands
    and mark them done.

    Workflow:
    1. Read through all unchecked items (lines starting with "- [ ]")
    2. For each item, run the appropriate shell command to perform the check
    3. Report pass/fail per item to the #ops-alerts Slack channel
    4. If a check fails, include the relevant error output in your Slack message

    Rules:
    - Never modify production resources — only read / inspect
    - If a command times out, report it as "timed out" and move to the next item
    - At the end, post a summary: items checked, passed, failed
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.0
  tools:
    - type: shell
      allowed_commands:
        - curl
        - ping
        - dig
        - df
        - free
        - uptime
        - systemctl
      require_confirmation: false
      timeout_seconds: 30
    - type: slack
      webhook_url: "${SLACK_WEBHOOK_URL}"
      default_channel: "#ops-alerts"
      username: Ops Heartbeat
      icon_emoji: ":heartbeat:"
    - type: datetime
  triggers:
    - type: heartbeat
      file: ./ops-checklist.md
      interval_seconds: 3600
      active_hours: [8, 18]
      timezone: America/New_York
  guardrails:
    max_tokens_per_run: 20000
    max_tool_calls: 25
    timeout_seconds: 180
    max_request_limit: 30

# Ops Checklist

## Infrastructure

- [ ] Check disk usage on /data (alert if > 80%)
- [ ] Verify DNS resolution for api.example.com
- [ ] Ping gateway 10.0.0.1 (alert if packet loss > 0%)
- [ ] Confirm NTP sync — `systemctl status chronyd`

## Services

- [ ] Curl health endpoint https://api.example.com/health (expect 200)
- [ ] Curl metrics endpoint https://api.example.com/metrics (expect 200)
- [ ] Check available memory (alert if free < 512 MB)

initrunner run ops-heartbeat.yaml --daemon

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: reloadable-assistant
  description: Slack daemon with hot-reload — edit YAML, see changes live
  tags:
    - example
    - daemon
    - hot-reload
    - slack
    - cron
spec:
  role: |
    You are a team assistant running as a long-lived daemon. You respond to Slack
    messages and run periodic summaries on a cron schedule.

    Responsibilities:
    1. Answer questions from the team in Slack
    2. Every four hours, summarise recent activity and post to #team-updates
    3. Use shell commands to gather system metrics when asked

    Tone: concise, friendly, and professional. Prefer bullet points over prose.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.3
    max_tokens: 4096
  tools:
    - type: slack
      webhook_url: "${SLACK_WEBHOOK_URL}"
      default_channel: "#team-updates"
      username: Team Assistant
      icon_emoji: ":robot_face:"
    - type: shell
      allowed_commands:
        - uptime
        - df
        - free
        - date
      require_confirmation: false
      timeout_seconds: 15
    - type: datetime
  triggers:
    - type: cron
      schedule: "0 */4 * * *"
      prompt: "Summarise recent activity and post a status update to Slack."
      timezone: UTC
  daemon:
    hot_reload: true
    reload_debounce_seconds: 2.0
  guardrails:
    max_tokens_per_run: 20000
    max_tool_calls: 15
    timeout_seconds: 120
    max_request_limit: 20
    daemon_token_budget: 500000
    daemon_daily_token_budget: 200000

initrunner run reloadable-assistant.yaml --daemon

# flow.yaml
apiVersion: initrunner/v1
kind: Flow
metadata:
  name: support-desk
  description: Support desk with auto-routing
spec:
  agents:
    intake:
      role: roles/intake.yaml
      sink:
        type: delegate
        strategy: sense
        target:
          - researcher
          - responder
          - escalator

    researcher:
      role: roles/researcher.yaml
      needs: [intake]

    responder:
      role: roles/responder.yaml
      needs: [intake]
      restart: { condition: on-failure, max_retries: 3, delay_seconds: 5 }

    escalator:
      role: roles/escalator.yaml
      needs: [intake]

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: intake
  description: Receives support requests and summarizes them for triage
  tags:
    - support
    - intake
spec:
  role: >
    You are a support intake agent. When you receive a support request,
    produce a concise summary including: the customer's issue, urgency
    level, and the type of action needed (research, direct response,
    or human escalation). Be factual and brief.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.1
  guardrails:
    max_tokens_per_run: 1000
    timeout_seconds: 30

apiVersion: initrunner/v1
kind: Agent
metadata:
  name: researcher
  description: Investigates technical issues and gathers diagnostic information
  tags:
    - research
    - analysis
    - investigation
    - technical
    - diagnose
spec:
  role: >
    You are a technical research agent for a support desk. When you
    receive a triaged support request that requires investigation,
    research the issue thoroughly. Produce a structured report with:
    root cause analysis, relevant documentation references, and
    recommended resolution steps.
  model:
    provider: openai
    name: gpt-5-mini
    temperature: 0.3
  guardrails:
    max_tokens_per_run: 4000
    timeout_seconds: 60

initrunner flow up flow.yaml