atproto Thingiverse but good
PM-38: fixed skill contents for clarity
+11
-11
+7
-7
.polytoken/skills/jira-solo-tasker-execute/SKILL.md
+7
-7
.polytoken/skills/jira-solo-tasker-execute/SKILL.md
···
48
48
49
49
This workflow uses jj workspaces, not Git worktrees. Do not use `.worktrees/`, `git -C .worktrees`, `git merge --squash`, or `.merge-lock` unless the project explicitly overrides this skill.
50
50
51
-
First inspect project instructions for a workspace wrapper. If one exists, use it. Otherwise use generic jj commands. After creating or entering the workspace, always start a fresh change with `jj new -m ...` before editing; otherwise work may be smushed into the current jj change.
51
+
First inspect project instructions for a workspace wrapper. If one exists, use it. Otherwise use generic jj commands. After creating or entering the workspace, always start a fresh change with `jj new -m ...` or describe an existing empty change with `jj desc -m ...` before editing; otherwise work may be smushed into the current jj change.
52
52
53
53
Suggested generic flow:
54
54
···
57
57
jj workspace list
58
58
workspace_path="$(dirname "$root")/<workspace-name>"
59
59
jj workspace add "$workspace_path" -r @
60
-
cd "$workspace_path" && jj new -m "<ticket-key>: <summary>"
60
+
cd "$workspace_path" && jj desc -m "<ticket-key>: <summary>"
61
61
```
62
62
63
63
Important shell rule: every shell call starts fresh. Use the absolute workspace path from setup for every workspace command; do not rely on relative paths like `../<workspace-name>`, and do not assume a previous `cd` persisted.
···
66
66
cd "$workspace_path" && <command>
67
67
```
68
68
69
-
For file tools, use paths in the active project checkout unless the harness has permission to access the sibling workspace. If file tools cannot write the sibling workspace safely, stop and ask whether to continue in the current checkout or adjust permissions.
69
+
For file tools, use absolute paths, never relative paths. If file tools cannot write the sibling workspace safely, stop and ask whether to continue in the current checkout or adjust permissions.
70
70
71
71
### 3. Track todos around the whole workflow
72
72
73
73
Make sure the todo list covers:
74
74
75
75
- Jira claim verified;
76
-
- jj workspace created/entered and fresh ticket change started with `jj new`;
76
+
- jj workspace created/entered and fresh ticket change started with `jj desc`;
77
77
- implementation;
78
78
- formatting/build/tests;
79
79
- implementation review loop;
···
100
100
101
101
Run the configured reviewer set. Default panel:
102
102
103
-
- `general-purpose` with `model_override` `codex/gpt-5.5(high)`
104
-
- `general-purpose` with `model_override` `anthropic/claude-opus-4-8(medium)`
105
-
- `general-purpose` with `model_override` `zai/glm-5.2(max)`
103
+
- `code-reviewer` with `model_override` `codex/gpt-5.5(high)`
104
+
- `code-reviewer` with `model_override` `anthropic/claude-opus-4-8(medium)`
105
+
- `code-reviewer` with `model_override` `zai/glm-5.2(max)`
106
106
107
107
Ask reviewers for Critical/High/Medium/Low findings, with evidence and suggested fixes.
108
108
+4
-4
.polytoken/skills/jira-solo-tasker-plan/SKILL.md
+4
-4
.polytoken/skills/jira-solo-tasker-plan/SKILL.md
···
95
95
- state that the ticket is already In Progress and execute must verify the claim, not re-claim blindly;
96
96
- specify a concrete jj workspace name and bookmark name derived from the ticket, using the form `pm-<number>-<short-description>` with at most three kebab-case summary words;
97
97
- direct execute to create or enter a jj workspace for the ticket, not a Git worktree;
98
-
- include todos around the implementation: verify Jira state, create/enter jj workspace, implement, run formatting/tests, run the review loop, describe/squash the jj change as appropriate, move Jira to In Review, wait for operator acceptance, then move Jira to Done;
98
+
- include todos around the implementation: verify Jira state, create/enter jj workspace, implement, run formatting/tests, run the review loop, describe/squash the jj change as appropriate, move Jira to In Review, wait for operator acceptance, merge (usually via rebase) if approved, then move Jira to Done;
99
99
- encode the shared review gate: run the configured reviewer set, fix or rebut every Critical/High finding with evidence, and re-run targeted review until zero unrebutted Critical/High findings remain;
100
100
- include final reporting expectations: restate the ticket key and summary, summarize changes, list validation performed, and give concrete operator test advice.
101
101
···
103
103
104
104
Use jj terminology consistently:
105
105
106
-
- workspace: isolated checkout created with `jj workspace add` or the project’s configured wrapper;
106
+
- workspace: isolated checkout created with the project’s configured workspace creation wrapper or `jj workspace add`;
107
107
- change: rename the change with the right context for the ticket work with `jj desc -m "<ticket-key>: <summary>"` before any edits;
108
108
- bookmark: optional named ref for pushing/sharing, normally the same slug as the workspace.
109
109
110
110
Do not mention Git worktrees, `.worktrees/`, `git merge --squash`, or `.merge-lock` unless the current project explicitly uses those. This workflow defaults to jj workspaces.
111
111
112
-
If the repo has a project wrapper for workspaces, cite it. Otherwise specify generic jj commands and make execution verify them. The handoff must require a fresh change with `jj new -m ...` before any edits; `jj describe` is only for updating an already-isolated change later.
112
+
If the repo has a project wrapper for workspaces, cite it. Otherwise specify generic jj commands and make execution verify them. The handoff will start on a fresh change after workspace creation, and individual internal tasks should use `jj new -m` to create new, labeled changes before starting a chunk of work; `jj describe` is only for updating an already-isolated change later.
113
113
114
114
```sh
115
115
root="$(jj workspace root)"
116
116
workspace_path="$(dirname "$root")/<workspace-name>"
117
117
jj workspace add "$workspace_path" -r @
118
-
cd "$workspace_path" && jj new -m "<ticket-key>: <summary>" # optional after this: jj bookmark create <workspace-name> -r @
118
+
cd "$workspace_path" && jj desc -m "<ticket-key>: <summary>" # optional after this: jj bookmark create <workspace-name> -r @
119
119
```
120
120
121
121
The exact parent directory for sibling workspaces is project policy. If not obvious, require execute to ask before creating one.