Skip to content
cccskills
FreePublished on GitHub

format-source

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.

OriginalShow the original description

Format source files to align with Liferay's coding standards.

liferay/liferay-portal2,267 stars(GitHub 2,267 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Formatting source files in a module
  • Checking formatting across committed changes
  • Applying the separate Go or shell formatting rules

Files included (1)

  • SKILL.md3.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Format Source

All the code is strictly formatted using the source formatter (Java, JavaScript, JSON, JSP, Markdown, properties, shell, XML, YAML, and others). This is how it works:

Run for a specific module:

cd <module-root> && <gradlew> formatSource

Run across the entire codebase:

git fetch --no-tags https://github.com/brianchandotcom/liferay-portal.git master

cd <repo-root>/portal-impl && ANT_OPTS="-Xmx2560m -Dgit.working.branch.name=$(git merge-base HEAD FETCH_HEAD)" ant format-source-current-branch

Pass git.working.branch.name in ANT_OPTS rather than on the command line, since the yarn formatter lists its files through a separate ant git-util call that inherits nothing else. When the fetch fails, leave out -Dgit.working.branch.name.

ant format-source-current-branch only inspects committed files, so run it after creating the commit, and amend any formatter changes or fixes into that commit.

In both cases, if there are issues to be fixed, the formatter will list them. Fix them.

Skip generated files. The automatic formatter already does this via BaseSourceProcessor.hasGeneratedTag; apply the same rule to any manual edit. A file is generated when it contains any of these unquoted markers:

  • @generated — Service Builder, REST Builder, taglib generator (Java, by far the most common; ~18k files)

  • $ANTLR — ANTLR-generated lexers and parsers

  • # This is a generated file. — generated scripts

  • ## Autogenerated — generated Markdown and config

  • // Code generated ... DO NOT EDIT. — go generate output, such as the controller-gen deepcopy and kubebuilder scaffolding under cloud/

These files are overwritten on the next build, so manual edits are lost and only pollute the diff.

Shell Scripts

Shell scripts (*.sh) follow a separate style guide maintained in the liferay-docker repository. Defer their formatting to the format-bash-source skill and the CODE_STYLE.md it depends on. Resolve both files in this order:

  1. Local Checkout — when liferay-docker sits beside this repository, read ../liferay-docker/.claude/skills/format-bash-source/SKILL.md and ../liferay-docker/.claude/CODE_STYLE.md.

  2. Remote Fallback — when the local checkout is absent, download both files from raw.githubusercontent.com and read them from there:

    temp_dir=$(mktemp -d)
    
    curl \
    	--fail \
    	--output "${temp_dir}/format-bash-source.md" \
    	--silent \
    	--url "https://raw.githubusercontent.com/liferay/liferay-docker/refs/heads/master/.claude/skills/format-bash-source/SKILL.md"
    
    curl \
    	--fail \
    	--output "${temp_dir}/CODE_STYLE.md" \
    	--silent \
    	--url "https://raw.githubusercontent.com/liferay/liferay-docker/refs/heads/master/.claude/CODE_STYLE.md"
    

For any *.sh file in scope, read the resolved format-bash-source SKILL.md and the CODE_STYLE.md it points to, then apply those rules.

Go Code

Go files (*.go) are outside the portal source formatter's set of file types, so the automatic formatter gofmt is used instead. The conventions for Go live in .claude/rules/go-style.md, which is scoped to cloud/operator/**/*.go. Read that file and apply it.

The workflow mirrors the one above. Run gofmt across the Go module — the directory that holds go.mod — apply the rules from .claude/rules/go-style.md, then rerun gofmt to absorb any changes. Both the first pass and the rerun are the same command:

cd <go-module-root> && gofmt -w .

List the files that are not yet formatted without rewriting them:

cd <go-module-root> && gofmt -l .

When a rule and gofmt disagree, gofmt wins; leave the formatted code as it stands.

Skip generated Go files. Beyond the marker line listed above, a Go file whose name contains zz_generated is generated output that the next go generate rewrites.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

jira-bug

FreeSummary

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.3KUpdated Oct 29, 2026

jira-task

FreeSummary

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.3KUpdated Oct 29, 2026

markdown-format

FreeSummary

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.3KUpdated Oct 29, 2026

poshi-migrate

FreeSummary

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.3KUpdated Oct 29, 2026

poshi-shrink

FreeSummary

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.

  • 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
liferay/liferay-portal2.3KUpdated Oct 29, 2026

pr

FreeSummary

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.3KUpdated Oct 29, 2026

See all skills by liferay

Report a problem with this skill