CtrlK
BlogDocsLog inGet started
Tessl Logo

poshi-migrate

Migrate a Liferay Poshi .testcase file to its modern test layer (Playwright, Jest, JUnit unit, Java integration). Routes each test to the right layer, consolidates compatible tests at write time, and follows existing Playwright patterns from a configurable reference folder. Use when the user asks to migrate, port, or convert a Poshi .testcase to Playwright, Jest, or JUnit.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

—

The risk profile of this skill

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.

A high-quality playbook: fully actionable commands and helper names, a rigorously sequenced five-phase workflow with genuine validation feedback loops, and disciplined avoidance of restating external rules. The two areas holding it back from perfect are moderate cross-section repetition of the same rules and a monolithic single-file layout where the per-layer details could be offloaded to reference files.

Suggestions

State each rule once and cross-reference it: the Drop-commit message convention is repeated in the feasibility table, the Plan 'Cleanup'/'Commits' sections, and the Implement phase; the Skip/missing-endpoint proposal rule is likewise duplicated between Feasibility and the API First Setup decision tree.

Move the per-layer implementation detail (Setup Mappings, Jest/JUnit unit/Java integration conventions, and the failure triage protocol) into reference files alongside the existing .claude/rules/playwright.md pattern, keeping SKILL.md as a navigable workflow overview.

Trim the plan template's column-level explanations (e.g., repeating 'Migrate / Skip / Drop' semantics inside the Feasibility table header) since the same vocabulary is already defined in the phase sections.

DimensionReasoningScore

Conciseness

The body is dense, imperative procedural guidance with essentially zero explanation of concepts Claude already knows — every line is a domain-specific rule, path, or command. It sits at the score-4 anchor (efficient, minor trimming possible) rather than 5 because some rules are restated across sections: the Drop-commit convention appears in the feasibility table, the Plan 'Cleanup'/'Commits' sections, and again in the Implement phase, and the Skip/missing-endpoint proposal rule is similarly repeated. It is well above the score-3 anchor, whose 'unnecessary explanation' implies padding rather than this cross-referenced redundancy.

4 / 5

Actionability

The guidance is fully executable for the common cases: exact bash commands ("git log --all --format=\"%H %s\" --grep=\"^${TICKET}\"", "yarn test --repeat-each=10 <relative-spec-path>"), a copy-paste-ready mergeTests fixture example, exact helper names ("apiHelpers.headlessAdminSite.postSite", "apiHelpers.headlessAdminUser.postUserAccount"), and concrete Poshi-to-helper setup mappings. The score-5 anchor (copy-paste ready commands covering common cases) fits; the score-4 anchor's 'minor gaps' would require missing key details, and the only placeholders are in the plan template where they are the intended output format.

5 / 5

Workflow Clarity

Five named phases (feasibility, inventory, plan, implement, validate) are clearly sequenced and gated on user approval, with an exhaustive plan checklist ("every test from the inventory phase appears in either the Feasibility, Existing Coverage, or Per-Test Routing table") and explicit feedback loops: the failure-mode triage protocol in 'When a Spec Fails' with a fix-and-revalidate cycle, the mandatory flake check, and hard rules like "Never xfail, comment out, or weaken an assertion". Destructive operations (deleting test blocks, commits) have validation gates, satisfying the score-5 anchor including the batch/destructive cap.

5 / 5

Progressive Disclosure

Structure is good: a one-level-deep external reference is clearly signaled ("Follow .claude/rules/playwright.md ... Do not duplicate or restate those rules here — read the file and apply it") and config defaults are delegated to config.example.json rather than restated. It matches the score-4 anchor (good structure, references clear, minor organization gaps) but not 5: at ~410 lines, the per-layer implementation rules (Setup Mappings, Jest/JUnit/integration conventions, failure triage) are inlined in SKILL.md where a reference file split — which the skill itself demonstrates with playwright.md — would make the overview easier to navigate. No bundle directories (references/, scripts/, assets/) exist, so there is no multi-level nesting risk to penalize.

4 / 5

Total

18

/

20

Passed

Description

100%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.

An exemplary description: concrete actions, explicit and natural trigger phrasing with synonyms and file extensions, both 'what' and 'when' clearly answered, and a distinctive niche that eliminates conflict risk. Third-person voice is used throughout and there is no padding.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with comprehensive coverage: "Migrate a Liferay Poshi .testcase file to its modern test layer (Playwright, Jest, JUnit unit, Java integration)", "Routes each test to the right layer", "consolidates compatible tests at write time", and "follows existing Playwright patterns from a configurable reference folder". It clearly matches the score-5 anchor (multiple specific concrete actions, comprehensive) and exceeds the score-4 anchor, which allows only minor coverage gaps — none are present.

5 / 5

Completeness

It explicitly answers both questions: the 'what' is the full migration workflow sentence, and the 'when' is the concrete trigger clause "Use when the user asks to migrate, port, or convert a Poshi .testcase to Playwright, Jest, or JUnit". This is exactly the score-5 anchor pattern; the score-4 anchor would require the 'when' to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Trigger terms are comprehensive and natural: the verb synonyms "migrate, port, or convert", the file extension ".testcase", and the target framework names "Playwright, Jest, or JUnit" in the 'Use when' clause. This matches the score-5 anchor (comprehensive coverage including synonyms and file extensions); the score-4 anchor requires missing natural terms, and none are missing — a user asking to port Liferay Poshi tests would use these exact words.

5 / 5

Distinctiveness Conflict Risk

"Liferay Poshi .testcase" carves out a clear niche with distinct triggers — no other plausible skill would claim a request to port a Poshi testcase. Conflict risk is minimal, matching the score-5 anchor; the score-4 anchor's 'minor overlap risk with closely related skills' does not apply since the domain and trigger terms are unique to this skill.

5 / 5

Total

20

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository
liferay/liferay-portal
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.