docs: sanitize skills

[vinpogo]

No description provided.

[Copilot]

Pull request overview

This PR “sanitizes” the Copilot skill docs by removing several detailed skill guides and heavily simplifying the remaining guidance, while also trimming the main Copilot instructions to reference fewer skills.

Changes:

• Delete multiple skills documents (type patterns, package structure, common workflows, debugging strategies, instruction validation).
• Simplify the remaining skills docs for testing decisions, state management, and common pitfalls.
• Remove the deleted-skill links from .github/copilot-instructions.md.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
.github/skills/type-patterns.md	Removes the type patterns skill document entirely.
.github/skills/package-structure.md	Removes the package structure skill document entirely.
.github/skills/instruction-validation.md	Removes the instruction validation skill document entirely.
.github/skills/debugging-strategies.md	Removes the debugging strategies skill document entirely.
.github/skills/common-workflows.md	Removes the common workflows skill document entirely.
.github/skills/testing-decisions.md	Replaces detailed decision trees/examples with shorter guidance and a style note.
.github/skills/state-management.md	Replaces detailed patterns/examples with brief high-level guidance.
.github/skills/common-pitfalls.md	Trims the pitfalls doc down to a short table and tweaks commands.
.github/copilot-instructions.md	Removes links/sections that referenced the deleted skills content.

Comments suppressed due to low confidence (4)

.github/skills/testing-decisions.md:27

• This guidance is incorrect for this repo: there are existing test files using Vitest hooks like beforeEach() to reset module-level singleton state (e.g., packages/vuebugger/src/registry.unit.test.ts and packages/vuebugger/src/devtools.unit.test.ts). Instead of “never vitest hooks”, document when hooks are acceptable (singleton/global reset) vs when explicit per-test setup/teardown functions are preferred.

### Always use explicit functions, never vitest hooks

Vitest hooks make it harder to read tests. Instead, extract the hooks content into functions which are called within the tests.

.github/skills/state-management.md:6

• This section has multiple grammar/clarity issues (“usecase”, “shall”, “package wide”, “have to be verified with the user”) and ends up being ambiguous guidance. Please rewrite with clear, standard phrasing (e.g., “use case”, “package-wide”), and clarify who “the user” is in this context (maintainer/reviewer?) and what “verified” means (design review? ADR?).

There is no specific solution for state management. Depending on the usecase an appropriate system shall be implemented.

When a package wide state is needed, encapsulate it into a module. If the state needs to be reusable, encapsulate it into a function. Any other state management solution have to be verified with the user.

.github/skills/common-pitfalls.md:8

• mise run oxlint assumes contributors are using mise, but the repo README/CONTRIBUTING don’t mention mise. Consider referencing the underlying command (pnpm oxlint) or documenting mise as an optional workflow so readers can actually follow this prevention step.

| Import cycles | Build failures | Check with `mise run oxlint` |

.github/skills/testing-decisions.md:3

• The opening sentence is grammatically incorrect/awkward and hard to parse. Consider rewriting to clearly separate the two file types (unit vs browser) and their suffixes (e.g., “There are two test types: …”).

There are 2 different test types available unit tests `.unit.test.ts`, and browser tests `.browser.test.ts`.