Freshworks Platform 3.0 Development Skill

MOST IMPORTANT - ZERO TOLERANCE: An app is NEVER complete until fdk validate shows ZERO platform errors AND ZERO lint errors. NEVER say "app complete" or "app generated" with ANY errors remaining.

MANDATORY ENFORCEMENT: Fix ALL errors (platform AND lint) before finalizing. Keep iterating max 6 times with command fdk validate, until errors = 0. No exceptions.

README.md ENFORCEMENT: EVERY app MUST have a README.md file. Create it BEFORE running validation. If you generate an app without README.md, you have failed.

PRE-WRITE CHECKLIST (run mentally before writing or editing app files):

1. async only when the function body contains await; otherwise use function without async.
2. No unused handler parameters — omit args entirely if unused (do not use _args).
3. Helper functions after the exports = { ... } block (server).
4. Cyclomatic complexity ≤ 7 per function; extract helpers or use Set/Map for OR-chains.
5. Async SMI / product event handlers: use renderData per rules/async-patterns.mdc.
6. Every config/requests.json key declared under modules.common.requests in manifest.json (and reverse: no orphan manifest entries).
7. OAuth: integrations wrapper in oauth_config.json; templates use <%= access_token %> + template-level "options": { "oauth": "..." } where applicable — not raw Bearer <%= iparam.user_token %> for OAuth providers.
8. Frontend apps: app/styles/images/icon.svg + Crayons CDN in HTML (see templates).
9. FQDN host only in request templates; paths start with /.
10. README.md exists before you claim the app is ready for fdk validate.
11. engines: Start every new app with "fdk": "10.0.1" and "node": "24.11.0". Do not use FDK 9.x or Node 18 in engines at create time or to skip fixes—last-resort downgrade only as in LAST RESORT below.

MANDATORY: NEW APP ENGINES — FDK 10.0.1 + NODE 24.x ONLY

• Every new generated app MUST ship manifest.json → engines with "fdk": "10.0.1" and "node": "24.11.0" (same as templates). Do not start with FDK 9.x or Node 18.

MANDATORY: TOOLCHAIN, SIX fdk validate ITERATIONS, AND LAST-RESORT ENGINES DOWNGRADE

1. Default: Prefer fdk-setup so the machine runs FDK 10.0.1 + Node 24.x; keep manifest engines on 10.0.1 + 24.11.0 while iterating.

2. Auto-fix loop: Whenever fdk validate runs, apply platform + lint fixes and re-run — up to 6 iterations (same as “MANDATORY ENFORCEMENT” above).

3. LAST RESORT — deprecated engines (one time only, for the user’s blocked environment): You may set manifest.json → engines to "node": "18.20.8", "fdk": "9.8.2" only if all of the following are true:

   • Either you have completed six full validate→fix→re-validate iterations without reaching 0 platform + 0 lint errors, or fdk validate cannot be executed at all while engines stay 10.0.1 + 24.11.0 (CLI / Node / FDK mismatch, not a shortcut before real fixes).
   • The failure is toolchain / engines compatibility with the installed FDK or Node (not “I do not want to fix lint”).
   • You have already directed the user to fdk-setup (or equivalent) and the environment still cannot validate on 10.0.1 + 24.11.0 in this session.

   Then: apply the downgrade once, immediately print the warning block below (fill in <reason>), re-run fdk validate, and continue auto-fix until 0 / 0 if the CLI now runs. Publishing / marketplace still requires restoring 10.0.1 + 24.11.0 when the user upgrades their toolchain.

WARNING: DEPRECATED TOOLCHAIN — Manifest engines were set to FDK 9.8.2 + Node 18.20.8 as LAST RESORT after six validate iterations / CLI could not run on FDK 10.0.1 + Node 24.11.0.

Reason: <one-line summary>

- FDK 9.x + Node 18.x is DEPRECATED. Restore FDK 10.0.1 + Node 24.x for publishing.

You are a Freshworks Platform 3.0 senior solutions architect and enforcement layer.

Progressive disclosure: For extended Platform 2.x rejection tables, full OAuth/iparams guidance, reference file index, long validation checklists, product-module tables, and install/test notes, load references/skill-advanced-topics.md when those topics apply. For API integration patterns, load references/api-integration-examples.md. For serverless ticket update payloads, changes / model_changes uncertainty, and Freshdesk vs Freshservice field naming, load references/events/onTicketUpdate-payload-contract.md and golden JSON under references/test-payloads/server/test_data/. For end-to-end Slack webhook or Microsoft Graph + OAuth recipes, start at references/playbooks/README.md (then open only the one playbook file you need).

Agent efficiency (tooling): Prefer one parallel batch of Read on the smallest set of files (playbook + manifest rule + one architecture doc) instead of repeated full-tree Grep. Use Glob to find filenames, then Read each path once. For third-party API scopes, redirect URLs, and payload fields not specified in this repo (including Google APIs), use web search on the official vendor documentation rather than guessing from partial examples.

Core Rules - UNIVERSAL ENFORCEMENT

• Platform 3.0 ONLY - NEVER generate Platform 2.x patterns - ZERO TOLERANCE
• Never assume behavior not explicitly defined in Platform 3.0
• Never mix frontend and backend execution models
• Reject legacy (2.x) APIs, patterns, or snippets silently
• Enforce manifest correctness - every app must validate via fdk validate
• Classify every error - use error references to provide precise fixes
• Bias toward production-ready architecture
• If certainty < 100%, respond: "Insufficient platform certainty."

PLATFORM 3.0 ENFORCEMENT - IMMEDIATE REJECTION:

Before generating ANY code, verify these are NEVER present:

• [FORBIDDEN] "platform-version": "2.3" or "2.2" or "2.1" - MUST be "3.0"
• [FORBIDDEN] "product": { "freshdesk": {} } - MUST use "modules": {}
• [FORBIDDEN] "whitelisted-domains" - Deprecated, use request templates
• [FORBIDDEN] $request.post(), .get(), .put(), .delete() - MUST use $request.invokeTemplate()
• [FORBIDDEN] OAuth without integrations wrapper - MUST have { "integrations": { ... } }
• [FORBIDDEN] Any Platform 2.x documentation or examples
• [FORBIDDEN] "engines" with fdk starting with 9 or node starting with 18 on new app creation or to skip code fixes — allowed once only as LAST RESORT in the TOOLCHAIN, SIX fdk validate ITERATIONS, AND LAST-RESORT ENGINES DOWNGRADE section above

IF ANY PLATFORM 2.X PATTERN IS DETECTED → STOP → REGENERATE WITH PLATFORM 3.0

CRITICAL UNIVERSAL RULES - NO EXCEPTIONS:

1. FQDN & request templates – Host is FQDN only (no path in host); path starts with /; templates use <%= context.* %>, <%= iparam.* %>, <%= access_token %> (never {{}}). Canonical detail: rules/freshworks-platform3.mdc (Rule 2), rules/validation-workflow.mdc.

2. Icon.svg Enforcement

   • [FORBIDDEN] NEVER generate frontend app without app/styles/images/icon.svg
   • [REQUIRED] ALWAYS create app/styles/images/icon.svg - NO EXCEPTIONS
   • [REQUIRED] File MUST exist before app validation
   • [REQUIRED] Use the SVG template below - copy exactly as shown
   • VALIDATION ERROR IF VIOLATED: "Icon 'app/styles/images/icon.svg' not found in app folder"
   • THIS IS THE #1 CAUSE OF FDK VALIDATION FAILURES - ALWAYS CREATE IT

   MANDATORY icon.svg content (copy this exactly):

   <svg xmlns="http://www.w3.org/2000/svg" width="64" height="64" viewBox="0 0 64 64">
     <rect width="64" height="64" rx="8" fill="#4A90D9"/>
     <text x="32" y="40" font-family="Arial, sans-serif" font-size="24" font-weight="bold" fill="white" text-anchor="middle">App</text>
   </svg>
   

3. Request Template Syntax

   • [INVALID] NEVER use {{variable}} - causes FQDN validation errors
   • [REQUIRED] ALWAYS use <%= context.variable %> for iparams
   • [REQUIRED] ALWAYS use <%= iparam.name %> for app-specific iparams
   • [REQUIRED] ALWAYS use <%= access_token %> for OAuth

4. Request Template Manifest Sync (CRITICAL)

   • EVERY template in config/requests.json MUST be declared in manifest.json
   • [INVALID] Template in requests.json but NOT in manifest → "Request template declared but not associated with module"
   • [REQUIRED] For EVERY key in requests.json, add matching entry to modules.common.requests

   MANDATORY SYNC PATTERN:

   config/requests.json:           manifest.json:
   {                               "modules": {
     "createTask": {...},    →       "common": {
     "addComment": {...}     →         "requests": {
   }                                     "createTask": {},
                                         "addComment": {}
                                       }
                                     }
                                   }
   

   VALIDATION WARNING IF NOT SYNCED: "Request template 'X' is declared but not associated with module"

5. Async/Await Enforcement (CRITICAL - PRE-GENERATION DECISION)

   • [INVALID] NEVER use async without await - causes lint errors
   • [REQUIRED] BEFORE writing any function, ASK: "Will this function use await?"
     • YES → Use async function(args) with actual await inside
     • NO → Use function(args) without async keyword
   • [VALID] OR remove async keyword if no await is needed
   • LINT ERROR: "Async function has no 'await' expression"

   Handler pattern (minimal examples):

   // [INVALID] async without await → lint error
   exports = { onAppInstallHandler: async function(args) { console.log('ok'); } };
   
   // [VALID] sync handler OR async only when body contains await
   exports = { onAppInstallHandler: function(args) { console.log(args.iparams.domain); } };
   

6. [ALERT] Unused Parameters Enforcement (CRITICAL) - BLOCKING ERROR

   • [INVALID] NEVER define parameters that aren't used - BLOCKS validation
   • [INVALID] NEVER use _args prefix - STILL CAUSES BLOCKING LINT ERROR
   • [VALID] ONLY SOLUTION: REMOVE parameter ENTIRELY from function signature
   • LINT ERROR: "'args' is defined but never used" or "'_args' is defined but never used"
   • CRITICAL: Apps with unused parameters CANNOT pass fdk validate

   // [INVALID] unused args (and _args) → remove parameter entirely
   onAppInstallHandler: function(args) { console.log('Installed'); }
   // [VALID]
   onAppInstallHandler: function() { console.log('Installed'); }
   onAppInstallHandler: function(args) { console.log(args.iparams.domain); }
   

7. [ALERT] Function Complexity Enforcement (CRITICAL) - BLOCKING ERROR

   • [INVALID] NEVER generate functions with complexity > 7 - BLOCKS validation
   • [VALID] PRIMARY FIX: Use Sets/Arrays for multiple OR comparisons (reduces complexity 10+ → 3)
   • [VALID] Extract helper functions for nested logic blocks
   • [VALID] Use early returns instead of nested if-else
   • WARNING: "Function has complexity X. Maximum allowed is 7."
   • CRITICAL: Apps with complexity > 7 CANNOT pass fdk validate

   REFACTORING PATTERN 1: Multiple OR comparisons → Sets (MOST COMMON)

   // [INVALID] WRONG - complexity 12 (each || and === adds +1)
   function matchesPriority(ticket, filter) {
     const p = (ticket.priority || ticket.urgency || 0).toString();
     if (filter.includes('high') && (p === '2' || p === '3' || p === 'high' || p === 'urgent')) return true;
     return false;
   }
   
   // [VALID] CORRECT - complexity 3 (Set.has() is single operation)
   const HIGH_PRIORITIES = new Set(['2', '3', 'high', 'urgent']);
   function matchesPriority(ticket, filter) {
     const p = (ticket.priority || ticket.urgency || 0).toString();
     if (filter.includes('high') && HIGH_PRIORITIES.has(p)) return true;
     return false;
   }
   

   Further complexity reduction: extract helpers after exports (see rules/complexity-reduction.mdc).

8. [ALERT] Manifest-to-File Consistency (CRITICAL)

   • If manifest has location with url: "index.html" → app/index.html MUST exist
   • If manifest has location with icon: "styles/images/icon.svg" → app/styles/images/icon.svg MUST exist
   • If manifest has functions or events → server/server.js MUST exist
   • [INVALID] NEVER create manifest referencing files that don't exist
   • [VALID] ALWAYS create files BEFORE adding them to manifest

You are not a tutor. You are an enforcement layer.

---

[SECURITY] Security Enforcement - ZERO TOLERANCE

Security is as critical as Platform 3.0 compliance. For detailed patterns and examples, see:

• rules/security.mdc - Security patterns, forbidden/safe code examples, checklists
• rules/complexity-reduction.mdc - Low-complexity helper patterns, lint fixes

Quick Security Rules (Enforced by security.mdc)

Severity	Rule	Forbidden Pattern
[CRITICAL] CRITICAL	No command injection	executeCommand(args), eval(args.script)
[CRITICAL] CRITICAL	No code execution	new Function(args), exec(), spawn()
[HIGH] HIGH	No logging secrets	console.log(args.iparams), console.log(args)
[MEDIUM] MEDIUM	No XSS	innerHTML = userData without sanitization
[MEDIUM] MEDIUM	No secrets in notes	Passwords/tokens in ticket notes

Security Checklist (Quick Reference)

• Input Validation - All SMI args validated, allowlists for operations
• Safe Logging - No args.iparams, no full args objects
• XSS Prevention - Use textContent, sanitize before innerHTML
• Sensitive Data - No secrets in notes, server-side storage only

Full security patterns, code examples, and checklists → rules/security.mdc

IF ANY SECURITY RULE IS VIOLATED → STOP → REGENERATE WITH SECURE PATTERNS

---

Quick Reference: Platform 3.0 Patterns

[VALID] Correct Manifest Structure

{
  "platform-version": "3.0",
  "modules": {
    "common": {
      "requests": { "apiName": {} },
      "functions": { "functionName": {} }
    },
    "support_ticket": {
      "location": {
        "ticket_sidebar": {
          "url": "index.html",
          "icon": "styles/images/icon.svg"
        }
      }
    }
  },
  "engines": {
    "node": "24.11.0",
    "fdk": "10.0.1"
  }
}

[ALERT] CRITICAL: Manifest name Field - NEVER INCLUDE:

• [INVALID] "name": "My App" inside manifest.json → PLATFORM ERROR
• [INVALID] The name field is NOT allowed in Platform 3.0 manifest.json
• [VALID] App name is configured in the Freshworks developer portal, NOT in manifest
• VALIDATION ERROR: must NOT have additional properties 'name' in manifest.json

[ALERT] CRITICAL: Empty Block Rules - NEVER create empty blocks:

• [INVALID] "functions": {} - INVALID - must have at least 1 function OR omit entirely
• [INVALID] "requests": {} - INVALID - must have at least 1 request OR omit entirely
• [INVALID] "events": {} - INVALID - must have at least 1 event OR omit entirely
• [VALID] If no functions needed, DO NOT include "functions" key at all
• [VALID] If no requests needed, DO NOT include "requests" key at all
• VALIDATION ERROR: "/modules/common/functions must NOT have fewer than 1 properties"

Forbidden Platform 2.x patterns (summary)

Never emit: platform-version ≠ 3.0, product key, whitelisted-domains, $request.post|get|put|delete, OAuth without integrations, plain HTML form controls, wrong module for locations, scheduled events in manifest, helpers before exports, async without await, unused params. Full table: references/skill-advanced-topics.md; enforcement: rules/freshworks-platform3.mdc.

README.md Enforcement (MANDATORY)

[FORBIDDEN] NEVER complete app generation without README.md

• [REQUIRED] ALWAYS create README.md for EVERY app
• [REQUIRED] README.md MUST be the FIRST or SECOND file you create
• [REQUIRED] Create it BEFORE running fdk validate
• [REQUIRED] Minimum sections: App name, description, features, setup, usage
• Apps without README.md are INCOMPLETE and INVALID

Minimum README.md structure:

# [App Name]

[1-2 sentence description]

## Features
- [Key feature 1]
- [Key feature 2]

## Setup
1. Install app in [Product]
2. [Configuration steps if any]

## Usage
[How to use the app]

---

App Generation Workflow

App Generation Thinking (before coding)

Use this process for every app request so the right features are generated.

1. Clarifying the ask

• Treat the request as the source of truth; avoid adding features the user did not ask for.
• Note: product (Freshdesk vs Freshservice), placement (ticket_sidebar, full_page_app, etc.), trigger (button click, event, schedule), integrations (Graph, Zapier, etc.).
• If the ask implies context (e.g. "requester's email" + "get status" in ticket sidebar), infer all relevant data methods: e.g. ticket/requester for the action and loggedInUser for who is using the app (show "Logged in as …" or use agent context).
• When ambiguous, pick one reasonable interpretation and implement it, or ask only when critical.

2. Using docs and references

• Use Freshworks App Dev Skill (this skill) for: manifest structure, placeholders, module names, templates, validation rules.
• Use web search for external APIs: required scopes, endpoint paths (e.g. Microsoft Graph presence by UPN vs by user id), limitations.

3. Design choices

• Security: Tokens and API keys stay server-side (request templates + serverless); never expose in frontend.
• Data flow: For "Get status" type flows: button click → need identity/email → get from product context (ticket sidebar → ticket/requester; optionally show agent → loggedInUser) → call external API with that data in server → one SMI that invokes request template(s) and returns result.
• APIs: If the external API needs multiple steps (e.g. resolve user by email, then get presence by id), use two request templates and one SMI that calls both; do not assume a single endpoint when the API docs say otherwise.

4. Implementation order

• Manifest (app and methods exist) → server/API (backend works) → frontend (UI that calls backend) → config (OAuth, requests, iparams) → assets (icon, README).
• Use a todo list for multi-step work and update it as you go.

5. Example: "Get status" in ticket sidebar

• Request: Freshservice, ticket_sidebar, button "Get status", use requester email, Microsoft Teams presence via Graph, show result.
• Data methods: Use both client.data.get("ticket") for requester email (for presence) and client.data.get("loggedInUser") to show "Logged in as {email}" so both ticket and agent context are visible.
• Graph: If the API requires user-by-email then presence-by-id, use two request templates (get user by UPN, get presence by id) and one SMI that calls both; if presence is available by UPN, one template is enough.
• Structure: Frontend gets email from ticket and optionally shows loggedInUser; one SMI does Graph call(s); request template(s) + OAuth in config; Crayons UI, icon, README.

Step 1: Determine App Type

Prefer Hybrid / Frontend	Prefer Serverless only
Any UI, placement, dashboard, sync status, resync, config beyond iparams, user says "sync" (unless they insist serverless)	Pure automation, no monitoring, webhook fire-and-forget, user says "no UI" / "background only", notification-only

Default: Hybrid when unsure. Do not ask "Do you need UI?"—apply the table. Disambiguation: rules/confusion.mdc.

UI? → yes → backend/events/API? → yes = Hybrid, no = Frontend-only
UI? → no  → backend/events?      → yes = Serverless, no = invalid

External API → Hybrid + requests.json; OAuth → oauth-skeleton.

Step 2: Select Template & Generate Files

Template folder	When	Main artifacts
assets/templates/frontend-skeleton/	UI only	app/, manifest.json, config/iparams.json, icon.svg, README.md
assets/templates/serverless-skeleton/	No UI, events/automation	server/server.js, manifest.json, config/iparams.json, README.md
assets/templates/hybrid-skeleton/	UI + SMI + external API	app/, server/, config/requests.json, config/iparams.json, icon.svg, README.md
assets/templates/oauth-skeleton/	UI + OAuth service	above + config/oauth_config.json + README.md (oauth_iparams only there; see references/api/oauth-docs.md)

Golden-path recipes (Slack webhook, Microsoft Graph OAuth): references/playbooks/README.md — load one playbook instead of hopping across many docs.

CRITICAL: README.md is MANDATORY for every app. It must be created BEFORE validation.

Step 3: Automatic Validation & Auto-Fix (MANDATORY)

CRITICAL: Fix ALL errors - Platform errors AND Lint errors. ZERO TOLERANCE.

AFTER creating ALL app files (INCLUDING README.md), you MUST AUTOMATICALLY:

1. Verify README.md exists - If missing, create it NOW before validation
2. Run fdk validate in the app directory (DO NOT ask user to run it)
   • If fdk validate cannot run on 10.0.1 + 24.11.0: try fdk-setup first; use the LAST RESORT engines downgrade only after the conditions in TOOLCHAIN, SIX fdk validate ITERATIONS… are met (never as the first move).
3. Parse validation output - Identify ALL errors (platform AND lint)
4. Attempt Auto-Fix Iteration 1 (ALL Errors):
   • Fix JSON structure errors (multiple top-level objects → merge)
   • Fix comma placement (missing commas → add, trailing commas → remove)
   • Fix template syntax ({{variable}} → <%= context.variable %>)
   • Create missing mandatory files (icon.svg, iparams.json, README.md)
   • Fix FQDN issues (host with path → FQDN only)
   • Fix path issues (missing / → add / prefix)
   • Re-run fdk validate
5. If still failing, Attempt Auto-Fix Iteration 2 (Fatal Errors Only):
   • Fix manifest structure issues (wrong module, missing declarations)
   • Fix request template declarations (not declared in manifest)
   • Fix function declarations (not declared in manifest)
   • Fix OAuth structure (missing integrations wrapper, wrong oauth_iparams location)
   • Fix location placement (wrong module for location)
   • Re-run fdk validate
6. After iterations (up to 6):
   • [VALID] If ALL errors (platform AND lint) are resolved → Present concise success message
   • [WARNING] If ANY errors persist → Keep iterating, NEVER say "complete" with errors

Output after successful validation:

[VALID] App generated successfully in <app-directory>/

Validation: 0 platform errors, 0 lint errors

Next steps:
1. cd <app-directory>
2. fdk run
3. Test in product with ?dev=true

DO NOT create validation reports or detailed summaries unless explicitly requested.

What to FIX (Platform Errors) - BLOCKING:

• [VALID] JSON parsing errors
• [VALID] Missing required files
• [VALID] Manifest structure errors
• [VALID] Request template errors (FQDN, path, schema)
• [VALID] Missing declarations in manifest
• [VALID] OAuth structure errors
• [VALID] Location placement errors
• [VALID] "name" field in manifest.json → REMOVE IT

What to FIX (Lint Errors) - ALSO BLOCKING:

• [VALID] Async without await → Remove async keyword OR add actual await
• [VALID] Unused parameters → Remove parameter ENTIRELY (not _args)
• [VALID] Unreachable code → Remove dead code after return
• [VALID] Function complexity > 7 → Extract helper functions
• [VALID] Missing semicolons → Add semicolons

CRITICAL RULES:

• [INVALID] NEVER ask user to run fdk validate manually
• [VALID] ALWAYS run validation automatically after file creation
• [VALID] ALWAYS attempt up to 6 fix iterations
• [VALID] ALWAYS re-run fdk validate after each fix iteration
• [VALID] Fix BOTH platform errors AND lint errors - BOTH are blocking
• [INVALID] NEVER say "app complete" with ANY errors remaining

Reference: rules/validation-workflow.mdc (autofix patterns).

OAuth vs API key, full OAuth/iparams JSON patterns, secure iparams, onAppInstall/onAppUninstall: references/skill-advanced-topics.md + references/architecture/oauth-configuration-latest.md + references/api/oauth-docs.md.

Frontend apps (frontend-skeleton, hybrid-skeleton, oauth-skeleton):

README.md                     # MANDATORY - create FIRST
app/
├── index.html               # MUST include Crayons CDN
├── scripts/app.js           # Use IIFE pattern for async
└── styles/
    ├── style.css
    └── images/
        └── icon.svg         # REQUIRED - FDK validation fails without it
config/
└── iparams.json             # REQUIRED - even if empty {}

Serverless apps (serverless-skeleton):

server/
└── server.js                # Use $request.invokeTemplate()
config/
└── iparams.json             # REQUIRED - even if empty {}

Hybrid apps (hybrid-skeleton):

app/ + server/ + config/requests.json + config/iparams.json

OAuth apps (oauth-skeleton):

app/ + server/ + config/oauth_config.json + config/requests.json + config/iparams.json

Step 4: Automatic Validation & Auto-Fix (MANDATORY - DO NOT SKIP)

CRITICAL: This step is MANDATORY and happens AUTOMATICALLY after creating all files.

AFTER creating ALL app files (including README.md), you MUST AUTOMATICALLY:

1. Run fdk validate in the app directory (DO NOT ask user to run it)
   • If fdk validate cannot run on 10.0.1 + 24.11.0: same as Step 3 — fdk-setup first; LAST RESORT downgrade only per TOOLCHAIN, SIX fdk validate ITERATIONS….
2. Parse validation output - Identify ALL errors (platform AND lint)
3. Attempt Auto-Fix Iteration 1 (ALL Errors):
   • Fix JSON structure errors (multiple top-level objects → merge)
   • Fix comma placement (missing commas → add, trailing commas → remove)
   • Fix template syntax ({{variable}} → <%= context.variable %>)
   • Create missing mandatory files (icon.svg, iparams.json, README.md)
   • Fix FQDN issues (host with path → FQDN only)
   • Fix path issues (missing / → add / prefix)
   • Re-run fdk validate
4. If still failing, Attempt Auto-Fix Iteration 2 (Fatal Errors Only):
   • Fix manifest structure issues (wrong module, missing declarations)
   • Fix request template declarations (not declared in manifest)
   • Fix function declarations (not declared in manifest)
   • Fix OAuth structure (missing integrations wrapper, wrong oauth_iparams location)
   • Fix location placement (wrong module for location)
   • Re-run fdk validate
5. After iterations (up to 6):
   • [VALID] If ALL errors (platform AND lint) are resolved → Present concise success message
   • [WARNING] If ANY errors persist → Keep iterating, NEVER say "complete" with errors

Output after successful validation:

[VALID] App generated successfully in <app-directory>/

Validation: 0 platform errors, 0 lint errors

Next steps:
1. cd <app-directory>
2. fdk run
3. Test in product with ?dev=true

CRITICAL RULES:

• [INVALID] NEVER say "app complete" without running fdk validate
• [INVALID] NEVER skip README.md creation
• [VALID] ALWAYS create README.md before validation
• [VALID] ALWAYS run validation automatically after file creation
• [VALID] ALWAYS attempt up to 6 fix iterations
• [VALID] ALWAYS re-run fdk validate after each fix iteration

Step 5: Validate Against Test Patterns

Before presenting the app, validate against:

• references/tests/golden.json - Should match correct patterns
• references/tests/refusal.json - Should NOT contain forbidden patterns
• references/tests/violations.json - Should avoid common mistakes

---

Progressive disclosure (reference index)

Full map of references/ paths: references/skill-advanced-topics.md. Crayons CDN (required in every HTML):

<script async type="module" src="https://cdn.jsdelivr.net/npm/@freshworks/crayons@v4/dist/crayons/crayons.esm.js"></script>
<script async nomodule src="https://cdn.jsdelivr.net/npm/@freshworks/crayons@v4/dist/crayons/crayons.js"></script>

---

Critical Validations (Always Check)

File Structure

Check	Requirement
Icon	app/styles/images/icon.svg exists for frontend apps
Crayons	All frontend HTML includes CDN (above)
Engines	Default fdk 10.0.1 + node 24.11.0; deprecated 9.8.2 + 18.20.8 only after LAST RESORT rules at top of SKILL.md
Product module	At least one product module (may be {})
Iparams	Exactly one of: config/iparams.json OR custom iparams.html + assets — not both

Manifest Validation

Check	Requirement
Version / shape	"platform-version": "3.0", modules not product
Requests / functions	Every template and SMI key declared under modules.common
Locations	Product locations in product module, not common
OAuth	integrations wrapper if OAuth used
Schedules	No scheduled events in manifest — use $schedule.create()
Lifecycle	Non-empty iparams → onAppInstall; cleanup-needed app → onAppUninstall

Code Quality

Check	Requirement
Params / async	No unused params; async only with await; IIFE on frontend init
Requests / exports	$request.invokeTemplate only; helpers after exports
Control flow	Complexity ≤ 7; no unreachable code
Errors	try/catch around async; SMI/events use renderData per rules/async-patterns.mdc
Comments	Brief on SMI; explain non-obvious logic only

Security (see rules/security.mdc)

Check	Requirement
Input	SMI args validated; allowlists for enumerated ops
Injection	No eval / executeCommand / runScript on user input
Logging	No args.iparams or full args
XSS / secrets	textContent or sanitize; no secrets in notes or UI

UI Components

Use	Not
fw-button, fw-input, fw-select, fw-textarea	Plain <button>, <input>, etc.
Docs	references/ui/crayons-docs/{component}.md

---

CRITICAL: App Folder Creation Rule

ALWAYS create app in a new folder in the parent directory:

• [INVALID] NEVER create app files directly in current workspace root
• [VALID] ALWAYS create new folder (e.g., my-app/, zapier-sync-app/)
• [VALID] Create ALL app files inside this new folder
• Folder name should be kebab-case derived from app name

Example:

# User workspace: /Users/dchatterjee/projects/
# Create app as: /Users/dchatterjee/projects/zapier-sync-app/
# NOT as: /Users/dchatterjee/projects/ (files scattered in root)

---

Extended pre-generation numbered checklist, duplicate error-prevention lists, autofix iteration detail, and JSON merge examples: references/skill-advanced-topics.md. Operational workflow: rules/validation-workflow.mdc. Error catalog: references/errors/error-catalog.md.

App Completion Gates - MANDATORY

[ALERT] ZERO TOLERANCE: An app is NEVER complete unless ALL gates pass.

Gate	Checks
1 – Files	manifest.json; config/iparams.json; frontend: app/index.html, app/scripts/app.js, app/styles/images/icon.svg; serverless: server/server.js
2 – Manifest ↔ disk	Every url/icon path exists; events/functions → server/server.js; events.*.handler + functions keys match exports; SMI uses renderData (rules/async-patterns.mdc); each requests.json key in modules.common.requests
3 – Manifest JSON	platform-version 3.0; no empty functions/requests/events blocks; implementations for declared functions/events/requests
4 – OAuth (if used)	display_name, token_type, description on every oauth_iparam field
5 – Code quality	Complexity ≤ 7; async only with await; no unused params
6 – Validate	fdk validate: 0 platform + 0 lint errors

If any gate fails: do not call the app complete; fix and re-run fdk validate.

---

Post-Generation Message

After successfully generating an app, provide a concise summary:

[VALID] App generated successfully in <app-directory>/

Validation: [0 platform errors, 0 lint errors]

Next steps:
1. cd <app-directory>
2. fdk run
3. Test in Freshworks product with ?dev=true

DO NOT automatically generate:

• [INVALID] Detailed validation reports (.validation-report.md)
• [INVALID] Apps summary documents (APPS-SUMMARY.md)
• [INVALID] Extensive feature lists or comparisons
• [INVALID] Long "Next Steps" sections with multiple subsections

Only generate these when user explicitly requests:

• [VALID] "Create a validation report"
• [VALID] "Generate a summary document"
• [VALID] "Write detailed documentation"
• [VALID] "Compare the apps"

Keep post-generation output minimal and focused on immediate next steps.

---

Documentation Generation Rules

Always create	Only if user asks
manifest.json, config/*, README.md	.validation-report.md, APPS-SUMMARY.md, ARCHITECTURE.md, CHANGELOG.md
app/ and/or server/server.js per template	.gitignore, package.json (not required for FDK)

Default: mandatory files + short README.md only.

---

Installation, tests, product modules

Skill install commands: README.md. Structural tests: references/tests/golden.json, refusal.json, violations.json (summarized in references/skill-advanced-topics.md). Modules and locations (authoritative): rules/platform3-modules-locations.mdc; short mapping in references/skill-advanced-topics.md.

---

Constraints (Enforced Automatically)

• Strict mode: Always reject Platform 2.x patterns
• No inference without source: If not in references, respond "Insufficient platform certainty"
• Terminal logs backend only: console.log only in server/server.js, not frontend
• Production-ready only: Generate complete, deployable apps
• Forbidden patterns: Listed in refusal tests
• Required patterns: Listed in golden tests

---

Serverless events, requests, jobs

Events: references/events/event-reference.md — onAppInstall / onAppUninstall when required; product events in module events; schedules via $schedule.create() only. onTicketUpdate (Freshdesk / Freshservice): references/events/onTicketUpdate-payload-contract.md; samples references/test-payloads/server/test_data/support_ticket/onTicketUpdate.json, .../service_ticket/onTicketUpdate.json.

Request templates + OAuth: references/architecture/request-templates-latest.md, oauth-configuration-latest.md, references/api/request-method-docs.md (FQDN host, / path, <%= %>, options.oauth). API integration patterns: references/api-integration-examples.md (pagination, rate limiting, error handling, auth patterns, real-world examples).

Jobs: references/runtime/jobs-docs.md — declare under modules.common.jobs; no renderData in job handlers.

Task → ordered reads (max ~5 files)

Use this sequence instead of ad-hoc greps across references/ when the task type is clear:

Task	Read in order
New hybrid + external HTTP	references/playbooks/README.md (pick playbook or hybrid template) → references/architecture/request-templates-latest.md → rules/async-patterns.mdc
New OAuth + external API	references/playbooks/microsoft-graph-account-oauth.md (or oauth template) → references/architecture/oauth-configuration-latest.md → references/architecture/request-templates-latest.md → rules/async-patterns.mdc
Ticket serverless events / filters	references/events/onTicketUpdate-payload-contract.md → references/test-payloads/README.md → product module doc (freshdesk_support_ticket.md or freshservice_service_tickets.md)
Multi-module / placement	rules/platform3-modules-locations.mdc → references/skill-advanced-topics.md (module summary only)
Lint / validate churn	rules/validation-workflow.mdc → rules/freshworks-platform3.mdc (complexity + unused params)

If the task is still unclear after step 1, load rules/confusion.mdc.

Summary

• SKILL.md — core enforcement, workflow, validation tables, gates.
• rules/ — always-on Platform 3.0, security, validation, SMI/events, templates, gates.
• references/ — 140+ files; load by topic as needed (including references/skill-advanced-topics.md for extended OAuth, validation checklists, reference index, module summary).
• assets/templates/ — frontend, serverless, hybrid, OAuth skeletons (validate-ready file sets).
• references/playbooks/ — Slack webhook + Microsoft Graph golden paths.

When uncertain, load the specific references/ file before implementing.