Use when a user says "add a ty diagnostic", "write this new ty diagnostic", "change a ty error message", "review ty diagnostics", or asks to add, update, or review ty checks, diagnostic messages, subdiagnostics, or concise output behavior.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Use this skill when adding or changing a ty diagnostic, especially as part of a new ty check.
Keep error messages concise. Think about how the diagnostic will look on a narrow terminal screen.
Put extra detail in subdiagnostics or secondary annotations when that helps, but make sure the primary diagnostic is understandable on its own.
Always check that the diagnostic still makes sense when the user passes --output-format=concise.
If the error code is entirely new or if you have changed the documentation for the error code,
you will need to run cargo dev generate-all after making your changes, to update the generated schema for ty
and the generated .md documentation files.
Diagnostics should usually be tested using mdtests. If you are changing behaviour for an existing diagnostic,
you should usually add your tests to a pre-existing .md file; otherwise, it may be appropriate to add a new
.md file for your tests. Snapshot tests are only usually necessary for diagnostics that use secondary annotations
or subdiagnostics. If you want to add a snapshot, inline # snapshot comments are preferred over the legacy
<!-- snapshot-annotations --> directive.
When using the declare_lint! macro, the status field should be set to LintStatus::stable(<next version of ty>).
You should determine what the next version of ty will be by inspecting https://pypi.org/pypi/ty/json, finding what
the latest release of ty is, and incrementing the patch version by one. For example, if the latest release of ty is 0.5.3, the status should be LintStatus::stable("0.5.4").
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when adding A2UI rendering to any AG-UI-supported framework or custom AG-UI application, scaffolding an AG-UI app that should render A2UI, adapting an AG-UI integration to emit A2UI surfaces, or wiring the AG-UI A2UI middleware/toolkit with a compatible renderer.
The English summary is being prepared. Showing the original description.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
The English summary is being prepared. Showing the original description.
Evaluate an open source project's AGENTS.md and produce a corpus entry for the /agents-md directory. Use when adding a project to the directory, refreshing an existing entry, or running a batch of candidate repositories.
The English summary is being prepared. Showing the original description.
Execute Anarlog work immediately while recording issues, decisions, progress, and lessons in Linear. Use for Anarlog repository or Anarlog desktop, web, mobile, and API work, including related worktrees and ANLG issues. Explicit brainstorming stays discussion-first. Do not use for unrelated repositories or meeting-data queries.
The English summary is being prepared. Showing the original description.
Use only for reviewing completed Biome PRs, branches, commit ranges, diffs, or working trees against business logic and requirements. Excludes broad code-quality and process audits, triage, reproduction, and implementation.
The English summary is being prepared. Showing the original description.
Finds or publishes a pkg.pr.new canary release for a Storybook branch. Use when the user wants the canary package specifier for a branch or needs to trigger the canary workflow manually.
The English summary is being prepared. Showing the original description.