CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

authored-recording-order

Check that every command the recording laws use, run at every place in Suggesting and in Editing on every small document with another author's pending change, records a document whose accept-everything result is what a plain editor gives, whose reject-everything result is the document before, whose undo and redo give back each side, and whose review ledger matches the kernel. Use before and after changing packages/plitejs/src/authored or packages/plitejs/src/history or another file in its coverage record, when the authored-recording step of pnpm check fails, or when fixing a recording bug a seed or a tester found.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

88%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An exceptionally dense, actionable gate-keeping skill: concrete commands with exit-code semantics, a validation-guarded baseline workflow, an explicit triage checklist for failures, and a well-defined coverage/sync procedure. The compressed prose assumes full competence and wastes no tokens on background; the only criticisms are inline time-sensitive operational details and an exhaustive findings catalog that could be split into a reference file.

DimensionReasoningScore

Conciseness

The body never explains concepts Claude already knows — every line carries project-specific fact ("The script calls the laws in packages/plitejs/test/support/recording-laws.ts, the same code the sampled spec calls"), and the compressed style assumes competence. Minor trimmable instances keep it from a 5: time-sensitive specifics such as "Seven recording fixes landed between 2026-10-24 and 2026-11-02" and machine-load timings ("in 28 to 33 s while other sessions load the machine, with load averages from 16 to 77") are not in a deprecated/old-patterns section, and the exhaustive Findings catalog could be tightened. Not score 3, since nothing is padded or unnecessary-to-the-domain.

4 / 5

Actionability

Guidance is fully executable and copy-paste ready: concrete commands ("pnpm check:authored-recording", "pnpm check:authored-recording --lower", "--case='<identity or part of one>'", "--replay='<counterexample>'", "git log --oneline -1 --grep \"check every recording command's accept and reject\""), documented exit codes ("Exit 0 is a pass and exit 1 a finding... Exit 2 is a bad flag or a crashed worker"), and worked examples of identities. This matches the anchor 'Fully executable; copy-paste ready code or commands; specific examples cover the common cases'.

5 / 5

Workflow Clarity

The multi-step process is clearly sequenced with explicit validation checkpoints and feedback loops: run the gate (with the GATE_CASES guard "the run also fails when it compares other than 9,062 cases"), triage a failure against a three-way checklist ("Real bug... Fix the recorder, resolver or history, then run --lower" / "Modeling error... Fix the builder or the script with the reason" / "Intended change... Never weaken a law"), and a sync procedure gated on both a diff review and "a run of pnpm check:authored-recording". Guards like "--lower and --init write nothing when the case count misses GATE_CASES" close the loop on the destructive baseline edit. Matches the anchor 'Clear sequence with explicit validation steps; feedback loops for error recovery; checklists for complex processes'.

5 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), and the body is a self-contained skill whose sections (What it checks, Run it, Read a failure, Findings, What a pass proves, Coverage record, What it does not cover) are well-organized and easy to navigate, with all file pointers being clearly-signaled one-level-deep repo paths. It is not a 5: the exhaustive Findings enumeration (261 gate findings across eight bug classes plus the deep-run catalog) and the mutant analysis are inline content that could plausibly live in a reference file, but they are also the skill's core working knowledge, so the structure is good with minor organization gaps rather than poorly placed.

4 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A highly specific, well-triggered description for a project-internal verification skill: it states exactly what is checked (accept, reject, undo/redo, ledger invariants) and exactly when to use it (before/after touching named source files, on gate failure, or when fixing a found recording bug). The only soft spot is trigger phrasing that leans on project jargon rather than natural synonyms.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete, comprehensive checks: "records a document whose accept-everything result is what a plain editor gives, whose reject-everything result is the document before, whose undo and redo give back each side, and whose review ledger matches the kernel" — four specific verification actions, not vague language. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' and exceeds the score-4 anchor, which allows coverage gaps.

5 / 5

Completeness

Both halves are explicit: the 'what' opens the description ("Check that every command the recording laws use... records a document whose accept-everything result is..."), and the 'when' is an explicit use clause with three concrete triggers ("Use before and after changing packages/plitejs/src/authored or packages/plitejs/src/history... when the authored-recording step of pnpm check fails, or when fixing a recording bug..."). This matches the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases' exactly.

5 / 5

Trigger Term Quality

Trigger phrases are concrete and match what a developer in this repo would say: "changing packages/plitejs/src/authored", "when the authored-recording step of pnpm check fails", "fixing a recording bug a seed or a tester found". Coverage is good but not comprehensive — common natural variations a user might phrase (e.g. "tracked changes", "suggestions", "accept/reject behavior") are absent, so it sits between anchor 3 (missing variations) and anchor 5 (synonyms and extensions), noticeably above the midpoint.

4 / 5

Distinctiveness Conflict Risk

The description occupies a clear niche — a formal verification gate for one package — with distinct triggers (specific file paths like "packages/plitejs/src/authored" and the named command "pnpm check") that no generic skill would match. Minimal conflict risk, matching the anchor 'Clear niche with distinct triggers'.

5 / 5

Total

19

/

20

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

13

/

16

Passed

Repository

udecode/plate

Path

.agents/skills/authored-recording-order/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.