abelworkflow 1.2.3 → 1.3.0

package/lib/templates/codex/agents/worker.toml

@@ -3,72 +3,38 @@
 
 name                   = "worker"
 description            = """
-Dispatch for bounded, module-level implementation: bug fixes, single-module
-feature additions, test writing, and intra-module refactors.
+Dispatch for bounded diff authoring: Red verifications, Green implementations,
+and optional intra-module refactors within an explicitly assigned write set.
+The parent applies and verifies every returned diff.
 Do NOT dispatch when the task touches global configs, shared utilities,
-
-public interfaces used across modules, or project scaffolding.
+public interfaces used across modules, or project scaffolding without an
+approved expanded contract.
 """
 nickname_candidates    = ["Forge", "Patch", "Builder"]
 model                  = "gpt-5.6-luna"
-model_reasoning_effort = "high"
-sandbox_mode           = "workspace-write"
-
-developer_instructions = """
-You are a local implementation sub-agent. Execute bounded tasks with
-precision and minimal footprint. You are not alone in the codebase.
-
-## Development Context
-
-Development context: work is currently in the development phase, and this is a development repository.
-Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
-Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
-This context does not by itself authorize destructive changes to user files or credentials outside the repository.
-
-## Boundaries
-
-- Work only within the file set and module boundary authorized by the
-  orchestrator. Do not expand scope unilaterally.
-
-- Never revert or overwrite changes made by other agents. On conflict, stop
-
-  and report.
-
-- Never spawn sub-agents. If you find you need to, file a Handover Report.
-
-## Prohibited (stop and report instead)
-
-Any of the following requires escalation — do not attempt alone:
-- Shared utility modules, infrastructure layers, or framework-level code
-- Global configs, global state, or global constants
-- Project initialization, scaffolding, or directory restructuring
-- New dependencies consumed by more than one module
-- Public interfaces or abstractions referenced across multiple modules
-
-Decision rule: if the blast radius exceeds the current module boundary,
-it is a global task — stop immediately.
-
-
-## Execution Standards
-
-1. Read before writing — understand relevant code before editing.
-2. Smallest defensible change — no speculative improvements.
-3. TDD when behavior changes — tests before or alongside implementation.
-4. Verify, don't claim — never say "fixed" without running verification;
-   if you cannot verify, say so explicitly.
-
-## Output
-
-Normal completion → Completion Report:
-  1. Modified files:   <path> — <what changed and why>
-
-  2. Verification:     <command> → <result, or "unverified: <reason>">
-  3. Residual risk:    <notes for orchestrator, or "none">
-
-Mid-task block → Handover Report (stop first, then write):
-  1. Completed changes:       <file> — <specific changes made>
-  2. Unfinished parts:        <steps not yet executed>
-  3. Blocking reason:         <what global capability is needed>
-
-  4. Continuation suggestion: <how the orchestrator should proceed>
+model_reasoning_effort = "max"
+sandbox_mode           = "read-only"
+
+developer_instructions = """Author bounded unified diffs for the parent orchestrator.
+- Work only on the explicitly assigned task, paths/symbols, and approved behavior.
+- Never write to the worktree, apply a patch, edit AGENTS indexes/OpenSpec tracking files, commit, spawn subagents, or advance task state.
+- Do not broaden a write set, add dependencies, change public/shared infrastructure, or invent behavior/architecture. Stop and report a blocker when the contract is insufficient.
+- Preserve unrelated user changes and base the diff on the supplied current baseline.
+
+TDD handoff:
+- Red: return only the approved failing test/static-verification diff and its expected target failure.
+- Green: after the parent confirms Red, return only the minimum implementation diff.
+- Refactor: after the parent confirms Green, return only an optional in-scope cleanup diff.
+- If the parent reports a verification failure, return a bounded correction diff or a blocker; do not silently change the contract.
+
+Return valid JSON only:
+{
+  "phase": "<red|green|refactor|blocked>",
+  "task_id": "<id>",
+  "modified_files": ["<path>"],
+  "diff": "<unified diff or empty string>",
+  "verification": [{"command": "<command>", "expected_or_observed": "<result>"}],
+  "residual_risk": ["<risk>"],
+  "blocked_by": ["<reason>"]
+}
 """

package/lib/templates/codex/config-base.toml

@@ -13,12 +13,6 @@ value.
 - An active workflow command takes precedence over this default orchestration
   policy. Follow its phase rules, write boundaries, required tools,
   verification order, and stop/go gates exactly.
-- `/abel-design` is design-only: investigate and produce validated OpenSpec
-  artifacts without implementing product code.
-- `/abel-implement` requires OpenSpec readiness and test-first Red, Green,
-  Refactor cycles before completion is recorded.
-- `/abel-diagnose` requires reproduction and evidence for the root cause before
-  a regression test and minimal fix.
 - Subagents assist inside the active phase. They never own workflow transitions
   or bypass required user confirmation.
 

package/lib/templates/{workflow/gitignore.template → gitignore.template}

@@ -5,9 +5,6 @@
 *.log
 */node_modules/
 */tmp/
-skills/dev-browser/profiles/
-skills/dev-browser/tmp/
-skills/dev-browser/.cache/
 *cache*/
 */dist/
 */build/

package/lib/tools/cli-installer.mjs

@@ -26,7 +26,28 @@ async function runCommand(command, args) {
   });
 }
 
-function buildCliToolInstallCommand({ packageName, skipScripts = false }) {
+async function installCadence(run = runCommand) {
+  await run("pi", ["install", "npm:@abelxiaoxing/cadence"]);
+}
+
+function detectPackageManager(exists = commandExists) {
+  if (exists("bun")) return "bun";
+  if (exists("npm")) return "npm";
+  return null;
+}
+
+function buildCliToolInstallCommand({ packageManager = "npm", packageName, skipScripts = false }) {
+  if (packageManager === "bun") {
+    return {
+      command: "bun",
+      args: [
+        "add",
+        "-g",
+        ...(skipScripts ? ["--ignore-scripts"] : []),
+        packageName
+      ]
+    };
+  }
   return {
     command: "npm",
     args: [
@@ -52,7 +73,9 @@ function getNpmInstallHelp(platform = getPlatform()) {
   };
 }
 
-async function installCliTool(tool, { confirmOrCancel }) {
+async function installCliTool(tool, { confirmOrCancel }, runtime = {}) {
+  const exists = runtime.commandExists ?? commandExists;
+  const run = runtime.runCommand ?? runCommand;
   const toolConfig = {
     claude: {
       label: "Claude Code",
@@ -74,16 +97,18 @@ async function installCliTool(tool, { confirmOrCancel }) {
 
   if (!toolConfig) throw new Error(`Unsupported tool: ${tool}`);
 
-  if (!commandExists("npm")) {
+  const packageManager = detectPackageManager(exists);
+  if (!packageManager) {
     const help = getNpmInstallHelp();
-    p.log.warn(`未检测到 npm，无法安装 ${toolConfig.label}。`);
-    p.log.message(`${help.platformLabel} 可先安装 Node.js/npm，再重新运行安装。`);
+    p.log.warn(`未检测到 bun 或 npm，无法安装 ${toolConfig.label}。`);
+    p.log.message(`推荐先安装 Bun: https://bun.sh/install`);
+    p.log.message(`${help.platformLabel} 也可先安装 Node.js/npm，再重新运行安装。`);
     p.log.message(`中国大陆镜像: ${help.mainlandUrl}`);
     p.log.message(`官方下载页: ${help.officialUrl}`);
-    return;
+    return false;
   }
 
-  const installed = commandExists(toolConfig.command);
+  const installed = exists(toolConfig.command);
   if (installed) {
     const shouldUpdate = await confirmOrCancel({
       message: `${toolConfig.label} 已检测到，是否继续安装/更新？`,
@@ -91,16 +116,17 @@ async function installCliTool(tool, { confirmOrCancel }) {
     });
     if (!shouldUpdate) {
       p.log.message(`跳过 ${toolConfig.label} 安装。`);
-      return;
+      return false;
     }
   }
 
-  const installCommand = buildCliToolInstallCommand(toolConfig);
-  const spinner = p.spinner();
-  spinner.start(`正在使用 npm 安装 ${toolConfig.label}...`);
+  const installCommand = buildCliToolInstallCommand({ ...toolConfig, packageManager });
+  const spinner = (runtime.spinner ?? p.spinner)();
+  spinner.start(`正在使用 ${packageManager} 安装 ${toolConfig.label}...`);
   try {
-    await runCommand(installCommand.command, installCommand.args);
+    await run(installCommand.command, installCommand.args);
     spinner.stop(`${toolConfig.label} 安装完成`);
+    return true;
   } catch (error) {
     spinner.cancel(c.red(`${toolConfig.label} 安装失败: ${error.message}`));
     throw error;
@@ -109,8 +135,10 @@ async function installCliTool(tool, { confirmOrCancel }) {
 
 export {
   buildCliToolInstallCommand,
+  detectPackageManager,
   getNpmInstallHelp,
   getRunCommandSpawnOptions,
   installCliTool,
+  installCadence,
   commandExists
 };

package/package.json

@@ -1,20 +1,18 @@
 {
   "name": "abelworkflow",
-  "version": "1.2.3",
-  "description": "Install AbelWorkflow into ~/.agents and create Claude, Codex, and Pi links.",
+  "version": "1.3.0",
+  "description": "Install AbelWorkflow into ~/.agents and configure Claude, Codex, and Pi.",
   "type": "module",
   "scripts": {
-    "test": "npm run build && npm run test:node",
+    "test": "npm run test:node",
     "test:node": "node --test test/*.test.mjs",
     "test:python": "python -B -m unittest discover -s test",
-    "test:dev-browser": "npm test --prefix skills/dev-browser",
     "test:contracts": "node --test test/runtime-doc-contracts.test.mjs test/cli-args.test.mjs",
-    "typecheck": "npm run typecheck --prefix skills/dev-browser",
-    "build": "npm run build --prefix skills/dev-browser",
-    "prepack": "npm run build",
+    "typecheck": "npm run typecheck:pi",
+    "typecheck:pi": "tsc -p tsconfig.pi.json",
     "check:docs": "node --test test/docs-contracts.test.mjs test/runtime-doc-contracts.test.mjs",
-    "check:package": "npm run build && node --test test/package-contents.test.mjs",
-    "check": "npm run build && npm run test:node && npm run test:python && npm run test:dev-browser && npm run typecheck"
+    "check:package": "node --test test/package-contents.test.mjs",
+    "check": "npm run test:node && npm run test:python && npm run typecheck"
   },
   "bin": {
     "abelworkflow": "bin/abelworkflow.mjs"
@@ -27,26 +25,23 @@
     "skills/context7-auto-research/.env.example",
     "skills/context7-auto-research/SKILL.md",
     "skills/context7-auto-research/context7-api.cjs",
-    "skills/dev-browser/SKILL.md",
-    "skills/dev-browser/dist",
-    "skills/dev-browser/package-lock.json",
-    "skills/dev-browser/package.json",
-    "skills/dev-browser/references",
-    "skills/git-commit/SKILL.md",
     "skills/grok-search/.env.example",
     "skills/grok-search/SKILL.md",
     "skills/grok-search/defaults.json",
     "skills/grok-search/requirements.txt",
     "skills/grok-search/scripts/_dotenv.py",
-    "skills/grok-search/scripts/groksearch_cli.py",
-    "skills/time/SKILL.md",
-    "skills/time/scripts/time_cli.py"
+    "skills/grok-search/scripts/groksearch_cli.py"
   ],
   "engines": {
     "node": ">=22"
   },
   "packageManager": "npm@10.9.2",
   "license": "MIT",
+  "devDependencies": {
+    "@earendil-works/pi-coding-agent": "0.85.1",
+    "@types/node": "22.20.1",
+    "typescript": "5.9.3"
+  },
   "dependencies": {
     "@clack/prompts": "^1.2.0",
     "picocolors": "^1.1.1",

package/lib/templates/workflow/AGENTS.md

@@ -1,50 +0,0 @@
-# Configuration
-
-## Language
-
-- Tool/model interactions: **English**
-- User-facing output: **Chinese**
-
-## Code Style
-
-- Concise, efficient, no redundancy
-- Minimal comments/docs (only when necessary)
-- Targeted changes only; never touch unrelated functionality
-
-## Development Context
-
-Development context: work is currently in the development phase, and this is a development repository.
-Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
-Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
-This context does not by itself authorize destructive changes to user files or credentials outside the repository.
-
-## Context Rules
-
-- Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads.
-- Rely only on project code plus `grok/context7` results
-- If information is insufficient or uncertain, state it explicitly
-
-## Workflow
-
-```
-/abel-init → /abel-design → /abel-implement(TDD)
-                           ↘ /abel-diagnose (bug fix)
-```
-
-## Universal Constraints
-
-1. Use `unified diff patch` format for proposed/applied changes
-2. Before applying changes, state assumptions and unknowns explicitly; stop and ask the user on any critical unknown
-
-## Stage Skill Matrix
-
-| Skill | Design | Implement | Diagnose | Capability & Triggers |
-| --- | :---: | :---: | :---: | --- |
-| /grok-search | ✅ | ❌ | ✅ | Deep research, concept understanding. Trigger: architectural patterns, best practices |
-| /context7-auto-research | ✅ | ✅ | ✅ | Official docs retrieval. Trigger: framework/library usage, APIs |
-| /dev-browser | ○ | ✅ | ✅ | Browser automation. Trigger: E2E testing, UI verification |
-| /time | ○ | ✅ | ○ | Time/timezone operations. Trigger: scheduling logic |
-
-Legend: ✅ Primary, ○ Optional, ❌ Forbidden
-
-OpenSpec commands: `/opsx:propose` `/opsx:explore` `/opsx:apply` `/opsx:update` `/opsx:sync` `/opsx:archive` `openspec view` `openspec status`

package/lib/templates/workflow/commands/abel-design.md

@@ -1,175 +0,0 @@
----
-name: abel-design
-description: Transform requirements into implementation-ready, traceable specs via gated clarification.
-category: abel
-tags: [abel, design, constraints, PBT, subagents]
-argument-hint: [requirement | --change <change_name>]
----
-
-<!-- ABEL:START -->
-
-# abel-design — Gated Design Mode (Specs Only, No Implementation)
-
-## Non-Negotiable Rules (Highest Priority)
-1. DESIGN MODE ONLY — you MUST NOT generate implementation code.
-2. WRITE SCOPE:
-   - Before Gate A: strictly read-only; persist nothing.
-   - After Gate A: write ONLY inside the resolved `changeRoot`. Create only ready artifacts; edit a done artifact only when an approved loop-back/consistency repair explicitly targets it.
-3. NEVER assume or guess — every blocking decision goes to the user (see Decision Model).
-4. Final output: a schema-valid, fully traceable OpenSpec change with BLOCKING_DECISIONS = 0, READY_TO_IMPLEMENT.
-
-**Skill Integration**: See `Stage Skill Matrix` (Design column)
-
----
-
-## Decision Model
-- Maintain an in-session Decision Ledger with: `id`, `class`, `question`, `evidence`, `options`, `recommendation`, `resolution`, `status`, `affected_artifacts`.
-- `BLOCKING_DECISIONS` is the count of unresolved, non-mechanical decisions in that ledger.
-- Behavior decisions answer WHAT: observable outcomes, scope/non-goals, scenarios, failure behavior, data/security/privacy/compatibility policies and success criteria.
-- Technical decisions answer HOW: interfaces, data flow, dependencies, storage/algorithms, implementation error mechanisms and key technical parameters.
-- MUST be approved by the user: goal, scope, non-goals and observable success behavior; data, security, privacy, compatibility and migration rules; new dependencies, cross-module architecture, irreversible changes; any technical choice with substantive trade-offs, including key parameters.
-- MAY be decided mechanically by the agent: naming, file locations and local structure uniquely determined by existing repo conventions; easily reversible details with no external behavior change; test placement and execution order derived directly from the approved design.
-- Record mechanical decisions and never re-ask them. Two or more viable options with substantive differences → escalate to a blocking decision.
-- Do NOT create a runtime ledger or approval-state file. Materialize approved decisions only in schema artifacts.
-
-## Phase 0 — Entry, Mode & Readiness (read-only)
-- Verify an initialized OpenSpec root and the required CLI capabilities: `new change`, `list --json`, `schemas --json`, `schema which --json`, `schema validate --json`, `templates --json`, `status --json`, `instructions --json`, and `validate --strict`. If unavailable, STOP with actionable `/abel-init` remediation; do not initialize or update from this command.
-- Resolve mode:
-  - Explicit `--change <name>` → Resume. If that change does not exist, STOP and ask the user to correct the name or choose New mode.
-  - Otherwise, an exact existing-change match → Resume.
-  - Otherwise → New mode; do not silently interpret an explicit/resume-like typo as a requirement.
-- Resolve the effective schema by precedence: explicit schema choice, existing change metadata, project config, then `spec-driven`; verify it appears in `openspec schemas --json`.
-- Before creating a change, run `openspec schema which <schema> --json` and `openspec schema validate <schema> --json`, inspect its definition and `openspec templates --schema <schema> --json`, and perform a preliminary behavior/technical/mixed dependency check. Implementation compatibility also requires a non-empty concrete `apply.tracks` that matches exactly one artifact's `generates`. An incompatible schema must fail closed before creation.
-- New mode minimum intake before ANY exploration:
-  - Problem/goal statement, AND
-  - Scope anchor (which module/directory is involved).
-- If either intake item is missing, ask the user concisely before proceeding.
-- Generate a provisional kebab-case change name and check `openspec list --changes --json`. Recompute and confirm it from the final Gate A scope before creation. Persist nothing yet.
-
-## Phase 1 — Evidence Exploration (read-only)
-- Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads.
-- Single context boundary → main agent explores directly.
-- Multiple independent context boundaries, when the platform permits → dispatch parallel Explore subagents:
-  - Divide by context boundary (NOT functional role); each boundary self-contained.
-  - Each subagent receives: mandatory use of the codebase retrieval policy, a clear scope, and the mandatory JSON output schema:
-{
-  "module_name": "所探索的上下文边界",
-  "existing_structures": ["关键结构/模式"],
-  "existing_conventions": ["约定/标准"],
-  "constraints_discovered": ["硬约束"],
-  "open_questions": ["需用户输入的歧义"],
-  "dependencies": ["跨模块依赖"],
-  "risks": ["风险/阻碍"],
-  "success_criteria_hints": ["可观察的成功行为"]
-}
-- Validate every subagent JSON before aggregation; aggregate constraints, dependencies, risks, conflicts and questions into the Decision Ledger.
-- Audit existing codebase patterns:
-  Use `rg`, `rg --files`, `git grep`, and direct file reads to validate against existing codebase patterns.
-- On-demand /context7-auto-research: verify candidate libraries/APIs against official contracts.
-- On-demand /grok-search: architectural patterns and best practices for candidate directions.
-- PBT boundary screening: probe empty input, idempotency, ordering, size/value bounds, state-transition legality → feed the question list for Phase 2.
-- Reference: Inspect codebase structure with `rg --files`, `git grep`, and direct file reads.
-
-## Phase 2 — Behavior Clarification Loop (multiple rounds allowed)
-- Cover WHAT only: goal, scope, non-goals, observable scenarios/success criteria, failure behavior, and data/security/privacy/compatibility policies.
-- Do not choose libraries, protocols, algorithms, storage, topology or implementation parameters in this phase; route them to Phase 4.
-- Each round asks ONLY the current highest-impact blocking questions, grouped concisely, each with evidence, impact and a recommended default.
-- Anti-patterns (flag and reject):
-  - Observable behavior deferred to implementation ("error behavior decided while coding")
-  - Technical mechanisms smuggled in as product requirements
-- Target behavior patterns:
-  - "Lock the account for 30 minutes after 5 consecutive failed logins."
-  - "Retain audit records for 30 days and never expose secrets in responses."
-  - "For an empty query, return an empty result within the approved latency bound."
-- An answer that widens modules, scenarios or data boundaries → return to Phase 1 for INCREMENTAL exploration only.
-- Loop until unresolved behavior decisions = 0.
-
-## ⛔ Gate A — Approve Behavior Contract
-- Present the behavior contract and affected Decision Ledger entries; the user explicitly approves goal, scope/non-goals, scenarios/success criteria and policies.
-- Recompute the change name from the approved scope and recheck duplicates.
-- New mode: ONLY NOW create the change with `openspec new change <change-name>` (add `--schema <schema>` only for an explicit non-default choice).
-- Build the Artifact Plan, then materialize only behavior-class artifacts that are safe and ready.
-
-## Artifact Plan & Write Protocol
-- Before New-mode creation, build a preliminary compatibility map from the resolved schema definition/templates. After creation or in Resume mode, build the final Artifact Plan from `status --json` and available `instructions --json`. Record the schema's `apply.tracks`; for every artifact record capture id/output paths, dependencies/status, substantive decision class (`behavior|technical|mixed`), write Gate, and affected decisions. Mechanical impact information alone does not make an artifact mixed.
-- Classify by the decisions the artifact carries, never by a hardcoded artifact name:
-  - behavior → Gate A
-  - technical or mixed → Gate B
-  - behavior depending on a Gate B artifact → defer until after Gate B and then follow the DAG
-- If the schema requires a write before Gate A, a write outside `changeRoot`, or an unapproved technical decision to unlock behavior, STOP before New-mode creation and ask the user to select a compatible schema/mapping. Schema order never overrides decision approval.
-- Mandatory loop for EVERY artifact write:
-  1. Run `openspec status --change <change-name> --json`; verify `schemaName`, `changeRoot`, `artifactPaths`, status/dependencies and `applyRequires`. `existingOutputPaths` may be empty and is not a new-file target.
-  2. Run `openspec instructions <artifact-id> --change <change-name> --json`; follow its template/rules/dependencies.
-  3. Read dependencies and existing outputs; check consistency in both directions.
-  4. Prepare content in memory and show the decision summary or unified diff before the corresponding Gate. If materialization reveals a new substantive decision, return to the relevant loop and re-approve it.
-  5. After Gate approval, create exactly one ready artifact, or edit one done artifact explicitly targeted by an approved loop-back/consistency repair. Rerun status after every write and process newly unlocked artifacts topologically.
-
-## Phase 3 — Technical Derivation
-- Derive the technical design from the Gate A contract, existing codebase patterns and official API contracts.
-- Mechanical decisions → record directly in the design. Substantive trade-offs → Phase 4.
-
-## Phase 4 — Technical Decision & Verification Loop
-- Cover HOW: interfaces, data flow, implementation error mechanisms, dependencies/algorithms and key parameters. Examples include JWT vs session design and an approved bcrypt cost factor.
-- Apply the same evidence/options/recommendation format to every substantive technical decision; update the Decision Ledger.
-- PBT applicability rule (screen with the six categories: commutativity/associativity, idempotency, round-trip, invariant preservation, monotonicity, bounds):
-  - Behavior with invariants, round-trips, idempotency, ordering, bounds or state transitions → MUST extract a property + falsification strategy.
-  - Behavior unsuited to PBT → use example/E2E/static verification and record why PBT does not apply. Do NOT force every requirement through every category.
-- Give every scenario a stable reference: `<spec-path>#<requirement-heading>/<scenario-heading>` and require those headings to be unique within the spec; maintain Requirement → Scenario → Verification → Task.
-- Every task has exactly one schema checkbox and a verification contract using ordinary indented bullets, NEVER nested `- [ ]`/`- [x]` lines:
-  - Task ID / dependencies
-  - Requirement + stable Scenario reference
-  - Verification type: property | example | E2E | static
-  - Red command + expected failure reason
-  - Green expected behavior
-  - Affected-suite verification command
-  - Target scope/files
-- For a non-behavior-change task, the Red command is a pre-change executable static verification. Manual-only verification is not implementation-ready and MUST NOT pass Gate B or Exit; reshape the task until it has executable property/example/E2E/static verification.
-- Loop until unresolved technical decisions = 0; prepare proposed remaining artifact contents/unified diffs in memory.
-
-## ⛔ Gate B — Approve Implementation Contract
-- Verify Phase 3/4 faithfully expand the Gate A contract; no unapproved new decisions introduced.
-- Present substantive technical decisions, task/verification mapping and artifact materialization preview.
-- The user explicitly approves that implementation contract.
-- Write the remaining ready artifacts one at a time per the Artifact Plan & Write Protocol.
-
-## Loop-Back Rules
-- A user answer widens modules, scenarios or data boundaries → return to Phase 1.
-- Technical analysis overturns the behavior contract → return to Phase 2; re-approve ONLY the affected decisions and synchronize all affected artifacts.
-- Gate B finds the materialization unfaithful → return to Phase 3/4; unaffected Gate A decisions remain approved.
-- Strict validation, verification-contract or traceability failure → return to the earliest phase that introduced the inconsistency.
-- Never hide a late-discovered blocking question.
-
-## Resume Rules
-- Never infer user approval from artifact existence: `status` reporting `done` proves file completion only, not Gate approval.
-- Never resume by fixed file names or file existence alone; the active schema decides.
-- Algorithm:
-  1. Run `openspec status --change <change-name> --json`.
-  2. Use its `schemaName`, `changeRoot`, `artifactPaths` and statuses; read all `existingOutputPaths` and dependencies.
-  3. Check `openspec validate <change-name> --strict --type change`, template completeness, cross-artifact consistency, traceability and verification contracts.
-  4. Rebuild Gate A/B summaries and the Artifact Plan. Re-confirm every Gate approval that cannot be proven in the current conversation.
-  5. Choose the next step:
-     - Explicit Resume change not found (`change_error`) → STOP for spelling/New-mode confirmation; never create silently.
-     - Artifacts incomplete → repair/confirm the nearest safe Gate, then handle the artifacts the schema reports ready.
-     - Artifacts complete but validation/traceability fails → earliest inconsistent phase.
-     - Every artifact id listed in `applyRequires` is `done` → re-confirm any unproven Gate, then run the Exit audit.
-     - Only in-session, un-persisted analysis exists → no mid-loop resume; re-run the read-only analysis.
-- Do NOT create runtime approval-state files; re-confirming the Gate summary IS the resume mechanism.
-
-## Exit Criteria
-- [ ] `openspec validate <change-name> --strict --type change` returns zero issues
-- [ ] Every artifact id in `applyRequires` has status `done`
-- [ ] Schema `apply.tracks` resolves to the generated task artifact inside `changeRoot`
-- [ ] Artifacts are consistent and traceable; every task has a valid verification contract
-- [ ] Every task has executable property/example/E2E/static verification; no task is manual-only
-- [ ] BLOCKING_DECISIONS = 0
-- [ ] User has explicitly approved the reconstructed/current Gate A and Gate B summaries in this conversation
-- [ ] Status: READY_TO_IMPLEMENT
-
-## Reference
-- `openspec context --json` / `openspec schemas --json`
-- `openspec view` / `openspec list --changes --json` / `openspec list --specs` (conflicts with existing specs)
-- `openspec status --change <change-name> --json` / `openspec instructions <artifact-id> --change <change-name> --json`
-- `openspec new change <change-name>` (Gate A only)
-- `openspec show <change-name> --json --deltas-only` when validation fails
-- `rg -n "Constraint:|MUST|MUST NOT|INVARIANT:|PROPERTY:" openspec/` before defining new ones
-<!-- ABEL:END -->

package/lib/templates/workflow/commands/abel-diagnose.md

@@ -1,63 +0,0 @@
----
-name: abel-diagnose
-description: Parallel diagnosis with batch fix reporting via systematic root cause analysis.
-category: abel
-tags: [abel, diagnosis, bugfix]
-argument-hint: <problem-description>
----
-<!-- ABEL:START -->
-**Arguments**
-- Required: `<problem-description>` (one or more bug descriptions; comma-separated supported)
-
-**Guardrails**
-- Root cause first; never fix symptoms only
-- Verify root cause hypothesis with evidence before fix
-- Only fixes with evidence-verified root cause may be applied
-- Every fix must include a regression test
-- Keep changes minimal and scoped
-- If verification fails, rollback and iterate
-
-**Execution Model**
-- Run detection and root-cause analysis for all issues in parallel
-- Infer scope automatically from problem text, traces, and retrieved code context
-- Build dependency/conflict order before any fix application
-- Same file: force sequential fix order; same symbol: merge when compatible, otherwise sequential
-- Independent scopes: parallel-safe
-- Fix generation for READY issues runs fully in parallel via subagents with forked/minimal context; main agent only aggregates and resolves conflicts
-- Patch application and final verification must run strictly sequential by dependency order
-- Always output one consolidated batch report
-
-**Skill Integration**: See `Stage Skill Matrix` (Diagnose column)
-
-**Steps**
-1. Parse input, infer scope, and split into issue list (single or multiple).
-2. For each issue in parallel: collect logs/traces and locate code via the configured codebase retrieval policy.
-3. For each issue in parallel: perform root cause analysis; for multi-component chains, decompose the failure chain step by step with evidence.
-4. Build dependency/conflict graph across issues and compute safe fix order.
-5. Verify each issue's root cause against collected evidence; only issues with a verified root cause can move to fix generation.
-6. Spawn one subagent per READY issue to generate `unified diff patch` and regression test with minimal scoped context.
-7. Main agent reviews/merges subagent outputs by dependency order and outputs one batch report with all issue statuses and patches.
-8. Apply merged patches strictly sequentially by dependency order.
-9. Run final verification strictly sequentially by the same dependency order and output verification matrix.
-
-**Batch Output**
-```text
-## /abel-diagnose Batch Report
-
-### Batch Summary
-Total: {n} | ReadyToFix: {n_ready} | Blocked: {n_blocked}
-
-### Issue Results
-- [{id}] Classification: {category}/{severity} | Root Cause: {summary} | Verified: {yes|no} | Subagent: {agent_id|none} | Status: {READY|BLOCKED}
-
-### Patch Queue (dependency order)
-1. [{id}] [subagent:{agent_id}] {file_list}
-{unified_diff_patch}
-
-### Verification Matrix
-- [{id}] Regression: {passed|failed} | Affected Suite: {passed|failed}
-
-### Final Status
-{FIXED|PARTIAL|NEEDS_REVIEW|BLOCKED}
-```
-<!-- ABEL:END -->