opencode-skills-collection 4.1.1 → 4.1.2

package/bundled-skills/course-upskilling-requests/SKILL.md

@@ -0,0 +1,354 @@
+---
+name: course-upskilling-requests
+description: 'Training request register: course, provider, cost, duration, budget line, the three approval steps, service bond and completion evidence. Use for upskilling approvals.'
+category: business
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-26"
+author: WHOISABHISHEKADHIKARI
+tags: [sme, business, operations, database, csv, notion, sql, develop]
+tools: []
+source_repo: WHOISABHISHEKADHIKARI/sme-ops-system-builder
+---
+
+# Course & Upskilling Requests
+
+**What it is:** Staff ask for a course, managers and finance approve, LMS tracks it.
+
+## Overview
+
+Works out the smallest useful **Course & Upskilling Requests** 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.
+
+Layer: Layer 5: Develop. Fits: Growth stage. Table code: n/a.
+
+## When to Use This Skill
+
+- training request form
+- upskilling request tracker
+- staff training request
+
+Also use it when the user says "staff ask for a course, managers and finance approve, lms tracks it", or describes the same process happening in a
+spreadsheet, a document or someone inboxes.
+
+Do not use it for: payroll calculation, tax filing, or legal advice. This skill produces
+empty templates only - it never holds or processes real employee or customer 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" -> the user wants artifacts; go to Step 2.
+- "our process is ..." or "it is in a sheet" -> the user wants to move an existing process; capture it, then Step 2.
+- "is this right" or "review" or "audit" -> the user wants a check, not a build; answer from what they share.
+- "how do I ..." -> advice question; answer directly and offer the build only if it helps.
+
+Ask only if this is the highest-value missing fact; otherwise proceed without an opener:
+
+> **Q:** What is the training budget per person?
+
+### Step 2 - Ask only what is missing
+
+Skip anything the user already answered, in any earlier message. Ask the rest one at a
+time, and stop as soon as the remaining answers would not change the output.
+
+- **Budget** - Budget per person? / Annual pool or per request? / Currency?
+- **Approval** - Who approves? / Manager then finance? / Fast track under what amount?
+- **After approval** - Bond needed? / LMS or external? / Certificate tracked?
+- **Current process** - How do people ask now? / Email or form? / What gets lost?
+- **Outcome** - What do you need? / A request form, approvals or tracking?
+
+Never invent an answer. If the user does not know, record it as unknown and carry on.
+
+### 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.
+
+```yaml
+module: course-upskilling-requests
+intent: null            # setup | advice | review | fix | build | convert | export
+scale: null             # Starter | Growth | Scale, only if the answer changes it
+areas:
+  "Budget": null
+  "Approval": null
+  "After approval": null
+  "Current process": null
+  "Outcome": null
+requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
+confirmed_facts: []     # only what the user actually said
+open_questions: []      # the unanswered ones, in the order worth asking
+```
+
+### Step 4 - Recommend the smallest workflow
+
+If an artifact was requested, build it after resolving essential missing facts. Otherwise give a short recommendation and offer the relevant artifact.
+
+**Recommended approach:** Route by cost, and record the decision. Tracking completion only matters if completion affects something.
+
+**Why this one:** Training requests stall at approval, not at enrolment. A cost threshold with a named approver removes the bottleneck.
+
+**Workflow:** Request → Manager approval → Finance approval → Enrolment → Completion and certificate
+
+### Step 5 - Build only on request
+
+Once the user asks for it, derive the fields from the confirmed context and emit the
+requested artifacts. For machine-readable text, keep prose outside the data; for files,
+provide a usable link. Report material validation failures or limitations separately.
+
+**A selected Notion output is rendered by `notion-manual-import`, so route the
+Notion step there.** When the user selects Notion, hand that step to
+@notion-manual-import: it holds the CSV, the property
+mapping, the import steps and the verification checklist, and it renders the Field
+Reference below instead of defining a table of its own. Do not restate the mapping
+here and do not improvise the import steps. Manual CSV and mapping outputs need no
+connection. For requested workspace changes, follow the shared contract: verify actual
+tool access and the target before writing. A user saying "connected" is not tool evidence.
+Never ask for a Notion password or token.
+
+For an Excel-compatible CSV, use UTF-8 with a byte order mark so Excel opens the
+text correctly. A CSV is not an `.xlsx` workbook; create `.xlsx` only when the user
+requests a workbook.
+A CSV carries no types, so after it, name the columns
+that need a number, date or currency format applied.
+
+```csv
+Request Title,Employee Name,Department,Course Name,Provider,Course Link,Linked Skill Gap,Reason,Cost,Currency,Duration (Hours),Start Date,Manager Approval,HR Approval,Finance Approval,Budget Line,Service Bond (Months),Enrolled in LMS,Completion Date,Certificate Received,Status,Course Request ID
+Promotion to L3,Aarav Sharma,Delivery,Advanced SQL, Udemy,https://example.com/courses/safety,GAP-2026-003,Skill gap identified in the quarterly review,98000.00,INR,2.5,2026-01-15,FALSE,FALSE,FALSE,BL-114 Travel,12,FALSE,2026-01-15,FALSE,Approved,
+```
+
+```sql
+CREATE TABLE course_upskilling_requests (
+  request_title VARCHAR(255),
+  employee_name VARCHAR(255),
+  department VARCHAR(255),
+  course_name VARCHAR(255),
+  provider VARCHAR(255),
+  course_link TEXT,
+  linked_skill_gap VARCHAR(255),  -- relation -> target record
+  reason VARCHAR(255),
+  cost NUMERIC(14,2) NOT NULL,
+  currency VARCHAR(255),
+  duration_hours NUMERIC NOT NULL,
+  start_date DATE NOT NULL,
+  manager_approval BOOLEAN NOT NULL,
+  hr_approval BOOLEAN NOT NULL,
+  finance_approval BOOLEAN NOT NULL,
+  budget_line VARCHAR(255),
+  service_bond_months NUMERIC NOT NULL,
+  enrolled_in_lms BOOLEAN NOT NULL,
+  completion_date DATE NOT NULL,
+  certificate_received BOOLEAN NOT NULL,
+  status VARCHAR(100) NOT NULL,
+  course_request_id SERIAL PRIMARY KEY,
+  created_at TIMESTAMP DEFAULT NOW(),
+  updated_at TIMESTAMP DEFAULT NOW()
+);
+
+CREATE INDEX idx_course_upskilling_requests_status ON course_upskilling_requests (status);
+```
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Course & Upskilling Requests",
+  "type": "object",
+  "additionalProperties": false,
+  "properties": {
+      "Request Title": { "type": "string" },
+      "Employee Name": { "type": "string" },
+      "Department": { "type": "string" },
+      "Course Name": { "type": "string" },
+      "Provider": { "type": "string" },
+      "Course Link": { "type": "string", "format": "uri" },
+      "Linked Skill Gap": { "type": "string" },
+      "Reason": { "type": "string" },
+      "Cost": { "type": "number" },
+      "Currency": { "type": "string" },
+      "Duration (Hours)": { "type": "number" },
+      "Start Date": { "type": "string", "format": "date" },
+      "Manager Approval": { "type": "boolean" },
+      "HR Approval": { "type": "boolean" },
+      "Finance Approval": { "type": "boolean" },
+      "Budget Line": { "type": "string" },
+      "Service Bond (Months)": { "type": "number" },
+      "Enrolled in LMS": { "type": "boolean" },
+      "Completion Date": { "type": "string", "format": "date" },
+      "Certificate Received": { "type": "boolean" },
+      "Status": { "type": "string" },
+      "Course Request ID": { "type": "integer" }
+  },
+  "required": [
+      "Cost",
+      "Duration (Hours)",
+      "Start Date",
+      "Service Bond (Months)",
+      "Completion Date",
+      "Status"
+  ]
+}
+```
+
+```markdown
+| CSV column | Notion property | Set after import |
+|---|---|---|
+| Request Title | Title | Use as the database title |
+| Employee Name | Text | Leave as Text |
+| Department | Text | Leave as Text |
+| Course Name | Text | Leave as Text |
+| Provider | Text | Leave as Text |
+| Course Link | URL | Convert to URL |
+| Linked Skill Gap | Relation (link to the target database) | Convert to Relation, link to the target database |
+| Reason | Text | Leave as Text |
+| Cost | Number (format: currency) | Convert to Number, set format to Currency |
+| Currency | Text | Leave as Text |
+| Duration (Hours) | Number | Convert to Number |
+| Start Date | Date | Convert to Date |
+| Manager Approval | Checkbox | Convert to Checkbox |
+| HR Approval | Checkbox | Convert to Checkbox |
+| Finance Approval | Checkbox | Convert to Checkbox |
+| Budget Line | Text | Leave as Text |
+| Service Bond (Months) | Number | Convert to Number |
+| Enrolled in LMS | Checkbox | Convert to Checkbox |
+| Completion Date | Date | Convert to Date |
+| Certificate Received | Checkbox | Convert to Checkbox |
+| Status | Select (add options after import) | Convert to Select, add options: "Requested", "Approved", "Scheduled", "In Progress", "Completed", "Rejected" |
+| Course Request ID | Text (preserve source ID) | Keep imported IDs as Text; optionally add a separate Unique ID property |
+```
+
+The rows above are documentation examples only. Emit empty templates unless the user explicitly requests examples. Money stays `currency`, dates stay `date`,
+and anything pointing at another table stays `relation`.
+
+## Field Reference
+
+| # | Field | Type | SQL | JSON Schema | Notion | CSV example |
+|---:|---|---|---|---|---|---|
+| 1 | Request Title | `text` | `VARCHAR(255)` | `string` | Text | `Promotion to L3` |
+| 2 | Employee Name | `text` | `VARCHAR(255)` | `string` | Text | `Aarav Sharma` |
+| 3 | Department | `text` | `VARCHAR(255)` | `string` | Text | `Delivery` |
+| 4 | Course Name | `text` | `VARCHAR(255)` | `string` | Text | `Advanced SQL` |
+| 5 | Provider | `text` | `VARCHAR(255)` | `string` | Text | ` Udemy` |
+| 6 | Course Link | `url` | `TEXT` | `string, format: uri` | URL | `https://example.com/courses/safety` |
+| 7 | Linked Skill Gap | `relation` | `VARCHAR(255)` | `string` | Relation (link to the target database) | `GAP-2026-003` |
+| 8 | Reason | `text` | `VARCHAR(255)` | `string` | Text | `Skill gap identified in the quarterly review` |
+| 9 | Cost | `currency` | `NUMERIC(14,2)` | `number` | Number (format: currency) | `98000.00` |
+| 10 | Currency | `text` | `VARCHAR(255)` | `string` | Text | `INR` |
+| 11 | Duration (Hours) | `number` | `NUMERIC` | `number` | Number | `2.5` |
+| 12 | Start Date | `date` | `DATE` | `string, format: date` | Date | `2026-01-15` |
+| 13 | Manager Approval | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `FALSE` |
+| 14 | HR Approval | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `FALSE` |
+| 15 | Finance Approval | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `FALSE` |
+| 16 | Budget Line | `text` | `VARCHAR(255)` | `string` | Text | `BL-114 Travel` |
+| 17 | Service Bond (Months) | `number` | `NUMERIC` | `number` | Number | `12` |
+| 18 | Enrolled in LMS | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `FALSE` |
+| 19 | Completion Date | `date` | `DATE` | `string, format: date` | Date | `2026-01-15` |
+| 20 | Certificate Received | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `FALSE` |
+| 21 | Status | `select` | `VARCHAR(100)` | `string` | Select (add options after import) | `Approved` |
+| 22 | Course Request ID | `id` | `SERIAL PRIMARY KEY` | `integer` | Text (preserve source ID) | `(blank)` |
+
+## Select Options
+
+**Status**
+
+```
+Requested | Approved | Scheduled | In Progress | Completed | Rejected
+```
+
+## Relations
+
+Link fields: `Linked Skill Gap`
+
+## Examples
+
+**Prompt**
+
+```
+Course requests come by email and get lost in the thread.
+```
+
+**Context first** - one question per message, nothing already answered:
+
+> **Q:** Budget per person?
+> **A:** Around 2,000 a year.
+>
+> **Q:** Who approves?
+> **A:** Manager and finance.
+>
+> **Q:** Tracked now?
+> **A:** Only in email.
+
+**Recommended next step** - offered, not built:
+
+> Route by cost, and record the decision. Tracking completion only matters if completion affects something.
+>
+> Workflow: Request → Manager approval → Finance approval → Enrolment → Completion and certificate
+>
+> Want the CSV, SQL, JSON Schema and Notion mapping for this?
+
+## Best Practices
+
+- Build when requested; recommend and offer a build for advice-only requests.
+- One question per message. A batched intake reads as a form and gets guessed at.
+- Keep display names identical across CSV and JSON; document normalized SQL identifiers.
+- Use `relation` for anything that points at another table, `text` only for free text.
+- Money fields are `currency`, never `text`. Dates are `date`, never free text.
+- If the user requests an example row, keep it obviously fake so nobody imports it as real data.
+
+## Limitations
+
+- Empty template only. It does not compute payroll, tax, leave balances or KPIs.
+- Notion relations need both databases imported before the link column resolves.
+- Select options are a starting set. Rename them to match how the business talks.
+- No automation, reminders or sync. Those need the integration layer.
+- Does not deliver courses or manage an LMS.
+- Legal, tax and HR review is still required before this drives real decisions.
+
+## Security & Safety Notes
+
+- Never fill in real names, salaries, medical or banking data. Placeholders only.
+- Label example rows as synthetic, and keep bank details masked.
+- Local reads, generation commands, and validation are part of a requested artifact build.
+  External writes, messages, provisioning, and publication require authorization for that
+  action and target; existing explicit authorization does not need to be repeated.
+- If sensitive data is supplied, avoid repeating unnecessary identifiers. Use only what
+  the requested review needs; keep generated templates empty. Do not claim deletion
+  from the conversation or service storage.
+- Privacy, legal and disciplinary cases need a qualified human reviewer before anything
+  is acted on.
+
+## Common Pitfalls
+
+- **Problem:** a static mapping is described as a completed workspace build.
+  **Solution:** deliver manual mappings without a connection; claim a live change only
+  after the authorized tool operation succeeds.
+- **Problem:** asked all six questions in one message.
+  **Solution:** ask one, wait, and drop any the first answer already covered.
+- **Problem:** built a full system when one table was asked for.
+  **Solution:** build what was requested; mention the parent skill separately.
+- **Problem:** all four artifacts drift apart.
+  **Solution:** derive all four from the field list in this file, never by hand.
+- **Problem:** Notion import shows every column as Text.
+  **Solution:** that is expected. Apply the property mapping table once, after import.
+
+## Related Skills
+
+- [Module Catalog](https://github.com/sickn33/agentic-awesome-skills/blob/main/CATALOG.md) - find the relevant module, then read its skill.
+- @people-directory - the employee master record most modules link to.
+- @notification-reminder-hub - turns due dates in this module into reminders.
+
+## Reusable Prompt
+
+```
+I want to set up staff ask for a course, managers and finance approve, lms tracks it for my company.
+Ask me one short question at a time, and only about what I have not already told you.
+Then recommend the smallest setup that fits, and wait for me to ask before you build it.
+When I ask, output CSV, SQL DDL, JSON Schema, a Notion property mapping or an Excel workbook. Data only.
+```
+

package/bundled-skills/credit-cycle-analysis/SKILL.md

@@ -0,0 +1,303 @@
+---
+name: credit-cycle-analysis
+description: 'Debtor and creditor credit-cycle analysis: weighted collection or payment days, ageing buckets, credit limit utilisation and gap against benchmark. Use for working-capital review.'
+category: business
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-26"
+author: WHOISABHISHEKADHIKARI
+tags: [sme, accounting, audit, finance, database, csv, notion, sql, working-capital, receivables, payables, aging]
+tools: []
+source_repo: WHOISABHISHEKADHIKARI/sme-ops-system-builder
+---
+
+# Debtor & Creditor Credit-Cycle Analysis
+
+**What it is:** How long the business actually waits to be paid and how long it actually takes to pay, measured per party and per period.
+
+## Overview
+
+Works out the smallest useful **Debtor & Creditor Credit-Cycle Analysis** 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.
+
+Layer: Layer 8: Close & Analyse. Fits: Growth stage. Table code: n/a.
+
+**The SOP rule this skill is built around:** analyse debtors on the average collection period,
+outstanding invoices, overdue receivables and the aging of receivables; analyse creditors on the
+average payment period, outstanding supplier balances, overdue payables and supplier aging; then
+compare the debtor collection cycle with the creditor payment cycle. The comparison is the point.
+Two cycles measured the same way can be read against each other, and the day-to-day pressure of
+waiting longer than you take is invisible as a line on the balance sheet. That pressure is
+measured in **days** here. Turning it into money is a separate calculation with its own basis,
+below.
+
+**Six concepts that never stand in for each other.** This table exists to keep them apart, and
+most of the wrong answers come from swapping one for another:
+
+| Concept | What it answers | Field that carries it |
+|---|---|---|
+| Contractual terms | What was agreed | `Contractual Terms Days` |
+| Actual cycle | What actually happened | `Actual Collection/Payment Days`, `Weighted Days` |
+| Benchmark | What to compare against | `Benchmark Days`, `Gap vs Benchmark` |
+| Aging | How old the unpaid items are | bucket amounts, and `Aging Bucket` on the invoice/bill detail |
+| Debtor-vs-creditor timing | Which side of the cycle is longer | `Cycle Gap Days` on the comparison record |
+| Working-capital funding | What the timing difference costs in money | `Estimated Working-Capital Funding`, `Calculation Basis` |
+
+Conflating them is the defect this module is built to prevent. Contractual terms of 30 days and
+an actual collection cycle of 42 days are two facts about the same party, and the 42 is the one
+that reaches the bank account. Writing the 30 into `Actual Collection/Payment Days` because it is
+the number in the contract is a substituted value, not a measurement.
+
+**Aging lives on the invoice, not on the party.** One party can hold open invoices in several
+aging buckets on the same day. So the party-period record carries the bucket **amounts**
+(`Current Amount`, `Aging 0-30 Amount`, `Aging 31-60 Amount`, `Aging 61-90 Amount`, `Aging 91-180 Amount`, `Aging Over 180 Amount`)
+and the single `Aging Bucket` belongs to one invoice or one bill on the aging-detail record. A
+party row carrying one `Aging Bucket` cannot describe a real aging position and is replaced by
+the bucket amounts.
+
+**Neutral field names.** The two movement fields are `Credit Movement` and `Settlement`, for
+customers and for suppliers alike. `Credit Movement` is the credit-side activity that created the
+balance in the period - customer invoices on the debtor side, supplier bills on the creditor
+side. `Settlement` is what closed it - customer collections, supplier payments. A name like
+`Total Billed` describes only the debtor side and quietly makes the creditor side unreadable.
+
+**The balance identity, and what happens when it fails.**
+
+```
+Closing Balance = Opening Balance + Credit Movement - Settlement +/- Adjustments
+```
+
+Check it on every row. If it does not hold, the difference is **recorded and marked**, never
+repaired by editing a component. A silently balanced row is worse than an unbalanced one,
+because the next period inherits it.
+
+**The cycle gap is descriptive, not a verdict.**
+
+```
+Cycle Gap Days = Debtor Collection Days - Creditor Payment Days
+```
+
+Positive means customers take longer to pay than the business takes to pay suppliers. Zero means
+the two measured cycles are equal. Negative means suppliers are paid later than customers are
+collected. A positive gap is not automatically bad - it is often the ordinary consequence of
+selling on credit to a customer base and buying on shorter terms. The module states the
+difference and leaves the judgement to the business.
+
+**Working-capital funding needs a monetary basis, and the basis is always written down.**
+
+```
+Estimated Working-Capital Funding = Cycle Gap Days x Relevant Daily Credit Movement
+```
+
+This is only computed when the relevant monetary basis exists, and `Calculation Basis` always
+records how that basis was built. A plausible daily figure is:
+
+```
+Relevant Daily Credit Movement = Relevant annual credit movement / 365
+```
+
+and it is only used when the selected annual movement is appropriate for the analysis. Where the
+monetary basis is missing, `Estimated Working-Capital Funding` is `Unknown` and the record says so.
+Never invent a monetary impact, and never divide a period's movement by 365 without checking that
+the period is the year the analysis is about.
+
+**Benchmarks are the user's, not the module's.** `Gap vs Benchmark` is `Actual Collection/Payment
+Days - Benchmark Days`. A benchmark must be supplied by the user, explicitly selected by the
+user, or clearly labelled a proposed default. It is never presented as a business target, and
+never as an industry figure unless the user supplied that figure.
+
+**Due dates are recorded, never derived.** `Days Overdue = Period End - Due Date`. Where a due date
+is not recorded, the aging is `Unknown` - a due date is never reconstructed from payment terms,
+because terms are an agreement and the due date is a fact about one invoice.
+
+**Percentages, money and rounding.** A percentage is stored as `97` for 97%, never `0.97`, and the
+convention is never mixed inside the table. Money is a bare number with no currency symbol in the
+cell, and the currency itself is `Unknown` until the user states it. Amounts are the gross ledger
+amounts as posted to the party's account, tax-inclusive; this module does not split tax out of a
+balance. Every figure is rounded once, at the end, to two decimal places, so the components can be
+re-derived from the row.
+
+## When to Use This Skill
+
+- debtor collection analysis
+- creditor payment analysis
+- receivables aging and payables aging
+- average collection period or average payment period
+- customer payment behaviour and supplier payment behaviour
+- working-capital cycle review
+- converting an existing credit-cycle spreadsheet or process
+
+Also use it when the user says "how long the business actually waits to be paid and how long it
+actually takes to pay, measured per party", or describes the same process happening in a
+spreadsheet, a document or someone inboxes.
+
+Do not use it for: collections chasing, credit-control action plans, payment execution, banking
+operations, employee analysis, disciplinary decisions, or legal advice. This skill designs
+templates and analysis structures. It does not execute financial transactions, and it produces
+empty templates only - it never holds or processes real customer or supplier data.
+
+## How It Works
+
+Follow the shared execution contract and the detailed domain workflow in [the bundled how-it-works reference](references/how-it-works.md). Keep unknown values explicit and derive every output from confirmed fields.
+
+## Field Reference
+
+The canonical fields and export mappings are maintained in [the bundled field-reference document](references/field-reference.md).
+
+## Select Options
+
+See the [bundled select-options reference](references/select-options.md).
+
+## Relations
+
+No relation fields. This table is standalone: `Party Name` is free text because no party master
+table is created by this build, and inventing a link to a database that does not exist would give
+a column that never resolves. Where the business later wants a live party link, add it once the
+party database actually exists.
+
+## Examples
+
+Worked examples are maintained in [the bundled examples reference](references/examples.md); keep identifiers fictional and preserve the evidence boundaries.
+
+## Best Practices
+
+See the [bundled best-practices reference](references/best-practices.md).
+
+## Limitations
+
+- Empty templates only. It does not calculate collection periods, chase anyone, set a credit limit
+  or recommend a change of terms. The days and the money on each row are the ones the business
+  entered.
+- It measures the gap; it does not close it and it does not judge it. Whether a positive gap is
+  worth fixing is a commercial decision, not a record.
+- A cycle measured from a ledger is only as good as the ledger. Reconcile the party balances
+  first, or the days will be precise and wrong.
+- Overdue amounts depend on due dates being recorded against every invoice. Where they are not,
+  the aging bucket is `Unknown` and the row is not aged - a guessed due date is worse than none.
+- `Estimated Working-Capital Funding` is an estimate on a stated basis, not a cash-flow forecast.
+  It excludes retention, factoring, bill discounting, foreign currency settlement timing and any
+  seasonality the annualised basis does not carry.
+- Averages hide concentration. A party-period row is not evidence about how the total is
+  distributed across parties; read the detail dataset for that.
+- `Data Quality Status` is a judgement the module cannot make for you. It records the checks that
+  were run and what they returned.
+- Notion relations need both databases imported before a link column resolves; this module has no
+  relation columns to worry about.
+- Select options are a starting set. Rename them to match how the business talks.
+- No automation, reminders or sync. Those need the integration layer.
+- Legal, tax and HR review is still required before this drives real decisions.
+
+## Security & Safety Notes
+
+See the [bundled security-notes reference](references/security-notes.md).
+
+## Common Pitfalls
+
+See the [bundled common-pitfalls reference](references/common-pitfalls.md) for review guidance.
+
+## Related Skills
+
+- @accounting-audit-system-builder - routes to this skill and the other 15 modules.
+- @party-ledger-reconciliation - agree the balances before measuring the cycle.
+- @sales-accounting - where the credit movement on the debtor side is recorded.
+- @purchase-accounting - where the credit movement on the creditor side is recorded.
+- @receipt-accounting - the collections that shorten the debtor cycle.
+- @payment-accounting - the payments that set the creditor cycle.
+- @day-book - the cash movement behind both cycles.
+- @monthly-closing-statements - the receivables and payables review this measures.
+- @source-document-filing - where the invoice or bill behind an aging line is filed.
+- @tds-booking-payment - deductions taken on collection, which change the settled amount.
+- @petty-cash-management - the small working-capital swings this sits alongside.
+- @expense-accounting - the expense detail behind a payment cycle.
+- @inventory-stock-reconciliation - the same count discipline applied to stock.
+
+## Reusable Prompt
+
+```
+I want to set up a system for measuring how long my business waits to be paid by customers and
+how long it takes to pay suppliers, measured per party and per period.
+
+Ask me one short question per message, and only about what I have not already told you. Do not
+assume that contractual payment terms are the same as actual payment behaviour, and never batch
+two questions into one message.
+
+First understand: whether customers and suppliers are both included and how many parties; the
+contractual payment terms and the actual cycle measured separately for customers and for
+suppliers; the measurement basis (invoice or bill date to settlement date, to first settlement
+date, due date to settlement date, or a weighted settlement date); whether due dates are recorded
+and whether aging is possible at invoice or bill level; which aging buckets are already in use;
+whether part-payments occur; the current process and how it is reconciled; and whether I need
+cycle measurement, aging, the debtor-versus-creditor comparison, working-capital analysis, or all
+of them.
+
+Then recommend the smallest setup that fits, explain briefly why the layers are needed, and wait
+for me to ask before you build anything.
+
+Use three logical datasets, and do not force them into one table:
+  party-period credit-cycle summary
+  invoice/bill aging detail
+  per-period debtor-versus-creditor working-capital comparison
+
+Keep these six concepts separate, and never substitute one for another:
+  contractual terms
+  actual cycle
+  benchmark
+  aging
+  debtor-creditor cycle gap
+  working-capital funding
+
+The party-period summary uses: Analysis Number, Period Start, Period End, Party Type, Party Name,
+Opening Balance, Credit Movement, Settlement, Adjustments, Closing Balance, Average Balance,
+Measurement Basis, Contractual Terms Days, Actual Collection/Payment Days, Weighted Days, Overdue
+Amount, Current Amount, Aging 0-30 Amount, Aging 31-60 Amount, Aging 61-90 Amount, Aging 91-180 Amount, Aging Over 180 Amount,
+Customer Credit Limit, Customer Credit Utilisation %, Benchmark Days, Gap vs Benchmark, Cycle
+Trend, Reconciliation Status, Data Quality Status, Reviewed By, Status, Notes, Cycle Analysis ID.
+Customer Credit Limit and Customer Credit Utilisation % are customer-only and are never applied
+to a supplier.
+
+The invoice/bill aging detail uses: Aging Detail ID, Party Type, Party Name, Invoice/Bill Number,
+Invoice/Bill Date, Due Date, Original Amount, Settled Amount, Outstanding Amount, Settlement Date,
+Days Overdue, Aging Bucket, Period End, Notes. A party can hold several aging buckets at the same
+time, so a single Aging Bucket never sits on a party-period row.
+
+The working-capital comparison uses: Comparison ID, Period Start, Period End, Debtor Collection
+Days, Creditor Payment Days, Cycle Gap Days, Relevant Daily Credit Movement, Estimated
+Working-Capital Funding, Calculation Basis, Data Quality Status, Cycle Trend, Reviewed By, Status,
+Notes.
+
+Use these calculations:
+  Closing Balance = Opening Balance + Credit Movement - Settlement +/- Adjustments
+  Cycle Gap Days = Debtor Collection Days - Creditor Payment Days
+  Gap vs Benchmark = Actual Collection/Payment Days - Benchmark Days
+  Days Overdue = Period End - Due Date
+  Customer Credit Utilisation % = Outstanding Customer Balance / Customer Credit Limit x 100
+  Estimated Working-Capital Funding = Cycle Gap Days x Relevant Daily Credit Movement
+  Weighted Settlement Date = SUM (Settled Amount x Settlement Date) / SUM (Settled Amount)
+
+Calculate actual collection and payment days from documented invoice/bill and settlement dates.
+Support partial payments with the weighted settlement calculation and record that it was used. Do
+not use contractual terms as actual cycle days. Interpret the cycle gap descriptively - a
+positive gap is not automatically bad. Do not guess a due date from payment terms. Compute
+working-capital funding only when a monetary basis exists, and always record Calculation Basis
+alongside it.
+
+A benchmark must be supplied by me, explicitly selected by me, or clearly labelled a proposed
+default - never presented as a business target.
+
+Before a record is complete, validate the balance reconciliation and the data quality, and record
+Reconciliation Status and Data Quality Status. Never silently correct an inconsistent balance.
+Never invent a missing value, benchmark, currency, date, payment behaviour, credit limit or
+financial impact. Unknown is a correct answer and is never turned into zero.
+
+When I explicitly ask for artifacts, build one canonical field dictionary first and derive every
+requested artifact from it. If I ask for all four, produce CSV, SQL DDL, JSON Schema and the
+Notion property mapping, with identical field names, types, order and required status across all
+four. Use obviously fake example data only.
+
+If I ask for a review, review the existing design instead of rebuilding it. If I ask for a fix,
+preserve the valid information I supplied and correct only the structural, calculation,
+data-quality and consistency problems.
+```