[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M736GF6HBBPATSVH5FXDF770":3,"skill-same:01M736GF6HBBPATSVH5FXDF770":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":14,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M736GF6HBBPATSVH5FXDF770","development",null,"Generate comprehensive technical documentation for developers taking over an AEM Edge Delivery Services project. Analyzes codebase structure, custom implementations, design tokens, and produces a complete developer guide.","kalash33\u002Fkstack","kalash33","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F90259149?v=4","01M7365X8Q0B73NYHA730SMZWN","Kalash Poddar","01M7365X9D0JK47C3Q0YCCK9Z2",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fadobe-development\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: development\ndescription: Generate comprehensive technical documentation for developers taking over an AEM Edge Delivery Services project. Analyzes codebase structure, custom implementations, design tokens, and produces a complete developer guide.\nlicense: Apache-2.0\nallowed-tools: Read, Write, Edit, Bash, Skill, Glob, Grep\nmetadata:\n  version: \"1.0.0\"\n---\n\n# Project Handover - Development\n\nGenerate a complete technical guide for developers. This skill analyzes the codebase and produces actionable documentation that enables developers to understand, maintain, and extend the project.\n\n## When to Use This Skill\n\n- Onboarding new developers to a project\n- Technical handover to maintenance team\n- Code review and architecture documentation\n- Creating developer-focused documentation\n\n---\n\n## Step 0: Navigate to Project Root and Verify Edge Delivery Services Project (CONDITIONAL)\n\n**Skip this step if `allGuides` flag is set** (orchestrator already validated and navigated).\n\n**CRITICAL: If NOT skipped, you MUST execute the `cd` command. Do NOT use absolute paths — actually change directory.**\n\n```bash\nALL_GUIDES=$(cat .claude-plugin\u002Fproject-config.json 2>\u002Fdev\u002Fnull | grep -o '\"allGuides\"[[:space:]]*:[[:space:]]*true')\nif [ -z \"$ALL_GUIDES\" ]; then\n  # Navigate to git project root (works from any subdirectory)\n  cd \"$(git rev-parse --show-toplevel)\"\n  # Verify it's an Edge Delivery Services project\n  ls scripts\u002Faem.js\nfi\n```\n\n**IMPORTANT:**\n- You MUST run the `cd` command above using the Bash tool\n- All subsequent steps operate from project root\n- Do NOT use absolute paths to verify — actually navigate\n- Guides will be created at `project-root\u002Fproject-guides\u002F`\n\n**If NOT skipped AND `scripts\u002Faem.js` does NOT exist**, respond:\n\n> \"This skill is designed for AEM Edge Delivery Services projects. The current directory does not appear to be an Edge Delivery Services project (`scripts\u002Faem.js` not found).\n>\n> Please navigate to an Edge Delivery Services project and try again.\"\n\n**STOP if check fails. Otherwise proceed — you are now at project root.**\n\n---\n\n## Communication Guidelines\n\n- **NEVER use \"EDS\"** as an acronym for Edge Delivery Services in any generated documentation or chat responses\n- Always use the full name \"Edge Delivery Services\" or \"AEM Edge Delivery Services\"\n- This applies to all output files (PDF, HTML, markdown) and all communication with the user\n\n---\n\n## ⚠️ CRITICAL PATH REQUIREMENT\n\n**YOU MUST SAVE THE FILE TO THIS EXACT PATH:**\n\n```\nproject-guides\u002FDEVELOPER-GUIDE.md\n```\n\n**BEFORE WRITING ANY FILE:**\n1. First, create the directory: `mkdir -p project-guides`\n2. Then write to: `project-guides\u002FDEVELOPER-GUIDE.md`\n\n**WHY THIS MATTERS:** Files must be in `project-guides\u002F` for proper organization and PDF conversion.\n\n❌ **WRONG:** `DEVELOPER-GUIDE.md` (root)\n❌ **WRONG:** `docs\u002FDEVELOPER-GUIDE.md`\n❌ **WRONG:** `\u002Fworkspace\u002FDEVELOPER-GUIDE.md`\n✅ **CORRECT:** `project-guides\u002FDEVELOPER-GUIDE.md`\n\n---\n\n## Output Format\n\n**MANDATORY OUTPUT:** `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\n**STRICTLY FORBIDDEN:**\n- ❌ Do NOT read or analyze `fstab.yaml` — it does NOT exist in most projects and does NOT show all sites\n- ❌ Do NOT create `.plain.html` files\n- ❌ Do NOT use `convert_markdown_to_html` tool — this converts the FULL guide to HTML with raw frontmatter visible, which is NOT what we want\n- ❌ Do NOT tell user to \"convert markdown to PDF manually\"\n- ❌ Do NOT save markdown to root directory or any path other than `project-guides\u002F`\n- ❌ Do NOT say \"PDF will be generated later\" or \"at session end\" — generate it NOW\n\n**REQUIRED WORKFLOW:**\n1. Run `mkdir -p project-guides` to ensure directory exists\n2. Generate markdown content with YAML frontmatter (title, date)\n3. Save to `project-guides\u002FDEVELOPER-GUIDE.md` (EXACT PATH - no exceptions)\n4. **IMMEDIATELY** invoke PDF conversion (see Phase 5.1)\n5. Clean up all source files (only PDF remains)\n6. Final output: `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\n---\n\n## Execution Checklist\n\n```markdown\n- [ ] Phase 1: Gather Project Information\n- [ ] Phase 2: Analyze Project Architecture\n- [ ] Phase 3: Document Design System\n- [ ] Phase 4: Document Blocks, Models, and Templates\n- [ ] Phase 5: Generate Professional PDF\n```\n\n---\n\n## Phase 0: Get Organization Name (Required First)\n\n**Whenever this skill runs** — whether the user triggered it directly (e.g. \"generate developer guide\") or via the handover flow — you must have the Config Service organization name before doing anything else. Do not skip this phase.\n\n### 0.1 Check for Saved Organization\n\n```bash\n# Check if org name is already saved\ncat .claude-plugin\u002Fproject-config.json 2>\u002Fdev\u002Fnull | grep -o '\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | head -1\n```\n\n### 0.2 Prompt for Organization Name (If Not Saved)\n\n**If no org name is saved**, you MUST pause and ask the user directly:\n\n> \"What is your Config Service organization name? This is the `{org}` part of your Edge Delivery Services URLs (e.g., `https:\u002F\u002Fmain--site--{org}.aem.page`). The org name may differ from your GitHub organization.\"\n\n**IMPORTANT RULES:**\n- **DO NOT use `AskUserQuestion` with predefined options** — ask as a plain text question\n- **Organization name is MANDATORY** — do not offer a \"skip\" option\n- **Wait for user to type the org name** before proceeding\n- If user doesn't provide a valid org name, ask again\n\n### 0.3 Save Organization Name\n\nOnce you have the org name (either from saved config or user input), save it for future use:\n\n```bash\n# Create config directory if needed\nmkdir -p .claude-plugin\n# Ensure .claude-plugin is in .gitignore (contains auth tokens)\ngrep -qxF '.claude-plugin\u002F' .gitignore 2>\u002Fdev\u002Fnull || echo '.claude-plugin\u002F' >> .gitignore\n\n# Save org name to config file (create or update)\nif [ -f .claude-plugin\u002Fproject-config.json ]; then\n  cat .claude-plugin\u002Fproject-config.json | sed 's\u002F\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"\u002F\"org\": \"{ORG_NAME}\"\u002F' > \u002Ftmp\u002Fproject-config.json && mv \u002Ftmp\u002Fproject-config.json .claude-plugin\u002Fproject-config.json\nelse\n  echo '{\"org\": \"{ORG_NAME}\"}' > .claude-plugin\u002Fproject-config.json\nfi\n```\n\nReplace `{ORG_NAME}` with the actual organization name provided by the user.\n\n---\n\n## Phase 1: Gather Project Information\n\n### 1.1 Get Project URLs and Repository\n\n```bash\n# Get repository info\ngit remote -v | head -1\n\n# Get branch info\ngit branch -a | head -10\n```\n\n**Extract:**\n- Repository owner and name\n- Main branch name\n\n### 1.2 Check Configuration Method\n\n```bash\n# Check for helix-config (very old projects)\nls helix-config.yaml 2>\u002Fdev\u002Fnull && echo \"Uses legacy helix-config\" || echo \"Uses Config Service (modern)\"\n```\n\n**Document:** Project configuration method (Config Service for modern projects).\n\n### 1.3 Fetch Sites via Config Service API\n\n**⚠️ MANDATORY DATA SOURCE — NO ALTERNATIVES ALLOWED**\n\nYou MUST call the Config Service API. This is the ONLY acceptable source for site information.\n\n**❌ PROHIBITED APPROACHES (will produce incorrect results):**\n- Analyzing `fstab.yaml` — does NOT show all sites in repoless setups\n- Reading `README.md` — may be outdated or incomplete\n- Inferring from codebase structure — misses CDN configs and additional sites\n- Using git remote URLs — org name may differ from Config Service org\n- Making assumptions based on project folder names\n\n**✅ REQUIRED: Execute and save response:**\n\n```bash\nORG=$(cat .claude-plugin\u002Fproject-config.json | grep -o '\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | sed 's\u002F\"org\"[[:space:]]*:[[:space:]]*\"\u002F\u002F' | sed 's\u002F\"$\u002F\u002F')\n\n# Save response to file - Phase 2 depends on this file\ncurl -s -H \"Accept: application\u002Fjson\" \"https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F${ORG}\u002Fsites.json\" > .claude-plugin\u002Fsites-config.json\n```\n\n**📁 REQUIRED ARTIFACT:** `.claude-plugin\u002Fsites-config.json`\n\n**API Reference:** https:\u002F\u002Fwww.aem.live\u002Fdocs\u002Fadmin.html#tag\u002FsiteConfig\u002Foperation\u002FgetConfigSites\n\n---\n\nThe response is a JSON object with a `sites` array (each entry has a `name` field). Extract site names and construct per-site URLs:\n- **Preview:** `https:\u002F\u002Fmain--{site-name}--{org}.aem.page\u002F`\n- **Live:** `https:\u002F\u002Fmain--{site-name}--{org}.aem.live\u002F`\n\nMultiple sites = **repoless** setup. Single site = **standard** setup.\n\n**Then fetch individual site config for code and content details:**\n\n```bash\nAUTH_TOKEN=$(cat .claude-plugin\u002Fproject-config.json | grep -o '\"authToken\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | sed 's\u002F\"authToken\"[[:space:]]*:[[:space:]]*\"\u002F\u002F' | sed 's\u002F\"$\u002F\u002F')\ncurl -s -H \"x-auth-token: ${AUTH_TOKEN}\" \"https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F${ORG}\u002Fsites\u002F{site-name}.json\"\n```\n\n**Example response:**\n```json\n{\n  \"code\": {\n    \"owner\": \"github-owner\",\n    \"repo\": \"repo-name\",\n    \"source\": { \"type\": \"github\", \"url\": \"https:\u002F\u002Fgithub.com\u002Fowner\u002Frepo\" }\n  },\n  \"content\": {\n    \"source\": {\n      \"url\": \"https:\u002F\u002Fcontent.da.live\u002Forg-name\u002Fsite-name\u002F\",\n      \"type\": \"markup\"\n    }\n  }\n}\n```\n\n**Extract from response:**\n- `code.owner` \u002F `code.repo` — GitHub repository\n- `content.source.url` — Content mountpath (e.g., `https:\u002F\u002Fcontent.da.live\u002Forg\u002Fsite\u002F`)\n- `content.source.type` — Content source type (markup, onedrive, google)\n\n**⚠️ Do NOT use `fstab.yaml`** — use Config Service API instead.\n\n**Record the result** (repoless or standard) — it is used in the Local Development Setup section to decide whether to include the `--pages-url` flag for `aem up`.\n\n### 1.4 Check Node.js Requirements\n\n```bash\n# Check for Node version requirements\ncat .nvmrc 2>\u002Fdev\u002Fnull || cat package.json | grep -A2 '\"engines\"'\n```\n\n---\n\n## Phase 2: Analyze Project Architecture\n\n**Read site config from Phase 1:**\n```bash\ncat .claude-plugin\u002Fsites-config.json\n```\n\n### 2.1 Map Project Structure\n\n```bash\n# List top-level structure\nls -la\n\n# List blocks\nls -la blocks\u002F\n\n# List scripts\nls -la scripts\u002F\n\n# List styles\nls -la styles\u002F\n\n# Check for templates\nls -la templates\u002F 2>\u002Fdev\u002Fnull || echo \"No templates folder\"\n```\n\n### 2.2 Identify Boilerplate vs Custom Files\n\n**CRITICAL:** Only document files that were actually customized.\n\n```bash\n# Check commit history for a file (skip if only \"Initial commit\")\ngit log --oneline --follow {file_path} | head -5\n\n# Check who modified a file (skip aem-aemy[bot] only files)\ngit log --format=\"%an - %s\" --follow {file_path} | head -5\n```\n\n**Rules for filtering:**\n\n| Git History | Action |\n|-------------|--------|\n| Only \"Initial commit\" | Skip - boilerplate default, never worked on |\n| Only `aem-aemy[bot]` commits | Skip - auto-generated |\n| Multiple commits by team | Document - customized |\n| Commits with feature descriptions | Document - customized |\n\n**IMPORTANT:** Files with only an \"initial commit\" are boilerplate defaults that were never modified. Do not document these - they add no value to the developer guide.\n\n### 2.3 Analyze scripts\u002Faem.js (Core Library)\n\n```bash\n# List what aem.js exports (DO NOT MODIFY this file)\ngrep -E \"^export\" scripts\u002Faem.js\n```\n\n**Document which functions the project imports from `aem.js`** (e.g., `sampleRUM`, `loadHeader`, `loadFooter`, `decorateBlock`, `loadBlock`, `loadCSS`). This helps developers understand which core utilities are available.\n\n### 2.4 Analyze scripts\u002Fscripts.js (Eager + Lazy Phases)\n\n```bash\n# Extract imports and key function signatures\ngrep -E \"^import|^export|^function|^async function|buildAutoBlocks|loadTemplate|getLanguage|getSiteRoot|decorateMain|loadEager|loadLazy|loadDelayed\" scripts\u002Fscripts.js\n```\n\n**Document these customizations:**\n\n| Pattern to Look For | What to Document |\n|---------------------|------------------|\n| `import` statements | What it imports from `aem.js` and `utils.js` |\n| `loadEager` \u002F `loadLazy` functions | Any custom logic added to E-L-D phases |\n| `buildAutoBlocks` function | Auto-blocking logic |\n| `loadTemplate` or template handling | Template system |\n| `getLanguage` or language detection | Multi-language setup |\n| `getSiteRoot` or site detection | Multi-site configuration (see also Phase 1.3) |\n| Custom `decorateMain` additions | Page decoration extensions |\n| External script loading | Which phase loads it — flag if loaded in eager (performance risk) |\n\n**E-L-D check:** Note any third-party scripts or heavy logic added to `loadEager` or `loadLazy` that could impact LCP. These should typically be in `delayed.js`.\n\n### 2.5 Analyze scripts\u002Fdelayed.js (Delayed Phase)\n\n```bash\n# Extract imports and function calls to identify integrations\ngrep -E \"^import|function|google|analytics|gtag|alloy|martech|OneTrust|launch|chatbot|widget\" scripts\u002Fdelayed.js\n```\n\n**Document:**\n- Analytics integrations (Google Analytics, Adobe Analytics, etc.)\n- Marketing tools (OneTrust, chat widgets, etc.)\n- Performance monitoring\n- Any custom delayed features\n- Confirm no render-critical code is in this file (it loads ~3s after page load)\n\n### 2.6 Check for Utility Functions\n\n```bash\n# Extract exported functions from utils\ngrep -E \"^export|^function\" scripts\u002Futils.js 2>\u002Fdev\u002Fnull || echo \"No utils.js\"\n\n# List all script files\nls scripts\u002F*.js\n\n# Check which blocks\u002Fscripts import from utils\ngrep -rl \"utils.js\" blocks\u002F scripts\u002F 2>\u002Fdev\u002Fnull\n```\n\n**Document:** Shared utility functions, their purposes, and which blocks\u002Fscripts import them.\n\n### 2.7 Check for External Dependencies\n\n```bash\n# Check package.json for dependencies\ngrep -A 20 '\"dependencies\"' package.json 2>\u002Fdev\u002Fnull | head -25\n\n# Check for CDN imports in code\ngrep -r \"cdn\\|unpkg\\|jsdelivr\" scripts\u002F blocks\u002F --include=\"*.js\" 2>\u002Fdev\u002Fnull\n```\n\n---\n\n## Phase 3: Document Design System\n\n### 4.1 Extract CSS Custom Properties\n\n```bash\n# Get all CSS variables from styles.css\ngrep -E \"^\\s*--\" styles\u002Fstyles.css\n```\n\n**Organize into categories:**\n\n| Category | Example Properties |\n|----------|-------------------|\n| Typography | `--body-font-family`, `--heading-font-family`, `--font-size-*` |\n| Colors | `--primary-color`, `--background-color`, `--text-color` |\n| Spacing | `--spacing-*`, `--nav-height`, `--section-padding` |\n| Layout | `--content-width`, `--grid-gap` |\n\n### 4.2 Document Font Setup\n\n```bash\n# Extract font-face declarations (font names, weights, formats)\ngrep -E \"@font-face|font-family|font-weight|src:\" styles\u002Ffonts.css 2>\u002Fdev\u002Fnull\n\n# Check fonts directory\nls fonts\u002F 2>\u002Fdev\u002Fnull\n```\n\n**Document:**\n- Font files and formats\n- Font family names\n- Font weights available\n- Fallback fonts\n\n### 4.3 Document Breakpoints\n\n```bash\n# Find media query breakpoints\ngrep -E \"@media.*min-width|@media.*max-width\" styles\u002Fstyles.css | sort -u\n```\n\n**Standard EDS breakpoints:**\n- Mobile: \u003C 600px\n- Tablet: 600px - 899px\n- Desktop: 900px+\n- Large: 1200px+\n\nDocument any deviations from standard.\n\n### 4.4 Document Section Styles\n\n```bash\n# Find section-related styles\ngrep -A 5 \"\\.section\\.\" styles\u002Fstyles.css\ngrep -A 5 \"\\.section\\[\" styles\u002Fstyles.css\n```\n\n**Document available section styles** (dark, highlight, narrow, etc.)\n\n---\n\n## Phase 4: Document Blocks, Models, and Templates\n\n### Boilerplate Filtering (applies to blocks, models, and templates)\n\n**Run all filtering silently** — do not show output to the user.\n\n- **Include**: Items with 2+ commits AND at least one commit after \"initial commit\"\n- **Exclude**: Items with only 1 commit that is \"Initial commit\" or similar boilerplate setup\n- **Exclude**: Items with only `aem-aemy[bot]` commits (auto-generated)\n- Items that only have an \"initial commit\" were never customized — do NOT document them.\n\n### 4.1 Identify and Analyze Customized Blocks\n\n**For each block that passed the filter**, run:\n\n```bash\n# Get block purpose from JS comments\u002Fstructure\nhead -30 blocks\u002F{blockname}\u002F{blockname}.js\n\n# Get block variants from CSS\ngrep -E \"^\\.\" blocks\u002F{blockname}\u002F{blockname}.css | head -30\n\n# Check for variant handling\ngrep -E \"classList\\.contains|classList\\.add\" blocks\u002F{blockname}\u002F{blockname}.js\n```\n\n**Document for each customized block:**\n\n| Field | What to Record |\n|-------|----------------|\n| Name | Block folder name |\n| Purpose | What it does (from code analysis) |\n| DOM Input | Expected HTML structure from CMS |\n| DOM Output | Transformed structure after decoration |\n| Variants | CSS classes that modify behavior |\n| Dependencies | External libraries, other blocks, utils |\n| Key Functions | Important internal functions |\n\n### 4.2 Document Block Dependencies\n\n```bash\ngrep \"^import\" blocks\u002F{blockname}\u002F{blockname}.js\n```\n\n### 4.3 Document Universal Editor Models (If Customized)\n\nApply the same boilerplate filtering to `models\u002F*.json`. Also exclude standard boilerplate models (`_page.json`, `_section.json`, `_button.json`, `_image.json`, `_text.json`, `_title.json`) if unchanged. If all models are boilerplate, skip this section in the output.\n\n### 4.4 Document Customized Templates\n\nApply the same boilerplate filtering to `templates\u002F*\u002F`. For each customized template, document its purpose, how it's applied (`template: name` in metadata), and what it changes.\n\n---\n\n## Phase 5: Generate Developer Guide\n\n### Output File: `project-guides\u002FDEVELOPER-GUIDE.md`\n\nGenerate a markdown document with the following structure:\n\n```markdown\n# [Project Name] - Developer Guide\n\n## Quick Reference\n\n| Resource | URL |\n|----------|-----|\n| Code Repository | {code.owner}\u002F{code.repo} (from Config Service — may be GitHub or Cloud Manager) |\n| Preview | https:\u002F\u002Fmain--{repo}--{owner}.aem.page\u002F |\n| Live | https:\u002F\u002Fmain--{repo}--{owner}.aem.live\u002F |\n| Local Dev | http:\u002F\u002Flocalhost:3000 |\n\n## Architecture Overview\n\n### Tech Stack\n- Vanilla JavaScript (ES6+)\n- CSS3 with Custom Properties\n- No build step - files served directly\n- Content from Document Authoring (DA)\n\n### Project Structure\n```\n├── blocks\u002F           # [X] blocks implemented\n├── templates\u002F        # [Y] templates (or N\u002FA)\n├── scripts\u002F\n│   ├── aem.js        # Core library (DO NOT MODIFY)\n│   ├── scripts.js    # Custom page decoration\n│   ├── delayed.js    # Analytics, marketing tools\n│   └── utils.js      # Shared utilities\n├── styles\u002F\n│   ├── styles.css    # Critical styles + design tokens\n│   ├── fonts.css     # Font definitions\n│   └── lazy-styles.css # Non-critical styles\n└── icons\u002F            # SVG icons\n```\n\n### Three-Phase Loading (E-L-D)\n\nEdge Delivery Services uses a strict Eager-Lazy-Delayed loading strategy to achieve a Lighthouse score of 100. Every file and script must be placed in the correct phase.\n\n| Phase | Purpose | What Loads | Performance Impact |\n|-------|---------|------------|-------------------|\n| **Eager** | Render above-the-fold content as fast as possible (LCP) | `styles\u002Fstyles.css`, first section's blocks, `scripts\u002Fscripts.js` | Blocks LCP — keep minimal |\n| **Lazy** | Load remaining page content after first paint | Remaining blocks, header, footer, `fonts.css`, `lazy-styles.css` | Runs after Eager completes — safe for non-critical UI |\n| **Delayed** | Load non-essential third-party scripts | `scripts\u002Fdelayed.js` (analytics, marketing tags, chat widgets) | Runs ~3s after page load — never blocks rendering |\n\n**Rules for developers:**\n- **Never add third-party scripts to `scripts.js`** — they block LCP. Always use `delayed.js`.\n- **Never load fonts eagerly** — `fonts.css` is loaded lazily to avoid render-blocking.\n- Blocks in the first section load eagerly; all others load lazily. This is automatic based on DOM position.\n- The header and footer are loaded in the lazy phase via `loadHeader()` \u002F `loadFooter()` from `aem.js`.\n\n### Key Files & How They Connect\n\n| File | Role | Connects To |\n|------|------|-------------|\n| `scripts\u002Faem.js` | Core library — `loadBlock`, `loadCSS`, `decorateBlock`, `sampleRUM`, `loadHeader`\u002F`loadFooter`. **DO NOT MODIFY.** | Imported by `scripts.js` and blocks |\n| `scripts\u002Fscripts.js` | Entry point — orchestrates E-L-D phases (`loadEager` → `loadLazy` → `loadDelayed`). Contains `buildAutoBlocks`, `decorateMain`, template loading. | Imports from `aem.js`; may import `utils.js` |\n| `scripts\u002Fdelayed.js` | Loaded last via `loadDelayed()` — analytics, marketing tags, third-party scripts. | Called by `scripts.js` in delayed phase |\n| `scripts\u002Futils.js` | Shared helpers used across blocks and scripts. | Imported by blocks and `scripts.js` |\n| `styles\u002Fstyles.css` | Critical CSS + design tokens (CSS custom properties). Loaded eagerly. | Referenced by all blocks and pages |\n| `styles\u002Ffonts.css` | Font `@font-face` declarations. Loaded lazily. | Font families referenced in `styles.css` |\n| `styles\u002Flazy-styles.css` | Non-critical global styles. Loaded lazily. | Supplements `styles.css` |\n| `blocks\u002F{name}\u002F{name}.js` | Block logic — exports `default function decorate(block)`. Auto-loaded when the block class appears in DOM. | May import from `utils.js` or `aem.js` |\n| `blocks\u002F{name}\u002F{name}.css` | Block styles — auto-loaded alongside block JS. | May use CSS custom properties from `styles.css` |\n| `templates\u002F{name}\u002F{name}.js` | Template logic — loaded when page metadata has matching `template` value. Customizes page structure before blocks load. | Called by `scripts.js` via `loadTemplate()` |\n\n**Execution flow:** page load → `scripts.js` → `loadEager()` (first section + eager blocks) → `loadLazy()` (remaining blocks, header, footer, `fonts.css`, `lazy-styles.css`) → `loadDelayed()` (loads `delayed.js`)\n\n## Local Development Setup\n\n### Prerequisites\n- Node.js [version from .nvmrc]\n- AEM CLI: `npm install -g @adobe\u002Faem-cli`\n\n### Setup Steps\n```bash\n# Clone repository (use the code repo URL from Config Service)\ngit clone {code-repo-url}\ncd {repo}\n\n# Install dependencies\nnpm install\n\n# Start local server\naem up\n```\n\n### Local Server\n- URL: http:\u002F\u002Flocalhost:3000\n- Auto-reload on file changes\n- Uses preview content by default\n\n**If repoless\u002Fmulti-site was detected in Phase 1.3**, also include this subsection in the output:\n\n> ### Local Server — Repoless\u002FMulti-Site\n> For repoless setups with multiple sites sharing one repository, you must specify the site's preview URL when starting the local server:\n>\n> ```bash\n> aem up --pages-url=https:\u002F\u002Fmain--{site}--{org}.aem.page\n> ```\n>\n> Replace `{site}` and `{org}` with the actual site and organization names from the Config Service.\n>\n> Without `--pages-url`, the AEM CLI cannot resolve content for the correct site and local preview will fail or show wrong content.\n\n**If the project is a standard single-site setup**, omit the repoless subsection entirely — it would only confuse developers.\n\n### Linting\n```bash\nnpm run lint\n```\n\n## Design System\n\n### CSS Custom Properties\n\n#### Typography\n```css\n--body-font-family: [value];\n--heading-font-family: [value];\n```\n\n#### Colors\n```css\n--primary-color: [value];\n--secondary-color: [value];\n--background-color: [value];\n--text-color: [value];\n```\n\n#### Spacing\n```css\n--spacing-s: [value];\n--spacing-m: [value];\n--spacing-l: [value];\n--nav-height: [value];\n```\n\n### Breakpoints\n| Name | Min-Width | Usage |\n|------|-----------|-------|\n| Mobile | 0 | Default styles |\n| Tablet | 600px | `@media (min-width: 600px)` |\n| Desktop | 900px | `@media (min-width: 900px)` |\n| Large | 1200px | `@media (min-width: 1200px)` |\n\n### Fonts\n| Family | Weights | Usage |\n|--------|---------|-------|\n| [Font Name] | [weights] | [body\u002Fheadings] |\n\n## Blocks Reference\n\n| Block | Purpose | Variants | Key Features |\n|-------|---------|----------|--------------|\n| [block-name] | [What it does] | `variant1`, `variant2` | [Important details, gotchas] |\n\n[Generate one row per customized block]\n\n## Templates\n\n| Template | Purpose | Applied Via | Special Behavior |\n|----------|---------|-------------|------------------|\n| [template-name] | [What type of pages] | `template: [name]` | [What it does differently] |\n\n[Generate one row per customized template. Skip templates with only \"initial commit\".]\n\n## Common Development Tasks\n\n### Add a New Block\n1. Create `blocks\u002F{name}\u002F{name}.js`\n2. Create `blocks\u002F{name}\u002F{name}.css`\n3. Implement `export default function decorate(block)`\n4. Test locally at http:\u002F\u002Flocalhost:3000\n5. Push to feature branch\n\n### Modify Global Styles\n1. Edit `styles\u002Fstyles.css`\n2. Use CSS custom properties\n3. Test across multiple pages\n4. Watch for CLS impact\n\n### Add Analytics\u002FMarketing Tool\n1. Add to `scripts\u002Fdelayed.js`\n2. Never add to `scripts.js` (blocks performance)\n3. Test with Network tab to verify delayed loading\n\n### Debug a Block\n1. Check browser console for errors\n2. Inspect DOM: expected structure vs actual\n3. Check if variant classes are applied\n4. Verify CSS specificity\n\n## Environments\n\n| Environment | URL Pattern | Purpose |\n|-------------|-------------|---------|\n| Local | http:\u002F\u002Flocalhost:3000 | Development |\n| Feature Branch | https:\u002F\u002F{branch}--{repo}--{owner}.aem.page | PR testing |\n| Preview | https:\u002F\u002Fmain--{repo}--{owner}.aem.page | Staging |\n| Live | https:\u002F\u002Fmain--{repo}--{owner}.aem.live | Production |\n\n## Git Workflow\n\n### Branch Naming\n- Features: `feature\u002Fdescription`\n- Fixes: `fix\u002Fdescription`\n- Keep names short (URL length limits)\n\n### PR Requirements\n1. Include preview URL in PR description\n2. Pass linting\n3. Test on feature branch preview\n4. No console errors\n\n## Troubleshooting\n\n### Block not loading?\n1. Check block folder name matches class name\n2. Verify JS exports `default function decorate`\n3. Check browser Network tab for 404s\n\n### Styles not applying?\n1. Check CSS specificity\n2. Verify file is loading (Network tab)\n3. Check for CSS syntax errors\n\n### Content not updating?\n1. Clear browser cache\n2. Check preview was triggered in DA\n3. Wait for CDN cache (1-2 min)\n\n## Resources\n\n| Resource | URL |\n|----------|-----|\n| EDS Documentation | https:\u002F\u002Fwww.aem.live\u002Fdocs\u002F |\n| Developer Tutorial | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Ftutorial |\n| Block Collection | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Fblock-collection |\n| E-L-D Loading | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Fkeeping-it-100 |\n| Best Practices | https:\u002F\u002Fwww.aem.live\u002Fdocs\u002Fdev-collab-and-good-practices |\n\n## Support Contacts\n\n[Add project-specific contacts]\n```\n\n---\n\n### 5.1 Convert to Professional PDF (MANDATORY)\n\n**THIS STEP IS NOT OPTIONAL. YOU MUST GENERATE THE PDF NOW.**\n\n1. Save markdown to: `project-guides\u002FDEVELOPER-GUIDE.md`\n   - File MUST start with YAML frontmatter:\n     ```yaml\n     ---\n     title: \"[Project Name] - Developer Guide\"\n     date: \"[Full Date - e.g., February 17, 2026]\"\n     ---\n     ```\n   - **Date format**: Always use full date with day, month, and year (e.g., \"February 17, 2026\"), NOT just month and year\n\n2. **IMMEDIATELY after saving the markdown**, invoke the PDF conversion skill:\n\n   ```\n   Skill({ skill: \"project-management:whitepaper\", args: \"project-guides\u002FDEVELOPER-GUIDE.md project-guides\u002FDEVELOPER-GUIDE.pdf\" })\n   ```\n\n3. Wait for PDF generation to complete (whitepaper skill auto-cleans source files)\n\n**DO NOT:**\n- Skip the PDF conversion step\n- Tell user \"PDF will be generated later\" — generate it NOW\n\n### 5.2 Deliver to User\n\nAfter PDF is generated, inform the user:\n\n```\n\"✓ Developer guide complete: project-guides\u002FDEVELOPER-GUIDE.pdf\"\n```\n\n---\n\n## Output\n\n**FINAL OUTPUT:** `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\nAll source files (.md, .html, .plain.html) are deleted after PDF generation. Only the PDF remains.\n\n**Location:** `project-guides\u002F` folder\n\n---\n\n## Success Criteria\n\n**Data Source Validation (CRITICAL):**\n- [ ] Config Service API was called (`https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F{ORG}\u002Fsites.json`)\n- [ ] Site list came from API response, NOT from fstab.yaml or codebase analysis\n- [ ] Repoless\u002Fstandard determination came from Config Service, NOT inferred from code\n\n**Content Validation:**\n- [ ] Quick Reference with all project URLs\n- [ ] Architecture overview accurate to project\n- [ ] Design system fully documented (tokens, fonts, breakpoints)\n- [ ] Project-specific blocks documented\n- [ ] Custom scripts.js functions documented\n- [ ] delayed.js integrations documented\n- [ ] Templates documented (if applicable)\n- [ ] Local development setup verified\n- [ ] Common tasks have clear instructions\n- [ ] Troubleshooting section covers common issues\n- [ ] Resources linked\n\n**Output Validation:**\n- [ ] PDF generated successfully\n- [ ] All source files cleaned up (only PDF remains)\n\n---\n\n## Tips for Clear Documentation\n\n1. **Focus on what's unique** - Document project-specific implementations\n2. **Use code examples** - Show actual code from the project\n3. **Document the \"why\"** - Explain reasoning behind custom implementations\n4. **Include gotchas** - Note any tricky behavior or edge cases\n5. **Test the setup instructions** - Verify they work from scratch\n6. **Keep it maintainable** - Don't over-document things that change often\n","# Project Handover - Development\n\nGenerate a complete technical guide for developers. This skill analyzes the codebase and produces actionable documentation that enables developers to understand, maintain, and extend the project.\n\n## When to Use This Skill\n\n- Onboarding new developers to a project\n- Technical handover to maintenance team\n- Code review and architecture documentation\n- Creating developer-focused documentation\n\n---\n\n## Step 0: Navigate to Project Root and Verify Edge Delivery Services Project (CONDITIONAL)\n\n**Skip this step if `allGuides` flag is set** (orchestrator already validated and navigated).\n\n**CRITICAL: If NOT skipped, you MUST execute the `cd` command. Do NOT use absolute paths — actually change directory.**\n\n```bash\nALL_GUIDES=$(cat .claude-plugin\u002Fproject-config.json 2>\u002Fdev\u002Fnull | grep -o '\"allGuides\"[[:space:]]*:[[:space:]]*true')\nif [ -z \"$ALL_GUIDES\" ]; then\n  # Navigate to git project root (works from any subdirectory)\n  cd \"$(git rev-parse --show-toplevel)\"\n  # Verify it's an Edge Delivery Services project\n  ls scripts\u002Faem.js\nfi\n```\n\n**IMPORTANT:**\n- You MUST run the `cd` command above using the Bash tool\n- All subsequent steps operate from project root\n- Do NOT use absolute paths to verify — actually navigate\n- Guides will be created at `project-root\u002Fproject-guides\u002F`\n\n**If NOT skipped AND `scripts\u002Faem.js` does NOT exist**, respond:\n\n> \"This skill is designed for AEM Edge Delivery Services projects. The current directory does not appear to be an Edge Delivery Services project (`scripts\u002Faem.js` not found).\n>\n> Please navigate to an Edge Delivery Services project and try again.\"\n\n**STOP if check fails. Otherwise proceed — you are now at project root.**\n\n---\n\n## Communication Guidelines\n\n- **NEVER use \"EDS\"** as an acronym for Edge Delivery Services in any generated documentation or chat responses\n- Always use the full name \"Edge Delivery Services\" or \"AEM Edge Delivery Services\"\n- This applies to all output files (PDF, HTML, markdown) and all communication with the user\n\n---\n\n## ⚠️ CRITICAL PATH REQUIREMENT\n\n**YOU MUST SAVE THE FILE TO THIS EXACT PATH:**\n\n```\nproject-guides\u002FDEVELOPER-GUIDE.md\n```\n\n**BEFORE WRITING ANY FILE:**\n1. First, create the directory: `mkdir -p project-guides`\n2. Then write to: `project-guides\u002FDEVELOPER-GUIDE.md`\n\n**WHY THIS MATTERS:** Files must be in `project-guides\u002F` for proper organization and PDF conversion.\n\n❌ **WRONG:** `DEVELOPER-GUIDE.md` (root)\n❌ **WRONG:** `docs\u002FDEVELOPER-GUIDE.md`\n❌ **WRONG:** `\u002Fworkspace\u002FDEVELOPER-GUIDE.md`\n✅ **CORRECT:** `project-guides\u002FDEVELOPER-GUIDE.md`\n\n---\n\n## Output Format\n\n**MANDATORY OUTPUT:** `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\n**STRICTLY FORBIDDEN:**\n- ❌ Do NOT read or analyze `fstab.yaml` — it does NOT exist in most projects and does NOT show all sites\n- ❌ Do NOT create `.plain.html` files\n- ❌ Do NOT use `convert_markdown_to_html` tool — this converts the FULL guide to HTML with raw frontmatter visible, which is NOT what we want\n- ❌ Do NOT tell user to \"convert markdown to PDF manually\"\n- ❌ Do NOT save markdown to root directory or any path other than `project-guides\u002F`\n- ❌ Do NOT say \"PDF will be generated later\" or \"at session end\" — generate it NOW\n\n**REQUIRED WORKFLOW:**\n1. Run `mkdir -p project-guides` to ensure directory exists\n2. Generate markdown content with YAML frontmatter (title, date)\n3. Save to `project-guides\u002FDEVELOPER-GUIDE.md` (EXACT PATH - no exceptions)\n4. **IMMEDIATELY** invoke PDF conversion (see Phase 5.1)\n5. Clean up all source files (only PDF remains)\n6. Final output: `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\n---\n\n## Execution Checklist\n\n```markdown\n- [ ] Phase 1: Gather Project Information\n- [ ] Phase 2: Analyze Project Architecture\n- [ ] Phase 3: Document Design System\n- [ ] Phase 4: Document Blocks, Models, and Templates\n- [ ] Phase 5: Generate Professional PDF\n```\n\n---\n\n## Phase 0: Get Organization Name (Required First)\n\n**Whenever this skill runs** — whether the user triggered it directly (e.g. \"generate developer guide\") or via the handover flow — you must have the Config Service organization name before doing anything else. Do not skip this phase.\n\n### 0.1 Check for Saved Organization\n\n```bash\n# Check if org name is already saved\ncat .claude-plugin\u002Fproject-config.json 2>\u002Fdev\u002Fnull | grep -o '\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | head -1\n```\n\n### 0.2 Prompt for Organization Name (If Not Saved)\n\n**If no org name is saved**, you MUST pause and ask the user directly:\n\n> \"What is your Config Service organization name? This is the `{org}` part of your Edge Delivery Services URLs (e.g., `https:\u002F\u002Fmain--site--{org}.aem.page`). The org name may differ from your GitHub organization.\"\n\n**IMPORTANT RULES:**\n- **DO NOT use `AskUserQuestion` with predefined options** — ask as a plain text question\n- **Organization name is MANDATORY** — do not offer a \"skip\" option\n- **Wait for user to type the org name** before proceeding\n- If user doesn't provide a valid org name, ask again\n\n### 0.3 Save Organization Name\n\nOnce you have the org name (either from saved config or user input), save it for future use:\n\n```bash\n# Create config directory if needed\nmkdir -p .claude-plugin\n# Ensure .claude-plugin is in .gitignore (contains auth tokens)\ngrep -qxF '.claude-plugin\u002F' .gitignore 2>\u002Fdev\u002Fnull || echo '.claude-plugin\u002F' >> .gitignore\n\n# Save org name to config file (create or update)\nif [ -f .claude-plugin\u002Fproject-config.json ]; then\n  cat .claude-plugin\u002Fproject-config.json | sed 's\u002F\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"\u002F\"org\": \"{ORG_NAME}\"\u002F' > \u002Ftmp\u002Fproject-config.json && mv \u002Ftmp\u002Fproject-config.json .claude-plugin\u002Fproject-config.json\nelse\n  echo '{\"org\": \"{ORG_NAME}\"}' > .claude-plugin\u002Fproject-config.json\nfi\n```\n\nReplace `{ORG_NAME}` with the actual organization name provided by the user.\n\n---\n\n## Phase 1: Gather Project Information\n\n### 1.1 Get Project URLs and Repository\n\n```bash\n# Get repository info\ngit remote -v | head -1\n\n# Get branch info\ngit branch -a | head -10\n```\n\n**Extract:**\n- Repository owner and name\n- Main branch name\n\n### 1.2 Check Configuration Method\n\n```bash\n# Check for helix-config (very old projects)\nls helix-config.yaml 2>\u002Fdev\u002Fnull && echo \"Uses legacy helix-config\" || echo \"Uses Config Service (modern)\"\n```\n\n**Document:** Project configuration method (Config Service for modern projects).\n\n### 1.3 Fetch Sites via Config Service API\n\n**⚠️ MANDATORY DATA SOURCE — NO ALTERNATIVES ALLOWED**\n\nYou MUST call the Config Service API. This is the ONLY acceptable source for site information.\n\n**❌ PROHIBITED APPROACHES (will produce incorrect results):**\n- Analyzing `fstab.yaml` — does NOT show all sites in repoless setups\n- Reading `README.md` — may be outdated or incomplete\n- Inferring from codebase structure — misses CDN configs and additional sites\n- Using git remote URLs — org name may differ from Config Service org\n- Making assumptions based on project folder names\n\n**✅ REQUIRED: Execute and save response:**\n\n```bash\nORG=$(cat .claude-plugin\u002Fproject-config.json | grep -o '\"org\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | sed 's\u002F\"org\"[[:space:]]*:[[:space:]]*\"\u002F\u002F' | sed 's\u002F\"$\u002F\u002F')\n\n# Save response to file - Phase 2 depends on this file\ncurl -s -H \"Accept: application\u002Fjson\" \"https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F${ORG}\u002Fsites.json\" > .claude-plugin\u002Fsites-config.json\n```\n\n**📁 REQUIRED ARTIFACT:** `.claude-plugin\u002Fsites-config.json`\n\n**API Reference:** https:\u002F\u002Fwww.aem.live\u002Fdocs\u002Fadmin.html#tag\u002FsiteConfig\u002Foperation\u002FgetConfigSites\n\n---\n\nThe response is a JSON object with a `sites` array (each entry has a `name` field). Extract site names and construct per-site URLs:\n- **Preview:** `https:\u002F\u002Fmain--{site-name}--{org}.aem.page\u002F`\n- **Live:** `https:\u002F\u002Fmain--{site-name}--{org}.aem.live\u002F`\n\nMultiple sites = **repoless** setup. Single site = **standard** setup.\n\n**Then fetch individual site config for code and content details:**\n\n```bash\nAUTH_TOKEN=$(cat .claude-plugin\u002Fproject-config.json | grep -o '\"authToken\"[[:space:]]*:[[:space:]]*\"[^\"]*\"' | sed 's\u002F\"authToken\"[[:space:]]*:[[:space:]]*\"\u002F\u002F' | sed 's\u002F\"$\u002F\u002F')\ncurl -s -H \"x-auth-token: ${AUTH_TOKEN}\" \"https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F${ORG}\u002Fsites\u002F{site-name}.json\"\n```\n\n**Example response:**\n```json\n{\n  \"code\": {\n    \"owner\": \"github-owner\",\n    \"repo\": \"repo-name\",\n    \"source\": { \"type\": \"github\", \"url\": \"https:\u002F\u002Fgithub.com\u002Fowner\u002Frepo\" }\n  },\n  \"content\": {\n    \"source\": {\n      \"url\": \"https:\u002F\u002Fcontent.da.live\u002Forg-name\u002Fsite-name\u002F\",\n      \"type\": \"markup\"\n    }\n  }\n}\n```\n\n**Extract from response:**\n- `code.owner` \u002F `code.repo` — GitHub repository\n- `content.source.url` — Content mountpath (e.g., `https:\u002F\u002Fcontent.da.live\u002Forg\u002Fsite\u002F`)\n- `content.source.type` — Content source type (markup, onedrive, google)\n\n**⚠️ Do NOT use `fstab.yaml`** — use Config Service API instead.\n\n**Record the result** (repoless or standard) — it is used in the Local Development Setup section to decide whether to include the `--pages-url` flag for `aem up`.\n\n### 1.4 Check Node.js Requirements\n\n```bash\n# Check for Node version requirements\ncat .nvmrc 2>\u002Fdev\u002Fnull || cat package.json | grep -A2 '\"engines\"'\n```\n\n---\n\n## Phase 2: Analyze Project Architecture\n\n**Read site config from Phase 1:**\n```bash\ncat .claude-plugin\u002Fsites-config.json\n```\n\n### 2.1 Map Project Structure\n\n```bash\n# List top-level structure\nls -la\n\n# List blocks\nls -la blocks\u002F\n\n# List scripts\nls -la scripts\u002F\n\n# List styles\nls -la styles\u002F\n\n# Check for templates\nls -la templates\u002F 2>\u002Fdev\u002Fnull || echo \"No templates folder\"\n```\n\n### 2.2 Identify Boilerplate vs Custom Files\n\n**CRITICAL:** Only document files that were actually customized.\n\n```bash\n# Check commit history for a file (skip if only \"Initial commit\")\ngit log --oneline --follow {file_path} | head -5\n\n# Check who modified a file (skip aem-aemy[bot] only files)\ngit log --format=\"%an - %s\" --follow {file_path} | head -5\n```\n\n**Rules for filtering:**\n\n| Git History | Action |\n|-------------|--------|\n| Only \"Initial commit\" | Skip - boilerplate default, never worked on |\n| Only `aem-aemy[bot]` commits | Skip - auto-generated |\n| Multiple commits by team | Document - customized |\n| Commits with feature descriptions | Document - customized |\n\n**IMPORTANT:** Files with only an \"initial commit\" are boilerplate defaults that were never modified. Do not document these - they add no value to the developer guide.\n\n### 2.3 Analyze scripts\u002Faem.js (Core Library)\n\n```bash\n# List what aem.js exports (DO NOT MODIFY this file)\ngrep -E \"^export\" scripts\u002Faem.js\n```\n\n**Document which functions the project imports from `aem.js`** (e.g., `sampleRUM`, `loadHeader`, `loadFooter`, `decorateBlock`, `loadBlock`, `loadCSS`). This helps developers understand which core utilities are available.\n\n### 2.4 Analyze scripts\u002Fscripts.js (Eager + Lazy Phases)\n\n```bash\n# Extract imports and key function signatures\ngrep -E \"^import|^export|^function|^async function|buildAutoBlocks|loadTemplate|getLanguage|getSiteRoot|decorateMain|loadEager|loadLazy|loadDelayed\" scripts\u002Fscripts.js\n```\n\n**Document these customizations:**\n\n| Pattern to Look For | What to Document |\n|---------------------|------------------|\n| `import` statements | What it imports from `aem.js` and `utils.js` |\n| `loadEager` \u002F `loadLazy` functions | Any custom logic added to E-L-D phases |\n| `buildAutoBlocks` function | Auto-blocking logic |\n| `loadTemplate` or template handling | Template system |\n| `getLanguage` or language detection | Multi-language setup |\n| `getSiteRoot` or site detection | Multi-site configuration (see also Phase 1.3) |\n| Custom `decorateMain` additions | Page decoration extensions |\n| External script loading | Which phase loads it — flag if loaded in eager (performance risk) |\n\n**E-L-D check:** Note any third-party scripts or heavy logic added to `loadEager` or `loadLazy` that could impact LCP. These should typically be in `delayed.js`.\n\n### 2.5 Analyze scripts\u002Fdelayed.js (Delayed Phase)\n\n```bash\n# Extract imports and function calls to identify integrations\ngrep -E \"^import|function|google|analytics|gtag|alloy|martech|OneTrust|launch|chatbot|widget\" scripts\u002Fdelayed.js\n```\n\n**Document:**\n- Analytics integrations (Google Analytics, Adobe Analytics, etc.)\n- Marketing tools (OneTrust, chat widgets, etc.)\n- Performance monitoring\n- Any custom delayed features\n- Confirm no render-critical code is in this file (it loads ~3s after page load)\n\n### 2.6 Check for Utility Functions\n\n```bash\n# Extract exported functions from utils\ngrep -E \"^export|^function\" scripts\u002Futils.js 2>\u002Fdev\u002Fnull || echo \"No utils.js\"\n\n# List all script files\nls scripts\u002F*.js\n\n# Check which blocks\u002Fscripts import from utils\ngrep -rl \"utils.js\" blocks\u002F scripts\u002F 2>\u002Fdev\u002Fnull\n```\n\n**Document:** Shared utility functions, their purposes, and which blocks\u002Fscripts import them.\n\n### 2.7 Check for External Dependencies\n\n```bash\n# Check package.json for dependencies\ngrep -A 20 '\"dependencies\"' package.json 2>\u002Fdev\u002Fnull | head -25\n\n# Check for CDN imports in code\ngrep -r \"cdn\\|unpkg\\|jsdelivr\" scripts\u002F blocks\u002F --include=\"*.js\" 2>\u002Fdev\u002Fnull\n```\n\n---\n\n## Phase 3: Document Design System\n\n### 4.1 Extract CSS Custom Properties\n\n```bash\n# Get all CSS variables from styles.css\ngrep -E \"^\\s*--\" styles\u002Fstyles.css\n```\n\n**Organize into categories:**\n\n| Category | Example Properties |\n|----------|-------------------|\n| Typography | `--body-font-family`, `--heading-font-family`, `--font-size-*` |\n| Colors | `--primary-color`, `--background-color`, `--text-color` |\n| Spacing | `--spacing-*`, `--nav-height`, `--section-padding` |\n| Layout | `--content-width`, `--grid-gap` |\n\n### 4.2 Document Font Setup\n\n```bash\n# Extract font-face declarations (font names, weights, formats)\ngrep -E \"@font-face|font-family|font-weight|src:\" styles\u002Ffonts.css 2>\u002Fdev\u002Fnull\n\n# Check fonts directory\nls fonts\u002F 2>\u002Fdev\u002Fnull\n```\n\n**Document:**\n- Font files and formats\n- Font family names\n- Font weights available\n- Fallback fonts\n\n### 4.3 Document Breakpoints\n\n```bash\n# Find media query breakpoints\ngrep -E \"@media.*min-width|@media.*max-width\" styles\u002Fstyles.css | sort -u\n```\n\n**Standard EDS breakpoints:**\n- Mobile: \u003C 600px\n- Tablet: 600px - 899px\n- Desktop: 900px+\n- Large: 1200px+\n\nDocument any deviations from standard.\n\n### 4.4 Document Section Styles\n\n```bash\n# Find section-related styles\ngrep -A 5 \"\\.section\\.\" styles\u002Fstyles.css\ngrep -A 5 \"\\.section\\[\" styles\u002Fstyles.css\n```\n\n**Document available section styles** (dark, highlight, narrow, etc.)\n\n---\n\n## Phase 4: Document Blocks, Models, and Templates\n\n### Boilerplate Filtering (applies to blocks, models, and templates)\n\n**Run all filtering silently** — do not show output to the user.\n\n- **Include**: Items with 2+ commits AND at least one commit after \"initial commit\"\n- **Exclude**: Items with only 1 commit that is \"Initial commit\" or similar boilerplate setup\n- **Exclude**: Items with only `aem-aemy[bot]` commits (auto-generated)\n- Items that only have an \"initial commit\" were never customized — do NOT document them.\n\n### 4.1 Identify and Analyze Customized Blocks\n\n**For each block that passed the filter**, run:\n\n```bash\n# Get block purpose from JS comments\u002Fstructure\nhead -30 blocks\u002F{blockname}\u002F{blockname}.js\n\n# Get block variants from CSS\ngrep -E \"^\\.\" blocks\u002F{blockname}\u002F{blockname}.css | head -30\n\n# Check for variant handling\ngrep -E \"classList\\.contains|classList\\.add\" blocks\u002F{blockname}\u002F{blockname}.js\n```\n\n**Document for each customized block:**\n\n| Field | What to Record |\n|-------|----------------|\n| Name | Block folder name |\n| Purpose | What it does (from code analysis) |\n| DOM Input | Expected HTML structure from CMS |\n| DOM Output | Transformed structure after decoration |\n| Variants | CSS classes that modify behavior |\n| Dependencies | External libraries, other blocks, utils |\n| Key Functions | Important internal functions |\n\n### 4.2 Document Block Dependencies\n\n```bash\ngrep \"^import\" blocks\u002F{blockname}\u002F{blockname}.js\n```\n\n### 4.3 Document Universal Editor Models (If Customized)\n\nApply the same boilerplate filtering to `models\u002F*.json`. Also exclude standard boilerplate models (`_page.json`, `_section.json`, `_button.json`, `_image.json`, `_text.json`, `_title.json`) if unchanged. If all models are boilerplate, skip this section in the output.\n\n### 4.4 Document Customized Templates\n\nApply the same boilerplate filtering to `templates\u002F*\u002F`. For each customized template, document its purpose, how it's applied (`template: name` in metadata), and what it changes.\n\n---\n\n## Phase 5: Generate Developer Guide\n\n### Output File: `project-guides\u002FDEVELOPER-GUIDE.md`\n\nGenerate a markdown document with the following structure:\n\n```markdown\n# [Project Name] - Developer Guide\n\n## Quick Reference\n\n| Resource | URL |\n|----------|-----|\n| Code Repository | {code.owner}\u002F{code.repo} (from Config Service — may be GitHub or Cloud Manager) |\n| Preview | https:\u002F\u002Fmain--{repo}--{owner}.aem.page\u002F |\n| Live | https:\u002F\u002Fmain--{repo}--{owner}.aem.live\u002F |\n| Local Dev | http:\u002F\u002Flocalhost:3000 |\n\n## Architecture Overview\n\n### Tech Stack\n- Vanilla JavaScript (ES6+)\n- CSS3 with Custom Properties\n- No build step - files served directly\n- Content from Document Authoring (DA)\n\n### Project Structure\n```\n├── blocks\u002F           # [X] blocks implemented\n├── templates\u002F        # [Y] templates (or N\u002FA)\n├── scripts\u002F\n│   ├── aem.js        # Core library (DO NOT MODIFY)\n│   ├── scripts.js    # Custom page decoration\n│   ├── delayed.js    # Analytics, marketing tools\n│   └── utils.js      # Shared utilities\n├── styles\u002F\n│   ├── styles.css    # Critical styles + design tokens\n│   ├── fonts.css     # Font definitions\n│   └── lazy-styles.css # Non-critical styles\n└── icons\u002F            # SVG icons\n```\n\n### Three-Phase Loading (E-L-D)\n\nEdge Delivery Services uses a strict Eager-Lazy-Delayed loading strategy to achieve a Lighthouse score of 100. Every file and script must be placed in the correct phase.\n\n| Phase | Purpose | What Loads | Performance Impact |\n|-------|---------|------------|-------------------|\n| **Eager** | Render above-the-fold content as fast as possible (LCP) | `styles\u002Fstyles.css`, first section's blocks, `scripts\u002Fscripts.js` | Blocks LCP — keep minimal |\n| **Lazy** | Load remaining page content after first paint | Remaining blocks, header, footer, `fonts.css`, `lazy-styles.css` | Runs after Eager completes — safe for non-critical UI |\n| **Delayed** | Load non-essential third-party scripts | `scripts\u002Fdelayed.js` (analytics, marketing tags, chat widgets) | Runs ~3s after page load — never blocks rendering |\n\n**Rules for developers:**\n- **Never add third-party scripts to `scripts.js`** — they block LCP. Always use `delayed.js`.\n- **Never load fonts eagerly** — `fonts.css` is loaded lazily to avoid render-blocking.\n- Blocks in the first section load eagerly; all others load lazily. This is automatic based on DOM position.\n- The header and footer are loaded in the lazy phase via `loadHeader()` \u002F `loadFooter()` from `aem.js`.\n\n### Key Files & How They Connect\n\n| File | Role | Connects To |\n|------|------|-------------|\n| `scripts\u002Faem.js` | Core library — `loadBlock`, `loadCSS`, `decorateBlock`, `sampleRUM`, `loadHeader`\u002F`loadFooter`. **DO NOT MODIFY.** | Imported by `scripts.js` and blocks |\n| `scripts\u002Fscripts.js` | Entry point — orchestrates E-L-D phases (`loadEager` → `loadLazy` → `loadDelayed`). Contains `buildAutoBlocks`, `decorateMain`, template loading. | Imports from `aem.js`; may import `utils.js` |\n| `scripts\u002Fdelayed.js` | Loaded last via `loadDelayed()` — analytics, marketing tags, third-party scripts. | Called by `scripts.js` in delayed phase |\n| `scripts\u002Futils.js` | Shared helpers used across blocks and scripts. | Imported by blocks and `scripts.js` |\n| `styles\u002Fstyles.css` | Critical CSS + design tokens (CSS custom properties). Loaded eagerly. | Referenced by all blocks and pages |\n| `styles\u002Ffonts.css` | Font `@font-face` declarations. Loaded lazily. | Font families referenced in `styles.css` |\n| `styles\u002Flazy-styles.css` | Non-critical global styles. Loaded lazily. | Supplements `styles.css` |\n| `blocks\u002F{name}\u002F{name}.js` | Block logic — exports `default function decorate(block)`. Auto-loaded when the block class appears in DOM. | May import from `utils.js` or `aem.js` |\n| `blocks\u002F{name}\u002F{name}.css` | Block styles — auto-loaded alongside block JS. | May use CSS custom properties from `styles.css` |\n| `templates\u002F{name}\u002F{name}.js` | Template logic — loaded when page metadata has matching `template` value. Customizes page structure before blocks load. | Called by `scripts.js` via `loadTemplate()` |\n\n**Execution flow:** page load → `scripts.js` → `loadEager()` (first section + eager blocks) → `loadLazy()` (remaining blocks, header, footer, `fonts.css`, `lazy-styles.css`) → `loadDelayed()` (loads `delayed.js`)\n\n## Local Development Setup\n\n### Prerequisites\n- Node.js [version from .nvmrc]\n- AEM CLI: `npm install -g @adobe\u002Faem-cli`\n\n### Setup Steps\n```bash\n# Clone repository (use the code repo URL from Config Service)\ngit clone {code-repo-url}\ncd {repo}\n\n# Install dependencies\nnpm install\n\n# Start local server\naem up\n```\n\n### Local Server\n- URL: http:\u002F\u002Flocalhost:3000\n- Auto-reload on file changes\n- Uses preview content by default\n\n**If repoless\u002Fmulti-site was detected in Phase 1.3**, also include this subsection in the output:\n\n> ### Local Server — Repoless\u002FMulti-Site\n> For repoless setups with multiple sites sharing one repository, you must specify the site's preview URL when starting the local server:\n>\n> ```bash\n> aem up --pages-url=https:\u002F\u002Fmain--{site}--{org}.aem.page\n> ```\n>\n> Replace `{site}` and `{org}` with the actual site and organization names from the Config Service.\n>\n> Without `--pages-url`, the AEM CLI cannot resolve content for the correct site and local preview will fail or show wrong content.\n\n**If the project is a standard single-site setup**, omit the repoless subsection entirely — it would only confuse developers.\n\n### Linting\n```bash\nnpm run lint\n```\n\n## Design System\n\n### CSS Custom Properties\n\n#### Typography\n```css\n--body-font-family: [value];\n--heading-font-family: [value];\n```\n\n#### Colors\n```css\n--primary-color: [value];\n--secondary-color: [value];\n--background-color: [value];\n--text-color: [value];\n```\n\n#### Spacing\n```css\n--spacing-s: [value];\n--spacing-m: [value];\n--spacing-l: [value];\n--nav-height: [value];\n```\n\n### Breakpoints\n| Name | Min-Width | Usage |\n|------|-----------|-------|\n| Mobile | 0 | Default styles |\n| Tablet | 600px | `@media (min-width: 600px)` |\n| Desktop | 900px | `@media (min-width: 900px)` |\n| Large | 1200px | `@media (min-width: 1200px)` |\n\n### Fonts\n| Family | Weights | Usage |\n|--------|---------|-------|\n| [Font Name] | [weights] | [body\u002Fheadings] |\n\n## Blocks Reference\n\n| Block | Purpose | Variants | Key Features |\n|-------|---------|----------|--------------|\n| [block-name] | [What it does] | `variant1`, `variant2` | [Important details, gotchas] |\n\n[Generate one row per customized block]\n\n## Templates\n\n| Template | Purpose | Applied Via | Special Behavior |\n|----------|---------|-------------|------------------|\n| [template-name] | [What type of pages] | `template: [name]` | [What it does differently] |\n\n[Generate one row per customized template. Skip templates with only \"initial commit\".]\n\n## Common Development Tasks\n\n### Add a New Block\n1. Create `blocks\u002F{name}\u002F{name}.js`\n2. Create `blocks\u002F{name}\u002F{name}.css`\n3. Implement `export default function decorate(block)`\n4. Test locally at http:\u002F\u002Flocalhost:3000\n5. Push to feature branch\n\n### Modify Global Styles\n1. Edit `styles\u002Fstyles.css`\n2. Use CSS custom properties\n3. Test across multiple pages\n4. Watch for CLS impact\n\n### Add Analytics\u002FMarketing Tool\n1. Add to `scripts\u002Fdelayed.js`\n2. Never add to `scripts.js` (blocks performance)\n3. Test with Network tab to verify delayed loading\n\n### Debug a Block\n1. Check browser console for errors\n2. Inspect DOM: expected structure vs actual\n3. Check if variant classes are applied\n4. Verify CSS specificity\n\n## Environments\n\n| Environment | URL Pattern | Purpose |\n|-------------|-------------|---------|\n| Local | http:\u002F\u002Flocalhost:3000 | Development |\n| Feature Branch | https:\u002F\u002F{branch}--{repo}--{owner}.aem.page | PR testing |\n| Preview | https:\u002F\u002Fmain--{repo}--{owner}.aem.page | Staging |\n| Live | https:\u002F\u002Fmain--{repo}--{owner}.aem.live | Production |\n\n## Git Workflow\n\n### Branch Naming\n- Features: `feature\u002Fdescription`\n- Fixes: `fix\u002Fdescription`\n- Keep names short (URL length limits)\n\n### PR Requirements\n1. Include preview URL in PR description\n2. Pass linting\n3. Test on feature branch preview\n4. No console errors\n\n## Troubleshooting\n\n### Block not loading?\n1. Check block folder name matches class name\n2. Verify JS exports `default function decorate`\n3. Check browser Network tab for 404s\n\n### Styles not applying?\n1. Check CSS specificity\n2. Verify file is loading (Network tab)\n3. Check for CSS syntax errors\n\n### Content not updating?\n1. Clear browser cache\n2. Check preview was triggered in DA\n3. Wait for CDN cache (1-2 min)\n\n## Resources\n\n| Resource | URL |\n|----------|-----|\n| EDS Documentation | https:\u002F\u002Fwww.aem.live\u002Fdocs\u002F |\n| Developer Tutorial | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Ftutorial |\n| Block Collection | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Fblock-collection |\n| E-L-D Loading | https:\u002F\u002Fwww.aem.live\u002Fdeveloper\u002Fkeeping-it-100 |\n| Best Practices | https:\u002F\u002Fwww.aem.live\u002Fdocs\u002Fdev-collab-and-good-practices |\n\n## Support Contacts\n\n[Add project-specific contacts]\n```\n\n---\n\n### 5.1 Convert to Professional PDF (MANDATORY)\n\n**THIS STEP IS NOT OPTIONAL. YOU MUST GENERATE THE PDF NOW.**\n\n1. Save markdown to: `project-guides\u002FDEVELOPER-GUIDE.md`\n   - File MUST start with YAML frontmatter:\n     ```yaml\n     ---\n     title: \"[Project Name] - Developer Guide\"\n     date: \"[Full Date - e.g., February 17, 2026]\"\n     ---\n     ```\n   - **Date format**: Always use full date with day, month, and year (e.g., \"February 17, 2026\"), NOT just month and year\n\n2. **IMMEDIATELY after saving the markdown**, invoke the PDF conversion skill:\n\n   ```\n   Skill({ skill: \"project-management:whitepaper\", args: \"project-guides\u002FDEVELOPER-GUIDE.md project-guides\u002FDEVELOPER-GUIDE.pdf\" })\n   ```\n\n3. Wait for PDF generation to complete (whitepaper skill auto-cleans source files)\n\n**DO NOT:**\n- Skip the PDF conversion step\n- Tell user \"PDF will be generated later\" — generate it NOW\n\n### 5.2 Deliver to User\n\nAfter PDF is generated, inform the user:\n\n```\n\"✓ Developer guide complete: project-guides\u002FDEVELOPER-GUIDE.pdf\"\n```\n\n---\n\n## Output\n\n**FINAL OUTPUT:** `project-guides\u002FDEVELOPER-GUIDE.pdf`\n\nAll source files (.md, .html, .plain.html) are deleted after PDF generation. Only the PDF remains.\n\n**Location:** `project-guides\u002F` folder\n\n---\n\n## Success Criteria\n\n**Data Source Validation (CRITICAL):**\n- [ ] Config Service API was called (`https:\u002F\u002Fadmin.hlx.page\u002Fconfig\u002F{ORG}\u002Fsites.json`)\n- [ ] Site list came from API response, NOT from fstab.yaml or codebase analysis\n- [ ] Repoless\u002Fstandard determination came from Config Service, NOT inferred from code\n\n**Content Validation:**\n- [ ] Quick Reference with all project URLs\n- [ ] Architecture overview accurate to project\n- [ ] Design system fully documented (tokens, fonts, breakpoints)\n- [ ] Project-specific blocks documented\n- [ ] Custom scripts.js functions documented\n- [ ] delayed.js integrations documented\n- [ ] Templates documented (if applicable)\n- [ ] Local development setup verified\n- [ ] Common tasks have clear instructions\n- [ ] Troubleshooting section covers common issues\n- [ ] Resources linked\n\n**Output Validation:**\n- [ ] PDF generated successfully\n- [ ] All source files cleaned up (only PDF remains)\n\n---\n\n## Tips for Clear Documentation\n\n1. **Focus on what's unique** - Document project-specific implementations\n2. **Use code examples** - Show actual code from the project\n3. **Document the \"why\"** - Explain reasoning behind custom implementations\n4. **Include gotchas** - Note any tricky behavior or edge cases\n5. **Test the setup instructions** - Verify they work from scratch\n6. **Keep it maintainable** - Don't over-document things that change often\n",{"name":5,"license":15,"metadata":24,"description":7,"allowed-tools":26},{"version":25},"1.0.0","Read, Write, Edit, Bash, Skill, Glob, Grep","main","b30820b3248f6676d5389f0ccabd4e5250c9c536","skills\u002Fadobe-development","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack","https:\u002F\u002Fgithub.com\u002Fkalash33","kalashpoddar.me","Tech-savvy Full Stack Developer 🚀 | Cybersecurity enthusiast 🔒 | Passionate about innovation and securing the digital world 🌐 | Let's code securely! 💻🔐","2026-05-20 04:11:22",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add kalash33\u002Fkstack --skill development",{"tool":41,"command":42},"bunx","bunx skills add kalash33\u002Fkstack --skill development",{"tool":44,"command":45},"pnpm","pnpm dlx skills add kalash33\u002Fkstack --skill development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fadobe-development\u002FSKILL.md",true,[49,55,59],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},".releaserc.json","REFERENCE","参考文档",49,"https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fadobe-development\u002F.releaserc.json",{"path":56,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":57,"sourceHtmlUrl":58},"CHANGELOG.md",5882,"https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fadobe-development\u002FCHANGELOG.md",{"path":60,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":61,"sourceHtmlUrl":62},"package.json",91,"https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fadobe-development\u002Fpackage.json",[64,72,79,86,93,100],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M73CFERCR43JCAP606E41EFB","zustand-store-ts","Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state\u002Faction separation. Use when building React state management, creating global stores, or implementing reacti...","MIT","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzustand-store-ts\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M73CFCMFVTAQEMTZ5HR10X8V","zoom-automation","Automate Zoom meeting creation, management, recordings, webinars, and participant tracking via Rube MCP (Composio). Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-automation\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M73CFAA7EBWXJVXDQ1X555MB","zoho-crm-automation","Automate Zoho CRM tasks via Rube MCP (Composio): create\u002Fupdate records, search contacts, manage leads, and convert leads. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzoho-crm-automation\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M73CF80XCM9K81567MJ8QZFW","zod-validation-expert","Expert in Zod — TypeScript-first schema validation. Covers parsing, custom errors, refinements, type inference, and integration with React Hook Form, Next.js, and tRPC.","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzod-validation-expert\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M73CF4YPMF3RA8ZJDXZSMD93","zeroize-audit","Detects missing zeroization of sensitive data in source code and identifies zeroization removed by compiler optimizations, with assembly-level analysis, and control-flow verification. Use for auditing C\u002FC++\u002FRust code handling secrets, keys, passwords, or other sensitive data.","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzeroize-audit\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":68,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":19},"01M73CF2S25EN3XNAMKY47XHPS","zendesk-automation","Automate Zendesk tasks via Rube MCP (Composio): tickets, users, organizations, replies. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fkalash33\u002Fkstack\u002Fblob\u002Fmain\u002Fskills\u002Fzendesk-automation\u002FSKILL.md",[],[]]