playbooks

home / skills / lambda-curry / devagent / quality-gate-detection

quality-gate-detection skill

/.devagent/plugins/ralph/skills/quality-gate-detection

This skill helps you detect and configure project quality gates by analyzing package.json scripts and frameworks to tailor verification.

npx playbooks add skill lambda-curry/devagent --skill quality-gate-detection

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: Quality Gate Detection
description: >-
  Detect and configure quality gate commands for Ralph's autonomous execution.
  Use when: (1) Analyzing a project to determine available test, lint, and build scripts,
  (2) Generatiing a task-specific verification checklist based on project reality.
  This skill enables Ralph to adapt verification to the specific project context.
---

# Quality Gate Detection

Dynamically detect project quality gates from `package.json` scripts and frameworks.

## Prerequisites

- Read access to `package.json` in the project root

## Detection Process

### Step 1: Analyze Project Scripts (Hybrid Diagnosis)

Read `package.json` and inspect the `scripts` section to identify verification commands.

**Priority Heuristics:**
1. **Test:** Look for `test`, `test:unit`, `test:ci`. Preference: `npm test` or specific script.
2. **Lint:** Look for `lint`, `lint:fix`, `eslint`. Preference: `npm run lint`.
3. **Typecheck:** Look for `typecheck`, `tsc`, `build`. Preference: `npm run typecheck` or `tsc --noEmit`.
4. **Browser/E2E:** Look for `test:browser`, `e2e`, `cypress`, `playwright`. Preference: `npm run test:browser`.

**Framework Detection:**
- Identify test runner: `jest`, `vitest`, `mocha`, `ava`.
- Identify linter: `eslint`, `tslint`, `biome`.
- Identify builder/runtime: `tsc`, `vite`, `next`, `webpack`.

### Step 2: Formulate Verification Commands

Construct the actual commands to be run by the agent.
- If a script exists (e.g., `"test": "jest"`), use `npm run test`.
- If no script exists but framework is detected (e.g., `jest` in dependencies), try standard binary `npx jest`.
- **MISSING:** If no scripts/frameworks are detected for a category, leave the command empty. Do NOT assume defaults like `npm test` exist.

### Step 3: Execution (Just-in-Time)

Use the detected commands immediately to verify your work.
- Do **not** write a `quality-gates.json` file.
- Do **not** ask for permission to run standard checks unless they are destructive.
- Simply execute the commands as part of your verification loop.

## Edge Cases

**Ambiguous Scripts:**
- If multiple scripts match (e.g., `test` and `test:all`), prefer the one that seems most appropriate for *local* verification (often `test` or `test:unit`).
- When in doubt, note the ambiguity in the "rationale".

**Missing Scripts:**
- If a category (e.g., `lint`) has no script and no detected config, omit it from the *required* gates. Report it as "Not Detected".

## Validation

1. Verify `package.json` exists and is valid JSON.
2. Ensure derived commands are executable (e.g., don't suggest `npm run lint` if `lint` script is missing).

## Reference Documentation

- **Config Template**: See `tools/config.json` for full configuration structure

Overview

This skill detects and configures project-specific quality gate commands so Ralph can run targeted verification automatically. It reads the project's package.json and the dependency footprint to identify available test, lint, typecheck, and E2E commands and then formulates safe, executable commands for just-in-time verification. The goal is to adapt verification to the actual project context rather than assuming defaults.

How this skill works

The skill inspects package.json scripts and the dependency list to find known test runners, linters, typecheckers, and builders. It uses a priority heuristic to pick the most appropriate script (for example preferring test or test:unit for unit tests) and builds executable commands (npm run <script> or npx <binary>) only when a script or framework is present. If no script or detectable framework exists for a gate, it marks that gate as Not Detected and omits it from required checks.

When to use it

  • When analyzing a repository to discover available test, lint, build, and typecheck commands.
  • Before starting autonomous verification so Ralph runs relevant, non-assumptive checks.
  • When generating a task-specific verification checklist tailored to the project.
  • When deciding which verification steps to execute in CI-like workflows without modifying project files.

Best practices

  • Always ensure package.json is present and valid; the skill depends on accurate JSON parsing.
  • Prefer existing npm scripts over invoking binaries directly; use npx only if no script exists but the framework is present.
  • Do not create or persist new config files; keep detection transient and executed just-in-time.
  • Report ambiguous matches and rationale so reviewers can confirm which script was chosen.
  • Omit gates that are not detected instead of guessing defaults to avoid false positives.

Example use cases

  • Discovering that a project provides test:unit and lint scripts and configuring Ralph to run npm run test:unit and npm run lint.
  • Detecting jest in dependencies but no test script and selecting npx jest as the verification command.
  • Identifying that no typechecking tool is present and marking typecheck as Not Detected in the verification checklist.
  • Choosing test:browser for browser/E2E checks when cypress or playwright appear in dependencies.

FAQ

What happens if multiple scripts match a category?

The skill prefers scripts suited for local verification (e.g., test or test:unit) and records the rationale; if ambiguity remains it reports it rather than guessing.

Will the skill add new scripts to package.json?

No. It never writes or persists project files. Detection is read-only and commands are executed just-in-time.