spreadsheet-manual-build – Documents & Office skill for AI agents

Spreadsheet Manual Build

What it is: a formatted, empty workbook from a field list someone has already

confirmed - no dashboards nobody asked for, no invented rows.

Overview

Prepares a spreadsheet or Excel workbook from confirmed business requirements. Use it

when the user wants an Excel workbook, a spreadsheet template, an .xlsx file, a manually

editable register, an importable table, or a workbook built from another skill's field

list.

The workbook is built only from confirmed fields. This is a helper: it defines no table of

its own and renders whatever field list the active module already confirmed, so the

workbook and the module's CSV cannot disagree.

Layer: n/a. Fits: every stage. Table code: n/a - it renders the active module's table.

When to Use This Skill

• I need an Excel workbook
• give me a spreadsheet template
• I want an .xlsx file
• build me a register I can edit by hand
• make this importable as a table
• build a workbook from the fields we agreed

Also use it when a module has confirmed a field list and the user wants that list as a

workbook rather than as DDL or a schema.

Do not use it to decide which fields the business needs. That is the module skill's job,

and this one starts from what it confirmed.

How It Works

Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

Step 1 - Identify intent

Read the request and pick the intent before asking anything.

• "a template", "an empty workbook" -> template only. Output: an empty workbook with

headers and formatting.

• "with a couple of rows to see the shape" -> workbook with examples, and only when the

user asked. The data is obviously fake.

• "the dates are showing as text", "the column is too narrow" -> fix existing workbook.

Output: only the structure or formatting that was asked for.

• "how should these fields sit in the sheet" -> mapping only. Output: the column plan,

no file.

Never produce more than the intent asked for. A fix does not become a rebuild, and a

mapping does not become a file.

Step 2 - Ask only what is missing

Reuse everything already confirmed, including by the module that owns the field list: the

workbook purpose, the field names and types, the select options, the date and currency

fields, any formula the parent skill defines explicitly, the statuses, and the IDs. Never

ask again for information the user has already supplied.

Ask one short question per message, and only when the answer changes the output:

> Q: Do you want .xlsx or CSV?

> Q: Should this be an empty template or include example rows?

If the answer does not materially change the result, do not ask, and default to:

format: xlsx
example_rows: false

Step 3 - Hold the internal context

Hold the answers in this shape. It stays internal - it is not shown to the user unless

they ask, and it never carries a value the user did not give.

module: spreadsheet-manual-build
intent: null            # set in Step 1, one of: template, examples, fix, mapping
source_module: null     # the module whose field list this renders
requested_outputs: []   # xlsx | csv | mapping
example_rows: false
confirmed_facts: []     # only what the user actually said
open_questions: []      # the unanswered ones, in the order worth asking

source_module is the one field this skill needs that a module skill does not have. If it

is unknown, ask which database to prepare, because a workbook built from a guess is a

rebuild of the guess later.

Step 4 - Recommend the smallest workflow

Build an already requested artifact without asking again. For advice-only requests, give a short recommendation and offer the relevant artifact.

Recommended approach: One sheet, one header row, one column per confirmed field,

frozen and filtered. That is a working register on day one.

Why this one: workbooks fail from decoration, not from missing columns. A single

filtered sheet gets maintained; a dashboard nobody opens does not, and every extra tab is

a second thing to keep in step with the first.

Workflow: Field list confirmed -> Columns and formats set -> Header frozen and

filtered -> (rows entered by the user) -> Reviewed

Default to one sheet unless the confirmed workflow requires more. Do not create

dashboards, charts, lookup sheets or instruction tabs unless the user asks for them or the

confirmed workflow clearly requires them. The default sheet name is Register.

Step 5 - Build only on request

Once the user asks, emit the workbook or the CSV as data only. No preamble, no summary, no

closing line. Every column comes from the canonical field list, with the exact field

names, in the same order, every time.

A .xlsx is a real file. A CSV is not a workbook: a CSV is UTF-8, with a byte order mark only for an Excel-oriented consumer that requires it, plus a note of which columns need a number, date or

currency format applied. Create .xlsx only when the user asks for a workbook.

Column rules

| Canonical type | Spreadsheet format |

|---|---|

| id | Text |

| title | Text |

| text | Text |

| long_text | Text, wrapped |

| number | Number |

| currency | Currency or Accounting, and only when the currency is known |

| percentage | Number on a 0–100 scale; convert to fraction before Percentage formatting |

| date | Date |

| datetime | Date + Time |

| checkbox | TRUE/FALSE |

| select | Data validation list |

| multi_select | Text, unless another structure is explicitly requested |

| url | Hyperlink or Text |

| email | Text |

| phone | Text |

| relation | Text reference key, unless the workbook design explicitly supports lookups |

Formatting

Practical business formatting only:

• a bold header row
• the top row frozen
• an autofilter over the header
• sensible column widths
• a date format on date fields
• a number format on numeric fields
• wrapped long-text fields

No decorative formatting that reduces usability. A currency format is applied only where

the user has named the currency; where they have not, the column stays numeric and the

currency is recorded separately, because a currency symbol in a cell is an assumption

nobody asked for.

Select fields

For a confirmed select field, use data validation where practical, listing only the

confirmed options:

Status:
Draft
Filed
Paid
Overdue
Amended

Never invent a status. A starting set is a suggestion, and the user renames it to match

how the business talks.

Formulas

Never invent a formula. One may be added only when the parent skill defines it, or when

the user asks for it and gives the rule. A value computed elsewhere - Net Tax Payable,

Days to Due, Balance, Variance - stays an input or an output column. If the parent

skill says the calculation belongs in accounting or tax software, that rule stands and no

Excel formula is written for it.

IDs

Do not auto-generate production IDs unless the user requests it, and leave the ID column

blank in an empty template. If the user wants an automatic spreadsheet ID, confirm the

required pattern first rather than guessing one.

Before you hand it over

Workbook name confirmed?
Sheet names necessary, or is one enough?
Every column from the canonical schema, and nothing else?
No invented fields?
No invented formulas?
No fake rows unless requested?
Correct date formats?
Correct number formats?
Only the confirmed select options?

Field Reference

This skill has no Field Reference of its own, and it must not grow one. The active

module's Field Reference is the single source: the same field list that produces its CSV,

SQL, JSON Schema and Notion mapping produces this workbook, so a column can never appear

here that is absent there.

If the field list is not in front of you, read skills/<slug>/SKILL.md for the module in

play. If it is missing or ambiguous, ask which workbook to prepare and stop.

Input Modules

A helper has no field list of its own, so its input is a module: the Field Reference

that module already confirmed. Read that section - field names, types, order,

requiredness, options and calculations - and render exactly that. The list below is

every module that owns a field list, grouped by the layer its catalog gives it, and is a static reference snapshot that can drift. Verify the selected module exists and read its current confirmed field list; counts here are not schema authority. CATALOG.md is the index to show a user; the module's own

SKILL.md holds the field list.

Layer 1: Foundation - 6 modules

• skills/access-matrix/SKILL.md - Access Matrix (16 fields)
• skills/organization-design/SKILL.md - Organization Design (13 fields)
• skills/policy-acknowledgement/SKILL.md - Policy Acknowledgement (12 fields)
• skills/policy-library/SKILL.md - Policy Library (14 fields)
• skills/sop-company-wiki/SKILL.md - SOP & Company Wiki (12 fields)
• `skills/account

… (full content is in the download package)