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
최근 소스 활동
2026년 10월 16일 11:17
감지된 SKILL.md 언어
영어
스타
1
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 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에서 보기