원클릭으로 Manus에서 모든 스킬 실행

시작하기

eslint-plugin-custom-rule

스타488

포크97

업데이트2026년 3월 27일 18:12

USE THIS when asked to create a new eslint plugin rule for the eslint-plugin-cds package

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

coinbase

coinbase/cds

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Writing new rules

Process

When asked to create a new custom rule for the package, follow these steps in order:

Run the scaffold-new-rule.mjs script found at packages/eslint-plugin-cds/scripts/scaffold-new-rule.mjs. The script should be used every time a new rule is created. This script will ensure that the same format is used for all custom rules created.
Ask the user what the custom rule should do. If the user doesn't provide enough context in the prompt, ask for clarification or follow up. Do not make assumptions about how a custom rule is meant to behave or what guideline it's supposed to enforce. After gathering the needed context, ask the user which package(s) the rule should be applied to.
Once you have all the needed context, ask the user to provide at least one valid and one invalid example demonstrating when the custom rule is being followed or not. This will help you to write tests for the custom rule in a future step. Similar to step 2, if the provided examples do not give you enough context to understand the difference between a valid versus invalid example, ask the user for clarification. Do not proceed until the user has provided at least one valid and one invalid example and you have enough needed context to understand a valid and invalid example.
Based on the user's provided context, fill in the rule file generated under the src/rules directory. The main section you should fill out is the create() function key that's in the rule object. You can refer to packages/eslint-plugin-cds/src/rules/custom-rule.ts for more documentation on how custom rules are formatted and information to enter. Custom rules should use the AST visitor methods to determine when rules have been violated and should report warnings in the linter. Custom rules should also verify the packages being imported before performing AST parsing. If a file doesn't import a package specified in step 2, do not report an error in the custom rule. Most custom rules already do this. As an example, you can refer to the ImportDeclaration() function in the no-v7-imports rule found here: packages/eslint-plugin-cds/src/rules/no-v7-imports.ts. The rule only reports an error when one of the CDS_PACKAGES packages is used,
Using the context from step 3, write in valid and invalid test cases for the test file generated from the scaffold-new-rule.mjs script. The valid and invalid examples provided in step 3 should be included. Based off those examples and the rule criteria provided in step 2, you can add additional valid or invalid examples.

Directory placement

Custom rules should always be placed in the packages/eslint-plugin-cds/src/rules directory. Tests for each custom rule should be placed in the packages/eslint-plugin-cds/tests directory.

이 저장소의 다른 Skills

같은 저장소

skill-creator

coinbase/cds

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

2026-06-26488

cds-code

coinbase/cds

Provides a structured workflow for writing high quality Coinbase Design System (CDS) code. Use this skill every time you are asked to create or update a user interface using React or React Native. Additinoally, this skill may be used to conduct a code review on existing code for CDS adherence. Trigger examples: "build this screen", "update this component", "perform a CDS audit on our changes", "check our codebase for CDS adherence", "does this feature use CDS well?"

2026-06-26488

cds-design-to-code

coinbase/cds

Turn Figma designs into CDS React (cds-web) or React Native (cds-mobile) code. Use when the user shares a Figma design URL (e.g. `figma.com/design/...?node-id=...`) or asks to "implement this design" or "build this from Figma" in a frontend project that is using Coinbase Design System (CDS). Do not use for general CDS UI work with no Figma reference (use `cds-code`), or for design critique without an implementation request.

2026-06-17488

cds-accessibility

coinbase/cds

Reviews already-written Coinbase Design System (CDS) UI for accessibility: verifying documented accessibility props (e.g. accessibilityLabel, accessibilityState), confirming the chosen CDS primitives cover the right assistive technology behavior, and checking usage against official CDS documentation—not generic web ARIA tutorials. Use this skill to review CDS UI for screen reader, keyboard, and labeled control requirements after the code has been written.

2026-06-16488

components-styles

coinbase/cds

Guidelines writing styles API (styles, classNames, and static classNames) for a CDS component. Use this skill when adding customization options to a React component via `styles` or `classNames` props or when needing to update the docsite with component styles documentation.

2026-06-15488

git-backport

coinbase/cds

Back-port a specific commit from master to a release branch via cherry-pick. Creates a dedicated backport branch, attempts the cherry-pick, pushes it, and opens a PR by default. Returns to the original branch when done (success or failure). If there are merge conflicts, diagnoses the root cause without attempting an autonomous resolution. Use when asked to "backport", "cherry-pick to release", or "port a fix to a release branch".

2026-06-11488

Writing new rules

Process

When asked to create a new custom rule for the package, follow these steps in order:

Run the scaffold-new-rule.mjs script found at packages/eslint-plugin-cds/scripts/scaffold-new-rule.mjs. The script should be used every time a new rule is created. This script will ensure that the same format is used for all custom rules created.

Ask the user what the custom rule should do. If the user doesn't provide enough context in the prompt, ask for clarification or follow up. Do not make assumptions about how a custom rule is meant to behave or what guideline it's supposed to enforce. After gathering the needed context, ask the user which package(s) the rule should be applied to.

Once you have all the needed context, ask the user to provide at least one valid and one invalid example demonstrating when the custom rule is being followed or not. This will help you to write tests for the custom rule in a future step. Similar to step 2, if the provided examples do not give you enough context to understand the difference between a valid versus invalid example, ask the user for clarification. Do not proceed until the user has provided at least one valid and one invalid example and you have enough needed context to understand a valid and invalid example.

Based on the user's provided context, fill in the rule file generated under the src/rules directory. The main section you should fill out is the create() function key that's in the rule object. You can refer to packages/eslint-plugin-cds/src/rules/custom-rule.ts for more documentation on how custom rules are formatted and information to enter. Custom rules should use the AST visitor methods to determine when rules have been violated and should report warnings in the linter. Custom rules should also verify the packages being imported before performing AST parsing. If a file doesn't import a package specified in step 2, do not report an error in the custom rule. Most custom rules already do this. As an example, you can refer to the ImportDeclaration() function in the no-v7-imports rule found here: packages/eslint-plugin-cds/src/rules/no-v7-imports.ts. The rule only reports an error when one of the CDS_PACKAGES packages is used,

Using the context from step 3, write in valid and invalid test cases for the test file generated from the scaffold-new-rule.mjs script. The valid and invalid examples provided in step 3 should be included. Based off those examples and the rule criteria provided in step 2, you can add additional valid or invalid examples.

Directory placement

Custom rules should always be placed in the packages/eslint-plugin-cds/src/rules directory. Tests for each custom rule should be placed in the packages/eslint-plugin-cds/tests directory.

name	eslint-plugin-custom-rule
description	USE THIS when asked to create a new eslint plugin rule for the eslint-plugin-cds package