Use when writing or modifying tests with hTest (htest.dev) — JS-first or HTML-first. Use when a project has htest.dev in devDependencies or uses `npx htest` to run tests. Use when writing declarative tests as nested object literals, or reftest tables in HTML.
End-to-end integration tests for Grafana Lens agent tools against a live LGTM stack. Detects local code changes and runs targeted tests for affected tools.
Continuous test-driven development loop — after every code change, builds the project, starts the server, and runs Unit Tests, Integration Tests, and System Tests. Applies on top of microprofile-server skill. Use during development when you want full verification after each change. Triggers on "continuous testing", "continuous-testing", "test loop", "st-loop", or requests to run all tests after every change.
Run ArduPilot SITL autotests (integration/behavior tests). Use when the user asks to run autotests, vehicle tests, or specific test methods.
Use when completing retro feature work, after implementation and tests pass, before creating PRs. Keywords: scenario tests, clean install, retro documentation updates.
Review and improve Kensa BDD tests written in Kotlin. Use this skill whenever the user shares a Kensa test file, asks you to review or improve a Kensa test, or mentions Given-When-Then tests in a Kensa project. Kensa tests use the KensaTest interface with given()/whenever()/then() DSL, @RenderedValue, @ExpandableSentence, Fixtures, and produce HTML reports with sequence diagrams.
Execute unit-test alignment after large refactors or broad code changes. Trigger when the user explicitly uses the command "-- 对齐测试 --" or asks to align/fix tests after massive modifications. Run relevant unit tests, analyze failing test cases, update tests and/or implementation, and iterate until stable.
Write, extend, or debug PHPUnit application tests for this WordPress plugin. Use this skill whenever tests are involved — adding a test for a new feature, testing hook or filter behavior, testing WordPress data operations with factories, or when asked to "add a test", "write tests", "test this function", or "verify this behavior with a test". This skill is opinionated about the project's wp-env-based setup and supersedes any generic PHPUnit guidance. --- # Application Testing Tests run exclusively inside the `wp-env` test container. The bootstrap and PHPUnit config are pre-wired. Do not modify `tests/bootstrap.php` or `phpunit.xml.dist`. The plugin is already loaded when tests run — no manual require needed. For full reference including common patterns, plugin dependencies, and CI details, read `references/testing.mdx`. ## Running the test suite
Generate and run end-to-end tests with Playwright. Creates test journeys, runs tests, captures screenshots/videos/traces, and uploads artifacts.
Reviews existing test suites for coverage gaps, quality, and rigor; identifies weak or missing tests and guides fixes to reach a target coverage threshold. Use when asked to "review unit tests", "fix unit tests", "check test coverage", "audit tests", "improve test suite", or ensure coverage at end of an initiative or during maintenance. Do NOT use when the user asks to write tests from scratch for new, untested code.
Use when generating tests for backend code (Express routes, MongoDB models, Node services) - analyzes file type, detects test framework from package.json, generates comprehensive tests with setup/teardown and edge case coverage
Add support for a new AI coding tool to AgentSync's sync engine. USE WHEN adding a new tool, integrating a new AI assistant, or asked to support a new IDE/editor. --- # Add New Tool Support Add a new AI coding tool to AgentSync so `agentsync sync` distributes instructions to it. ## Steps 1. **Study an existing tool config** — Read `.ai/src/tools/claude.yaml` or `.ai/src/tools/cursor.yaml` for the pattern. 2. **Create the tool YAML** — Copy `.ai/src/tools/_TEMPLATE.yaml` to `.ai/src/tools/<tool>.yaml`. 3. **Configure targets** — Define where each content type goes: - `agents` → main instructions file - `rules` → rules directory or merged file - `skills` → skills directory (if supported) - `commands` → commands directory (if supported) - `subagents` → agents directory (if supported) - `settings` / `mcp` → tool-specific config files 4. **Handle format differences** — Check if the tool needs: - `.mdc` extension instead of `.md` (Cursor) - Frontmatter wrapping (`alwaysApply: true` for Cursor rules) - Inline skill/rule merging into agents file (`inline_into_agents: true`) - `00-context.md` pattern for AGENTS.md content in rules dir - TOML format for agents (Codex) 5. **Add sync logic** — If the tool needs custom transformation, add a handler in `lib/sync.sh` (look for the `sync_tool` function and existing tool-specific blocks). 6. **Add to `lib/templates/tools/`** — Create a default YAML config. 7. **Write tests** — Add assertions in: - `tests/sync.bats` — verify output files exist - `tests/sync_options.bats` — verify `--only`/`--skip` filtering - `tests/check.bats` — verify `agentsync check` detects drift 8. **Test on all platforms** — Run `bats tests/sync.bats` locally, verify CI passes. ## Gotchas - Every tool has quirks. Read the tool's docs for where it expects instruction files. - Some tools share output paths (e.g., Copilot uses `.github/`). Check for collisions with existing tools. - The custom YAML parser doesn't support arrays or multiline YAML blocks — keep too
skill-sample/ ├─ SKILL.md ⭐ Required: skill entry doc (purpose / usage / examples / deps) ├─ manifest.sample.json ⭐ Recommended: machine-readable metadata (index / validation / autofill) ├─ LICENSE.sample ⭐ Recommended: license & scope (open source / restriction / commercial) ├─ scripts/ │ └─ example-run.py ✅ Runnable example script for quick verification ├─ assets/ │ ├─ example-formatting-guide.md 🧩 Output conventions: layout / structure / style │ └─ example-template.tex 🧩 Templates: quickly generate standardized output └─ references/ 🧩 Knowledge base: methods / guides / best practices ├─ example-ref-structure.md 🧩 Structure reference ├─ example-ref-analysis.md 🧩 Analysis reference └─ example-ref-visuals.md 🧩 Visual reference
More Agent Skills specs Anthropic docs: https://agentskills.io/home
├─ ⭐ Required: YAML Frontmatter (must be at top) │ ├─ ⭐ name : unique skill name, follow naming convention │ └─ ⭐ description : include trigger keywords for matching │ ├─ ✅ Optional: Frontmatter extension fields │ ├─ ✅ license : license identifier │ ├─ ✅ compatibility : runtime constraints when needed │ ├─ ✅ metadata : key-value fields (author/version/source_url...) │ └─ 🧩 allowed-tools : tool whitelist (experimental) │ └─ ✅ Recommended: Markdown body (progressive disclosure) ├─ ✅ Overview / Purpose ├─ ✅ When to use ├─ ✅ Step-by-step ├─ ✅ Inputs / Outputs ├─ ✅ Examples ├─ 🧩 Files & References ├─ 🧩 Edge cases ├─ 🧩 Troubleshooting └─ 🧩 Safety notes
Skill files are scattered across GitHub and communities, difficult to search, and hard to evaluate. SkillWink organizes open-source skills into a searchable, filterable library you can directly download and use.
We provide keyword search, version updates, multi-metric ranking (downloads / likes / comments / updates), and open SKILL.md standards. You can also discuss usage and improvements on skill detail pages.
Quick Start:
Import/download skills (.zip/.skill), then place locally:
~/.claude/skills/ (Claude Code)
~/.codex/skills/ (Codex CLI)
One SKILL.md can be reused across tools.
Everything you need to know: what skills are, how they work, how to find/import them, and how to contribute.
A skill is a reusable capability package, usually including SKILL.md (purpose/IO/how-to) and optional scripts/templates/examples.
Think of it as a plugin playbook + resource bundle for AI assistants/toolchains.
Skills use progressive disclosure: load brief metadata first, load full docs only when needed, then execute by guidance.
This keeps agents lightweight while preserving enough context for complex tasks.
Use these three together:
Note: file size for all methods should be within 10MB.
Typical paths (may vary by local setup):
One SKILL.md can usually be reused across tools.
Yes. Most skills are standardized docs + assets, so they can be reused where format is supported.
Example: retrieval + writing + automation scripts as one workflow.
Some skills come from public GitHub repositories and some are uploaded by SkillWink creators. Always review code before installing and own your security decisions.
Most common reasons:
We try to avoid that. Use ranking + comments to surface better skills:
