القائمة
Use this skill when working on GML ESLint language support, lint rules, diagnostics, single-file autofixes, rule tests, parser services, or formatter/lint/refactor boundaries.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create and modify GameMaker resources through structured project tooling. Use when working with objects, events, rooms, scripts, instances, project metadata, or resource relationships.
Use this skill to remove compatibility shims, legacy behavior wrappers, and import/export pass-through files by migrating call sites to direct ownership APIs.
Organize GameMaker resources, manage layout and naming, structure project notes, and establish reusable architectural systems. Use when organizing resources, naming systems, or structuring GameMaker projects.
Use Playwright to inspect, navigate, and play a running browser-based GameMaker game. Use when the user wants the agent to verify gameplay, menus, input, screenshots, browser behavior, or the exported HTML5 game loop. This skill is for operating the game through the browser like a player, not for editing code.
Understand and work with GameMaker Language (GML), including its syntax differences from JavaScript, GML-specific language constructs, data accessors, keywords, constants, and formatting conventions.
Apply adversarial verification during any meaningful code change before the approach hardens. Use for medium or larger changes where regressions, hidden coupling, ownership mistakes, or invalid assumptions are plausible. Skip only for trivial mechanical edits.
| name | lint-rules-gml |
| description | Use this skill when working on GML ESLint language support, lint rules, diagnostics, single-file autofixes, rule tests, parser services, or formatter/lint/refactor boundaries. |
Use this skill when an agent is changing the lint workspace, ESLint language wiring, or GML lint rules.
The lint target state is a precise, single-file analysis and autofix layer:
Lint should help agents and developers improve GameMaker code without hiding risk or crossing workspace boundaries.
Lint owns:
Lint does not own:
.yy or .yyp metadata updatesIf a rule needs global correctness, emit a diagnostic and point to a refactor workflow instead of applying a risky autofix.
Before writing or changing a rule:
Implementation should:
Good GML lint rules are:
Use established libraries when they reduce risk, but avoid pulling in dependencies for simple syntax checks that the existing parser, ESLint APIs, or core helpers already cover.
Autofixes must be safe within the local file.
Examples that belong elsewhere:
globalvar migration belongs in refactorRules should consume language-specific information through parser services rather than reaching into parser internals.
Add or update tests for:
Do not modify protected .gml golden fixtures unless explicitly permitted.
Before finishing lint work, verify:
require(), any, or non-null assertions to avoid proper typing.When changing existing lint rules, first check whether the behavior duplicates, recreates, or partially overlaps a rule from another lint namespace.
The target state is one canonical owner for each lint behavior. If a custom GML rule is an exact or near-exact recreation of a Feather-owned diagnostic, migrate the complete and safest behavior into the Feather rule, then remove the duplicate GML rule entirely. Do not leave aliases, compatibility shims, duplicate docs, duplicate config examples, or stale catalog entries unless explicitly required by a migration plan.
When consolidating ownership:
If a GML rule and a Feather rule only partially overlap, do not blindly merge them. Decide which rule owns the rewrite capability and which rule should remain diagnostic-only. Remaining overlapping rules may both report diagnostics, but only the canonical owner should provide fixes.
Autofix ownership must be explicit.
A rule may own a fix only when:
When behavior moves between rules, the complete safe-fix behavior should move with it. Do not downgrade a mature GML implementation just because the destination rule currently has weaker logic. Instead, upgrade the canonical rule and retire the duplicate.
If the safer outcome is report-only behavior, remove fixable metadata and strip runtime fixes or suggestions consistently. Rule metadata, generated catalogs, and actual runtime behavior must agree.
Maintain an explicit internal conflict registry for known overlapping rule behavior.
The registry should make conflicts visible and enforce the target state centrally. Conflicting non-owner rules should continue reporting useful diagnostics, but they should not expose autofixes or suggestions. This prevents duplicate edits, overlapping fixes, autofix oscillation, and misleading catalog metadata.
Do not solve conflicts ad hoc inside individual rules when a shared conflict mechanism is available.
Use namespace ownership as an API contract.
GML-specific rules should own behavior that is genuinely specific to the custom GML lint layer. Feather rules should own behavior that corresponds to Feather diagnostics or metadata categories. Formatter-only behavior belongs in format. Project-aware behavior belongs in refactor. Semantic indexing belongs in semantic services or refactor tooling.
When a behavior could fit multiple places, choose the owner that best matches the diagnostic’s public meaning and long-term catalog surface, not whichever implementation currently has the most code.
When retiring a duplicate rule, removal must be complete.
Check and update:
Do not leave stale references to removed rule IDs. Do not preserve removed IDs as aliases unless the migration explicitly calls for backwards compatibility.
When moving behavior from one rule to another, move the tests with it.
Consolidated tests should prove:
Prefer renaming and consolidating test suites over copying tests into parallel namespaces.
Before modifying an existing lint rule, the agent should:
The preferred end state is fewer duplicate rules, clearer public ownership, safer fixes, and no loss of valid autofix capability.