openclaw-engineering-harness（OpenClaw engineering harness 搜索）

***

name: openclaw-engineering-harness description: A single skill for engineering workflow loop, responsible for request clarification, code discovery, tool-driven execution, smallest coherent changes, validation, and preparing publishable artifacts. allowed-tools:

• Read
• LS
• Glob
• Grep
• SearchCodebase
• Edit
• MultiEdit
• Write
• TodoWrite
• AskUserQuestion
• Bash(git status:\*)
• Bash(git diff:\*)
• Bash(git checkout:\*)
• Bash(git add:\*)
• Bash(git commit:\*)
• Bash(git reset:\*)
• Bash(python3:\*)

when\_to\_use: Use when the task requires a single skill that can clarify scope, inspect a codebase, implement the smallest coherent change, run validation, audit the publishable surface, and summarize delivery evidence.

***

Engineering Workflow

This Skill combines request clarification, implementation execution, validation closure, runtime assistance, and artifact preparation into a single, independently distributable engineering loop.

🚀 How to Use This Skill

As a user, you can invoke this skill in your prompts using the following methods:

Method 1: Explicitly by Name (Recommended) Simply mention the skill name and ask the AI to follow its workflow:

"Please use the openclaw-engineering-harness skill to build \[your task]. Start from the clarify phase and confirm the goal and scope with me before proceeding."

Method 2: Implicitly by Keywords Describe your task using the core concepts of this skill, and the AI will automatically trigger it:

"Help me implement \[your task]. Before starting, please clarify scope, ensure you make the smallest coherent change, and finally run validation and summarize delivery evidence."

Method 3: Enforcing the Phases You can command the AI to strictly follow the 5 phases defined in this skill:

"Execute \[your task] by strictly following these phases: clarify, map, implement, verify, and deliver. Stop and wait for my approval after each phase."

***

Always Start Here (For AI Agent)

1. Read refs/request-shape.md first to confirm the goal, scope, success criteria, and constraints.
2. Read refs/capability-model.md to understand the 3-layer runtime skeleton (tool/state/policy), tool priorities, and state progression rules.
3. Read refs/execution-loop.md to proceed in the exact order: discover -> design -> implement -> verify -> deliver.
4. When you need to generate a structured execution plan, run scripts/run_workflow.py with policies/workflow-policy.json, tool/tool-config.json, state/state-policy.json, and policy/constraint-policy.json.
5. Memory System: Read refs/memory-system.md. Always check .claude/MEMORY.md (if it exists) to learn user preferences and project context before starting. Update it during the deliver phase.
6. When you need to evaluate constraints independently, run scripts/run_constraints.py to output rule matches, passes, and blocking conclusions.
7. When preparing publishable artifacts, read refs/export-policy.md and refs/release-checklist.md, then run scripts/run_audit.py with policies/export-audit-policy.json.

Core Workflow

• Clarify the task shape first: If the goal, boundary, validation criteria, or memory context are missing, ask or retrieve them first. Never modify code with vague assumptions.
• Build a minimal working map first: Entry points, dependencies, impact areas, validation points, and rollback points must come in pairs.
• Make the smallest coherent change: Reuse existing patterns. Avoid unrelated refactoring, naming drift, or introducing secondary mechanisms.
• Verify immediately after changes: Prioritize running checks that match the impact area. Record passed items, failed items, and uncovered risks.
• Keep runtime and documentation consistent during delivery: Verify first, summarize the results, extract new lessons learned to the .claude/MEMORY.md system, and only then generate publishable artifacts.

Output Contract

• Implementation Plan: Goal, impact area, change strategy, rollback method.
• Change Results: What was done, why it was done, what areas were affected.
• Validation Record: What was executed, the results, remaining risks.
• Distribution Summary: Export directory, checklist, audit conclusions, and future recommendations.

Runtime Surface

• tool/tool-config.json: Defines tool groups, tools required per phase, and the boundary between single-skill and standard library.
• state/state-policy.json: Defines state sequence, phase bindings, and minimum inputs required for each state.
• policy/constraint-policy.json: Defines deliverable constraint rules to determine if the 3-layer skeleton still satisfies boundaries.
• scripts/run_workflow.py: Reads structured requests, combines tool/state/policy layer results, and generates a minimal execution plan.
• scripts/run_constraints.py: Independently executes constraint evaluations, outputting rule matches, passes, and blocks.
• scripts/run_audit.py: Scans the target publish directory against audit policies to output matched items and blocking conclusions.
• policies/workflow-policy.json: Defines required fields, phase order, phase checkpoints, and default 3-layer configuration entries.
• policies/export-audit-policy.json: Defines audit file extensions and blocking patterns to prevent exposing host path signatures, URLs, or proprietary identifiers.

Hard Boundaries (The Engineering Iron Laws)

• DO NOT commit or declare a task as 'done' if the validation (tests or execution) fails. Always return to the implement phase to fix the issue.
• DO NOT introduce massive refactoring, unrelated format changes, or new third-party dependencies unless explicitly approved by the user. Keep the PR/diff as small as possible.
• DO NOT leave debugging print statements, hardcoded mock data, or temporary comments in the final deliverable.
• DO NOT invent custom configurations or patterns if the project already has an established way of doing it (e.g., stick to the existing database ORM or UI component library).