engineering-cybernetics-experience-loop

Files (1)

• SKILL.md

SKILL.md (first lines)

# Engineering Cybernetics Experience Loop

## Overview

This skill is the shared experience-writeback rule for runtime-host Hermes agents. Use Qian Xuesen's 《工程控制论》 as the first standard for learning from TARGET_PROJECT, hardflow workflow/runtime/profile, and multi-agent operations.

Treat every task as a controlled engineering system with goals, boundaries, observations, feedback, control actions, disturbances, safety constraints, verification, and adaptive correction.

The storage split is strict:

- **Memory:** bottom-level logic, stable facts, user preferences, durable environment conventions, and long-lived safety invariants only.
- **Skills:** procedures, commands, workflows, examples, pitfalls, verification recipes, review/deploy checklists, runbooks, and daily curation routines.

## When to Use

Use this after:

- completing a complex runtime-host / SmartMulti / hardflow / Hermes profile task;
- receiving a user correction about workflow, memory, skills, review gates, routing, or operating standards;
- discovering a repeatable failure mode or recovery pattern;
- deciding whether knowledge belongs in memory or skills;
- doing end-of-day cleanup of agent-created or agent-maintained skills.

Do **not** use it to bypass Discord route selection. For new Discord tasks, first obtain the user's explicit route choice, then apply this skill inside the chosen route.

## Primary Standard: Engineering Cybernetics

For every lesson, express the control loop before writing it back:

1. **Control objective / target state** — what stable state the system should reach.
2. **Controlled object and boundary** — business repo, workflow runtime, profile, API, service, Feishu table, Task Center, agent handoff, or human approval path; also what is outside scope.
3. **Observable signals** — status cards, tests, logs, API smoke, git state, Task Center artifacts, reviewer verdicts, user acceptance, gateway state, or runtime health.
4. **Feedback path** — how observations are compared against the target; include delay, noise, stale artifacts, false positives, and missing evidence.
5. **Controller / decision rule** — which agent/operator/stage decides the next action and under what rule.
6. **Actuator / action** — code change, config change, runtime install, restart, documentation writeback, skill patch, memory update, pipeline rerun, or manual escalation.
7. **Disturbance / uncertainty** — dirty worktrees, stale runtime copies, credential boundaries, vague requirements, reviewer drift, artifact mismatch, permission errors, or channel routing ambiguity.
8. **Safety and stability constraints** — no secret printing, no unsafe reset/force push, no production data deletion, no destructive production actions without an explicit target, verified backup, audit record, and rollback command.
9. **Verification and acceptance** — targeted tests, `git diff --check`, compileall, smoke, remote containment, status-card evidence, gateway state, or explicit manual acceptance.
10. **Adaptive correction** — if feedback fails, patch the controller/skill/workflow rather than repeating the same open-loop action.

## Memory vs Skill Decision Gate

### Put in memory only when it is bottom-level logic

Good memory candidates:

- stable user preference or correction;
- canonical project identity, live host, durable path, or environment convention;
- invariant safety principle;
- high-level control logic that should shape future behavior.

Memory format:

- declarative fact, not imperative instruction;
- compact, no raw logs or command transcripts;
- no temporary task state or completed-work diary;
- no secrets, tokens, credentials, cookies, auth JSON, private keys, or sensitive values.

### Put in skills when it is reusable procedure

Good skill candidates:

- step-by-step workflow;
- exact commands or safe command patterns;
- test/review/deploy checklist;
- troubleshooting playbook;
- API/tool quirks;
- examples from a successful or failed task;
- pitfalls and how to verify them;
- daily/weekly curation routine.

Prefer patching an existing skill when the new lesson refines an existing workflow. Create a new skill only when no current skill has the right trigger scope.

## End-of-Day Skill Curation Loop

At the end of a work day, run this closed loop:

1. **Collect observations**
   - Review completed sessions, status cards, failed/recovered runs, user corrections, tool evidence, tests, gateway/API smoke, and git state.
   - Exclude secrets and raw credentials.

2. **Normalize into control-loop facts**
   - For each meaningful lesson, fill: objective, object, signal, feedback, controller, action, disturbance, safety, verification, acceptance.

3. **Separate memory from skill**
   - Keep only the bottom logic or stable convention as a compact memory entry.
   - Move procedures, commands, cases, and failure patterns into skills.

4. **Patch before creating**
   - Search existing skills by trigger terms.
   - Patch the most relevant skill if it already exists.
   - Create a new skill only for a genuinely new reusable workflow.

5. **Structure each changed skill by control loop**
   - Trigger / when to use
   - Target state
   - Controlled object and boundary
   - Observables / evidence
   - Feedback and decision rule
   - Actions / commands
   - Disturbances and failure modes
   - Safety constraints
   - Verification checklist
   - Writeback rule

6. **Reduce duplication**
   - Merge overlapping notes into one umbrella skill when safe.
   - Do not delete skills without explicit user confirmation.
   - If a skill is stale, patch it with the corrected control rule and mark old pitfalls as resolved or superseded.

7. **Verify**
   - Re-read changed skills.
   - Check frontmatter and descriptions.
   - Confirm each skill contains actionable verification steps.
   - Confirm memory does not contain task logs or procedural dumps.

## Daily Output Template

```markdown

From XX-Trader/openclaw-hardflow-backup-20260302, MIT.

More from XX-Trader/openclaw-hardflow-backup-20260302