Agent Instructions

# Agent Status Reporting Instructions

## Overview

This document is intended for development-focused AI agents such as Cursor, Codex, and Claude Code.

Always send structured system status updates to the bunny.fyi status API while monitoring this service, system, pipeline, job, or automation. You may send updates even if no new task has started.

Reporting mode: System Status

Use this mode when you are reporting the ongoing state of a service, system, bot, crawler, deployment, or pipeline.

## Important rules

- Never send the example payload unchanged.
- Always replace example values with real values from the current monitored system, service, pipeline, job, or automation.
- Do not send a status update just to confirm that you read these instructions.
- Generate a fresh current ISO timestamp for every update.
- Use `complete` only when you are reporting a monitored run, pipeline, or job that has actually finished.
- Choose identifiers carefully:
  - `projectId`: the real current product, system, or environment name
  - `agentId`: the actual agent you are running as, such as `cursor`, `codex`, or `claude_code`
  - `subjectId`: the real monitored service, system, pipeline, deployment, crawler, bot, or job identifier

## When to send updates

Send an update:
- periodically while the system is being monitored, for example every few minutes
- when the monitored system enters a new health state
- when key metrics materially change
- immediately when warnings or failures appear
- when a degraded or failed system returns to healthy status

## API endpoint

https://www.bunny.fyi/api/records

## Authentication

Use this API key:

test_agent_key_local_123

Send the key in either of these ways:
- Authorization: Bearer test_agent_key_local_123
- x-api-key: test_agent_key_local_123

## Payload example

Send POST requests with JSON payloads similar to the example below.
Fields may be omitted if they are not relevant.

{
  "projectId": "<current-product-or-environment-name>",
  "agentId": "<current-agent-name>",
  "subjectId": "<current-service-or-crawler-id>",
  "subjectType": "<service|system|pipeline|job|deployment|crawler|bot>",
  "title": "<short monitored system title>",
  "summary": "<short health or operating-state summary for humans viewing the dashboard>",
  "status": "healthy",
  "viewType": "status_card",
  "timestamp": "<current-iso-timestamp>",
  "data": {
    "notes": [
      "<important health or state note>",
      "<optional metric or warning note>"
    ],
    "staleAfterMinutes": 60,
    "checks": [
      { "label": "Last crawl", "value": "running normally", "status": "healthy" },
      { "label": "Queue depth", "value": "18 pending", "status": "healthy" }
    ]
  }
}

## Recommended status values

- healthy for normal operation
- warning for degraded operation or partial issues
- failed for incidents, outages, or hard failures
- in_progress for rollouts, syncs, or transitional activity

## Recommended view types

- status_card for current operating status
- metric_grid for health indicators and headline metrics
- table for structured operational rows
- log_stream for execution output or diagnostic logs
- alert for high-signal failures or urgent warnings

## Identifier guidance

`subjectType` should describe the monitored entity, such as `service`, `system`, `pipeline`, `job`, `deployment`, `crawler`, or `bot`.

## Example data shapes

### status_card

{
  "notes": [
    "Started implementation",
    "Auth helper completed"
  ],
  "checks": [
    { "label": "API auth", "value": "done", "status": "complete" },
    { "label": "Instructions page", "value": "in progress", "status": "in_progress" }
  ],
  "staleAfterMinutes": 120
}

### timeline

{
  "events": [
    {
      "at": "2026-03-14T10:00:00.000Z",
      "label": "Work started",
      "description": "Initial implementation began."
    },
    {
      "at": "2026-03-14T10:30:00.000Z",
      "label": "Milestone complete",
      "description": "API authentication check was added."
    }
  ]
}

### metric_grid

{
  "metrics": [
    { "label": "Files changed", "value": 12, "unit": "" },
    { "label": "Tests passing", "value": 24, "unit": "" },
    { "label": "Coverage", "value": 87, "unit": "%" }
  ],
  "highlights": [
    "Core implementation is complete.",
    "One follow-up check remains."
  ]
}

### log_stream

{
  "lines": [
    {
      "at": "2026-03-14T10:05:00.000Z",
      "level": "info",
      "message": "Fetching current route files."
    },
    {
      "at": "2026-03-14T10:06:00.000Z",
      "level": "warn",
      "message": "Build retry required after import error."
    }
  ]
}

### table

{
  "columns": [
    { "key": "step", "label": "Step" },
    { "key": "owner", "label": "Owner" },
    { "key": "state", "label": "State" }
  ],
  "rows": [
    { "step": "Auth helper", "owner": "codex", "state": "complete" },
    { "step": "Instructions page", "owner": "codex", "state": "in_progress" }
  ]
}

### checklist

{
  "items": [
    {
      "label": "Define API key config",
      "description": "Shared config exported for page and backend.",
      "checked": true,
      "status": "complete"
    },
    {
      "label": "Build instructions page",
      "description": "Visible page and copy button still in progress.",
      "checked": false,
      "status": "in_progress"
    }
  ]
}

### alert

{
  "severity": "failed",
  "alerts": [
    {
      "title": "Build failed",
      "description": "Type error detected in the API route.",
      "source": "build",
      "code": "TS_BUILD_ERROR"
    }
  ]
}

## Guidelines

- Keep every update short and clear.
- Write updates so a human can understand progress quickly from the dashboard.
- Focus on progress and state instead of deep code details.
- Prefer meaningful milestone updates over noisy low-value chatter.