Menu
A deliberately broken fixture used by example/README.md to show what each rule's error output looks like.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Guidelines and format for writing pull request descriptions in this repository. Use this skill whenever the user asks you to draft a pull request description, submit a PR, or update a PR description.
Validates an in-progress PR or feature branch of dart_skills_lint against known downstream ecosystem consumers. Use when assessing breaking changes across external repositories during PR evaluation, testing migrations against the changelog, or determining necessary backwards compatibility shims.
How to integrate, update, and configure the dart_skills_lint validation tool within a repository. Make sure to use this skill whenever the user asks to update dart_skills_lint, configure skills validation tests, fix skills linter dependency drifts, verify repository state before editing, optimize lint rules execution, or draft pull request submission commands.
Use this skill when you need to validate AI agent skills with dart_skills_lint — running the linter, interpreting failures, fixing violations, and authoring custom rules.
Reference fixture for dart_skills_lint. Demonstrates a SKILL.md that passes every default rule: hyphen-lowercase name matching the parent directory, a properly sized description, and no other frontmatter fields that would trigger the disallowed-field check.
Reviews the specified code against the canonical API Design guidelines. Use this skill when the user asks for an API review or to check code against API design principles.
| name | NotInvalid |
| description | A deliberately broken fixture used by example/README.md to show what each rule's error output looks like. |
| secret_field | not allowed by the spec |
| metadata | {"internal":true} |
This skill deliberately trips three rules so the CLI's diagnostic output can be inspected end-to-end. One fires under defaults; two need to be enabled to surface as errors (the spec ships them at lower severities).
invalid-skill-name (error by default) — the frontmatter name:
is NotInvalid, which is not lowercase and does not match the
parent directory invalid.disallowed-field (disabled by default; enable via
--disallowed-field or YAML config) — secret_field: is not in
the spec's allowed field list.check-absolute-paths (warning by default; escalate to error via
--check-absolute-paths or YAML config) — the link below uses an
absolute filesystem path, which is not portable across machines.The broken link: absolute link
Run it with default rules:
dart run dart_skills_lint --skill ./example/skills/invalid
…and again with every rule turned up to error:
dart run dart_skills_lint --skill ./example/skills/invalid \
--disallowed-field --check-absolute-paths
Expected: non-zero exit, error messages naming each rule that is enabled.