[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MCYRRCRSS8DK3AN3V27FD":3,"skill-same:01M71MCYRRCRSS8DK3AN3V27FD":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":55},"01M71MCYRRCRSS8DK3AN3V27FD","grill",null,"Run an explicitly requested decision interview and record each settled decision in durable project documentation.","marshadgani\u002FArshad.AI","marshadgani","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F275367399?v=4","01M71G2BP4YMZ4AX5YY0QBHAZH","01M71G2BPPHHFRMHQAKJTZPGK4",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fsystem-prompts-leaks\u002Fgrill\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27],"documentation","interview","record","project documentation","github","project","run","https","decision","decision interview","2026-11-10 10:56:23",false,"---\nname: grill\ndescription: Run an explicitly requested decision interview and record each settled decision in durable project documentation.\nsource: https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\nlicense: MIT\n---\n\n# Grill\n\nUse this skill only when the user explicitly asks for grilling plus durable documentation or directly invokes this skill; the `agents` coordinator handing it an unclear goal, or one decision needing the user's confirmation, before its plan is a direct invocation (its question is the user's judgement — target, measure, scope — that repository facts shape but never answer), and there the durable record is the project's own `PROJECT.md` or `library\u002F` file, never a repository doc. Complexity, ambiguity, or a possible need for docs alone never activates it. This skill carries its own interview and documentation contract. Do not load or invoke `domain-modeling` at runtime.\n\n## Interview Contract\n\n1. Research discoverable facts in the repository, issue, docs, and code before asking the user. Ask only for judgments or facts that cannot be discovered.\n2. Ask one decision-forcing question at a time. State the recommended answer and the reason briefly, then wait for the answer.\n3. Ask every interview question in plain text as an ordinary assistant response. Do not use a question tool.\n   - When a bounded decision benefits from 2-3 short, mutually exclusive choices, list them in plain text with the recommended answer first.\n   - Invite the user to choose, modify, or discuss the choices instead of forcing a structured selection.\n4. Use comparison tables only when the user explicitly requested one or the question concerns agent-product behavior, such as Claude Code versus Codex.\n5. Follow dependent decisions until the skill decides the decision tree is exhausted. Never ask a final \"are we done?\" meta-question.\n6. Summarize the settled contract: goals, non-goals, decisions, constraints, risks, validation, and unresolved items.\n\n## Background formal evidence\n\nWhen the target project provides an applicable formal checker, follow its\nlocal documentation to prepare the declared interview input and run the check\nbefore choosing the outline and after relevant answers or source changes.\nRead the completed invocation's results and source\u002Finput binding, then use\nunresolved obligations and counterexamples to revise the next question.\nRecheck changed inputs. Reuse answers only within their supported scope and\nconditions, preserving independent choices. After each answer, write its source\nand applicable scope into the declared input and the journal or Draft decision;\nrerun and record the revised remaining obligations before the next outline.\nA possible model assignment is not human acceptance; bounded coverage does\nnot cover unlisted questions.\nMissing or stale evidence limits dependent conclusions while independent\npermitted work continues. Ask one practical question in the user's language,\nwith ordinary choices and consequences; explain formal techniques when asked.\n\n## Scope Contract\n\nThe interview is not finished until the settled contract fixes the scope in\nwriting and the user accepts that text explicitly:\n\n1. **Artifact-level boundary.** Name what the deliverable is (the documents,\n   directories, PRs, or code paths in scope) and the artifact classes that are\n   out of scope, such as follow-on specs, tests, runtime code, or task plans.\n2. **Done means.** A short checklist of the observable conditions that finish\n   the work: landed commits, closed issues, verified evidence. Nothing outside\n   the checklist is a completion dependency.\n3. **Staged designs are approved one stage at a time.** If a decision record\n   describes later stages (an ADR that stages Constitution, spec, or runtime\n   changes), record them as deferred proposals; accepting the record never\n   approves the later stages. Each stage returns for its own interview.\n4. **Execution words never widen scope.** \"Go\", \"do it all\", or \"land 1-5\"\n   authorize only the accepted boundary. When later work would add an artifact\n   class, a new PR, or a task program outside the boundary, stop before\n   producing it and take one of exactly two paths: obtain the owner's explicit\n   approval of the wider boundary, recorded on the owning issue, or move the\n   extra work into a follow-up issue that starts its own interview. Never build\n   first and ask afterwards.\n\nPost the accepted scope contract where the executing lane and its supervisors\ncan read it (for repository work, the owning issue), quoting the acceptance.\nThis comment is lane-coordination evidence, not a decision record: it quotes\nthe user's exact words with channel and time; the durable decision lives in the\nrecord this skill writes, never in the comment.\n\nEnding the interview never authorizes implementation. Implement only after a separate explicit user request.\n\n## Documentation Contract\n\n1. Before the first question, resolve the target document from the user's named target and the repository's existing documentation conventions. Inspect local instructions, indexes, specs, ADRs, glossaries, and nearby docs. If the target is undeterminable, ask one question. Never invent a universal `docs\u002Fgrilling\u002F\u003Cdate>.md` location.\n2. Create or update the target as **Draft**. Write each settled decision immediately as Draft instead of waiting for the interview to end. Keep unresolved questions visibly marked.\n3. If interrupted or cancelled, preserve the Draft and all file edits, mark unresolved questions, and never auto-revert documentation changes.\n4. Read detailed `CONTEXT.md`, ADR, glossary, or other format references only when that document type is actually being written.\n5. Normal Write\u002FEdit tool events are the live proof of documentation work. Do not emit duplicate `Updated \u003Cpath>` status lines.\n6. An explicit docs request is a hard completion condition: the session cannot finish successfully without a useful documentation creation or update. \"No docs needed\" with zero file changes never satisfies it.\n7. Only explicit user acceptance may change a document from Draft to **Final**. Exhausting the decision tree does not imply acceptance.\n8. In the final response, list every changed documentation path and whether it stayed Draft or became Final.\n\n## Credit\n\nThis skill's name and interview approach — one recommended answer per\nquestion, repository facts researched instead of asked, decisions written\ndown as they settle — come from the `grilling` skill (and the former\n`grill-with-docs` skill) by Matt Pocock (@mattpocockuk),\n\u003Chttps:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills>. The skill text shipped here is our own.\nSee the package's `CREDITS.md`.\n","# Grill\n\nUse this skill only when the user explicitly asks for grilling plus durable documentation or directly invokes this skill; the `agents` coordinator handing it an unclear goal, or one decision needing the user's confirmation, before its plan is a direct invocation (its question is the user's judgement — target, measure, scope — that repository facts shape but never answer), and there the durable record is the project's own `PROJECT.md` or `library\u002F` file, never a repository doc. Complexity, ambiguity, or a possible need for docs alone never activates it. This skill carries its own interview and documentation contract. Do not load or invoke `domain-modeling` at runtime.\n\n## Interview Contract\n\n1. Research discoverable facts in the repository, issue, docs, and code before asking the user. Ask only for judgments or facts that cannot be discovered.\n2. Ask one decision-forcing question at a time. State the recommended answer and the reason briefly, then wait for the answer.\n3. Ask every interview question in plain text as an ordinary assistant response. Do not use a question tool.\n   - When a bounded decision benefits from 2-3 short, mutually exclusive choices, list them in plain text with the recommended answer first.\n   - Invite the user to choose, modify, or discuss the choices instead of forcing a structured selection.\n4. Use comparison tables only when the user explicitly requested one or the question concerns agent-product behavior, such as Claude Code versus Codex.\n5. Follow dependent decisions until the skill decides the decision tree is exhausted. Never ask a final \"are we done?\" meta-question.\n6. Summarize the settled contract: goals, non-goals, decisions, constraints, risks, validation, and unresolved items.\n\n## Background formal evidence\n\nWhen the target project provides an applicable formal checker, follow its\nlocal documentation to prepare the declared interview input and run the check\nbefore choosing the outline and after relevant answers or source changes.\nRead the completed invocation's results and source\u002Finput binding, then use\nunresolved obligations and counterexamples to revise the next question.\nRecheck changed inputs. Reuse answers only within their supported scope and\nconditions, preserving independent choices. After each answer, write its source\nand applicable scope into the declared input and the journal or Draft decision;\nrerun and record the revised remaining obligations before the next outline.\nA possible model assignment is not human acceptance; bounded coverage does\nnot cover unlisted questions.\nMissing or stale evidence limits dependent conclusions while independent\npermitted work continues. Ask one practical question in the user's language,\nwith ordinary choices and consequences; explain formal techniques when asked.\n\n## Scope Contract\n\nThe interview is not finished until the settled contract fixes the scope in\nwriting and the user accepts that text explicitly:\n\n1. **Artifact-level boundary.** Name what the deliverable is (the documents,\n   directories, PRs, or code paths in scope) and the artifact classes that are\n   out of scope, such as follow-on specs, tests, runtime code, or task plans.\n2. **Done means.** A short checklist of the observable conditions that finish\n   the work: landed commits, closed issues, verified evidence. Nothing outside\n   the checklist is a completion dependency.\n3. **Staged designs are approved one stage at a time.** If a decision record\n   describes later stages (an ADR that stages Constitution, spec, or runtime\n   changes), record them as deferred proposals; accepting the record never\n   approves the later stages. Each stage returns for its own interview.\n4. **Execution words never widen scope.** \"Go\", \"do it all\", or \"land 1-5\"\n   authorize only the accepted boundary. When later work would add an artifact\n   class, a new PR, or a task program outside the boundary, stop before\n   producing it and take one of exactly two paths: obtain the owner's explicit\n   approval of the wider boundary, recorded on the owning issue, or move the\n   extra work into a follow-up issue that starts its own interview. Never build\n   first and ask afterwards.\n\nPost the accepted scope contract where the executing lane and its supervisors\ncan read it (for repository work, the owning issue), quoting the acceptance.\nThis comment is lane-coordination evidence, not a decision record: it quotes\nthe user's exact words with channel and time; the durable decision lives in the\nrecord this skill writes, never in the comment.\n\nEnding the interview never authorizes implementation. Implement only after a separate explicit user request.\n\n## Documentation Contract\n\n1. Before the first question, resolve the target document from the user's named target and the repository's existing documentation conventions. Inspect local instructions, indexes, specs, ADRs, glossaries, and nearby docs. If the target is undeterminable, ask one question. Never invent a universal `docs\u002Fgrilling\u002F\u003Cdate>.md` location.\n2. Create or update the target as **Draft**. Write each settled decision immediately as Draft instead of waiting for the interview to end. Keep unresolved questions visibly marked.\n3. If interrupted or cancelled, preserve the Draft and all file edits, mark unresolved questions, and never auto-revert documentation changes.\n4. Read detailed `CONTEXT.md`, ADR, glossary, or other format references only when that document type is actually being written.\n5. Normal Write\u002FEdit tool events are the live proof of documentation work. Do not emit duplicate `Updated \u003Cpath>` status lines.\n6. An explicit docs request is a hard completion condition: the session cannot finish successfully without a useful documentation creation or update. \"No docs needed\" with zero file changes never satisfies it.\n7. Only explicit user acceptance may change a document from Draft to **Final**. Exhausting the decision tree does not imply acceptance.\n8. In the final response, list every changed documentation path and whether it stayed Draft or became Final.\n\n## Credit\n\nThis skill's name and interview approach — one recommended answer per\nquestion, repository facts researched instead of asked, decisions written\ndown as they settle — come from the `grilling` skill (and the former\n`grill-with-docs` skill) by Matt Pocock (@mattpocockuk),\n\u003Chttps:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills>. The skill text shipped here is our own.\nSee the package's `CREDITS.md`.\n",{"name":5,"source":33,"license":14,"description":7},"https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills","claude\u002Fai-personal-assistant-main","fb33f7f5b3a206eb019c788e3c48e91c02ccb1f9",".claude\u002Fskills\u002Fsystem-prompts-leaks\u002Fgrill",0,"https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI","https:\u002F\u002Farshad-ai-seven.vercel.app","https:\u002F\u002Fgithub.com\u002Fmarshadgani","2026-11-02 00:51:35",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add marshadgani\u002FArshad.AI --skill grill",{"tool":48,"command":49},"bunx","bunx skills add marshadgani\u002FArshad.AI --skill grill",{"tool":51,"command":52},"pnpm","pnpm dlx skills add marshadgani\u002FArshad.AI --skill grill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fsystem-prompts-leaks\u002Fgrill\u002FSKILL.md",true,[],[57,91,117,149,179,203],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":61,"licenseFileUrl":62,"sourceHtmlUrl":63,"categories":64,"keywords":73,"publishedAt":28},"01M71MVWH15PQRS9KT3J24D7WV","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[65,70],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":71,"categoryName":72,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000009","前端开发",[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90],"webapp","testing","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":61,"licenseFileUrl":95,"sourceHtmlUrl":96,"categories":97,"keywords":99,"publishedAt":28},"01M71MVMAZ1J606SGA4JPHRDAZ","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[98],{"categoryNo":71,"categoryName":72,"taxonomyType":68,"taxonomyTypeDesc":69},[100,101,102,87,103,104,105,77,106,107,80,108,109,110,111,112,113,114,115,116],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":121,"sourceHtmlUrl":122,"categories":123,"keywords":132,"publishedAt":28},"01M71MSTFAEYT9J9GA587SP3RB","ui-styling","Create beautiful, accessible user interfaces with shadcn\u002Fui components (built on Radix UI + Tailwind), Tailwind CSS utility-first styling, and canvas-based visual designs. Use when building user interfaces, implementing design systems, creating responsive layouts, adding accessible components (dialogs, dropdowns, forms, tables), customizing themes and colors, implementing dark mode, generating visual designs and posters, or establishing consistent styling patterns across applications.","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fui-ux-pro-max\u002Fui-styling\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fui-ux-pro-max\u002Fui-styling\u002FSKILL.md",[124,127],{"categoryNo":125,"categoryName":126,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[133,134,89,105,106,135,136,137,138,139,140,141,142,111,143,144,145,146,147,148],"ui styling","styling","mode","canvas","implementing","design","themes","utility","design systems","when","across","create","component","layout","forms","patterns",{"skillNo":150,"name":138,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":162,"publishedAt":28},"01M71MSM72HXKQRCY5D45WYPNP","Comprehensive design skill: brand identity, design tokens, UI styling, logo generation (55 styles, Gemini, Atlas Cloud, or MuAPI AI), corporate identity program (50 deliverables, CIP mockups), HTML presentations (Chart.js), banner design (22 styles, social\u002Fads\u002Fweb\u002Fprint), icon design (15 styles, SVG, Gemini 3.1 Pro), social photos (HTML→screenshot, multi-platform). Actions: design logo, create CIP, generate mockups, build slides, design banner, generate icon, create social photos, social media images, brand identity, design system. Platforms: Facebook, Twitter, LinkedIn, YouTube, Instagram, Pinterest, TikTok, Threads, Google Ads.","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fui-ux-pro-max\u002Fdesign\u002FSKILL.md",[154,157,158,161],{"categoryNo":155,"categoryName":156,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":125,"categoryName":126,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":159,"categoryName":160,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},[138,163,164,165,133,166,167,168,169,144,170,171,172,173,174,175,176,177,89,178],"Media","tiktok","actions","logo","logo generation","chart","multi-platform","ads","youtube","generate","presentations","google","atlas cloud","screenshot","muapi","identity",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":187,"publishedAt":28},"01M71MSH9T7S227MN2YSYB2EP5","design-system","Token architecture, component specifications, and slide generation. Three-layer tokens (primitive→semantic→component), CSS variables, spacing\u002Ftypography scales, component specs, strategic slide creation. Use for design tokens, systematic design, brand-compliant presentations.","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fui-ux-pro-max\u002Fdesign-system\u002FSKILL.md",[185,186],{"categoryNo":125,"categoryName":126,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},[138,188,189,105,190,191,192,193,145,173,194,195,196,197,198,199,200,77,201,202],"design system","system","css variables","creation","Variables","architecture","systematic","token","spacing","layer","typography","brand","three","tokens","slide generation",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":211,"publishedAt":28},"01M71MSCFZ1HFMNBDMAFXDZV92","banner-design","Design banners for social media, ads, website heroes, creative assets, and print. Multiple art direction options with optional generated or supplied visuals. Actions: design, create, generate banner. Platforms: Facebook, Twitter\u002FX, LinkedIn, YouTube, Instagram, Google Display, website hero, print. Styles: minimalist, gradient, bold typography, photo-based, illustrated, geometric, retro, glassmorphism, 3D, neon, duotone, editorial, collage.","https:\u002F\u002Fgithub.com\u002Fmarshadgani\u002FArshad.AI\u002Fblob\u002Fclaude\u002Fai-personal-assistant-main\u002F.claude\u002Fskills\u002Fui-ux-pro-max\u002Fbanner-design\u002FSKILL.md",[209,210],{"categoryNo":125,"categoryName":126,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},[138,212,213,163,214,215,216,165,217,218,219,220,221,222,144,170,171,172,223,224],"banner","banner design","3D","direction","neon","Art","social","generated","hero","dimensions","display","options","website"]