LogBrew for agents

This page explains how agents should read LogBrew without needing browser state, hidden context, or private dashboard access.

Read Markdown
First safe read
logbrew status --json

Start with local status, then read logs, issues, actions, traces, releases, and projects only after auth and reachability are clear.

Agent task map

Use this order when an assistant is helping a developer set up LogBrew or read private signals.

  1. Step 1

    Read the public map

    Load the public route index before changing app code so the assistant starts from current LogBrew context.

    curl -L https://logbrew.co/llms.txt
    Use the linked Markdown mirrors for deeper public context.
  2. Step 2

    Choose the SDK card

    Read the SDK chooser before installing anything, then use Copy installation prompt in Add Project so the assistant follows the selected platform.

    curl -L https://logbrew.co/en/docs.md
    Ask the signed-in user to open Add Project, copy the installation prompt, and keep ingest credentials out of chat.
  3. Step 3

    Check local status

    Confirm API reachability and auth source before reading private projects, logs, issues, actions, traces, or releases.

    logbrew status --json
    Follow the token-safe next field instead of guessing.
  4. Step 4

    Verify the first signal

    After setup sends a safe SDK signal, read one scoped result and keep tokens, cookies, and project data out of prompts.

    logbrew logs info --json
    Use issue, action, trace, release, and project reads only after auth is ready.
AI assistant context

Give an agent the public LogBrew map before it edits your app or setup command.

curl -L https://logbrew.co/llms.txt
Read https://logbrew.co/llms.txt, then choose the matching SDK card at https://logbrew.co/en/docs#docs-sdk-choice-title. Use npm install @logbrew/sdk @logbrew/node only for a server-side Node.js service; for Next.js, React, iOS, Android, or React Native, use the selected card and Add Project prompt. Ask the signed-in user to open Add Project and place credentials only in the matching app environment. For server-side Node.js, the env var is LOGBREW_SERVER_API_KEY. Run node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs only for Node services, then verify with logbrew logs info --json. Do not ask for credentials in chat or commits.
Use predictable public URLs

Agents should find public LogBrew context through stable localized pages, Markdown mirrors, llms.txt, robots.txt, and sitemap.xml.

  • Use /en/agents.md when plain text is the safest input.
  • Use /en/docs.md for command and API route context.
  • Use /llms.txt to discover public agent-readable resources.
Start with token-safe status

The CLI should tell agents whether local auth, API reachability, and recovery steps are ready without exposing token material.

  • Run logbrew status --json before project reads.
  • Follow next steps from JSON and human output instead of guessing.
  • Keep token material out of prompts, logs, screenshots, and public pages.
Prefer resource-specific reads

Agents should read logs, issues, actions, traces, releases, and projects through the same resource vocabulary used by humans.

  • Use filters for release, environment, project, trace, severity, status, name, and user.
  • Use issue and trace detail routes when an identifier is known.
  • Use Markdown mirrors for public context and the authenticated API for private project data.
Keep private data behind auth

Public agent surfaces must stay readable, while dashboard and project data remain protected by backend auth and noindex metadata.

  • Do not scrape dashboard data without a valid user session.
  • Do not publish private project names, tokens, traces, or deployment details.
  • Use public pages for general learning and authenticated routes for scoped user data.