Layerz

View saved version →

---
name: business-plan
description: "Build or extend a business plan, a budget, a forecast or a three-statement model (P&L, balance sheet, cash flow) in Layerz; add assumptions, formulas, drivers, a dashboard; \"model this business\", \"build the BP\", \"add a hiring plan\". Reads the conventions first, lays out the structure the workspace expects, builds in one validated pass, keeps every stock as a rolling balance and the checks at zero, then edits incrementally."
license: MIT
metadata:
  layerz_version: "1.1.0"
  generated_by: "layerzlabs/layerz scripts/build-plugin-skills.ts, from the modeling guide"
---

# Layerz: Business plan

**Instruction priority.** Explicit instructions from the user in the conversation come first. Then the model's FINANCE.md and the workspace conventions: both come back as `conventions` in the results of `layerz_get_model`, `layerz_create_model`, `layerz_build_from_blueprint`, an unfiltered `layerz_read` and `layerz_get_conventions`. They describe this workspace and this model (currency, units, signs, depth, structure, who reads it) and override the defaults below. Your own skills and instructions keep their priority on how you work. This skill describes how the Layerz tools work and in which order; it states no fact about any business.

## When this applies

Build or extend a business plan, a budget, a forecast, a three-statement model; add assumptions, formulas, a dashboard; "model this", "build the BP".

## Sequence

1. Conventions first: `layerz_get_conventions { model_id }` (or `{ workspace_id }` for a new model). The workspace Context says what to build and how deep; the FINANCE.md says the model's currency, units, signs and structure. Every value the tools return is expressed in those conventions.
2. On an existing model, read before writing: `layerz_read` (structure, values) or `layerz_get_model` (full detail). `computable: false` is a broken graph: fix it first (skill `review-and-fix`).
3. Lay out the structure the Context asks for. A common one: an Assumptions section (every input, grouped), an Operations section (non-money drivers), the three statements, a dashboard. Statements never carry a typed number: inputs live in Assumptions, formulas in the statements.
4. Every stock (cash, debt, receivables, payables, fixed assets, equity, ARR, headcount) is a `balance` with an `opening_balance` and its flows attached as `callup` children; a flow that depends on the stock reads the previous period with the `_M-1` suffix. See the Stock-flow reference.
5. First build in one pass: `layerz_build_from_blueprint { apply_if_clean: true }`, items referencing each other by name. Nothing is written while there is an error; errors come back with a path: fix and send again. A large blueprint goes as a file (`layerz_create_upload_url`, then `file_id`).
6. `layerz_read { health: true }`. Every failing check is fixed before the model is handed over; a Balance check (Assets minus Liabilities and Equity) at 0 every period is the minimum.
7. In the same turn, `layerz_set_finance_md` (objective, structure of the three statements, conventions, open questions) and a `glyph` (`meta` op of `layerz_patch`).
8. Later changes go through `layerz_patch`: `replace` to swap an item (keeps its UID, its references and its presentation), `update` for a strict partial change, temp ids (`_rev`) to create and reference within one batch; read `map` before the next batch. Every write carries a `summary` in plain words.
9. Per-element series (by product, team member, cohort, debt tranche) are lists, not copies of items. See the Lists reference.
10. Hand over with the model's `url`, what changed and the assumptions taken.

## References

From the Layerz modeling guide (version 1.1.0; the whole guide: `layerz_get_conventions { include_guide: true }` or the `modeling-guide://reference` resource):

- [2. Structure: roles and hierarchy](references/02-structure-roles-and-hierarchy.md)
- [3. Building: blueprint vs patch](references/03-buil

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: monthly-close
description: "Monthly close in Layerz: import actuals from a ledger export, FEC, trial balance, bank or accounting export; map accounts to the model lines; resync a source; compare budget and actuals and comment the variances; pin the closed version. \"Close October\", \"import the ledger\", \"map these accounts\", \"budget vs actual\". Walks the upload, dry run, mapping loop and sync in the order the tools expect."
license: MIT
metadata:
  layerz_version: "1.1.0"
  generated_by: "layerzlabs/layerz scripts/build-plugin-skills.ts, from the modeling guide"
---

# Layerz: Monthly close

**Instruction priority.** Explicit instructions from the user in the conversation come first. Then the model's FINANCE.md and the workspace conventions: both come back as `conventions` in the results of `layerz_get_model`, `layerz_create_model`, `layerz_build_from_blueprint`, an unfiltered `layerz_read` and `layerz_get_conventions`. They describe this workspace and this model (currency, units, signs, depth, structure, who reads it) and override the defaults below. Your own skills and instructions keep their priority on how you work. This skill describes how the Layerz tools work and in which order; it states no fact about any business.

## When this applies

Monthly close, import actuals (a ledger export, FEC, trial balance, bank or accounting export), map accounts to the model's lines, resync a source, budget vs actual variances, "close October".

## Sequence

1. `layerz_get_conventions { model_id }` (signs, units, fiscal year, what the Context says about variances and comments), then `layerz_list_integrations { model_id }`: the sources already connected, each with its rows and rules.
2. New file: `layerz_create_upload_url { filename, size, content_type }`, PUT the bytes from the shell, then `layerz_import_branch { model_id, branch, file_id, dry_run: true, summary }`. Read `unmapped`, `overridden_items`, `validation_errors_new`, `suggested_replace_source`.
3. A new version of a file already imported: `file_id` + `replace_source_id`. A new exercise (next year's ledger): `file_id` + `rules_from_source_id` (the sibling source's rules classify it). Then commit the same call without `dry_run`.
4. Mapping loop until `unmapped` is empty: `layerz_list_transactions { connection_id }` or `layerz_list_mappings { include_coverage: true }`, then `layerz_manage_mapping { op: "set", source_id, rules: [...] }` (one call for the whole plan, `__ignore__` for rows that belong nowhere), then `layerz_manage_integration { op: "sync", connection_id }`. Ask before creating a P&L line for an account the model does not have.
5. `layerz_read { model_id, branch_id, health: true }` on the actuals branch: the balance check at 0, the cutover (`actuals_through`) where expected.
6. Variances: read budget (base) and actuals (branch) side by side with `layerz_read { branch_id }` (`vv` is branch minus base); comment the lines above the threshold the Context sets, as item notes through `layerz_patch`.
7. `layerz_diff { from }` to show what the close changed, then `layerz_manage_version { op: "pin", version, summary }` on the closed state ("October 2026 close").

Credentials for an accounting connector are entered in the web app, never through the tools.

## References

From the Layerz modeling guide (version 1.1.0; the whole guide: `layerz_get_conventions { include_guide: true }` or the `modeling-guide://reference` resource):

- [7. Branches, scenarios and actuals](references/07-branches-scenarios-and-actuals.md)
- [8. Sources and mapping rules](references/08-sources-and-mapping-rules.md)

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: review-and-fix
description: "Review and fix a Layerz model: a check fails, the balance sheet does not balance, \"the numbers are wrong\", a model is not computable, verify that a refactor changed nothing, compare two versions or an imported model with its source workbook, undo or restore, \"what changed since yesterday\". Reads health by branch, finds the cycle or the typed number, previews a patch before applying it, and uses history, diff and versions to prove or undo a change."
license: MIT
metadata:
  layerz_version: "1.1.0"
  generated_by: "layerzlabs/layerz scripts/build-plugin-skills.ts, from the modeling guide"
---

# Layerz: Review and fix

**Instruction priority.** Explicit instructions from the user in the conversation come first. Then the model's FINANCE.md and the workspace conventions: both come back as `conventions` in the results of `layerz_get_model`, `layerz_create_model`, `layerz_build_from_blueprint`, an unfiltered `layerz_read` and `layerz_get_conventions`. They describe this workspace and this model (currency, units, signs, depth, structure, who reads it) and override the defaults below. Your own skills and instructions keep their priority on how you work. This skill describes how the Layerz tools work and in which order; it states no fact about any business.

## When this applies

A check fails, the balance sheet does not balance, "the numbers are wrong", `computable: false`, verify that a refactor changed nothing, compare two versions, undo, restore, "what changed".

## Sequence

1. `layerz_read { model_id, health: true }` (add `branch_id` to judge the branch the user looks at; `health.by_branch` on a multi-branch model). Each violation names the line and the periods.
2. `computable: false` or `health.status: "unknown"`: `layerz_validate_model` returns the cycle or the broken reference path. Fix the graph before reasoning on any value; every series is zero-filled until then.
3. A failing check: read the line and its sources (`layerz_dependencies { uid }`), look for the typed number, the wrong sign, the missing callup (a `balance` without callup children stays flat), the formula that sums a stock. Fix with `layerz_patch` (`replace` keeps the UID and the presentation), then read health again.
4. Before a structural change on a working model: `layerz_patch { dry_run: true, compare_values: true }` previews the cells that move on checks, totals and the `uids` named. A refactor is neutral when nothing moves.
5. What changed: `layerz_history { model_id, uid }` (one item's changes, or the versions without `uid`) and `layerz_diff { from, to, values: true }` (omit `to` for the live model). On an imported model, `layerz_diff { model_id, source: { set, refs } }` (top level, in place of `from`) compares the live model with its source workbook as Layerz recalculates it: per line, `first_gaps` and `summary.score`; `set` overrides cells (`"Sheet!C6": 0.4`) to compare a scenario.
6. Undo: `layerz_manage_version { op: "restore", version }` after reading the history and the diff (the live state is backed up first); `op: "pin"` keeps a version past the retention window. A patch retried after a timeout re-applies its `create` ops: read the history first.
7. Report in words: what was wrong, what was changed, what the checks say now.

Finance judgement (is the plan credible, what to challenge, what a lender looks at) is not in this plugin: the Layerz cookbook (github.com/layerzlabs/cookbook) has skills for that, which the user installs and adapts.

## References

From the Layerz modeling guide (version 1.1.0; the whole guide: `layerz_get_conventions { include_guide: true }` or the `modeling-guide://reference` resource):

- [10. Checks, health and broken DAGs](references/10-checks-health-and-broken-dags.md)
- [11. Versions](references/11-versions.md)

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: scenarios-and-cash
description: "Scenarios and cash in Layerz: a base, upside and downside case, a fundraise or a delayed hire, runway, a cash-flow forecast, \"what if\", switching between actuals and forecast at the cutover. Creates scenario branches, writes scenario values without touching the base, reads branch versus base, and builds the cash balance and the runway the right way."
license: MIT
metadata:
  layerz_version: "1.1.0"
  generated_by: "layerzlabs/layerz scripts/build-plugin-skills.ts, from the modeling guide"
---

# Layerz: Scenarios and cash

**Instruction priority.** Explicit instructions from the user in the conversation come first. Then the model's FINANCE.md and the workspace conventions: both come back as `conventions` in the results of `layerz_get_model`, `layerz_create_model`, `layerz_build_from_blueprint`, an unfiltered `layerz_read` and `layerz_get_conventions`. They describe this workspace and this model (currency, units, signs, depth, structure, who reads it) and override the defaults below. Your own skills and instructions keep their priority on how you work. This skill describes how the Layerz tools work and in which order; it states no fact about any business.

## When this applies

Scenarios (base, upside, downside, a fundraise, a hire delayed), runway, a cash-flow forecast, "what if", actuals versus forecast.

## Sequence

1. `layerz_get_conventions { model_id }` and a `layerz_read` of the base: which assumptions drive cash, where the cash `balance` is, where `actuals_through` stands.
2. A scenario is a branch; no data source is involved. `layerz_update_branch` with `patch.display_name` creates it; the same name again updates it.
3. Scenario values: `layerz_patch { model_id, branch_id, ops }` with `update` ops carrying `value` / `values` / `timeline_values` on assumptions. Only the cells that differ from the base are stored; structure and non-value fields apply model-wide. The base is never overwritten to test a case.
4. Read the scenario with `layerz_read { branch_id }` (`v` the branch, `vv` branch minus base); without `branch_id`, reads and writes are the base plan.
5. Cash forecast: cash is a `balance` fed by callups of the operating, investing and financing flows; a fundraise is one assumption (amount and month) that moves cash, equity and runway together; runway is a formula on the cash balance and the monthly burn. With actuals in the model, `IF(IS_ACTUAL, actual_line, forecast_line)` switches at the cutover, pinned with `layerz_update_branch` and `patch.actuals_through`.
6. Dashboard: KPIs read the branch checked out; `period_mode: "ytd"` for year-to-date tiles; `meta.default_branch` opens the model on the scenario the user reads first.
7. Hand over the comparison in words: what moves, by how much, under which assumption.

## References

From the Layerz modeling guide (version 1.1.0; the whole guide: `layerz_get_conventions { include_guide: true }` or the `modeling-guide://reference` resource):

- [4. Stock-flow (rolling balances)](references/04-stock-flow-rolling-balances.md)
- [7. Branches, scenarios and actuals](references/07-branches-scenarios-and-actuals.md)

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: start
description: "First steps with Layerz: the first conversation, a workspace with no model yet, \"what can Layerz do\", \"where do I start\", \"import my Excel model\", a fresh connection. Lists the models, offers a template, a few questions or the import of an existing workbook when the account is empty, reads the workspace conventions before the first write, builds a first model in one pass and hands over its link. Use it whenever the Layerz tools are available and no model has been opened yet in the conversation."
license: MIT
metadata:
  layerz_version: "1.1.0"
  generated_by: "layerzlabs/layerz scripts/build-plugin-skills.ts, from the modeling guide"
---

# Layerz: Start

**Instruction priority.** Explicit instructions from the user in the conversation come first. Then the model's FINANCE.md and the workspace conventions: both come back as `conventions` in the results of `layerz_get_model`, `layerz_create_model`, `layerz_build_from_blueprint`, an unfiltered `layerz_read` and `layerz_get_conventions`. They describe this workspace and this model (currency, units, signs, depth, structure, who reads it) and override the defaults below. Your own skills and instructions keep their priority on how you work. This skill describes how the Layerz tools work and in which order; it states no fact about any business.

## When this applies

First conversation with Layerz, a workspace with no model yet, "what can Layerz do", "where do I start".

## Sequence

1. `layerz_list_models`. Read `workspaces[]` (`has_conventions` says whether its members wrote a Context) and `models[]`.
2. When `models` is empty, do not stop there. Offer two ways in one sentence:
   - from a template: `layerz_list_templates`, then `layerz_create_model { template_id, timelines }` (a template's `description` is its FINANCE.md, the usage guide);
   - from the business: ask 4 to 6 questions (what the company sells and to whom, how it makes money, stage and size, horizon, who reads the model) and wait for the answers. When the user says to go ahead, build on stated assumptions and list them in the FINANCE.md as open questions.
   - from an existing workbook: `layerz_create_upload_url`, PUT the file, `layerz_parse_file { file_id }` (its `workbook` says what Layerz recalculates, its scenarios and data tables; `guidance` says how to proceed), then `layerz_create_model { file_id, name }`. The import runs after the answer and its report lands in the model's FINANCE.md; a `409 IMPORT_DECISION_REQUIRED` lists the decisions to ask the user (undated period headers), answered through `anchors`. See the Rebuilding a workbook reference.
3. `layerz_get_conventions { workspace_id }` before the first write. `custom_instructions` is the workspace Context: what its members expect of a model (depth, structure, presentation, working style). Follow it; it is theirs.
4. Build in one pass with the `business-plan` skill: `layerz_build_from_blueprint { apply_if_clean: true }`, then `layerz_read { health: true }`, fix every failing check, then `layerz_set_finance_md` and a `glyph` through the `meta` op of `layerz_patch`.
5. End with the model's `url` and three lines: what was built, the assumptions taken, what is left to decide.

## Where a preference goes

When the user states a preference, write it where every agent and every teammate will read it, and say where it went:

- about every model of this workspace (depth, structure, formats, working style): the workspace Context, `layerz_set_custom_instructions { workspace_id, content }`. The write replaces the whole text (3,000 characters at most): read the current one with `layerz_get_conventions` first and keep what is there.
- about this model (currency, units, signs, statement structure, objective, open questions): its FINANCE.md, `layerz_set_finance_md { model_id, content, summary }`.
- about how you work (tone, questions, deliverables): the user's own skills or instructions, not Layerz.

Finance judgement (is the plan credib

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.