cp

Name: cp
Author: dgk-dev

51stars12forks

How to install cp?

dgk-dev/dgk-gpt/cp

$npx -y skills add dgk-dev/dgk-gpt --skill cp

Installs into the current project.

Summary

Local verify-commit-push wrapper for Codex. Use only when the user explicitly says /cp or clearly asks to finish the current work by running the relevant local checks, staging intended files explicitly, committing on the current branch, and pushing. This workflow may commit dir

Files · 1

View on GitHub

SKILL.md

1	# Cp
2
3	Use this as a thin finish mode after implementation is done.
4
5	`cp` is the local gate before push: verify first, then commit and push the intended changes on the current branch.
6
7	## Default Flow
8
9	1. Inspect:
10	- `git status`
11	- current branch
12	- intended files for this task
13	- recent commit message style if needed
14	2. Run the closest local verification to the repo's normal safety checks before committing.
15	- Prefer repo-native commands over invented ones.
16	- Prefer the narrowest safe checks first: changed-file lint/format checks, affected package tests, or targeted builds.
17	- If the repo's only reliable gate is broader, run the broader command.
18	3. If a broad local check fails because of unrelated dirty files outside the intended change set, stop and report that clearly instead of fixing or staging those unrelated files.
19	4. Stage only the intended files explicitly.
20	5. If a commit message was not provided, generate a concise conventional commit message that matches the repo style.
21	6. Commit on the current branch.
22	- Committing directly to `main` or `master` is allowed when that is the repo or user's chosen workflow.
23	- If the repo explicitly requires short-lived branches, follow that instead.
24	7. Push the current branch.
25	- If upstream is missing, push with upstream tracking.
26
27	## Rules
28
29	- Never use `git add .`, `git add -A`, or similar broad staging.
30	- Never commit unrelated local changes from other tasks or sessions.
31	- Never commit secrets, `.env` files, credentials, or generated noise by accident.
32	- Never silently skip verification; state what ran and what was skipped.
33	- Never force push unless the user explicitly asks for it.
34	- Do not create or require a PR unless the user explicitly asks for one.
35
36	## Good Targets
37
38	- "/cp"
39	- "커밋하고 푸시해줘"
40	- "메인에 올려"
41	- "이제 검증하고 바로 푸시해"
42
43	## Avoid
44
45	- Do not use this for "just commit" or "just push" if the user clearly asked for only one of those actions.
46	- Do not infer permission to push a different branch than the current one.
47	- Do not hide skipped or excluded files; mention them briefly if they matter.
48
49	## Finish
50
51	Return:
52	- branch pushed
53	- verification run or skipped
54	- commit message
55	- commit hash
56	- intentionally excluded files if any

People who liked this also viewed

6 picks

Type

cp

51stars12forks

View on GitHub

How to install cp?

dgk-dev/dgk-gpt/cp

$npx -y skills add dgk-dev/dgk-gpt --skill cp

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Cp
2
3	Use this as a thin finish mode after implementation is done.
4
5	`cp` is the local gate before push: verify first, then commit and push the intended changes on the current branch.
6
7	## Default Flow
8
9	1. Inspect:
10	- `git status`
11	- current branch
12	- intended files for this task
13	- recent commit message style if needed
14	2. Run the closest local verification to the repo's normal safety checks before committing.
15	- Prefer repo-native commands over invented ones.
16	- Prefer the narrowest safe checks first: changed-file lint/format checks, affected package tests, or targeted builds.
17	- If the repo's only reliable gate is broader, run the broader command.
18	3. If a broad local check fails because of unrelated dirty files outside the intended change set, stop and report that clearly instead of fixing or staging those unrelated files.
19	4. Stage only the intended files explicitly.
20	5. If a commit message was not provided, generate a concise conventional commit message that matches the repo style.
21	6. Commit on the current branch.
22	- Committing directly to `main` or `master` is allowed when that is the repo or user's chosen workflow.
23	- If the repo explicitly requires short-lived branches, follow that instead.
24	7. Push the current branch.
25	- If upstream is missing, push with upstream tracking.
26
27	## Rules
28
29	- Never use `git add .`, `git add -A`, or similar broad staging.
30	- Never commit unrelated local changes from other tasks or sessions.
31	- Never commit secrets, `.env` files, credentials, or generated noise by accident.
32	- Never silently skip verification; state what ran and what was skipped.
33	- Never force push unless the user explicitly asks for it.
34	- Do not create or require a PR unless the user explicitly asks for one.
35
36	## Good Targets
37
38	- "/cp"
39	- "커밋하고 푸시해줘"
40	- "메인에 올려"
41	- "이제 검증하고 바로 푸시해"
42
43	## Avoid
44
45	- Do not use this for "just commit" or "just push" if the user clearly asked for only one of those actions.
46	- Do not infer permission to push a different branch than the current one.
47	- Do not hide skipped or excluded files; mention them briefly if they matter.
48
49	## Finish
50
51	Return:
52	- branch pushed
53	- verification run or skipped
54	- commit message
55	- commit hash
56	- intentionally excluded files if any

People who liked this also viewed

6 picks

Type