inventory-stock-reconciliation – Other skill for AI agents

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:

> Q: How many items do you hold, and when did you last count them physically?

Treat the two halves independently. If the user answers only one, record only that one and

ask the other separately if it would change the recommendation. 20 to 50 records the item

count range and leaves the last physical count date Unknown.

Then, only as needed:

• Stock - How many items do you hold? / What do you hold? / How many locations or

warehouses?

• Count - When did you last count physically? / Full count or cycle count? / How often?

/ Who counts? / Who verifies? - ask these as two separate questions, never as one.

• Differences - What gets investigated when the physical count differs from the books? /

Who approves an adjustment? / Is there a threshold that requires escalation?

• Current process - Is the count currently recorded anywhere? / Spreadsheet, accounting

package, or another system? / What is currently being missed?

• Outcome - A reconciliation record, a count sheet, or both?

Ambiguous answers are not answers. yes, no, maybe, same, okay and fine are

not answers to a multiple-choice question - not even when the question was phrased as two

options in a sentence. A bare yes to "Do you want a full count or a cycle count?" resolves

nothing, because the question had no yes/no answer to give. Re-ask as an explicit choice and

wait:

> Q: Which do you mean: full count of all items or cycle count of selected items?

Partial answers keep only the answered part. If a question carries two pieces of

information and the user answers one, retain only that one and leave the rest Unknown.

Never turn Unknown into 0 - a quantity nobody has counted is not a quantity of zero.

Never invent an answer. If the user does not know, record it as Unknown and carry on.

Step 3 - Hold the internal context

Keep 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: inventory-stock-reconciliation
intent: null            # set in Step 1: set up | fix | review | report | import
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  "Stock": null
  "Count": null
  "Differences": null
  "Current process": null
  "Outcome": null
  # Sub-areas recorded with the same discipline, and only when the answer changes the build:
  #   Stock.item_count | Stock.stock_types | Stock.locations      - never assumed
  #   Count.count_type | Count.frequency                        - full vs cycle, and how often
  #   Count.counted_by | Count.verified_by                       - asked separately, never inferred
  #   Differences.adjustment_approver | Differences.escalation_threshold
  #   Outcome.requested_outputs                                  - csv | sql | json | notion, as asked
requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
confirmed_facts: []     # only what the user actually said
unknowns: []            # asked and not answered
open_questions: []      # the unanswered ones, in the order worth asking

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 reconciliation record per count session, item, location and relevant lot/serial/UOM (rather than overwriting an earlier count). Freeze or reconcile movements to one stated cutoff, separate owned/consigned goods and avoid double-counting damage/expiry. One record per item counted, carrying the book quantity, the physical quantity, the variance, the variance reason, the investigation notes and the authorised adjustment, with the count sheet filed against the same reconciliation.

Why this one: The minimum defensible record connects the physical count to the book balance, documents why a difference exists, and records who authorised any adjustment. A count that is not reconciled back to the books proves nothing, and an adjustment passed without a named approver is a correction dressed up as control.

Workflow: Count planned → Items counted → Compared with books → Variance investigated → Adjustment authorised → Adjustment booked → Reconciliation filed

If no artifact was requested, offer the relevant format. Otherwise continue the build.

Step 5 - Build only on request

Once the user asks, derive the

… (full content is in the download package)