Critique Intake

Critique Intake turns messy user reports into investigated engineering packets. It is not the same as the public Feedback page, which sends product feedback to the Critique team. Intake is for your application: users report a bug, Critique asks a focused follow-up, captures technical context, classifies the issue, and prepares work your team can route into Builder, Review runs, GitHub issues, Linear, or the Merge Gate API loop.

For the market positioning, why this exists, and how it compares with feedback tools such as Usersnap, Sentry User Feedback, and Marker.io, read the launch essay: Critique Intake: Feedback That Arrives Already Debugged.

Who it is for

How it works

flowchart LR
  User[User reports issue] --> Clarify[One focused follow-up]
  Clarify --> Context[URL browser errors requests actions]
  Context --> Triage[Type severity owner confidence]
  Triage --> Inbox[Dashboard Intake]
  Inbox --> Work[Builder GitHub Linear or agent prompt]
  Work --> Review[Review runs]
  Review --> Passport[Change Passport]

1. Capture — install the widget in a web app. It records the user report, page URL, user agent, viewport, recent clicks, console errors, and failed fetch requests.
2. Clarify — the widget asks one follow-up question based on the report. The goal is to collect the missing detail without making users fill out a long form.
3. Investigate — the API classifies the report, estimates severity, assigns a likely owner, extracts evidence, and writes a Critique run prompt.
4. Handoff — operators review the packet in Dashboard → Intake, copy the generated prompt, queue agent work, or create an issue in the team’s tracker.
5. Control — when that work becomes a PR, use Review runs, Change Passports, and the Merge Gate API to decide whether the fix can ship.

Install the widget

<script
  src="https://critique.sh/intake/widget.js"
  data-project-id="PROJECT_ID"
  async></script>

For local development against a non-production Critique instance, override the endpoint:

<script
  src="http://localhost:3000/intake/widget.js"
  data-project-id="local-demo"
  data-endpoint="http://localhost:3000/api/intake/report"
  async></script>

The widget exposes a floating Report issue button. You can change the label with data-label="Send bug report".

Captured context

The MVP captures lightweight browser context:

Screenshots, session replay, source-map expansion, log correlation, and external ticket creation are later layers. The current implementation focuses on a reliable, low-friction packet that already beats a raw feedback form.

API

Submit a report:

curl https://critique.sh/api/intake/report \
  -H "Content-Type: application/json" \
  -d '{
    "projectId": "acme-web",
    "reporterEmail": "customer@example.com",
    "message": "The invoice download is broken",
    "followUpAnswer": "It shows an error every time.",
    "context": {
      "pageUrl": "https://app.example.com/billing/invoices",
      "viewport": "1440x900",
      "consoleErrors": ["Failed to fetch PDF"],
      "networkFailures": ["GET /api/invoices/928/download 500"],
      "clickTrail": ["Billing", "Invoice #928", "Download PDF"]
    }
  }'

The response includes an id and triage object:

{
  "ok": true,
  "id": "clx...",
  "triage": {
    "category": "billing_account",
    "severity": "high",
    "confidence": 82,
    "suggestedOwner": "Billing",
    "critiqueRunPrompt": "User reported: The invoice download is broken..."
  }
}

Authenticated users can read their reports from GET /api/intake/reports. The Dashboard uses the same route.

Dashboard workflow

Open Dashboard → Intake. Each report shows:

• reporter and project id,
• type, severity, status, and confidence,
• likely issue and suggested owner,
• captured evidence,
• reproduction steps,
• an agent-ready Critique prompt,
• statuses: investigated, queued, resolved, and ignored.

Use Copy prompt when you want to paste the packet into Builder, Workspace, Codex, Claude Code, Cursor, or a GitHub issue. Use Queue when the report is ready for engineering work.

How it works with the rest of Critique

Naming

Use Critique Intake for the product surface. Use agentic bug intake as the category phrase. Avoid calling it only “feedback,” because Critique already has a /feedback route for product feedback sent to the Critique team.

Current limits

• The widget captures browser metadata and failed fetch calls, not full network HAR files.
• Triage is deterministic and fast. It does not run a model by default.
• The Dashboard shows reports owned by the signed-in user. Production project ownership and install tokens can be added as a later hardening layer.
• Creating Linear, GitHub, Jira, or Slack tickets is intentionally separate from capture. Connect those workflows through Connections & Platform API or your existing automation.