[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79TSJS9BFXNP696FMJ9GKDA":3,"skill-same:01M79TSJS9BFXNP696FMJ9GKDA":53},{"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":32,"commitSha":33,"skillDirectory":34,"forksCount":14,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M79TSJS9BFXNP696FMJ9GKDA","content-microcopy-architect",null,"Architect-level UI content — where strings live, voice and terminology consistency, error and empty-state copy as part of the interface, translation-ready authoring, and the content model a product needs before it multiplies screens. Use when the words in the interface matter as much as the pixels.","SriAkhilSJ\u002FPulseAIRepo","SriAkhilSJ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206201543?v=4","01M79RWFD1Q09B89SXTTKKJY6Z","Sri Akhil SJ","01M79RWFE26NPG0BZ1FRNX376H",0,"MIT","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: content-microcopy-architect\ndescription: Architect-level UI content — where strings live, voice and terminology consistency, error and empty-state copy as part of the interface, translation-ready authoring, and the content model a product needs before it multiplies screens. Use when the words in the interface matter as much as the pixels.\nlicense: MIT\ncompatibility: Framework-agnostic; i18n catalogues (see i18n-architect)\nmetadata:\n  crusor-domain: website-architect\n  crusor-path: website-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect\n  crusor-origin: original\n  crusor-sources: \"nngroup.com\u002Farticles (microcopy, error messages); gov.uk content design guidance\"\n  crusor-triggers: \"microcopy, ux writing, interface copy, error messages, empty state copy, terminology, tone of voice\"\n  crusor-verified-on: \"2026-10-30\"\n---\n\n# Content & Microcopy Architect\n\nCopy is **interface**. A button label is not decoration; it is the specification of\nwhat pressing it does.\n\n## When to use\n\n- Writing labels, buttons, errors, empty states, confirmations.\n- Terminology is inconsistent across screens (Save\u002FUpdate\u002FSubmit).\n- Copy is hard-coded and needs to become translatable.\n\n## When NOT to use\n\n- Marketing copy and long-form content, which have their own editing process.\n\n## Decision 1 — Strings are data\n\n- All UI strings live in a catalogue keyed by meaning (see `i18n-architect`).\n- No concatenation: \"{n} items\" is one message with a plural rule, not\n  `n + \" items\"`.\n- Placeholder names are descriptive (`{fileName}`, not `{0}`).\n- Content limits are part of the design spec: buttons truncate, headlines\n  wrap — decide which.\n\n## Decision 2 — Voice and terminology\n\n- One verb per action, product-wide: pick \"Delete\" and never also use \"Remove\",\n  \"Discard\", \"Erase\" for the same operation.\n- A terminology list exists and is enforced in review (glossary in the repo).\n- Second person, active, present tense: \"We couldn't save your changes.\"\n- No jargon the user did not introduce; no idioms that will not translate.\n\n## Decision 3 — Errors as guidance\n\nEvery error answers three questions:\n\n1. What happened, in the user's terms.\n2. Why, if it is knowable and actionable.\n3. What to do next.\n\n- Never expose codes, stack traces, or internal identifiers as the message.\n- Field errors sit next to the field and name the fix (\"Enter a date after\n  1 March\"), not the failure (\"Invalid input\").\n- Distinguish user error, system error, and permission error — the actions\n  differ.\n\n## Decision 4 — Empty and first-run states\n\n- Empty is a design state with a purpose: explain the value, offer the first\n  action, and — where useful — show an example.\n- Distinguish \"nothing yet\" from \"nothing matched your filter\" from \"no\n  permission\".\n- Loading copy sets expectations for anything over a second.\n- Confirmations name what changed (\"Invite sent to ana@…\"), not \"Success!\".\n\n## Decision 5 — Translation-ready authoring\n\n- Short sentences, no nested clauses; translation expands text 30–40%.\n- No text inside images; no string splits across elements.\n- Dates, numbers, currency via `Intl`, never pre-formatted in strings.\n- Provide context to translators (screenshot + what the string is for).\n\n## Failure modes at scale\n\n- Three words for the same action, so users cannot predict outcomes.\n- Errors like \"Error 422\" that tell the user nothing.\n- Empty states that say \"No data\" and offer no next step.\n- Button labels that change meaning after translation and no longer fit.\n- Copy invented per screen by whoever implemented it last.\n\n## Verification receipts\n\n1. Terminology glossary in the repo, enforced on strings changed in the PR.\n2. Error-copy checklist applied to every error path in the flow.\n3. Empty state present and purposeful for every list\u002Fdata surface.\n4. String catalogue: no concatenation, no embedded HTML, placeholders named.\n5. Pseudo-locale pass on the primary screens (overflow, truncation).\n","# Content & Microcopy Architect\n\nCopy is **interface**. A button label is not decoration; it is the specification of\nwhat pressing it does.\n\n## When to use\n\n- Writing labels, buttons, errors, empty states, confirmations.\n- Terminology is inconsistent across screens (Save\u002FUpdate\u002FSubmit).\n- Copy is hard-coded and needs to become translatable.\n\n## When NOT to use\n\n- Marketing copy and long-form content, which have their own editing process.\n\n## Decision 1 — Strings are data\n\n- All UI strings live in a catalogue keyed by meaning (see `i18n-architect`).\n- No concatenation: \"{n} items\" is one message with a plural rule, not\n  `n + \" items\"`.\n- Placeholder names are descriptive (`{fileName}`, not `{0}`).\n- Content limits are part of the design spec: buttons truncate, headlines\n  wrap — decide which.\n\n## Decision 2 — Voice and terminology\n\n- One verb per action, product-wide: pick \"Delete\" and never also use \"Remove\",\n  \"Discard\", \"Erase\" for the same operation.\n- A terminology list exists and is enforced in review (glossary in the repo).\n- Second person, active, present tense: \"We couldn't save your changes.\"\n- No jargon the user did not introduce; no idioms that will not translate.\n\n## Decision 3 — Errors as guidance\n\nEvery error answers three questions:\n\n1. What happened, in the user's terms.\n2. Why, if it is knowable and actionable.\n3. What to do next.\n\n- Never expose codes, stack traces, or internal identifiers as the message.\n- Field errors sit next to the field and name the fix (\"Enter a date after\n  1 March\"), not the failure (\"Invalid input\").\n- Distinguish user error, system error, and permission error — the actions\n  differ.\n\n## Decision 4 — Empty and first-run states\n\n- Empty is a design state with a purpose: explain the value, offer the first\n  action, and — where useful — show an example.\n- Distinguish \"nothing yet\" from \"nothing matched your filter\" from \"no\n  permission\".\n- Loading copy sets expectations for anything over a second.\n- Confirmations name what changed (\"Invite sent to ana@…\"), not \"Success!\".\n\n## Decision 5 — Translation-ready authoring\n\n- Short sentences, no nested clauses; translation expands text 30–40%.\n- No text inside images; no string splits across elements.\n- Dates, numbers, currency via `Intl`, never pre-formatted in strings.\n- Provide context to translators (screenshot + what the string is for).\n\n## Failure modes at scale\n\n- Three words for the same action, so users cannot predict outcomes.\n- Errors like \"Error 422\" that tell the user nothing.\n- Empty states that say \"No data\" and offer no next step.\n- Button labels that change meaning after translation and no longer fit.\n- Copy invented per screen by whoever implemented it last.\n\n## Verification receipts\n\n1. Terminology glossary in the repo, enforced on strings changed in the PR.\n2. Error-copy checklist applied to every error path in the flow.\n3. Empty state present and purposeful for every list\u002Fdata surface.\n4. String catalogue: no concatenation, no embedded HTML, placeholders named.\n5. Pseudo-locale pass on the primary screens (overflow, truncation).\n",{"name":5,"license":15,"metadata":24,"description":7,"compatibility":31},{"crusor-path":25,"crusor-domain":26,"crusor-origin":27,"crusor-sources":28,"crusor-triggers":29,"crusor-verified-on":30},"website-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect","website-architect","original","nngroup.com\u002Farticles (microcopy, error messages); gov.uk content design guidance","microcopy, ux writing, interface copy, error messages, empty state copy, terminology, tone of voice","2026-10-30","Framework-agnostic; i18n catalogues (see i18n-architect)","main","8fa4e240be65b98472c9b2d3a505ade2aea1a5c6","skills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ","Studying in CMR institute of Technology\r\n2024 - 2028","2026-11-13 21:02:23",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add SriAkhilSJ\u002FPulseAIRepo --skill content-microcopy-architect",{"tool":45,"command":46},"bunx","bunx skills add SriAkhilSJ\u002FPulseAIRepo --skill content-microcopy-architect",{"tool":48,"command":49},"pnpm","pnpm dlx skills add SriAkhilSJ\u002FPulseAIRepo --skill content-microcopy-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect\u002FSKILL.md",true,[],[54,61,68,75,82,89],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M79TTAJNACCNXCEN3649CMMD","interaction-patterns-architect","Architect-level interaction design in code — choosing established patterns over invented ones, feedback and latency behaviour, destructive-action safeguards, navigation and overlay conventions, and the state model behind every interactive surface. Use when a screen has to behave, not just look.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Finteraction-patterns-architect\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M79TT2ESKB1TKZBYY9KYJHV9","design-system-ops-architect","Architect-level operation of a design system in code — token pipelines and versioning, component API and variant policy, the catalogue as the contract, adoption metrics, and the governance that stops a system from forking into three. Use when a component library must survive several teams.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-system-ops-architect\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M79TSV0PWGNK3PRX9P4JDR9N","design-handoff-architect","Architect-level design handoff — what must be specified before implementation starts, tokens over raw values, responsive and content-limit contracts, state matrices, and the review loop that catches drift between design and code. Use when a design is about to become code.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-handoff-architect\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M79TSCNBST3N1M68V1KPH9HQ","ui-ux-implementation-architect","Architect-level direction for turning a design into working UI — the handoff contract, component ownership versus screen-level layout, interaction and state conventions, design QA gates, and the review habits that keep an implementation faithful without frozen pixels. Use before any specific UI implementation skill.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M79TS4N6A4D2QQ433VXS5D0R","test-strategy-architect","Architect-level test strategy — allocating assertions across unit, integration, contract and end-to-end layers, designing for testability through dependency boundaries, fixture and data strategy, and the flake and coverage policies that keep a suite trustworthy. Use when defining how a codebase is tested.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Ftesting-and-deployment-architect\u002Ftest-strategy-architect\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M79TRWDN0NS53SS9DPFCH2SD","release-strategy-architect","Architect-level release practice — small-batch delivery, feature flag and canary strategy, expand\u002Fcontract database changes, rollback versus roll-forward decisions, and the versioning and communication that keep releases boring. Use when deciding how code reaches users.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Ftesting-and-deployment-architect\u002Frelease-strategy-architect\u002FSKILL.md",[],[]]