LatentCodeGet started
Common workflows
Prompts and commands for everyday tasks: understanding code, fixing bugs, testing, reviewing and working with git.
Understand a codebase
Switch to Plan (tab) so nothing changes while you explore, then start broad and narrow down:
> Give me a tour of this repository: the main components, how a request flows through them, and where the tests live.
> How does authentication work? Point me to the files involved.
> @src/billing/invoice.ts why does finalize() lock the account row?- Reference files with
@so the agent starts from the right place.@file#10-40narrows it to lines. - For wide searches, the agent hands work to the
exploresubagent. Ask for it directly with@explore. - Once you understand the project,
/initwrites what you learned intoAGENTS.md.
Fix a bug
/bug-fix Uploading a CSV with a BOM fails with "unknown column id"/bug-fix sets a goal: find the root cause, make the smallest fix, add a regression test and run the tests. The agent keeps going until that's done or it needs you. Give it everything you have: the error, the stack trace, steps to reproduce. Paste a screenshot with ctrl+v, or run the failing command yourself with ! so the output is in the conversation:
! pnpm vitest run src/import/csv.test.tsWrite tests
> Write tests for @src/pricing/discounts.ts. Follow the style of the existing tests in src/pricing/.
Cover the edge cases: zero quantity, stacked discounts, expired codes. Run them and make sure they pass.Say which framework and which existing tests to imitate, and ask it to run them. If your test command isn't obvious, put it in AGENTS.md.
Refactor safely
- Plan first in Plan, and agree on the approach before switching to Build.
- Ask for small steps and a test run after each. Check them with
/diff, and use/undoto back out one that went wrong. - For large changes,
/forkthe session to try an alternative without losing the first attempt.
Review changes
/review # uncommitted changes, including untracked files
/review branch main # this branch compared with main
/review commit 4f2a9c1 # one commit
/review pr 212 tests errors # a GitHub pull request, only the tests and error-handling aspects/review runs specialist reviewers in parallel, each on one aspect (code, errors, tests, types, comments, simplify), and reports what they find. It doesn't change anything; ask for fixes afterwards. Pull requests are fetched from your git remote, so this needs a GitHub repository.
/diff shows the same changes for your own review. See The diff viewer.
Work with git and pull requests
Commits and branches
Ask in plain language: commit this with a descriptive message, create a branch for this fix. Git commands that change the repository ask for approval by default, and pushes, rebases and hard resets are treated as dangerous and ask even in the Auto agent. See Permissions.
Pick up a pull request
latentcode pr 212Checks out pull request 212 into a branch named pr/212 and opens LatentCode on it, ready for questions or fixes. It uses the GitHub CLI, which must be installed and logged in.
Run it in scripts and CI
latentcode run sends one prompt and prints the answer, then exits. In CI, connect with an API key stored as a secret, and allow only what the job needs:
latentcode config set base-url https://latentstack.dev/v1
latentcode config set api-key "$LS_API_KEY"
export LATENTCODE_PERMISSION='{"edit":"deny","bash":{"*":"deny","git diff*":"allow","git log*":"allow"}}'
git diff origin/main...HEAD | latentcode run --agent plan --format json \
"Review this diff for bugs and security problems. Reply with a markdown list." > review.jsonlrun. Either allow it in config, as above, or pass --auto inside a disposable environment such as a CI container.See the run reference for every flag and the JSON event format.