Skip to main content
AI coding agents should use LogBrew as a read-first observability source. Start with stable JSON, gather release and trace context, then decide whether a code change is justified.
Use --json for every automated read. Human-readable output is for terminal browsing and can change for readability.

​
Read the public docs first

When an agent joins a LogBrew project, start from the public docs map before calling product APIs or changing code.
Use llms.txt as the website-owned agent entry point, then follow the linked docs page or Markdown mirror when you need exact command examples. Treat all example values as placeholders.

​
Ask the CLI for examples

When an agent needs current command examples, start with the built-in examples guide before composing a longer workflow.
The examples guide covers first-run checks, troubleshooting, live watch, and machine-readable workflows.

​
Set up SDK telemetry from the CLI

CLI v0.1.32 or newer can create a backend-owned project or issue a key for an existing project without dashboard interaction. Keep the flow short and safe.
1

Check approved account access

If authentication is missing, ask a human to run logbrew login. Do not start a new login when approved authentication already works.
2

Select or create the project securely

If the intended project already exists, do not create a duplicate:
Otherwise create the project and its first key:
Both commands change account state. The CLI creates the destination file with owner-only permissions before it reports success and never prints the key or its path. Repeat an ambiguous attempt only with the exact same command.
3

Inspect the setup plan and install

Use only the project-scoped key as SDK configuration. Do not substitute account or session authentication.
4

Send one info event

Follow the exact released Node.js snippet in the quickstart. Keep release and environment explicit, omit private data, then unset the SDK key variable.
5

Verify readiness and readback

​
Investigation loop

1

Check access and project state

projects setup records setup-observed state for an existing project. CLI v0.1.32 or newer reads and creates backend-owned projects and can issue a key for an existing project without duplicate project creation; logbrew setup --create-project is help only. usage is a read and does not calculate quota state locally. If authentication is missing, run logbrew login before continuing.
2

Find current unresolved issues

Start broad, then add release and environment filters.
3

Collect evidence before editing code

Treat issue details, trace spans, and related logs as the evidence set for the fix.
4

Check product actions when behavior changed

Actions help connect runtime signals to user-visible workflows.
5

Update issue status only after verification

Only mark an issue resolved after the change is shipped or otherwise verified by the team workflow.

​
Watch live events

Use live watch for active debugging sessions where new logs or issues may appear while the agent is testing a fix.
Use logbrew watch --json for all live events. Use logs, issues, or actions when the agent should follow one live stream type. Trace and span terms are detail-read workflows that require a trace ID, not watch resources. Severity filtering for watch is client-side today. Keep --severity error,critical in the command when the agent should focus on actionable live events. The stream reconnects after transient disconnects with backoff.

​
Reliable filters

​
Agent rules

  • Prefer --json and parse structured output.
  • Accept --json before or after a command, such as logbrew --json status and logbrew status --json.
  • Use logbrew status --json to detect missing auth. If auth is missing, ask a human to run logbrew login before continuing.
  • Expect JSON errors to include ok, error, message, and next.
  • Read before proposing code changes.
  • Keep release and environment filters explicit.
  • Use trace IDs to connect logs, spans, issues, and actions.
  • Do not expose stored auth material in logs, prompts, tickets, or summaries.
  • Do not use an account bearer token as SDK or ingest configuration.
  • Do not create local-only project, install, setup, or quota state.
  • Do not treat human-readable CLI output as an automation contract.