# How the ITKIT portals, design guides and videos were made — reusable prompt

This file explains, step by step, how each ITKIT product was built: the prototype portal, its documentation portal (the design guide for every screen), the walkthrough animations, the marketing film, the website, and the decks. Each stage has a prompt you can paste into Claude, or give to a design and video team, to rebuild a product or make a new one in the same style.

Fill in the `<angle-bracket>` fields. The table at the end lists the values used for all 20 products.

---

## 0. Master prompt (paste this first)

> You are building one product for ITKIT, a government-technology portfolio. The product is **<Product name>** (Arabic: **<Arabic name>**), in the **<family>** family. Its job: **<one-line tagline>**.
>
> Deliver, in this order:
> 1. an interactive **prototype portal**: a design canvas of mobile screens (390×844) and web screens (1440 wide), in English, with Arabic RTL copies of the key screens;
> 2. a **standards review** of 10–20 checks against the international standards for this business, and fixes for the gaps, added to the prototype as new screens or new sections;
> 3. a **help button and popover** on every screen, linking to that screen's page in the guide;
> 4. a **documentation portal** (design guide): one page per screen with its purpose, users, steps, business rules, tips, related screens, an animated walkthrough and a recording script, plus the standards table, the sources and the marketing film script, all in English and Arabic;
> 5. a **75-second marketing film** in English and in Arabic, built from the real prototype screens;
> 6. a **website entry** and a 15-slide **"Problem to Solution" deck** in English and in Arabic.
>
> Rules that apply everywhere:
> - Every text exists in English **and** natural Modern Standard Arabic (not transliteration). Arabic screens are true RTL.
> - Data is synthetic and Syrian in context (names such as Yara Sabbagh, Omar Khatib, Lina Darwish; places such as Damascus, Aleppo, Homs, Nasib border, Damascus Airport; SYP; dates in October 2026; IDs such as `DEC-EX-2026-118204`).
> - People decide; systems advise. Risk and anomaly scores always show their reasons and never hold, seize or refer anything on their own.
> - Do not claim customers, contracts, deployments or certifications. Say "designed to align with <standard>".
> - Plain, specific copy. No marketing filler.
> - Never remove a screen, a field, a link or a piece of interaction when you improve something. Changes are additions only.

---

## 1. The visual standard (one family look)

Every product uses the same government look, taken from the original TradeGate Customs prototype.

> Use this design standard for every screen:
>
> **Fonts:** `'Noto Sans','Noto Kufi Arabic',system-ui,sans-serif` (Arabic screens put Noto Kufi Arabic first). Codes and IDs use `'Geist Mono',monospace`.
>
> **Colours:**
> - Government green `#0B5A45`, dark `#063A2C`, header `#0A503E`, utility bar `#063A2C` (text `#D7E7E0`), dark panel `#073D2F`.
> - Gold `#B68A35`, light gold `#E2C88E` (on green), gold tint `#F8F2E6`, gold text `#7A5A1E`, gold border `#EADBBB`.
> - Ink `#161B22`, ink-2 `#344054`, muted `#5B6470`, section label `#98A2B3`.
> - Lines `#DFE3E6` / `#EEF1F2`, input border `#D0D5DD`, page ground `#F5F7F6`.
> - Status colours: success `#075C46` on `#E3F2EC`, warning `#9A5600` on `#FBF0DD`, danger `#AE2A20` on `#FBE9E7`, info `#1F55B8` on `#E8EEFB`.
>
> **Shape:** cards radius 16 (mobile 12–14); buttons and inputs radius 10; nav items 8; pills 999. Card shadow `0 1px 2px rgba(16,24,40,.05)`.
>
> **Type:** page title 32–36 px / 650 weight, letter-spacing −0.035em, with a gold 14 px kicker above it. Body text 14 px on web and 15 px on mobile; tables 13 px; KPIs 26 px.
>
> **Status:** always a pill with a dot and a word. Never show status by colour alone.
>
> **Internal web screen (staff):**
> 1. Utility bar: "<Product> · Internal system · Prototype · synthetic data", the date, A− / A / A+ text size, and Contrast.
> 2. Green header with a 3 px gold bottom border: a gold-outlined round crest with the product icon, a two-line title (small "ITKIT · <unit>" plus the Arabic name, big product name), then a date pill, an "عربي" link and a gold avatar.
> 3. White sidebar, 248–264 px wide. The active item has a white background, a 3 px gold inset on the inline-start side, and weight 600. At the bottom sits a "Prototype — synthetic data, integrations simulated" note card.
> 4. Main area: gold kicker, title, lead line, and actions on the right. The main dashboard has one dark "live" panel (`#073D2F`, gold glow, dot grid, 3 px gold top).
>
> **Public / citizen web page:**
> - Utility bar, then a white header with a 3 px gold bottom rule and a green sign-in button.
> - Green gradient hero with a faint gold diagonal-stripe pattern, and a white quick-action card with a gold top.
> - Dark green footer with a gold top rule.
>
> **Mobile screen (390×844):**
> - Green header band with a dot grid, a gold glow and a gold rule.
> - The first white card overlaps the band and has a gold top.
> - Quick-action tiles with a green top rule.
> - 50 px primary buttons, radius 10.
> - The active tab-bar item is green with a gold marker.
>
> **Icons:** inline stroke SVG, stroke width 1.8, round caps. No emoji.

---

## 2. The prototype portal (design canvas)

> Build the prototype for **<Product>** as a design canvas: one file per screen (`M1-Welcome`, `M2-…` for mobile; `W1-Overview`, `W2-…` for web; `AR-…` for Arabic copies), laid out on a board in rows (mobile row, web row, Arabic row), 80 px between frames and 120 px between rows. Each row gets a title note above it.
>
> **Screens.** Cover every journey the product has: <list the journeys, e.g. activate → verify → passkey → home → sign-in request → sign a document → share data → activity → recovery → appeal> for the citizen side, and <list, e.g. overview → adjudication queue → relying parties → developer portal → PKI → audit → assisted enrollment> for the staff side. Include error, denied, locked and empty states where a real user would meet them.
>
> **Interaction.** Screens link to each other with normal links, so a reviewer can click through each journey. Use small state toggles (tabs, expand/collapse, a selected row) where they help. Never build the page with scripts that create markup.
>
> **Arabic.** Make Arabic RTL copies (`AR-<same name>`) of the key screens:
> - `dir="rtl"`, with Noto Kufi Arabic first in the font stack and line-height +0.1.
> - Mirror left and right: positions, padding, text alignment, gradients, and back and chevron arrows.
> - Western digits.
> - Keep in Latin script, wrapped in `dir="ltr"`: product names, standards, IDs, hashes and times.
> - Levantine month names (تشرين الأول).
> - Arabic forms of names and places (يارا الصباغ، دمشق).
> - The language toggle reads "English" on the Arabic screen and "عربي" on the English one.
> - Use the product's official Arabic terms consistently. For identity, for example: مفتاح المرور، السجل المدني، التحقق من الحيوية، الجهة المعتمِدة.
>
> **Honesty.** Every screen carries "Prototype · synthetic data". No real logos, ministries or customers.

---

## 3. Standards review and gap fixes

> Review **<Product>** against the international standards and leading practice for its business. Examples by family:
>
> - **Identity:** NIST SP 800-63-4, FIDO2/WebAuthn, OpenID Connect, eIDAS 2.0, ICAO 9303, ISO/IEC 30107-3.
> - **Registries and census:** the UN vital statistics and census principles, the Washington Group short set, ICD-11.
> - **Justice:** ISO/IEC 27037 and 27041 (digital evidence), UNODC guidance.
> - **Health:** HL7 FHIR, IPS, SNOMED CT, LOINC, IHE, DICOM.
> - **Customs:** the WCO HS, the WCO Data Model, the Revised Kyoto Convention, SAFE 2025, WTO TFA, FATF Rec. 32 (cash and gold), ISO 17712 (seals), ISO 6346 (containers), eTIR.
> - **Airport and road gates:** IATA CUSS/CUWS, IATA BCBP (Res. 792), ICAO 9303 and Doc 9944 (ABC gates), ISO 17573 and EN 15509 (tolling).
> - **AI:** the NIST AI RMF.
> - **Everywhere:** WCAG 2.2 AA, ISO/IEC 27001:2022, NIST CSF 2.0.
>
> Confirm the current version of every standard on the web before citing it. Cite only sources you actually opened.
>
> Produce 10–20 checks. Each check gives:
> - the standard and clause;
> - what it requires;
> - how the prototype does today (met / partial / gap);
> - the fix, in English and Arabic;
> - the screens it touches.
>
> For every partial or gap a screen can show, change the prototype: add a screen, or add a section, field, state, step, consent text or audit entry to an existing one. Mark the new screens `added: true`. Put them in a new row titled "Standards additions". Delete nothing.

---

## 4. Help button and popover on every screen

> Give every screen a feature id `<productid>-<screen name in lowercase>` (for example `oneid-w2-adjudication`). Variants of the same screen (error, Arabic) share the id.
>
> **The button.** In the header (web: right side, before the avatar; mobile: the top row of the header band) add a round 38–44 px "?" button. Its label is "Help for this screen" (Arabic: «مساعدة لهذه الشاشة»).
>
> **The popover.**
> - A white card, 340 px wide (mobile: full width minus 32 px), with a 3 px gold top, radius 12 and a soft shadow.
> - Contents: the kicker "About this screen" (Arabic: «عن هذه الشاشة»), one sentence of purpose, and "How to use" with 3 numbered steps.
> - Two links: **Read the guide** → `<docs portal URL>#<featureid>` and **Watch the walkthrough** → `<docs portal URL>#<featureid>-video`.
> - A close button.
>
> On Arabic screens everything is in Arabic and mirrored.

---

## 5. The documentation portal (design guide for each screen)

The guide is one page per product, generated from a single bilingual data file. Its structure:

- **Top band:** product name in English and Arabic, its family, an EN/AR switch, and a link back to the prototype.
- **Side navigation:** Overview · Marketing film · Standards · each screen (grouped Mobile / Web / Standards additions) · Sources.
- **Overview:** 2–3 sentences of intro in each language, plus the screen counts.
- **Each screen page** (anchor `#<featureid>`):
  - the title, who uses it and its purpose;
  - **How to use this screen** (4–7 numbered steps);
  - **Rules on this screen** (2–5 business rules);
  - **Tips**, **Related screens**, and a link that opens the screen in the prototype;
  - **an animated walkthrough** (anchor `#<featureid>-video`): a 3–4 scene animation (scene types: title, phone, console, flow, stack, outcome; 5–8 s each), playable in the page, with captions in English and Arabic;
  - **a recording script** for a video team: 5–8 shots, each with a time code, the shot description and the voice-over, in both languages.
- **Standards:** a table of every check (standard · area · requirement · before: met/partial/gap · fix · screens).
- **Marketing film:** the film's title, length, audience, message and call to action, and the scene-by-scene script (time code · visual · on-screen text · voice-over · sound).
- **Sources:** title and link for every source opened.

> Write the documentation data for **<Product>** as one bilingual record, every text an `[English, Arabic]` pair:
>
> - `intro`
> - `standards[]`: `std`, `area`, `req`, `before`, `fix`, `screens`
> - `sources[]`
> - `marketing`:
>   - `title`, `length` (60–90 s), `audience`, `message`, `cta`
>   - `scenes[]`: 7–10 scenes, each with `t`, `visual`, `onscreen`, `vo` and `sound`
> - `features[]`: one per screen, each with:
>   - `id` and `screens`
>   - `added` (true for screens added by the standards review)
>   - `title`, `who`, `purpose`
>   - `steps` (4–7), `rules` (2–5), `tips`, `related`
>   - `walkthrough` (3–4 animated scenes)
>   - `script` (5–8 shots)
>
> Check that every screen in the canvas maps to exactly one feature id, and that it matches the screen's help link. Then build the page with the shared guide template: same layout, same green and gold styling, full RTL when Arabic is selected.

---

## 6. Video guidance

### 6a. Per-screen walkthroughs (inside the guide)

Built from the `walkthrough` scenes above and played inside the guide page with no video file. Each scene shows one moment of the screen:
- a phone or console frame with the real screen content;
- a flow of steps;
- a stack of cards;
- or an outcome card.

The caption is in the selected language. Use this as the "Watch the walkthrough" link target.

### 6b. The 75-second marketing film (MP4, English and Arabic)

> Turn the marketing script into a film built from the **real prototype screens**:
>
> 1. **Scene spec.** One film scene per script scene. The last scene is always the end card. Each scene gets a 2–3 word kicker. The headline is the script's on-screen line. The layouts are:
>    - `icons`: big icon tiles for the problem or a principle, optionally as a flow with arrows;
>    - `phone`: one phone with a headline and up to 3 chips beside it;
>    - `phones`: two phones side by side;
>    - `monitor`: a web screen in a monitor, with page pan and an optional callout card;
>    - `phone_monitor`: both together;
>    - `end`: product name, Arabic name, CTA and "by ITKIT".
>
>    Start with an `icons` scene for the problem. Use phone and monitor scenes in the middle, and at most one more `icons` scene.
>
>    Highlights (rectangles or ovals) point at the exact element the narration talks about, one at a time, timed to the words. Zoom stays at 1.15× or less, and grows upward so nothing covers the subtitle band (the bottom 150 px). Times are fractions of the scene, so narration length decides the final timing.
> 2. **Arabic screens.** The Arabic film shows Arabic screens. Make an RTL copy of every screen the film uses (rules in §2), render it at the English board size, and re-measure the highlight positions on the Arabic render.
> 3. **Narration.**
>    - English: a neural voice (Kokoro, voice `af_heart`). Product names are spelled for speech: "One I.D.", "eye Gates", "I.T. Kit".
>    - Arabic: a Levantine-friendly male voice (Piper `ar_JO-kareem`). The text gets full diacritics (tashkeel) so it is read correctly.
>    - Each scene stretches to fit its line plus a short pause.
> 4. **Music and sound.** A quiet minimal-tech bed (112 BPM, A-minor colours: Am9 · Fmaj7 · Cmaj7 · G6sus). It ducks under the voice. Soft whooshes on scene changes and ticks on highlights.
> 5. **Render.**
>    - 1920×1080, 30 fps, H.264 (CRF 18, high profile), AAC 192 kbps, loudness normalised to −16 LUFS.
>    - Burned-in subtitles in the film's language.
>    - Every frame is rendered from the same HTML engine, so the film and the prototype match pixel for pixel.
> 6. **Web copy.** Compress a web version (CRF 30, AAC 112 kbps). Take a poster frame at 30% of the duration for the website.
> 7. **Review.** Before rendering, check a 3-frames-per-scene contact sheet in both languages: no text over text, highlights on target, nothing clipped.

---

## 7. Website entry and decks

> **Website.** Add **<Product>** to the ITKIT single-page site as one record:
> - id, family, industry and capability tags;
> - a tagline of 60 characters or fewer, a pitch of 1–2 sentences, and 3 problems;
> - 8–16 modules, 5–9 journeys, the standards, integrations and limits;
> - links to the prototype and the guide;
> - a 5–6 scene in-page film and a 5-step guided demo with audit-event codes;
> - the marketing MP4 and poster in both languages.
>
> **Deck.** A 15-slide "Problem to Solution" deck in English and in Arabic, 1920×1080:
> - cover (with a prototype screenshot), the problem, our answer;
> - 6 "how it works" slides, each with a real prototype screenshot and an amber box on the element discussed;
> - what it includes, standards, integrations, safeguards, delivery, and the next step;
> - speaker notes on every slide.
>
> Type and colours: Archivo and IBM Plex Sans (Arabic: IBM Plex Sans Arabic), navy `#0F2340` and light `#F4F6F9`.

---

## 8. Quality checklist (run before calling a product done)

- [ ] Every screen is reachable by clicking from a journey start. No dead links.
- [ ] Every screen has the help button, and its feature id exists in the guide.
- [ ] Arabic screens: no English left except allowed Latin names and IDs, arrows mirrored, nothing clipped.
- [ ] Standards: every cited version confirmed; "designed to align with", never "certified".
- [ ] Guide: every screen page has steps, rules, a walkthrough and a script in both languages.
- [ ] Film: both languages rendered. Highlights on target. Subtitles readable. Loudness −16 LUFS.
- [ ] Synthetic data only. No claimed customers. People decide, systems advise.
- [ ] Additions only: compared with the previous version, no screen, field or link was removed.

---

## 9. The 20 products: values used

| # | Product | Arabic name | Family | Screens in guide | Standards checks | Film scenes / length | Key standards |
|---|---|---|---|---|---|---|---|
| 01 | OneID | الهوية الرقمية الموحدة | Identity and government services | 22 | 20 | 8 / 75 s | NIST SP 800-63A-4, ISO/IEC 30107-3, FIDO2 |
| 02 | OneService + OneGov | بوابة الخدمات الحكومية الموحدة | Identity and government services | 20 | 20 | 9 / 80 s | WCAG 2.2 (W3C Recommendation, 2023) |
| 03 | OneRegistry | السجلات الوطنية الموحدة | Identity and government services | 23 | 20 | 8 / 75 s | UN Vital Statistics Rev.3, WHO ICD-11 |
| 04 | OneCensus | التعداد والتسجيل الوطني | Identity and government services | 24 | 17 | 8 / 78 s | UN Census P&R Rev.3, Washington Group |
| 05 | OneJustice | منظومة العدالة الرقمية | Justice | 20 | 17 | 9 / 80 s | ISO/IEC 27037, ISO/IEC 27041 |
| 06 | OneHealth | المنصة الصحية الوطنية | Health | 21 | 20 | 8 / 75 s | HL7 FHIR R4/R5, IPS 2.0.1 |
| 07 | Customs HQ | المنظومة الجمركية المركزية | Customs | 7 | 14 | 8 / 80 s | WCO HS 2022, WTO TFA Art. 3, RKC |
| 08 | Customs Port Operations | عمليات المنافذ الجمركية | Customs | 8 | 12 | 8 / 80 s | ISO 17712, ISO 6346, SAFE 2025 |
| 09 | Customs Tariff | البحث العام في التعرفة الجمركية | Customs | 2 | 10 | 8 / 70 s | WTO TFA Art. 1 and 3 |
| 10 | Customs Declare | بوابة التصريح عن النقد والذهب | Customs | 6 | 12 | 8 / 75 s | FATF Rec. 32 |
| 11 | Customs Declare app | تطبيق التصريح عن النقد والذهب | Customs | 12 | 16 | 8 / 78 s | FATF Rec. 32 and its Interpretive Note |
| 12 | Customs Kiosk & Officer app | أكشاك التصريح وتطبيق موظف الجمارك | Customs | 12 | 17 | 8 / 80 s | ICAO Doc 9303 Parts 3, 4, 11–13 |
| 13 | Customs Bank Verify | التحقق المصرفي | Customs | 3 | 10 | 8 / 70 s | FATF Rec. 10, 20, 29, 32 |
| 14 | Customs Admin | إدارة المنظومة الجمركية | Customs | 5 | 10 | 8 / 65 s | NIST SP 800-53 AC-5, ISO/IEC 27001:2022 |
| 15 | Smart Transit | العبور الذكي | Customs | 22 | 19 | 8 / 75 s | UNECE eTIR, WTO TFA Art. 11 |
| 16 | iCheck | التسجيل الذاتي وتسليم الأمتعة | Airport and road gates | 9 | 14 | 8 / 75 s | IATA CUSS/CUWS, BCBP Res. 792 |
| 17 | iGates | بوابات الجوازات الإلكترونية | Airport and road gates | 14 | 15 | 8 / 80 s | ICAO Doc 9303 Parts 11–12, ICAO PKD |
| 18 | iBoard | قارئ الصعود إلى الطائرة | Airport and road gates | 5 | 11 | 7 / 70 s | IATA Res. 792 (BCBP) |
| 19 | iToll | تحصيل رسوم الطرق الذكي | Airport and road gates | 7 | 12 | 7 / 75 s | ISO 17573-1, EN 15509, EN ISO 14906 |
| 20 | ITKIT Anomaly Detection | منصة كشف الحالات الشاذة | Artificial intelligence | 3 | 12 | 8 / 70 s | NIST AI RMF 1.0 |

The products share prototype canvases:
- Customs HQ, Port Operations, Tariff, Declare, Bank Verify, Admin and Anomaly Detection: the **Customs** prototype.
- Declare app and Kiosk & Officer app: the **Customs Apps & Kiosk** prototype.
- iCheck, iGates, iBoard and iToll: the **Gate Platform** prototype.