[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JVY6JS4AP811T3PZN6DSJN":3,"skill-same:01M6JVY6JS4AP811T3PZN6DSJN":75},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6JVY6JS4AP811T3PZN6DSJN","chunking-form-grouping",null,"Use this skill when designing or fixing long forms that ask the user for many fields — sign-up flows, profile setup, settings panels, checkout, intake forms, applications. Trigger when forms exceed ~6 fields, when users complain forms are \"too long,\" when seeing high mid-form drop-off, or when picking how to break a form into sections. Sub-aspect of `chunking`; read that first.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1571,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fchunking-form-grouping\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"chunking form grouping","grouping","form","chunking","trigger","when","break","for","too long","flows","checkout","how to","panels","intake","drop","forms","up","read","ask","how","applications","2026-11-10 10:12:30",false,"---\nname: chunking-form-grouping\ndescription: 'Use this skill when designing or fixing long forms that ask the user for many fields — sign-up flows, profile setup, settings panels, checkout, intake forms, applications. Trigger when forms exceed ~6 fields, when users complain forms are \"too long,\" when seeing high mid-form drop-off, or when picking how to break a form into sections. Sub-aspect of `chunking`; read that first.'\n---\n\n# Chunking applied to forms\n\nA form with 25 fields in one continuous scroll is a wall. The same 25 fields organized into 4–5 named sections of 5–6 fields each is a list of small tasks. The total content is identical; the perceived complexity drops dramatically.\n\n## When to chunk a form\n\n- The form has more than ~7 fields.\n- Drop-off analytics show users abandoning mid-form.\n- Users describe the form as \"long,\" \"complicated,\" or \"I don't know where I am.\"\n- The fields fall into natural categories (account info, profile info, preferences).\n\nIf the form is short (3–5 fields) or all fields belong to a single concept, chunking adds noise without benefit.\n\n## Section structure\n\nThree patterns for chunked forms:\n\n### Single-page with named sections\n\nAll sections visible on one page; user scrolls through and fills in.\n\n```html\n\u003Cform class=\"long-form\">\n  \u003Csection>\n    \u003Ch2>Account\u003C\u002Fh2>\n    \u003Cp class=\"hint\">How you'll sign in.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Csection>\n    \u003Ch2>Profile\u003C\u002Fh2>\n    \u003Cp class=\"hint\">How others see you.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Csection>\n    \u003Ch2>Workspace\u003C\u002Fh2>\n    \u003Cp class=\"hint\">Set up your team space.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Cbutton>Create account\u003C\u002Fbutton>\n\u003C\u002Fform>\n```\n\nPros: user sees total scope; can fill in any order; one save action.\n\nCons: the scroll can still feel long; mid-form abandonment possible.\n\n### Accordion sections (one open at a time)\n\nSections collapse to headers; user opens one at a time.\n\nPros: less visual mass; user focuses on current chunk.\n\nCons: total scope is hidden; users may not realize how many sections remain.\n\n### Multi-step wizard\n\nEach section is its own page; \"Continue\" advances; \"Back\" returns.\n\nPros: focused attention on one chunk; easier mobile experience.\n\nCons: more clicks; loss of context between steps; back-button management complexity.\n\nThe right pattern depends on form length, mobile context, and whether the user benefits from seeing total scope (probably yes for sign-up; maybe not for long government forms).\n\n## Naming sections\n\nSection names should:\n\n- **Match the user's mental model** — \"Profile\" not \"User Information Subsystem.\"\n- **Suggest what's inside** without requiring the user to open it.\n- **Be parallel** in grammar — all noun phrases, or all verb phrases, not mixed.\n\nBad section names:\n\n- \"Section 1 of 5\" — generic; provides no structure.\n- \"Required Information\" — vague; everything is information.\n- \"Etc.\" — gives up.\n\nGood section names:\n\n- \"Account credentials\"\n- \"Notification preferences\"\n- \"Billing address\"\n\n## Section progress signals\n\nFor long single-page forms, a sticky table-of-contents or progress indicator helps:\n\n```html\n\u003Caside class=\"form-toc\">\n  \u003Col>\n    \u003Cli>\u003Ca href=\"#account\" class=\"done\">Account\u003C\u002Fa>\u003C\u002Fli>\n    \u003Cli>\u003Ca href=\"#profile\" class=\"active\">Profile\u003C\u002Fa>\u003C\u002Fli>\n    \u003Cli>\u003Ca href=\"#workspace\">Workspace\u003C\u002Fa>\u003C\u002Fli>\n  \u003C\u002Fol>\n\u003C\u002Faside>\n```\n\nFor multi-step wizards, a stepper:\n\n```html\n\u003Cnav class=\"stepper\" aria-label=\"Progress\">\n  \u003Col>\n    \u003Cli class=\"done\">1. Account\u003C\u002Fli>\n    \u003Cli class=\"active\">2. Profile\u003C\u002Fli>\n    \u003Cli>3. Workspace\u003C\u002Fli>\n  \u003C\u002Fol>\n\u003C\u002Fnav>\n```\n\nBoth let the user see where they are and how much remains.\n\n## Field count per section\n\nAim for 4–7 fields per section. More than that and the section itself becomes a wall; less and the section overhead exceeds its benefit.\n\nIf you find yourself with 12 fields in one logical section, ask:\n\n- Are all 12 actually required? (Often not; cut.)\n- Can the section split into two? (E.g., \"Personal\" and \"Contact.\")\n- Can some fields move to \"later\" via progressive disclosure?\n\n## Single-page vs. multi-step decision\n\nA useful matrix:\n\n| Length | Mobile-primary | Recommended |\n|---|---|---|\n| ≤ 5 fields | Either | Single page, no sections |\n| 6–15 fields | Desktop | Single page with named sections |\n| 6–15 fields | Mobile | Multi-step or accordion |\n| 16–30 fields | Either | Multi-step wizard |\n| 30+ fields | Either | Multi-step + reconsider scope |\n\nThe question after 30+: do you really need all this data up front? Most products can defer 60% of fields until the user has experienced value.\n\n## Anti-patterns\n\n- **Sections without names.** Visual breaks (a horizontal rule) without headings provide visual chunking but no semantic chunking. The user doesn't know what's in each.\n- **Inconsistent section size.** Five fields, two fields, fourteen fields. The user can't predict what's coming.\n- **Required + optional mixed within sections.** A user finishing what looked like a required field discovers more required fields hidden among optional ones. Worse: discovers there are required fields in a section they thought was optional.\n- **Auto-advance on field change.** A field that automatically moves focus or advances steps when value changes surprises the user.\n- **Save state per section unclear.** Multi-step wizards that don't save state per step can lose user data on navigation.\n\n## Heuristics\n\n1. **The \"name each section in 2–3 words\" test.** If you can't, the chunking isn't meaningful.\n2. **The completion-rate audit.** If sign-up completion drops below ~70% (varies by industry), the form is too long; cut, defer, or chunk better.\n3. **The mobile walkthrough.** Walk the form on a 375px screen. Single-page sections that feel manageable on desktop often feel oppressive on mobile.\n\n## Related sub-skills\n\n- **`chunking`** (parent).\n- **`chunking-numeric-and-otp`** — chunking within field values.\n- **`progressive-disclosure`** — defer optional fields rather than showing them all.\n- **`proximity-form-fields`** (perception) — visual proximity within and between sections.\n- **`hicks-law`** — fewer fields = faster decisions.\n","# Chunking applied to forms\n\nA form with 25 fields in one continuous scroll is a wall. The same 25 fields organized into 4–5 named sections of 5–6 fields each is a list of small tasks. The total content is identical; the perceived complexity drops dramatically.\n\n## When to chunk a form\n\n- The form has more than ~7 fields.\n- Drop-off analytics show users abandoning mid-form.\n- Users describe the form as \"long,\" \"complicated,\" or \"I don't know where I am.\"\n- The fields fall into natural categories (account info, profile info, preferences).\n\nIf the form is short (3–5 fields) or all fields belong to a single concept, chunking adds noise without benefit.\n\n## Section structure\n\nThree patterns for chunked forms:\n\n### Single-page with named sections\n\nAll sections visible on one page; user scrolls through and fills in.\n\n```html\n\u003Cform class=\"long-form\">\n  \u003Csection>\n    \u003Ch2>Account\u003C\u002Fh2>\n    \u003Cp class=\"hint\">How you'll sign in.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Csection>\n    \u003Ch2>Profile\u003C\u002Fh2>\n    \u003Cp class=\"hint\">How others see you.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Csection>\n    \u003Ch2>Workspace\u003C\u002Fh2>\n    \u003Cp class=\"hint\">Set up your team space.\u003C\u002Fp>\n    \u003C!-- 4-5 fields -->\n  \u003C\u002Fsection>\n\n  \u003Cbutton>Create account\u003C\u002Fbutton>\n\u003C\u002Fform>\n```\n\nPros: user sees total scope; can fill in any order; one save action.\n\nCons: the scroll can still feel long; mid-form abandonment possible.\n\n### Accordion sections (one open at a time)\n\nSections collapse to headers; user opens one at a time.\n\nPros: less visual mass; user focuses on current chunk.\n\nCons: total scope is hidden; users may not realize how many sections remain.\n\n### Multi-step wizard\n\nEach section is its own page; \"Continue\" advances; \"Back\" returns.\n\nPros: focused attention on one chunk; easier mobile experience.\n\nCons: more clicks; loss of context between steps; back-button management complexity.\n\nThe right pattern depends on form length, mobile context, and whether the user benefits from seeing total scope (probably yes for sign-up; maybe not for long government forms).\n\n## Naming sections\n\nSection names should:\n\n- **Match the user's mental model** — \"Profile\" not \"User Information Subsystem.\"\n- **Suggest what's inside** without requiring the user to open it.\n- **Be parallel** in grammar — all noun phrases, or all verb phrases, not mixed.\n\nBad section names:\n\n- \"Section 1 of 5\" — generic; provides no structure.\n- \"Required Information\" — vague; everything is information.\n- \"Etc.\" — gives up.\n\nGood section names:\n\n- \"Account credentials\"\n- \"Notification preferences\"\n- \"Billing address\"\n\n## Section progress signals\n\nFor long single-page forms, a sticky table-of-contents or progress indicator helps:\n\n```html\n\u003Caside class=\"form-toc\">\n  \u003Col>\n    \u003Cli>\u003Ca href=\"#account\" class=\"done\">Account\u003C\u002Fa>\u003C\u002Fli>\n    \u003Cli>\u003Ca href=\"#profile\" class=\"active\">Profile\u003C\u002Fa>\u003C\u002Fli>\n    \u003Cli>\u003Ca href=\"#workspace\">Workspace\u003C\u002Fa>\u003C\u002Fli>\n  \u003C\u002Fol>\n\u003C\u002Faside>\n```\n\nFor multi-step wizards, a stepper:\n\n```html\n\u003Cnav class=\"stepper\" aria-label=\"Progress\">\n  \u003Col>\n    \u003Cli class=\"done\">1. Account\u003C\u002Fli>\n    \u003Cli class=\"active\">2. Profile\u003C\u002Fli>\n    \u003Cli>3. Workspace\u003C\u002Fli>\n  \u003C\u002Fol>\n\u003C\u002Fnav>\n```\n\nBoth let the user see where they are and how much remains.\n\n## Field count per section\n\nAim for 4–7 fields per section. More than that and the section itself becomes a wall; less and the section overhead exceeds its benefit.\n\nIf you find yourself with 12 fields in one logical section, ask:\n\n- Are all 12 actually required? (Often not; cut.)\n- Can the section split into two? (E.g., \"Personal\" and \"Contact.\")\n- Can some fields move to \"later\" via progressive disclosure?\n\n## Single-page vs. multi-step decision\n\nA useful matrix:\n\n| Length | Mobile-primary | Recommended |\n|---|---|---|\n| ≤ 5 fields | Either | Single page, no sections |\n| 6–15 fields | Desktop | Single page with named sections |\n| 6–15 fields | Mobile | Multi-step or accordion |\n| 16–30 fields | Either | Multi-step wizard |\n| 30+ fields | Either | Multi-step + reconsider scope |\n\nThe question after 30+: do you really need all this data up front? Most products can defer 60% of fields until the user has experienced value.\n\n## Anti-patterns\n\n- **Sections without names.** Visual breaks (a horizontal rule) without headings provide visual chunking but no semantic chunking. The user doesn't know what's in each.\n- **Inconsistent section size.** Five fields, two fields, fourteen fields. The user can't predict what's coming.\n- **Required + optional mixed within sections.** A user finishing what looked like a required field discovers more required fields hidden among optional ones. Worse: discovers there are required fields in a section they thought was optional.\n- **Auto-advance on field change.** A field that automatically moves focus or advances steps when value changes surprises the user.\n- **Save state per section unclear.** Multi-step wizards that don't save state per step can lose user data on navigation.\n\n## Heuristics\n\n1. **The \"name each section in 2–3 words\" test.** If you can't, the chunking isn't meaningful.\n2. **The completion-rate audit.** If sign-up completion drops below ~70% (varies by industry), the form is too long; cut, defer, or chunk better.\n3. **The mobile walkthrough.** Walk the form on a 375px screen. Single-page sections that feel manageable on desktop often feel oppressive on mobile.\n\n## Related sub-skills\n\n- **`chunking`** (parent).\n- **`chunking-numeric-and-otp`** — chunking within field values.\n- **`progressive-disclosure`** — defer optional fields rather than showing them all.\n- **`proximity-form-fields`** (perception) — visual proximity within and between sections.\n- **`hicks-law`** — fewer fields = faster decisions.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fchunking-form-grouping",490,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 02:12:02",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill chunking-form-grouping",{"tool":61,"command":62},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill chunking-form-grouping",{"tool":64,"command":65},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill chunking-form-grouping","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fchunking-form-grouping\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Flong-form-patterns.md","REFERENCE","参考文档",2553,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fcognition-and-learnability-principles\u002Fskills\u002Fchunking-form-grouping\u002Freferences\u002Flong-form-patterns.md",[76,84,91,98,124,149],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":83},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":83},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":83},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[105,106,107,108,109,110,111,112,113,114,115,24,116,117,118,119,120,121,122,123],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[131,132,133,119,134,135,136,137,138,139,140,141,142,143,110,144,145,146,147,148],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":166,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[155,160,163],{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":161,"categoryName":162,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":164,"categoryName":165,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000010","后端与接口",[151,167,168,169,170,171,172,145,173,111,174,175,176,177,24,178,179,180,181,182],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]