@astrosheep/keiyaku 4.6.7 → 4.6.9

package/build/plugins/codex/skills/keiyaku-debt/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: keiyaku-debt
+description: >-
+  Must read when recording confirmed unresolved work or dependencies in Debts.
+---
+
+# Keiyaku Debt
+
+A Debt records confirmed unresolved work and its relationships. Debt is an
+independent product; it is not a Contract, Arc, Akuma, permission, acceptance
+boundary, or fulfillment lifecycle.
+
+## 1. When To Use A Debt
+
+Use a Debt when confirmed unresolved work or a dependency must outlive the
+current conversation. Keep plans and execution progress in reasoning or session
+notes instead.
+
+- Use a `kei` for one independently acceptable outcome.
+- Use an Arc for a chapter inside one `kei`.
+- Use a Debt for confirmed unresolved work and its prerequisites.
+- Do not create a Debt just to mirror a `kei`.
+
+A Debt may exist without a Contract. Associating a Debt with a `kei` does not
+transfer the Contract's holder, acceptance, or lifecycle to the Debt.
+
+## 2. Relationships And Parallel Work
+
+Independent work may proceed in parallel when its dependencies allow it.
+Debt records no execution-progress state.
+
+Use the relationships for their actual meanings:
+
+- `needs` means this Debt must wait for another Debt to become terminal.
+- `parent` groups decomposition; it does not create a dependency.
+- `supersedes` points to work replaced by this Debt.
+- `relates` records a connection without affecting readiness.
+
+Only `needs` orders work. Do not add it because Debts touch the same Region or
+because one Debt is related to another. A terminal Debt releases its dependents.
+
+## 3. Debt Commands
+
+Create and inspect Debts:
+
+```bash
+keiyaku debt add "<title>"
+keiyaku debt add "<title>" --priority 1 --needs <debt-id>
+keiyaku debt show <debt-id>
+keiyaku debt ls
+keiyaku debt ready
+keiyaku debt blocked
+keiyaku debt tree <debt-id>
+keiyaku debt doctor
+```
+
+Use complete Debt IDs for targeted commands. `ls`, `ready`, and `blocked` use
+the current namespace; use `--world` to inspect the complete Debt world.
+
+Close work:
+
+```bash
+keiyaku debt done <debt-id>...
+keiyaku debt drop <debt-id>... --note "<reason>"
+```
+
+Use `done` when the Debt is complete. Use `drop` when it is no longer owed.
+Both terminal states release dependent Debts. Unresolved `needs` appear in
+`blocked`; open work with all prerequisites terminal appears in `ready`.
+
+Update a Debt without changing its lifecycle:
+
+```bash
+keiyaku debt update <debt-id> --title "<title>"
+keiyaku debt update <debt-id> --body "<body>"
+keiyaku debt update <debt-id> --needs <debt-id>
+```
+
+## 4. After Creating A Debt
+
+Read the returned Debt identity. Then:
+
+1. Add or remove relationships when the confirmed prerequisites change.
+2. Mark completed work `done`, or work no longer owed `drop` with a reason.
+3. Use `ready`, `blocked`, `tree`, or `doctor` to inspect the current ledger.
+
+Debt records unresolved work. It does not perform the work, claim acceptance,
+assign a holder, or decide what a Contract may accept.
+
+Read `keiyaku-bind` for Contract authoring and `keiyaku-workflow` for Contract
+lifecycle.

package/build/plugins/codex/skills/keiyaku-workflow/SKILL.md

@@ -33,7 +33,7 @@ to create parallel work.
 
 - Separate `kei`s have independently acceptable outcomes.
 - An Arc is a chapter of one `kei`; it is not separately accepted.
-- A Task stores decomposition or dependencies that outlive this conversation.
+- A Debt records confirmed unresolved work and its dependencies.
 
 Use `after` only when one `kei` requires another to be accepted first. Ordinary
 overlap is not a dependency.
@@ -101,7 +101,7 @@ authority.
 | Role | Grant at birth | Return |
 | --- | --- | --- |
 | Holder | The actions the delegated loop will perform; include `contract.review` when this holder will review. Commission with the `kei`, current Arc when one exists, appointed worktree, and holder duties. | Acceptance or abandonment, with receipts. |
-| Deliverer | The ordinary baseline: every Task mutation, Contract audit and delivery, and Akuma management. `keiyaku -C <repo> call worker --alias @deliverer --contract <kei/...> --workdir <appointed-path> -` | The delivery receipt. |
+| Deliverer | The ordinary baseline: every Debt mutation, Contract audit and delivery, and Akuma management. `keiyaku -C <repo> call worker --alias @deliverer --contract <kei/...> --workdir <appointed-path> -` | The delivery receipt. |
 | Reviewer | `--allowed contract.review`: `keiyaku -C <repo> call review-akuma --alias @reviewer --contract <kei/...> --workdir <appointed-path> --allowed contract.review -` | The verdict receipt. Without the grant, `not-allowed` refuses and no verdict is recorded. |
 
 An Archetype's explicit allowed set replaces the ordinary baseline; check

package/build/plugins/opencode/index.js

@@ -1,7 +1,7 @@
 import { readFile } from "node:fs/promises";
 import { fileURLToPath } from "node:url";
 
-const skills = ["keiyaku", "keiyaku-task", "keiyaku-bind", "keiyaku-workflow", "keiyaku-akuma", "keiyaku-babysit"].map(
+const skills = ["keiyaku", "keiyaku-debt", "keiyaku-bind", "keiyaku-workflow", "keiyaku-akuma", "keiyaku-babysit"].map(
   (name) => fileURLToPath(new URL(`./skills/${name}/SKILL.md`, import.meta.url)),
 );
 

package/build/plugins/opencode/skills/keiyaku/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: keiyaku
 description: >-
-  Keiyaku is a CLI that records plans, writes handoff terms for deliveries,
+  Keiyaku is a CLI that records unresolved work, writes handoff terms for deliveries,
   and calls delegates. Use this skill when you need to figure out which
   Keiyaku skill or command to reach for.
 ---
@@ -10,8 +10,8 @@ description: >-
 
 ## Model
 
-Keiyaku is three independent pillars, not a bundle: **Task** remembers plans
-and dependencies, **Contract** makes acceptance standing and auditable,
+Keiyaku is three independent pillars, not a bundle: **Debt** records unresolved
+work and dependencies, **Contract** makes acceptance standing and auditable,
 **Akuma** invokes capability. Use any one alone; combine them only when the
 work calls for it. Behind every Contract in flight there is one holder of its
 fulfillment loop — whoever turns intent into commissions and returns into
@@ -23,9 +23,8 @@ equally. See `keiyaku-workflow` for the loop, `keiyaku-bind` for authoring,
 ## Quick Start
 
 ```bash
-keiyaku -C <repo> task add "title"
-keiyaku -C <repo> task start <task-id>
-keiyaku -C <repo> bind [--task <task-id>] -
+keiyaku -C <repo> debt add "title"
+keiyaku -C <repo> bind [--debt <debt-id>] -
 keiyaku -C <repo> status
 keiyaku -C <repo> deliver [<contract>|@<contract>]
 keiyaku -C <repo> review [<contract>|@<contract>] --satisfied

package/build/plugins/opencode/skills/keiyaku-akuma/SKILL.md

@@ -113,7 +113,7 @@ complete grammar.
 ## JavaScript automation
 
 Use [Automation With The Akuma API](references/automation.md) for a
-task-specific JavaScript coordinator, structured answers, or multi-worker
+debt-specific JavaScript coordinator, structured answers, or multi-worker
 orchestration. The CLI is enough for one commission and its return. A
 prompt-free birth followed by one input-bound ask uses the same identity:
 

package/build/plugins/opencode/skills/keiyaku-akuma/references/automation.md

@@ -1,15 +1,15 @@
 # Automation With The Akuma API
 
 Use this guide when the work calls for a program that coordinates agents,
-not a sequence of manual CLI calls. Start with the current task, invent an
+not a sequence of manual CLI calls. Start with the current debt, invent an
 appropriate algorithm, write it as ordinary JavaScript, and run it. Treat
 examples here as material to adapt, not a mandatory workflow or a new product
 API. Product semantics remain owned by the repository's `docs/` chapters.
 
-## Write A Harness For This Task
+## Write A Harness For This Debt
 
 A dynamic workflow is more than parallel delegation. The flagship writes a
-small, task-specific program whose variables hold intermediate answers and
+small, debt-specific program whose variables hold intermediate answers and
 whose control flow performs comparisons, branching, filtering, experiments,
 and verification. Only the useful final result needs to enter the flagship's
 context. The program itself is an inspectable, reusable artifact.
@@ -21,7 +21,7 @@ The useful combination is:
 - JavaScript holds the plan, candidate sets, budgets, and stopping conditions.
 - AkuId lets a later step reconnect to an existing worker when continuity helps.
 
-Reach for this when the task needs many independent judgments, repeated
+Reach for this when the debt needs many independent judgments, repeated
 experiments, adversarial checking, or a reusable orchestration artifact. A
 single bounded question usually needs one worker, not a panel.
 
@@ -30,7 +30,7 @@ single bounded question usually needs one worker, not a panel.
 Do not stop at "one reviewer per directory." Choose an algorithm around the
 judgment you need:
 
-| Task | Task-specific orchestration |
+| Debt | Debt-specific orchestration |
 | --- | --- |
 | Find a name or visual direction with taste | Generate candidates from deliberately different directions; anonymize them; run pairwise judging agents; retain finalists and rejection reasons; generate another round against the discovered weaknesses. |
 | Rank a large qualitative backlog | Use agents as comparators, with code maintaining buckets or tournament brackets. Repeat disputed comparisons. Do not assume subjective preferences are transitive or absolute scores calibrated. |
@@ -118,7 +118,7 @@ unknowns in the requested value; acceptance still needs a suitable judge.
 The following continues the script above. One agent determines the claim set;
 code fans out verification with bounded concurrency; only supported claims go
 to fresh skeptics. The program keeps every item's success or failure. Adapt
-the prompts, schemas, routing, and selection to the task rather than always
+the prompts, schemas, routing, and selection to the debt rather than always
 running this exact pipeline.
 
 ```js
@@ -206,7 +206,7 @@ console.log(JSON.stringify(
 
 This script has a bounded work set (12 claims), at most two item pipelines in
 flight, and at most two fresh judges per claim. Each item advances to its own
-next stage without waiting for unrelated items. A different task might need
+next stage without waiting for unrelated items. A different debt might need
 pairwise comparisons, experiment queues, or adaptive sampling instead.
 
 ## Failure, Control, And Reconnection
@@ -264,6 +264,6 @@ observations for program control, not delivery notifications as receipts.
 
 These are sources of techniques, not Keiyaku runtime guarantees:
 
-- [A harness for every task: dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)
+- [A harness for every debt: dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-debt-dynamic-workflows-in-claude-code)
 - [Orchestrate subagents at scale with dynamic workflows](https://platform.claude.com/cookbook/claude-agent-sdk-08-dynamic-workflows)
 - [Claude Code workflow runtime](https://code.claude.com/docs/en/workflows)

package/build/plugins/opencode/skills/keiyaku-babysit/SKILL.md

@@ -59,7 +59,7 @@ does not move without you.
 
 ## What Babysitting Never Owns
 
-Commands and semantics belong to task, bind, workflow, and akuma. Acceptance
+Commands and semantics belong to debt, bind, workflow, and akuma. Acceptance
 belongs to the Contract's journal and its Reviewer's testimony. The question
 belongs to whoever commissioned it. Babysitting decides only when you look and
 what you check next.

package/build/plugins/opencode/skills/keiyaku-bind/SKILL.md

@@ -59,14 +59,14 @@ writing one broad Objective around unrelated fixes.
 
 - Use an Arc only for a chapter inside that one acceptance boundary; an Arc is
   not separately accepted and MUST NOT substitute for an independent `kei`.
-- Use a Task for decomposition or dependency memory that must outlive the
-  current conversation.
+- Use a Debt for confirmed unresolved work and dependencies that must outlive
+  the current conversation.
 
 A `kei` owns one independently acceptable outcome and its delivery lifecycle. A
-Task records decomposition or dependency memory; it may exist without a `kei`,
+Debt records confirmed unresolved work; it may exist without a `kei`,
 and it does not create a second acceptance or lifecycle. Associate a `kei` with
-an existing Task only when that Task has real scheduling or dependency value.
-Do not create a Task just to mirror a `kei`.
+an existing Debt only when the delivery actually settles that unresolved work.
+Do not create a Debt just to mirror a `kei`.
 
 ### Parallel Work
 
@@ -74,7 +74,7 @@ Parallel work is the default.
 
 - Bind and advance independent `kei`s in parallel. Each has its own acceptance
   boundary and holder.
-- Within one `kei`, run independent Tasks or Arc chapters in parallel whenever
+- Within one `kei`, run independent Debts or Arc chapters in parallel whenever
   their work can proceed independently. They converge on the one acceptance
   boundary, which the holder owns.
 
@@ -162,10 +162,10 @@ prospective candidate. Without `verified`, no verb runs Verification and the
 section is inert document text. `reviewed` independently requires review
 evidence. Selected gates are checked at placement.
 
-For an existing Task with real scheduling or dependency value:
+For an existing Debt that this delivery settles:
 
 ```bash
-keiyaku -C <repo> bind --task <task/...> - < CONTRACT.md
+keiyaku -C <repo> bind --debt <debt/...> - < CONTRACT.md
 ```
 
 For a real logical dependency between Contracts:
@@ -204,7 +204,7 @@ waiting, the stated prerequisites remain; do not bind a duplicate Contract.
 
 The holder now owns the lifecycle:
 
-1. Start the work directly or delegate Tasks, Arc chapters, Akumas, or Contract roles.
+1. Start the work directly or delegate Debts, Arc chapters, Akumas, or Contract roles.
 2. Run independent work in parallel and let it converge on the one acceptance
    boundary.
 3. Prepare and deliver the candidate.

package/build/plugins/opencode/skills/keiyaku-debt/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: keiyaku-debt
+description: >-
+  Must read when recording confirmed unresolved work or dependencies in Debts.
+---
+
+# Keiyaku Debt
+
+A Debt records confirmed unresolved work and its relationships. Debt is an
+independent product; it is not a Contract, Arc, Akuma, permission, acceptance
+boundary, or fulfillment lifecycle.
+
+## 1. When To Use A Debt
+
+Use a Debt when confirmed unresolved work or a dependency must outlive the
+current conversation. Keep plans and execution progress in reasoning or session
+notes instead.
+
+- Use a `kei` for one independently acceptable outcome.
+- Use an Arc for a chapter inside one `kei`.
+- Use a Debt for confirmed unresolved work and its prerequisites.
+- Do not create a Debt just to mirror a `kei`.
+
+A Debt may exist without a Contract. Associating a Debt with a `kei` does not
+transfer the Contract's holder, acceptance, or lifecycle to the Debt.
+
+## 2. Relationships And Parallel Work
+
+Independent work may proceed in parallel when its dependencies allow it.
+Debt records no execution-progress state.
+
+Use the relationships for their actual meanings:
+
+- `needs` means this Debt must wait for another Debt to become terminal.
+- `parent` groups decomposition; it does not create a dependency.
+- `supersedes` points to work replaced by this Debt.
+- `relates` records a connection without affecting readiness.
+
+Only `needs` orders work. Do not add it because Debts touch the same Region or
+because one Debt is related to another. A terminal Debt releases its dependents.
+
+## 3. Debt Commands
+
+Create and inspect Debts:
+
+```bash
+keiyaku debt add "<title>"
+keiyaku debt add "<title>" --priority 1 --needs <debt-id>
+keiyaku debt show <debt-id>
+keiyaku debt ls
+keiyaku debt ready
+keiyaku debt blocked
+keiyaku debt tree <debt-id>
+keiyaku debt doctor
+```
+
+Use complete Debt IDs for targeted commands. `ls`, `ready`, and `blocked` use
+the current namespace; use `--world` to inspect the complete Debt world.
+
+Close work:
+
+```bash
+keiyaku debt done <debt-id>...
+keiyaku debt drop <debt-id>... --note "<reason>"
+```
+
+Use `done` when the Debt is complete. Use `drop` when it is no longer owed.
+Both terminal states release dependent Debts. Unresolved `needs` appear in
+`blocked`; open work with all prerequisites terminal appears in `ready`.
+
+Update a Debt without changing its lifecycle:
+
+```bash
+keiyaku debt update <debt-id> --title "<title>"
+keiyaku debt update <debt-id> --body "<body>"
+keiyaku debt update <debt-id> --needs <debt-id>
+```
+
+## 4. After Creating A Debt
+
+Read the returned Debt identity. Then:
+
+1. Add or remove relationships when the confirmed prerequisites change.
+2. Mark completed work `done`, or work no longer owed `drop` with a reason.
+3. Use `ready`, `blocked`, `tree`, or `doctor` to inspect the current ledger.
+
+Debt records unresolved work. It does not perform the work, claim acceptance,
+assign a holder, or decide what a Contract may accept.
+
+Read `keiyaku-bind` for Contract authoring and `keiyaku-workflow` for Contract
+lifecycle.

package/build/plugins/opencode/skills/keiyaku-workflow/SKILL.md

@@ -33,7 +33,7 @@ to create parallel work.
 
 - Separate `kei`s have independently acceptable outcomes.
 - An Arc is a chapter of one `kei`; it is not separately accepted.
-- A Task stores decomposition or dependencies that outlive this conversation.
+- A Debt records confirmed unresolved work and its dependencies.
 
 Use `after` only when one `kei` requires another to be accepted first. Ordinary
 overlap is not a dependency.
@@ -101,7 +101,7 @@ authority.
 | Role | Grant at birth | Return |
 | --- | --- | --- |
 | Holder | The actions the delegated loop will perform; include `contract.review` when this holder will review. Commission with the `kei`, current Arc when one exists, appointed worktree, and holder duties. | Acceptance or abandonment, with receipts. |
-| Deliverer | The ordinary baseline: every Task mutation, Contract audit and delivery, and Akuma management. `keiyaku -C <repo> call worker --alias @deliverer --contract <kei/...> --workdir <appointed-path> -` | The delivery receipt. |
+| Deliverer | The ordinary baseline: every Debt mutation, Contract audit and delivery, and Akuma management. `keiyaku -C <repo> call worker --alias @deliverer --contract <kei/...> --workdir <appointed-path> -` | The delivery receipt. |
 | Reviewer | `--allowed contract.review`: `keiyaku -C <repo> call review-akuma --alias @reviewer --contract <kei/...> --workdir <appointed-path> --allowed contract.review -` | The verdict receipt. Without the grant, `not-allowed` refuses and no verdict is recorded. |
 
 An Archetype's explicit allowed set replaces the ordinary baseline; check

package/build/plugins/pi/keiyaku.ts

@@ -1,13 +1,8 @@
-import { existsSync } from "node:fs";
-import { dirname, resolve } from "node:path";
-import { fileURLToPath } from "node:url";
 import type { ExtensionAPI, Theme } from "@earendil-works/pi-coding-agent";
 
 type ExecResult = Readonly<{ stdout: string; stderr: string; code: number }>;
 
 async function runStatus(pi: ExtensionAPI): Promise<ExecResult> {
-  const bundledCli = resolve(dirname(fileURLToPath(import.meta.url)), "../../src/cli/index.js");
-  if (existsSync(bundledCli)) return await pi.exec(process.execPath, [bundledCli, "status"]);
   return await pi.exec("keiyaku", ["status"]);
 }
 

package/build/skills/keiyaku/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: keiyaku
 description: >-
-  Keiyaku is a CLI that records plans, writes handoff terms for deliveries,
+  Keiyaku is a CLI that records unresolved work, writes handoff terms for deliveries,
   and calls delegates. Use this skill when you need to figure out which
   Keiyaku skill or command to reach for.
 ---
@@ -10,8 +10,8 @@ description: >-
 
 ## Model
 
-Keiyaku is three independent pillars, not a bundle: **Task** remembers plans
-and dependencies, **Contract** makes acceptance standing and auditable,
+Keiyaku is three independent pillars, not a bundle: **Debt** records unresolved
+work and dependencies, **Contract** makes acceptance standing and auditable,
 **Akuma** invokes capability. Use any one alone; combine them only when the
 work calls for it. Behind every Contract in flight there is one holder of its
 fulfillment loop — whoever turns intent into commissions and returns into
@@ -23,9 +23,8 @@ equally. See `keiyaku-workflow` for the loop, `keiyaku-bind` for authoring,
 ## Quick Start
 
 ```bash
-keiyaku -C <repo> task add "title"
-keiyaku -C <repo> task start <task-id>
-keiyaku -C <repo> bind [--task <task-id>] -
+keiyaku -C <repo> debt add "title"
+keiyaku -C <repo> bind [--debt <debt-id>] -
 keiyaku -C <repo> status
 keiyaku -C <repo> deliver [<contract>|@<contract>]
 keiyaku -C <repo> review [<contract>|@<contract>] --satisfied

package/build/skills/keiyaku-akuma/SKILL.md

@@ -113,7 +113,7 @@ complete grammar.
 ## JavaScript automation
 
 Use [Automation With The Akuma API](references/automation.md) for a
-task-specific JavaScript coordinator, structured answers, or multi-worker
+debt-specific JavaScript coordinator, structured answers, or multi-worker
 orchestration. The CLI is enough for one commission and its return. A
 prompt-free birth followed by one input-bound ask uses the same identity:
 

package/build/skills/keiyaku-akuma/references/automation.md

@@ -1,15 +1,15 @@
 # Automation With The Akuma API
 
 Use this guide when the work calls for a program that coordinates agents,
-not a sequence of manual CLI calls. Start with the current task, invent an
+not a sequence of manual CLI calls. Start with the current debt, invent an
 appropriate algorithm, write it as ordinary JavaScript, and run it. Treat
 examples here as material to adapt, not a mandatory workflow or a new product
 API. Product semantics remain owned by the repository's `docs/` chapters.
 
-## Write A Harness For This Task
+## Write A Harness For This Debt
 
 A dynamic workflow is more than parallel delegation. The flagship writes a
-small, task-specific program whose variables hold intermediate answers and
+small, debt-specific program whose variables hold intermediate answers and
 whose control flow performs comparisons, branching, filtering, experiments,
 and verification. Only the useful final result needs to enter the flagship's
 context. The program itself is an inspectable, reusable artifact.
@@ -21,7 +21,7 @@ The useful combination is:
 - JavaScript holds the plan, candidate sets, budgets, and stopping conditions.
 - AkuId lets a later step reconnect to an existing worker when continuity helps.
 
-Reach for this when the task needs many independent judgments, repeated
+Reach for this when the debt needs many independent judgments, repeated
 experiments, adversarial checking, or a reusable orchestration artifact. A
 single bounded question usually needs one worker, not a panel.
 
@@ -30,7 +30,7 @@ single bounded question usually needs one worker, not a panel.
 Do not stop at "one reviewer per directory." Choose an algorithm around the
 judgment you need:
 
-| Task | Task-specific orchestration |
+| Debt | Debt-specific orchestration |
 | --- | --- |
 | Find a name or visual direction with taste | Generate candidates from deliberately different directions; anonymize them; run pairwise judging agents; retain finalists and rejection reasons; generate another round against the discovered weaknesses. |
 | Rank a large qualitative backlog | Use agents as comparators, with code maintaining buckets or tournament brackets. Repeat disputed comparisons. Do not assume subjective preferences are transitive or absolute scores calibrated. |
@@ -118,7 +118,7 @@ unknowns in the requested value; acceptance still needs a suitable judge.
 The following continues the script above. One agent determines the claim set;
 code fans out verification with bounded concurrency; only supported claims go
 to fresh skeptics. The program keeps every item's success or failure. Adapt
-the prompts, schemas, routing, and selection to the task rather than always
+the prompts, schemas, routing, and selection to the debt rather than always
 running this exact pipeline.
 
 ```js
@@ -206,7 +206,7 @@ console.log(JSON.stringify(
 
 This script has a bounded work set (12 claims), at most two item pipelines in
 flight, and at most two fresh judges per claim. Each item advances to its own
-next stage without waiting for unrelated items. A different task might need
+next stage without waiting for unrelated items. A different debt might need
 pairwise comparisons, experiment queues, or adaptive sampling instead.
 
 ## Failure, Control, And Reconnection
@@ -264,6 +264,6 @@ observations for program control, not delivery notifications as receipts.
 
 These are sources of techniques, not Keiyaku runtime guarantees:
 
-- [A harness for every task: dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)
+- [A harness for every debt: dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-debt-dynamic-workflows-in-claude-code)
 - [Orchestrate subagents at scale with dynamic workflows](https://platform.claude.com/cookbook/claude-agent-sdk-08-dynamic-workflows)
 - [Claude Code workflow runtime](https://code.claude.com/docs/en/workflows)

package/build/skills/keiyaku-babysit/SKILL.md

@@ -59,7 +59,7 @@ does not move without you.
 
 ## What Babysitting Never Owns
 
-Commands and semantics belong to task, bind, workflow, and akuma. Acceptance
+Commands and semantics belong to debt, bind, workflow, and akuma. Acceptance
 belongs to the Contract's journal and its Reviewer's testimony. The question
 belongs to whoever commissioned it. Babysitting decides only when you look and
 what you check next.

package/build/skills/keiyaku-bind/SKILL.md

@@ -59,14 +59,14 @@ writing one broad Objective around unrelated fixes.
 
 - Use an Arc only for a chapter inside that one acceptance boundary; an Arc is
   not separately accepted and MUST NOT substitute for an independent `kei`.
-- Use a Task for decomposition or dependency memory that must outlive the
-  current conversation.
+- Use a Debt for confirmed unresolved work and dependencies that must outlive
+  the current conversation.
 
 A `kei` owns one independently acceptable outcome and its delivery lifecycle. A
-Task records decomposition or dependency memory; it may exist without a `kei`,
+Debt records confirmed unresolved work; it may exist without a `kei`,
 and it does not create a second acceptance or lifecycle. Associate a `kei` with
-an existing Task only when that Task has real scheduling or dependency value.
-Do not create a Task just to mirror a `kei`.
+an existing Debt only when the delivery actually settles that unresolved work.
+Do not create a Debt just to mirror a `kei`.
 
 ### Parallel Work
 
@@ -74,7 +74,7 @@ Parallel work is the default.
 
 - Bind and advance independent `kei`s in parallel. Each has its own acceptance
   boundary and holder.
-- Within one `kei`, run independent Tasks or Arc chapters in parallel whenever
+- Within one `kei`, run independent Debts or Arc chapters in parallel whenever
   their work can proceed independently. They converge on the one acceptance
   boundary, which the holder owns.
 
@@ -162,10 +162,10 @@ prospective candidate. Without `verified`, no verb runs Verification and the
 section is inert document text. `reviewed` independently requires review
 evidence. Selected gates are checked at placement.
 
-For an existing Task with real scheduling or dependency value:
+For an existing Debt that this delivery settles:
 
 ```bash
-keiyaku -C <repo> bind --task <task/...> - < CONTRACT.md
+keiyaku -C <repo> bind --debt <debt/...> - < CONTRACT.md
 ```
 
 For a real logical dependency between Contracts:
@@ -204,7 +204,7 @@ waiting, the stated prerequisites remain; do not bind a duplicate Contract.
 
 The holder now owns the lifecycle:
 
-1. Start the work directly or delegate Tasks, Arc chapters, Akumas, or Contract roles.
+1. Start the work directly or delegate Debts, Arc chapters, Akumas, or Contract roles.
 2. Run independent work in parallel and let it converge on the one acceptance
    boundary.
 3. Prepare and deliver the candidate.