Menu
Add a new rule to the format-source skill, derived from a Git commit.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/liferay/liferay-portal --skill format-source-add-ruleThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Based on SOC occupation classification
| description | Add a new rule to the format-source skill, derived from a Git commit. |
| name | format-source-add-rule |
Add a new rule to the format-source skill, derived from a Git commit. Anyone can use this to encode a convention they spotted in someone's commit. Rules can apply to any file type the source formatter handles — Java, .properties, XML, JSP, Markdown, Gradle, .gitignore, YAML, and so on. Do not bias toward Java.
A Git commit SHA.
Optional: a hint about which aspect of the commit to encode. Commits often touch multiple things; a hint narrows the scope.
Inspect the commit's full diff. Identify a single, learnable formatting pattern — something a future reviewer could apply mechanically to other code. Stop and ask the user to clarify when:
Multiple distinct rules are present. Ask the user to pick one, or run the skill once per rule.
The commit mixes formatting changes with logic or refactoring changes that cannot be separated.
The pattern is not generalizable beyond the specific file or context.
Read the existing rules in .claude/skills/format-source/SKILL.md and compare against the pattern from the previous step. If the pattern duplicates or substantially overlaps an existing rule, flag it to the user and ask whether to skip, refine the existing rule, or proceed anyway.
Find the next rule number in .claude/skills/format-source/SKILL.md, then append the new rule at the end of the file using this exact markdown template:
### Rule <next-number>: <Title Case name, for example "Method Parameter Ordering">
**Why:** <one-sentence explanation of what consistency the rule buys, not what the rule does>
**Examples:**
```diff
- <one or more before lines demonstrating the rule, using abstract identifiers — not the commit's literal code>
+ <matching after lines>
```
Use abstract identifiers in the diff rather than the verbatim names from the commit — for example methodA, fieldB, Foo for Java; some.property, myTag, someKey for properties, XML, YAML, or Markdown. The examples should illustrate the general pattern; reproducing the commit's exact text overfits the rule to one case and makes future readers match on names rather than the underlying pattern.
For rules with nuance, use several diff blocks for each additional case. Add a single line of prose before the diff block when a diff alone is unclear.
Validate that the appended rule reproduces the input commit when applied to the commit's parent state. To do this, create a new branch at the commit's parent and run /format-source scoped to only the files touched by the commit, applying only the manual rules (skip the automatic formatter). Compare the result with the commit. If the rule does not produce an equivalent change, revise the rule and repeat until it does.
After the self-test passes, stage only .claude/skills/format-source/SKILL.md and commit with this commit message format:
<ticket> Add rule derived from <sha>