abelworkflow 1.2.2 → 1.2.4

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

@@ -1,50 +1,170 @@
 ---
 name: abel-implement
-description: Implement an OpenSpec change with test-first Red, Green, Refactor cycles.
+description: Implement approved changes with mandatory TDD.
 category: abel
 tags: [abel, implementation, TDD]
 argument-hint: [change_name]
 ---
 
 <!-- ABEL:START -->
-# abel-implement
+**Arguments**
+- Requested: `<change_name>`
 
-Implement one ready OpenSpec change with minimal, verified patches.
+**Guardrails**
 
-## Rules
+- Keep changes tightly scoped to the requested outcome; enforce side-effect review before applying any modification.
+- Minimize documentation—avoid unnecessary comments; prefer self-explanatory code.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) for additional OpenSpec conventions or clarifications.
 
-- Follow the repository instructions and the Implement column of its Stage Skill Matrix.
-- Before any write, state assumptions and unknowns explicitly. If a critical unknown could change behavior, scope, architecture, or safety, stop and ask the user or return to `/abel-design --change <change-name>`.
-- Retrieve project context with `rg`, `rg --files`, `git grep`, and direct file reads.
-- Use unified diff patches and stay inside the task's declared scope. Do not invent missing product or architecture decisions.
+**TDD Guardrails (mandatory)**
+- **Red Phase**: Create or execute the task's failing executable verification ONLY; implementation code is FORBIDDEN.
+- **Green Phase**: Write MINIMAL code to satisfy the verification; over-engineering is FORBIDDEN.
+- **Refactor Phase**: Optimize code quality while keeping target and affected verification green and introducing no new full-suite failures.
+- **Mandatory**: Run the task's executable verification after EVERY code change; never skip verification.
+- **Test-First**: Each task MUST have a failing executable verification before implementation begins.
 
-## Readiness
+**Skill Integration**: See `Stage Skill Matrix` (Implement column)
 
-1. Resolve `<change-name>` from the explicit argument; ask only if it is missing or ambiguous.
-2. Run `openspec status --change <change-name> --json`. Read `schemaName`, `changeRoot`, `artifactPaths`, `applyRequires`, and artifact states; every required artifact must be done.
-3. Inspect `openspec schema which <schemaName> --json`. Resolve its concrete `apply.tracks` file inside `changeRoot`; never guess a task filename.
-4. Run `openspec validate <change-name> --strict --type change` and `openspec instructions apply --change <change-name> --json`.
-5. Read the reported artifacts, tracking file, affected source, and nearby tests. Confirm that every task states scope, dependencies, Requirement/Scenario, Red failure, Green behavior, and verification commands.
-6. Run the affected tests and full suite as a baseline. Record commands, exit status, and existing failure identities; an existing failure is not the target Red.
+**Readiness Preflight (before any code or test write)**
 
-If readiness is incomplete or inconsistent, stop without product writes and return the issue to design.
+1. Explicit argument takes precedence. Resolve it directly; ask only when the argument is missing or cannot be resolved uniquely. Never require unconditional `openspec view` confirmation.
+2. Run `openspec status --change <change-name> --json`; read `schemaName`, `changeRoot`, `artifactPaths`, `applyRequires`, and `artifacts`.
+3. Run `openspec schema which <schemaName> --json`, read the resolved `schema.yaml`, and extract `apply.tracks`. Resolve `apply.tracks` relative to `changeRoot`; it must name one concrete existing regular file inside `changeRoot`. Missing, null, non-concrete, or escaping paths fail closed; do not infer the tracking path from apply-instruction `contextFiles` or `tasks`.
+4. Every artifact id in `applyRequires` must have status `done`; array presence or a general completion flag is insufficient.
+5. Run `openspec validate <change-name> --strict --type change`; require zero issues.
+6. Read every planning artifact reported by `artifactPaths`, then run `openspec instructions apply --change <change-name> --json` and follow the returned apply contract.
+7. Verify stable Requirement and Scenario references, the Requirement → Scenario → Verification → Task chain, and every task verification contract. Rebuild the Gate A and Gate B summaries; if approval cannot be proven in the current conversation, show the summaries and require explicit user confirmation.
+8. Run and record affected baseline tests and the full test suite before any write. Record each command, exit status, and normalized failure identities/reasons. Keep existing failures from the full suite separate from the target Red; an existing failure never counts as Red.
+9. If any preflight item fails, STOP and return `/abel-design --change <change-name>`. Do not invent or repair product, behavior, or architecture decisions here.
 
-## TDD Cycle
+**Tool Routing**:
+- **TDD Cycle**: Autonomous refactoring
+- **Final Review** (after all tasks):
+  - Backend refactor (subagents)
+  - Frontend refactor (subagents)
+- **E2E tasks** → `/dev-browser`
 
-For each incomplete task, in dependency order:
+After preflight, detect the project's verification tooling and work through the tracked tasks sequentially.
 
-1. Red: add or update the smallest executable test or static check, then run it. It must fail for the target's expected reason before implementation changes. If it passes or fails for another reason, stop and resolve the mismatch.
-2. Green: apply the minimal implementation patch and rerun the Red command until it passes.
-3. Refactor: simplify only where useful, keeping the target and affected tests green after each code change.
-4. Run the task's affected verification. Review the diff for unintended behavior, unrelated edits, security issues, and leaked runtime state.
-5. Leave the task incomplete in `apply.tracks` until final verification succeeds.
+**TDD Cycle (per task)**
 
-## Final Verification
+Consume these ordinary indented bullets from the task verification contract, never Markdown checkboxes:
+- verification type: property | example | E2E | static
+- Red command and expected failure reason
+- Green expected behavior
+- affected-suite command
+- target scope/files
 
-- Run all target tests, affected suites, and the same full-suite baseline command. Require no new failure identities.
-- Rerun `openspec validate <change-name> --strict --type change` and inspect `openspec status --change <change-name> --json`.
-- Only after those checks pass, mark each implemented task complete in the file resolved from `apply.tracks`; require exactly one matching task ID. Rerun validation and status after this completion-only patch.
-- If any verification fails, ensure those tasks remain incomplete or restore them to incomplete so a resumed run selects them again.
-- Review the complete unified diff and report changed files, Red/Green evidence, final verification, baseline exceptions, and residual risks.
-- Do not archive automatically; `/opsx:archive` remains a separate user-authorized action.
+- Red must fail because of the target defect described by the contract.
+- If the failure reason differs or the command is invalid, STOP and return `/abel-design --change <change-name>`; do not improvise a replacement contract.
+- A non-behavior-change task starts with its specified failing executable static verification.
+- A manual-only task is not implementation-ready; STOP and return `/abel-design --change <change-name>`.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Step 1: 🔴 Red Phase - Execute Contract Verification    │
+│   ├─ Use the contract's verification type and scope     │
+│   ├─ Generate the required failing verification via     │
+│   │   PROMPT: "Generate failing verification for: {task}│
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: implementation code"          │
+│   ├─ Apply verification code (after review)             │
+│   ├─ Run Red command → MUST FAIL for expected reason    │
+│   └─ If it passes or fails differently → STOP           │
+├─────────────────────────────────────────────────────────┤
+│ Step 2: 🟢 Green Phase - Minimal Implementation         │
+│   ├─ Generate minimal implementation                    │
+│   │   PROMPT: "Generate minimal code for verification:  │
+│   │            Verification: {verification_context}     │
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: over-engineering"             │
+│   ├─ Apply implementation (after review & rewrite)      │
+│   ├─ Run Red command → MUST PASS                        │
+│   └─ If fails → analyze error, fix, retry               │
+├─────────────────────────────────────────────────────────┤
+│ Step 3: 🔵 Refactor Phase                               │
+│   ├─ Analyzes code quality                              │
+│   ├─ Apply standard refactoring techniques:             │
+│   │   ├─ Eliminate code duplication                     │
+│   │   ├─ Improve naming and structure                   │
+│   │   ├─ Enhance readability                            │
+│   │   └─ Simplify logic where possible                  │
+│   ├─ Apply refactoring changes                          │
+│   ├─ Run affected-suite command → MUST STILL PASS       │
+│   └─ If fails → rollback refactoring                    │
+└─────────────────────────────────────────────────────────┘
+```
+
+Before applying any change, perform mandatory side-effect review.
+
+After a task's TDD cycle completes, locate the task ID's checkbox in the concrete tracking file resolved from schema `apply.tracks`; require exactly one match and update only it. Zero or multiple matches must STOP and return `/abel-design --change <change-name>`. Never hardcode an artifact filename or infer the tracking path from apply instructions.
+
+**Final Review & Refactor** (after all tasks complete)
+
+1. Require all target tests to be green, then run the affected suites.
+2. Re-run the same full-suite command (the full test suite), compare normalized failure identities with the recorded full-suite baseline, and require no new failures.
+
+3. Execute global code review via subagents:
+
+4. Wait for background tasks to complete; review diff patches.
+5. Rewrite patches into production-grade code (per rewriting principle).
+6. Apply refactoring changes.
+7. Re-run target, affected, and full-suite verification against the baseline.
+8. If a target test fails or the full suite has a new failure, analyze the root cause and fix or roll back.
+9. Perform final side-effect review.
+10. Report that the change is ready for archive; do not archive until the user explicitly authorizes `/opsx:archive`.
+
+**TDD Output Format**
+
+```
+## /abel-implement (TDD Mode)
+
+### Task 1/N: {task_description}
+
+🔴 Red Phase
+├─ Type: {verification_type}
+├─ Generated: {verification_files_or_none}
+├─ Run: {red_command}
+└─ Result: failed for {expected_failure_reason} ✓
+
+🟢 Green Phase
+├─ Generated: {implementation_files}
+├─ Run: {red_command}
+└─ Result: {green_expected_behavior} ✓
+
+🔵 Refactor Phase (Agent autonomous)
+├─ Optimized: {description}
+├─ Run: {affected_suite_command}
+└─ Result: target verification green ✓
+
+✓ Task complete → Next task
+
+---
+
+### All Tasks Complete
+
+🔍 Final Review & Refactor
+
+Backend Review
+├─ Files: {backend_files}
+├─ Status: Running in background...
+└─ Task ID: {task_id}
+
+Frontend Review
+├─ Files: {frontend_files}
+├─ Status: Running in background...
+└─ Task ID: {task_id}
+
+[Waiting for completion...]
+
+✓ Reviews complete
+├─ Applied: {refactoring_summary}
+├─ Target tests: green ✓
+├─ Full suite: no failures beyond baseline ✓
+└─ Ready for user-authorized archive
+
+✓ Implementation complete
+```
 <!-- ABEL:END -->

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

@@ -14,7 +14,7 @@ tags: [openspec, init, setup]
 **Steps**
 1. Detect OS and adapt command style (Unix/PowerShell).
 2. Verify `openspec` availability via `openspec --version`.
-3. If missing, stop and report `npm install -g @fission-ai/openspec` as manual remediation; do not run it automatically.
+3. If missing, install globally with `bun add --global @fission-ai/openspec@latest` when `bun --version` succeeds; otherwise use `npm install -g @fission-ai/openspec@latest`, then re-check version.
 4. Run `openspec init` (or `openspec update` for existing projects).
 5. Verify required skills:
    - Skills: `/dev-browser` `/context7-auto-research` `/grok-search`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "abelworkflow",
-  "version": "1.2.2",
+  "version": "1.2.4",
   "description": "Install AbelWorkflow into ~/.agents and create Claude, Codex, and Pi links.",
   "type": "module",
   "scripts": {
@@ -39,8 +39,6 @@
     "skills/grok-search/requirements.txt",
     "skills/grok-search/scripts/_dotenv.py",
     "skills/grok-search/scripts/groksearch_cli.py",
-    "skills/prompt-enhancer/SKILL.md",
-    "skills/prompt-enhancer/TEMPLATE.md",
     "skills/time/SKILL.md",
     "skills/time/scripts/time_cli.py"
   ],

package/extensions/k2think-compat.ts

@@ -1,40 +0,0 @@
-import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
-
-type JsonRecord = Record<string, unknown>;
-
-const MODEL_ID = "MBZUAI-IFM/K2-Think-v2";
-
-function isRecord(value: unknown): value is JsonRecord {
-  return !!value && typeof value === "object" && !Array.isArray(value);
-}
-
-function normalizeTextContent(content: unknown): unknown {
-  if (!Array.isArray(content)) return content;
-  if (
-    !content.every(
-      (part) =>
-        isRecord(part) &&
-        part.type === "text" &&
-        typeof part.text === "string",
-    )
-  ) {
-    return content;
-  }
-
-  return content.map((part) => part.text).join("");
-}
-
-export default function (pi: ExtensionAPI) {
-  pi.on("before_provider_request", (event, ctx) => {
-    if (ctx.model?.provider !== "ifm" || ctx.model.id !== MODEL_ID) return;
-    if (!isRecord(event.payload) || !Array.isArray(event.payload.messages)) return;
-
-    return {
-      ...event.payload,
-      messages: event.payload.messages.map((message) => {
-        if (!isRecord(message)) return message;
-        return { ...message, content: normalizeTextContent(message.content) };
-      }),
-    };
-  });
-}

package/skills/prompt-enhancer/SKILL.md

@@ -1,24 +0,0 @@
----
-name: prompt-enhancer
-description: |
-  Rewrite a raw prompt into a clearer prompt for a coding agent. Use only when the user explicitly asks to improve, optimize, rewrite, or structure a prompt for Codex, Claude Code, Gemini CLI, or another AI agent. Triggers: "improve this prompt", "rewrite this prompt", "optimize this prompt for Codex", "make this prompt better for an AI agent".
----
-
-# Prompt Enhancer
-
-Rewrite raw prompts into concise, structured prompts for coding agents.
-
-## Use When
-
-- The input itself is a prompt or instruction for an AI agent.
-- The user explicitly asks to improve, optimize, or rewrite that prompt.
-- The target is a coding agent such as Codex, Claude Code, or Gemini CLI.
-
-Do not use this for general writing edits like email, docs, or PR copy.
-
-## Do
-
-- Rewrite the prompt directly with the current agent, following the structure from [TEMPLATE.md](TEMPLATE.md).
-- Preserve the user's intent and explicit constraints.
-- Add structure and missing execution context only when it helps the agent act.
-- Use placeholders for unknown context instead of inventing new requirements.

package/skills/prompt-enhancer/TEMPLATE.md

@@ -1,87 +0,0 @@
-# Prompt Enhancement Template
-
-This is the system prompt used to enhance user prompts.
-
-## System Role
-
-You are an expert Prompt Engineer for Coding Agents (Claude Code, Codex, Gemini CLI).
-Your goal is to rewrite the user's raw input into a structured, high-context prompt that maximizes the agent's effectiveness.
-
-## Guidelines
-
-1. **Structure**: Use a clear Markdown structure with headers.
-2. **Chain of Thought**: Explicitly ask the agent to "Think step-by-step" or "Analyze the file structure first".
-3. **Context**: If the user's prompt is vague, add placeholders like "[Insert relevant file(s)]" or "[Specify tech stack]" in the rewritten prompt, or simply infer them if obvious.
-4. **Format**:
-   - **Context**: What is the current state? What files are involved?
-   - **Objective**: What exactly should be done?
-   - **Constraints**: specific libraries, coding styles, or "no placeholders".
-   - **Response Format**: e.g., "Return only the code block" or "Explain step-by-step".
-
-## Output Template
-
-```markdown
-# Context
-[Refined context description]
-
-# Objective
-[Precise task definition]
-
-# Step-by-Step Instructions
-1. [Step 1]
-2. [Step 2]
-...
-
-# Constraints
-- [Constraint 1]
-- [Constraint 2]
-```
-
-## Examples
-
-### Example 1: Vague Input
-
-**Input:** "Write a login component"
-
-**Enhanced Output:**
-```markdown
-# Context
-Building a React application. Need secure authentication UI component.
-
-# Objective
-Create a functional Login component with form validation.
-
-# Step-by-Step Instructions
-1. Create LoginForm component with email/password fields
-2. Add client-side validation (email format, password min length)
-3. Handle form submission with loading state
-4. Display error messages for failed attempts
-5. Provide success callback for navigation
-
-# Constraints
-- Use controlled components for form inputs
-- Follow accessibility best practices (ARIA labels, focus management)
-- Handle both validation errors and API errors distinctly
-```
-
-### Example 2: Ambiguous Bug Fix
-
-**Input:** "fix the sorting bug"
-
-**Enhanced Output:**
-```markdown
-# Context
-There is a reported bug related to sorting functionality. Need to investigate and fix.
-
-# Objective
-Identify and fix the sorting bug in the codebase.
-
-# Step-by-Step Instructions
-1. First, identify files containing sorting logic (search for "sort", "order", "compare")
-2. Review the sorting implementation and identify the issue
-3. Check edge cases: empty arrays, single items, duplicate values
-4. Implement the fix with proper type handling
-5. Add or update tests to cover the bug scenario
-
-# Constraints
-```