abelworkflow 1.2.2 → 1.2.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -3
- package/lib/config/toml.mjs +286 -2
- package/lib/paths.mjs +1 -0
- package/lib/providers/claude.mjs +69 -4
- package/lib/providers/codex.mjs +81 -3
- package/lib/providers/pi.mjs +13 -8
- package/lib/templates/codex/agents/explorer.toml +1 -1
- package/lib/templates/codex/agents/worker.toml +1 -1
- package/lib/templates/codex/config-base.toml +77 -0
- package/lib/templates/workflow/commands/abel-design.md +161 -23
- package/lib/templates/workflow/commands/abel-diagnose.md +56 -30
- package/lib/templates/workflow/commands/abel-implement.md +150 -30
- package/lib/templates/workflow/commands/abel-init.md +1 -1
- package/package.json +1 -3
- package/extensions/k2think-compat.ts +0 -40
- package/skills/prompt-enhancer/SKILL.md +0 -24
- package/skills/prompt-enhancer/TEMPLATE.md +0 -87
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
personality = "pragmatic"
|
|
2
|
+
approval_policy = "never"
|
|
3
|
+
sandbox_mode = "danger-full-access"
|
|
4
|
+
model = "gpt-5.6-sol"
|
|
5
|
+
model_reasoning_effort = "high"
|
|
6
|
+
developer_instructions = """
|
|
7
|
+
Act as the parent agent and orchestrator. Prefer direct execution for simple,
|
|
8
|
+
well-scoped tasks; delegate only when specialization or parallelism adds clear
|
|
9
|
+
value.
|
|
10
|
+
|
|
11
|
+
## Instruction Precedence
|
|
12
|
+
|
|
13
|
+
- An active workflow command takes precedence over this default orchestration
|
|
14
|
+
policy. Follow its phase rules, write boundaries, required tools,
|
|
15
|
+
verification order, and stop/go gates exactly.
|
|
16
|
+
- `/abel-design` is design-only: investigate and produce validated OpenSpec
|
|
17
|
+
artifacts without implementing product code.
|
|
18
|
+
- `/abel-implement` requires OpenSpec readiness and test-first Red, Green,
|
|
19
|
+
Refactor cycles before completion is recorded.
|
|
20
|
+
- `/abel-diagnose` requires reproduction and evidence for the root cause before
|
|
21
|
+
a regression test and minimal fix.
|
|
22
|
+
- Subagents assist inside the active phase. They never own workflow transitions
|
|
23
|
+
or bypass required user confirmation.
|
|
24
|
+
|
|
25
|
+
## Direct Work and Delegation
|
|
26
|
+
|
|
27
|
+
- For simple, local, low-risk tasks, the parent agent completes the work
|
|
28
|
+
directly when delegation overhead would exceed its value.
|
|
29
|
+
- Do not dispatch Planner or Reviewer by default. Use them only when planning
|
|
30
|
+
uncertainty or review risk justifies the extra step.
|
|
31
|
+
- Delegate with an explicit goal, bounded scope, relevant evidence, and a
|
|
32
|
+
disjoint write set. Parallelize only independent work.
|
|
33
|
+
- Keep working on non-overlapping integration or verification while delegated
|
|
34
|
+
tasks run; avoid duplicate exploration or implementation.
|
|
35
|
+
|
|
36
|
+
## Agent Roles
|
|
37
|
+
|
|
38
|
+
- `explorer`: read-only codebase mapping, symbol lookup, execution tracing, and
|
|
39
|
+
impact discovery.
|
|
40
|
+
- `planner`: pre-implementation scope, sequencing, risks, and verification when
|
|
41
|
+
the next steps are genuinely unclear.
|
|
42
|
+
- `worker`: bounded implementation, tests, and module-local fixes after the
|
|
43
|
+
active phase permits writes.
|
|
44
|
+
- `reviewer`: post-implementation correctness, regression, security, and test
|
|
45
|
+
coverage review when change risk warrants it.
|
|
46
|
+
- `default`: concise synthesis, fallback triage, and mixed-scope support that
|
|
47
|
+
does not fit a specialist.
|
|
48
|
+
|
|
49
|
+
## Phase Boundaries
|
|
50
|
+
|
|
51
|
+
- Do not dispatch implementation work during design or other read-only phases.
|
|
52
|
+
- Do not ask a Reviewer to substitute for missing reproduction, readiness, or
|
|
53
|
+
tests.
|
|
54
|
+
- Do not let a subagent broaden scope, make unresolved product decisions, or
|
|
55
|
+
cross an active command's write boundary.
|
|
56
|
+
- If a critical unknown blocks the active phase, stop and ask rather than
|
|
57
|
+
delegating around it.
|
|
58
|
+
|
|
59
|
+
## Parent Responsibility
|
|
60
|
+
|
|
61
|
+
- The parent agent owns decisions, synthesis, conflict resolution, integration,
|
|
62
|
+
final verification, and the user-facing result.
|
|
63
|
+
- Validate delegated output against the active workflow and repository
|
|
64
|
+
instructions before using it.
|
|
65
|
+
- Resolve handoffs and conflicts explicitly; never treat a subagent report as
|
|
66
|
+
automatic permission to advance phases or declare completion.
|
|
67
|
+
"""
|
|
68
|
+
|
|
69
|
+
[agents]
|
|
70
|
+
max_threads = 10
|
|
71
|
+
max_depth = 1
|
|
72
|
+
job_max_runtime_seconds = 2400
|
|
73
|
+
|
|
74
|
+
[features]
|
|
75
|
+
multi_agent = true
|
|
76
|
+
guardian_approval = true
|
|
77
|
+
shell_snapshot = true
|
|
@@ -1,37 +1,175 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: abel-design
|
|
3
|
-
description: Transform requirements into implementation-ready
|
|
3
|
+
description: Transform requirements into implementation-ready, traceable specs via gated clarification.
|
|
4
4
|
category: abel
|
|
5
|
-
tags: [abel, design,
|
|
5
|
+
tags: [abel, design, constraints, PBT, subagents]
|
|
6
6
|
argument-hint: [requirement | --change <change_name>]
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
<!-- ABEL:START -->
|
|
10
|
-
# abel-design
|
|
11
10
|
|
|
12
|
-
|
|
11
|
+
# abel-design — Gated Design Mode (Specs Only, No Implementation)
|
|
13
12
|
|
|
14
|
-
## Rules
|
|
13
|
+
## Non-Negotiable Rules (Highest Priority)
|
|
14
|
+
1. DESIGN MODE ONLY — you MUST NOT generate implementation code.
|
|
15
|
+
2. WRITE SCOPE:
|
|
16
|
+
- Before Gate A: strictly read-only; persist nothing.
|
|
17
|
+
- 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.
|
|
18
|
+
3. NEVER assume or guess — every blocking decision goes to the user (see Decision Model).
|
|
19
|
+
4. Final output: a schema-valid, fully traceable OpenSpec change with BLOCKING_DECISIONS = 0, READY_TO_IMPLEMENT.
|
|
15
20
|
|
|
16
|
-
|
|
17
|
-
- Before any write, state assumptions and unknowns explicitly. If a critical unknown could change scope, behavior, architecture, data handling, security, or an irreversible action, stop and ask the user.
|
|
18
|
-
- Retrieve project context with `rg`, `rg --files`, `git grep`, and direct file reads. Use only project evidence and research sources allowed by the repository instructions.
|
|
19
|
-
- Use unified diff patches for proposed and applied changes. Write only inside the resolved OpenSpec `changeRoot`.
|
|
20
|
-
- Do not create runtime approval or resume state.
|
|
21
|
+
**Skill Integration**: See `Stage Skill Matrix` (Design column)
|
|
21
22
|
|
|
22
|
-
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## Decision Model
|
|
26
|
+
- Maintain an in-session Decision Ledger with: `id`, `class`, `question`, `evidence`, `options`, `recommendation`, `resolution`, `status`, `affected_artifacts`.
|
|
27
|
+
- `BLOCKING_DECISIONS` is the count of unresolved, non-mechanical decisions in that ledger.
|
|
28
|
+
- Behavior decisions answer WHAT: observable outcomes, scope/non-goals, scenarios, failure behavior, data/security/privacy/compatibility policies and success criteria.
|
|
29
|
+
- Technical decisions answer HOW: interfaces, data flow, dependencies, storage/algorithms, implementation error mechanisms and key technical parameters.
|
|
30
|
+
- 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.
|
|
31
|
+
- 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.
|
|
32
|
+
- Record mechanical decisions and never re-ask them. Two or more viable options with substantive differences → escalate to a blocking decision.
|
|
33
|
+
- Do NOT create a runtime ledger or approval-state file. Materialize approved decisions only in schema artifacts.
|
|
34
|
+
|
|
35
|
+
## Phase 0 — Entry, Mode & Readiness (read-only)
|
|
36
|
+
- 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.
|
|
37
|
+
- Resolve mode:
|
|
38
|
+
- Explicit `--change <name>` → Resume. If that change does not exist, STOP and ask the user to correct the name or choose New mode.
|
|
39
|
+
- Otherwise, an exact existing-change match → Resume.
|
|
40
|
+
- Otherwise → New mode; do not silently interpret an explicit/resume-like typo as a requirement.
|
|
41
|
+
- Resolve the effective schema by precedence: explicit schema choice, existing change metadata, project config, then `spec-driven`; verify it appears in `openspec schemas --json`.
|
|
42
|
+
- 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.
|
|
43
|
+
- New mode minimum intake before ANY exploration:
|
|
44
|
+
- Problem/goal statement, AND
|
|
45
|
+
- Scope anchor (which module/directory is involved).
|
|
46
|
+
- If either intake item is missing, ask the user concisely before proceeding.
|
|
47
|
+
- 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.
|
|
48
|
+
|
|
49
|
+
## Phase 1 — Evidence Exploration (read-only)
|
|
50
|
+
- Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads.
|
|
51
|
+
- Single context boundary → main agent explores directly.
|
|
52
|
+
- Multiple independent context boundaries, when the platform permits → dispatch parallel Explore subagents:
|
|
53
|
+
- Divide by context boundary (NOT functional role); each boundary self-contained.
|
|
54
|
+
- Each subagent receives: mandatory use of the codebase retrieval policy, a clear scope, and the mandatory JSON output schema:
|
|
55
|
+
{
|
|
56
|
+
"module_name": "所探索的上下文边界",
|
|
57
|
+
"existing_structures": ["关键结构/模式"],
|
|
58
|
+
"existing_conventions": ["约定/标准"],
|
|
59
|
+
"constraints_discovered": ["硬约束"],
|
|
60
|
+
"open_questions": ["需用户输入的歧义"],
|
|
61
|
+
"dependencies": ["跨模块依赖"],
|
|
62
|
+
"risks": ["风险/阻碍"],
|
|
63
|
+
"success_criteria_hints": ["可观察的成功行为"]
|
|
64
|
+
}
|
|
65
|
+
- Validate every subagent JSON before aggregation; aggregate constraints, dependencies, risks, conflicts and questions into the Decision Ledger.
|
|
66
|
+
- Audit existing codebase patterns:
|
|
67
|
+
Use `rg`, `rg --files`, `git grep`, and direct file reads to validate against existing codebase patterns.
|
|
68
|
+
- On-demand /context7-auto-research: verify candidate libraries/APIs against official contracts.
|
|
69
|
+
- On-demand /grok-search: architectural patterns and best practices for candidate directions.
|
|
70
|
+
- PBT boundary screening: probe empty input, idempotency, ordering, size/value bounds, state-transition legality → feed the question list for Phase 2.
|
|
71
|
+
- Reference: Inspect codebase structure with `rg --files`, `git grep`, and direct file reads.
|
|
72
|
+
|
|
73
|
+
## Phase 2 — Behavior Clarification Loop (multiple rounds allowed)
|
|
74
|
+
- Cover WHAT only: goal, scope, non-goals, observable scenarios/success criteria, failure behavior, and data/security/privacy/compatibility policies.
|
|
75
|
+
- Do not choose libraries, protocols, algorithms, storage, topology or implementation parameters in this phase; route them to Phase 4.
|
|
76
|
+
- Each round asks ONLY the current highest-impact blocking questions, grouped concisely, each with evidence, impact and a recommended default.
|
|
77
|
+
- Anti-patterns (flag and reject):
|
|
78
|
+
- Observable behavior deferred to implementation ("error behavior decided while coding")
|
|
79
|
+
- Technical mechanisms smuggled in as product requirements
|
|
80
|
+
- Target behavior patterns:
|
|
81
|
+
- "Lock the account for 30 minutes after 5 consecutive failed logins."
|
|
82
|
+
- "Retain audit records for 30 days and never expose secrets in responses."
|
|
83
|
+
- "For an empty query, return an empty result within the approved latency bound."
|
|
84
|
+
- An answer that widens modules, scenarios or data boundaries → return to Phase 1 for INCREMENTAL exploration only.
|
|
85
|
+
- Loop until unresolved behavior decisions = 0.
|
|
86
|
+
|
|
87
|
+
## ⛔ Gate A — Approve Behavior Contract
|
|
88
|
+
- Present the behavior contract and affected Decision Ledger entries; the user explicitly approves goal, scope/non-goals, scenarios/success criteria and policies.
|
|
89
|
+
- Recompute the change name from the approved scope and recheck duplicates.
|
|
90
|
+
- New mode: ONLY NOW create the change with `openspec new change <change-name>` (add `--schema <schema>` only for an explicit non-default choice).
|
|
91
|
+
- Build the Artifact Plan, then materialize only behavior-class artifacts that are safe and ready.
|
|
92
|
+
|
|
93
|
+
## Artifact Plan & Write Protocol
|
|
94
|
+
- 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.
|
|
95
|
+
- Classify by the decisions the artifact carries, never by a hardcoded artifact name:
|
|
96
|
+
- behavior → Gate A
|
|
97
|
+
- technical or mixed → Gate B
|
|
98
|
+
- behavior depending on a Gate B artifact → defer until after Gate B and then follow the DAG
|
|
99
|
+
- 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.
|
|
100
|
+
- Mandatory loop for EVERY artifact write:
|
|
101
|
+
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.
|
|
102
|
+
2. Run `openspec instructions <artifact-id> --change <change-name> --json`; follow its template/rules/dependencies.
|
|
103
|
+
3. Read dependencies and existing outputs; check consistency in both directions.
|
|
104
|
+
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.
|
|
105
|
+
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.
|
|
106
|
+
|
|
107
|
+
## Phase 3 — Technical Derivation
|
|
108
|
+
- Derive the technical design from the Gate A contract, existing codebase patterns and official API contracts.
|
|
109
|
+
- Mechanical decisions → record directly in the design. Substantive trade-offs → Phase 4.
|
|
110
|
+
|
|
111
|
+
## Phase 4 — Technical Decision & Verification Loop
|
|
112
|
+
- 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.
|
|
113
|
+
- Apply the same evidence/options/recommendation format to every substantive technical decision; update the Decision Ledger.
|
|
114
|
+
- PBT applicability rule (screen with the six categories: commutativity/associativity, idempotency, round-trip, invariant preservation, monotonicity, bounds):
|
|
115
|
+
- Behavior with invariants, round-trips, idempotency, ordering, bounds or state transitions → MUST extract a property + falsification strategy.
|
|
116
|
+
- Behavior unsuited to PBT → use example/E2E/static verification and record why PBT does not apply. Do NOT force every requirement through every category.
|
|
117
|
+
- 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.
|
|
118
|
+
- Every task has exactly one schema checkbox and a verification contract using ordinary indented bullets, NEVER nested `- [ ]`/`- [x]` lines:
|
|
119
|
+
- Task ID / dependencies
|
|
120
|
+
- Requirement + stable Scenario reference
|
|
121
|
+
- Verification type: property | example | E2E | static
|
|
122
|
+
- Red command + expected failure reason
|
|
123
|
+
- Green expected behavior
|
|
124
|
+
- Affected-suite verification command
|
|
125
|
+
- Target scope/files
|
|
126
|
+
- 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.
|
|
127
|
+
- Loop until unresolved technical decisions = 0; prepare proposed remaining artifact contents/unified diffs in memory.
|
|
128
|
+
|
|
129
|
+
## ⛔ Gate B — Approve Implementation Contract
|
|
130
|
+
- Verify Phase 3/4 faithfully expand the Gate A contract; no unapproved new decisions introduced.
|
|
131
|
+
- Present substantive technical decisions, task/verification mapping and artifact materialization preview.
|
|
132
|
+
- The user explicitly approves that implementation contract.
|
|
133
|
+
- Write the remaining ready artifacts one at a time per the Artifact Plan & Write Protocol.
|
|
134
|
+
|
|
135
|
+
## Loop-Back Rules
|
|
136
|
+
- A user answer widens modules, scenarios or data boundaries → return to Phase 1.
|
|
137
|
+
- Technical analysis overturns the behavior contract → return to Phase 2; re-approve ONLY the affected decisions and synchronize all affected artifacts.
|
|
138
|
+
- Gate B finds the materialization unfaithful → return to Phase 3/4; unaffected Gate A decisions remain approved.
|
|
139
|
+
- Strict validation, verification-contract or traceability failure → return to the earliest phase that introduced the inconsistency.
|
|
140
|
+
- Never hide a late-discovered blocking question.
|
|
141
|
+
|
|
142
|
+
## Resume Rules
|
|
143
|
+
- Never infer user approval from artifact existence: `status` reporting `done` proves file completion only, not Gate approval.
|
|
144
|
+
- Never resume by fixed file names or file existence alone; the active schema decides.
|
|
145
|
+
- Algorithm:
|
|
146
|
+
1. Run `openspec status --change <change-name> --json`.
|
|
147
|
+
2. Use its `schemaName`, `changeRoot`, `artifactPaths` and statuses; read all `existingOutputPaths` and dependencies.
|
|
148
|
+
3. Check `openspec validate <change-name> --strict --type change`, template completeness, cross-artifact consistency, traceability and verification contracts.
|
|
149
|
+
4. Rebuild Gate A/B summaries and the Artifact Plan. Re-confirm every Gate approval that cannot be proven in the current conversation.
|
|
150
|
+
5. Choose the next step:
|
|
151
|
+
- Explicit Resume change not found (`change_error`) → STOP for spelling/New-mode confirmation; never create silently.
|
|
152
|
+
- Artifacts incomplete → repair/confirm the nearest safe Gate, then handle the artifacts the schema reports ready.
|
|
153
|
+
- Artifacts complete but validation/traceability fails → earliest inconsistent phase.
|
|
154
|
+
- Every artifact id listed in `applyRequires` is `done` → re-confirm any unproven Gate, then run the Exit audit.
|
|
155
|
+
- Only in-session, un-persisted analysis exists → no mid-loop resume; re-run the read-only analysis.
|
|
156
|
+
- Do NOT create runtime approval-state files; re-confirming the Gate summary IS the resume mechanism.
|
|
23
157
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
10. Give each implementation task its target files, dependencies, requirement/scenario reference, Red command and expected failure, minimal Green behavior, and affected/final verification commands.
|
|
34
|
-
11. Run `openspec validate <change-name> --strict --type change`. Finish only when validation passes, every `applyRequires` artifact is done, `apply.tracks` resolves inside `changeRoot`, artifacts agree, and no critical unknown remains.
|
|
158
|
+
## Exit Criteria
|
|
159
|
+
- [ ] `openspec validate <change-name> --strict --type change` returns zero issues
|
|
160
|
+
- [ ] Every artifact id in `applyRequires` has status `done`
|
|
161
|
+
- [ ] Schema `apply.tracks` resolves to the generated task artifact inside `changeRoot`
|
|
162
|
+
- [ ] Artifacts are consistent and traceable; every task has a valid verification contract
|
|
163
|
+
- [ ] Every task has executable property/example/E2E/static verification; no task is manual-only
|
|
164
|
+
- [ ] BLOCKING_DECISIONS = 0
|
|
165
|
+
- [ ] User has explicitly approved the reconstructed/current Gate A and Gate B summaries in this conversation
|
|
166
|
+
- [ ] Status: READY_TO_IMPLEMENT
|
|
35
167
|
|
|
36
|
-
|
|
168
|
+
## Reference
|
|
169
|
+
- `openspec context --json` / `openspec schemas --json`
|
|
170
|
+
- `openspec view` / `openspec list --changes --json` / `openspec list --specs` (conflicts with existing specs)
|
|
171
|
+
- `openspec status --change <change-name> --json` / `openspec instructions <artifact-id> --change <change-name> --json`
|
|
172
|
+
- `openspec new change <change-name>` (Gate A only)
|
|
173
|
+
- `openspec show <change-name> --json --deltas-only` when validation fails
|
|
174
|
+
- `rg -n "Constraint:|MUST|MUST NOT|INVARIANT:|PROPERTY:" openspec/` before defining new ones
|
|
37
175
|
<!-- ABEL:END -->
|
|
@@ -1,37 +1,63 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: abel-diagnose
|
|
3
|
-
description:
|
|
3
|
+
description: Parallel diagnosis with batch fix reporting via systematic root cause analysis.
|
|
4
4
|
category: abel
|
|
5
|
-
tags: [abel, diagnosis, bugfix
|
|
5
|
+
tags: [abel, diagnosis, bugfix]
|
|
6
6
|
argument-hint: <problem-description>
|
|
7
7
|
---
|
|
8
|
-
|
|
9
8
|
<!-- ABEL:START -->
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
9
|
+
**Arguments**
|
|
10
|
+
- Required: `<problem-description>` (one or more bug descriptions; comma-separated supported)
|
|
11
|
+
|
|
12
|
+
**Guardrails**
|
|
13
|
+
- Root cause first; never fix symptoms only
|
|
14
|
+
- Verify root cause hypothesis with evidence before fix
|
|
15
|
+
- Only fixes with evidence-verified root cause may be applied
|
|
16
|
+
- Every fix must include a regression test
|
|
17
|
+
- Keep changes minimal and scoped
|
|
18
|
+
- If verification fails, rollback and iterate
|
|
19
|
+
|
|
20
|
+
**Execution Model**
|
|
21
|
+
- Run detection and root-cause analysis for all issues in parallel
|
|
22
|
+
- Infer scope automatically from problem text, traces, and retrieved code context
|
|
23
|
+
- Build dependency/conflict order before any fix application
|
|
24
|
+
- Same file: force sequential fix order; same symbol: merge when compatible, otherwise sequential
|
|
25
|
+
- Independent scopes: parallel-safe
|
|
26
|
+
- Fix generation for READY issues runs fully in parallel via subagents with forked/minimal context; main agent only aggregates and resolves conflicts
|
|
27
|
+
- Patch application and final verification must run strictly sequential by dependency order
|
|
28
|
+
- Always output one consolidated batch report
|
|
29
|
+
|
|
30
|
+
**Skill Integration**: See `Stage Skill Matrix` (Diagnose column)
|
|
31
|
+
|
|
32
|
+
**Steps**
|
|
33
|
+
1. Parse input, infer scope, and split into issue list (single or multiple).
|
|
34
|
+
2. For each issue in parallel: collect logs/traces and locate code via the configured codebase retrieval policy.
|
|
35
|
+
3. For each issue in parallel: perform root cause analysis; for multi-component chains, decompose the failure chain step by step with evidence.
|
|
36
|
+
4. Build dependency/conflict graph across issues and compute safe fix order.
|
|
37
|
+
5. Verify each issue's root cause against collected evidence; only issues with a verified root cause can move to fix generation.
|
|
38
|
+
6. Spawn one subagent per READY issue to generate `unified diff patch` and regression test with minimal scoped context.
|
|
39
|
+
7. Main agent reviews/merges subagent outputs by dependency order and outputs one batch report with all issue statuses and patches.
|
|
40
|
+
8. Apply merged patches strictly sequentially by dependency order.
|
|
41
|
+
9. Run final verification strictly sequentially by the same dependency order and output verification matrix.
|
|
42
|
+
|
|
43
|
+
**Batch Output**
|
|
44
|
+
```text
|
|
45
|
+
## /abel-diagnose Batch Report
|
|
46
|
+
|
|
47
|
+
### Batch Summary
|
|
48
|
+
Total: {n} | ReadyToFix: {n_ready} | Blocked: {n_blocked}
|
|
49
|
+
|
|
50
|
+
### Issue Results
|
|
51
|
+
- [{id}] Classification: {category}/{severity} | Root Cause: {summary} | Verified: {yes|no} | Subagent: {agent_id|none} | Status: {READY|BLOCKED}
|
|
52
|
+
|
|
53
|
+
### Patch Queue (dependency order)
|
|
54
|
+
1. [{id}] [subagent:{agent_id}] {file_list}
|
|
55
|
+
{unified_diff_patch}
|
|
56
|
+
|
|
57
|
+
### Verification Matrix
|
|
58
|
+
- [{id}] Regression: {passed|failed} | Affected Suite: {passed|failed}
|
|
59
|
+
|
|
60
|
+
### Final Status
|
|
61
|
+
{FIXED|PARTIAL|NEEDS_REVIEW|BLOCKED}
|
|
62
|
+
```
|
|
37
63
|
<!-- ABEL:END -->
|
|
@@ -1,50 +1,170 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: abel-implement
|
|
3
|
-
description: Implement
|
|
3
|
+
description: Implement approved changes with mandatory TDD.
|
|
4
4
|
category: abel
|
|
5
5
|
tags: [abel, implementation, TDD]
|
|
6
6
|
argument-hint: [change_name]
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
<!-- ABEL:START -->
|
|
10
|
-
|
|
10
|
+
**Arguments**
|
|
11
|
+
- Requested: `<change_name>`
|
|
11
12
|
|
|
12
|
-
|
|
13
|
+
**Guardrails**
|
|
13
14
|
|
|
14
|
-
|
|
15
|
+
- Keep changes tightly scoped to the requested outcome; enforce side-effect review before applying any modification.
|
|
16
|
+
- Minimize documentation—avoid unnecessary comments; prefer self-explanatory code.
|
|
17
|
+
- 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.
|
|
15
18
|
|
|
16
|
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
-
|
|
19
|
+
**TDD Guardrails (mandatory)**
|
|
20
|
+
- **Red Phase**: Create or execute the task's failing executable verification ONLY; implementation code is FORBIDDEN.
|
|
21
|
+
- **Green Phase**: Write MINIMAL code to satisfy the verification; over-engineering is FORBIDDEN.
|
|
22
|
+
- **Refactor Phase**: Optimize code quality while keeping target and affected verification green and introducing no new full-suite failures.
|
|
23
|
+
- **Mandatory**: Run the task's executable verification after EVERY code change; never skip verification.
|
|
24
|
+
- **Test-First**: Each task MUST have a failing executable verification before implementation begins.
|
|
20
25
|
|
|
21
|
-
|
|
26
|
+
**Skill Integration**: See `Stage Skill Matrix` (Implement column)
|
|
22
27
|
|
|
23
|
-
|
|
24
|
-
2. Run `openspec status --change <change-name> --json`. Read `schemaName`, `changeRoot`, `artifactPaths`, `applyRequires`, and artifact states; every required artifact must be done.
|
|
25
|
-
3. Inspect `openspec schema which <schemaName> --json`. Resolve its concrete `apply.tracks` file inside `changeRoot`; never guess a task filename.
|
|
26
|
-
4. Run `openspec validate <change-name> --strict --type change` and `openspec instructions apply --change <change-name> --json`.
|
|
27
|
-
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.
|
|
28
|
-
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.
|
|
28
|
+
**Readiness Preflight (before any code or test write)**
|
|
29
29
|
|
|
30
|
-
|
|
30
|
+
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.
|
|
31
|
+
2. Run `openspec status --change <change-name> --json`; read `schemaName`, `changeRoot`, `artifactPaths`, `applyRequires`, and `artifacts`.
|
|
32
|
+
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`.
|
|
33
|
+
4. Every artifact id in `applyRequires` must have status `done`; array presence or a general completion flag is insufficient.
|
|
34
|
+
5. Run `openspec validate <change-name> --strict --type change`; require zero issues.
|
|
35
|
+
6. Read every planning artifact reported by `artifactPaths`, then run `openspec instructions apply --change <change-name> --json` and follow the returned apply contract.
|
|
36
|
+
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.
|
|
37
|
+
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.
|
|
38
|
+
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.
|
|
31
39
|
|
|
32
|
-
|
|
40
|
+
**Tool Routing**:
|
|
41
|
+
- **TDD Cycle**: Autonomous refactoring
|
|
42
|
+
- **Final Review** (after all tasks):
|
|
43
|
+
- Backend refactor (subagents)
|
|
44
|
+
- Frontend refactor (subagents)
|
|
45
|
+
- **E2E tasks** → `/dev-browser`
|
|
33
46
|
|
|
34
|
-
|
|
47
|
+
After preflight, detect the project's verification tooling and work through the tracked tasks sequentially.
|
|
35
48
|
|
|
36
|
-
|
|
37
|
-
2. Green: apply the minimal implementation patch and rerun the Red command until it passes.
|
|
38
|
-
3. Refactor: simplify only where useful, keeping the target and affected tests green after each code change.
|
|
39
|
-
4. Run the task's affected verification. Review the diff for unintended behavior, unrelated edits, security issues, and leaked runtime state.
|
|
40
|
-
5. Leave the task incomplete in `apply.tracks` until final verification succeeds.
|
|
49
|
+
**TDD Cycle (per task)**
|
|
41
50
|
|
|
42
|
-
|
|
51
|
+
Consume these ordinary indented bullets from the task verification contract, never Markdown checkboxes:
|
|
52
|
+
- verification type: property | example | E2E | static
|
|
53
|
+
- Red command and expected failure reason
|
|
54
|
+
- Green expected behavior
|
|
55
|
+
- affected-suite command
|
|
56
|
+
- target scope/files
|
|
43
57
|
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
|
|
49
|
-
|
|
58
|
+
- Red must fail because of the target defect described by the contract.
|
|
59
|
+
- If the failure reason differs or the command is invalid, STOP and return `/abel-design --change <change-name>`; do not improvise a replacement contract.
|
|
60
|
+
- A non-behavior-change task starts with its specified failing executable static verification.
|
|
61
|
+
- A manual-only task is not implementation-ready; STOP and return `/abel-design --change <change-name>`.
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
┌─────────────────────────────────────────────────────────┐
|
|
65
|
+
│ Step 1: 🔴 Red Phase - Execute Contract Verification │
|
|
66
|
+
│ ├─ Use the contract's verification type and scope │
|
|
67
|
+
│ ├─ Generate the required failing verification via │
|
|
68
|
+
│ │ PROMPT: "Generate failing verification for: {task}│
|
|
69
|
+
│ │ Context: {code_context} │
|
|
70
|
+
│ │ Output: unified diff patch │
|
|
71
|
+
│ │ FORBIDDEN: implementation code" │
|
|
72
|
+
│ ├─ Apply verification code (after review) │
|
|
73
|
+
│ ├─ Run Red command → MUST FAIL for expected reason │
|
|
74
|
+
│ └─ If it passes or fails differently → STOP │
|
|
75
|
+
├─────────────────────────────────────────────────────────┤
|
|
76
|
+
│ Step 2: 🟢 Green Phase - Minimal Implementation │
|
|
77
|
+
│ ├─ Generate minimal implementation │
|
|
78
|
+
│ │ PROMPT: "Generate minimal code for verification: │
|
|
79
|
+
│ │ Verification: {verification_context} │
|
|
80
|
+
│ │ Context: {code_context} │
|
|
81
|
+
│ │ Output: unified diff patch │
|
|
82
|
+
│ │ FORBIDDEN: over-engineering" │
|
|
83
|
+
│ ├─ Apply implementation (after review & rewrite) │
|
|
84
|
+
│ ├─ Run Red command → MUST PASS │
|
|
85
|
+
│ └─ If fails → analyze error, fix, retry │
|
|
86
|
+
├─────────────────────────────────────────────────────────┤
|
|
87
|
+
│ Step 3: 🔵 Refactor Phase │
|
|
88
|
+
│ ├─ Analyzes code quality │
|
|
89
|
+
│ ├─ Apply standard refactoring techniques: │
|
|
90
|
+
│ │ ├─ Eliminate code duplication │
|
|
91
|
+
│ │ ├─ Improve naming and structure │
|
|
92
|
+
│ │ ├─ Enhance readability │
|
|
93
|
+
│ │ └─ Simplify logic where possible │
|
|
94
|
+
│ ├─ Apply refactoring changes │
|
|
95
|
+
│ ├─ Run affected-suite command → MUST STILL PASS │
|
|
96
|
+
│ └─ If fails → rollback refactoring │
|
|
97
|
+
└─────────────────────────────────────────────────────────┘
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
Before applying any change, perform mandatory side-effect review.
|
|
101
|
+
|
|
102
|
+
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.
|
|
103
|
+
|
|
104
|
+
**Final Review & Refactor** (after all tasks complete)
|
|
105
|
+
|
|
106
|
+
1. Require all target tests to be green, then run the affected suites.
|
|
107
|
+
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.
|
|
108
|
+
|
|
109
|
+
3. Execute global code review via subagents:
|
|
110
|
+
|
|
111
|
+
4. Wait for background tasks to complete; review diff patches.
|
|
112
|
+
5. Rewrite patches into production-grade code (per rewriting principle).
|
|
113
|
+
6. Apply refactoring changes.
|
|
114
|
+
7. Re-run target, affected, and full-suite verification against the baseline.
|
|
115
|
+
8. If a target test fails or the full suite has a new failure, analyze the root cause and fix or roll back.
|
|
116
|
+
9. Perform final side-effect review.
|
|
117
|
+
10. Report that the change is ready for archive; do not archive until the user explicitly authorizes `/opsx:archive`.
|
|
118
|
+
|
|
119
|
+
**TDD Output Format**
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
## /abel-implement (TDD Mode)
|
|
123
|
+
|
|
124
|
+
### Task 1/N: {task_description}
|
|
125
|
+
|
|
126
|
+
🔴 Red Phase
|
|
127
|
+
├─ Type: {verification_type}
|
|
128
|
+
├─ Generated: {verification_files_or_none}
|
|
129
|
+
├─ Run: {red_command}
|
|
130
|
+
└─ Result: failed for {expected_failure_reason} ✓
|
|
131
|
+
|
|
132
|
+
🟢 Green Phase
|
|
133
|
+
├─ Generated: {implementation_files}
|
|
134
|
+
├─ Run: {red_command}
|
|
135
|
+
└─ Result: {green_expected_behavior} ✓
|
|
136
|
+
|
|
137
|
+
🔵 Refactor Phase (Agent autonomous)
|
|
138
|
+
├─ Optimized: {description}
|
|
139
|
+
├─ Run: {affected_suite_command}
|
|
140
|
+
└─ Result: target verification green ✓
|
|
141
|
+
|
|
142
|
+
✓ Task complete → Next task
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
### All Tasks Complete
|
|
147
|
+
|
|
148
|
+
🔍 Final Review & Refactor
|
|
149
|
+
|
|
150
|
+
Backend Review
|
|
151
|
+
├─ Files: {backend_files}
|
|
152
|
+
├─ Status: Running in background...
|
|
153
|
+
└─ Task ID: {task_id}
|
|
154
|
+
|
|
155
|
+
Frontend Review
|
|
156
|
+
├─ Files: {frontend_files}
|
|
157
|
+
├─ Status: Running in background...
|
|
158
|
+
└─ Task ID: {task_id}
|
|
159
|
+
|
|
160
|
+
[Waiting for completion...]
|
|
161
|
+
|
|
162
|
+
✓ Reviews complete
|
|
163
|
+
├─ Applied: {refactoring_summary}
|
|
164
|
+
├─ Target tests: green ✓
|
|
165
|
+
├─ Full suite: no failures beyond baseline ✓
|
|
166
|
+
└─ Ready for user-authorized archive
|
|
167
|
+
|
|
168
|
+
✓ Implementation complete
|
|
169
|
+
```
|
|
50
170
|
<!-- ABEL:END -->
|
|
@@ -14,7 +14,7 @@ tags: [openspec, init, setup]
|
|
|
14
14
|
**Steps**
|
|
15
15
|
1. Detect OS and adapt command style (Unix/PowerShell).
|
|
16
16
|
2. Verify `openspec` availability via `openspec --version`.
|
|
17
|
-
3. If missing,
|
|
17
|
+
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.
|
|
18
18
|
4. Run `openspec init` (or `openspec update` for existing projects).
|
|
19
19
|
5. Verify required skills:
|
|
20
20
|
- Skills: `/dev-browser` `/context7-auto-research` `/grok-search`
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "abelworkflow",
|
|
3
|
-
"version": "1.2.
|
|
3
|
+
"version": "1.2.3",
|
|
4
4
|
"description": "Install AbelWorkflow into ~/.agents and create Claude, Codex, and Pi links.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"scripts": {
|
|
@@ -39,8 +39,6 @@
|
|
|
39
39
|
"skills/grok-search/requirements.txt",
|
|
40
40
|
"skills/grok-search/scripts/_dotenv.py",
|
|
41
41
|
"skills/grok-search/scripts/groksearch_cli.py",
|
|
42
|
-
"skills/prompt-enhancer/SKILL.md",
|
|
43
|
-
"skills/prompt-enhancer/TEMPLATE.md",
|
|
44
42
|
"skills/time/SKILL.md",
|
|
45
43
|
"skills/time/scripts/time_cli.py"
|
|
46
44
|
],
|