kent-dogfooding

name	kent-dogfooding
description	How to use `kent` cli to change your behavior, environment, config, or debug issues. Read when the user asks you to use/manage a worktree, set a goal, change Kent config.toml/settings/behavior/hooks/subagents, or to debug project/workspace/worktree/workflow errors.

Kent is the harness you are running inside, but it's also a server that runs agentic loops, a TUI, and a CLI.

Source-of-truth for commands and public docs:

• Run kent --help and kent <command> --help for exact current CLI flags.
• Full docs index: https://kent.sh/llms.txt.

You can directly curl -S each of the docs pages with an .md postfix to get its content. Avoid using web fetch tools on those.

Projects And Workspace Bindings

Kent tracks projects and workspace roots so sessions can move across checkouts and remote/local server boundaries. If your subagent commands fail with errors about workspace binding or projects, simply attach a workspace folder where you want to run the subagent to the project where you are running:

$ kent attach <path/to/subagent/workspace>

More info in --help.

Worktrees

Kent can dynamically manage your worktrees: setting it up for you, running hooks, and changing your CWD, so prefer kent worktree commands to plain git worktree. Prefer entering a worktree rather than constantly supplying paths to your edit tool or cds for shell commands. Enter worktrees as needed for your coding work, for example when the user wants to make a new branch.

kent worktree status
kent worktree list
kent worktree create <branch-or-ref> [path] # make a kent-tracked worktree
kent worktree enter <selector> # teleport yourself along with your CWD to a worktree
kent worktree leave # teleport yourself to the main worktree
kent worktree delete <selector>

Use --force only when the user explicitly authorizes removing a dirty or indeterminate worktree folder. Worktree setup scripts prepare new checkouts with local files, credentials, symlinks, or dependencies. Read the setup contract at https://kent.sh/worktrees.md.

Config Locations

Global config (applies to all projects) ~/.kent/config.toml (%USERPROFILE%\.kent\ on Windows), local config is at <workspace-root>/.kent/config.toml. Workspace root is usually your cwd, or your worktree's main workspace cwd. Config schema and full notes at https://kent.sh/config.md. The database and session logs that kent uses are colocated with the config file. Session logs are .json files with a full history of events, split per-project. Careful: session logs are very long and can weigh gigabytes.

• Do not write directly to the live metadata database for normal operations. Manual edits can bypass Kent's invariants and leave the database inconsistent; use first-party CLI, API, or store operations instead.
• If Kent cannot perform an operation without direct database edits, file an issue. Carefully repairing an already-corrupted database is the only valid exception.
• Treat workflow deletion as high impact because it cascades through the workflow's links, tasks, and graph. Review the deletion preview before confirming.

Runtime logs live under the persistence root (default ~/.kent; override with $KENT_PERSISTENCE_ROOT):

• Desktop: <persistence-root>/gui/desktop.log.
• CLI: <persistence-root>/logs/tui.log.
• Server: <persistence-root>/logs/server.log and <persistence-root>/logs/server.err.log; kent service status prints the exact paths.

Most behavior changes you make affect only new sessions and only after server restart. Existing sessions will keep captured conversation logs and settings. After changing config, ask the user to restart the service with kent service restart, restart the Kent GUI, and then start a new session, for changes to apply.

Important: do not make changes to your configuration that were not authorized or directly asked for by the user. If your environment is buggy/broken, ask the user for help instead of messing with your internals.

Change Agent Behavior

Use prompt files for broad behavior changes, skills for reusable on-demand workflows, and subagent roles for specialized headless agents. Start by reading docs at https://kent.sh/prompts.md

Note that you shouldn't be rewriting main agent's system prompt: the output can be biased and low-quality. System prompts need to be crafted carefully and vary strongly per LLM model family and use-case. Either the user should supply an existing prompt they want to use, or use {{.DefaultSystemPrompt}} for sane defaults, and add additional instructions to it.

Subagent roles

User may ask you to define new "subagents" or "agent roles". Subagents are kent run commands you call. You can also use them for scripting of user's kent-based workflows. More info at kent run --help and https://kent.sh/headless.md.

Shell Postprocess Hooks

Kent can post-process shell command output before you see it. Hook shape, output, and config are at https://kent.sh/command-postprocessing.md

You can disable this feature with raw=true in your exec_command tool. This hook is intended to optimize, shrink, or log the commands that you run. For example, a user may want you to use a tool that makes outputs smaller. Kent also ships embedded optimizers (builtin mode toggle) out of the box.

Goals

The user can set you a goal, or you may set a goal for yourself at will by running kent goal set "<objective>". This goal will nudge you and all future agents across handoffs to work on a shared objective until completion. You should proactively set goals for yourself for larger tasks (this is encouraged) that might take multiple handoffs to complete. Goal text is a .md-formatted clear and exhaustive description of what needs to be done. Provide paths to relevant context: plan/doc files, checklists, etc., clear Definition of Done, and measurable explicit completion criteria, in the goal text.

Assume the agents that will read your goal text will know nothing about this conversation or session. Avoid assigning subtasks, phases of a larger plan, or implementation slices, as goals - instead, assign the overall task as a goal and keep a file-based worklog or checklist. If you are blocked and unable to complete your goal, ask the User a question to summon them to help you.

Bug Reports

File Kent bugs in respawn-llc/kent with gh issue create --repo respawn-llc/kent.

Include the observed and expected behavior, minimal reproduction steps, Kent version, operating system, and relevant redacted log excerpts. Do not attach full logs or secrets.

Every ticket must include this exact line:

Filed by Kent on behalf of the user

For suspected security vulnerabilities, follow the repository's SECURITY.md instead of filing a public issue.