feat: Add lint skill (zero-tolerance) + strengthen kickstart linting mandate

New skill: lint — zero-tolerance linting enforcement for all code changes.
Detects project linter, fixes ALL violations, never disables rules.

Updated kickstart: linting now explicit standing order #3 in worker template
with "NON-NEGOTIABLE" language and zero-tolerance enforcement.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

README.md

@@ -1,6 +1,6 @@
 # Agent Skills
 
-Complete agent skill fleet for Mosaic Stack. 94 skills across 12 domains — coding, business development, design, marketing, writing, orchestration, document generation, Vue/Vite ecosystem, and more. Platform-aware — works with both GitHub (`gh`) and Gitea (`tea`) via our abstraction scripts.
+Complete agent skill fleet for Mosaic Stack. 95 skills across 12 domains — coding, business development, design, marketing, writing, orchestration, document generation, Vue/Vite ecosystem, and more. Platform-aware — works with both GitHub (`gh`) and Gitea (`tea`) via our abstraction scripts.
 
 ## Security Audit
 
@@ -16,12 +16,13 @@ All skills were reviewed on 2026-02-16. Findings:
 
 88 of 93 audited skills passed all checks as clean instruction-only SKILL.md files.
 
-## Skills (94)
+## Skills (95)
 
-### Code Quality & Review (5)
+### Code Quality & Review (6)
 
 | Skill | Purpose | Origin |
 |-------|---------|--------|
+| `lint` | Zero-tolerance linting — detect linter, fix ALL violations, never disable rules | Mosaic Stack |
 | `pr-reviewer` | Structured PR code review workflow (Gitea/GitHub) | Adapted from SpillwaveSolutions |
 | `code-review-excellence` | Code review methodology and checklists | awesome-skills |
 | `verification-before-completion` | Evidence-based completion claims | obra/superpowers |
@@ -191,7 +192,7 @@ All skills were reviewed on 2026-02-16. Findings:
 | [wshobson/agents](https://github.com/wshobson/agents) | 3 | Architecture, Python, Tailwind |
 | [mblode/agent-skills](https://github.com/mblode/agent-skills) | 1 | UI animation |
 | [giuseppe-trisciuoglio/developer-kit](https://github.com/giuseppe-trisciuoglio/developer-kit) | 1 | shadcn/ui |
-| Mosaic Stack (original) | 3 | PR review, code review, orchestration |
+| Mosaic Stack (original) | 4 | PR review, code review, orchestration, linting |
 
 ## Installation
 

skills/kickstart/SKILL.md

@@ -205,12 +205,13 @@ You are now the **orchestrator**. Follow the protocol from `~/.claude/agent-guid
 
 1. **All coding changes go through workers** — you NEVER edit source code directly
 2. **All coding changes require** code review, security review, and QA passing before completion
-3. **Completed issues are closed** in the repo via `~/.claude/scripts/git/issue-close.sh`
-4. **tasks.md is the single source of truth** — you are the sole writer
-5. **Branch from `develop`** (or whatever was detected/confirmed in Step 1) as the upstream
-6. **Max 2 parallel workers** at any time
-7. **Two-Phase Completion:** Bulk phase (target 90%), then Polish phase (target 100%)
-8. **Context threshold (55-60%):** Output handoff kickstart and STOP — do not compact
+3. **Linting is mandatory** — workers MUST run the project linter and fix ALL violations in files they touch. Zero lint errors. No disabling rules. No skipping files. This is non-negotiable.
+4. **Completed issues are closed** in the repo via `~/.claude/scripts/git/issue-close.sh`
+5. **tasks.md is the single source of truth** — you are the sole writer
+6. **Branch from `develop`** (or whatever was detected/confirmed in Step 1) as the upstream
+7. **Max 2 parallel workers** at any time
+8. **Two-Phase Completion:** Bulk phase (target 90%), then Polish phase (target 100%)
+9. **Context threshold (55-60%):** Output handoff kickstart and STOP — do not compact
 
 ### Orchestrator Loop
 
@@ -246,9 +247,14 @@ When spawning a worker, provide this structure:
 ### Requirements
 {Issue description and acceptance criteria}
 
-### Quality Gates
-Run these before reporting success:
+### Quality Gates (MANDATORY — zero tolerance)
+Run ALL of these before reporting success. Fix every failure.
+```
 {quality gate commands from project}
+```
+**Linting is NON-NEGOTIABLE.** Run the project linter and fix ALL violations
+in every file you touched. Do NOT leave lint warnings, do NOT disable rules,
+do NOT skip files. If you changed it, you lint it.
 
 ### Skills
 Read these before starting:

skills/lint/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: lint
+description: "Enforce zero-tolerance linting on every code change. This skill MUST be followed after writing or modifying any code file. Run the project linter, fix ALL violations, and never cut corners. Triggers on: lint, delint, fix lint errors, clean up code, run linter."
+---
+
+# Lint — Zero Tolerance
+
+**Every code change you make MUST pass the project linter with zero errors and zero warnings before you consider the work done.**
+
+This is not optional. This is not "nice to have." This is a hard gate.
+
+---
+
+## The Rules
+
+1. **Run the linter after every code change.** Not at the end. After every change.
+2. **Fix ALL violations** in files you touched. Not just the ones you introduced — if you touched the file, you own it.
+3. **Never disable lint rules** to make errors go away. Fix the code, not the config.
+4. **Never skip files** with `// eslint-disable`, `# noqa`, `// nolint`, `@SuppressWarnings`, or any equivalent.
+5. **Never leave warnings.** Warnings are errors you haven't fixed yet.
+6. **Never claim "it was already there."** If you modified a line with a violation, you fix it. (Campsite Rule)
+7. **Never report success with lint failures.** If the linter reports errors, you are not done.
+
+---
+
+## Step 1: Detect the Project Linter
+
+Check for these in order:
+
+| File / Config | Linter | Command |
+|---------------|--------|---------|
+| `biome.json` or `biome.jsonc` | Biome | `pnpm biome check --write .` or `npx biome check --write .` |
+| `.eslintrc.*` or `eslint.config.*` or `package.json` has `eslint` | ESLint | `pnpm lint` or `npx eslint --fix .` |
+| `pyproject.toml` with `[tool.ruff]` | Ruff | `ruff check --fix .` |
+| `pyproject.toml` with `[tool.flake8]` or `.flake8` | Flake8 | `flake8 .` |
+| `pyproject.toml` with `[tool.pylint]` or `.pylintrc` | Pylint | `pylint **/*.py` |
+| `.rubocop.yml` | RuboCop | `rubocop -a .` |
+| `Cargo.toml` | Clippy | `cargo clippy --fix` |
+| `.golangci.yml` | golangci-lint | `golangci-lint run --fix` |
+
+Also check `package.json` scripts for a `lint` or `lint:fix` command — prefer the project's configured command over raw tool invocations.
+
+If a `Makefile` has a `lint` target, use `make lint`.
+
+If the project has a `.woodpecker.yml` or CI config, check what lint command CI runs — your local lint must match CI.
+
+---
+
+## Step 2: Run the Linter
+
+```bash
+# Preferred: use the project's configured lint command
+pnpm lint          # or npm run lint, yarn lint
+pnpm lint --fix    # auto-fix what can be auto-fixed
+
+# Then check for remaining errors
+pnpm lint
+```
+
+If the project doesn't have a `lint` script, run the detected tool directly (see table above).
+
+---
+
+## Step 3: Fix All Violations
+
+### Auto-fixable violations
+Most linters have a `--fix` flag. Use it first:
+```bash
+pnpm lint --fix
+# or
+npx eslint --fix .
+# or
+ruff check --fix .
+```
+
+### Manual violations
+After auto-fix, re-run the linter without `--fix`. For each remaining error:
+1. Read the rule name and understand WHY it exists
+2. Fix the code to comply with the rule
+3. Do NOT add a disable comment
+
+### Common violations and correct fixes
+
+| Violation | Wrong Fix | Right Fix |
+|-----------|-----------|-----------|
+| `no-unused-vars` | `// eslint-disable-next-line` | Delete the unused variable |
+| `@typescript-eslint/no-explicit-any` | `// eslint-disable` | Add a proper type |
+| `prefer-const` | Ignore it | Change `let` to `const` |
+| `no-console` | `// eslint-disable` | Use the project's logger |
+| Import order | Ignore it | Let auto-fix sort imports |
+| `any` type | `as unknown as Type` | Define the correct type |
+
+### The only acceptable exception
+
+If fixing a violation would require a major refactor outside your task scope:
+1. Do NOT disable the rule
+2. Document it as a deferred item with rationale
+3. Create a follow-up task/issue for the fix
+4. The orchestrator (not you) decides if this is acceptable
+
+---
+
+## Step 4: Verify Clean
+
+Run the linter one final time with no flags:
+
+```bash
+pnpm lint
+```
+
+Expected output: **zero errors, zero warnings.** If you see any output that isn't "all clear," you are not done.
+
+---
+
+## Step 5: Also Run Type Checking
+
+Linting alone is not enough. If the project has TypeScript:
+
+```bash
+pnpm typecheck    # or npx tsc --noEmit
+```
+
+Fix ALL type errors too. The same zero-tolerance rules apply.
+
+---
+
+## For Orchestrated Workers
+
+When you receive a task from an orchestrator, linting is part of the quality gates. Your workflow is:
+
+```
+1. Implement the change
+2. Run lint --fix
+3. Run lint (verify zero errors)
+4. Run typecheck (if applicable)
+5. Run tests
+6. Only THEN report success
+```
+
+If you report `"status": "success"` with lint errors, you have failed the task.
+
+---
+
+## Quick Reference
+
+```bash
+# JavaScript/TypeScript
+pnpm lint --fix && pnpm lint && pnpm typecheck
+
+# Python
+ruff check --fix . && ruff check . && mypy .
+
+# Rust
+cargo clippy --fix && cargo clippy
+
+# Go
+golangci-lint run --fix && golangci-lint run
+```