| 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]
kent worktree enter <selector>
kent worktree leave
kent worktree delete <selector>
