// Use when a user says "work on ty", "fix this ty issue", "debug ty", "update this ty PR", or asks about ty type checker changes, issues, branches, failing tests, or PRs in the Ruff repository.
Use when a user says "minimize this ty ecosystem change", "reproduce this ecosystem result", "investigate a primer difference", "investigate a mypy_primer difference", "investigate a mypy-primer difference", or asks to reproduce, investigate, or minimize behavior changes in ty ecosystem/primer/mypy_primer/mypy-primer projects.
Use when a user says "summarise ecosystem results", "summarize this ty ecosystem report", "what changed in this ecosystem run?", or asks to summarise or summarize ty ecosystem results for a Ruff PR from a PR number, PR URL, GitHub ecosystem-results comment, or detailed HTML report.
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.
| name | working-on-ty |
| description | Use when a user says "work on ty", "fix this ty issue", "debug ty", "update this ty PR", or asks about ty type checker changes, issues, branches, failing tests, or PRs in the Ruff repository. |
When the task matches a more specific ty workflow, also read and follow that skill from the repository root:
.agents/skills/adding-ty-diagnostics/SKILL.md..agents/skills/summarise-ecosystem-results/SKILL.md..agents/skills/minimizing-ty-ecosystem-changes/SKILL.md.When running ty against a temporary Python reproduction file, create it outside the Ruff checkout (for example, under /tmp). A file inside the checkout discovers Ruff's root pyproject.toml, whose requires-python = ">=3.7" causes ty to infer Python 3.7 as the default Python version.
When working on ty, PR titles should start with [ty]. Add the ty GitHub label if you have permission to do so;
if you don't, however, automation should add it anyway, so there's no need to worry about it. Similarly, add the server
label if your change only affects the LSP server and you have permission to add that label.
db parameterFor free functions and associated functions without a self parameter, db should be the first parameter. For methods with a self parameter, db should come immediately after self.
Adding #[salsa::tracked] to a function or method means that the Salsa framework will cache the function/method.
This can sometimes be done for performance reasons, and can also be done to ensure incremental computation in an
IDE context.
Methods that access .node() should usually be #[salsa::tracked], or ty's incrementality will suffer:
we don't want to accidentally introduce a dependency on module a's AST in a Salsa query that would be
called when type-checking module b. Prefer higher-level semantic APIs over raw AST access where possible,
but ask for guidance from the user if this would require significant refactoring.
For Salsa-cached values, avoid retaining excess collection capacity. Prefer boxed slices; otherwise shrink collections that may have spare capacity before returning them. In particular, inspect HashMap and HashSet values constructed via extend, collect, explicit reservation, or removal, since those operations can leave capacity that insert-only construction does not.
Salsa caching can occur due to a function/method having #[salsa::tracked] on it, or due to a struct with #[salsa::interned] being constructed.