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 (Arabic: ), in the family. Its job: .

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 ". - 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: " · 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 · " 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 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: for the citizen side, and 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 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 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:
2. icons: big icon tiles for the problem or a principle, optionally as a flow with arrows;
3. phone: one phone with a headline and up to 3 chips beside it;
4. phones: two phones side by side;
5. monitor: a web screen in a monitor, with page pan and an optional callout card;
6. phone_monitor: both together;
7. 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 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

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.