Inventory / Stock Reconciliation

What it is: Physical stock counts against book quantities, differences investigated, and authorised adjustments recorded.

Overview

Works out the smallest useful Inventory / Stock Reconciliation setup for the business in front of it, then builds it only when asked. The default output is a short recommendation, not a spreadsheet. Artifacts - CSV, SQL DDL, JSON Schema, Notion mapping - are produced on request, from one field list so they cannot drift apart.

Three guardrails shape the whole table.

The artifact stage is template-only. What the user receives is a structure: a CSV that is a header row and no data row, DDL with no INSERTs, a schema with no example values, and a property mapping table. Add one clearly labelled illustrative row only when the user explicitly asks for one. The failure this prevents is an unknown quietly turning into fake data inside a generated artifact.

Counting, verifying and approving are three separate roles. Counted By, Verified By and Approved By answer three different questions and are never inferred from one another. The manager who approves an adjustment is not automatically the verifier, and the verifier is not automatically the counter. If the business genuinely runs two of these as one job, that has to be said, not assumed.

A variance without an investigated reason stays unresolved. No adjustment is booked without a named approver, and a record does not reach Done while a difference has no recorded cause. A missing answer stays blank or Unknown - never a plausible-looking number, and never 0.

Never manufacture a name, a date, a quantity, a price, a location, an approval, a variance reason or a transaction reference to fill a gap. Unknown and blank are correct answers.

The count is periodic by design. Book quantity is a number the system believes; it is only ever as good as the last entry. Until someone walks the shelves and writes down what is actually there, the books are an opinion, and the frequency of the count is a business decision driven by volume, value and risk rather than a setting anyone can skip. Two things follow from that. First, every adjustment needs a named approver before it is booked - a correction passed without authorisation is just a quiet write-off. Second, investigating a shrinkage is a human judgement, not a calculation: no formula tells you whether a missing stack of cartons was theft, a mis-pick, or two dispatches that never got a stock entry.

Layer: Layer 7: Reconcile. Fits: Growth stage. Table code: n/a.

When to Use This Skill

• physical stock count
• stock variance investigation
• stock adjustment register
• inventory shrinkage tracker
• cycle count sheet

Also use it when the user describes the same process happening in a spreadsheet, on paper, or in someone's inbox.

Do not use it for: purchase or sales booking, inventory valuation method design, reorder-point design, or legal or tax advice. This skill produces empty templates only - it never holds or processes real employee, customer or stock-movement data.

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.

• "set up" or "build" or "create" -> a new structure; go to Step 2.
• "our process is ..." or "it is in a sheet" -> capture the existing process first, then Step 2.
• "is this right" or "review" or "audit" -> a check, not a build; answer from what they share and do not rebuild.
• "how do I ..." -> advice; answer directly and offer a build only if it helps.

Step 2 - Ask only what is missing

Treat ambiguous replies as unanswered and ask which explicit option the user means. Record unknown values as Unknown; Unknown is not zero. A record must not be Done when a required check fails.

One message, one question, no batching. Skip anything the user already answered, in any earlier message. Ask only questions whose answer would change the recommendation or the requested artifact. Stop as soon as the remaining unknowns would not change the output. Record Unknown and move on when the user does not know, and never ask the same unknown twice.

The opening question targets the biggest missing fact that changes the output, not a generic opener. For a new setup the usual first question is:

…