[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7B66DH3EX8C4A3JBAPB1NCY":3,"skill-same:01M7B66DH3EX8C4A3JBAPB1NCY":61},{"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":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M7B66DH3EX8C4A3JBAPB1NCY","lens-review",null,"USE WHEN reviewing uncommitted work, a branch diff or a pull request through several installed skills, each run as its own review lens; NOT WHEN you need one cold second opinion (double-check), a verdict against a specification (acceptance-review) or the built-in fixed-lens \u002Fcode-review. Runs each lens in an isolated read-only agent, has a separate agent try to refute every finding, and returns one severity-ranked report.","mintuz\u002Fskills","mintuz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F447031?v=4","01M6BVWJYSVR4XQC9AQCEMWQRG","Adam Bulmer","01M6C4DCXKNYZB281YB3PZDJJG",35,"MIT","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Flens-review\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: lens-review\ndescription: \"USE WHEN reviewing uncommitted work, a branch diff or a pull request through several installed skills, each run as its own review lens; NOT WHEN you need one cold second opinion (double-check), a verdict against a specification (acceptance-review) or the built-in fixed-lens \u002Fcode-review. Runs each lens in an isolated read-only agent, has a separate agent try to refute every finding, and returns one severity-ranked report.\"\n---\n\n# Lens review\n\nReview one diff through several lenses. A lens is one installed skill, loaded by one read-only sub-agent that judges only that skill's concern. You are the orchestrator: resolve the diff, compose the roster, run the lenses, have each finding verified, and write one report.\n\nRead these before the step that needs them:\n\n| Reference | Read before |\n| --- | --- |\n| [`references\u002Flenses.md`](references\u002Flenses.md) | Step 3: the built-in lens, the default and detected lenses, and the lens brief |\n| [`references\u002Fworkflow.md`](references\u002Fworkflow.md) | Step 4: how to run the lenses and verifiers on each host |\n| `babysit` forge reference: [GitHub](..\u002Fbabysit\u002Freferences\u002Fgithub.md) or [Forgejo and Gitea](..\u002Fbabysit\u002Freferences\u002Fforgejo.md) | Step 1 for a PR target, and step 7 |\n\n## Invocation\n\n`\u002Flens-review [target] [modifiers] [lens...]`. In Codex, use `$lens-review` with the same tokens.\n\n| Token | Meaning |\n| --- | --- |\n| *(no target)* | Review the current branch: the diff from the merge base with the default branch, plus uncommitted changes |\n| `wip` | Review only the uncommitted changes, staged and unstaged, against `HEAD` |\n| `#123`, `123` or a PR URL | Review that pull request (PR) |\n| `\u003Cskill-name>` | Add that installed skill as a lens |\n| `only \u003Cnames...>` | Use exactly the named lenses: no built-in, default or detected lens |\n| `-\u003Cname>` | Remove that lens from the roster |\n| `thorough` | Run every detected lens, and use three verifiers for each finding |\n| `post` | Post the report to the PR as a comment. Needs a PR target |\n\nExamples: `\u002Flens-review`, `\u002Flens-review #482 thorough`, `\u002Flens-review wip only react-testing xstate`, `\u002Flens-review 57 post`.\n\nIf a token is not a token in this table and does not name an installed skill, stop before any lens runs. Report the token, list near matches from the installed skills, and ask the user. Do not substitute a near match by yourself. In the same message, show the diff command from step 1 and the roster from step 3, including the lenses it leaves not covered, so the user answers with the full plan.\n\n## 1. Resolve the diff\n\n- **Branch** (no target): run `git diff $(git merge-base \u003Cdefault-branch> HEAD)`. This includes committed and uncommitted changes to tracked files. Run `git status --porcelain` and include untracked files. Say that uncommitted changes are included.\n- **`wip`**: run `git diff HEAD`, and include untracked files from `git status --porcelain`.\n- **PR**: use the forge's *PR details* and *PR diff* rows. Record the PR title, body, base branch and head SHA.\n- **Stacked branch**: if stack metadata names an immediate parent branch, diff against that parent, not against the default branch.\n\nIf the diff is empty or the target does not resolve, stop and report that. Do not review.\n\n## 2. Scout inline\n\nDo not use sub-agents for this step.\n\n1. Sort the changed files into production, test, configuration and documentation.\n2. Read the project's `CLAUDE.md` or `AGENTS.md`, its package or build manifests, and any glossary or decision records. Record the stack and the local conventions.\n3. Record the change's claim: the PR title and body, the commit messages, or the intent that the user stated. The lenses judge the diff against this claim.\n\n## 3. Compose the roster\n\n1. Apply [`references\u002Flenses.md`](references\u002Flenses.md): the built-in `quality` lens, the stack defaults, and the detected lenses.\n2. Apply the user's tokens: `only`, added names and `-\u003Cname>` removals. With `only`, record each omitted lens as not covered.\n3. Keep 3–6 skill lenses. If detection finds more, keep the lenses most relevant to the diff and record the others as not covered. With `thorough`, run them all.\n4. Tell the user, in one line, the roster and the scale: the number of lens nodes, plus one verifier for each unique finding (three with `thorough`).\n5. If the roster has more than 8 lens nodes, ask the user before you launch, unless they gave `thorough`. Otherwise, launch without asking.\n\n## 4. Run the lenses\n\nRun every lens node in parallel, in its own context. Brief each one with the lens brief in `references\u002Flenses.md`. Lens nodes do not modify files. Follow the section of [`references\u002Fworkflow.md`](references\u002Fworkflow.md) for the host:\n\n- **Claude Code**: the `Workflow` script. A user who invokes this skill has opted in to the workflow.\n- **No workflow tool** (for example OMP): sub-agents launched in one message.\n- **Codex**: fresh threads or sub-agents.\n- **No sub-agents**: each lens in sequence, labelled `sequential (degraded): not independent`.\n\n## 5. Verify and merge\n\n1. Retry a lens that returns nothing or malformed output once. Then record it as lost and list it under Not covered. A lost lens is not a clean result.\n2. Merge findings that share a file, line and claim. Record which lenses agree. Agreement is a signal, not proof.\n3. Give each unique finding to a fresh verifier. Send the claim, its evidence and the base and head refs. Never send the lens's brief or reasoning.\n4. Tell the verifier to try to refute the finding against the code. It returns `confirmed`, `refuted`, or `unverifiable` when it cannot decide either way. With `thorough`, use three verifiers and take the majority. A tie is `unverifiable`.\n\nGive each verifier these review checks:\n\n- Does the problem exist at that `file:line` at the head ref?\n- Is it a rule of that lens's skill, not a matter of taste?\n- Did this diff introduce it? If the problem is only in unchanged code, it is pre-existing and out of scope, unless the diff makes it worse.\n\nAfter verification:\n\n- If two confirmed findings make incompatible suggestions for the same code, report a conflict with both arguments. Do not choose a winner.\n- If a finding contradicts an explicit local convention from step 2, report it as a conflict. Do not enforce the lens over the convention.\n\n## 6. Report\n\n```markdown\n## Lens review: \u003Ctarget> — \u003Cthe change's claim in one line>\n\n**Roster:** \u003Clenses run> · **Scale:** \u003Cn lens nodes; m findings verified: c confirmed, r refuted, u unverifiable> · **Runtime:** \u003Cworkflow | sub-agents | Codex threads | sequential (degraded)>\n\n| Lens | Verdict | Confirmed findings |\n| --- | --- | --- |\n| \u003Clens> | ✅ \u002F ⚠️ \u002F ❌ | \u003Cn> |\n\n**Recommendation:** APPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n\n### Confirmed findings\n\u003Cseverity> **[\u003Clens or lenses>] \u003Ctitle>** — `\u003Cfile>:\u003Cline>`\nProblem. Why it matters. Suggested fix.\n\n### Conflicts            (only when present; both arguments)\n### Unverifiable claims  (each one, with what blocked the check)\n### Clean                (what the lenses inspected and found sound)\n### Not covered          (omitted lenses, lost nodes, scope that no lens could judge)\n```\n\n- Rank confirmed findings by severity, then by the number of lenses that agree, then by confidence.\n- When several lenses report the same claim, show it once and name each lens.\n- Count refuted findings in the scale line. Do not list them.\n- Recommendation: any confirmed `critical` finding gives REQUEST CHANGES. Otherwise, an unresolved conflict gives NEEDS DISCUSSION. Otherwise, give APPROVE and list the minor findings.\n\n## 7. Post the report\n\nDo this step only when the user gave `post`.\n\n1. If the target is not a PR, do not post and do not create a PR. Tell the user that the report stays local.\n2. Pick the forge from the remote, then confirm access before you post: `gh auth status` for GitHub, `tea logins list` for Forgejo or Gitea. If access fails, stop and report it.\n3. Write the report to a file outside the worktree. Start it with `## lens-review` and name the roster.\n4. Post the file with the *Comment on the PR* row. Never put the report text in a shell argument.\n5. Post a comment only. Never approve the PR or submit a review state, even if the user asks or the recommendation is APPROVE. Tell the user that the approval is theirs to give.\n\n## Boundaries\n\n- `double-check` gives independence: one cold reviewer, preferably from another provider. This skill gives breadth through your own skills, but every lens shares the host model's blind spots. Run `lens-review` first and `double-check` last on high-stakes work.\n- `acceptance-review` decides whether a change meets a specification. This skill does not give an acceptance verdict.\n- The built-in `\u002Fcode-review` uses fixed issue classes. This skill uses the installed skills that you choose.\n- `babysit` takes the reviewed branch to green CI and merge.\n\n## Done\n\n- You showed the roster and scale before launch.\n- Each lens node loaded one skill and judged only its concern.\n- Each reported finding survived a verifier, with `file:line` evidence.\n- The report shows conflicts, unverifiable claims, clean areas and gaps in coverage.\n- You posted only with the `post` token, and only as a comment.\n","# Lens review\n\nReview one diff through several lenses. A lens is one installed skill, loaded by one read-only sub-agent that judges only that skill's concern. You are the orchestrator: resolve the diff, compose the roster, run the lenses, have each finding verified, and write one report.\n\nRead these before the step that needs them:\n\n| Reference | Read before |\n| --- | --- |\n| [`references\u002Flenses.md`](references\u002Flenses.md) | Step 3: the built-in lens, the default and detected lenses, and the lens brief |\n| [`references\u002Fworkflow.md`](references\u002Fworkflow.md) | Step 4: how to run the lenses and verifiers on each host |\n| `babysit` forge reference: [GitHub](..\u002Fbabysit\u002Freferences\u002Fgithub.md) or [Forgejo and Gitea](..\u002Fbabysit\u002Freferences\u002Fforgejo.md) | Step 1 for a PR target, and step 7 |\n\n## Invocation\n\n`\u002Flens-review [target] [modifiers] [lens...]`. In Codex, use `$lens-review` with the same tokens.\n\n| Token | Meaning |\n| --- | --- |\n| *(no target)* | Review the current branch: the diff from the merge base with the default branch, plus uncommitted changes |\n| `wip` | Review only the uncommitted changes, staged and unstaged, against `HEAD` |\n| `#123`, `123` or a PR URL | Review that pull request (PR) |\n| `\u003Cskill-name>` | Add that installed skill as a lens |\n| `only \u003Cnames...>` | Use exactly the named lenses: no built-in, default or detected lens |\n| `-\u003Cname>` | Remove that lens from the roster |\n| `thorough` | Run every detected lens, and use three verifiers for each finding |\n| `post` | Post the report to the PR as a comment. Needs a PR target |\n\nExamples: `\u002Flens-review`, `\u002Flens-review #482 thorough`, `\u002Flens-review wip only react-testing xstate`, `\u002Flens-review 57 post`.\n\nIf a token is not a token in this table and does not name an installed skill, stop before any lens runs. Report the token, list near matches from the installed skills, and ask the user. Do not substitute a near match by yourself. In the same message, show the diff command from step 1 and the roster from step 3, including the lenses it leaves not covered, so the user answers with the full plan.\n\n## 1. Resolve the diff\n\n- **Branch** (no target): run `git diff $(git merge-base \u003Cdefault-branch> HEAD)`. This includes committed and uncommitted changes to tracked files. Run `git status --porcelain` and include untracked files. Say that uncommitted changes are included.\n- **`wip`**: run `git diff HEAD`, and include untracked files from `git status --porcelain`.\n- **PR**: use the forge's *PR details* and *PR diff* rows. Record the PR title, body, base branch and head SHA.\n- **Stacked branch**: if stack metadata names an immediate parent branch, diff against that parent, not against the default branch.\n\nIf the diff is empty or the target does not resolve, stop and report that. Do not review.\n\n## 2. Scout inline\n\nDo not use sub-agents for this step.\n\n1. Sort the changed files into production, test, configuration and documentation.\n2. Read the project's `CLAUDE.md` or `AGENTS.md`, its package or build manifests, and any glossary or decision records. Record the stack and the local conventions.\n3. Record the change's claim: the PR title and body, the commit messages, or the intent that the user stated. The lenses judge the diff against this claim.\n\n## 3. Compose the roster\n\n1. Apply [`references\u002Flenses.md`](references\u002Flenses.md): the built-in `quality` lens, the stack defaults, and the detected lenses.\n2. Apply the user's tokens: `only`, added names and `-\u003Cname>` removals. With `only`, record each omitted lens as not covered.\n3. Keep 3–6 skill lenses. If detection finds more, keep the lenses most relevant to the diff and record the others as not covered. With `thorough`, run them all.\n4. Tell the user, in one line, the roster and the scale: the number of lens nodes, plus one verifier for each unique finding (three with `thorough`).\n5. If the roster has more than 8 lens nodes, ask the user before you launch, unless they gave `thorough`. Otherwise, launch without asking.\n\n## 4. Run the lenses\n\nRun every lens node in parallel, in its own context. Brief each one with the lens brief in `references\u002Flenses.md`. Lens nodes do not modify files. Follow the section of [`references\u002Fworkflow.md`](references\u002Fworkflow.md) for the host:\n\n- **Claude Code**: the `Workflow` script. A user who invokes this skill has opted in to the workflow.\n- **No workflow tool** (for example OMP): sub-agents launched in one message.\n- **Codex**: fresh threads or sub-agents.\n- **No sub-agents**: each lens in sequence, labelled `sequential (degraded): not independent`.\n\n## 5. Verify and merge\n\n1. Retry a lens that returns nothing or malformed output once. Then record it as lost and list it under Not covered. A lost lens is not a clean result.\n2. Merge findings that share a file, line and claim. Record which lenses agree. Agreement is a signal, not proof.\n3. Give each unique finding to a fresh verifier. Send the claim, its evidence and the base and head refs. Never send the lens's brief or reasoning.\n4. Tell the verifier to try to refute the finding against the code. It returns `confirmed`, `refuted`, or `unverifiable` when it cannot decide either way. With `thorough`, use three verifiers and take the majority. A tie is `unverifiable`.\n\nGive each verifier these review checks:\n\n- Does the problem exist at that `file:line` at the head ref?\n- Is it a rule of that lens's skill, not a matter of taste?\n- Did this diff introduce it? If the problem is only in unchanged code, it is pre-existing and out of scope, unless the diff makes it worse.\n\nAfter verification:\n\n- If two confirmed findings make incompatible suggestions for the same code, report a conflict with both arguments. Do not choose a winner.\n- If a finding contradicts an explicit local convention from step 2, report it as a conflict. Do not enforce the lens over the convention.\n\n## 6. Report\n\n```markdown\n## Lens review: \u003Ctarget> — \u003Cthe change's claim in one line>\n\n**Roster:** \u003Clenses run> · **Scale:** \u003Cn lens nodes; m findings verified: c confirmed, r refuted, u unverifiable> · **Runtime:** \u003Cworkflow | sub-agents | Codex threads | sequential (degraded)>\n\n| Lens | Verdict | Confirmed findings |\n| --- | --- | --- |\n| \u003Clens> | ✅ \u002F ⚠️ \u002F ❌ | \u003Cn> |\n\n**Recommendation:** APPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n\n### Confirmed findings\n\u003Cseverity> **[\u003Clens or lenses>] \u003Ctitle>** — `\u003Cfile>:\u003Cline>`\nProblem. Why it matters. Suggested fix.\n\n### Conflicts            (only when present; both arguments)\n### Unverifiable claims  (each one, with what blocked the check)\n### Clean                (what the lenses inspected and found sound)\n### Not covered          (omitted lenses, lost nodes, scope that no lens could judge)\n```\n\n- Rank confirmed findings by severity, then by the number of lenses that agree, then by confidence.\n- When several lenses report the same claim, show it once and name each lens.\n- Count refuted findings in the scale line. Do not list them.\n- Recommendation: any confirmed `critical` finding gives REQUEST CHANGES. Otherwise, an unresolved conflict gives NEEDS DISCUSSION. Otherwise, give APPROVE and list the minor findings.\n\n## 7. Post the report\n\nDo this step only when the user gave `post`.\n\n1. If the target is not a PR, do not post and do not create a PR. Tell the user that the report stays local.\n2. Pick the forge from the remote, then confirm access before you post: `gh auth status` for GitHub, `tea logins list` for Forgejo or Gitea. If access fails, stop and report it.\n3. Write the report to a file outside the worktree. Start it with `## lens-review` and name the roster.\n4. Post the file with the *Comment on the PR* row. Never put the report text in a shell argument.\n5. Post a comment only. Never approve the PR or submit a review state, even if the user asks or the recommendation is APPROVE. Tell the user that the approval is theirs to give.\n\n## Boundaries\n\n- `double-check` gives independence: one cold reviewer, preferably from another provider. This skill gives breadth through your own skills, but every lens shares the host model's blind spots. Run `lens-review` first and `double-check` last on high-stakes work.\n- `acceptance-review` decides whether a change meets a specification. This skill does not give an acceptance verdict.\n- The built-in `\u002Fcode-review` uses fixed issue classes. This skill uses the installed skills that you choose.\n- `babysit` takes the reviewed branch to green CI and merge.\n\n## Done\n\n- You showed the roster and scale before launch.\n- Each lens node loaded one skill and judged only its concern.\n- Each reported finding survived a verifier, with `file:line` evidence.\n- The report shows conflicts, unverifiable claims, clean areas and gaps in coverage.\n- You posted only with the `post` token, and only as a comment.\n",{"name":5,"description":7},"main","8cc95d9146ca13624d48611702d0ab12bbe7756a","src\u002Fcore\u002Fskills\u002Flens-review",7,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills","https:\u002F\u002Fgithub.com\u002Fmintuz","http:\u002F\u002Fwww.mintuz.com","Working at @monzo, Previously worked at Moonpig, @booking and @bbc","2026-11-13 19:21:11",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add mintuz\u002Fskills --skill lens-review",{"tool":39,"command":40},"bunx","bunx skills add mintuz\u002Fskills --skill lens-review",{"tool":42,"command":43},"pnpm","pnpm dlx skills add mintuz\u002Fskills --skill lens-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Flens-review\u002FSKILL.md",true,[47,53,57],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"agents\u002Fopenai.yaml","REFERENCE","参考文档",310,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Flens-review\u002Fagents\u002Fopenai.yaml",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Flenses.md",4717,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Flens-review\u002Freferences\u002Flenses.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fworkflow.md",5728,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Flens-review\u002Freferences\u002Fworkflow.md",[62,86,109,122,143,160],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":76,"publishedAt":85},"01M6C4PDGB6ZZWBS35N3DF7PZZ","xstate","WHEN React state changes in response to an external answer — async submit, in-flight or loading flags, retries, cancellation, polling, optimistic updates, stale responses — or to an interaction with an interruptible middle, such as a drag or a gesture; or WHEN building, reviewing, testing, or visualising XState 5 actors and @xstate\u002Freact integrations; NOT for a value one event sets completely, such as a text draft, a focus flag, or a plain open and closed toggle; models typed lifecycles and renders legal Mermaid stateDiagram-v2 charts.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fxstate\u002FSKILL.md",[68,73],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":74,"categoryName":75,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000009","前端开发",[64,77,78,79,80,81,82,83,84],"react","text","state","integrations","Charts","mermaid","testing","open","2026-11-10 10:12:30",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":100,"publishedAt":85},"01M6C4PB6VVC2X19B63B7YNH0T","web-design","WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fweb-design\u002FSKILL.md",[92,97],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":98,"categoryName":99,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000015","视觉设计",[101,102,103,104,105,106,107,108],"web","design","web design","code implementation","polish","ui","typography","code",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":85},"01M6C4P8D92GJDA49V7X1CZXEV","tailwind","USE WHEN writing, fixing or reviewing styling in a project that uses Tailwind CSS, even a one-class change or a request that does not name Tailwind: colours, focus rings, spacing, class names chosen by a prop, map or CVA variants, theme tokens and dark mode in the Tailwind stylesheet or tailwind.config, setup or upgrades (if unsure whether the project uses Tailwind, check package.json or the main stylesheet first); NOT WHEN writing plain CSS or Sass in a project without Tailwind; produces class names Tailwind can find, syntax for the installed major version, visible focus indicators, and no unrequested dependency or invented brand value.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Ftailwind\u002FSKILL.md",[115],{"categoryNo":98,"categoryName":99,"taxonomyType":71,"taxonomyTypeDesc":72},[117,118,119,120,102,121],"Tailwind","libraries","component","css","design systems",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":131,"publishedAt":85},"01M6C4P5VWQ69Q32DA0634GDJY","refactoring","WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Frefactoring\u002FSKILL.md",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000007","代码审查",[124,132,133,134,135,136,137,138,139,140,108,141,142],"Safety","baseline","refactor","behavior","change","plan","new feature","SET","up","feature delivery","test",{"skillNo":144,"name":77,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":150,"publishedAt":85},"01M6C4P345APEFEX00J8T7QMXQ","USE WHEN changing the logic, data, props, state, Effects or rendered text of a React component, hook or page, even a one-line change; NOT WHEN the request is styling only (class names, Tailwind, CSS, dark mode, spacing, shadows) or tests only, or when it models submit, in-flight, loading, retry or failure states, even for a named React form (xstate covers that, including its React wiring); applies React 19 composition, state, Effect, structure, API and performance rules with only the project's installed libraries.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact\u002FSKILL.md",[148,149],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},{"categoryNo":74,"categoryName":75,"taxonomyType":71,"taxonomyTypeDesc":72},[77,108,120,117,151,83,152,153,154,155,156,79,142,157,158,159],"performance","hooks","components","architecture","api","react components","state management","styling","management",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":168,"publishedAt":85},"01M6C4P0DK385QBG3B3S86TQV2","react-testing","USE WHEN writing, fixing or reviewing a React Testing Library test for a component, hook or context provider, even one small test, or when asked for an end-to-end journey inside a Vitest or React Testing Library suite; NOT WHEN changing the component itself (react), testing XState actors or @xstate\u002Freact (xstate), or writing a Playwright or Cypress test; covers renderHook, providers, async results, forms and false-pass anti-patterns, and declines end-to-end journeys with the testable slices.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact-testing\u002FSKILL.md",[166,167],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},{"categoryNo":74,"categoryName":75,"taxonomyType":71,"taxonomyTypeDesc":72},[169,83,77,170,152,171,172,173,153,174,175,156],"react testing","anti-patterns","e2e","library","testing library","Providers","context"]