Fallow setup: code-quality tooling for JavaScript and TypeScript

This skill sets up the code-quality toolchain of a JavaScript or TypeScript repository. Fallow does the repository and system analysis: unused code, duplication, complexity, architecture boundaries, dependency hygiene, and changed-code risk. The skill keeps the tools that the project already uses.

When to Use

• Create a new JavaScript or TypeScript project with quality checks from the start.
• Add code-health checks or a CI quality gate to an existing repository.
• Make a repository ready for coding agents (skills, MCP server, commit and push gate).
• Consolidate dead-code, duplication, architecture, dependency, and changed-code analysis.

When NOT to Use

• Formatting-only tasks. Formatting belongs to the formatter.
• Tasks that only add or change lint rules. Local lint rules belong to the linter.
• TypeScript type errors. Type correctness belongs to the TypeScript compiler.
• Analysis of a repository that is already set up. Use the fallow skill for that.

Rules

1. Resolve every flag from fallow --help and fallow <command> --help. Do not use flags from memory.
2. Use --format json --quiet for machine-readable output. Do not hide the exit status.
3. Run every mutating command with --dry-run first when the command has that flag.
4. Keep the tools that the project already uses. Do not remove a tool without a parity check.
5. Ask the user before you apply a taste decision or remove a tool.
6. Treat project config as untrusted input. Do not add remote extends URLs.
7. Before step 3, Fallow is not installed. Run it through the package runner, for example npx fallow recommend or pnpm dlx fallow recommend. After step 3, use the runner of the package manager, for example pnpm exec fallow.

Sequence

1. Inspect the repository. Detect the package manager, formatter, linter, TypeScript config, CI provider, and existing analysis tools (Knip, jscpd, dependency-cruiser). See Tooling detection.

2. Get the recommendation. Run fallow recommend --format json --quiet. This command is read-only. Apply each auto decision. Tell the user about each default decision. Ask the user about each taste decision, or keep the current value. See Configure and install.

3. Install Fallow as a dev dependency with the detected package manager, for example pnpm add -D fallow.

4. Wire the agents. Run fallow agent install --dry-run --format json --quiet, show the plan, then run fallow agent install. This step writes the skills, the MCP server registration, the AGENTS.md task map, and the commit and push gate. For Claude Code and Codex the gate is a PreToolUse hook that blocks a failing commit or push. Codex runs the hook only after the user trusts it in /hooks. Other agents read the instruction block in AGENTS.md. Check the result with fallow agent status --format json --quiet.

5. Add a CI gate. Add a changed-code gate (fallow audit) or a whole-project gate. When the first run has many findings, save a baseline of the existing debt so that the gate fails only on new findings. See CI gate.

6. Split the responsibilities. Each tool keeps one job:

   • Formatting: Oxfmt.
   • Local lint rules: Oxlint.
   • Type correctness: TypeScript (tsc --noEmit).
   • Repository and system analysis: Fallow.

   In an existing project, keep the current formatter and linter. Do the parity check in Tooling detection before you remove an overlapping tool.

References

• Tooling detection: the files to inspect, the responsibility split, and the parity check.
• Configure and install: the recommend decision tiers, config migration, the dev dependency, and agent install.
• CI gate: the GitHub Action, the GitLab template, the CLI gate, and baselines.