Project Lint Creator

A skill for generating project-specific project-lint skills that automate code quality verification (type checking, linting, building) across a codebase.

What is a project-lint skill?

A project-lint skill tells AI agents exactly which verification commands to run for each package/directory in a project, ensuring that agent-made changes are type-safe, buildable, and lint-clean. It acts as a quality gate — the agent must pass all checks before considering work complete.

When to use this skill

• User wants to set up automated code quality checks for their project
• Project has multiple packages/directories with different lint/build commands
• User says "create a project-lint" or "set up lint verification"
• After initial project setup, to document the verification workflow

Workflow

Step 1: Discover project structure

Scan the project to understand its layout:

1. Check if it's a monorepo (look for pnpm-workspace.yaml, lerna.json, turbo.json, or root workspaces in package.json)
2. List all packages/directories that contain a package.json
3. For each package, extract available scripts: check, lint, typecheck, build, test

# Find all package.json files (excluding node_modules)
find . -name "package.json" -not -path "*/node_modules/*" -not -path "*/dist/*"

# For each, list scripts
cat <package>/package.json | jq '.scripts | keys'

Step 2: Identify verification commands

For each package, determine the correct verification command by priority:

1. check — Preferred. Often combines lint + typecheck + build in one command
2. lint + typecheck — If no check script, use both separately
3. lint + build — If build includes type checking (e.g., tsc --noEmit)
4. lint only — Minimum viable gate

Ask the user to confirm the commands for each package. Show what was discovered and let them adjust.

Step 3: Generate the project-lint SKILL.md

Create a project-lint skill with this structure:

---
name: project-lint
description: "Runs verification commands to ensure changes are type-safe, buildable, and lint-clean. Use after making code changes to verify quality. Triggers: check code, run lint, verify changes, quality gate."
license: MIT
metadata:
  version: "1.0.0"
  author: <team-name>
  project: <project-name>
  tags: [lint, code-quality, verification, <project-name>]
---

# Project Lint

Verify that code changes pass all quality gates before committing.

## Allowed Directories

<list each package directory>

## Constraints

- Execute commands only in the listed directories, never in the project root (unless explicitly listed)
- Use the exact `pnpm run ...` / `npm run ...` script declared in each package's package.json
- Run checks only for packages touched by the change
- If multiple packages were modified, validate each separately

## Workflow & Commands

### `<package-path>`

1. Full Gate: `pnpm run check`

<description of what check does for this package>

<repeat for each package>

## Success Criteria

1. Every command returns exit code 0
2. For each touched package, the relevant gate command passes
3. No root-level shortcuts — run package-local checks

## Self-Healing

If any command fails:
- Capture the full error log
- Locate the source file and line number
- Analyze and apply a fix
- Re-run the failed command until it passes

Step 4: Place the skill

Ask the user where to put the generated skill:

• Project-local: .github/skills/project-lint/SKILL.md (for this project only)
• SkillHub: Push to the company skillhub for centralized management

If pushing to skillhub, use skillctl push project-lint -r skillhub.

Step 5: Verify

After generating the skill, do a dry run:

1. Pick a package that was recently modified
2. Run the verification command from the generated skill
3. Confirm it passes (or fix if not)
4. Show the user the result

Tips for writing good project-lint skills

• Be specific: List exact commands, not generic instructions
• Document what each command does: "check runs lint + build, where build is tsc --noEmit"
• Keep the allowed directories list up to date: When new packages are added, update the skill
• Add project metadata: Use metadata.project to identify which project this skill belongs to
• Scope by change: The agent should only lint packages it actually modified, not the entire repo

Example

Given a project with:

packages/
  fe/          # package.json has: check, lint, build, dev
  api/         # package.json has: lint, typecheck, build
  shared/      # package.json has: check, test

The generated project-lint would include:

• packages/fe → pnpm run check
• packages/api → pnpm run lint && pnpm run typecheck
• packages/shared → pnpm run check