@autosk/feature-dev 0.1.1 → 0.1.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autosk/feature-dev",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "feature-dev (dev → review → docs → validator → accept) wired to @autosk/pi-agent roles and worktree isolation.",
   "license": "MIT",
   "author": "wierdbytes",

package/prompts/dev.md

@@ -10,6 +10,8 @@ You receive a task with a description and an implementation plan (see the task t
 
 When the implementation per the plan is complete and local checks pass, hand the task off to the `review` step. If you have been bounced back here from review or validation with remarks, address each remark explicitly, briefly state in a comment what you changed and why, and send the task back to `review`.
 
+Use autosk_comment tool to write accessible comments.
+
 ## Available transitions
 
 When the step is done, call the `autosk_transit` tool exactly once with `to` set to:

package/prompts/docs.md

@@ -13,6 +13,8 @@ If updates are needed, make them directly in the repository as minimal focused c
 
 You do NOT reopen the discussion about the code itself — that is the job of `review`. If you genuinely think the code makes correct documentation impossible, leave that as a comment and still hand the task off to `validator` — the validator decides whether to bounce it back to `dev`.
 
+Use autosk_comment tool to write accessible comments.
+
 ## Available transitions
 
 When the step is done, call the `autosk_transit` tool exactly once with `to` set to:

package/prompts/review.md

@@ -12,6 +12,8 @@ Record every remark as a separate comment with specifics: file, line/function, w
 
 If there are substantive remarks the developer must address, send the task back to `dev`. If the review found no blocking issues, send the task to `docs`.
 
+Use autosk_comment tool to write accessible comments.
+
 ## Available transitions
 
 When the review is done, call the `autosk_transit` tool exactly once with `to` set to one of:

package/prompts/validator.md

@@ -61,6 +61,8 @@ Only when item-by-item validation passed, the CHANGELOG entry is in place (or ex
 
 If release-hygiene work itself fails for a reason you cannot fix in one step (e.g. `git` binary missing, repository state corrupted, `CHANGELOG.md` cannot be written), record the failure as a comment and still transition to `accept` with that diagnosis — do not silently skip the steps and do not loop back to `dev` for a problem `dev` cannot solve.
 
+Use autosk_comment tool to write accessible comments.
+
 ## Available transitions
 
 When the step is done, call the `autosk_transit` tool exactly once with `to` set to one of: