correct
WHEN preventing a repeated codebase mistake; NOT for one-off hypotheses or writing preferences; proves scoped mechanical enforcement
- License 许可
- MIT
- 所属仓库
- mintuz/skills
- 最近更新
- 2026-11-13
- Stars
- ★ 35
- Forks
- 7
01 前言 Front Matter
- name
- correct
- description
- WHEN preventing a repeated codebase mistake; NOT for one-off hypotheses or writing preferences; proves scoped mechanical enforcement
03 SKILL.md 正文
Correct
Make a demonstrated recurring codebase mistake harder to express, within the authorized scope.
- Establish recurrence. Read relevant corrections, changes and failures. Cite at least two independent occurrences of the same concrete mistake and its consequence. Copied/resumed transcripts, a recap of one incident or an unenforced rule alone do not establish recurrence. Separate observed error from suspected cause; insufficient evidence calls for bounded diagnosis, not policy.
- Choose the owner. Keep one complete correction scoped to the affected behavior. Prefer eliminating the invalid path or duplicate state owner, then domain types, an executable check with an actionable error, then behavior tests. Explain briefly why a higher-level guard is unsuitable. Judgment-only lessons belong to
record-lesson; prose preferences belong to their writing owner. Stale or misactivated skill instructions belong to their canonical skill/evaluation/install owner, not a product architecture rewrite; useskill-doctorwhen available and apply the repository's skill TDD there. - Prove enforcement. Preserve a real prior bad example. Show the old mechanism accepts or misses it, then show the new guard rejects it. The corrected case and legitimate neighboring behavior must pass the same local/CI check. Preserve meaningful empty, absent or undefined outcomes when the contract requires them. A test that only copies implementation details cannot establish enforcement.
- Complete the authorized correction. Update affected callers and run focused regressions. For existing widespread violations, enforce new violations while naming the remaining migration scope. Keep the executable owner authoritative; any indispensable judgment rule stays small. Do not commit automatically, maintain a standing rule table, impose a blanket exceptions process, or renovate unrelated code.
Report the two evidence locators, chosen guard and scope, old-failure/new-enforcement results, valid-case checks and remaining limitations. If execution is unavailable, distinguish the proposed proof from a verified correction.
04 同仓库更多 Skills
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/react 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.
web-design
WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.
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.
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.
react
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.
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/react (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.