[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JWN4W0CT0EBTTDY2XAMHSR":3,"skill-same:01M6JWN4W0CT0EBTTDY2XAMHSR":76},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6JWN4W0CT0EBTTDY2XAMHSR","weakest-link-identification",null,"Apply methods for finding the weakest link in a workflow, system, or feature set. Use when planning a redesign, prioritizing engineering or design investment, auditing a product for quality issues, or beginning any improvement effort. Several methods exist (funnel analysis, journey mapping, failure-mode enumeration, support-pattern review, direct user observation); each surfaces different kinds of weakness, and combining them gives the clearest picture.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1554,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fweakest-link-identification\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"weakest link","weakest link identification","identification","link","journey","when","mode","funnel analysis","mapping","pattern","journey mapping","design","surfaces","redesign","direct","analysis","SET","product","issues","support","workflow","review","2026-11-10 10:12:30",false,"---\nname: weakest-link-identification\ndescription: 'Apply methods for finding the weakest link in a workflow, system, or feature set. Use when planning a redesign, prioritizing engineering or design investment, auditing a product for quality issues, or beginning any improvement effort. Several methods exist (funnel analysis, journey mapping, failure-mode enumeration, support-pattern review, direct user observation); each surfaces different kinds of weakness, and combining them gives the clearest picture.'\n---\n\n# Weakest Link — identification\n\nBefore you can treat a weakest link, you have to find it. The work of identification is often skipped in favor of optimizing whatever is currently visible or interesting; the result is misallocated effort. Several methods help find weakest links systematically.\n\n## Method 1: funnel analysis\n\nFor sequential workflows (signup, checkout, onboarding, multi-step forms), measure completion at each step. The biggest single drop is your prime suspect.\n\nPractical setup:\n- Instrument each step with an event (\"started step 3,\" \"completed step 3\").\n- Calculate the conversion rate from step n to step n+1 for each pair.\n- Look for the largest drop in conversion.\n\nExample:\n- Step 1: 10,000 users start.\n- Step 2: 9,000 users (90% conversion).\n- Step 3: 7,500 users (83%).\n- Step 4: 4,000 users (53%). ← Biggest drop.\n- Step 5: 3,800 users (95%).\n\nStep 4 is the weakest link. Investigate why users abandon there.\n\n## Method 2: user journey mapping\n\nWalk through the entire user experience as if you were a new user. For each step, ask:\n\n- What can go wrong here?\n- How often does it go wrong?\n- What's the cost when it does?\n- Can the user recover?\n\nScore each step on these dimensions. The step with the worst combined score is your weakest link.\n\nThis method surfaces issues that funnel analysis misses — including issues that affect users without dropping them out entirely. A confusing step that users complete with frustration is a weakest link even though the funnel doesn't show it.\n\n## Method 3: failure-mode analysis (FMEA)\n\nA systematic enumeration of how things can go wrong. For each component or step:\n\n- List the failure modes (specific ways it can fail).\n- For each failure mode, estimate severity (1–10), occurrence (1–10), and detectability (1–10).\n- Compute the Risk Priority Number (RPN) = severity × occurrence × detectability.\n- Rank by RPN.\n\nThe highest-RPN items are your weakest links.\n\nThis is more work than funnel analysis but surfaces less-obvious risks (rare-but-catastrophic failures, hard-to-detect failures).\n\n## Method 4: support-pattern review\n\nLook at customer support tickets for the past 30\u002F90\u002F365 days. Categorize by topic. The most common categories are likely tracking the weakest links from the user's perspective.\n\nIf support tickets cluster around specific features (\"can't reset password,\" \"billing confusion,\" \"search not working\"), those features are weakest links. Users are encountering them, struggling, and asking for help.\n\nThis method has the advantage of reflecting real user friction, not designer hypotheses. The disadvantage: it only captures issues that users complain about; silent abandonment doesn't show up.\n\n## Method 5: direct user observation\n\nWatch real users use the product. Where do they hesitate, get confused, or fail? The recurring trouble spots are weakest links.\n\nThis is the most expensive method but produces the richest insights. A user testing session of even 5–10 users typically reveals weakest links that data alone misses.\n\nVariants:\n\n- **Moderated user testing:** facilitator guides the user through tasks, observing behavior.\n- **Unmoderated user testing:** users complete tasks alone, recorded for later review.\n- **In-product analytics replays:** session replay tools (Hotjar, FullStory) record real-user sessions for review.\n- **Usability questions in support transcripts:** when users ask \"how do I X\" the X is often a weakest link.\n\n## Method 6: dependency reliability analysis\n\nFor technical systems, audit external dependencies (services, APIs, libraries). Each dependency has its own reliability characteristics; the weakest is your composed-system weakest link.\n\nPractical setup:\n- List all dependencies.\n- Track uptime\u002Ferror rate for each.\n- Identify the lowest-reliability dependency.\n- Calculate composed reliability and identify dependencies that drag it most.\n\nOften the weakest dependency isn't the one you expect. Newer integrations, less-popular services, and pre-production tools often have worse reliability than established ones.\n\n## Method 7: edge-case enumeration\n\nFor each feature, enumerate the edge cases (unusual inputs, rare conditions, error states). For each edge case, ask:\n\n- Does the product handle this?\n- If not, what does the user experience?\n- How rare is this case?\n\nEdge cases that are common enough to hit users regularly and bad enough to harm the experience when they do are weakest links. Users hitting them typically don't report (they assume the product just doesn't support their case) but they leave with a bad impression.\n\n## Combining methods\n\nThe methods complement each other. Funnel analysis catches drop-offs; journey mapping catches frustration without drop-off; FMEA catches rare-but-severe; support-review catches what users complain about; observation catches what users don't articulate; dependency analysis catches infrastructure issues; edge-case enumeration catches the \"we forgot about that\" problems.\n\nFor a comprehensive audit, use multiple methods. The weakest links found by multiple methods are particularly high-priority.\n\n## Prioritizing among multiple weak links\n\nOnce you've identified candidate weakest links, prioritize by:\n\n**User impact.** How many users hit this, and how badly does it affect them?\n\n**Business impact.** Does this weak link cost revenue, retention, or reputation?\n\n**Effort to fix.** Some weak links are quick fixes; others require major work. Fast-and-impactful ones first.\n\n**Cascading effects.** Fixing some weak links has positive effects throughout the system; others are isolated. Prefer the cascading ones.\n\nThe ideal first targets are weak links that are high-impact, quick to fix, and have cascading benefits. The hardest decisions are the high-impact, hard-to-fix weak links — sometimes worth the investment, sometimes worth the patient strategy.\n\n## Worked examples\n\n### A product with multiple identified weak links\n\nAfter a comprehensive audit, the team identifies five weak links:\n\n1. **Sign-up email deliverability** (high user impact, infrastructure, hard to fix).\n2. **Onboarding step 4: data import** (high user impact, design, moderate effort).\n3. **Search results ranking** (medium user impact, ML, very hard to fix).\n4. **Mobile checkout flow** (high user impact, design, moderate effort).\n5. **Notification settings page** (low user impact, design, easy to fix).\n\nPrioritization:\n- Items 2 and 4 (high impact, moderate effort) get priority.\n- Item 1 gets investigation (deliverability is hard but might have quick wins).\n- Item 5 is bundled into a sprint as a quick win.\n- Item 3 is parked for a longer-term ML investment.\n\nThis is a more deliberate allocation than treating all weak links equally.\n\n### Funnel reveals an unexpected weak link\n\nA team running a checkout funnel discovers the biggest drop is between \"review order\" and \"submit payment.\" They had assumed the weak link would be earlier (cart abandonment, address entry).\n\nInvestigation reveals: the \"review order\" page is missing the shipping cost; users discover the shipping cost only on the submit-payment page and abandon when they see it.\n\nThe fix is to surface shipping cost earlier (on the review page, ideally on the cart page). Once shipping is transparent, the abandonment at submit-payment drops dramatically.\n\nThe lesson: data revealed a weak link that designer intuition missed.\n\n## Anti-patterns\n\n**Optimizing without measuring.** Improving things based on intuition rather than data. Often optimizes the wrong thing.\n\n**Single-method audits.** Relying only on funnel data or only on support tickets. Different methods catch different weaknesses.\n\n**Treating \"user complaints\" as proportional to actual frequency.** Loud users may not represent silent ones. Combine complaint data with usage data.\n\n**Underweighting silent abandonment.** Users who leave without telling anyone are the largest category of negative outcomes for most products. Direct observation and analytics on hesitation\u002Fdropoff capture them better than support tickets.\n\n**Confusing the weakest link with the loudest issue.** The most-discussed issue isn't always the most-impactful. Look for impact, not just visibility.\n\n## Heuristic checklist\n\nWhen auditing for weakest links, ask: **Have I used multiple identification methods?** Single methods miss things. **Have I quantified frequency and impact for each candidate?** Subjective ranking misallocates. **Have I considered both observed and silent failures?** Drop-off + frustration. **Have I prioritized by impact and effort?** Or am I just fixing what I notice first?\n\n## Related sub-skills\n\n- `weakest-link` — parent principle on the disproportionate impact of the weakest component.\n- `weakest-link-treatment` — sibling skill on what to do once a weak link is identified.\n- `errors` — error-prone steps are often weak links.\n- `iteration` — weakest-link improvement is iterative.\n\n## See also\n\n- `references\u002Faudit-workflow.md` — a step-by-step workflow for conducting a weakest-link audit.\n","# Weakest Link — identification\n\nBefore you can treat a weakest link, you have to find it. The work of identification is often skipped in favor of optimizing whatever is currently visible or interesting; the result is misallocated effort. Several methods help find weakest links systematically.\n\n## Method 1: funnel analysis\n\nFor sequential workflows (signup, checkout, onboarding, multi-step forms), measure completion at each step. The biggest single drop is your prime suspect.\n\nPractical setup:\n- Instrument each step with an event (\"started step 3,\" \"completed step 3\").\n- Calculate the conversion rate from step n to step n+1 for each pair.\n- Look for the largest drop in conversion.\n\nExample:\n- Step 1: 10,000 users start.\n- Step 2: 9,000 users (90% conversion).\n- Step 3: 7,500 users (83%).\n- Step 4: 4,000 users (53%). ← Biggest drop.\n- Step 5: 3,800 users (95%).\n\nStep 4 is the weakest link. Investigate why users abandon there.\n\n## Method 2: user journey mapping\n\nWalk through the entire user experience as if you were a new user. For each step, ask:\n\n- What can go wrong here?\n- How often does it go wrong?\n- What's the cost when it does?\n- Can the user recover?\n\nScore each step on these dimensions. The step with the worst combined score is your weakest link.\n\nThis method surfaces issues that funnel analysis misses — including issues that affect users without dropping them out entirely. A confusing step that users complete with frustration is a weakest link even though the funnel doesn't show it.\n\n## Method 3: failure-mode analysis (FMEA)\n\nA systematic enumeration of how things can go wrong. For each component or step:\n\n- List the failure modes (specific ways it can fail).\n- For each failure mode, estimate severity (1–10), occurrence (1–10), and detectability (1–10).\n- Compute the Risk Priority Number (RPN) = severity × occurrence × detectability.\n- Rank by RPN.\n\nThe highest-RPN items are your weakest links.\n\nThis is more work than funnel analysis but surfaces less-obvious risks (rare-but-catastrophic failures, hard-to-detect failures).\n\n## Method 4: support-pattern review\n\nLook at customer support tickets for the past 30\u002F90\u002F365 days. Categorize by topic. The most common categories are likely tracking the weakest links from the user's perspective.\n\nIf support tickets cluster around specific features (\"can't reset password,\" \"billing confusion,\" \"search not working\"), those features are weakest links. Users are encountering them, struggling, and asking for help.\n\nThis method has the advantage of reflecting real user friction, not designer hypotheses. The disadvantage: it only captures issues that users complain about; silent abandonment doesn't show up.\n\n## Method 5: direct user observation\n\nWatch real users use the product. Where do they hesitate, get confused, or fail? The recurring trouble spots are weakest links.\n\nThis is the most expensive method but produces the richest insights. A user testing session of even 5–10 users typically reveals weakest links that data alone misses.\n\nVariants:\n\n- **Moderated user testing:** facilitator guides the user through tasks, observing behavior.\n- **Unmoderated user testing:** users complete tasks alone, recorded for later review.\n- **In-product analytics replays:** session replay tools (Hotjar, FullStory) record real-user sessions for review.\n- **Usability questions in support transcripts:** when users ask \"how do I X\" the X is often a weakest link.\n\n## Method 6: dependency reliability analysis\n\nFor technical systems, audit external dependencies (services, APIs, libraries). Each dependency has its own reliability characteristics; the weakest is your composed-system weakest link.\n\nPractical setup:\n- List all dependencies.\n- Track uptime\u002Ferror rate for each.\n- Identify the lowest-reliability dependency.\n- Calculate composed reliability and identify dependencies that drag it most.\n\nOften the weakest dependency isn't the one you expect. Newer integrations, less-popular services, and pre-production tools often have worse reliability than established ones.\n\n## Method 7: edge-case enumeration\n\nFor each feature, enumerate the edge cases (unusual inputs, rare conditions, error states). For each edge case, ask:\n\n- Does the product handle this?\n- If not, what does the user experience?\n- How rare is this case?\n\nEdge cases that are common enough to hit users regularly and bad enough to harm the experience when they do are weakest links. Users hitting them typically don't report (they assume the product just doesn't support their case) but they leave with a bad impression.\n\n## Combining methods\n\nThe methods complement each other. Funnel analysis catches drop-offs; journey mapping catches frustration without drop-off; FMEA catches rare-but-severe; support-review catches what users complain about; observation catches what users don't articulate; dependency analysis catches infrastructure issues; edge-case enumeration catches the \"we forgot about that\" problems.\n\nFor a comprehensive audit, use multiple methods. The weakest links found by multiple methods are particularly high-priority.\n\n## Prioritizing among multiple weak links\n\nOnce you've identified candidate weakest links, prioritize by:\n\n**User impact.** How many users hit this, and how badly does it affect them?\n\n**Business impact.** Does this weak link cost revenue, retention, or reputation?\n\n**Effort to fix.** Some weak links are quick fixes; others require major work. Fast-and-impactful ones first.\n\n**Cascading effects.** Fixing some weak links has positive effects throughout the system; others are isolated. Prefer the cascading ones.\n\nThe ideal first targets are weak links that are high-impact, quick to fix, and have cascading benefits. The hardest decisions are the high-impact, hard-to-fix weak links — sometimes worth the investment, sometimes worth the patient strategy.\n\n## Worked examples\n\n### A product with multiple identified weak links\n\nAfter a comprehensive audit, the team identifies five weak links:\n\n1. **Sign-up email deliverability** (high user impact, infrastructure, hard to fix).\n2. **Onboarding step 4: data import** (high user impact, design, moderate effort).\n3. **Search results ranking** (medium user impact, ML, very hard to fix).\n4. **Mobile checkout flow** (high user impact, design, moderate effort).\n5. **Notification settings page** (low user impact, design, easy to fix).\n\nPrioritization:\n- Items 2 and 4 (high impact, moderate effort) get priority.\n- Item 1 gets investigation (deliverability is hard but might have quick wins).\n- Item 5 is bundled into a sprint as a quick win.\n- Item 3 is parked for a longer-term ML investment.\n\nThis is a more deliberate allocation than treating all weak links equally.\n\n### Funnel reveals an unexpected weak link\n\nA team running a checkout funnel discovers the biggest drop is between \"review order\" and \"submit payment.\" They had assumed the weak link would be earlier (cart abandonment, address entry).\n\nInvestigation reveals: the \"review order\" page is missing the shipping cost; users discover the shipping cost only on the submit-payment page and abandon when they see it.\n\nThe fix is to surface shipping cost earlier (on the review page, ideally on the cart page). Once shipping is transparent, the abandonment at submit-payment drops dramatically.\n\nThe lesson: data revealed a weak link that designer intuition missed.\n\n## Anti-patterns\n\n**Optimizing without measuring.** Improving things based on intuition rather than data. Often optimizes the wrong thing.\n\n**Single-method audits.** Relying only on funnel data or only on support tickets. Different methods catch different weaknesses.\n\n**Treating \"user complaints\" as proportional to actual frequency.** Loud users may not represent silent ones. Combine complaint data with usage data.\n\n**Underweighting silent abandonment.** Users who leave without telling anyone are the largest category of negative outcomes for most products. Direct observation and analytics on hesitation\u002Fdropoff capture them better than support tickets.\n\n**Confusing the weakest link with the loudest issue.** The most-discussed issue isn't always the most-impactful. Look for impact, not just visibility.\n\n## Heuristic checklist\n\nWhen auditing for weakest links, ask: **Have I used multiple identification methods?** Single methods miss things. **Have I quantified frequency and impact for each candidate?** Subjective ranking misallocates. **Have I considered both observed and silent failures?** Drop-off + frustration. **Have I prioritized by impact and effort?** Or am I just fixing what I notice first?\n\n## Related sub-skills\n\n- `weakest-link` — parent principle on the disproportionate impact of the weakest component.\n- `weakest-link-treatment` — sibling skill on what to do once a weak link is identified.\n- `errors` — error-prone steps are often weak links.\n- `iteration` — weakest-link improvement is iterative.\n\n## See also\n\n- `references\u002Faudit-workflow.md` — a step-by-step workflow for conducting a weakest-link audit.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fweakest-link-identification",468,"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-11 02:22:54",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill weakest-link-identification",{"tool":62,"command":63},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill weakest-link-identification",{"tool":65,"command":66},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill weakest-link-identification","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fweakest-link-identification\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Faudit-workflow.md","REFERENCE","参考文档",5580,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fweakest-link-identification\u002Freferences\u002Faudit-workflow.md",[77,102,126,160,181,194],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":41},"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",[],[84,85,86,87,88,89,90,91,92,30,93,24,94,95,96,97,98,99,100,101],"search","deja search","error","ready","never","memory","re","decide","fix","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":41},"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",[],[109,110,111,112,89,113,114,115,116,117,118,119,40,97,120,121,122,123,124,125],"reflect","deja reflect","brew","remember","project rules","project","session","end","reflection","Rules","decisions","with","record","github","next","https","node",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":143,"publishedAt":41},"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",[132,137,140],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":138,"categoryName":139,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":141,"categoryName":142,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000023","Skill与智能体开发",[128,144,145,146,147,148,114,149,90,150,151,152,153,24,154,155,156,157,158,159],"Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","URL","image","mcp server","schedule","api","publish",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":41},"01M71569ZM2X3H5RBFK8PVKMK2","review-study","Review a QuestionPunk survey before launch for wording, answer choices, branching, and missing settings. Use for check my survey or review this draft before publishing.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Freview-study\u002FSKILL.md",[],[167,168,40,169,170,171,172,173,174,175,176,177,178,179,180],"study","review study","for","answer","missing","survey","publishing","use","check","draft","settings","launch","my","branching",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":41},"01M71567GV0C35YQBY0DPGR86B","manage-study","Find QuestionPunk studies, check status, publish an explicitly requested draft, or retrieve its participant link. Use for find my survey, publish this study, or how many people responded.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fmanage-study\u002FSKILL.md",[],[188,167,189,169,172,174,190,175,176,159,191,192,22,193,179],"manage study","manage","people","how","find","status",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":41},"01M71565A8TCA01AZQZRGRYMFZ","create-study","Create a saved QuestionPunk survey draft from a research brief or edit specified questions. Use for requests such as make a customer feedback survey or shorten my onboarding study.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fcreate-study\u002FSKILL.md",[],[201,167,202,203,204,205,169,206,172,207,174,208,209,176,210,211,212,213,214,179],"create study","create","brief","as","feedback","customer feedback","research brief","shorten","saved","research","requests","customer","questions","edit"]