> ## Documentation Index > Fetch the complete documentation index at: https://docs.heylua.ai/llms.txt > Use this file to discover all available pages before exploring further. # lua.skill.yaml > The project state manifest: every key, which command writes it, and what happens when you edit it by hand `lua.skill.yaml` is the state manifest at the root of a project. It records which [agent](/concepts/agents) the project is bound to and the server id and current version of every primitive the CLI has compiled or pushed. It holds no configuration: the persona, model, tools, and schedules live in `src/`. `lua init` creates the file, `lua compile`, `lua push`, `lua sync`, and `lua deploy` rewrite it, and only the `template:` section is written by you. *Verified against lua-cli 3.33.0.* ## Example After a compile and a push of one skill, one webhook, and two processors the file looks like this: ```yaml lua.skill.yaml theme={null} agent: agentId: agent_abc123 orgId: org_abc123 skills: - name: tickets skillId: skill_abc123 version: 1.0.3 webhooks: - name: ticket-status-webhook version: 1.0.3 webhookId: webhook_abc123 jobs: [] preprocessors: - name: pii-redaction preprocessorId: preprocessor_abc123 version: 1.0.3 postprocessors: - name: ticket-footer postprocessorId: postprocessor_abc123 version: 1.0.3 mcpServers: [] backup: activeVersion: 3 lastHash: 8198f4f371f01a496147ec72b4cfcbc208aa0242803167d56c20323117d1af47 lastPushedAt: '2026-09-12T12:49:51.474Z' workflows: [] ``` Keys are written in a fixed order: `agent`, `skills`, `webhooks`, `jobs`, `preprocessors`, `postprocessors`, `mcpServers`, `template`, `skill`, then the remaining keys alphabetically. ## Keys | Key | Written by | Contents | | --------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `agent` | `lua init` | `agentId` and `orgId` of the bound agent | | `skills` | compile, push, sync | One row per [skill](/concepts/skills-and-tools): `name`, `version`, `skillId` | | `webhooks` | compile, push, sync | `name`, `version`, `webhookId` | | `triggers` | compile, push, sync | `name`, `version`, `triggerId` | | `jobs` | compile, push, sync | `name`, `version`, `jobId` | | `workflows` | compile, `lua push workflow` | `name`, `version`, `workflowId` | | `preprocessors`, `postprocessors` | compile, push, sync | `name`, `version`, `preprocessorId` or `postprocessorId` | | `mcpServers` | push, sync | `name`, `mcpServerId`; MCP servers have no version | | `devices`, `deviceTriggers` | compile, push, sync | `name`, `version`, `deviceId` or `deviceTriggerId` | | `voices` | compile, push, sync | `name`, `version`, `voiceId` | | `backup` | push, `lua init` restore | `lastHash`, `lastPushedAt`, and `activeVersion` of the source backup | | `git` | `lua git connect`, `lua git disconnect` | `enabled`, `autoPush` | | `template` | you | [Agent template](/concepts/agent-templates) sections: `connections`, `personaTemplate`, `triggerPresets`, `paramsMeta`, `onInstall`, `onUninstall`, `installPolicy` | | `skill` | legacy | Single-skill format of old projects, read only when `skills` is empty | A row is written with exactly `name`, `version`, and its id field. Any other key on a row is dropped the next time the CLI writes the file. ## Writes by the CLI * `lua compile` adds a row for every primitive reachable from the `LuaAgent` in `src/index.ts`, with `version: 1.0.0` and an empty id for a new one, and removes rows whose primitive is no longer in the code, as long as at least one primitive of that kind remains. It never writes server ids and sends nothing to the server. * `lua push` and `lua sync` reconcile with the server: they register primitives that have no id yet and write the returned id, link a row whose name already exists on the server, set `version` to the server's active version when the two differ, and add a row for any primitive that exists on the server but not in your code, with a `Found … on server not in your local code` message. * A push then writes the version it pushed; `lua deploy` writes the version it made live. * Every push except `lua push agent` ends with a source backup and updates `backup`. ## Hand edits The file is safe to commit. Editing it is rarely needed, and these are the effects: * Changing `version`: overwritten by the server's active version the next time the CLI reconciles. To push a specific version use `lua push --set-version `; to bump automatically use `--force`. * Deleting an id line: the next `lua push` or `lua sync` links the row to the server entity with the same name, or registers a new one when none exists, and writes the id. This is the fix when the server entity was deleted and a push fails with `no longer exists on the server` (exit 3); for workflows the CLI clears a stale id itself. * Deleting a row: `lua compile` recreates it while the primitive is still in the code. * Removing a primitive from the code: its row disappears on compile, but the server copy stays and returns as a server-only row on the next push or sync until you delete it with that primitive's `delete` action, for example `lua webhooks delete`. * Changing `agentId` or `orgId`: use `lua init --agent-id --force` instead; it also updates the `LuaAgent` name and persona in `src/index.ts`. * Editing `backup` or `git`: the next push or `lua git connect` overwrites them. * Editing `template`: intended. Every section is sent on `lua marketplace template publish`; an absent section clears that part of the template rather than keeping the previous value. ## See also * [`lua compile`](/reference/cli/compile) and [`lua push`](/reference/cli/push) * [`lua sync`](/reference/cli/sync) — resolve drift between this file, your code, and the server * [Project structure](/get-started/project-structure) * [Agent templates](/concepts/agent-templates) — the `template:` section