메뉴
MANDATORY skill for ALL commits. Must be used EVERY TIME before creating any git commit. No exceptions.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/ossappscollective/OSS-DocumentScanner --skill commit명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | commit |
| description | MANDATORY skill for ALL commits. Must be used EVERY TIME before creating any git commit. No exceptions. |
BEFORE ANY git commit COMMAND:
git diff --staged first to see changestest/lint/format scripts — invoke the binaries with npx; yarn vitest/yarn eslint/yarn prettier fail on Yarn 4):
npx vitest run <path> when a *.test.ts covers the change (isolate with a path or -t '<name>')yarn svelte-check when .svelte/.ts typing is affected (this one is a real script)npx eslint <changed files>--auto (caller runs autonomously): skip all approval/confirmation waits here (commit-plan gate below + fixup/rebase) — commit directly. Diff review, atomic splitting, checks, message format unchanged.
User trust requires seeing the plan before execution. Always present the full commit plan and wait for explicit approval before running any git commit command.
For each commit (regular or fixup), present:
Then ask the user to confirm. Do not proceed until they approve. If they request changes to the message or grouping, adjust and re-present.
This applies equally to regular commits, fixups, and any commits triggered during the open-pr workflow.
Before creating a new commit, check whether the staged changes should be fixup'd into a recent commit on the current branch.
Process:
git log main..HEAD --oneline to list all commits on the branch since diverging from maingit log main..HEAD -- <file> to see if it was modified in a recent branch commit<file> looks like it should be fixup'd into <sha> <message>. Want me to fixup instead of creating a new commit?"When fixup is confirmed:
git commit --fixup=<sha> (with user confirmation)GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash main to squash immediately (with user confirmation before the rebase)If the change doesn't clearly relate to a previous commit, proceed with a normal new commit.
This repo uses Conventional Commits (enforced by the @commitlint/config-conventional config inline in package.json). The format is fixed:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory; scope, body, and footer are optional.
Shape: <type>(<scope>): <subject>
<type> is one of: build ci docs feat fix fix-next perf refactor release style test<scope> (optional) is the affected area — usually a feature under app/components/ or a service under app/services/ (e.g. ocr, pdf, camera, sync, settings, security, edit, pkpass). When a change is platform-specific, prefix the scope with the platform: android/sync, ios/camera<subject>: imperative present tense ("change" not "changed"), lowercase first letter, no trailing periodExamples:
docs(README): add build setup steps for submodules
fix(ios/camera): correct preview orientation on rotation
ONLY add a body when the header alone isn't enough for a reviewer:
Fixes #<issue> / Closes #<issue>BREAKING CHANGE: followed by a description and migration pathA commit that reverts another begins with revert: followed by the reverted header. The body states This reverts commit <hash>.
Only add a Co-Authored-By trailer when Claude actually wrote the code being committed. If the user wrote the changes themselves (and Claude is just committing), do not add it.
Build a feature end-to-end (GitHub issue or free-text → plan → implement → PR), OR plan one read-only with `--investigate`. Add `--auto` to run unattended (never asks; build stops at a draft PR). Use anytime you need to build a feature, or to plan one ahead without writing code.
Ensure you're on a correct working branch off up-to-date main before planning or editing — starting from a GitHub issue when one is in play.
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
SOC 직업 분류 기준
