[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSRWDDBGSFCD8RPB9DS9SJ":3,"skill-same:01M7CSRWDDBGSFCD8RPB9DS9SJ":49},{"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":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M7CSRWDDBGSFCD8RPB9DS9SJ","code-review-rubric",null,"Use when a task is in code_review - how to read the diff, which findings block, and the verdict move","makifbaysal\u002Ftasktrooper","makifbaysal","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25031940?v=4","01M7CRG3ZCSYZSSEVDMW3DEYC8","Mehmet Akif Baysal","01M7CRG401FJ8YAXH5ER730XYV",122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fsystem-architect\u002Fskills\u002Fcode-review-rubric\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: code-review-rubric\ncategory: quality\ndescription: Use when a task is in code_review - how to read the diff, which findings block, and the verdict move\nsource: obra\u002Fsuperpowers (MIT), adapted\n---\n# Code Review Rubric\n\n## Overview\n\nEvery task a developer finishes lands in code_review as a pull request. You are the last technical gate before QA. Review the PR diff against the task's acceptance criteria and the spec\u002Fplan — identify issues before they cascade.\n\n**Review is reading, not running.** The PR link and its diff are in your context — the file list (`git diff --stat`) in full, the patch cut at 24,000 bytes, ending `…(truncated)` when it was. You do not boot the app, run a build, run a test suite, or verify behaviour by executing it — the pipeline did that before you and QA does it after you. You also never edit the diff: a finding is written down and handed back, never fixed by the reviewer.\n\n## Before Reviewing\n\n1. `list_task_comments` — the only way to see an earlier need_revision comment (yours, QA's or the pipeline's). A re-submission enters code_review from `in_progress`, so that history is NOT re-injected. If one exists, load root-cause-review.\n2. get_pipeline_status — the build\u002Ftest pipeline runs on entry to code_review. Red pipeline → the task cannot pass review regardless of the diff.\n3. Read the task description, every acceptance criterion, the human's requirement comments on the task (injected as \"The human's requirements written on this task\"; `list_task_comments` shows them as `author_type=user`), the spec\u002Fplan reference, and any comment the developer left — a run that went cleanly leaves none, so the absence of one is normal and says nothing about the change.\n4. Read the injected PR diff completely, including every file the 24,000-byte cut left out — `run_terminal`: `base=$(git merge-base HEAD origin\u002FHEAD 2>\u002Fdev\u002Fnull || git merge-base HEAD origin\u002Fmain); git diff \"$base\" -- \u003Cpath>` (reading, not running), or `read_file`. Never give feedback on code you didn't actually read, and never approve a file you did not see.\n5. Check the repo's own `CLAUDE.md`\u002F`AGENTS.md`\u002F`CONTRIBUTING.md` for rules this diff might break — a violation is Important, quoted verbatim.\n\n## What to Check\n\n**Plan\u002FAC alignment**\n- Does the implementation match the plan, the acceptance criteria and the human's requirement comments? Is anything missing? Is anything extra beyond all of those (scope creep)?\n- The human's comments on the task outrank its description: a later comment that widens or changes the scope (\"show the logos in the marquee too\") makes that work part of THIS task, even when the description's out-of-scope list says otherwise. Review it like any criterion; never flag it as a scope violation or ask for it to be reverted or split.\n- Are deviations justified improvements or problematic departures? Flag them specifically so the developer can confirm intent.\n\n**Code quality**\n- Clean separation of concerns, proper error handling (no swallowed errors), type safety, DRY without premature abstraction, edge cases handled.\n- Reuse over rewriting (the developers' rule reuse-before-writing): a new helper, client or component that duplicates one the repository already has (name the existing path from grep_code); hand-rolled code for what the standard library or an installed dependency already does; hand-rolled crypto, auth, parsing, date\u002Ftime-zone or money math where an established library belongs; a new dependency for a few lines, for a job an installed one already does, without its lockfile change, or with a non-permissive licence. Important when the duplicate must change together with the original or the hand-rolled code is security- or correctness-critical; Minor otherwise.\n\n**Architecture**\n- Sound design decisions, integrates cleanly with surrounding code, respects layer boundaries (hexagonal: domain imports no adapters).\n\n**Domain impact (what the diff breaks outside itself)**\n- The diff is the subject of the review; its blast radius is not limited to the diff. A change is only correct if the code that depends on it is still correct.\n- Read outside the diff whenever it touches something shared — a domain type or its invariants, an interface or function signature, a DB query or migration, an API\u002Fevent contract, auth or tenancy scoping, a default value, a shared component. Use grep_code for the exact symbol, expand_symbol_context to read the callers, codebase_search for the concept, get_symbol_skeleton for structure.\n- Concrete questions: who else calls this and do they still hold? Does the migration break rows already in the table, or a reader deployed before it? Does a changed contract have a consumer in another repository (the task's project has more than one)? Did a renamed\u002Fremoved field leave a stale reader? Does a new query bypass the tenant\u002Fuser filter its neighbours apply?\n- Report an impact finding like any other: name the file:line OUTSIDE the diff that now breaks, and what in the diff breaks it. \"Might affect other callers\" is not a finding — the callers are one grep away.\n- Reading the repository for this is expected. Reviewing files the PR does not touch is not: unrelated pre-existing problems are at most a Minor note, never a reason to hand the task back.\n\n**Security**\n- Input validated at boundaries, parameterized queries, no secrets in code or logs, new endpoints behind the same auth as neighbors.\n- Load security-review for anything touching input handling, auth, queries, files, outbound requests, secrets, dependencies or LLM calls — it has the full checklist and severity mapping.\n- Load migration-and-contract-review for any migration, endpoint\u002FDTO, event payload or shared-type change — a rollback here is a `git revert` that leaves the schema in place.\n\n**Testing**\n- Tests verify real behavior, not mocks. Edge cases covered. New behavior has tests in the same diff. Pipeline green.\n\n**Frontend \u002F UI changes (web)**\n- Component placed at the right atomic level and reused instead of rebuilt — `INVENTORY.md` updated for any new component.\n- Presentation-only below pages: atoms\u002Fmolecules\u002Forganisms\u002Ftemplates take props in and callbacks out — no data hooks, no API calls.\n- Semantic tokens only — no raw palette classes, no hex, no arbitrary px values; `ui-guard` green if the repo has it.\n- Mobile-first classes (unprefixed = phone, `sm:`\u002F`md:`\u002F`lg:` upward) — no fixed pixel widths, no `h-screen`.\n- Required states present: loading\u002Fempty\u002Ferror on data views, hover\u002Ffocus-visible\u002Factive\u002Fdisabled on controls.\n- Accessibility basics: visible labels, focus-visible rings, icon-only buttons have accessible names.\n- The visual check is not yours to re-run or to demand: a frontend hand-off without a screenshot is refused by the system, and QA screenshots all four widths in in_qa. You judge the code that causes those bugs — a fixed pixel width or `w-[Npx]` on a layout box, `h-screen`, a `max-*:`-first layout, a flex\u002Fgrid child holding text without `min-w-0`, a hover-only control, a missing loading\u002Fempty\u002Ferror branch. Each is Important with the file:line.\n\n**Mobile UI changes** (a mobile repository's diff is not judged by the web rules above)\n- Component placed at the right atomic level for that repo's library, and `INVENTORY.md` updated.\n- Theme tokens only (`ui-guard`-equivalent test green if the repo has one) — no hard-coded colours or sizes.\n- Required states present: loading\u002Fempty\u002Ferror.\n- Touch targets ≥ 48dp (Android) \u002F 44pt (iOS), and icon-only controls carry an accessible label.\n- A size-matrix test exists for a changed layout (phone, tablet, both orientations).\n- The closing message names the render path used (device\u002Fsimulator\u002Fwidget previewer) and the matrix it checked — that is the mobile equivalent of the web four-width evidence, and its absence on a layout change is a finding.\n\n**Design conformance (every UI diff, web or mobile)** — judged by reading, like everything else here:\n- **Values come from the design system.** No raw hex\u002Frgb colour, px\u002Fdp\u002Fpt size, font size or font family outside the token files — `design\u002Ftokens.css`, `design\u002Ftokens.json` and the theme files built from them (`@theme` \u002F `:root` \u002F `.dark`, `ThemeData` \u002F `ThemeExtension`s, `Theme.swift` and the asset catalog, `Color.kt` \u002F `Type.kt`). Components reference tokens by name (`bg-primary`, `var(--space-4)`, `context.colors.primary`, `MaterialTheme.spacing.md`). A value the design system does not hold is a finding even when it looks right: the developer names it as missing, the designer adds it through a design task (`get_design_system` shows what exists).\n- **Components come from the inventory** (`design\u002FINVENTORY.md` and the repository's own `INVENTORY.md`): a component the approved hand-off does not mark NEW, or a second implementation of one the inventory already has, is a finding.\n- **The diff renders the approved design.** When your context carries \"## The approved design this task builds\", its `handoff: \u003Cscreen>` spec is the contract: the components and variants it names, every state it lists, its breakpoints, and its copy verbatim — compare string by string with its Copy table. A missing state, a paraphrased string, a different component or an element the design does not show is a finding, citing the hand-off line it contradicts. The task description is the narrower scope and wins where the two disagree; it never licenses a different look.\n- **Generated files stay generated.** `DESIGN.md` and `design\u002F*` are written verbatim from `get_design_system` `files: true`; a hand edit to one is a finding.\n\n## Severity Calibration\n\nNot everything is Critical:\n- **Critical (must fix):** bugs, security issues, data loss risk, broken functionality, or a weakened\u002Fdeleted test.\n- **Important (should fix):** unmet acceptance criterion, architecture problems, missing error handling, real test gaps.\n- **Minor:** style, optimization opportunities, polish. Never blocks and is never a comment on its own — list it only at the end of a need_revision comment under `Minor (optional):`.\n- **Frontend specifics (must-fix, Critical or Important):** a duplicated\u002Fre-built component, raw or off-palette colours, a missing required state, or one of the layout bugs named above (fixed width, `h-screen`, missing `min-w-0`, …) found in the code.\n- **Design conformance (Important):** a value outside the design system, a component outside the inventory, or a deviation from the approved design — file:line plus the token, inventory entry or hand-off line it contradicts.\n\nFor each finding: file:line, what's wrong, why it matters, how to fix if not obvious. In a need_revision comment you may add ONE line on what is right and should be kept, so the developer does not undo it — never a comment for praise alone.\n\n## Worked Example (a finding done right)\n\n> **Critical — internal\u002Fapplication\u002Fexport\u002Fservice.go:24.** `ListByProject` error is ignored (`tasks, _ := repo.ListByProject(...)`): on a DB failure the export returns an empty CSV as if the project had no tasks — silent data loss. Fix: propagate the error and map it to 500. Blocks: unmet AC2 (must surface failures) + swallowed error.\n\nContrast the useless version: *\"improve error handling in the export service.\"* The good finding names the file:line, the exact mechanism, the user-visible consequence, and the fix — the developer can act without a second round-trip.\n\n## Verdict (mandatory — never leave without one)\n\n- Pipeline green AND no Critical\u002FImportant findings → `move_board_task` to **ready_for_qa** and write nothing: the move, the green pipeline and the history are the record (add_task_comment's own contract).\n- Pipeline red OR any Critical\u002FImportant finding → move_board_task to **need_revision** with a numbered comment: each item quotes the acceptance criterion or exact defect location and states what must change. Put every Critical\u002FImportant finding in this ONE comment — a second round judges only the prior points plus what the new diff changed; three moves into need_revision without a human touch park the task automatically, so a real design disagreement belongs there, not a fourth round-trip.\n\n## Never\n\n- Say \"looks good\" without having read the diff.\n- Run the app, a build, or a test suite to review it — reproducing the pipeline burns the run and answers a question that already has an answer.\n- Fix a finding yourself, or push anything to the branch. You write findings; the developer writes code.\n- Mark nitpicks as Critical, or block on Minor findings.\n- Be vague (\"improve error handling\") — every finding is actionable.\n- Approve by assumption — cite the diff and the pipeline result.\n","# Code Review Rubric\n\n## Overview\n\nEvery task a developer finishes lands in code_review as a pull request. You are the last technical gate before QA. Review the PR diff against the task's acceptance criteria and the spec\u002Fplan — identify issues before they cascade.\n\n**Review is reading, not running.** The PR link and its diff are in your context — the file list (`git diff --stat`) in full, the patch cut at 24,000 bytes, ending `…(truncated)` when it was. You do not boot the app, run a build, run a test suite, or verify behaviour by executing it — the pipeline did that before you and QA does it after you. You also never edit the diff: a finding is written down and handed back, never fixed by the reviewer.\n\n## Before Reviewing\n\n1. `list_task_comments` — the only way to see an earlier need_revision comment (yours, QA's or the pipeline's). A re-submission enters code_review from `in_progress`, so that history is NOT re-injected. If one exists, load root-cause-review.\n2. get_pipeline_status — the build\u002Ftest pipeline runs on entry to code_review. Red pipeline → the task cannot pass review regardless of the diff.\n3. Read the task description, every acceptance criterion, the human's requirement comments on the task (injected as \"The human's requirements written on this task\"; `list_task_comments` shows them as `author_type=user`), the spec\u002Fplan reference, and any comment the developer left — a run that went cleanly leaves none, so the absence of one is normal and says nothing about the change.\n4. Read the injected PR diff completely, including every file the 24,000-byte cut left out — `run_terminal`: `base=$(git merge-base HEAD origin\u002FHEAD 2>\u002Fdev\u002Fnull || git merge-base HEAD origin\u002Fmain); git diff \"$base\" -- \u003Cpath>` (reading, not running), or `read_file`. Never give feedback on code you didn't actually read, and never approve a file you did not see.\n5. Check the repo's own `CLAUDE.md`\u002F`AGENTS.md`\u002F`CONTRIBUTING.md` for rules this diff might break — a violation is Important, quoted verbatim.\n\n## What to Check\n\n**Plan\u002FAC alignment**\n- Does the implementation match the plan, the acceptance criteria and the human's requirement comments? Is anything missing? Is anything extra beyond all of those (scope creep)?\n- The human's comments on the task outrank its description: a later comment that widens or changes the scope (\"show the logos in the marquee too\") makes that work part of THIS task, even when the description's out-of-scope list says otherwise. Review it like any criterion; never flag it as a scope violation or ask for it to be reverted or split.\n- Are deviations justified improvements or problematic departures? Flag them specifically so the developer can confirm intent.\n\n**Code quality**\n- Clean separation of concerns, proper error handling (no swallowed errors), type safety, DRY without premature abstraction, edge cases handled.\n- Reuse over rewriting (the developers' rule reuse-before-writing): a new helper, client or component that duplicates one the repository already has (name the existing path from grep_code); hand-rolled code for what the standard library or an installed dependency already does; hand-rolled crypto, auth, parsing, date\u002Ftime-zone or money math where an established library belongs; a new dependency for a few lines, for a job an installed one already does, without its lockfile change, or with a non-permissive licence. Important when the duplicate must change together with the original or the hand-rolled code is security- or correctness-critical; Minor otherwise.\n\n**Architecture**\n- Sound design decisions, integrates cleanly with surrounding code, respects layer boundaries (hexagonal: domain imports no adapters).\n\n**Domain impact (what the diff breaks outside itself)**\n- The diff is the subject of the review; its blast radius is not limited to the diff. A change is only correct if the code that depends on it is still correct.\n- Read outside the diff whenever it touches something shared — a domain type or its invariants, an interface or function signature, a DB query or migration, an API\u002Fevent contract, auth or tenancy scoping, a default value, a shared component. Use grep_code for the exact symbol, expand_symbol_context to read the callers, codebase_search for the concept, get_symbol_skeleton for structure.\n- Concrete questions: who else calls this and do they still hold? Does the migration break rows already in the table, or a reader deployed before it? Does a changed contract have a consumer in another repository (the task's project has more than one)? Did a renamed\u002Fremoved field leave a stale reader? Does a new query bypass the tenant\u002Fuser filter its neighbours apply?\n- Report an impact finding like any other: name the file:line OUTSIDE the diff that now breaks, and what in the diff breaks it. \"Might affect other callers\" is not a finding — the callers are one grep away.\n- Reading the repository for this is expected. Reviewing files the PR does not touch is not: unrelated pre-existing problems are at most a Minor note, never a reason to hand the task back.\n\n**Security**\n- Input validated at boundaries, parameterized queries, no secrets in code or logs, new endpoints behind the same auth as neighbors.\n- Load security-review for anything touching input handling, auth, queries, files, outbound requests, secrets, dependencies or LLM calls — it has the full checklist and severity mapping.\n- Load migration-and-contract-review for any migration, endpoint\u002FDTO, event payload or shared-type change — a rollback here is a `git revert` that leaves the schema in place.\n\n**Testing**\n- Tests verify real behavior, not mocks. Edge cases covered. New behavior has tests in the same diff. Pipeline green.\n\n**Frontend \u002F UI changes (web)**\n- Component placed at the right atomic level and reused instead of rebuilt — `INVENTORY.md` updated for any new component.\n- Presentation-only below pages: atoms\u002Fmolecules\u002Forganisms\u002Ftemplates take props in and callbacks out — no data hooks, no API calls.\n- Semantic tokens only — no raw palette classes, no hex, no arbitrary px values; `ui-guard` green if the repo has it.\n- Mobile-first classes (unprefixed = phone, `sm:`\u002F`md:`\u002F`lg:` upward) — no fixed pixel widths, no `h-screen`.\n- Required states present: loading\u002Fempty\u002Ferror on data views, hover\u002Ffocus-visible\u002Factive\u002Fdisabled on controls.\n- Accessibility basics: visible labels, focus-visible rings, icon-only buttons have accessible names.\n- The visual check is not yours to re-run or to demand: a frontend hand-off without a screenshot is refused by the system, and QA screenshots all four widths in in_qa. You judge the code that causes those bugs — a fixed pixel width or `w-[Npx]` on a layout box, `h-screen`, a `max-*:`-first layout, a flex\u002Fgrid child holding text without `min-w-0`, a hover-only control, a missing loading\u002Fempty\u002Ferror branch. Each is Important with the file:line.\n\n**Mobile UI changes** (a mobile repository's diff is not judged by the web rules above)\n- Component placed at the right atomic level for that repo's library, and `INVENTORY.md` updated.\n- Theme tokens only (`ui-guard`-equivalent test green if the repo has one) — no hard-coded colours or sizes.\n- Required states present: loading\u002Fempty\u002Ferror.\n- Touch targets ≥ 48dp (Android) \u002F 44pt (iOS), and icon-only controls carry an accessible label.\n- A size-matrix test exists for a changed layout (phone, tablet, both orientations).\n- The closing message names the render path used (device\u002Fsimulator\u002Fwidget previewer) and the matrix it checked — that is the mobile equivalent of the web four-width evidence, and its absence on a layout change is a finding.\n\n**Design conformance (every UI diff, web or mobile)** — judged by reading, like everything else here:\n- **Values come from the design system.** No raw hex\u002Frgb colour, px\u002Fdp\u002Fpt size, font size or font family outside the token files — `design\u002Ftokens.css`, `design\u002Ftokens.json` and the theme files built from them (`@theme` \u002F `:root` \u002F `.dark`, `ThemeData` \u002F `ThemeExtension`s, `Theme.swift` and the asset catalog, `Color.kt` \u002F `Type.kt`). Components reference tokens by name (`bg-primary`, `var(--space-4)`, `context.colors.primary`, `MaterialTheme.spacing.md`). A value the design system does not hold is a finding even when it looks right: the developer names it as missing, the designer adds it through a design task (`get_design_system` shows what exists).\n- **Components come from the inventory** (`design\u002FINVENTORY.md` and the repository's own `INVENTORY.md`): a component the approved hand-off does not mark NEW, or a second implementation of one the inventory already has, is a finding.\n- **The diff renders the approved design.** When your context carries \"## The approved design this task builds\", its `handoff: \u003Cscreen>` spec is the contract: the components and variants it names, every state it lists, its breakpoints, and its copy verbatim — compare string by string with its Copy table. A missing state, a paraphrased string, a different component or an element the design does not show is a finding, citing the hand-off line it contradicts. The task description is the narrower scope and wins where the two disagree; it never licenses a different look.\n- **Generated files stay generated.** `DESIGN.md` and `design\u002F*` are written verbatim from `get_design_system` `files: true`; a hand edit to one is a finding.\n\n## Severity Calibration\n\nNot everything is Critical:\n- **Critical (must fix):** bugs, security issues, data loss risk, broken functionality, or a weakened\u002Fdeleted test.\n- **Important (should fix):** unmet acceptance criterion, architecture problems, missing error handling, real test gaps.\n- **Minor:** style, optimization opportunities, polish. Never blocks and is never a comment on its own — list it only at the end of a need_revision comment under `Minor (optional):`.\n- **Frontend specifics (must-fix, Critical or Important):** a duplicated\u002Fre-built component, raw or off-palette colours, a missing required state, or one of the layout bugs named above (fixed width, `h-screen`, missing `min-w-0`, …) found in the code.\n- **Design conformance (Important):** a value outside the design system, a component outside the inventory, or a deviation from the approved design — file:line plus the token, inventory entry or hand-off line it contradicts.\n\nFor each finding: file:line, what's wrong, why it matters, how to fix if not obvious. In a need_revision comment you may add ONE line on what is right and should be kept, so the developer does not undo it — never a comment for praise alone.\n\n## Worked Example (a finding done right)\n\n> **Critical — internal\u002Fapplication\u002Fexport\u002Fservice.go:24.** `ListByProject` error is ignored (`tasks, _ := repo.ListByProject(...)`): on a DB failure the export returns an empty CSV as if the project had no tasks — silent data loss. Fix: propagate the error and map it to 500. Blocks: unmet AC2 (must surface failures) + swallowed error.\n\nContrast the useless version: *\"improve error handling in the export service.\"* The good finding names the file:line, the exact mechanism, the user-visible consequence, and the fix — the developer can act without a second round-trip.\n\n## Verdict (mandatory — never leave without one)\n\n- Pipeline green AND no Critical\u002FImportant findings → `move_board_task` to **ready_for_qa** and write nothing: the move, the green pipeline and the history are the record (add_task_comment's own contract).\n- Pipeline red OR any Critical\u002FImportant finding → move_board_task to **need_revision** with a numbered comment: each item quotes the acceptance criterion or exact defect location and states what must change. Put every Critical\u002FImportant finding in this ONE comment — a second round judges only the prior points plus what the new diff changed; three moves into need_revision without a human touch park the task automatically, so a real design disagreement belongs there, not a fourth round-trip.\n\n## Never\n\n- Say \"looks good\" without having read the diff.\n- Run the app, a build, or a test suite to review it — reproducing the pipeline burns the run and answers a question that already has an answer.\n- Fix a finding yourself, or push anything to the branch. You write findings; the developer writes code.\n- Mark nitpicks as Critical, or block on Minor findings.\n- Be vague (\"improve error handling\") — every finding is actionable.\n- Approve by assumption — cite the diff and the pipeline result.\n",{"name":5,"source":24,"category":25,"description":7},"obra\u002Fsuperpowers (MIT), adapted","quality","main","910394a0b6db9fc8c9a8f36328ec421d3ebd8b38","catalog\u002Fagents\u002Fsystem-architect\u002Fskills\u002Fcode-review-rubric",18,"https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper","https:\u002F\u002Ftasktrooper.ai","https:\u002F\u002Fgithub.com\u002Fmakifbaysal","Senior Software Developer","2026-11-15 04:50:29",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add makifbaysal\u002Ftasktrooper --skill code-review-rubric",{"tool":41,"command":42},"bunx","bunx skills add makifbaysal\u002Ftasktrooper --skill code-review-rubric",{"tool":44,"command":45},"pnpm","pnpm dlx skills add makifbaysal\u002Ftasktrooper --skill code-review-rubric","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fsystem-architect\u002Fskills\u002Fcode-review-rubric\u002FSKILL.md",true,[],[50,56,63,70,77,84],{"skillNo":51,"name":52,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":19},"01M7CSVEPQW6J6TD6CS2T5FPNZ","visual-craft","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fvisual-craft\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M7CSVAQG91ETHQ0HBNZDG5FR","ux-copy","Use when you write any words a user reads in a mockup or a hand-off - content language and voice, buttons, labels, errors, empty states, confirmations, numbers and dates, and the longest-string check","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fux-copy\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M7CSV6H0J38659NDXHJQ8396","screen-mockup-html","Use when you draw screens as the design task's HTML mockup - ONE canvas document holding every screen and every variant side by side, the sanitizer-safe recipe, phone and wide frames, the states grid, static control states, and the loopback self-check with screenshots at 375, 768 and 1440 attached to the task","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fscreen-mockup-html\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7CSV3JFRF3BM3XK52M7YEYR","performance-awareness","How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7CSTZDH00YRF5SCT7BRT9QD","design-variants","Use when a screen design needs variants - how many, variants as side-by-side rows on the one canvas, what makes two variants genuinely different, recommending one, how the human's choice is read, and narrowing to the chosen one in revision","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-variants\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7CSTV6P3SM3PAE28DB0RF77","design-system-authoring","Use when you derive, change or extend a design system - where tokens live per stack, the DTCG token tree, role-based names for both themes, base vs layer vs drift, the DESIGN.md section order, the inventory format, the contrast check and the lint every proposal returns","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-system-authoring\u002FSKILL.md",[],[]]