Pos Sales Operations Engineering logo

Pos Sales Operations Engineering

Community
peterbamuhigire
pos-sales-operations-engineering

Use when implementing or reviewing a tenant-aware ERP POS, agent POS, or manual sales-entry workflow where customer defaults, product-to-stock identity, inventory timing, payments, permissions, and audit-safe posting must remain consistent. Use the design engine for visual craft.

Overview

Publisherpeterbamuhigire
Repositorychwezi-dev-engine
Skill namepos-sales-operations-engineering
Stars
29
Forks
6
Bundled files
1
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 1 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by peterbamuhigire on GitHub. Read the source before you install it.

Installation

Install the Pos Sales Operations Engineering AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/peterbamuhigire/chwezi-dev-engine/tree/main/skills/frontend-ux/pos-sales-operations-engineering
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/peterbamuhigire/chwezi-dev-engine.git /tmp/chwezi-dev-engine
mkdir -p .claude/skills
cp -r /tmp/chwezi-dev-engine/skills/frontend-ux/pos-sales-operations-engineering .claude/skills/pos-sales-operations-engineering
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Pos Sales Operations Engineering in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Pos Sales Operations Engineering on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Pos Sales Operations Engineering is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

POS Sales Operations Engineering

This skill owns the application and service contract for operational point of sale. It keeps fast sales entry aligned with tenant isolation, finished-stock truth, manufacturing timing, payment idempotency, permissions, accounting posting, and evidence. Visual hierarchy and typography remain owned by the external chwezi-design-engine engine.

Prerequisites

Load skills/frontend-ux/pos-sales-operations-engineering for implementation rules together with the external design engine's pos-and-retail-operations skill for presentation decisions. For money, inventory value, or ledger work, also route to chwezi-accounting-doctrine and the local accounting-engine.

Use When

  • Building or auditing pos.php, agent-pos.php, or encode-sales.php in an ERP.
  • Defining a tenant-wide Walk-in/default customer and its administrator permission.
  • Connecting products to finished stock, manufacturing recipes, batches, and sale deductions.
  • Consolidating multiple sales writers, payment handlers, or retry paths into one boundary.
  • Testing tenant, branch, sales-agent, plant, stock, invoice, payment, GL, and audit controls together.

Do Not Use When

  • The work is only visual composition, typography, colour, or interaction polish; use the external design engine.
  • The workflow is quotation → customer order → delivery → invoice → payment collection; design that as separate order-to-cash, not POS.
  • The task is a financial statement, statutory rule, or accounting policy judgement; use the accounting doctrine.
  • The task is generic frontend architecture without POS-specific transaction or stock semantics.

Required Inputs

InputProduced byRequired?Why
Surface inventory and user journeysProduct owner / route auditrequiredSeparates shop POS, agent POS, and manual encoding
Tenant, branch, store, agent, and plant access modelArchitecture / securityrequiredPrevents accidental scope escalation
Product-to-finished-stock mapInventory and manufacturingrequiredIdentifies the stock item a sale may deduct
Recipe and manufacturing posting rulesManufacturing / accountingwhen applicableKeeps ingredient consumption at manufacture
Customer, tender, tax, invoice, and GL mappingsSales / financerequiredDefines a complete posting boundary
Representative fixtures and replay expectationsQA / demo seedingrequiredProves normal, failed, retried, and isolated paths

Outputs

ArtefactConsumed byTemplate or acceptance condition
POS surface contractProduct, design, frontend, QANames the three operational pages and the separate order-to-cash workflow
Product-stock and manufacturing mapInventory, manufacturing, salesEvery saleable product has one active finished-stock mapping
Default-customer configuration contractTenant administration and QAOne server-resolved active customer is shared by all POS surfaces
Canonical posting boundaryAPI, accounting, inventory, auditOne atomic/idempotent service owns invoice, payment, stock, GL, and audit effects
Test and evidence bundleRelease owner and finance reviewIncludes tenant, permission, failure, replay, stock-timing, and reconciliation evidence

Non-negotiables

  1. Keep exactly three operational POS surfaces distinct: pos.php is the general shop POS; agent-pos.php posts sales strictly for a sales agent; encode-sales.php manually records an already-made sale.
  2. Store one tenant-wide default customer, normally Walk-in, in a tenant-scoped configuration key such as pos_default_customer_id. Resolve it server-side on every POS page. Never choose the first active customer or infer a default from a name containing “cash” or “walk”.
  3. Allow only super administrators, max administrators, or users with the dedicated tenant configuration permission to change that setting. Validate customer ownership and active status before saving.
  4. If the setting is missing or inactive, stop the POS page before the selling interface opens. Show a clear, localised configuration state and route the authorised user to settings; do not post an unassigned sale.
  5. Sell products, not arbitrary stock items. Each saleable product must map 1:1 to a finished stock item. Ingredients and packaging are not POS catalogue cards.
  6. Manufacturing consumes recipe ingredient stock and produces the finished stock item. Sale posting deducts only that finished stock item. Do not deduct recipe ingredients again at sale.
  7. Use one canonical transaction service or explicit adapters into it. Enforce tenant scope, customer validation, mapped product identity, batch/FEFO availability, price, invoice, payment, stock movement, GL posting, audit lineage, and idempotency in the service boundary.
  8. Keep branch-sales access, sales-agent access, and plant/job access as separate permissions. A user who can view branch sales does not automatically gain plant access.
  9. Treat a timeout as an unknown result. Retry with the same idempotency key and reconcile persisted records before displaying a new success or creating a second invoice.
  10. For fiscal POS deployments, apply the mandatory session-locking and receipt sequence controls in skills/product-business/product-discovery/references/feature-planning/references/pos-mandatory-requirements.md.

Decision rules

ConditionRequired actionFailure avoided
Active tenant default existsLoad it in all three POS pages before async catalogue workEmpty or divergent customer attribution
Default is absent or inactiveBlock the POS interface and show configuration guidanceUnassigned or guessed customer sales
Operator selects a named customerPreserve it through product, sales-point, review, and retry statesSilent reset to Walk-in
Product lacks an active 1:1 finished-stock mappingHide or reject it and report the data defectRaw ingredient or phantom stock sale
Recipe ingredient is consumedPost at manufacturing completionDouble consumption at sale
Finished stock is soldDeduct the mapped finished item by batchIngredient deduction or negative stock leakage
User has branch rights but no plant rightsKeep plant records and job cards inaccessiblePermission transitivity breach
Payment response is unavailableReconcile by idempotency key before retryingDuplicate payment or invoice
Any journal, stock, or invoice write failsRoll back the atomic boundary or post an authorised reversalPartial economic event

Workflow

  1. Inventory the surfaces. Search routes, APIs, JavaScript, services, stored procedures, seeders, reports, and tests. Mark every writer and payment path; retire fake or random-ID writers rather than leaving them as competing authorities.
  2. Write the identity map. Record product ID, finished stock-item ID, recipe ingredient IDs, batch ID, UOM, price, cost, and the direction of each manufacturing and sales movement. Keep customer-facing product identity separate from inventory identity.
  3. Define tenant configuration. Add the setting, permission, settings UI, API validation, audit metadata, and a repeatable demo seeder. Verify the default belongs to the current tenant and is active.
  4. Gate and initialise all pages. Resolve the default before rendering the sale interface or starting asynchronous catalogue calls. Show explicit loading, empty, error, disabled, and configuration-required states.
  5. Consolidate posting. Route normal invoice sales, manual encoding, agent sales, and payment receipt through the canonical service. Preserve the same request/idempotency contract across retries and replay.
  6. Enforce stock timing. Manufacture ingredient-to-finished movements at job completion; sell product-to-finished-stock movements at sale posting; lock and validate the relevant batch quantities in the same transaction.
  7. Verify boundaries. Test tenant and branch scope, sales-agent scope, plant separation, permission changes, inactive defaults, unmapped products, insufficient stock, duplicate keys, payment timeouts, voids, and reversals.
  8. Reconcile evidence. Confirm invoice lines, payments, stock ledger, batch balances, GL journals, customer balance, and audit entries agree. Run the seeder in dry-run/apply/verify modes and prove replay does not duplicate.

Quality Standards

  • Use server-derived tenant context and prepared statements; never trust a tenant ID, customer ID, stock ID, branch ID, or plant ID from the browser.
  • Keep errors solution-bearing and localisable. Never return a green success state before the persisted result is known.
  • Require focused unit/contract tests, a database-backed integration path where possible, PHP/JavaScript syntax checks, and a release evidence record.
  • Keep the implementation separate from the visual system. Hand off spacing, type, colour, touch targets, and visual QA to the design engine.

Anti-Patterns

  • Name heuristic default: selecting the first customer matching “cash”. Fix: resolve the explicit tenant setting and block when invalid.
  • Terminal override: letting a sales-point default silently replace the tenant default. Fix: keep compatibility fields secondary to the tenant key.
  • Raw-stock catalogue: displaying bottles, jars, labels, or ingredients as products. Fix: expose only active product-to-finished-stock mappings.
  • Sale-time recipe deduction: consuming ingredients when a product is sold. Fix: consume ingredients at manufacture and finished stock at sale.
  • Writer sprawl: separate fake sale/payment writers for each screen. Fix: use one canonical transaction boundary and adapters.
  • Permission shortcut: treating branch visibility as plant access. Fix: model and enforce plant permissions separately.
  • Retry duplication: generating a new idempotency key after a timeout. Fix: query the original key and reconcile before retrying.
  • False success: trusting a browser toast without invoice, stock, and GL evidence. Fix: verify persisted records and reconcile the posting.

Read next

  • External chwezi-design-engine/skills/06-sector-and-domain-ux/pos-and-retail-operations
  • skills/architecture/api-design-first
  • skills/finance-accounting/accounting-engine
  • skills/backend-databases/database-design-engineering
  • skills/security/vibe-security-skill
  • skills/sdlc-meta/advanced-testing-strategy
  • skills/devops-cloud/reliability-engineering
  • skills/sdlc-meta/skill-composition-standards

References

  • references/pos-operations-contract.md — detailed identity, transaction, permissions, and evidence contract.
  • skills/product-business/product-discovery/references/feature-planning/references/pos-mandatory-requirements.md — session and receipt controls.
  • skills/sdlc-meta/skill-composition-standards/references/test-plan-template.md — test evidence shape.
  • skills/sdlc-meta/skill-composition-standards/references/rollback-plan-template.md — rollback evidence shape.

Evidence Produced

CategoryArtifactFormatExample
CorrectnessPOS sale-to-ledger journey evidenceMarkdown plus transaction fixturescustomer, stock, payment, posting, retry, reversal, permission, and reconciliation

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Pos Sales Operations Engineering AI skill do?

Use when implementing or reviewing a tenant-aware ERP POS, agent POS, or manual sales-entry workflow where customer defaults, product-to-stock identity, inventory timing, payments, permissions, and audit-safe posting must remain consistent. Use the design engine for visual craft.

Why use Pos Sales Operations Engineering on TypingMind?

Because you install it once and use it with any model. Pos Sales Operations Engineering is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Pos Sales Operations Engineering in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/peterbamuhigire/chwezi-dev-engine/tree/main/skills/frontend-ux/pos-sales-operations-engineering. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Pos Sales Operations Engineering?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Pos Sales Operations Engineering?

As many as you like. As long as a model supports skills, you can use Pos Sales Operations Engineering with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Pos Sales Operations Engineering AI skill free?

Yes. It is published on GitHub by peterbamuhigire under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇