Turn a code pattern the user doesn't want into a check that finds it without them — an oxlint rule in `scripts/oxlint/shift-plugin.mjs`, a workspace clippy lint, or a report in `shift-scan` (Rust) or `scan-ts` (TypeScript) — and clean up what it finds. Use when the user says "I don't like X", "we keep doing X", "add a lint/rule/check for X", "make this a rule", "scan for X", "can we catch this automatically", or when the same review comment comes up a second time. Also use to run the scanners on a branch before review.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Every pattern the user has to point out twice should be found by a tool after that. A rule that blocks is better than a report; a report is better than a reviewer remembering.
Write a before/after for the pattern from real code (file:line), and one case that looks similar
but is fine. Show it with show_code and agree it with the user before writing the check: a rule
that flags the wrong thing teaches everyone to ignore it.
| The pattern is | Put it in | Effect |
|---|---|---|
| Decidable in one TypeScript file, from syntax | a rule in scripts/oxlint/shift-plugin.mjs, enabled in .oxlintrc.json | blocks in pnpm lint:check and CI |
| Covered by an existing clippy lint | [workspace.lints.clippy] in Cargo.toml | blocks in clippy and CI |
Covered by an oxlint built-in or a plugin rule (@shadcn/lint for the design system) | .oxlintrc.json (the root, or a package's for its own rules) | blocks |
| Needs other files, types, or a reviewer's judgement (TypeScript) | a kind in scripts/scan/scan-ts.mjs | pnpm scan:ts reports |
| Rust structure clippy can't see (free functions, shared shapes, chains) | a Kind in crates/shift-scan | pnpm scan:rust reports |
Prefer the first row that fits. A scanner kind is right when some hits are correct code (a free numeric helper, a cache that really is a cache), so it can't block.
Run the new check over the tree first (pnpm lint:check, pnpm scan:ts --kind <kind>,
pnpm scan:rust --kind <kind>) and report the count with a few real hits.
lint:check runs with --deny-warnings, so a "warn" rule blocks as well as "error".
oxlint rule: copy the shape of a nearby rule in shift-plugin.mjs (meta.messages saying
what to write instead, create(context) returning node visitors). Add describe cases to
scripts/oxlint/shift-plugin.test.mjs for a flagged line and an unflagged look-alike; run
pnpm test:lint-rules.
scan-ts kind: add it to KINDS, check it in FileScan#check (or across files in
TsScan#findings), add a test in scripts/scan/scan-ts.test.mjs; run pnpm test:scan.
shift-scan kind: add a Kind variant (with as_str), report it from FileScan or
CrateScan, and add a test in crate_scan.rs. Then run:
cargo test -p shift-scan
cargo clippy -p shift-scan --all-targets -- -D warnings
cargo fmt -p shift-scan
Add or update the rule's line in the skill that owns it (typescript, rust, signals,
writing-tests, ui, jsdoc) and end it with "Enforced by shift/<rule>" or "Reported by
pnpm scan:ts --kind <kind>". AGENTS.md's anti-slop list holds only rules no tool checks;
remove a rule from it once a check covers it.
Before review, report only what the branch touches:
pnpm scan:ts --since origin/main
pnpm scan:rust --since origin/main
Treat each finding as a question, not a failure: say for each whether to fix it in the branch, leave it (and why), or turn it into a rule.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Canonical rules for writing git commits in the Shift codebase. Use whenever the user asks to commit, stage and commit, create a pull request that requires commits, or draft a commit message. Enforces Conventional Commits, release-note quality, concise subjects, and logical commit boundaries.
日本語の概要は準備中です。原文の説明を表示しています。
Find and remove dead code (unused files, exports, class members) using Knip as a candidate generator, then verify each candidate through AST-level analysis and interface tracing before removing anything. Use when the user asks to clean up unused code, find dead code, or reduce the codebase.
日本語の概要は準備中です。原文の説明を表示しています。
Update or create DOCS.md files for Shift subsystems. Use this skill whenever the user asks to update docs, refresh documentation, create a DOCS.md, write module documentation, or says "update docs for X". Also trigger after completing a large feature when Claude.md says to update docs — check if any DOCS.md in the affected subsystem needs refreshing.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially fact-check DOCS.md files against the actual source code, verifying every concrete claim rather than trusting structure checks. Use when the user asks to audit docs, verify documentation accuracy, check whether docs are still true, or on a scheduled documentation review. This is the semantic layer the mechanical checkers cannot cover.
日本語の概要は準備中です。原文の説明を表示しています。
Canonical rules for finding, creating, and updating Shift GitHub issues. Use whenever the user asks to file, create, open, update, triage, or search for an issue, or when substantial work needs an issue before a pull request. Prevents duplicates and defines acceptance criteria and pull-request closure semantics.
日本語の概要は準備中です。原文の説明を表示しています。
Add or revise source-level JSDoc for Shift APIs. Use this skill before writing or editing documentation comments for exported classes, methods, constructors, domain data structures, render frames, reactive state, or any API where caller intent, side effects, lifetime, ownership, or nullability are easy to misunderstand.
日本語の概要は準備中です。原文の説明を表示しています。