---
title: "Getting good results from Indent"
description: "Frame tasks well, give the right context, and set Indent up to get better at your work over time."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.indent.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting good results from Indent

The best way to work with Indent is to treat it like a capable colleague. Say what you want, give it
what it needs to get there, and check the result.

## Frame the task like a brief

Hand Indent a task the way you'd hand one to a teammate. State the outcome you want, not the
keystrokes to get there.

- **Lead with the goal.** "Add rate limiting to the public API so a single client can't exceed 100
  requests a minute" beats "edit the middleware file."
- **Name the constraints and edge cases that matter.** The config that can't change, the endpoint
  that must stay backward-compatible, the deadline behavior.
- **Say what "done" looks like.** Tests passing, a specific bug no longer reproducing, a number
  matching a known value.
- **Don't over-specify the approach.** Give the destination and let Indent find the path; step in if
  it heads the wrong way.

You don't have to get the framing perfect up front. Indent asks clarifying questions when something
is ambiguous, and you can redirect it mid-session.

## Give it the right context

Indent starts each session fresh. The context you provide, and the context you've set up in advance,
decide how well it does.

- **Attach what's relevant.** Paste a Sentry link, a stack trace, an error message, or a screenshot.
  You can attach up to 10 files or images to your prompts by drag-and-drop, paste, or the paperclip.

  ![The composer with an image and a file attached alongside a prompt](/images/composer-attachments.png)

- **Point at a real environment when the task needs your build.** A bare sandbox has your code but
  not your running application. When a task needs the app built, services up, or the UI exercised in
  a browser, start the session in an [environment](/getting-started/environments) so everything is
  ready from the first message. For a quick code edit or a question, a sandbox is enough.
- **Connect the systems the task touches** — [GitHub](/connecting/github),
  [databases](/connecting/databases), [Slack](/connecting/slack), [Datadog](/connecting/datadog),
  [Sentry](/connecting/sentry), and other [integrations](/connecting/mcp-servers) — so Indent can
  pull the evidence itself instead of asking you for it.

## Train Indent on your business, systems, and codebase

- **[AGENTS.md](/learning/agents-md) — standing repository instructions.** Commit an `AGENTS.md` at
  the repo root, or in a subdirectory for rules that apply to just that part of the tree. Put setup
  steps, architecture, conventions, testing, and deployment in it. Indent reads it in full at the
  start of every session that includes the repo.
- **[Skills](/learning/skills) — named, reusable procedures.** Commit a `SKILL.md` for a workflow
  too narrow for AGENTS.md but too costly to re-explain, like a deploy, a migration, or a release
  runbook. Indent pulls the matching skill in on its own when a task fits its description.
- **[Memories](/learning/memory) — what Indent learns as it works.** Indent records durable facts on
  its own, and you can tell it to remember or drop something directly. Memory carries across
  sessions and isn't tied to a repo, so it holds your preferences and cross-repository conventions.
  Correct Indent once and it records the correction.

The payoff: new sessions start already knowing your setup, your procedures, and your preferences, so
you brief Indent less each time and it repeats fewer mistakes.

## Review and verify the output

Indent shows its work: the files it read, the commands it ran, and the queries it wrote. That lets
you check its reasoning, not just its result.

![A run_query tool call showing the SQL Indent wrote and the rows it returned](/images/tool-query-panel.png)

![An inline diff of an edit Indent made to a file](/images/tool-diff-panel.png)

- **Read the diff, not just the summary.** Open the pull request and review the change as you would
  a teammate's.
- **Check the evidence behind a claim.** For an analysis, the SQL is inline with the results; for an
  incident, the logs and traces are in the transcript.
- **Redirect in the session** when the approach is off. A follow-up message steers the work without
  starting over. See [Troubleshooting](/working-with-indent/troubleshooting) when Indent gets stuck
  or a check keeps failing.

Source: https://docs.indent.com/working-with-indent/getting-good-results/index.mdx