Skip to main content

tsk

Enable, configure, and write tsk Go linters. Use when the user asks to enforce a convention or architectural constraint, to fix a kind of issue across the codebase, or to change .tsk/config.toml or a .tsk/*.ts linter.

معلومات المصدر

المستودع
block/spectre
آخر نشاط في المصدر
١٦ أكتوبر ٢٠٢٦ في ١١:١٧
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
tsk
description
Enable, configure, and write tsk Go linters. Use when the user asks to enforce a convention or architectural constraint, to fix a kind of issue across the codebase, or to change .tsk/config.toml or a .tsk/*.ts linter.
# tsk `tsk` runs Go linters written in TypeScript. The repository's config is `.tsk/config.toml`, and its own linters are `.tsk/<name>.ts`. The full reference is the README at https://github.com/alecthomas/tsk. ## Commands - `tsk [packages...]` lints `./...`, or the given packages. `--fix` applies suggested fixes. `--enable` and `--disable` override the config for one run. - `tsk list` lists every linter, whether it is enabled, and its summary. `tsk list --json` adds each linter's full documentation. - `tsk config <linter>` prints a linter's options, documented and set to their defaults. - `tsk check` type-checks the scripts and validates the config. - `tsk test [--enable <linter>]` runs linters against their test data. - `tsk editor` writes TypeScript declarations to `.tsk/types/` for editors. ## Enable an existing linter 1. Find candidates with `tsk list --json`, and read their documentation. 2. Measure the impact with `tsk --enable <linter>` before changing the config. 3. Add the linter to `enable` in `.tsk/config.toml`. If the config does not set `disable-all`, a linter on by default needs only removing from `disable`. 4. Set options in a table named after the linter, using `tsk config <linter>` for the names and defaults. Option names are kebab-case. 5. Fix the existing findings, or keep intentional ones with `//nolint:<linter> // <reason>`. Use `--fix` where the linter offers fixes. Narrow a linter with an `[[exclude]]` rule rather than disabling it. A rule names `linters` and any of `path`, `path-except`, `text`, and `source`, each a regular expression. `skip-tests` drops a linter's findings in `_test.go` files. ## Write a linter Write one when no existing linter or configuration enforces the rule. 1. Put the linter in `.tsk/<name>.ts`. It default-exports `defineAnalyzer({ name, doc, requires, run(pass) })` from `"tsk"`, named as the file is. `run` mirrors a Go `analysis.Analyzer`: import Go packages such as `"go/ast"` and `"go/types"` by path, with lowerCamelCase names, and report with `pass.report({ pos, message })`. 2. Traverse syntax with the `inspect` pass from `"tsk/passes"`, as in `pass.resultOf(inspect).root().preorder(ast.CallExpr)`, so Go filters the nodes. 3. Add test data under `.tsk/testdata/<name>/`, as a module or a GOPATH tree under `src/`. Mark each expected finding with a ``// want `regexp` `` comment, and include code the linter must accept. 4. Run `tsk check`, then `tsk test --enable <name>`, until both pass. 5. Run `tsk` and fix existing violations in the same change, or keep intentional ones with `//nolint:<name> // <reason>`. 6. Note in the repository's agent instructions that the linter enforces the rule. Keep a linter precise: a false positive costs more than a missed finding. Report a message that says what to do instead. Offer a suggested fix only when it is unambiguous. Run `tsk editor` for declarations of the full script API, which the README describes under "Writing linters".
عرض على GitHub