[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D1X2WWJXTZZS981KVRWMBM":3,"skill-same:01M6D1X2WWJXTZZS981KVRWMBM":72},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":54,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6D1X2WWJXTZZS981KVRWMBM","docs-comments",null,"Comments, doc comments, commit messages and pull request descriptions: comments that explain why, invariants and surprising decisions rather than narrating code, doc comments on public interfaces, TODOs with an owner and a ticket, keeping comments true when code changes, commit subjects and bodies that explain intent, and PR descriptions that let a reviewer review. Read before writing comments, commit messages or pull request descriptions.","enowdev\u002Fenowxcli","enowdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F179420349?v=4","01M6D1MVX2KC0X3Z9NESE7P22K","Enow Dev.","01M6D1MW1FMZGBDKWAJY4GQX81",67,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fdocs-comments\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"docs comments","docs","doc","intent","read","decisions","public","reviewer","explain","commit messages","why","writing","messages","pull","code","pull request","pr","commit","doc comments","review","2026-11-10 10:12:30",false,"---\nname: docs-comments\ndescription: \"Comments, doc comments, commit messages and pull request descriptions: comments that explain why, invariants and surprising decisions rather than narrating code, doc comments on public interfaces, TODOs with an owner and a ticket, keeping comments true when code changes, commit subjects and bodies that explain intent, and PR descriptions that let a reviewer review. Read before writing comments, commit messages or pull request descriptions.\"\n---\n\n# Comments, commits and pull requests that explain intent\n\nThe generated version comments every line with what it does\n(`\u002F\u002F increment the counter`), puts a banner over each section, keeps\ncommented-out code \"just in case\", writes `TODO: fix this` with no owner,\ndocuments `@param id the id`, and leaves comments describing code that\nchanged two versions ago. Its commits say \"fix\", \"update\" or \"address\nreview comments\", and its pull request description is the template with\nempty headings. This skill covers the text around code: what only a\ncomment can say, how to keep it true, and the commit messages and pull\nrequests a reviewer can work from. The short rules are in `code` (section\n8); this goes further.\n\n## 1. What a comment is for\n\nThe code says what and how. A comment says what the code cannot:\n\n- **Why this way**: the requirement, constraint or trade-off. \"Sorted by\n  id as well as time: two rows can share a timestamp, and the cursor must\n  be stable.\"\n- **Invariants and preconditions** the types do not enforce: \"`items` is\n  never empty here: `validate` rejected that.\"\n- **Units and ranges** when the type does not carry them: \"timeout in\n  milliseconds\", \"0 to 1, not a percentage\".\n- **Surprising decisions**: \"Not awaited on purpose: the receipt email must\n  not hold up checkout; failures go to the retry queue.\"\n- **Workarounds**, with what they work around and when they can go: the\n  upstream issue's link and the version or condition that ends them.\n- **References**: the spec section, RFC, ticket or decision record\n  (`\u002F\u002F See docs\u002Fadr\u002F0007-use-postgresql-for-the-job-queue.md`).\n- **Concurrency**: which lock guards what, what may run in parallel, what\n  order is assumed.\n- **Performance or security reasons**, with what was measured or the\n  threat guarded against. A number only if someone measured it.\n\n```ts\n\u002F\u002F Bad: repeats the code\n\u002F\u002F Loop over the users and send each one a reminder\nfor (const user of users) await sendReminder(user);\n\n\u002F\u002F Good: says why it is sequential\n\u002F\u002F One at a time: the provider allows 10 requests a second and has no\n\u002F\u002F batch endpoint.\nfor (const user of users) await sendReminder(user);\n```\n\nBefore writing a comment, try a better name or a smaller function. A\ncomment explaining what a block does is often a function name waiting to\nbe extracted.\n\n## 2. What not to write\n\n- Narration (\"Step 1: validate the input\"), names restated\n  (`\u002F\u002F get the user` above `getUser()`), section banners, end-of-block\n  markers (`} \u002F\u002F end if`).\n- History: \"changed by Ana in March\", \"old version below\". Git keeps it,\n  with the reason in the commit.\n- Commented-out code: delete it, git has it. If it must stay, the comment\n  says why and links the issue that will decide.\n- Jokes, apologies, emoji, capitals for emphasis.\n- Comments that contradict the code: fix whichever one is wrong.\n- Boilerplate docblocks on private helpers that say nothing the signature\n  does not.\n\n## 3. Doc comments\n\n- Every public item of a library, and every exported function at a module\n  boundary, gets one: a first sentence that summarises, then what the\n  signature does not say (meaning, units, errors, panics, an example). The\n  syntax per language, and the tests that run the examples, are in\n  `docs-api`.\n- A private helper gets one only when its name and signature are not\n  enough.\n- Never restate types (`@param {string} name the name`); give what the\n  type cannot: format, limits, what `null` means.\n\n## 4. Markers and suppressions\n\n- A TODO names an owner or an issue, and the condition that ends it. A\n  TODO with neither becomes an issue, or is deleted.\n\n```ts\n\u002F\u002F TODO(#1234): drop the v1 fallback once no client sends X-Api-Version: 1.\n```\n\n- FIXME marks known wrong behaviour that ships, with its issue. Use the\n  markers the project already uses; do not bring new ones.\n- Rust: a `\u002F\u002F SAFETY:` comment above every `unsafe` block says why its\n  invariants hold (clippy's `undocumented_unsafe_blocks` checks for it).\n- Every lint or type-check suppression carries its reason, in the form the\n  tool reads:\n\n```ts\n\u002F\u002F eslint-disable-next-line no-await-in-loop -- the provider has no batch endpoint\n\u002F\u002F @ts-expect-error: the published types omit the two-argument overload (fixed in 3.2)\n```\n\n```rust\n#[expect(clippy::too_many_arguments, reason = \"mirrors the C API one to one\")]\n```\n\n- Prefer `@ts-expect-error` to `@ts-ignore`, and `#[expect]` to\n  `#[allow]`: both complain when the problem they silence goes away, so\n  the suppression cannot outlive its reason.\n\n## 5. Keeping comments true\n\n- When you change code, read the comments around it and update or delete\n  them in the same change. A false comment costs more than a missing one,\n  because it is believed.\n- Do not copy a value into a comment (\"retries 3 times\"); name the\n  constant (`MAX_RETRIES`), so the comment cannot drift from it.\n- In review, a comment that no longer matches its code is a bug.\n- Licence headers only when the project requires them, in its form, for\n  example `\u002F\u002F SPDX-License-Identifier: Apache-2.0`. Never add or change one\n  on your own.\n- Match the density and tone of the neighbouring files.\n\n## 6. Commit messages\n\n- First, the project's convention: its recent history, `CONTRIBUTING.md`,\n  a commitlint config (`commitlint.config.*`, `.commitlintrc*`), a commit\n  template.\n- **Subject**: the imperative mood, what applying the commit does (\"Add\",\n  \"Fix\", \"Remove\", \"Rename\"); about 50 characters, 72 at most; no full\n  stop; capitalised unless the convention is lowercase (Conventional\n  Commits descriptions usually are).\n- **Body**, after a blank line, wrapped at 72: why the change was needed,\n  what it changes at a level above the diff, trade-offs, what it does not\n  do, and how it was checked when that is not obvious. Not how it works,\n  which the diff shows, unless the approach is surprising.\n- **Trailers** at the end: `Fixes #123` or `Closes #123` (the issue closes\n  when the commit reaches the default branch), `Refs: #123`,\n  `Co-authored-by: Name \u003Cemail>`, `Signed-off-by:` where the project asks\n  for a DCO sign-off (`git commit -s`), `BREAKING CHANGE:` under\n  Conventional Commits.\n- One logical change per commit: a refactor and a behaviour change are two\n  commits; formatting on its own is a third.\n- Conventional Commits when the project uses them:\n  `feat(api): add cursor pagination to GET \u002Forders`,\n  `fix(cli)!: exit non-zero when a table is skipped`.\n- With squash merging, the pull request title becomes the subject and its\n  description often the body: write both to these rules.\n- Never a secret, a customer's data or a private hostname in a message:\n  history is hard to rewrite and is often public.\n\n```text\nRetry webhook deliveries on 429 and 503\n\nPartners throttle bursts after their own deploys, and we dropped those\ndeliveries after one attempt. Retry up to 5 times with exponential\nbackoff (1, 2, 4, 8, 16 seconds), and wait for Retry-After when it is\nlonger.\n\nDeliveries that still fail go to the dead-letter table, as before.\n\nFixes #482\n```\n\nSubjects that say nothing: \"fix bug\", \"update\", \"changes\", \"WIP\", \"misc\",\n\"address review comments\", \"final fix\".\n\n## 7. Pull request descriptions\n\n- **Title**: like a commit subject, and specific: \"Add cursor pagination to\n  GET \u002Forders\".\n- **What and why**: the problem and the change in two to five sentences,\n  with the issue linked.\n- **How to review**: where to start, what deserves attention, what is\n  mechanical (renames, generated files, a regenerated spec).\n- **Testing**: the commands you ran and their results, the manual checks,\n  and what was not tested. A plain \"Not tested: the Windows path\" beats a\n  ticked box.\n- **Screenshots or a short recording** for interface changes, before and\n  after, at the widths that changed.\n- **Risk and rollout**: migrations and their order, feature flags,\n  compatibility, upgrade notes for anything breaking, how to roll back,\n  what to watch after the deploy.\n- **Follow-ups**: what was left out on purpose, with issues.\n- Use the project's template (`.github\u002Fpull_request_template.md`): fill it\n  in, and delete the sections that do not apply rather than writing \"N\u002FA\"\n  under each. A checklist only when the template has one.\n- Small pull requests get real reviews. Split a large change into a\n  sequence: the refactor first, the behaviour change second.\n\n```markdown\n## What and why\n\n`GET \u002Forders` returned every order, and large accounts timed out (#471).\nIt now pages with `limit` (default 25, maximum 100) and `cursor`.\n\n## How to review\n\nStart with `orders\u002Flist.ts`. `openapi.yaml` is regenerated.\n\n## Testing\n\n- `pnpm test orders`: passing, with 6 new cases for cursors.\n- Paged through the staging account with the most orders: no gaps, no\n  repeats.\n- Not tested: the admin CSV export, which uses the old helper (#475).\n\n## Rollout\n\nBreaking for clients that expect the whole list in one response. The web\napp is updated here; the mobile app ships its change first (#476).\n```\n\n## Check it\n\n- Each comment you wrote says something the code cannot. For each one,\n  ask whether the next engineer would lose anything if it were deleted.\n- No commented-out code, no TODO without an owner or issue and an end\n  condition, no stale comment beside the lines you changed, no\n  suppression without a reason.\n- The commit subject is imperative and under 72 characters, the body is\n  wrapped at 72, and the trailers are right.\n- The pull request's testing section lists real commands and results, and\n  claims nothing that was not run.\n\n## Avoid\n\nComments that narrate the next line; banners and end-of-block markers;\ncommented-out code; TODOs without an owner; `@param id the id`; comments\nleft false after a change; suppressions without a reason; \"fix\", \"update\"\nand \"WIP\" as commit subjects; bodies that retell the diff; a pull request\ndescription that is an empty template; test claims nobody ran.\n","# Comments, commits and pull requests that explain intent\n\nThe generated version comments every line with what it does\n(`\u002F\u002F increment the counter`), puts a banner over each section, keeps\ncommented-out code \"just in case\", writes `TODO: fix this` with no owner,\ndocuments `@param id the id`, and leaves comments describing code that\nchanged two versions ago. Its commits say \"fix\", \"update\" or \"address\nreview comments\", and its pull request description is the template with\nempty headings. This skill covers the text around code: what only a\ncomment can say, how to keep it true, and the commit messages and pull\nrequests a reviewer can work from. The short rules are in `code` (section\n8); this goes further.\n\n## 1. What a comment is for\n\nThe code says what and how. A comment says what the code cannot:\n\n- **Why this way**: the requirement, constraint or trade-off. \"Sorted by\n  id as well as time: two rows can share a timestamp, and the cursor must\n  be stable.\"\n- **Invariants and preconditions** the types do not enforce: \"`items` is\n  never empty here: `validate` rejected that.\"\n- **Units and ranges** when the type does not carry them: \"timeout in\n  milliseconds\", \"0 to 1, not a percentage\".\n- **Surprising decisions**: \"Not awaited on purpose: the receipt email must\n  not hold up checkout; failures go to the retry queue.\"\n- **Workarounds**, with what they work around and when they can go: the\n  upstream issue's link and the version or condition that ends them.\n- **References**: the spec section, RFC, ticket or decision record\n  (`\u002F\u002F See docs\u002Fadr\u002F0007-use-postgresql-for-the-job-queue.md`).\n- **Concurrency**: which lock guards what, what may run in parallel, what\n  order is assumed.\n- **Performance or security reasons**, with what was measured or the\n  threat guarded against. A number only if someone measured it.\n\n```ts\n\u002F\u002F Bad: repeats the code\n\u002F\u002F Loop over the users and send each one a reminder\nfor (const user of users) await sendReminder(user);\n\n\u002F\u002F Good: says why it is sequential\n\u002F\u002F One at a time: the provider allows 10 requests a second and has no\n\u002F\u002F batch endpoint.\nfor (const user of users) await sendReminder(user);\n```\n\nBefore writing a comment, try a better name or a smaller function. A\ncomment explaining what a block does is often a function name waiting to\nbe extracted.\n\n## 2. What not to write\n\n- Narration (\"Step 1: validate the input\"), names restated\n  (`\u002F\u002F get the user` above `getUser()`), section banners, end-of-block\n  markers (`} \u002F\u002F end if`).\n- History: \"changed by Ana in March\", \"old version below\". Git keeps it,\n  with the reason in the commit.\n- Commented-out code: delete it, git has it. If it must stay, the comment\n  says why and links the issue that will decide.\n- Jokes, apologies, emoji, capitals for emphasis.\n- Comments that contradict the code: fix whichever one is wrong.\n- Boilerplate docblocks on private helpers that say nothing the signature\n  does not.\n\n## 3. Doc comments\n\n- Every public item of a library, and every exported function at a module\n  boundary, gets one: a first sentence that summarises, then what the\n  signature does not say (meaning, units, errors, panics, an example). The\n  syntax per language, and the tests that run the examples, are in\n  `docs-api`.\n- A private helper gets one only when its name and signature are not\n  enough.\n- Never restate types (`@param {string} name the name`); give what the\n  type cannot: format, limits, what `null` means.\n\n## 4. Markers and suppressions\n\n- A TODO names an owner or an issue, and the condition that ends it. A\n  TODO with neither becomes an issue, or is deleted.\n\n```ts\n\u002F\u002F TODO(#1234): drop the v1 fallback once no client sends X-Api-Version: 1.\n```\n\n- FIXME marks known wrong behaviour that ships, with its issue. Use the\n  markers the project already uses; do not bring new ones.\n- Rust: a `\u002F\u002F SAFETY:` comment above every `unsafe` block says why its\n  invariants hold (clippy's `undocumented_unsafe_blocks` checks for it).\n- Every lint or type-check suppression carries its reason, in the form the\n  tool reads:\n\n```ts\n\u002F\u002F eslint-disable-next-line no-await-in-loop -- the provider has no batch endpoint\n\u002F\u002F @ts-expect-error: the published types omit the two-argument overload (fixed in 3.2)\n```\n\n```rust\n#[expect(clippy::too_many_arguments, reason = \"mirrors the C API one to one\")]\n```\n\n- Prefer `@ts-expect-error` to `@ts-ignore`, and `#[expect]` to\n  `#[allow]`: both complain when the problem they silence goes away, so\n  the suppression cannot outlive its reason.\n\n## 5. Keeping comments true\n\n- When you change code, read the comments around it and update or delete\n  them in the same change. A false comment costs more than a missing one,\n  because it is believed.\n- Do not copy a value into a comment (\"retries 3 times\"); name the\n  constant (`MAX_RETRIES`), so the comment cannot drift from it.\n- In review, a comment that no longer matches its code is a bug.\n- Licence headers only when the project requires them, in its form, for\n  example `\u002F\u002F SPDX-License-Identifier: Apache-2.0`. Never add or change one\n  on your own.\n- Match the density and tone of the neighbouring files.\n\n## 6. Commit messages\n\n- First, the project's convention: its recent history, `CONTRIBUTING.md`,\n  a commitlint config (`commitlint.config.*`, `.commitlintrc*`), a commit\n  template.\n- **Subject**: the imperative mood, what applying the commit does (\"Add\",\n  \"Fix\", \"Remove\", \"Rename\"); about 50 characters, 72 at most; no full\n  stop; capitalised unless the convention is lowercase (Conventional\n  Commits descriptions usually are).\n- **Body**, after a blank line, wrapped at 72: why the change was needed,\n  what it changes at a level above the diff, trade-offs, what it does not\n  do, and how it was checked when that is not obvious. Not how it works,\n  which the diff shows, unless the approach is surprising.\n- **Trailers** at the end: `Fixes #123` or `Closes #123` (the issue closes\n  when the commit reaches the default branch), `Refs: #123`,\n  `Co-authored-by: Name \u003Cemail>`, `Signed-off-by:` where the project asks\n  for a DCO sign-off (`git commit -s`), `BREAKING CHANGE:` under\n  Conventional Commits.\n- One logical change per commit: a refactor and a behaviour change are two\n  commits; formatting on its own is a third.\n- Conventional Commits when the project uses them:\n  `feat(api): add cursor pagination to GET \u002Forders`,\n  `fix(cli)!: exit non-zero when a table is skipped`.\n- With squash merging, the pull request title becomes the subject and its\n  description often the body: write both to these rules.\n- Never a secret, a customer's data or a private hostname in a message:\n  history is hard to rewrite and is often public.\n\n```text\nRetry webhook deliveries on 429 and 503\n\nPartners throttle bursts after their own deploys, and we dropped those\ndeliveries after one attempt. Retry up to 5 times with exponential\nbackoff (1, 2, 4, 8, 16 seconds), and wait for Retry-After when it is\nlonger.\n\nDeliveries that still fail go to the dead-letter table, as before.\n\nFixes #482\n```\n\nSubjects that say nothing: \"fix bug\", \"update\", \"changes\", \"WIP\", \"misc\",\n\"address review comments\", \"final fix\".\n\n## 7. Pull request descriptions\n\n- **Title**: like a commit subject, and specific: \"Add cursor pagination to\n  GET \u002Forders\".\n- **What and why**: the problem and the change in two to five sentences,\n  with the issue linked.\n- **How to review**: where to start, what deserves attention, what is\n  mechanical (renames, generated files, a regenerated spec).\n- **Testing**: the commands you ran and their results, the manual checks,\n  and what was not tested. A plain \"Not tested: the Windows path\" beats a\n  ticked box.\n- **Screenshots or a short recording** for interface changes, before and\n  after, at the widths that changed.\n- **Risk and rollout**: migrations and their order, feature flags,\n  compatibility, upgrade notes for anything breaking, how to roll back,\n  what to watch after the deploy.\n- **Follow-ups**: what was left out on purpose, with issues.\n- Use the project's template (`.github\u002Fpull_request_template.md`): fill it\n  in, and delete the sections that do not apply rather than writing \"N\u002FA\"\n  under each. A checklist only when the template has one.\n- Small pull requests get real reviews. Split a large change into a\n  sequence: the refactor first, the behaviour change second.\n\n```markdown\n## What and why\n\n`GET \u002Forders` returned every order, and large accounts timed out (#471).\nIt now pages with `limit` (default 25, maximum 100) and `cursor`.\n\n## How to review\n\nStart with `orders\u002Flist.ts`. `openapi.yaml` is regenerated.\n\n## Testing\n\n- `pnpm test orders`: passing, with 6 new cases for cursors.\n- Paged through the staging account with the most orders: no gaps, no\n  repeats.\n- Not tested: the admin CSV export, which uses the old helper (#475).\n\n## Rollout\n\nBreaking for clients that expect the whole list in one response. The web\napp is updated here; the mobile app ships its change first (#476).\n```\n\n## Check it\n\n- Each comment you wrote says something the code cannot. For each one,\n  ask whether the next engineer would lose anything if it were deleted.\n- No commented-out code, no TODO without an owner or issue and an end\n  condition, no stale comment beside the lines you changed, no\n  suppression without a reason.\n- The commit subject is imperative and under 72 characters, the body is\n  wrapped at 72, and the trailers are right.\n- The pull request's testing section lists real commands and results, and\n  claims nothing that was not run.\n\n## Avoid\n\nComments that narrate the next line; banners and end-of-block markers;\ncommented-out code; TODOs without an owner; `@param id the id`; comments\nleft false after a change; suppressions without a reason; \"fix\", \"update\"\nand \"WIP\" as commit subjects; bodies that retell the diff; a pull request\ndescription that is an empty template; test claims nobody ran.\n",{"name":5,"description":7},"main","38293fe1b096e6bf3646c7344c38786ed688f464","crates\u002Fenowx-core\u002Fskills\u002Fdocs-comments",21,"https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli","https:\u002F\u002Fenowx.ai","https:\u002F\u002Fgithub.com\u002Fenowdev","Pretending to be a Developer","2026-10-06 02:05:35",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add enowdev\u002Fenowxcli --skill docs-comments",{"tool":64,"command":65},"bunx","bunx skills add enowdev\u002Fenowxcli --skill docs-comments",{"tool":67,"command":68},"pnpm","pnpm dlx skills add enowdev\u002Fenowxcli --skill docs-comments","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fdocs-comments\u002FSKILL.md",true,[],[73,89,111,127,151,172],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":44},"01M6D2HQYSQD9N7MTNDT4A7CBM","demo-skill","Project-scope demo skill for tests.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fworkspace\u002F.agents\u002Fskills\u002Fdemo-skill\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,28],"demo skill","demo","tests","project",{"skillNo":90,"name":35,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":100,"publishedAt":44},"01M6D2HM0GCPM0TM2HPG9HHR2R","Writing words people read: the specific thing instead of claims, words to drop, sentences, interface copy (buttons, labels, errors, empty states, confirmations), page copy, notifications and emails, alt text and link text, numbers and dates, words that translate well, documentation and voice. Read before writing a page's copy, an interface's text or a document.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fwriting\u002FSKILL.md",[94,97],{"categoryNo":95,"categoryName":96,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[35,101,102,103,104,105,28,106,107,108,109,110],"text","emails","empty","drop","document","page","voice","notifications","documentation","translate",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":120,"publishedAt":44},"01M6D2HG07YS49NM196Q0R3AZ8","ui","Designing or restyling an interface: direction, layout, type, colour, icons, components, states, responsive behaviour. Read before building a page, a screen or a set of components.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fui\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[113,121,122,123,124,106,125,28,126],"icons","components","SET","responsive","layout","before building",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":137,"publishedAt":44},"01M6D2HB59HZHWG1RYZDV4SJ91","ui-themes","Light and dark themes, and colour that holds in both: tokens with a value per theme, and what each kind of content needs to stay visible (icons, SVG drawings and line art, logos, photos, screenshots, charts, code, maps, borders, shadows, focus, form controls), switching without a flash, and checking both. Read before building a second theme or a theme toggle, and before any drawing, logo or chart on a page that has two themes.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fui-themes\u002FSKILL.md",[133,136],{"categoryNo":134,"categoryName":135,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,138,139,140,141,142,143,144,145,28,126,146,106,38,147,148,121,149,150],"ui themes","switching","photos","tokens","drawing","focus","maps","Art","flash","Charts","content","screenshots","logo",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":160,"publishedAt":44},"01M6D2H5R5KRAE524C8QX0T7Q0","ui-structure","Structure before styling: the blueprint written before any interface code (the screen's job, the regions its kind of page needs, their order and why, the layout skeleton in numbers, the components and their states), the anatomy and order of a homepage, a dashboard, a list, a detail page, settings, a form, sign-in, pricing, docs, an article and a checkout, and how to turn the blueprint into code (tokens, layout primitives, components, sections, page). Read first, before building or rebuilding any page or screen.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fui-structure\u002FSKILL.md",[157,158,159],{"categoryNo":95,"categoryName":96,"taxonomyType":82,"taxonomyTypeDesc":83},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[161,113,162,122,163,164,38,165,166,167,125,141,168,169,170,28,126,106,34,171],"structure","ui structure","pricing","dashboard","Blueprint","article","anatomy","styling","primitives","list","how",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":185,"publishedAt":44},"01M6D2H0ZZBJG77MBGPZHA6MWD","ui-stack-vue","Building interfaces in Vue 3 and Nuxt: project layout, script setup with typed defineProps, defineEmits and defineModel, attribute fallthrough, slots and scoped slots, template refs, ref, reactive and computed, watch versus watchEffect, composables and VueUse, provide and inject, Pinia, keyed v-for, transitions, Nuxt 4 (app directory, pages, layouts, useFetch and useAsyncData keys, $fetch in handlers, server routes, runtime config, useSeoMeta, NuxtImg, middleware), VeeValidate forms, Reka UI and Nuxt UI, testing, vue-tsc, and the traps. Read when the project uses Vue or Nuxt.","https:\u002F\u002Fgithub.com\u002Fenowdev\u002Fenowxcli\u002Fblob\u002Fmain\u002Fcrates\u002Fenowx-core\u002Fskills\u002Fui-stack-vue\u002FSKILL.md",[178,181,184],{"categoryNo":179,"categoryName":180,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":182,"categoryName":183,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},[113,186,187,188,189,190,191,192,125,88,193,194,28,195,196,197,198,199,200,201],"vue","stack","ui stack vue","forms","pages","watch","runtime","transitions","fetch","pinia","nuxt","template","server","config","directory","testing"]