abelworkflow 0.1.0

package/.gitignore

@@ -0,0 +1,13 @@
+*/.venv/
+*Cache/
+*node_modules/
+*.env
+*.log
+*/node_modules/
+*/tmp/
+skills/dev-browser/profiles/
+skills/dev-browser/tmp/
+*/dist/
+*/build/
+.claude/
+.codex/

package/.skill-lock.json

@@ -0,0 +1,29 @@
+{
+  "version": 3,
+  "skills": {
+    "git-commit": {
+      "source": "github/awesome-copilot",
+      "sourceType": "github",
+      "sourceUrl": "https://github.com/github/awesome-copilot.git",
+      "skillPath": "skills/git-commit/SKILL.md",
+      "skillFolderHash": "883a6a7466f55a9cd9f22cf1cce2d9333fc9b998",
+      "installedAt": "2026-03-12T08:25:08.313Z",
+      "updatedAt": "2026-03-12T08:25:08.313Z"
+    }
+  },
+  "dismissed": {
+    "findSkillsPrompt": true
+  },
+  "lastSelectedAgents": [
+    "amp",
+    "cline",
+    "codex",
+    "cursor",
+    "gemini-cli",
+    "github-copilot",
+    "kimi-cli",
+    "opencode",
+    "claude-code",
+    "crush"
+  ]
+}

package/AGENTS.md

@@ -0,0 +1,45 @@
+# 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
+
+## Context Rules
+
+- Use `mcp__augment-context-engine__codebase-retrieval` as the primary codebase search tool
+- Rely only on project code plus `grok/context7` results
+- If information is insufficient or uncertain, state it explicitly
+
+## Workflow
+
+```
+/oc:init → /oc:research → /oc:plan → /oc:implementation(TDD)
+                                   ↘ /oc:diagnose (bug fix)
+```
+
+## Universal Constraints
+
+1. Use `unified diff patch` format for proposed/applied changes
+2. Require confidence ≥90% before applying changes
+
+## Stage Skill Matrix
+
+| Skill | Research | Plan | Implement | Diagnose | Capability & Triggers |
+| --- | :---: | :---: | :---: | :---: | --- |
+| /sequential-think | ✅ | ✅ | ❌ | ✅ | Multi-step reasoning, hypothesis testing. Trigger: 3+ interconnected components |
+| /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 |
+| /confidence-check | ❌ | ✅ | ✅ | ✅ | Readiness verification. Trigger: before implementation/fix (≥90%) |
+| /time | ○ | ✅ | ✅ | ○ | Time/timezone operations. Trigger: scheduling logic |
+
+Legend: ✅ Primary, ○ Optional, ❌ Forbidden
+
+OpenSpec commands: `/opsx:new` `/opsx:ff` `/opsx:archive` `openspec view` `openspec status`

package/README.md

@@ -0,0 +1,147 @@
+# AbelWorkflow
+
+Codex、OpenCode、Claude Code 的 Skills 和 Commands 配置仓库。
+
+## 目录结构
+
+```
+.agents/
+├── skills/              # 技能目录
+│   ├── time/                    # 时间与时区工具
+│   ├── grok-search/             # 增强型网页搜索
+│   ├── sequential-think/        # 多步推理引擎
+│   ├── dev-browser/             # 浏览器自动化
+│   ├── context7-auto-research/   # 自动文档检索
+│   ├── confidence-check/        # 实施前信心评估
+│   ├── git-commit/            # Git 提交助手
+│   └── prompt-enhancer/     # 提示词优化器
+├── commands/           # 命令目录
+│   └── oc/                # 工作流命令
+├── AGENTS.md         # Agent 全局系统 prompts
+└── README.md
+```
+
+## 技能概览
+
+| 技能 | 描述 |
+|------|------|
+| **time** | 时间和时区工具，获取当前时间及时区转换 |
+| **grok-search** | 通过 Grok API 增强网页搜索与实时内容检索 |
+| **sequential-think** | 多步推理引擎，支持假设检验与分支的复杂分析 |
+| **dev-browser** | 浏览器自动化，支持导航、表单填写、截图与数据提取 |
+| **context7-auto-research** | 自动从 Context7 获取最新库/框架文档 |
+| **confidence-check** | 实施前置信度评估（≥90%），含架构合规与根因识别 |
+| **git-commit** | Conventional Commits 规范提交，智能暂存与消息生成 |
+| **prompt-enhancer** | CoT 推理优化 AI 编码提示词，模糊请求转结构化指令 |
+
+## 命令概览
+
+| 命令 | 描述 |
+|------|------|
+| **/oc:init** | 初始化 OpenSpec 环境并验证工具链 |
+| **/oc:research** | 结构化需求探索与约束集生成（不实施） |
+| **/oc:plan** | 将已批准变更细化为零决策可执行方案 |
+| **/oc:implementation** | 以 TDD 方式实施已批准的变更 |
+| **/oc:diagnose** | 系统化根因分析与批量修复报告 |
+
+## 工作流
+
+```
+/oc:init → /oc:research → /oc:plan → /oc:implementation(TDD)
+                                   ↘ /oc:diagnose (bug fix)
+```
+
+## 配置说明
+
+- **目录位置**:
+  - Linux/macOS: `~/.agents/`
+  - Windows: `%USERPROFILE%\.agents\`（PowerShell: `$HOME\.agents`）
+- **AGENTS.md**: Agent 全局系统 prompts 配置
+
+## 安装与更新
+
+### 推荐：`npx` 一键安装
+
+```bash
+# 安装到 ~/.agents，并自动完成 ~/.claude / ~/.codex 的链接
+npx abelworkflow
+
+# 更新到最新发布版本
+npx abelworkflow@latest
+```
+
+> 说明：
+> - npm 发布包名必须使用小写，所以实际可执行命令是 `npx abelworkflow`。
+> - 仓库显示名可以继续叫 `AbelWorkflow`，但不建议承诺 `npx AbelWorkflow`，这不符合 npm 当前命名规则。
+> - 一键安装会把仓库内容同步到 `~/.agents`，并自动建立下文 README 中的链接关系，无需再手动执行 `ln -s`。
+
+### 备用：Git 克隆安装
+
+### Linux/macOS（bash/zsh）
+
+```bash
+# 首次安装
+git clone https://github.com/abelxiaoxing/AbelWorkflow ~/.agents
+
+# 更新
+git -C ~/.agents pull
+```
+
+### Windows（PowerShell）
+
+```powershell
+# 首次安装
+git clone https://github.com/abelxiaoxing/AbelWorkflow "$HOME\.agents"
+
+# 更新
+git -C "$HOME\.agents" pull
+```
+
+## 链接到 Claude Code / Codex（`npx` 会自动完成）
+
+> 目标：把本仓库作为「单一来源」，通过符号链接同步到 `~/.claude/` 和 `~/.codex/`。以后只需 `git -C ~/.agents pull`，两边配置会自动更新。
+
+### 映射关系（本仓库 → 配置目录）
+
+| 本仓库 | Claude Code | Codex | 说明 |
+|---|---|---|---|
+| `AGENTS.md` | `~/.claude/CLAUDE.md` | `~/.codex/AGENTS.md` | 全局系统提示词/规则 |
+| `skills/<skill>/` | `~/.claude/skills/<skill>/` | `~/.codex/skills/<skill>/` | Skills（每个目录一个技能） |
+| `commands/oc/` | `~/.claude/commands/oc/` | `~/.codex/prompts/*.md` | Claude 读 `commands/`；Codex 读 `prompts/` |
+
+### Linux/macOS（bash/zsh）
+
+```bash
+AGENTS_DIR="$HOME/.agents"
+
+# Claude Code
+mkdir -p "$HOME/.claude/commands" "$HOME/.claude/skills"
+ln -s "$AGENTS_DIR/AGENTS.md" "$HOME/.claude/CLAUDE.md"
+ln -s "$AGENTS_DIR/commands/oc" "$HOME/.claude/commands/oc"
+for d in "$AGENTS_DIR/skills/"*; do
+  [ -d "$d" ] && ln -s "$d" "$HOME/.claude/skills/"
+done
+
+# Codex
+mkdir -p "$HOME/.codex/skills" "$HOME/.codex/prompts"
+ln -s "$AGENTS_DIR/AGENTS.md" "$HOME/.codex/AGENTS.md"
+for d in "$AGENTS_DIR/skills/"*; do
+  [ -d "$d" ] && ln -s "$d" "$HOME/.codex/skills/"
+done
+ln -s "$AGENTS_DIR/commands/oc/init.md" "$HOME/.codex/prompts/init.md"
+ln -s "$AGENTS_DIR/commands/oc/research.md" "$HOME/.codex/prompts/research.md"
+ln -s "$AGENTS_DIR/commands/oc/plan.md" "$HOME/.codex/prompts/plan.md"
+ln -s "$AGENTS_DIR/commands/oc/implementation.md" "$HOME/.codex/prompts/implementation.md"
+ln -s "$AGENTS_DIR/commands/oc/diagnose.md" "$HOME/.codex/prompts/diagnose.md"
+```
+
+> 提示：
+> - 如果提示 `File exists`，说明目标路径已存在：先备份/删除原文件（例如 `mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak`），再重新执行 `ln -s`。
+> - 不建议把整个 `skills/` 目录直接链接成 `~/.codex/skills`，否则可能遮住 Codex 自带的 `~/.codex/skills/.system/`。
+
+### 验证（可选）
+
+```bash
+ls -la "$HOME/.claude/CLAUDE.md" "$HOME/.claude/commands/oc"
+ls -la "$HOME/.codex/AGENTS.md" "$HOME/.codex/prompts/"{init,research,plan,implementation,diagnose}.md
+```

package/bin/abelworkflow.mjs

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+import "../lib/cli.mjs";

package/commands/oc/diagnose.md

@@ -0,0 +1,63 @@
+---
+name: OC:Diagnose
+description: Parallel diagnosis with batch fix reporting via systematic root cause analysis.
+category: OC
+tags: [diagnosis, bugfix]
+argument-hint: <problem-description>
+---
+<!-- OC: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
+- Confidence gate: ≥90% before applying fixes
+- 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 `mcp__augment-context-engine__codebase-retrieval`.
+3. For each issue in parallel: perform root cause analysis; use `/sequential-think` for multi-component chains.
+4. Build dependency/conflict graph across issues and compute safe fix order.
+5. Run `/confidence-check` per issue; only issues with score ≥90% 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
+## /oc:diagnose Batch Report
+
+### Batch Summary
+Total: {n} | ReadyToFix: {n_ready} | Blocked: {n_blocked}
+
+### Issue Results
+- [{id}] Classification: {category}/{severity} | Root Cause: {summary} | Confidence: {score} | 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}
+```
+<!-- OC:END -->

package/commands/oc/implementation.md

@@ -0,0 +1,157 @@
+---
+name: OC:Implementation
+description: Implement approved changes with mandatory TDD.
+category: OC
+tags: [openspec, implementation, TDD]
+argument-hint: [change_name]
+---
+
+<!-- OC:START -->
+**Arguments**
+- Requested: `<change_name>`
+
+**Guardrails**
+
+**Guardrails**
+
+- 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.
+
+**TDD Guardrails (mandatory)**
+- **Red Phase**: Generate failing tests ONLY; implementation code is FORBIDDEN.
+- **Green Phase**: Write MINIMAL code to pass tests; over-engineering is FORBIDDEN.
+- **Refactor Phase**: Optimize code quality while keeping ALL tests passing.
+- **Mandatory**: Run tests after EVERY code change; never skip verification.
+- **Test-First**: Each task MUST have a failing test before implementation begins.
+
+**Skill Integration**: See `Stage Skill Matrix` (Implement column)
+
+**Tool Routing**:
+- **TDD Cycle**: Autonomous refactoring
+- **Final Review** (after all tasks):
+  - Backend refactor (subagents)
+  - Frontend refactor (subagents)
+- **E2E tasks** → `/dev-browser`
+
+1. Run `openspec view` to inspect current project status and review `Active Changes`; ask the user to confirm which change folder (`<change_name>`) they want to implement.
+2. Check artifact status: `openspec status --change <change_name>`
+3. Get apply instructions: `openspec instructions apply --change <change_name>`
+4. Detect test framework: identify project's testing setup (pytest/jest/vitest/etc.)
+5. Work through tasks sequentially; for each task, execute the **TDD Cycle** below.
+
+**TDD Cycle (per task)**
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Step 0: Pre-Check                                       │
+│   └─ /confidence-check → require ≥90% to proceed        │
+├─────────────────────────────────────────────────────────┤
+│ Step 1: 🔴 Red Phase - Generate Failing Test            │
+│   ├─ Analyze task → determine test type                 │
+│   │   ├─ Backend → pytest/jest                          │
+│   │   ├─ Frontend → vitest/jest                         │
+│   │   └─ E2E → dev-browser                              │
+│   ├─ Generate test via                                  │
+│   │   PROMPT: "Generate failing test for: {task}        │
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: implementation code"          │
+│   ├─ Apply test code (after review)                     │
+│   ├─ Run test → MUST FAIL                               │
+│   └─ If passes → test invalid, regenerate               │
+├─────────────────────────────────────────────────────────┤
+│ Step 2: 🟢 Green Phase - Minimal Implementation         │
+│   ├─ Generate minimal implementation                    │
+│   │   PROMPT: "Generate minimal code to pass test:      │
+│   │            Test: {test_code}                        │
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: over-engineering"             │
+│   ├─ Apply implementation (after review & rewrite)      │
+│   ├─ Run test → 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 test → MUST STILL PASS                         │
+│   └─ If fails → rollback refactoring                    │
+└─────────────────────────────────────────────────────────┘
+```
+
+6. Before applying any change, perform mandatory side-effect review.
+
+7. After TDD cycle completes for a task, mark as `- [x]` in `tasks.md`.
+
+**Final Review & Refactor** (after all tasks complete)
+
+8. Run all tests to ensure everything passes.
+
+9. Execute global code review via subagents:
+
+10. Wait for background tasks to complete; review diff patches.
+11. Rewrite patches into production-grade code (per rewriting principle).
+12. Apply refactoring changes.
+13. Run all tests → MUST ALL PASS.
+14. If any test fails → analyze root cause, fix or rollback.
+15. Perform final side-effect review.
+16. Run `openspec archive <change_name>` or `/opsx:archive`.
+
+**TDD Output Format**
+
+```
+## /oc:implementation (TDD Mode)
+
+### Task 1/N: {task_description}
+
+📋 Confidence Check: {score}% {status}
+
+🔴 Red Phase
+├─ Generated: tests/{test_file}
+├─ Run: {test_command}
+└─ Result: {count} failed ✓ (expected)
+
+🟢 Green Phase
+├─ Generated: src/{impl_file}
+├─ Run: {test_command}
+└─ Result: {count} passed ✓
+
+🔵 Refactor Phase (Agent autonomous)
+├─ Optimized: {description}
+├─ Run: {test_command}
+└─ Result: {count} passed ✓
+
+✓ 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}
+├─ Tests: {count} passed ✓
+└─ Ready for archive
+
+✓ Implementation complete
+```
+<!-- OC:END -->

package/commands/oc/init.md

@@ -0,0 +1,27 @@
+---
+name: OC:Init
+description: Initialize OpenSpec environment and validate required tooling.
+category: OC
+tags: [openspec, init, setup]
+---
+
+<!-- OC:START -->
+**Guardrails**
+- Complete steps in order; stop on failure
+- Preserve existing config; do not overwrite without confirmation
+- Provide actionable remediation when a step fails
+
+**Steps**
+1. Detect OS and adapt command style (Unix/PowerShell).
+2. Verify `openspec` availability via `openspec --version`.
+3. If missing, `npm install -g @fission-ai/openspec@latest`, then re-check version.
+4. Run `openspec init` (or `openspec update` for existing projects).
+5. Verify required capability:
+   - MCP: `mcp__augment-context-engine__codebase-retrieval`
+   - Skills: `/dev-browser` `/sequential-think` `/context7-auto-research` `/grok-search` `/confidence-check`
+6. Output summary with ✓/✗:
+   - OpenSpec installation
+   - Project initialization
+   - MCP availability
+   - Required skills availability
+<!-- OC:END -->

package/commands/oc/plan.md

@@ -0,0 +1,88 @@
+---
+name: OC:Plan
+description: Refine approved change into a zero-decision executable plan.
+category: OC
+tags: [OC, plan, PBT]
+argument-hint: [change_name]
+---
+<!-- OC:START -->
+**Guardrails**
+- Strictly adhere to **OpenSpec** rules when writing **standardized spec-structured projects**.
+- The goal of this phase is to eliminate ALL decision points from the task flow—implementation should be pure mechanical execution.
+- Do not proceed to implementation until every ambiguity is resolved and every constraint is explicitly documented.
+- Every requirement must have Property-Based Testing (PBT) properties defined—focus on invariants, not just example-based tests.
+- If constraints cannot be fully specified, escalate back to the user or return to the research phase rather than making assumptions.
+- Refer to `openspec/AGENTS.md` for additional conventions; run `openspec update` if the file is missing.
+
+**Skill Integration**: See `Stage Skill Matrix` (Plan column)
+
+**FORBIDDEN**: Direct implementation code generation
+
+**Steps**
+1. Run `openspec view` to display all **Active Changes**, then confirm with the user which change folder (`<change_name>`) they wish to refine into a zero-decision plan.
+
+2. Navigate to `openspec/changes/<change_name>/` and review existing artifacts:
+   - Check `openspec status --change <change_name>` for artifact completion
+   - Use `openspec instructions specs --change <change_name>` for specs guidance
+
+3. **Implementation Analysis**: Invoke skills to perform systematic analysis to derive a plan:
+   ```
+   # First, invoke /sequential-think skill for systematic analysis if proposal has 3+ interconnected requirements
+
+   /sequential-think: "Analyze change <change_name> systematically: Break down into components, identify dependencies, evaluate architectural trade-offs, and surface potential conflicts."
+   
+   # Then invoke /context7-auto-research skill to validate framework/library choices
+
+   /context7-auto-research: "For each technology mentioned in change <change_name>, retrieve official documentation patterns and best practices."
+   ```
+   Produce a consolidated, constraint-complete plan and list any missing constraints as questions to the user.
+
+4. **Uncertainty Elimination Audit**: Invoke skills to detect and eliminate remaining ambiguities:
+   ```
+   # First, use augment-context-engine to validate against existing codebase patterns
+   mcp__augment-context-engine__codebase-retrieval: "Search for existing implementations similar to change <change_name>. Keywords: [key concepts from proposal]"
+   # Then audit for ambiguities directly and list them explicitly
+   Review change <change_name> for decision points that remain unspecified. For each: [AMBIGUITY] <description> → [REQUIRED CONSTRAINT] <what must be specified>.
+   Identify implicit assumptions in change <change_name>. For each: [ASSUMPTION] <description> → [EXPLICIT CONSTRAINT NEEDED] <concrete specification>.
+   ```
+   
+   **Anti-Pattern Detection** (flag and reject):
+   - Information collection without decision boundaries (e.g., "JWT vs OAuth2 vs session—all viable")
+   - Technical comparisons without selection criteria
+   - Deferred decisions marked as "to be determined during implementation"
+   
+   **Target Pattern** (required for approval):
+   - Explicit technology choices with parameters (e.g., "JWT with accessToken TTL=15min, refreshToken TTL=7days")
+   - Concrete algorithm selections with configurations (e.g., "bcrypt with cost factor=12")
+   - Precise behavioral rules (e.g., "Lock account for 30min after 5 failed login attempts")
+   
+   Iterate with user until ALL ambiguities are resolved into explicit constraints.
+
+5. **PBT Property Extraction**: Invoke skills to derive testable invariants:
+   ```
+   "Extract Property-Based Testing properties from change <change_name>. For each requirement: [INVARIANT] <must always hold> → [FALSIFICATION STRATEGY] <how to generate counterexamples>."
+   "Define system properties for change <change_name>: [PROPERTY] <name> | [DEFINITION] <formal description> | [BOUNDARY CONDITIONS] <edge cases> | [COUNTEREXAMPLE GENERATION] <approach>."
+   ```
+   
+   **PBT Property Categories to Extract**:
+   - **Commutativity/Associativity**: Order-independent operations
+   - **Idempotency**: Repeated operations yield same result
+   - **Round-trip**: Encode→Decode returns original
+   - **Invariant Preservation**: State constraints maintained across operations
+   - **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
+   - **Bounds**: Value ranges, size limits, rate constraints
+
+**Reference**
+- Use `openspec show <change_name> --json --deltas-only` to inspect proposal structure when validation fails.
+- Use `openspec list --specs` to check for conflicts with existing specifications.
+- Search existing patterns with `rg -n "INVARIANT:|PROPERTY:|Constraint:" openspec/` before defining new ones.
+- For complex proposals, consider running steps 2-4 iteratively on sub-components.
+- Use `AskUserQuestions` for ANY ambiguity—do not assume or guess.
+
+**Exit Criteria**
+A proposal is ready to exit the Plan phase only when:
+- [ ] Zero ambiguities remain (verified by step 4 audit)
+- [ ] All PBT properties documented with falsification strategies
+- [ ] `openspec validate <change_name> --strict` returns zero issues
+- [ ] User has explicitly approved all constraint decisions
+<!-- OC:END -->