---
name: erp-kit-score
description: Evaluate a consumer repo's adherence to erp-kit philosophy across two independent dimensions (template sync, implementation thinness). Use when the user asks "how erp-kit-aligned is this repo?", as a periodic health check, or before deciding to refactor. For forward-looking update recommendations use erp-kit-update-advisor instead.
disable-model-invocation: true
metadata:
  erp-kit-version: "0.59.0"
---

# erp-kit Score Workflow

Evaluate a repo's **current state** against erp-kit philosophy across two independent dimensions and emit findings per dimension. The dimensions are **not aggregated into a single overall score** — they describe different concerns and are intended to be read side-by-side.

This skill is **not a strict drift checker** and **not a future-looking update advisor.** Scoring tolerates legitimate divergences (project-specific customizations, intentional dependency pinning, etc.). The goal is to surface whether the repo follows the spirit of erp-kit at the current point in time. For "should I update?" use [`erp-kit-update-advisor`](../erp-kit-update-advisor/SKILL.md).

Repo structure and version alignment used to be score dimensions, but they are deterministic pass/fail checks — they are now enforced by the `erp-kit verify` CI gate (shipped in the `erp-kit-check` workflow) and are no longer evaluated here. This skill keeps only the dimensions that need judgement.

## Output shape per dimension

| Dimension | Output type | What it means |
| --------- | ----------- | ------------- |
| Template sync | 0-100 score | continuous — degrees of drift acceptability |
| Implementation thinness | 0-100 score | continuous — degrees of alignment with the thin-implementation principle |

Both dimensions are continuous because they tolerate legitimate divergence — there are degrees of alignment, unlike the binary filesystem/version contracts that `erp-kit verify` enforces.

## When to Use

- User asks "how erp-kit-aligned is this repo?" or "score this codebase"
- As a periodic health check (quarterly, before releases, etc.)
- Before deciding to refactor a module / app

## Workflow

```
SETUP → DISPATCH DIMENSION AGENTS → REPORT (each dimension stands alone)
```

## Step 1: Setup

Define shared context:

- `REPO_ROOT`: argument or current working directory. Must contain a `package.json` and a `node_modules/@tailor-platform/erp-kit/` directory.
- `APP_ROOT` (optional): path to one app directory under `REPO_ROOT`
- `APPS_ROOT` (optional): path to the apps directory under `REPO_ROOT`
- `MODULES_ROOT` (optional): path to the modules directory under `REPO_ROOT`

If `@tailor-platform/erp-kit` is not a dependency, stop with: "erp-kit is not installed in this repo."

## Step 2: Dispatch Dimension Agents (parallel)

Two agents run in parallel:

| Agent | Prompt template | Inputs |
| ----- | --------------- | ------ |
| Templates | [references/dim-templates.md](references/dim-templates.md) | `REPO_ROOT` |
| Thinness | [references/dim-thinness.md](references/dim-thinness.md) | `REPO_ROOT`, optional `APP_ROOT` and `MODULES_ROOT` |

Each agent returns structured JSON shaped `{ score: 0-100, findings: [...] }`. See [references/score-report-format.md](references/score-report-format.md) for the full shape.

## Step 3: Report

Emit each dimension's result independently — no weighting, no overall score. Follow the layout defined in [references/score-report-format.md](references/score-report-format.md):

- Summary table with the two dimensions side-by-side (score plus headline finding count)
- Per-dimension section with full findings

The reader reads each dimension on its own merits; a "low template sync" repo can still have great thinness, and the score skill should make that obvious.