メニュー
Atomic commit workflow — groups changed files into logical commits and produces Conventional Commit messages prefixed with branch name and author initials. Use when performing any git staging, committing, or when the user asks to save, commit, or push work.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Playwright E2E test setup and authoring for any web application. Plan-first: when asked to write or generate E2E tests, draft a markdown test plan (Overview, Seed, TC-numbered scenarios with Steps + Expected Results) and confirm scope with the user BEFORE writing any .spec.ts. Inspired by Playwright Test Agents (planner → generator → healer): plan, generate from the plan, then run + heal once before declaring done. Use this skill any time the user wants to create, set up, fix, scaffold, or migrate browser-level tests for a web application — whether or not they mention Playwright by name. Typical asks: "write a test for [page/route/flow]", "add e2e coverage for [feature I just shipped]", "generate an e2e test plan", "set up Playwright in [repo]", "fix our broken Playwright setup", "migrate Cypress to Playwright", "add a page object for [X]", "create a fixture that composes with authedPage", "switch our auth helper from token-bypass to real Cognito/SSO/Singpass", "wire up storageState/JWT/session cookies/mol-to
GCC deployment via Rabbit Deploy — initialize a local project with git, configure the Rabbit Deploy GitLab remote with a Project Access Token, and push to trigger automatic deployment. Use when a user wants to deploy their project to GCC using Rabbit Deploy, set up version control for the first time, or push code changes to trigger the CI/CD pipeline.
Enhancement Proposal (EP) creation — stepwise, KEP-style EP authoring with template discovery, parallel codebase research, and structured Part-1 / Part-2 / Part-3 generation. Use when creating or drafting an EP or feature design document.
Implementation plan generation — decomposes an EP or task description into a parallelised, phase-based workplan with a Mermaid dependency graph, critical path analysis, per-task agent prompts, and a parallel dispatch table. Use when creating an implementation plan for an EP or any task description.
React 18 patterns reference — concurrent rendering, automatic batching, transitions, Suspense, new hooks (useId, useTransition, useDeferredValue, useSyncExternalStore), streaming SSR, and TypeScript integration. Use when implementing, reviewing, or debugging React components in any React 18.x project.
React 19.2 modern patterns reference — hooks, Actions API, Server Components, concurrent rendering, TypeScript integration, and quality-of-life improvements. Use when implementing, reviewing, or debugging React components in any React 19+ project.
| name | cc-git-commit |
| description | Atomic commit workflow — groups changed files into logical commits and produces Conventional Commit messages prefixed with branch name and author initials. Use when performing any git staging, committing, or when the user asks to save, commit, or push work. |
Group all changed files into atomic commits — one logical concern per
commit — and produce a Conventional Commit message for each group,
prefixed with [BRANCH_NAME][AUTHOR_INITIALS].
Run one terminal command to get the branch name and author name:
git branch --show-current && git config user.name
Then use getChangedFiles to retrieve all diffs:
sourceControlState: ["staged"] to check for staged
changes.sourceControlState: ["unstaged"] to get all unstaged changes.sourceControlState: ["staged", "unstaged"] to get the full picture.Do NOT run any further terminal commands until Step 3.
An atomic commit contains exactly one logical concern. A single file may appear in more than one group if it contains unrelated changes.
fix — Bug fixes first, so they are reviewable in isolation.feat — New features.refactor / perf — Code improvements with no behaviour change.test — Test additions or updates.docs / style / chore / ci / build — Supporting changes last.Before staging anything, display the proposed grouping:
Proposed atomic commits (N total):
1. fix(auth): correct null check in token validator
Files: src/auth/token.ts
2. feat(ui): add loading spinner to submit button
Files: src/components/Button.tsx, src/components/Button.css
3. chore: bump eslint to v9
Files: package.json, package-lock.json
Proceed with this grouping? (yes / edit)
You MUST wait for user confirmation before staging anything. If the user edits the grouping, update the plan and present it again before proceeding.
When invoked by a subagent on behalf of a non-technical user (e.g. from the Product Manager agent): surface the proposed grouping in plain language before proceeding — replace git jargon with plain descriptions of what each commit saves. For example: "I'll save your changes in 2 batches: (1) the new Home page, (2) the project setup files."
Construct the message using this format:
[<BRANCH_NAME>][AUTHOR_INITIALS] <type>(<scope>): <subject>
<body — optional>
No footer. Subject line only in most cases; include a body only when the subject alone cannot convey the reason for the change (e.g. a non-obvious trade-off, a workaround for an external bug, or an intentional constraint).
BRANCH_NAME — the current branch name, uppercased, with / replaced
by - and special characters stripped.
Example: feature/user-auth → FEATURE-USER-AUTH.AUTHOR_INITIALS — derived from git config user.name by taking the
first letter of each word, uppercased.
Example: John Wei Jian → JWJ.
If user.name is unset or empty, fall back to ? and warn the user.| Type | When to use |
|---|---|
feat | A new feature or capability |
fix | A bug fix |
refactor | Code change that neither fixes a bug nor adds a feature |
chore | Build process, dependency updates, tooling |
docs | Documentation only |
test | Adding or updating tests |
style | Formatting changes (no logic change) |
perf | Performance improvements |
ci | CI/CD configuration changes |
revert | Reverts a previous commit |
build | Build system or external dependency changes |
Include a body only when the subject alone is insufficient to convey the reason for the change. When included:
Process each group from the approved plan in order. For each group:
Stage only the files belonging to this group. You MUST place each file
on its own line using \ continuation for readability:
git add \
<file1> \
<file2>
For mixed-concern files where only specific hunks belong to this group,
use git add -p to stage interactively — but note this requires a
separate approval. Prefer splitting files by concern when possible to
avoid patch-mode staging.
Run staging and committing as a single compound command per group.
You MUST place each file on its own line and each && command on its
own line:
git add \
<file1> \
<file2> \
&& git commit \
-m "<subject line>" \
-m "<body>" \
&& git log --oneline -1
-m per paragraph. Omit the second -m when there is no body.&& git log --oneline -1 confirms the commit without an extra
approval.After each commit, display:
Commit N/total done: <subject line>
Remaining: <list of pending group subjects>
[<BRANCH_NAME>][AUTHOR_INITIALS]git commit exits with code 0git log --oneline -<N> shows N clean, well-scoped commits