Skill This
AI Skill Report Card

Developing Canteen OS

B-62·Aug 12, 2026·Source: Web
Quick Start12 / 15

Before touching any file, classify it:

  1. Canteen OS Web → React + TypeScript + Smart UI Community Edition only.
  2. Canteen OS Expo Mobile → Expo + React Native + TypeScript, WhatsApp-like UX.
  3. Shared → API contracts, auth, business logic, data models, validation — no UI framework.

Then: inspect the relevant code first, confirm reality against this policy, and execute. Do not produce long analysis before making changes.

Recommendation▾
This is a highly project-specific skill (tied to a proprietary codebase called 'Canteen OS' with a specific 'Smart UI' library) — it's unclear if this generalizes beyond one internal project, which limits reusability and may not be appropriate as a general-purpose skill.
Workflow12 / 15

Progress:

  • Identify platform (Web / Mobile / Shared) for the files in scope
  • Inspect existing code/patterns actually in the repo (don't assume)
  • Verify Smart UI package/version if touching Web UI (Community Edition only)
  • Verify WhatsApp-like interaction pattern applies if touching Mobile UX
  • Implement using platform-correct technology
  • Remove redundant/dead code encountered along the way
  • Run relevant tests/build verification
  • Stop — no documentation, no README, no migration report

Step Detail

1. Classify before editing. If a change spans Web and Mobile, split the work: shared logic goes in shared layer, presentation stays platform-specific.

2. Inspect first, execute fast. Read the actual code, actual installed package.json/dependencies, and actual component usage before deciding an approach. Once you have enough evidence, act — do not keep re-analyzing or exploring alternatives that don't change the outcome.

3. Smart UI verification (Web only). Never assume a Smart UI feature exists in Community Edition. Check the installed package version and public CE docs/exports. If a needed feature only exists in Professional/Enterprise, build the equivalent with plain React/CSS instead of introducing a paid dependency.

4. WhatsApp-like UX verification (Mobile only). For conversational/operational flows (orders, tasks, notifications, staff/kitchen communication), map them onto messaging-app patterns (chat list, conversation view, bubbles, states, gestures) rather than shrinking desktop layouts. Keep Canteen OS branding and terminology — do not clone WhatsApp assets/branding.

5. Shared logic. Business rules, validation, auth, and data models live once, in shared code. Web and Mobile consume them; they don't reimplement them.

Recommendation▾
Examples are somewhat concrete but lack actual code snippets (e.g., show real React Native bubble component code vs a ported web form) to make the good/bad contrast tangible rather than descriptive.
Examples13 / 20

Example 1: Input: "Add an order-status update flow to mobile." Output: Implemented as a conversation-style thread (message bubbles for status events, timestamps, delivered/read-style indicators) using React Native components and existing shared order API/service — not a ported web form, no Smart UI involved.

Example 2: Input: "Add a data table for staff shifts on Web." Output: Verified Smart UI Community Edition grid component is installed and supports required features (sorting/paging). Used it directly. Did not reach for a Pro-only feature (e.g., advanced pivot/export) — built export via plain code instead.

Example 3: Input: "Make mobile order list look like the web dashboard." Output: Declined literal visual parity. Kept native list/virtualized FlatList with WhatsApp-like row pattern (avatar/icon, title, snippet, timestamp, unread badge) instead of replicating a dense desktop table.

Recommendation▾
Add a concrete decision-tree or file-path heuristic (e.g., 'if file is in /apps/web/ → Web rules') to make platform classification mechanical rather than requiring inference each time.
Best Practices
  • Treat "Smart UI Community Edition only" as a hard rule for Web — verify, don't assume.
  • Treat "WhatsApp-like UX, not WhatsApp clone" as the mobile UX target — behavior and ergonomics, not branding/assets.
  • Keep platform-specific presentation code separate; keep business logic, API contracts, and data models shared.
  • Make autonomous decisions once the codebase gives enough evidence — don't stall for more certainty than needed.
  • Prioritize implementation speed, correctness, and removal of redundant code over theoretical completeness.
  • Remove dead/duplicate code you encounter while implementing, rather than leaving it for later.
  • Only pull in a new skill/dependency if it's genuinely blocking implementation — not speculatively.
Common Pitfalls
  • Introducing Smart UI Professional/Enterprise/trial components into Web — forbidden, no exceptions.
  • Porting Smart UI Web Components into the Expo/React Native app — forbidden.
  • Shrinking desktop web layouts (dense tables, tiny controls, sidebars) into mobile screens instead of using native mobile/messaging patterns.
  • Rewriting working mobile architecture purely for visual similarity to Web.
  • Duplicating business logic separately in Web and Mobile instead of using the shared layer.
  • Spending excessive time on analysis, exploration, or alternative-comparison before making a change.
  • Creating README files, migration reports, architecture docs, changelogs, or other documentation during implementation — this happens separately, later.
  • Installing unrelated skills (documentation, technical-writing, generic skill-discovery, unrelated frameworks/DevOps/DB) that don't unblock the current implementation.
0
Grade B-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
12/15
Workflow
12/15
Examples
13/20
Completeness
14/20
Format
13/15
Conciseness
13/15
Save to My Skills