[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADS8QX8FB097GVETE63CJ2":3,"skill-same:01M6ADS8QX8FB097GVETE63CJ2":74},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6ADS8QX8FB097GVETE63CJ2","lean-comments",null,"Audits, writes, and refines maintained first-party source-code comments and declaration-level documentation across languages. Use when adding, editing, reviewing, cleaning up, or auditing comments, doc comments, docstrings, TODO, FIXME, NOTE, suppressions, or other source commentary, including while modifying code and deciding whether a comment is warranted at all. Defaults to no comment unless it preserves meaningful, non-obvious information that cannot reasonably be recovered from the code or nearby repository context.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41128,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flean-comments\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"lean comments","comments","lean","use","when","source","at","commentary","information","across","todo","up","doc comments","context","editing","code comments","doc","repository","code","documentation","2026-11-10 10:12:30",false,"---\nname: lean-comments\ndescription: 'Audits, writes, and refines maintained first-party source-code comments and declaration-level documentation across languages. Use when adding, editing, reviewing, cleaning up, or auditing comments, doc comments, docstrings, TODO, FIXME, NOTE, suppressions, or other source commentary, including while modifying code and deciding whether a comment is warranted at all. Defaults to no comment unless it preserves meaningful, non-obvious information that cannot reasonably be recovered from the code or nearby repository context.'\n---\n\n# Lean Comments\n\n## Goal\n\nKeep the smallest amount of high-value commentary necessary to make a codebase easier and safer to understand and maintain.\n\nThe default is **no comment**.\n\nA comment must preserve meaningful information that a competent maintainer cannot reasonably recover from the code, names, types, signatures, structure, tests, configuration, or nearby context.\n\nComments are not labels, narration, decoration, declaration summaries, change logs, or substitutes for clear code.\n\n## Reader model\n\nWrite for a competent maintainer reading the repository at HEAD months later, without access to the current conversation, prompt, diff, pull request, issue discussion, review discussion, or implementation process.\n\nDocument the durable state, contract, constraint, or rationale of the code as it exists. Do not assume the reader knows what changed, what came before, or what was discussed unless that context is deliberately preserved in a reliable project source.\n\n## Authority and evidence\n\nUse this skill as the comment-policy authority when it is active.\n\nUse language, framework, library, or infrastructure skills to determine whether a non-obvious constraint is real, not to override this skill's necessity test.\n\nHonor explicit current repository requirements, public API documentation requirements, tooling contracts, and generated-source rules. Do not infer a documentation requirement merely from existing comment density or precedent.\n\nBase retained or newly written rationale on evidence from the repository, tests, configuration, official API behavior, project documentation, issue tracker, ADRs, specifications, or another reliable source.\n\nNever invent a security reason, performance reason, business rule, compatibility requirement, API constraint, historical reason, architectural rationale, or external limitation to justify commentary.\n\nIf no supported non-obvious reason exists, remove or omit it.\n\n## Core decision rule\n\nBefore retaining or adding ordinary commentary, mentally remove it and ask:\n\n> Would a competent maintainer lose meaningful, non-obvious information if this comment did not exist?\n\nIf no, remove or omit it.\n\nIf uncertain, prefer no comment unless repository evidence demonstrates that the information matters.\n\nIf yes, retain only the minimum information necessary.\n\nNever preserve a comment merely because it is correct, harmless, already present, grammatically polished, written as a warning, related to security or validation, related to internal or public state, or attached to an exported declaration.\n\nThe information itself must justify the comment.\n\n## Decision order\n\nEvaluate existing and proposed commentary in this order:\n\n1. **Delete or omit** if the information is already clear without it\n2. **Express through code** if a tiny behavior-preserving readability improvement removes the need for it\n3. **Shorten** if it is necessary but contains unnecessary information or words\n4. **Rewrite** if it is necessary but unclear, inaccurate, stale, awkward, or inconsistent\n5. **Use declaration documentation** if the information belongs to the declaration's contract, semantics, or intended usage\n6. **Keep unchanged** only if it is already necessary, minimal, accurate, durable, and correctly styled\n\nAlways decide necessity before wording.\n\nDo not polish an unnecessary comment or convert one into documentation.\n\n## What deserves an implementation comment\n\nUse an implementation comment when it preserves non-obvious information such as:\n\n- Why intentionally surprising code exists\n- An external constraint or compatibility requirement\n- An important invariant or subtle edge case\n- A meaningful tradeoff or required workaround\n- Non-obvious coupling\n- An ordering, timing, lifecycle, concurrency, performance, or security constraint\n- A reason an apparently simpler implementation would be incorrect\n\nPrefer comments that explain **why** something matters.\n\nComments that merely explain **what** the code does should normally be removed.\n\n## Remove low-value commentary\n\nRemove comments that merely:\n\n- Restate or translate the code into prose\n- Narrate the next statement or obvious control flow\n- Explain an obvious guard clause, return, assignment, or branch\n- Describe an obvious fetch, validation, transformation, mapping, filtering, creation, update, or deletion\n- Repeat a declaration name, property name, type, signature, parameter, or return type\n- Label or summarize a declaration\n- Repeat information already represented clearly by tests or configuration\n- Add generic context that is immediately inferable\n- Act as unnecessary section headings or visual separators\n- Preserve obsolete change history\n- Address the reviewer or justify the current change\n- State a bare rule or prohibition without useful non-obvious context\n- Add rhetorical emphasis without information\n\nWords such as `Never`, `Always`, `Important`, `Security`, `Internal`, `Public`, or `Required` do not make a comment valuable.\n\nJudge the information, not how serious the wording sounds.\n\n## Prefer self-explanatory code\n\nWhen a comment compensates for unnecessarily confusing code, consider a tiny local behavior-preserving improvement such as improving a local name, extracting a clearly named boolean, simplifying local control flow, or removing redundant local structure.\n\nKeep such changes minimal and directly related to clarity.\n\nDo not turn comment cleanup into a general refactor or change behavior, architecture, public APIs, dependencies, or unrelated code merely to eliminate comments.\n\n## Comment and documentation forms\n\nApply the same necessity test across languages and syntaxes.\n\nRelevant forms may include:\n\n- Line and block comments such as `\u002F\u002F`, `#`, `--`, and `\u002F* ... *\u002F`\n- JSDoc, TSDoc, JavaDoc, KDoc, Rust doc comments, Go doc comments, C# XML documentation, and equivalent declaration documentation\n- Module, package, and file documentation\n- Python docstrings and other declaration documentation represented as runtime-visible strings\n- TODO, FIXME, NOTE, HACK, XXX, and similar markers\n- Tooling, compiler, formatter, coverage, build, framework, generator, and machine-consumed directives\n\nDo not treat comment-like text inside string literals, regular expressions, URLs, snapshots, fixtures, templates, or test data as source comments merely because it contains comment syntax.\n\n### Implementation comments\n\nUse the language's normal implementation-comment form for brief rationale, constraints, invariants, workarounds, or other non-obvious local context.\n\nPrefer one concise line when one line is sufficient.\n\n### Declaration documentation\n\nUse the language's declaration-documentation form only when the information belongs to the declaration itself and forms part of its contract, semantics, or intended usage.\n\nFor TypeScript, use TSDoc-compatible documentation when warranted. For JavaScript, follow intentional repository JSDoc conventions. For other languages, follow the language and repository's real documentation conventions without creating coverage for its own sake.\n\n### Module and file documentation\n\nAdd module, package, or file-level documentation only for a durable architectural concept, boundary, invariant, terminology, lifecycle rule, or design rationale that is not apparent from the contents.\n\nDo not add file headers that merely summarize exports or describe an obvious file purpose.\n\n### Runtime-visible documentation\n\nSome documentation forms, especially Python docstrings, can be observable at runtime through introspection or tooling.\n\nBefore removing or materially changing runtime-visible documentation, verify that doing so does not change a supported runtime contract, generated documentation surface, or external API expectation.\n\n## Declaration documentation rules\n\nThis is not a documentation coverage exercise.\n\nDo not document declarations merely because they are exported or public, and do not assume every language-level export in application code is an intentionally supported external API.\n\nUse declaration documentation when consumers or maintainers need non-obvious information about:\n\n- Behavioral contracts, parameter constraints, return semantics, or special values\n- Error behavior, side effects, preconditions, or postconditions\n- Ordering, timing, lifecycle, concurrency, or caching behavior\n- Security, runtime, server, client, SSR, or environment constraints\n- Compatibility requirements or upstream API behavior\n- Business rules or invariants\n- Units, formats, ranges, encodings, or cross-field relationships\n- Deprecation, extension points, or important usage restrictions\n- Non-obvious usage that materially benefits from an example\n\nApply a stronger documentation bias to published libraries, SDKs, packages, plugins, extension APIs, and intentionally external interfaces.\n\nApply a stronger no-documentation bias to internal helpers, simple CRUD methods, straightforward adapters, composables, plain data shapes, DTOs, and internal utilities.\n\n### Do not repeat the type system\n\nDo not add documentation that merely restates names, types, signatures, obvious values, or structure already expressed by the language.\n\nDo not mechanically add tags such as `@param`, `@returns`, `@throws`, `@example`, `@remarks`, or `@see`. Use a tag only when it contributes information beyond the declaration and type system.\n\nPlain interfaces, records, DTOs, structs, types, and obvious data shapes normally require no documentation unless they contain non-obvious semantics, invariants, formats, units, relationships, external constraints, or compatibility requirements.\n\n## Style\n\n### Single-line prose implementation comments\n\nFor a necessary single-line prose implementation comment, regardless of comment delimiter:\n\n- Keep it as short as possible without making it cryptic\n- Start normal prose with an uppercase letter unless technically required casing dictates otherwise\n- Do not end it with `.`, `!`, `?`, or other terminal sentence punctuation\n- Do not use em dashes or en dashes\n- Do not use dash-based sentence punctuation\n- Do not use semicolons as sentence punctuation\n- Prefer a concise clause over unnecessarily complete prose\n- Preserve exact casing and punctuation in identifiers, code, commands, URLs, paths, package names, versions, API values, and other technical literals\n\nExample:\n\n```ts\n\u002F\u002F Preserve source order for positional matching\n```\n\nNot:\n\n```ts\n\u002F\u002F Preserve source order for positional matching.\n```\n\nThese prose rules do not apply to machine-consumed syntax, technically significant punctuation, or genuine multi-line declaration documentation.\n\n### Declaration documentation\n\nUse normal sentence punctuation for genuine multi-sentence declaration documentation.\n\nKeep it concise and focused on meaningful contract or semantic information. Do not add prose, tags, examples, or sections merely to make documentation appear complete.\n\n## High-value examples\n\n\u003Cexamples>\n\n\u003Cexample>\nDelete:\n\n```ts\n\u002F\u002F A watchlist row\nexport interface FlickWatchlistItem {\n  media: FlickMedia;\n  added_at: string;\n}\n```\n\nCorrect:\n\n```ts\nexport interface FlickWatchlistItem {\n  media: FlickMedia;\n  added_at: string;\n}\n```\n\nThe declaration already communicates the concept. Do not shorten the comment or convert it into declaration documentation.\n\u003C\u002Fexample>\n\n\u003Cexample>\nUsually delete:\n\n```ts\n\u002F\u002F Never copy a raw internal message into the public response\n```\n\nDo not preserve this merely because it contains `Never` or concerns a public boundary.\n\nIf repository evidence establishes a genuinely non-obvious reason, retain only that supported reason:\n\n```ts\n\u002F\u002F Keep provider errors private because messages may contain credentials\n```\n\nNever invent such rationale to save the original comment.\n\u003C\u002Fexample>\n\n\u003Cexample>\nDelete:\n\n```ts\n\u002F\u002F Return the normalized result\nreturn normalize(result);\n```\n\nThe code already communicates the action.\n\u003C\u002Fexample>\n\n\u003Cexample>\nKeep when supported by the implementation or external contract:\n\n```ts\n\u002F\u002F Preserve source order because the upstream API matches items by position\n```\n\nThe comment communicates a non-obvious positional constraint.\n\u003C\u002Fexample>\n\n\u003Cexample>\nUseful declaration documentation:\n\n```ts\n\u002F**\n * Returns `null` for private profiles instead of propagating the upstream authorization error.\n *\u002F\nexport async function getProfile(): Promise\u003CProfile | null> {\n  \u002F\u002F ...\n}\n```\n\nThe documentation explains caller-visible behavior that the type alone cannot communicate.\n\u003C\u002Fexample>\n\n\u003C\u002Fexamples>\n\n## TODO, FIXME, NOTE, and similar markers\n\nTreat TODO, FIXME, NOTE, HACK, XXX, and equivalent markers as comments, not exceptions.\n\nVerify that each one is still relevant, technically accurate, useful, and actionable when appropriate. Follow repository conventions for issue references or ownership when such conventions actually exist.\n\nRemove stale, completed, meaningless, or superseded markers.\n\nDo not add a marker prefix merely to make an ordinary comment appear important.\n\nDo not implement unrelated work solely to remove a valid marker.\n\n## Commented-out code\n\nCommented-out executable code is normally dead code.\n\nDelete it when version control already preserves the history and there is no current reason for the disabled code to remain.\n\nRetain it only when the disabled form serves a current supported purpose, such as a deliberate copyable example, a semantically significant fixture, a documented compatibility fallback that maintainers are expected to re-enable under a known condition, or tooling\u002Fframework syntax that must remain disabled in source form.\n\nDo not preserve commented-out code merely because it might be useful later.\n\nDo not uncomment or execute old code solely to justify keeping it.\n\n## Technically significant directives and headers\n\nPreserve constructs whose presence, position, or exact syntax has technical, tooling, generation, runtime, or legal significance, including applicable:\n\n- Shebangs\n- Lint and formatter directives\n- Compiler and type-checker directives\n- Coverage directives\n- Build tags and pragmas\n- Framework directives\n- Bundler or optimizer annotations\n- Source-map and sourceURL directives\n- Generated markers\n- Required annotations\n- Encoding declarations\n- Licensing and copyright headers\n- Other machine-consumed comments\n\nThese are not ordinary prose comments. Do not apply prose formatting rules to their syntax, and preserve technically required punctuation exactly.\n\n### Stale directives\n\nTechnically significant directives are protected only while they remain necessary.\n\nWhen practical, verify whether suppressions and other tooling directives are still required. Remove a directive when repository evidence or the relevant tooling proves it obsolete.\n\nDo not remove or rewrite an unfamiliar directive merely because its purpose is unclear. Verify it first.\n\nDo not broaden a suppression. Only narrow or remove one when the change is clearly safe, directly related to the audit, and does not require unrelated refactoring.\n\nTreat legal headers more conservatively than tooling directives. Do not remove or alter licensing or copyright text without clear project authority.\n\n## Durable references and links\n\nA bare issue, pull request, specification, or documentation URL is not automatically useful commentary.\n\nRetain or add a reference only when it materially preserves non-obvious context that cannot be expressed clearly enough in the code alone.\n\nPrefer concise durable context plus a stable reference when the external source contains important details that would be unreasonable to duplicate.\n\nDo not rely on transient conversation context or an inaccessible review thread as the only explanation for surprising code.\n\n## Editing existing code\n\nTreat existing comments as untrusted. Surviving previous cleanup passes does not make a comment correct or necessary.\n\nWhen code changes make commentary inaccurate or redundant, update or remove it in the same change.\n\nDo not narrate change history with phrases such as `now`, `previously`, `new approach`, `old behavior`, or `no longer`.\n\nDocument the durable state instead.\n\nDo not address the reviewer or refer to the current conversation, prompt, diff, pull request, or implementation process.\n\n## Interaction with prose-refinement skills\n\nWhen a prose-refinement skill such as `unslop` is available, `lean-comments` remains authoritative.\n\nUse prose refinement only after determining that the commentary deserves to exist.\n\nThe order is:\n\n1. Determine necessity\n2. Delete if unnecessary\n3. Determine the correct comment form\n4. Minimize the information\n5. Refine the wording\n\nRefinement may improve clarity, naturalness, and readability, but must not introduce personality or voice for its own sake, rhetorical flourish, humor, conversational filler, additional rationale, additional examples, additional claims, increased verbosity, or information that was not already justified.\n\nPrefer the shortest natural wording that preserves the necessary technical meaning.\n\nDo not allow a prose-refinement skill to weaken this skill's requirements for necessity, minimalism, accuracy, durability, or style.\n\nA polished unnecessary comment is still unnecessary.\n\n## Normal implementation work\n\nWhen adding or modifying code:\n\n- Do not add comments by default\n- Add one only when it passes the necessity test\n- Apply this skill to commentary directly affected by the implementation\n- Remove commentary made obsolete by the change\n- Do not perform an unrelated repository-wide comment cleanup unless requested\n\n## Repository-wide audits\n\nWhen explicitly asked to audit commentary throughout a repository:\n\n1. Inspect enough of the repository to understand its terminology, architecture, languages, tooling, external constraints, and documentation conventions\n2. Identify maintained first-party scope and exclude generated, vendored, dependency, third-party, and externally maintained content\n3. Search systematically for all relevant comment, documentation, marker, directive, and commented-out-code forms used by the repository's languages\n4. Review comments untouched by previous cleanup passes\n5. Apply the necessity test before making wording changes\n6. Review declaration documentation as critically as ordinary comments\n7. Review commentary immediately preceding declarations for redundant labels or summaries\n8. Review TODO, FIXME, NOTE, HACK, XXX, tooling directives, suppressions, and commented-out code\n9. Inspect the final diff for accidental behavior, formatting, or unrelated changes\n10. Search again for likely missed violations\n11. Run relevant repository validation when source files or directives changed\n\nFor single-line prose comments, specifically inspect remaining comments ending in `.`, `!`, or `?`.\n\nDo not blindly modify matches. Exclude technically significant syntax and comment-like text that is actually data.\n\nFor directives and suppressions, use the relevant tool when practical to distinguish required controls from stale ones.\n\n## Scope boundaries\n\nApply this skill to maintained first-party source content.\n\nDo not modify generated, vendored, dependency, third-party, externally maintained, or machine-generated content unless synchronization with an intentional source change requires it.\n\nDo not introduce unrelated functional, architectural, behavioral, dependency, broad-formatting, or refactoring changes.\n\nKeep the resulting diff focused.\n\n## Final acceptance check\n\nBefore completing a repository-wide audit, verify that:\n\n- Every remaining ordinary comment contributes meaningful non-obvious information\n- Obvious comments were deleted rather than polished\n- Label comments, code narration, and bare warnings are gone\n- Comments are as concise as possible without becoming cryptic\n- Single-line prose comments follow the style rules above\n- Declaration documentation adds genuine contract or semantic information\n- Plain data declarations are not decorated with useless documentation\n- Types and signatures are not repeated unnecessarily\n- No rationale or history was invented\n- Stale TODO, FIXME, NOTE, HACK, XXX, and equivalent markers are gone\n- Unjustified commented-out code is gone\n- Required machine-significant constructs remain intact\n- Proven-stale tooling directives and suppressions are gone\n- Runtime-visible documentation was not removed without checking its contract\n- Comment-like data was not mistaken for source commentary\n- No unrelated changes were introduced\n- Relevant validation passes\n\nIf a repository-wide cleanup still consists mainly of wording or punctuation changes while almost all original comments survive, re-evaluate necessity.\n\nDo not optimize for a target number or percentage of comments.\n\nStop when further deletion or shortening would remove genuinely useful information rather than merely reduce comment count.\n","# Lean Comments\n\n## Goal\n\nKeep the smallest amount of high-value commentary necessary to make a codebase easier and safer to understand and maintain.\n\nThe default is **no comment**.\n\nA comment must preserve meaningful information that a competent maintainer cannot reasonably recover from the code, names, types, signatures, structure, tests, configuration, or nearby context.\n\nComments are not labels, narration, decoration, declaration summaries, change logs, or substitutes for clear code.\n\n## Reader model\n\nWrite for a competent maintainer reading the repository at HEAD months later, without access to the current conversation, prompt, diff, pull request, issue discussion, review discussion, or implementation process.\n\nDocument the durable state, contract, constraint, or rationale of the code as it exists. Do not assume the reader knows what changed, what came before, or what was discussed unless that context is deliberately preserved in a reliable project source.\n\n## Authority and evidence\n\nUse this skill as the comment-policy authority when it is active.\n\nUse language, framework, library, or infrastructure skills to determine whether a non-obvious constraint is real, not to override this skill's necessity test.\n\nHonor explicit current repository requirements, public API documentation requirements, tooling contracts, and generated-source rules. Do not infer a documentation requirement merely from existing comment density or precedent.\n\nBase retained or newly written rationale on evidence from the repository, tests, configuration, official API behavior, project documentation, issue tracker, ADRs, specifications, or another reliable source.\n\nNever invent a security reason, performance reason, business rule, compatibility requirement, API constraint, historical reason, architectural rationale, or external limitation to justify commentary.\n\nIf no supported non-obvious reason exists, remove or omit it.\n\n## Core decision rule\n\nBefore retaining or adding ordinary commentary, mentally remove it and ask:\n\n> Would a competent maintainer lose meaningful, non-obvious information if this comment did not exist?\n\nIf no, remove or omit it.\n\nIf uncertain, prefer no comment unless repository evidence demonstrates that the information matters.\n\nIf yes, retain only the minimum information necessary.\n\nNever preserve a comment merely because it is correct, harmless, already present, grammatically polished, written as a warning, related to security or validation, related to internal or public state, or attached to an exported declaration.\n\nThe information itself must justify the comment.\n\n## Decision order\n\nEvaluate existing and proposed commentary in this order:\n\n1. **Delete or omit** if the information is already clear without it\n2. **Express through code** if a tiny behavior-preserving readability improvement removes the need for it\n3. **Shorten** if it is necessary but contains unnecessary information or words\n4. **Rewrite** if it is necessary but unclear, inaccurate, stale, awkward, or inconsistent\n5. **Use declaration documentation** if the information belongs to the declaration's contract, semantics, or intended usage\n6. **Keep unchanged** only if it is already necessary, minimal, accurate, durable, and correctly styled\n\nAlways decide necessity before wording.\n\nDo not polish an unnecessary comment or convert one into documentation.\n\n## What deserves an implementation comment\n\nUse an implementation comment when it preserves non-obvious information such as:\n\n- Why intentionally surprising code exists\n- An external constraint or compatibility requirement\n- An important invariant or subtle edge case\n- A meaningful tradeoff or required workaround\n- Non-obvious coupling\n- An ordering, timing, lifecycle, concurrency, performance, or security constraint\n- A reason an apparently simpler implementation would be incorrect\n\nPrefer comments that explain **why** something matters.\n\nComments that merely explain **what** the code does should normally be removed.\n\n## Remove low-value commentary\n\nRemove comments that merely:\n\n- Restate or translate the code into prose\n- Narrate the next statement or obvious control flow\n- Explain an obvious guard clause, return, assignment, or branch\n- Describe an obvious fetch, validation, transformation, mapping, filtering, creation, update, or deletion\n- Repeat a declaration name, property name, type, signature, parameter, or return type\n- Label or summarize a declaration\n- Repeat information already represented clearly by tests or configuration\n- Add generic context that is immediately inferable\n- Act as unnecessary section headings or visual separators\n- Preserve obsolete change history\n- Address the reviewer or justify the current change\n- State a bare rule or prohibition without useful non-obvious context\n- Add rhetorical emphasis without information\n\nWords such as `Never`, `Always`, `Important`, `Security`, `Internal`, `Public`, or `Required` do not make a comment valuable.\n\nJudge the information, not how serious the wording sounds.\n\n## Prefer self-explanatory code\n\nWhen a comment compensates for unnecessarily confusing code, consider a tiny local behavior-preserving improvement such as improving a local name, extracting a clearly named boolean, simplifying local control flow, or removing redundant local structure.\n\nKeep such changes minimal and directly related to clarity.\n\nDo not turn comment cleanup into a general refactor or change behavior, architecture, public APIs, dependencies, or unrelated code merely to eliminate comments.\n\n## Comment and documentation forms\n\nApply the same necessity test across languages and syntaxes.\n\nRelevant forms may include:\n\n- Line and block comments such as `\u002F\u002F`, `#`, `--`, and `\u002F* ... *\u002F`\n- JSDoc, TSDoc, JavaDoc, KDoc, Rust doc comments, Go doc comments, C# XML documentation, and equivalent declaration documentation\n- Module, package, and file documentation\n- Python docstrings and other declaration documentation represented as runtime-visible strings\n- TODO, FIXME, NOTE, HACK, XXX, and similar markers\n- Tooling, compiler, formatter, coverage, build, framework, generator, and machine-consumed directives\n\nDo not treat comment-like text inside string literals, regular expressions, URLs, snapshots, fixtures, templates, or test data as source comments merely because it contains comment syntax.\n\n### Implementation comments\n\nUse the language's normal implementation-comment form for brief rationale, constraints, invariants, workarounds, or other non-obvious local context.\n\nPrefer one concise line when one line is sufficient.\n\n### Declaration documentation\n\nUse the language's declaration-documentation form only when the information belongs to the declaration itself and forms part of its contract, semantics, or intended usage.\n\nFor TypeScript, use TSDoc-compatible documentation when warranted. For JavaScript, follow intentional repository JSDoc conventions. For other languages, follow the language and repository's real documentation conventions without creating coverage for its own sake.\n\n### Module and file documentation\n\nAdd module, package, or file-level documentation only for a durable architectural concept, boundary, invariant, terminology, lifecycle rule, or design rationale that is not apparent from the contents.\n\nDo not add file headers that merely summarize exports or describe an obvious file purpose.\n\n### Runtime-visible documentation\n\nSome documentation forms, especially Python docstrings, can be observable at runtime through introspection or tooling.\n\nBefore removing or materially changing runtime-visible documentation, verify that doing so does not change a supported runtime contract, generated documentation surface, or external API expectation.\n\n## Declaration documentation rules\n\nThis is not a documentation coverage exercise.\n\nDo not document declarations merely because they are exported or public, and do not assume every language-level export in application code is an intentionally supported external API.\n\nUse declaration documentation when consumers or maintainers need non-obvious information about:\n\n- Behavioral contracts, parameter constraints, return semantics, or special values\n- Error behavior, side effects, preconditions, or postconditions\n- Ordering, timing, lifecycle, concurrency, or caching behavior\n- Security, runtime, server, client, SSR, or environment constraints\n- Compatibility requirements or upstream API behavior\n- Business rules or invariants\n- Units, formats, ranges, encodings, or cross-field relationships\n- Deprecation, extension points, or important usage restrictions\n- Non-obvious usage that materially benefits from an example\n\nApply a stronger documentation bias to published libraries, SDKs, packages, plugins, extension APIs, and intentionally external interfaces.\n\nApply a stronger no-documentation bias to internal helpers, simple CRUD methods, straightforward adapters, composables, plain data shapes, DTOs, and internal utilities.\n\n### Do not repeat the type system\n\nDo not add documentation that merely restates names, types, signatures, obvious values, or structure already expressed by the language.\n\nDo not mechanically add tags such as `@param`, `@returns`, `@throws`, `@example`, `@remarks`, or `@see`. Use a tag only when it contributes information beyond the declaration and type system.\n\nPlain interfaces, records, DTOs, structs, types, and obvious data shapes normally require no documentation unless they contain non-obvious semantics, invariants, formats, units, relationships, external constraints, or compatibility requirements.\n\n## Style\n\n### Single-line prose implementation comments\n\nFor a necessary single-line prose implementation comment, regardless of comment delimiter:\n\n- Keep it as short as possible without making it cryptic\n- Start normal prose with an uppercase letter unless technically required casing dictates otherwise\n- Do not end it with `.`, `!`, `?`, or other terminal sentence punctuation\n- Do not use em dashes or en dashes\n- Do not use dash-based sentence punctuation\n- Do not use semicolons as sentence punctuation\n- Prefer a concise clause over unnecessarily complete prose\n- Preserve exact casing and punctuation in identifiers, code, commands, URLs, paths, package names, versions, API values, and other technical literals\n\nExample:\n\n```ts\n\u002F\u002F Preserve source order for positional matching\n```\n\nNot:\n\n```ts\n\u002F\u002F Preserve source order for positional matching.\n```\n\nThese prose rules do not apply to machine-consumed syntax, technically significant punctuation, or genuine multi-line declaration documentation.\n\n### Declaration documentation\n\nUse normal sentence punctuation for genuine multi-sentence declaration documentation.\n\nKeep it concise and focused on meaningful contract or semantic information. Do not add prose, tags, examples, or sections merely to make documentation appear complete.\n\n## High-value examples\n\n\u003Cexamples>\n\n\u003Cexample>\nDelete:\n\n```ts\n\u002F\u002F A watchlist row\nexport interface FlickWatchlistItem {\n  media: FlickMedia;\n  added_at: string;\n}\n```\n\nCorrect:\n\n```ts\nexport interface FlickWatchlistItem {\n  media: FlickMedia;\n  added_at: string;\n}\n```\n\nThe declaration already communicates the concept. Do not shorten the comment or convert it into declaration documentation.\n\u003C\u002Fexample>\n\n\u003Cexample>\nUsually delete:\n\n```ts\n\u002F\u002F Never copy a raw internal message into the public response\n```\n\nDo not preserve this merely because it contains `Never` or concerns a public boundary.\n\nIf repository evidence establishes a genuinely non-obvious reason, retain only that supported reason:\n\n```ts\n\u002F\u002F Keep provider errors private because messages may contain credentials\n```\n\nNever invent such rationale to save the original comment.\n\u003C\u002Fexample>\n\n\u003Cexample>\nDelete:\n\n```ts\n\u002F\u002F Return the normalized result\nreturn normalize(result);\n```\n\nThe code already communicates the action.\n\u003C\u002Fexample>\n\n\u003Cexample>\nKeep when supported by the implementation or external contract:\n\n```ts\n\u002F\u002F Preserve source order because the upstream API matches items by position\n```\n\nThe comment communicates a non-obvious positional constraint.\n\u003C\u002Fexample>\n\n\u003Cexample>\nUseful declaration documentation:\n\n```ts\n\u002F**\n * Returns `null` for private profiles instead of propagating the upstream authorization error.\n *\u002F\nexport async function getProfile(): Promise\u003CProfile | null> {\n  \u002F\u002F ...\n}\n```\n\nThe documentation explains caller-visible behavior that the type alone cannot communicate.\n\u003C\u002Fexample>\n\n\u003C\u002Fexamples>\n\n## TODO, FIXME, NOTE, and similar markers\n\nTreat TODO, FIXME, NOTE, HACK, XXX, and equivalent markers as comments, not exceptions.\n\nVerify that each one is still relevant, technically accurate, useful, and actionable when appropriate. Follow repository conventions for issue references or ownership when such conventions actually exist.\n\nRemove stale, completed, meaningless, or superseded markers.\n\nDo not add a marker prefix merely to make an ordinary comment appear important.\n\nDo not implement unrelated work solely to remove a valid marker.\n\n## Commented-out code\n\nCommented-out executable code is normally dead code.\n\nDelete it when version control already preserves the history and there is no current reason for the disabled code to remain.\n\nRetain it only when the disabled form serves a current supported purpose, such as a deliberate copyable example, a semantically significant fixture, a documented compatibility fallback that maintainers are expected to re-enable under a known condition, or tooling\u002Fframework syntax that must remain disabled in source form.\n\nDo not preserve commented-out code merely because it might be useful later.\n\nDo not uncomment or execute old code solely to justify keeping it.\n\n## Technically significant directives and headers\n\nPreserve constructs whose presence, position, or exact syntax has technical, tooling, generation, runtime, or legal significance, including applicable:\n\n- Shebangs\n- Lint and formatter directives\n- Compiler and type-checker directives\n- Coverage directives\n- Build tags and pragmas\n- Framework directives\n- Bundler or optimizer annotations\n- Source-map and sourceURL directives\n- Generated markers\n- Required annotations\n- Encoding declarations\n- Licensing and copyright headers\n- Other machine-consumed comments\n\nThese are not ordinary prose comments. Do not apply prose formatting rules to their syntax, and preserve technically required punctuation exactly.\n\n### Stale directives\n\nTechnically significant directives are protected only while they remain necessary.\n\nWhen practical, verify whether suppressions and other tooling directives are still required. Remove a directive when repository evidence or the relevant tooling proves it obsolete.\n\nDo not remove or rewrite an unfamiliar directive merely because its purpose is unclear. Verify it first.\n\nDo not broaden a suppression. Only narrow or remove one when the change is clearly safe, directly related to the audit, and does not require unrelated refactoring.\n\nTreat legal headers more conservatively than tooling directives. Do not remove or alter licensing or copyright text without clear project authority.\n\n## Durable references and links\n\nA bare issue, pull request, specification, or documentation URL is not automatically useful commentary.\n\nRetain or add a reference only when it materially preserves non-obvious context that cannot be expressed clearly enough in the code alone.\n\nPrefer concise durable context plus a stable reference when the external source contains important details that would be unreasonable to duplicate.\n\nDo not rely on transient conversation context or an inaccessible review thread as the only explanation for surprising code.\n\n## Editing existing code\n\nTreat existing comments as untrusted. Surviving previous cleanup passes does not make a comment correct or necessary.\n\nWhen code changes make commentary inaccurate or redundant, update or remove it in the same change.\n\nDo not narrate change history with phrases such as `now`, `previously`, `new approach`, `old behavior`, or `no longer`.\n\nDocument the durable state instead.\n\nDo not address the reviewer or refer to the current conversation, prompt, diff, pull request, or implementation process.\n\n## Interaction with prose-refinement skills\n\nWhen a prose-refinement skill such as `unslop` is available, `lean-comments` remains authoritative.\n\nUse prose refinement only after determining that the commentary deserves to exist.\n\nThe order is:\n\n1. Determine necessity\n2. Delete if unnecessary\n3. Determine the correct comment form\n4. Minimize the information\n5. Refine the wording\n\nRefinement may improve clarity, naturalness, and readability, but must not introduce personality or voice for its own sake, rhetorical flourish, humor, conversational filler, additional rationale, additional examples, additional claims, increased verbosity, or information that was not already justified.\n\nPrefer the shortest natural wording that preserves the necessary technical meaning.\n\nDo not allow a prose-refinement skill to weaken this skill's requirements for necessity, minimalism, accuracy, durability, or style.\n\nA polished unnecessary comment is still unnecessary.\n\n## Normal implementation work\n\nWhen adding or modifying code:\n\n- Do not add comments by default\n- Add one only when it passes the necessity test\n- Apply this skill to commentary directly affected by the implementation\n- Remove commentary made obsolete by the change\n- Do not perform an unrelated repository-wide comment cleanup unless requested\n\n## Repository-wide audits\n\nWhen explicitly asked to audit commentary throughout a repository:\n\n1. Inspect enough of the repository to understand its terminology, architecture, languages, tooling, external constraints, and documentation conventions\n2. Identify maintained first-party scope and exclude generated, vendored, dependency, third-party, and externally maintained content\n3. Search systematically for all relevant comment, documentation, marker, directive, and commented-out-code forms used by the repository's languages\n4. Review comments untouched by previous cleanup passes\n5. Apply the necessity test before making wording changes\n6. Review declaration documentation as critically as ordinary comments\n7. Review commentary immediately preceding declarations for redundant labels or summaries\n8. Review TODO, FIXME, NOTE, HACK, XXX, tooling directives, suppressions, and commented-out code\n9. Inspect the final diff for accidental behavior, formatting, or unrelated changes\n10. Search again for likely missed violations\n11. Run relevant repository validation when source files or directives changed\n\nFor single-line prose comments, specifically inspect remaining comments ending in `.`, `!`, or `?`.\n\nDo not blindly modify matches. Exclude technically significant syntax and comment-like text that is actually data.\n\nFor directives and suppressions, use the relevant tool when practical to distinguish required controls from stale ones.\n\n## Scope boundaries\n\nApply this skill to maintained first-party source content.\n\nDo not modify generated, vendored, dependency, third-party, externally maintained, or machine-generated content unless synchronization with an intentional source change requires it.\n\nDo not introduce unrelated functional, architectural, behavioral, dependency, broad-formatting, or refactoring changes.\n\nKeep the resulting diff focused.\n\n## Final acceptance check\n\nBefore completing a repository-wide audit, verify that:\n\n- Every remaining ordinary comment contributes meaningful non-obvious information\n- Obvious comments were deleted rather than polished\n- Label comments, code narration, and bare warnings are gone\n- Comments are as concise as possible without becoming cryptic\n- Single-line prose comments follow the style rules above\n- Declaration documentation adds genuine contract or semantic information\n- Plain data declarations are not decorated with useless documentation\n- Types and signatures are not repeated unnecessarily\n- No rationale or history was invented\n- Stale TODO, FIXME, NOTE, HACK, XXX, and equivalent markers are gone\n- Unjustified commented-out code is gone\n- Required machine-significant constructs remain intact\n- Proven-stale tooling directives and suppressions are gone\n- Runtime-visible documentation was not removed without checking its contract\n- Comment-like data was not mistaken for source commentary\n- No unrelated changes were introduced\n- Relevant validation passes\n\nIf a repository-wide cleanup still consists mainly of wording or punctuation changes while almost all original comments survive, re-evaluate necessity.\n\nDo not optimize for a target number or percentage of comments.\n\nStop when further deletion or shortening would remove genuinely useful information rather than merely reduce comment count.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Flean-comments",5353,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-13 11:40:39",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add github\u002Fawesome-copilot --skill lean-comments",{"tool":60,"command":61},"bunx","bunx skills add github\u002Fawesome-copilot --skill lean-comments",{"tool":63,"command":64},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill lean-comments","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flean-comments\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"package.json","REFERENCE","参考文档",852,"https:\u002F\u002Fgithub.com\u002Fnodetool-ai\u002Fnodetool\u002Fblob\u002Fmain\u002Fpackages\u002Fsandbox-packs\u002Fsandbox-qr\u002Fpackage.json",[75,108,136,165,199,216],{"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":89,"publishedAt":39},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[81,86],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发",[90,91,92,93,94,23,95,96,97,98,99,100,101,102,103,104,22,105,106,107],"supabase","rls","supabase rls","supabase rls policies","project","review","change","read","write","security","isolation","tables","as","tests","prove","users","functions","with",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":39},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[114],{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},[116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":140,"sourceHtmlUrl":141,"categories":142,"keywords":148,"publishedAt":39},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[149,37,150,151,152,153,122,94,154,155,156,157,158,159,160,22,161,162,163,164],"custom","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":169,"sourceHtmlUrl":170,"categories":171,"keywords":176,"publishedAt":39},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},[177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,23,192,193,194,195,196,122,197,198],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":203,"licenseFileUrl":204,"sourceHtmlUrl":205,"categories":206,"keywords":212,"publishedAt":39},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[207,208,211],{"categoryNo":173,"categoryName":174,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":209,"categoryName":210,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},[213,119,186,214,215],"resemble detect","https","identity",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":203,"licenseFileUrl":220,"sourceHtmlUrl":221,"categories":222,"keywords":227,"publishedAt":39},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[223,226],{"categoryNo":224,"categoryName":225,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},[228,229,230,231,37,95,9,118,232,233,214,234,235,236,237,238,239,240,241,242,243,244,103,245,246,247,248],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]