Pull request

Skill SEA-AI/seapowers/skills/pull-request

Shared collection of Claude Code skills and AI workflows for the SEA.AI org

Install

npx -y skills add SEA-AI/seapowers --skill pull-request

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

SEA.AI pull request template. Enforces a consistent PR format with What/Why/How/Testing sections. Use when creating pull requests.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

1.8 KB, 349 tokens by cl100k_base, as published. Nobody here has run it

Pull Request Format

When creating a pull request, use the following format for the PR body:

## What?

Briefly describe the changes introduced by this PR. Highlight the difference between the state before and after the changes. Max 2 sentences.

## Why?

Why are these changes necessary? Is there a specific stakeholder (PM, service, QA, devs, sales) who is driving the motivation for these changes?

## How?

A high level description of the implemented changes. Visual aid is always preferred (diagrams, plots, tables, etc...).

## Testing

<!-- To be filled in manually. -->

Instructions

Use the complete diff against the base branch as the source of truth.
Describe the impact of the change, not the implementation history.
Focus on user-visible, behavioral, or architectural changes. Skip mechanical details unless they matter for review.
Leave the Testing section empty with the HTML comment. Suggest relevant pre-merge validation (tests, benchmarks, screenshots, videos, manual checks, etc.) that the author can add.

Writing Style

Be concise and precise: write only what helps the reader understand the change.
Use simple, plain language. Avoid jargon and unnecessary formality.
Make PRs easy to scan. Prefer tables, diagrams, and code snippets over long paragraphs when they improve clarity.

Large PRs

If the diff is large (e.g. 500+ lines changed, many unrelated files, or multiple independent features), suggest to the user that the PR should be split into smaller, focused PRs. Explain which changes could be grouped together and propose a split.