docs(skills): prevent recurring lint migration review cleanup

[Yuchao Yan (msyyc)]

Summary

Update five lint development/promotion skills to prevent the recurring review feedback in the supplied 58-comment retrospective across 17 migration PRs. Target feature/lintdiff-migration-new, the branch current when this work was requested.

Review theme	Comments	Prevention
Redundant internal change entries	28	Inspect and reuse task-owned unreleased feature/fix coverage before creating entries; preserve genuinely needed coverage for other packages.
Multiple behavior suites for one public rule	14	Extend the canonical suite, found by its imported rule object even when its historical filename differs from the public name.
Repetitive test headings	13	Use file-scope cases or meaningful scenario groups, preserving scoped setup rather than repeating the rule/filename.
Private fixture APIs	2	Use supported public imports/decorators; redesign or remove artificial private-only cases without changing production scope.
Bespoke Markdown parser	1	Enforce the existing prohibition without relocating the parser or losing distinct semantic/example evidence.

These are five recurring lessons, not 58 independent design judgments: 55 comments explicitly disclose Copilot generation, and three have no automation disclosure. Original report IDs 37-39 on #5591 and #5654 remain outside the selection.

Changes

• typespec-lint-validate: define canonical suite ownership and meaningful grouping; clarify genuine public-entry/package tests versus duplicate rule execution under import guards; require public fixture APIs.
• typespec-lint-implement: centralize unreleased change-entry reconciliation and include the shared test policies in implementation/final review.
• lintdiff-rule-promote: replace unconditional creation of a test file/change entry with discovery and reuse; reconcile acceptance-evidence and review instructions with the shared policies.
• develop-lintdiff-rule: reference the shared policies during test planning and independent review; preserve migration/corpus requirements.
• create-linter-rule: apply the same guidance to scaffold cleanup, existing-rule extensions, public fixtures, and changelog coverage.

Evidence and boundaries

• Changelog guidance, report 22
• Private APIs, report 23
• One behavior suite per rule, report 36
• Historical canonical filename, report 48
• Isolation-suite duplication, report 53
• Meaningful scenario grouping, report 55
• Markdown parser removal, report 33

Keep independent utility tests, genuine package/registration evidence, rule-owned diagnostic regressions, and actual published-example validation. Keep separate rulesets-package internal coverage when needed; do not delete all internal entries. Existing production semantics, audience/enablement, source immutability, parity evidence, and required validation remain unchanged.

Skills only: no generator, rule implementation/test, package, dependency, release entry, or CI changes. The scaffolder's redundant wrapper is explicitly handled by cleanup guidance; changing the generator is a separate follow-up.

Validation

• Scoped Prettier write/check on the five changed Markdown files, using the repository's scalar formatting settings without optional plugins because the configured TypeSpec plugin has no built output. No dependencies or submodules were initialized for this documentation update.
• Relative Markdown file/heading reference checks and full five-file diff review.
• git diff --check and explicit staged-file scope verification.

No package builds, corpus runs, docs regeneration, or repository-wide formatting/source linting are needed for this Markdown-only change.