Fallow Setup

---
name: fallow-setup
description: Set up or modernize code-quality tooling for JavaScript and TypeScript projects. Use when creating a project, adding code-health or CI quality checks, making a repository agent-ready, or consolidating dead-code, duplication, architecture, dependency, and changed-code analysis. Do not use for formatting-only, lint-rule-only, or TypeScript type-error tasks. Do not use to run an analysis of a project that is already set up; use the fallow skill for that.
license: MIT
---

# 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](references/tooling-detection.md).
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](references/configure-and-install.md).
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](references/ci-gate.md).
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](references/tooling-detection.md#parity-check) before you remove an overlapping tool.

## References
- [Tooling detection](references/tooling-detection.md): the files to inspect, the responsibility split, and the parity check.
- [Configure and install](references/configure-and-install.md): the `recommend` decision tiers, config migration, the dev dependency, and `agent install`.
- [CI gate](references/ci-gate.md): the GitHub Action, the GitLab template, the CLI gate, and baselines.