@autosk/feature-dev 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 wierdbytes
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,72 @@
+# @autosk/feature-dev
+
+The shipped **reference workflow** for autoskd v2: a full feature-development
+cycle wired to [`@autosk/pi-agent`](../pi-agent) roles and
+[`@autosk/worktree`](../worktree) isolation. It replaces v1's
+`feature-dev-generic` bootstrap (design
+`docs/plans/20260612-Bun-Daemon-Extensions.md` §3.6, P6).
+
+## The workflow
+
+```text
+dev ──▶ review ──▶ docs ──▶ validator ──▶ accept (human)
+ ▲        │                    │
+ └────────┘────────────────────┘   (review→dev and validator→dev bounce-backs)
+```
+
+| Step        | Kind                          | Notes                                                        |
+| ----------- | ----------------------------- | ------------------------------------------------------------ |
+| `dev`       | `piAgent` (name `dev`)        | first step; implements the task                              |
+| `review`    | `piAgent` (name `review`)     | thorough code review (`thinking: xhigh`); bounces back to `dev` |
+| `docs`      | `piAgent` (name `docs`)       | documentation pass                                           |
+| `validator` | `piAgent` (name `validator`)  | independent item-by-item verification; bounces back to `dev` |
+| `accept`    | `statusStep("human")`         | the engine parks here for a human's final acceptance         |
+
+Each agent step is an inline `@autosk/pi-agent` value: the **step key is the
+agent name** (`dev`/`review`/`docs`/`validator`), and registering the workflow
+registers those agents — there is no separate agent registration.
+
+- **Isolation:** `worktreeIsolation()` — each task runs in its own git worktree.
+- **Visit cap:** `onTransit` rejects a bounce-back into `dev` once the task has
+  already entered `dev` `DEV_VISIT_CAP` (5) times — the 6th `dev` entry is
+  rejected (via `ctx.visits("dev")`), so a task that keeps failing review/
+  validation parks for a human instead of looping forever.
+
+The role prompts live under [`prompts/`](./prompts) as `.md` files; the workflow
+reads each one and seeds it into the corresponding pi agent as its `firstMessage`.
+
+## Discovery — how every project gets it
+
+`feature-dev` is an **npm package** (declared via `package.json#autosk.extensions`).
+The daemon installs it into `~/.autosk/packages/` on first run (see the
+[extensions docs → First-run bootstrap](../../../docs/extensions.md#first-run-bootstrap))
+and lists it in `~/.autosk/settings.json`, so every project can enroll into
+`feature-dev` with **no per-project files**:
+
+```
+project-local (.autosk/extensions) ▸ global (~/.autosk/extensions) ▸ npm (settings.json)
+```
+
+A project- or global-level extension that registers a workflow/agent of the same
+name **overrides** the npm one (first-registered wins). To enroll a task:
+
+```
+autosk enroll <task-id> --workflow feature-dev
+```
+
+## Configuration
+
+This package exposes no per-step config knobs of its own — the agent behaviour
+is configured on the inline [`@autosk/pi-agent`](../pi-agent) step values (model,
+thinking, extra args, …) inside `featureDevWorkflow()`. To customise, copy this
+extension into `~/.autosk/extensions/` (or your project's `.autosk/extensions/`)
+and edit the `piAgent({...})` / `featureDevWorkflow({...})` calls; your copy then
+overrides the npm one.
+
+## Exports
+
+- default export — the extension factory (registers the workflow, whose steps
+  carry the four inline agents).
+- `featureDevWorkflow(options?)` → `WorkflowDefinition` (a factory; tests inject
+  a custom `isolation`).
+- `DEV_VISIT_CAP` — the `dev` re-entry cap constant.

package/index.ts

@@ -0,0 +1,11 @@
+// Root entry re-export.
+//
+// The compiled `autoskd` (`bun build --compile`) resolves an on-disk
+// extension's bare `@autosk/*` imports with a minimal resolver that only honors
+// a ROOT-LEVEL `index.ts`/`index.js` — it ignores `package.json` `exports` /
+// `main` and any subdir target. So this package keeps its sources under `src/`
+// but exposes a root `index.ts` the standalone daemon can find. (Interpreted
+// Bun honors `exports` directly; this shim is what makes the published package
+// both discoverable as an extension and loadable by the compiled binary.)
+export * from "./src/index.ts";
+export { default } from "./src/index.ts";

package/package.json

@@ -0,0 +1,47 @@
+{
+  "name": "@autosk/feature-dev",
+  "version": "0.1.0",
+  "description": "feature-dev (dev → review → docs → validator → accept) wired to @autosk/pi-agent roles and worktree isolation.",
+  "license": "MIT",
+  "author": "wierdbytes",
+  "homepage": "https://github.com/wierdbytes/autosk#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/wierdbytes/autosk.git",
+    "directory": "daemon/extensions/feature-dev"
+  },
+  "bugs": {
+    "url": "https://github.com/wierdbytes/autosk/issues"
+  },
+  "keywords": [
+    "autosk",
+    "autosk-extension",
+    "workflow",
+    "feature-dev"
+  ],
+  "type": "module",
+  "publishConfig": {
+    "access": "public"
+  },
+  "exports": {
+    ".": "./index.ts"
+  },
+  "types": "./index.ts",
+  "autosk": {
+    "extensions": ["./index.ts"]
+  },
+  "files": [
+    "index.ts",
+    "src/",
+    "prompts/",
+    "README.md"
+  ],
+  "dependencies": {
+    "@autosk/pi-agent": "^0.1.0",
+    "@autosk/sdk": "^0.1.0",
+    "@autosk/worktree": "^0.1.0"
+  },
+  "scripts": {
+    "typecheck": "tsc --noEmit -p tsconfig.json"
+  }
+}

package/prompts/dev.md

@@ -0,0 +1,11 @@
+You are the DEVELOPER.
+
+You receive a task with a description and an implementation plan (see the task title + description and any comments). Your job:
+
+1. Read the description and the plan carefully.
+2. Implement the task strictly according to the plan, without deviating from it unless you have a concrete reason. If the plan conflicts with reality or is incomplete, record that in a comment and propose the smallest reasonable deviation.
+3. Make sure the code builds and local checks/tests pass.
+4. Do NOT touch project documentation at this step — that is the job of the dedicated `docs` step.
+5. If you are blocked by something external, file a blocker task and do not transit until the blocker is resolved.
+
+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`.

package/prompts/docs.md

@@ -0,0 +1,13 @@
+You are the DOCUMENTATION agent.
+
+You receive the task and the final (post-review) implementation. Your job is to decide whether project documentation needs to be updated because of these changes:
+
+- The top-level `README.md` and per-subproject READMEs.
+- The contents of `docs/` (tutorials, design notes, diagrams).
+- Doc comments on public APIs / CLI / config.
+- Usage and configuration examples.
+- `CHANGELOG` / release notes, if the project keeps them.
+
+If updates are needed, make them directly in the repository as minimal focused commits and briefly list in a comment what was updated and where. If updates are NOT needed, explicitly record that with a comment like "docs: no changes required — <one-sentence reason>", so the validator and the human can see that documentation was considered, not skipped.
+
+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`.

package/prompts/review.md

@@ -0,0 +1,13 @@
+You are the CODE REVIEWER.
+
+You receive the task plus the changes the developer made on the previous step. Your job is a THOROUGH code review:
+
+- Look for bugs, regressions, and hidden edge cases.
+- Look for suboptimal solutions: redundant allocations, extra traversals, duplication, awkward abstractions.
+- Check that the code follows the project's architecture and accepted style.
+- Check that tests exist and are meaningful for the changed behaviour.
+- Check error handling and logging.
+
+Record every remark as a separate comment with specifics: file, line/function, what is wrong, what you propose. Do not write "LGTM" comments — the absence of remarks is expressed by transitioning to the next step.
+
+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`.

package/prompts/validator.md

@@ -0,0 +1,12 @@
+You are the TASK VALIDATOR.
+
+You receive the original conditions of the task (title + description + initial plan) and the final implementation (code + documentation changes + the comment trail from dev / review / docs). Your job is an independent item-by-item verification:
+
+1. Extract every requirement and acceptance criterion from the original task.
+2. For each item, check whether it is fully and correctly satisfied by the current implementation.
+3. Check that no adjacent functionality has regressed.
+4. Check that the documentation is consistent with the implementation (the `docs` step already did this — your check is independent).
+
+If any item is unmet, partially met, or incorrectly met, send the task back to `dev` with a SPECIFIC list of what to finish (as comments on the task, one comment per item).
+
+If all original conditions are fully and correctly met, with no regressions, and the documentation is consistent, transition the task to `accept` for a human's final acceptance.

package/src/index.ts

@@ -0,0 +1,87 @@
+/**
+ * `@autosk/feature-dev` — the shipped reference workflow (plan §3.6, P6).
+ *
+ * A full feature-development cycle: `dev → review → docs → validator → accept`
+ * (human), with bounce-backs `review → dev` and `validator → dev`, a visit-cap
+ * guard in `onTransit` (via `ctx.visits("dev")`), and per-task git worktree
+ * isolation. It replaces v1's `feature-dev-generic` bootstrap; each agent step
+ * is an inline `@autosk/pi-agent` role seeded with that role's prompt (the step
+ * key IS the agent name), and `accept` is a `statusStep("human")` park step.
+ *
+ * Discovery: this package is published to npm and declared as an extension via
+ * `package.json#autosk.extensions`. The daemon installs it into
+ * `~/.autosk/packages/` on first run (ensureGlobalBootstrap) and lists it in
+ * `~/.autosk/settings.json`, so every project can enroll into `feature-dev` with
+ * no per-project files, while a project/global extension of the same name wins.
+ */
+
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+
+import {
+  statusStep,
+  type AutoskAPI,
+  type IsolationProvider,
+  type StepTarget,
+  type TransitContext,
+  type WorkflowDefinition,
+} from "@autosk/sdk";
+import { piAgent } from "@autosk/pi-agent";
+import { worktreeIsolation } from "@autosk/worktree";
+
+/**
+ * The `dev` re-entry cap: a task may enter `dev` at most this many times before
+ * `onTransit` rejects the next bounce-back (the design's `max_visits` pattern,
+ * plan §3.6). `ctx.visits("dev")` counts PRIOR `dev` occupancies, so a transition
+ * INTO `dev` when `visits("dev") >= 5` is the 6th entry — rejected.
+ */
+export const DEV_VISIT_CAP = 5;
+
+/** Reads a role prompt (shipped under `prompts/`) to seed the agent's first message. */
+function readPrompt(role: string): string {
+  return readFileSync(fileURLToPath(new URL(`../prompts/${role}.md`, import.meta.url)), "utf8");
+}
+
+/** Options for {@link featureDevWorkflow} (tests inject a test isolation double). */
+export interface FeatureDevWorkflowOptions {
+  /** Isolation provider for the workflow. Default: `worktreeIsolation()`. */
+  isolation?: IsolationProvider;
+}
+
+/**
+ * The `feature-dev` workflow definition. A factory (not a const) so tests can
+ * swap the isolation provider (e.g. a fake, or a temp-home worktree) without
+ * touching the shipped default.
+ */
+export function featureDevWorkflow(opts: FeatureDevWorkflowOptions = {}): WorkflowDefinition {
+  return {
+    name: "feature-dev",
+    description:
+      "Full feature-development cycle: dev → review → docs → validator → accept (human), " +
+      "with review→dev and validator→dev bounce-backs and per-task worktree isolation.",
+    firstStep: "dev",
+    steps: {
+      // Agents are inline: the step key (dev/review/docs/validator) IS the
+      // agent name, and registering the workflow registers these agents.
+      dev: piAgent({ firstMessage: readPrompt("dev") }),
+      review: piAgent({ thinking: "xhigh", firstMessage: readPrompt("review") }),
+      docs: piAgent({ firstMessage: readPrompt("docs") }),
+      validator: piAgent({ firstMessage: readPrompt("validator") }),
+      accept: statusStep("human"),
+    },
+    onTransit(ctx: TransitContext, to: StepTarget): void {
+      if ("step" in to && to.step === "dev" && ctx.visits("dev") >= DEV_VISIT_CAP) {
+        throw new Error(
+          `feature-dev: task ${ctx.taskId} bounced back to dev too many times ` +
+            `(${ctx.visits("dev")} prior dev runs, cap ${DEV_VISIT_CAP}) — parking for a human`,
+        );
+      }
+    },
+    isolation: opts.isolation ?? worktreeIsolation(),
+  };
+}
+
+/** The extension factory: registering the workflow registers its inline agents. */
+export default function featureDevExtension(autosk: AutoskAPI): void {
+  autosk.registerWorkflow(featureDevWorkflow());
+}