You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace the Corbits-tool rewrite with Guy's GaaS implement body (TaskCreate, @greybeard, @Critique, Acknowledgment). Keep slash /implement. Tool-name mapping, including TaskList and karen to the primary, stays on native-integration.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,7 @@ parallel copies under `docs/` or `scripts/notes/`. At cut time: rename
19
19
20
20
### Changed
21
21
22
+
- Restore the implement skill body 1:1 with GaaS (TaskCreate, @greybeard, Acknowledgment). Tool-name mapping stays on native-integration. Slash /implement remains.
22
23
- Restore the typescript skill body 1:1 with GaaS. bun:test vs tap mapping lives on native-integration. user-invocable: false stays so it remains use_skill-only.
23
24
- Restore the philosophy skill body 1:1 with GaaS (including the review acknowledgment). `user-invocable: false` stays so it remains use_skill-only.
24
25
- Restore the style skill body 1:1 with GaaS (including the git-repo requirement and review acknowledgment). Non-git-folder policy stays on native-integration. `user-invocable: false` stays so it remains use_skill-only.
Copy file name to clipboardExpand all lines: plugins/corbits-skills/skills/implement/SKILL.md
+19-34Lines changed: 19 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,43 +11,39 @@ A disciplined implementation workflow that produces reviewed, verified commits.
11
11
12
12
Before using this workflow, load the `style` and `philosophy` skills. Follow their conventions throughout.
13
13
14
-
## Linear claim (when applicable)
15
-
16
-
When the work is tied to a Linear issue ID, claim it **before** greybeard / explore / build thrash: set state to "In Progress" with `mcp__linear__save_issue`. This is a hard first step. Parallel lanes each claim their own issue ID — never claim a sibling lane's ID. If Linear MCP is unavailable or the update fails, report that the issue status could not be updated; do not pretend it was claimed.
17
-
18
14
## When to Use
19
15
20
-
This is a standalone skill, loaded on request. Use it when you want a single agent to work through a series of commits with review discipline.
16
+
This is a standalone skill, loaded on request. It is not part of dispatch. Use it when you want a single agent to work through a series of commits with review discipline.
21
17
22
18
The caller defines what work to do and where the commit boundaries are. This skill defines _how_ each commit gets produced.
23
19
24
20
## Tracking Progress
25
21
26
-
Track progress with `manage_tasks`. One item per commit-sized unit.
22
+
Use `TaskCreate`, `TaskUpdate`, and `TaskList` to track progress throughout the workflow. These tools give the user real-time visibility into what you're doing.
27
23
28
24
### Initial Planning
29
25
30
-
Before starting implementation, create a `manage_tasks` item for each commit-sized unit of work from the caller's instructions:
26
+
Before starting implementation, use `TaskCreate` for each commit-sized unit of work from the caller's instructions:
31
27
32
28
-**subject**: Clear imperative description of the unit of work
33
29
-**description**: Enough context that you could pick it up cold
34
30
-**activeForm**: Present continuous form for the spinner (e.g., "Refactoring HTTP client retry logic")
35
31
36
32
### During the Per-Commit Workflow
37
33
38
-
When you begin a unit of work, mark its `manage_tasks` item in progress. As you move through the workflow steps, update the task's `activeForm` to reflect which step you're in:
34
+
When you begin a unit of work, mark its task `in_progress` with `TaskUpdate`. As you move through the workflow steps, update the task's `activeForm` to reflect which step you're in:
39
35
40
36
-**Step 1**: "Reviewing approach with Greybeard: {subject}"
41
37
-**Step 2**: "Implementing: {subject}"
42
38
-**Step 3**: "Running build gate: {subject}"
43
39
-**Step 4**: "Committing: {subject}"
44
-
-**Step 5**: "Running critic loop: {subject}"
40
+
-**Step 5**: "Running Critique loop: {subject}"
45
41
46
42
When the commit lands and Critique is clean, mark the task `completed`.
47
43
48
44
### Discovered Work
49
45
50
-
If new work surfaces during implementation (Greybeard suggests a preparatory refactor, Critique reveals a missing edge case that warrants its own commit), append a `manage_tasks` item and work it through the full per-commit workflow.
46
+
If new work surfaces during implementation (Greybeard suggests a preparatory refactor, Critique reveals a missing edge case that warrants its own commit), create a new task with `TaskCreate` and work it through the full per-commit workflow.
51
47
52
48
## Workflow Per Commit
53
49
@@ -73,7 +69,7 @@ Before writing any code, describe your implementation approach to Greybeard and
73
69
- You don't need to agree with every suggestion, but you need a reason to disagree
74
70
- Once you're aligned on approach, move to Step 2
75
71
76
-
Use `spawn_agent(agent="greybeard")`, then `wait_agents`, for this step.
72
+
Use the `@greybeard` subagent for this step.
77
73
78
74
### Step 2: Implement and Test
79
75
@@ -116,15 +112,15 @@ Update `activeForm` to "Committing: {subject}".
116
112
117
113
Create the commit. Follow the commit message conventions from the `style` skill. Include the test in the same commit as the implementation — they are one logical unit of work.
118
114
119
-
### Step 5: Critic loop
115
+
### Step 5: Critique Loop
120
116
121
-
Update `activeForm` to "Running critic loop: {subject}".
117
+
Update `activeForm` to "Running Critique loop: {subject}".
122
118
123
-
Ask critic to review the committed change.
119
+
Ask Critique to review the committed change.
124
120
125
121
**How to run:**
126
122
127
-
1. Spawn `spawn_agent(agent="critic")`, then `wait_agents`, and ask it to review the output of `git show HEAD`. Include the intent from Step 1 (what the change is meant to accomplish and the approach agreed with Greybeard) so Critique can evaluate whether the implementation matches the plan, not just surface-level quality. Tell critic to limit its findings to the scope of the current commit -- pre-existing issues in touched files are out of scope.
123
+
1. Spawn the `@critique` subagent and ask it to review the output of `git show HEAD`. Include the intent from Step 1 (what the change is meant to accomplish and the approach agreed with Greybeard) so Critique can evaluate whether the implementation matches the plan, not just surface-level quality. Tell Critique to limit its findings to the scope of the current commit -- pre-existing issues in touched files are out of scope.
128
124
2. Read its findings
129
125
3. For each issue marked VERIFIED or HIGH confidence: fix it
130
126
4. Re-run the build gate (Step 3) to verify fixes
@@ -141,42 +137,31 @@ Ask critic to review the committed change.
141
137
142
138
If the situation calls for more elaborate history surgery, search your available skills for one whose description covers git rebase or branch-history cleanup, and load it. Re-run the build gate after the rebase completes.
143
139
144
-
6. Ask critic to review `git show HEAD` again. Re-include the original intent from Step 1 and tell it what you fixed since the last pass so it can focus on verifying the fixes and checking for new issues rather than re-reviewing the entire change from scratch.
140
+
6. Ask Critique to review `git show HEAD` again. Re-include the original intent from Step 1 and tell it what you fixed since the last pass so it can focus on verifying the fixes and checking for new issues rather than re-reviewing the entire change from scratch.
145
141
7. Repeat until Critique comes back clean or all remaining findings are acknowledged and intentional
146
142
147
143
**When to stop looping:**
148
144
149
-
-critic reports no issues
145
+
-Critique reports no issues
150
146
- Remaining findings are judgment calls you've consciously decided against, not oversights
151
147
- The build passes after the last round of fixes
152
148
153
149
### Step 6: Next
154
150
155
-
Mark the current `manage_tasks` item done. Move to the next unit of work and return to Step 1.
151
+
Mark the current task `completed` with `TaskUpdate`. Move to the next unit of work and return to Step 1.
156
152
157
153
## Guidelines
158
154
159
-
**Claim Linear work first when applicable.** When tied to a Linear issue: claim "In Progress" with `mcp__linear__save_issue` before the spawn loop. Parallel lanes claim their own IDs. If Linear MCP is unavailable, report that the issue status could not be updated.
160
-
161
-
**Close the loop.** Ship → verify → fix → re-verify.
162
-
163
-
**Do not invent a worker-count or fan-out ceiling.**
164
-
165
155
**Don't shortcut the loop.** The value is in the discipline. Skipping Greybeard "because this change is simple" or skipping Critique "because the build passes" defeats the purpose.
166
156
167
-
**Keep commits focused, but do not drop findings.** When critic surfaces something outside the current commit's scope, every finding must be assigned one of four dispositions: (a) fix in the current commit, (b) commit it separately on this branch, (c) file a new issue with concrete acceptance criteria, or (d) accept it as-is. "Out of scope" is not a disposition. "Note it for later" is not a disposition unless you also say which of (a)–(d) "later" means.
157
+
**Keep commits focused, but do not drop findings.** When Critique surfaces something outside the current commit's scope, every finding must be assigned one of four dispositions: (a) fix in the current commit, (b) commit it separately on this branch, (c) file a new issue with concrete acceptance criteria, or (d) accept it as-is. "Out of scope" is not a disposition. "Note it for later" is not a disposition unless you also say which of (a)–(d) "later" means.
168
158
169
-
**Disposition (d) always requires operator approval** — neither you nor greybeard can drop a finding on your own. For (c), the issue must be filed in this session, with its ID or URL in the status update; a promise to file it later is dropping the work. Consult the operator before choosing (c) or (d).
159
+
**Disposition (d) always requires operator approval** — neither you nor greybeard can drop a finding on your own. For (c), the issue must be filed in this session, with its ID or URL in the status update; a promise to file it later is dropping the work. If you are orchestrated by karen, route the decision through karen's section 9 procedure (consult greybeard, paste his recommendation verbatim, escalate to the operator for any "accept as-is" or any unclear answer). If you are running directly, consult the operator before choosing (c) or (d).
170
160
171
161
**Build must pass before every commit, amend, and rebase stop.** Never commit code that doesn't compile or pass tests. Fix build failures first, then commit, amend, or continue the rebase.
172
162
173
-
**Greybeard is for approach, critic is for execution.** Greybeard reviews your plan before you write code. critic reviews your code after you write it. Don't conflate the two.
174
-
175
-
## When Shipping a PR
163
+
**Greybeard is for approach, Critique is for execution.** Greybeard reviews your plan before you write code. Critique reviews your code after you write it. Don't conflate the two.
176
164
177
-
This skill produces commits. When the work is tracked in Linear and ends in a pull request, hand off to `linear-issue-workflow` for Phase 6–7. Non-negotiable bar (also encoded in `review` and `pull-request-review`):
165
+
## Acknowledgment
178
166
179
-
1.**Post a real GitHub PR review** with `gh pr review` after the PR exists — not a one-line self-review issue comment.
180
-
2.**Multi-persona when used:** if critic / greybeard / OSS-quality lenses ran with substance, each posts its own labeled review. Primary owns approve/request-changes; secondary lenses comment only.
181
-
3.**No AI slop in review bodies:** lens · verdict, one present-tense line on what the branch does, `path:line` findings. No filler, journey narration, or "LGTM" alone.
182
-
4.**Linear: In Review at ready-for-review PR-open; checkboxes and Done post-merge + green CI only.** The Phase 6–7 handoff in `linear-issue-workflow` must move the issue to In Review when the PR is ready for review. Flip boxes and mark Done only when `main` actually has the outcome. Never Done on open PR.
167
+
After reviewing this skill, state: "I have reviewed the implement skill and am ready to follow the commit workflow."
`intent="general"` is not a Corbits spawn. Use a closed director id.
38
39
39
40
Slash names that differ from GaaS skill ids: `/review` is GaaS `code-review`; `/create-issue` is GaaS `linear-create`. Keep those Corbits names.
40
41
42
+
When GaaS implement says you are orchestrated by karen, that is the Corbits primary (Skywalker). Route those disposition decisions through the primary, not a worker.
43
+
41
44
## Linear claim-first
42
45
43
46
When the work tracks a Linear issue and Linear MCP is available: set the issue to In Progress before explore/build thrash. Parallel lanes claim their own IDs. When a PR is ready for review, move the issue to In Review — never Done at PR-open. If Linear MCP is unavailable, report that status could not be updated.
0 commit comments