Skip to content
All Skills

Ln 740 Quality Setup

Sets up linters, pre-commit hooks, and test infrastructure. Use when adding code quality tooling to a project.

Software Engineering|v1|Updated 7/14/2026|GitHub source
MCP get_skill({ skillId: "ln-740-quality-setup-09c97be8" })

Use this skill with your agent

Create a free account and connect via MCP

Get Started Free
> **Paths:** File paths (`references/`, `../ln-*`) are relative to this skill directory.

# ln-740-quality-setup

**Type:** L2 Domain Coordinator
**Category:** 7XX Project Bootstrap
**Parent:** ln-700-project-bootstrap

Coordinates code quality tooling configuration for the project.

---

## Purpose & Scope

**Does:**
- Detects project technology stack (TypeScript/React, .NET, Python)
- Checks for existing quality configurations
- Delegates to specialized workers for each quality aspect
- Verifies final configuration works correctly

**Does NOT:**
- Generate configuration files directly (workers do this)
- Modify source code
- Run in isolation (requires ln-720 structure first)

---

## When to Use

| Trigger | Action |
|---------|--------|
| After ln-720-structure-migrator completes | Automatic delegation from ln-700 |
| Manual quality setup needed | Invoke directly with project path |
| Existing project needs quality tools | Run with existing config detection |

---

## Workflow Overview

| Phase | Action | Output |
|-------|--------|--------|
| 1 | Stack Detection | Identified technologies |
| 2 | Existing Config Check | Skip/merge/replace decisions |
| 3 | Parallel Delegation | Worker invocations |
| 4 | Verification | Working quality pipeline |

---

## Phase 1: Stack Detection

Detect project technologies to determine which quality tools to configure.

**Detection Rules:**

| File Pattern | Technology | Linter Stack |
|--------------|------------|--------------|
| `package.json` + `tsconfig.json` | TypeScript/React | ESLint + Prettier |
| `*.csproj` or `*.sln` | .NET | editorconfig + Roslyn |
| `pyproject.toml` or `requirements.txt` | Python | Ruff |
| Multiple detected | Mixed | Configure all detected |

**Actions:**
1. Glob for technology indicators
2. Build technology list
3. Log detected stack to user

---

## Phase 2: Existing Configuration Check

Before delegating, check what configurations already exist.

**Config Files to Check:**

| Technology | Config Files |
|------------|--------------|
| TypeScript | `eslint.config.*`, `.prettierrc*`, `tsconfig.json` |
| .NET | `.editorconfig`, `Directory.Build.props` |
| Python | `ruff.toml`, `pyproject.toml [tool.ruff]` |
| Pre-commit | `.husky/`, `.pre-commit-config.yaml` |
| Tests | `vitest.config.*`, `pytest.ini`, `*.Tests.csproj` |

**Decision Matrix:**

| Existing Config | Action | Confirmation |
|-----------------|--------|--------------|
| None found | Create from template | No |
| Exists but incomplete | Extend to match template | No |
| Exists and matches template | Skip | Inform user |

**Completeness Check (Python):** evaluate against ln-741's Completeness Check table (7 aspects: Ruff rules, per-file-ignores, advanced settings, MyPy strict, advanced tools, lint script, editorconfig). If ANY aspect is incomplete, delegate to ln-741 with instruction to EXTEND (not replace).

---

## Phase 3: Parallel Delegation

Invoke workers for each quality aspect. Workers can run in parallel as they configure independent tools.

**Delegation Order:**

```
ln-740 (this)
    |
    +---> ln-741-linter-configurator
    |         - ESLint/Prettier (TypeScript)
    |         - editorconfig/Roslyn (.NET)
    |         - Ruff (Python)
    |
    +---> ln-742-precommit-setup
    |         - Husky + lint-staged (Node.js)
    |         - pre-commit framework (Python)
    |         - commitlint
    |
    +---> ln-743-test-infrastructure
              - Vitest (TypeScript)
              - xUnit (.NET)
              - pytest (Python)
```

Pass detected stack and existing configs to workers via direct Skill tool invocation. For Python: instruct ln-741 to apply full quality stack per its Completeness Check table.

**Invocations:**
```
Skill(skill: "ln-741-linter-configurator", args: "{projectPath}")
Skill(skill: "ln-742-precommit-setup", args: "{projectPath}")
Skill(skill: "ln-743-test-infrastructure", args: "{projectPath}")
```

---

## Phase 4: Verification

After all workers complete, verify the quality pipeline works.

**Verification Steps:**

| Check | TypeScript | Python | .NET |
|-------|-----------|--------|------|
| Lint | ESLint | `ruff check` | `dotnet format --verify-no-changes` |
| Format | Prettier | `ruff format --check` | dotnet format |
| Type check | `tsc --noEmit` | `mypy` | Roslyn (build) |
| Import boundaries | depcruise | `lint-imports` | -- |
| Unused deps | knip | `deptry` | -- |
| Dead code | knip | `vulture` | -- |
| Vulnerability scan | `npm audit` | `pip-audit` | -- |
| Unified script | `bash scripts/lint.sh` | `bash scripts/lint.sh` | `bash scripts/lint.sh` |
| Tests | `npm test` | `pytest` | `dotnet test` |
| Hooks | Create test commit | Create test commit | Create test commit |

**On Failure:**
1. Log specific failure
2. Suggest fix or re-run specific worker
3. Do NOT mark as complete until verification passes

---

## Critical Rules

> **RULE 1:** Never overwrite existing user configurations without explicit confirmation.

> **RULE 2:** Workers run AFTER stack detection - do not invoke workers without knowing the stack.

> **RULE 3:** Verification phase is MANDATORY - quality setup is not complete until tools run successfully.

> **RULE 4:** eslint-config-prettier is REQUIRED when both ESLint and Prettier are configured.

---

**TodoWrite format (mandatory):**
```
- Invoke ln-741-linter-configurator (pending)
- Invoke ln-742-precommit-setup (pending)
- Invoke ln-743-test-infrastructure (pending)
- Verify quality pipeline (pending)
```

## Worker Invocation (MANDATORY)

**Host Skill Invocation:** `Skill(skill: "...", args: "...")` is mandatory delegation.
- Claude: call the Skill tool exactly as shown.
- Codex: if no Skill tool exists, locate the named skill in available skills, read its `SKILL.md`, treat `args` as `$ARGUMENTS`, execute that skill workflow, then return here with its result/artifact.
- Do not inline worker logic or mark the worker complete without executing the target skill.

| Phase | Worker | Context |
|-------|--------|---------|
| 3a | ln-741-linter-configurator | Shared (Skill tool) — ESLint/Prettier, editorconfig, Ruff |
| 3b | ln-742-precommit-setup | Shared (Skill tool) — Husky, lint-staged, commitlint |
| 3c | ln-743-test-infrastructure | Shared (Skill tool) — Vitest, xUnit, pytest |

**All workers:** Invoke via Skill tool — workers see coordinator context.

## Definition of Done

- [ ] All detected technology stacks have appropriate quality tools
- [ ] Existing configurations preserved or backed up
- [ ] Lint command runs without errors
- [ ] Format command runs without errors
- [ ] Test command runs and sample tests pass
- [ ] Pre-commit hooks trigger on test commit
- [ ] User informed of all installed tools and commands

---

## Phase 5: Meta-Analysis

Optional reference: load `references/meta_analysis_protocol.md` only when the user asks for post-run meta-analysis or protocol-formatted run reflection.

Skill type: `execution-orchestrator`. When requested, analyze this session per protocol §7. Output per protocol format.

---

## Reference Files

| File | Purpose |
|------|---------|
| [stack_detection.md](references/stack_detection.md) | Detailed detection rules |
| [verification_checklist.md](references/verification_checklist.md) | Full verification checklist |

---

## Error Handling

| Error | Cause | Resolution |
|-------|-------|------------|
| No stack detected | Empty project | Ask user for intended stack |
| Worker failed | Missing dependencies | Install prerequisites, retry |
| Verification failed | Config error | Check specific tool output, fix |
| Hooks not working | Git not initialized | Run `git init` first |

---

**Version:** 3.0.0
**Last Updated:** 2026-03-18
#agile-workflow#code-review#code#qualityfilesystem-access

Related Skills

More skills in Software Engineering

Accessibility Standards

Comprehensive web accessibility standards based on WCAG 2.2 AA, with 38+ anti-patterns, legal enforcement context (EAA, ADA Title II), WAI-ARIA patterns, and framework-specific fixes for modern web frameworks and libraries.

#github-copilot#accessibilityMIT

Accord

Authoring unified specification packages across Business/Development/Design teams via staged elaboration (L0 Vision → L1 Requirements → L2 Team Detail → L3 Acceptance Criteria). No code. Use when authoring cross-team specs, building L0-L3 packages, or aligning Biz/Dev/Design on a single source of truth.

#broad-capability#developmentMIT

Acquire Codebase Knowledge

Use this skill when the user explicitly asks to map, document, or onboard into an existing codebase. Trigger for prompts like "map this codebase", "document this architecture", "onboard me to this repo", or "create codebase docs". Do not trigger for routine feature implementation, bug fixes, or narrow code edits unless the user asks for repository-level discovery.

#github-copilot#documentationMIT

Acreadiness Assess

Run the AgentRC readiness assessment on the current repository and produce a static HTML dashboard at reports/index.html. Wraps `npx github:microsoft/agentrc readiness` and hands off rendering to the @ai-readiness-reporter custom agent. Supports policies (--policy) for org-specific scoring. Use when asked to assess, audit, or score the AI readiness of a repo.

#github-copilot#planningMIT

Acreadiness Generate Instructions

Generate tailored AI agent instruction files via AgentRC instructions command. Produces .github/copilot-instructions.md (default, recommended for Copilot in VS Code) plus optional per-area .instructions.md files with applyTo globs for monorepos. Use after running /acreadiness-assess to close gaps in the AI Tooling pillar.

#github-copilot#skillMIT

Acreadiness Policy

Help the user pick, write, or apply an AgentRC policy. Policies customise readiness scoring by disabling irrelevant checks, overriding impact/level, setting pass-rate thresholds, or chaining org baselines with team overrides. Use when the user asks about strict mode, AI-only scoring, custom weights, CI gating, or wants org-wide standardisation.

#github-copilot#planningMIT