set-up-dev-toolchain
Skill7 starsChanged 15 days agoMITView on GitHub
Use when setting up or auditing a repo's developer toolchain — mise pins and tasks or just, shared task verbs, lefthook git hooks, editorconfig, GitHub CLI conventions, and a doctor task that verifies everything.
- Pipes a download into a shell
- Installs packages
- Commits and pushes
1 other project uses a version of this.
Adopted by
Most recently taken up by
- VelimirMueller/ai-development-skillsword for word, first seen Oct 25, 2026
Other versions1 project uses a version of this.
Word for word · 1
- VelimirMueller/ai-development-skills★ 7100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository156 other files it gives its agents.
- skills/swift/swiftui-design-principles/AGENTS.mdAGENTS.md
- skills/swift/ios-code-audit/CLAUDE.mdCLAUDE.md
- skills/swift/swift-focusengine-pro/llms.txtllms.txt
- build-llm-seamSkill
- build-mcp-serverSkill
- build-rag-pipelineSkill
- secure-llm-featuresSkill
- set-up-llm-evalsSkill
- build-nextjs-backendSkill
- build-supabase-edge-functionSkill
- configure-backend-testsSkill
- design-http-apiSkill
- harden-backendSkill
- scaffold-fastapi-serviceSkill
- scaffold-go-serviceSkill
- scaffold-hono-serviceSkill
- secure-supabase-rlsSkill
- set-up-backend-authSkill
- set-up-background-jobsSkill
- set-up-databaseSkill
- set-up-nextjs-supabase-authSkill
- set-up-observabilitySkill
- set-up-supabaseSkill
- build-cliSkill
- release-cliSkill
- audit-securitySkill
- audit-toolchainSkill
- extend-skillsetSkill
- promote-releaseSkill
- set-up-stack-profileSkill
- write-commit-messagesSkill
- write-pull-requestsSkill
- analyze-complexitySkill
- apply-algorithmsSkill
- apply-design-patternsSkill
- apply-design-principlesSkill
- apply-solidSkill
- choose-data-structureSkill
- debug-systematicallySkill
- enforce-dependency-ruleSkill
- refactor-safelySkill
- slice-and-estimateSkill
- write-clean-testsSkill
- write-readable-codeSkill
- clean-frontend-scaffoldingSkill
- configure-accessibilitySkill
- configure-analyticsSkill
- configure-ciSkill
- configure-error-trackingSkill
- configure-lintingSkill
- configure-test-stackSkill
- configure-typescriptSkill
- create-moduleSkill
- optimize-performanceSkill
- scaffold-frontend-projectSkill
- set-up-authSkill
- set-up-design-systemSkill
- set-up-document-headSkill
- set-up-error-boundariesSkill
- set-up-feature-flagsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 47
Run the live check first (mise --version, npm view pnpm version, gh api repos/golangci/golangci-lint/releases/latest), then install the …
- Very specific: line 117
Commit mise.toml and mise.lock.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Set up dev toolchain
One runner, one lockfile, one set of verbs (setup dev test lint fmt check build plus typecheck and doctor), the same on every repo. Hooks call tools through the runner, never a bare binary. CI runs the same check a developer runs.
Rules with reasons and tested config: toolchain-patterns.md. Versions: stack-versions.md (verify live first, per version-protocol). Stack profile: stack-profile.md.
1. Audit current state
Change nothing yet. Read the stack profile, then list what exists.
cat .claude/stack-profile.md 2>/dev/null | sed -n '1,40p'
ls mise.toml .mise.toml .tool-versions .nvmrc justfile Makefile lefthook.yml .husky .pre-commit-config.yaml .editorconfig 2>/dev/null
grep -nE '"(scripts|prepare)"' package.json 2>/dev/nullRecord: language(s), current task runner, git hooks, editorconfig, CI. Note what is missing and what already exists.
2. Decide what to do
- Nothing present → full scaffold (steps 3-7).
- Some pieces present, gaps remain → delta. Name each gap you will close.
- Runner, hooks, editorconfig and doctor already match this file → say "already in place" and stop.
Respect existing tools. Never replace husky, make or just with something else unasked; only fill gaps. An existing runner wins over the default.
3. Detect the track
Pick from languages in the profile or from the files on disk:
| Track | Evidence | Package manager |
| TypeScript / Node | package.json + pnpm-lock.yaml | pnpm |
| Go | go.mod | go |
| Python | pyproject.toml + uv.lock | uv |
| Rust | Cargo.toml | cargo |
A polyglot repo pins all of its tracks in one mise.toml.
4. Install only what is missing
Run the live check first (mise --version, npm view pnpm version, gh api repos/golangci/golangci-lint/releases/latest), then install the vendor installer or brew, then pin in the project:
curl https://mise.run | sh # or: brew install mise
mise use node@24 pnpm@12 lefthook@2 actionlint@1 zizmor@1.30.1 # TypeScript
mise use go golangci-lint lefthook@2 actionlint@1 zizmor@1.30.1 # Go
mise use uv ruff lefthook@2 actionlint@1 zizmor@1.30.1 # Python
mise use rust lefthook@2 actionlint@1 zizmor@1.30.1 # RustInstall only what step 1 found missing. mise use writes [tools] into mise.toml.
5. Generate
mise.toml — [tools] (step 4), [settings] lockfile = true, min_version, and the tasks. The same verbs in every repo: setup dev test lint fmt check build typecheck doctor. The canonical file is in toolchain-patterns.md. Per-language bodies:
| Verb | TypeScript | Go | Python | Rust |
| lint | biome check . | golangci-lint run ./... | ruff check | cargo clippy --all-targets -- -D warnings |
| fmt | biome format --write . | golangci-lint fmt | ruff format | cargo fmt |
| typecheck | tsc --noEmit | go build ./... | — | cargo check |
| test | vitest run | go test ./... | uv run pytest | cargo test |
| build | tsdown | go build ./... | uv build | cargo build --release |
tsc --noEmit assumes a single tsconfig (the CLI track, built by tsdown). A Vite SPA repo has a solution-style tsconfig (files: [] plus references), where tsc --noEmit checks zero files — use tsc -b there (see the frontend configure-typescript skill).
setup installs tools, deps and hooks (idempotent). dev runs the entry (node src/cli.ts, go run ./cmd/<name>, uv run <pkg>, cargo run). check runs lint + typecheck + test. doctor is one shared script, mise-tasks/doctor. build declares sources/outputs so mise can skip it.
Task runner — honour task_runner from the profile. Unset → package scripts for a pure JS/TS repo, mise tasks for a polyglot one (default per stack-profile.md): mise is already required to pin runtimes, so one tool and one file; tasks pin their own tools and skip work by sources/outputs. just when the profile says so (better for argument-heavy recipes and plain shell, but a separate install; the tested justfile is in toolchain-patterns.md). package-scripts: keep the scripts, mise only pins runtimes. make: keep it. See the table in toolchain-patterns.md.
lefthook.yml — pre-commit parallel with glob + {staged_files}, stage_fixed: true for formatters, pre-push runs mise run check. Every hook command calls tools through mise x -- (git hooks do not run in an activated shell; a bare biome fails with "command not found"). Canonical file in toolchain-patterns.md.
.editorconfig:
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 2
[*.go]
indent_style = tab
[Makefile]
indent_style = tab
[*.py]
indent_size = 4
[*.rs]
indent_size = 4GitHub CLI conventions — keep to these, do not invent flags: gh auth status, gh pr create --fill, gh pr checks --watch, gh run watch. Branch names: type/short-slug (e.g. feat/add-doctor).
CI — .github/workflows/ci.yml using jdx/mise-action, checkout with persist-credentials: false, permissions: contents: read, running mise run check. The tested file is in toolchain-patterns.md.
6. Wire it
mise trust
mise install
mise lock --platform linux-x64,macos-arm64Commit mise.toml and mise.lock. Put lefthook install inside the setup task, not a manual step. README "Getting started" is one line: mise run setup.
7. Verify
mise run doctor # every line starts "ok" (gh may warn)
mise run check # greenThen prove the guards work: stage a deliberately bad file (a lint error) and confirm the commit is blocked; run mise run setup a second time and confirm it changes nothing.
References
- toolchain-patterns.md: canonical
mise.toml,lefthook.yml,mise-tasks/doctor, justfile,ci.yml; pitfalls and their reasons. - ../_shared/stack-versions.md: verified versions.
- ../../core/_shared/stack-profile.md: the profile keys this skill reads.
- ../build-cli/SKILL.md, ../release-cli/SKILL.md: the skills that consume these verbs.
- ../../core/_shared/engineering-principles.md, ../../core/_shared/security-baseline.md: seams and secrets.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

