plugins/git
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request 'PR 技能自家三支腳本的路徑補上外掛目錄名，不再解到不存在的位置' (#35) from fix/pr-skill-tool-paths-resolve-to-plugin-root into develop

Browse Source 
Reviewed-on: #35
This commit was merged in pull request #35.
This commit is contained in:
admin
2026-09-04 02:46:53 +00:00
parent bc59208d67 5d3f761677
commit eedd2255b4
4 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "jsc-git", "name": "jsc-git",
"version": "0.1.5", "version": "0.1.7",
"description": "Commit 分組認可與 Push Request 建立", "description": "Commit 分組認可與 Push Request 建立",
"skills": "./skills", "skills": "./skills",
"author": { "author": {
.codex-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "jsc-git", "name": "jsc-git",
"version": "0.1.5", "version": "0.1.7",
"description": "Commit 分組認可與 Push Request 建立", "description": "Commit 分組認可與 Push Request 建立",
"skills": "./skills", "skills": "./skills",
"jsc": { "jsc": {
plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "jsc-git", "name": "jsc-git",
"version": "0.1.5", "version": "0.1.7",
"description": "Commit 分組認可與 Push Request 建立", "description": "Commit 分組認可與 Push Request 建立",
"skills": "./skills/", "skills": "./skills/",
"jsc": { "jsc": {
skills/pr/SKILL.md
+10 -8
View File
@@ -1,15 +1,17 @@
--- ---
name: pr name: pr
description: Commit all changes via jsc-git:commit, name a ladder-shaped target branch, derive the base with tools/base-branch.sh (sub-feature → feat/{feature}/main → develop → master; fix → develop → master, no level skipping), push, then open a Gitea PR with the templated description. When the branch already has an open PR, compare its title, description, and prerequisite dependency, and update only the items that differ. Use when work is ready for review, or when an open PR needs re-syncing after new commits; not for plain commits. description: Commit all changes via jsc-git:commit, name a ladder-shaped target branch, derive the base with jsc-git/tools/base-branch.sh (sub-feature → feat/{feature}/main → develop → master; fix → develop → master, no level skipping), push, then open a Gitea PR with the templated description. When the branch already has an open PR, compare its title, description, and prerequisite dependency, and update only the items that differ. Use when work is ready for review, or when an open PR needs re-syncing after new commits; not for plain commits.
--- ---
# pr — create a Push Request # pr — create a Push Request
The ladder rules live in one place only: section 「PR 分支階梯」 of `jsc-meta/references/guidelines.md`. `tools/base-branch.sh --derive` is the running implementation of that section. Read the rung a branch belongs to there; never hand-pick a base, and never restate the ladder table in this file. The ladder rules live in one place only: section 「PR 分支階梯」 of `jsc-meta/references/guidelines.md`. `jsc-git/tools/base-branch.sh --derive` is the running implementation of that section. Read the rung a branch belongs to there; never hand-pick a base, and never restate the ladder table in this file.
Every script path in this file starts with its plugin's own directory name — `jsc-git/tools/…` for this plugin's, `jsc-gitea/tools/…` and `jsc-hooks/tools/…` for the others — and is resolved against the tool root the caller supplies, never against this skill's own directory. These three scripts sit at the plugin root, not under `skills/pr/`, so a bare `tools/base-branch.sh` resolves to a path that does not exist and exits 127. That failure is worse than it looks: step 4 says never hand-pick a base, and an agent that cannot run the deriver is one step away from picking one anyway, which turns a wrong path into a PR opened against the wrong rung.
## Steps ## Steps
1. **Validate the caller's base first.** A caller may pass a base in (`jsc-sdlc:implement` passes the analysis page's source branch). Whether that base is legal depends on origin alone, not on the target branch name, so settle it before any naming work. Skip the whole step when no caller base was passed, and record "no caller base" for step 4. Otherwise run `tools/base-branch.sh {caller base}` and branch on its exit code: 1. **Validate the caller's base first.** A caller may pass a base in (`jsc-sdlc:implement` passes the analysis page's source branch). Whether that base is legal depends on origin alone, not on the target branch name, so settle it before any naming work. Skip the whole step when no caller base was passed, and record "no caller base" for step 4. Otherwise run `jsc-git/tools/base-branch.sh {caller base}` and branch on its exit code:
- 0 → keep the printed name; step 4 cross-checks it against the derived base. - 0 → keep the printed name; step 4 cross-checks it against the derived base.
- 2 (too many arguments) → the base arrived as several words. Quote it as one argument and rerun. - 2 (too many arguments) → the base arrived as several words. Quote it as one argument and rerun.
- 3 (cannot reach origin) → stop and report that origin is unreachable. Nothing downstream works without the remote. - 3 (cannot reach origin) → stop and report that origin is unreachable. Nothing downstream works without the remote.
@@ -20,12 +22,12 @@ The ladder rules live in one place only: section 「PR 分支階梯」 of `jsc-m
- Done when the script printed one branch name, or the run is recorded as having no caller base. - Done when the script printed one branch name, or the run is recorded as having no caller base.
2. Call `jsc-git:commit` to commit every file change. Tell it that `jsc-git:pr` is the caller, so it skips its own open-PR lookup — step 6 here is the only such lookup in this chain. Done when `git status --porcelain` prints nothing. 2. Call `jsc-git:commit` to commit every file change. Tell it that `jsc-git:pr` is the caller, so it skips its own open-PR lookup — step 6 here is the only such lookup in this chain. Done when `git status --porcelain` prints nothing.
3. Build the target branch name in ladder shape: 3. Build the target branch name in ladder shape:
1. Pipe the subjects of step 2's commits into `tools/pick-type.sh` (`git log --format=%s {range} | tools/pick-type.sh`), which owns the type priority order. Exit 0 → take the printed type. Exit 2 (no input) → step 2 produced no commits, so there is nothing to open a PR for; stop and report. Exit 3 (no ladder type in the input) → stop, report the subjects, and correct them to `{type}({scope}): {message}` before retrying. Done when the script printed exactly one type. 1. Pipe the subjects of step 2's commits into `jsc-git/tools/pick-type.sh` (`git log --format=%s {range} | jsc-git/tools/pick-type.sh`), which owns the type priority order. Exit 0 → take the printed type. Exit 2 (no input) → step 2 produced no commits, so there is nothing to open a PR for; stop and report. Exit 3 (no ladder type in the input) → stop, report the subjects, and correct them to `{type}({scope}): {message}` before retrying. Done when the script printed exactly one type.
2. Summarize one title from all commit messages, as a single Traditional Chinese sentence saying what this PR does. This sentence is the PR title steps 7 and 8 use; step 3.3 only borrows its meaning to build the ASCII slug. Done when one title line covers every commit in the range and reads as one Traditional Chinese sentence. 2. Summarize one title from all commit messages, as a single Traditional Chinese sentence saying what this PR does. This sentence is the PR title steps 7 and 8 use; step 3.3 only borrows its meaning to build the ASCII slug. Done when one title line covers every commit in the range and reads as one Traditional Chinese sentence.
3. Translate the feature and the title into short English phrases, then build the name with `tools/slugify.sh`. `fix` takes one call: `tools/slugify.sh fix {change phrase}` → `fix/order-export-crash`. Every other type takes two calls, feeding the first result back in as the type: `tools/slugify.sh feat {feature phrase}` → `feat/order-export`, then `tools/slugify.sh feat/order-export {sub-feature phrase}` → `feat/order-export/report-filter`. Done when the name has the shape its ladder row requires; exit 2 (non-ASCII input) or exit 3 (empty slug) → re-translate into an English phrase and retry, never hand-build the branch name. 3. Translate the feature and the title into short English phrases, then build the name with `jsc-git/tools/slugify.sh`. `fix` takes one call: `jsc-git/tools/slugify.sh fix {change phrase}` → `fix/order-export-crash`. Every other type takes two calls, feeding the first result back in as the type: `jsc-git/tools/slugify.sh feat {feature phrase}` → `feat/order-export`, then `jsc-git/tools/slugify.sh feat/order-export {sub-feature phrase}` → `feat/order-export/report-filter`. Done when the name has the shape its ladder row requires; exit 2 (non-ASCII input) or exit 3 (empty slug) → re-translate into an English phrase and retry, never hand-build the branch name.
- The name is the only input step 6's lookup and the description draft need. Start both the moment this step ends, and run them alongside steps 4 and 5; neither waits for the push. - The name is the only input step 6's lookup and the description draft need. Start both the moment this step ends, and run them alongside steps 4 and 5; neither waits for the push.
4. Resolve the base branch: 4. Resolve the base branch:
- Run `tools/base-branch.sh --derive {target branch}`. Exit 0 → the script printed one branch name. - Run `jsc-git/tools/base-branch.sh --derive {target branch}`. Exit 0 → the script printed one branch name.
- Exit 2 (too many arguments) → the branch name arrived as several words. Quote it as one argument and rerun. - Exit 2 (too many arguments) → the branch name arrived as several words. Quote it as one argument and rerun.
- Exit 3 (cannot reach origin) → stop and report that origin is unreachable. - Exit 3 (cannot reach origin) → stop and report that origin is unreachable.
- Exit 4, 5 or 6 → these belong to caller mode. Seeing one means the `--derive` flag was dropped. Rerun with the flag. - Exit 4, 5 or 6 → these belong to caller mode. Seeing one means the `--derive` flag was dropped. Rerun with the flag.
@@ -42,7 +44,7 @@ The ladder rules live in one place only: section 「PR 分支階梯」 of `jsc-m
- Any other non-zero → treat it as exit 4 and stop. - Any other non-zero → treat it as exit 4 and stop.
- Done when either the PR number plus its title, base and body are held, or exit 3 confirmed the branch has no open PR. - Done when either the PR number plus its title, base and body are held, or exit 3 confirmed the branch has no open PR.
7. Create the PR, then hang its prerequisite on it. Run `jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {target branch} {base branch} "{branch name}" {description file}`. Ask the user to confirm before this call runs. 7. Create the PR, then hang its prerequisite on it. Run `jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {target branch} {base branch} "{branch name}" {description file}`. Ask the user to confirm before this call runs.
- Title = step 3.2's summary: one Traditional Chinese sentence saying what this PR does. Never pass the branch name as the title. A branch name and a title carry different jobs — the branch name is a machine-readable ASCII slug that the ladder and `tools/base-branch.sh` parse, while the title is the one line a human reads in the review list, where a column of long slugs shows who touched the repo but never what changed. The STE100 output rule in `jsc-meta/references/ste100.md` names PR titles and descriptions explicitly, and a hook enforces it; binding the title to the branch name is what put the two rules in conflict, so the title gives way to the language rule and the branch name stays ASCII per rule 4. - Title = step 3.2's summary: one Traditional Chinese sentence saying what this PR does. Never pass the branch name as the title. A branch name and a title carry different jobs — the branch name is a machine-readable ASCII slug that the ladder and `jsc-git/tools/base-branch.sh` parse, while the title is the one line a human reads in the review list, where a column of long slugs shows who touched the repo but never what changed. The STE100 output rule in `jsc-meta/references/ste100.md` names PR titles and descriptions explicitly, and a hook enforces it; binding the title to the branch name is what put the two rules in conflict, so the title gives way to the language rule and the branch name stays ASCII per rule 4.
- Write the description into a temp file first, using `templates/pr-description.md` (a Traditional Chinese template; the generated description stays in Traditional Chinese per the STE100 output rule). - Write the description into a temp file first, using `templates/pr-description.md` (a Traditional Chinese template; the generated description stays in Traditional Chinese per the STE100 output rule).
- Exit 0 → the command prints a PR URL; keep it. - Exit 0 → the command prints a PR URL; keep it.
- Exit 2 (description file not found) → write the description file, then rerun. - Exit 2 (description file not found) → write the description file, then rerun.
@@ -100,4 +102,4 @@ The ladder rules live in one place only: section 「PR 分支階梯」 of `jsc-m
1. No template section may stay empty: fill the literal 「無」 when there is no plan page, analyze page, or prerequisite PR. 1. No template section may stay empty: fill the literal 「無」 when there is no plan page, analyze page, or prerequisite PR.
2. Read the `jsc-sdlc` plan page and analyze page through `jsc-gitea:wiki`, which resolves `JSC_WIKI_REPO_PLAN` for the plan page and `JSC_WIKI_REPO_ANALYZE` for the analyze page from the inherited environment, falls back to `JSC_WIKI_REPO`, and asks only when neither is set. Each page type reads its own variable only; a page type never borrows another type's variable. Take both links from the pages read this way; the analyze link must point at the work package heading anchor. 2. Read the `jsc-sdlc` plan page and analyze page through `jsc-gitea:wiki`, which resolves `JSC_WIKI_REPO_PLAN` for the plan page and `JSC_WIKI_REPO_ANALYZE` for the analyze page from the inherited environment, falls back to `JSC_WIKI_REPO`, and asks only when neither is set. Each page type reads its own variable only; a page type never borrows another type's variable. Take both links from the pages read this way; the analyze link must point at the work package heading anchor.
3. Branch title summarization (step 3.2) and description drafting MUST run as a sub agent. The description sub agent starts right after step 3 and runs alongside steps 4 and 5, so steps 7 and 8 already hold a draft. 3. Branch title summarization (step 3.2) and description drafting MUST run as a sub agent. The description sub agent starts right after step 3 and runs alongside steps 4 and 5, so steps 7 and 8 already hold a draft.
4. Branch names are ASCII only (`a-z0-9`, `/`, `-`). Traditional Chinese phrases go through `tools/slugify.sh` first; `tools/base-branch.sh --derive` rejects anything else. PR titles and descriptions take the opposite rule: they stay Traditional Chinese per `jsc-meta/references/ste100.md`. The two never copy each other. 4. Branch names are ASCII only (`a-z0-9`, `/`, `-`). Traditional Chinese phrases go through `jsc-git/tools/slugify.sh` first; `jsc-git/tools/base-branch.sh --derive` rejects anything else. PR titles and descriptions take the opposite rule: they stay Traditional Chinese per `jsc-meta/references/ste100.md`. The two never copy each other.