본문으로 건너뛰기
cccskills
무료GitHub에 공개

poshi-shrink

Plan and carry out a reduction of a Liferay component’s Poshi test suite by identifying overlapping tests and combining their unique assertions. The skill inventories matching test files, preserves tests with special setup or properties, and commits each planned rename or merge separately.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Shrink a Liferay component's Poshi test suite by merging overlapping tests. Use when the user asks to reduce, merge, or clean up Poshi tests for a @component-name.

liferay/liferay-portal스타 2,267(GitHub 2,267 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • Reduce overlapping Poshi tests for a component
  • Prepare a test suite for migration to another test layer
  • Review a file-by-file plan for merging functional tests

포함된 파일(1)

  • SKILL.md5.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Shrink Poshi Tests

A playbook for shrinking a Liferay component's Poshi test suite before migrating tests to Playwright, Java integration, or the unit layer. Typical outcome: a file with ~27 tests ends up with ~8, in ~24 small reviewable commits.

Preconditions

  • The working tree is clean. Abort and ask the user to commit or stash first when dirty.

Input

Component Name

The @component-name annotation, passed as ${ARGUMENTS} (e.g., portal-analytics-cloud, portal-commerce, portal-content-management). When ${ARGUMENTS} is empty, scan .testcase files under portal-web/test/functional/com/liferay/portalweb/tests/enduser, list the distinct @component-name values found, and ask the user to pick one. Do not guess.

Verify the component by enumerating, under portal-web/test/functional/com/liferay/portalweb/tests/enduser, every .testcase whose @component-name matches; abort when no file matches. The same enumeration feeds the Shrink Plan: per file, capture the path, the testray.main.component.name value, and the test-block count.

Expected Output

Shrink Plan

Build the plan via plan mode (EnterPlanMode) using this format:

## Inventory

| File | Test Count | testray.main.component.name |
| --- | --- | --- |
| <path> | <N> | <component> |

## Files to Attack

### <file path> (N → M)

> **Group A — <Context name>** (N → 1):
>
> - Rename `<Keeper>` → `<FinalName>` (commit 1)
> - Merge `<Source2>` → adds `<assertion>` (commit 2)
> - Merge `<Source3>` → adds `<assertion>` (commit 3)
> - … etc

### <next file path> (N → M)

…

Sort the inventory ascending by test count so small files (easy wins) surface first. Avoid files with 40+ tests on the first pass.

Pick the keeper for each group: the test with the most comprehensive assertions, even when its name is awkward — the keeper does not have to keep its name. The final name describes the combined behavior (e.g., ContentPerformancePanelInBlogDisplayPage, LanguageDropdownInContentPage) and is typically different from the keeper's original name.

Common merge-worthy signals — classic patterns from Liferay test names:

  • Multiple AuthorNotShowIn<Context> tests — usually one per panel context is enough.
  • Multiple MetricsIconVisibleIn<Context> + PanelInformationIn<Context> — the first checks title+traffic, the second title+URL+language — huge overlap between the two.
  • CheckAllInfo* or similar catch-all tests that duplicate specific-field tests.
  • Tests that share the full setUp + first N tasks (navigate, create blog, open panel) and differ only in the final assertion.

Merge Signals — DO

  • Same setup + same UI surface + different assertion → one test with N assertion tasks.
  • Tests differing only in asset type (blog vs document vs widget vs content page) when the panel behavior being asserted is identical — one representative usually suffices; propose deletion for the rest rather than merging four tests into four.
  • Tests where the source's assertion is already fully covered in the target — the commit still happens — it just deletes the source.

Merge Signals — DO NOT

  • Tests with test-level property overrides that differ: property portal.upstream = "quarantine", property test.liferay.virtual.instance = "false", property test.run.type = "single" (when not inherited).
  • Tests with special setup (localized URLs, fragment translations, system settings changes, extra page creation).
  • Tests with @ignore / @skip annotations.

Shrunk Test Files

After ExitPlanMode returns the user's approval, apply each operation in the order it appears in the plan and commit after each one — one commit per operation, never squashed. The per-merge granularity is exactly what makes the diff reviewable.

  • Rename — change the keeper's test <OldName> to test <FinalName> with no other edits. Commit message: <TICKET> Rename test <Keeper> to <FinalName>.
  • Merge — delete the source's test <Source> { ... } block and fold its unique assertions into the target as new task blocks. When the source's assertions are already fully covered by the target, simply delete the source. When the same condition is asserted at different strengths (e.g., AssertTextEquals.assertPartialText("web/<site-path>") vs the weaker AssertVisible value1="http://"), keep the stronger one. Commit message: <TICKET> Merge test <Source> into <FinalName>.

When the file convention keeps tests alphabetical, add a final <TICKET> Alphabetic order commit after all merges.

Summary

After the file is shrunk, report:

  • The file shrunk and its testray.main.component.name.
  • Before/after test counts.
  • Total commits made (renames + merges + optional cleanups).
  • Tests kept intact and the reason (special setup, differing properties, @ignore).

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Use this skill to format Liferay source files according to the project’s conventions. It describes the formatter workflows for modules and committed changes, how to handle Go and shell files, and which generated files to leave untouched.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Formatting source files in a module
  • Checking formatting across committed changes
  • Applying the separate Go or shell formatting rules
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

jira-bug

무료

Use this skill to file a bug in the LPD Jira project from a description or fix commit. It gathers reproduction steps and expected versus actual behavior, applies required project fields, and returns the created ticket key and link.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Filing a newly reported LPD bug
  • Turning a fix commit into a bug ticket
  • Recording reproduction steps and expected behavior
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

jira-task

무료

Use this skill to create a Task ticket in the LPD Jira project from a description or commit. It gathers missing details, selects a matching component, formats the description with acceptance criteria when applicable, and returns the ticket key and link.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Creating an LPD task from a short description
  • Turning a commit into a task ticket
  • Adding acceptance criteria to a Jira task
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

Format Markdown files for Liferay repositories by aligning front matter, heading capitalization, shell examples, and prose with the project’s style rules. Use it to clean up or copy-edit a document and receive a summary of the changes.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Formatting a Markdown guide for a Liferay repository
  • Cleaning up headings and front matter in a document
  • Polishing shell examples and prose in Markdown
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

Analyzes a Liferay Poshi `.testcase`, checks feasibility and existing coverage, then routes each test to Playwright, Jest, JUnit unit, or Java integration tests. It creates a migration plan and can implement the approved changes using repository patterns.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Migrating Poshi test cases to modern test layers
  • Finding existing specs that already cover Poshi tests
  • Planning Playwright, Jest, or JUnit test conversions
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

pr

무료

Create a GitHub pull request from the current branch, assemble its title and description from the branch’s commits, and connect it to the relevant Jira tickets. The workflow also runs the required PR check and records the new PR URL on each ticket.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Opening a pull request for the current development branch
  • Preparing a PR description from commits and Jira tickets
  • Recording a new PR on its related Jira work items
liferay/liferay-portal2.3천2026년 10월 29일 업데이트

liferay의 스킬 모두 보기

이 스킬의 문제 신고