lint
Run linters on recently changed files with the correct tools for each language. Use when asked to "lint", "check style", or "run linters".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Run linters on recently changed files with the correct tools for each language. Use when asked to "lint", "check style", or "run linters".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Apply Fleet's house article format and article-specific voice to Fleet ARTICLES — blog pieces with meta category "articles" or "comparison" (thought-leadership, how-to, and comparison pieces). Use when writing a NEW article or editing, refreshing, or tightening an EXISTING one, even if the user doesn't say "use the format." Governs structure and article-specific voice; pair with content-style for word-level voice. Do NOT use for guides, case studies, or announcements — those are separate content types with their own skills.
Create GitHub issues in fleetdm/confidential for Aikido pen test findings. Use when asked to "create aikido tickets", "aikido ticket", or "create pen test tickets".
Write, edit, and review any public-facing or customer/prospect-facing Fleet content so it follows Fleet's writing, brand, voice, and style guidelines. Use this whenever you create or change the words in website copy (fleetdm.com), handbook pages, docs, guides, tutorials, articles, blog posts, announcements, release notes, product UI text and microcopy, GitHub issues about content, or marketing and sales enablement material, even if the user never says "style guide." Trigger on edits under website/, handbook/, docs/, articles/, and on requests like "write a blog post," "draft an announcement," "review this guide for style," "make this sound like Fleet," "tighten this up," or "clean up this copy." This skill is for authoring and editing prose for voice, brand, and style. It does not apply to writing code, tests, scripts, commit messages, or internal team chat, even when those happen to mention articles, announcements, blog posts, or UI strings.
Move reference doc updates from one release docs branch to another (e.g., 4.89 → 4.90) when a feature is pushed to a later release. Handles three PR states — open (retarget), closed-without-merge (apply-only), merged (revert + apply).
Break down a Fleet GitHub story issue into implementable sub-issues with technical specs. Use when asked to "spec", "break down", or "analyze" a story or issue.
Authoring guide for the Fleet command palette. Use when adding or editing items in frontend/components/CommandPalette/groups/, when editing frontend/router/paths.ts or frontend/router/index.tsx, or when adding a new top-level page, global create action, MDM connector / singleton config, automation hook, or picker action that needs a palette entry.
| name | lint |
| description | Run linters on recently changed files with the correct tools for each language. Use when asked to "lint", "check style", or "run linters". |
| allowed-tools | Bash(make lint*), Bash(golangci-lint *), Bash(go vet*), Bash(yarn lint*), Bash(yarn --cwd *), Bash(npx eslint*), Bash(npx prettier*), Bash(git diff*), Bash(git status*), Read, Grep, Glob |
| effort | low |
Run the appropriate linters on files changed in the current branch. Use the project's own make targets when available.
Find recently changed files (last commit, staged, and unstaged):
git diff --name-only HEAD~1 # Last commit
git diff --name-only --cached # Staged but not committed
git diff --name-only # Unstaged changes
Combine all three and deduplicate to get the full set.
Go files (*.go):
Use the project's incremental linter — it only checks changes since branching from main:
make lint-go-incremental
This uses .golangci-incremental.yml with --new-from-merge-base=origin/main. It's faster and more relevant than linting entire packages.
For a full lint (e.g., before committing), use:
make lint-go
TypeScript/JavaScript files (*.ts, *.tsx, *.js, *.jsx):
npx eslint frontend/path/to/changed/files
npx prettier --check frontend/path/to/changed/files
Or use the make target:
make lint-js
SCSS files (*.scss):
npx prettier --check frontend/path/to/changed/files.scss
For each linter run, show:
If everything passes, confirm which linters ran and on which files.
If an argument is provided, use it to filter: $ARGUMENTS
go — only Go linters (uses make lint-go-incremental)full — full Go lint (uses make lint-go)js or frontend — only frontend linters (uses make lint-js)