{"id":"93bf38cd-fe39-49a8-b218-c1c4e009fba3","entityType":"agent","slug":"clawhub-ambitioncn-taskforce-loop-engineering","name":"taskforce-loop-engineering","canonicalUrl":"https://www.xpersona.co/agent/clawhub-ambitioncn-taskforce-loop-engineering","canonicalPath":"/agent/clawhub-ambitioncn-taskforce-loop-engineering","generatedAt":"2026-10-10T06:42:09.473Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":null},"description":"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.9K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s176403v6056szwqp2hd324dpx857gdh:taskforce-loop-engineering","sourceUrl":"https://clawhub.ai/ambitioncn/taskforce-loop-engineering","homepage":"https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/ambitioncn/taskforce-loop-engineering","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":66,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"taskforce-loop-engineering technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":null},"stars":null,"forks":null,"downloads":1949,"packageName":null,"latestVersion":"0.15.21","tractionLabel":"1.9K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T22:01:48.220Z","lastCrawledAt":"2026-10-09T22:01:48.220Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T22:01:48.220Z","lastVerifiedAt":null,"highlights":[{"version":"0.15.21","createdAt":"2026-09-30T17:10:11.202Z","changelog":"Opt-in backlog status reconciliation with fail-closed project and task-binding safeguards; deferred internal relay routing.","fileCount":4,"zipByteSize":11145},{"version":"0.15.20","createdAt":"2026-09-29T05:09:59.141Z","changelog":"Release 0.15.20: opt-in project backlog relay with fail-closed authority and duplicate-enqueue safeguards.","fileCount":4,"zipByteSize":11098},{"version":"0.15.19","createdAt":"2026-09-19T10:34:50.501Z","changelog":"Recover dispatcher launches rejected during OpenClaw Gateway restart drain; match only explicit non-zero restart signatures and avoid unrelated 503 or successful-output replay.","fileCount":4,"zipByteSize":11270},{"version":"0.15.18","createdAt":"2026-09-18T01:13:24.246Z","changelog":"Recover interrupted OpenClaw turns via runtime session rotation while preventing successful recovered turns or quoted prompts from being replayed; add regression coverage.","fileCount":4,"zipByteSize":11331},{"version":"0.15.17","createdAt":"2026-09-13T21:07:32.811Z","changelog":"Fix OpenClaw doctor and disposable smoke compatibility with strict account validation by removing the synthetic doctor account while preserving real source-account forwarding.","fileCount":4,"zipByteSize":11235},{"version":"0.15.16","createdAt":"2026-09-13T20:20:46.569Z","changelog":"Resolve nested checkpoint project identity; defer future authorization gates while safe work remains; strengthen regression coverage and synchronize packaged version docs.","fileCount":4,"zipByteSize":11297},{"version":"0.15.15","createdAt":"2026-08-31T16:32:15.132Z","changelog":"Lock accepted task terminals against broader-project scope creep; require authoritative source/actor/generation-bound Gate artifacts; fail closed for empty or unbound gates and suppress actionable dry-run commands.","fileCount":4,"zipByteSize":11214},{"version":"0.15.14","createdAt":"2026-08-30T09:02:26.939Z","changelog":"Add authoritative cross-interface Human Gates, quota runtime decisions, durable multi-agent team controls, and updated OpenClaw verification guidance.","fileCount":4,"zipByteSize":11184}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176403v6056szwqp2hd324dpx857gdh:taskforce-loop-engineering","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s176403v6056szwqp2hd324dpx857gdh:taskforce-loop-engineering` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/ambitioncn/taskforce-loop-engineering before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T06:42:09.467Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ambitioncn-taskforce-loop-engineering/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":null},"readme":"Skill: taskforce-loop-engineering\n\nOwner: ambitioncn\n\nSummary: Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nTags: latest:0.15.21\n\nVersion history:\n\nv0.15.21 | 2026-09-30T17:10:11.202Z | user\n\nOpt-in backlog status reconciliation with fail-closed project and task-binding safeguards; deferred internal relay routing.\n\nv0.15.20 | 2026-09-29T05:09:59.141Z | user\n\nRelease 0.15.20: opt-in project backlog relay with fail-closed authority and duplicate-enqueue safeguards.\n\nv0.15.19 | 2026-09-19T10:34:50.501Z | user\n\nRecover dispatcher launches rejected during OpenClaw Gateway restart drain; match only explicit non-zero restart signatures and avoid unrelated 503 or successful-output replay.\n\nv0.15.18 | 2026-09-18T01:13:24.246Z | user\n\nRecover interrupted OpenClaw turns via runtime session rotation while preventing successful recovered turns or quoted prompts from being replayed; add regression coverage.\n\nv0.15.17 | 2026-09-13T21:07:32.811Z | user\n\nFix OpenClaw doctor and disposable smoke compatibility with strict account validation by removing the synthetic doctor account while preserving real source-account forwarding.\n\nv0.15.16 | 2026-09-13T20:20:46.569Z | user\n\nResolve nested checkpoint project identity; defer future authorization gates while safe work remains; strengthen regression coverage and synchronize packaged version docs.\n\nv0.15.15 | 2026-08-31T16:32:15.132Z | user\n\nLock accepted task terminals against broader-project scope creep; require authoritative source/actor/generation-bound Gate artifacts; fail closed for empty or unbound gates and suppress actionable dry-run commands.\n\nv0.15.14 | 2026-08-30T09:02:26.939Z | user\n\nAdd authoritative cross-interface Human Gates, quota runtime decisions, durable multi-agent team controls, and updated OpenClaw verification guidance.\n\nv0.15.13 | 2026-08-28T22:57:58.391Z | user\n\nAdd the project-first operator workspace, Gateway-coupled Dashboard autostart, and fail-closed localhost/Tailnet listening modes.\n\nv0.15.12 | 2026-08-28T12:44:37.911Z | user\n\nFix public CI setup for repositories without an npm lockfile.\n\nv0.15.11 | 2026-08-28T12:39:16.053Z | user\n\nAdd transactional state kernel, public Goal API and five-command CLI, public CI, and seven competitive acceptance fixtures.\n\nv0.15.10 | 2026-08-28T09:24:28.782Z | user\n\nFix human-gate materialization so only explicitly missing, currently needed authority blocks progress; honor standing production authorization and checkpoint-bound project backlogs.\n\nv0.15.9 | 2026-08-25T15:16:07.895Z | user\n\nClarify OpenClaw smoke write scope and require checkpoint evidence; add regression coverage.\n\nv0.15.8 | 2026-08-25T02:29:54.440Z | user\n\nPreserve and deduplicate non-blocking terminal checkpoint risks in final judgement summaries, including accepted project completions, with regression coverage.\n\nv0.15.7 | 2026-08-24T15:29:48.454Z | user\n\nPrevent accepted phase checkpoints from being misjudged as terminal completion; preserve continuation risks; use accepted terminal contracts as completion authority; reconcile stale post-completion gates into done.\n\nv0.15.6 | 2026-08-24T08:39:11.405Z | user\n\nSupport external-only authoritative project backlogs in project-status, fail closed when no backlog source exists, and avoid false registry drift when no embedded projection is configured.\n\nv0.15.5 | 2026-08-24T08:19:00.876Z | user\n\nPrevent future paid/deploy/publish gates from stopping safe local backlog work; automatically reconcile premature waiting gates; recover incomplete embedded-runtime turns.\n\nv0.15.4 | 2026-08-22T03:49:16.682Z | user\n\nPreserve source conversation routing across revisions; fail closed on unroutable routed revisions; materialize the newest authoritative blocked project human gate; add end-to-end regression coverage.\n\nv0.15.3 | 2026-08-21T19:42:23.027Z | user\n\nRemove workspace-specific Ironman queue/dispatcher instructions; resolve each machine's installed queue and managed wrapper; add regression coverage against host-specific dispatcher leakage. Existing queue data is untouched.\n\nv0.15.2 | 2026-08-21T10:17:45.965Z | user\n\nImprove terminal notifications with final judgement and checkpoint summaries, enforce Chinese queue localization, and link notification ledger evidence back to run artifacts.\n\nv0.15.1 | 2026-08-20T07:14:43.946Z | user\n\nFix OpenClaw and Hermes scheduler health reporting when asynchronous notification delivery fails.\n\nv0.15.0 | 2026-08-20T06:59:50.626Z | user\n\nReconcile project-scoped human gates with authoritative contracts and acceptance ledgers; strengthen project status and doctor drift checks; make supersession project-aware; add durable gate regression coverage.\n\nv0.14.0 | 2026-08-14T06:32:19.090Z | user\n\nAdd the platform-neutral runtime adapter SDK v1 for OpenClaw, Hermes, Codex CLI, and Claude Code, with shared conformance tests, fail-closed effects, redacted telemetry, migration guidance, and a credential-free demo.\n\nv0.13.0 | 2026-08-14T00:51:04.828Z | user\n\nAdd production-trust runtime adapters, durable journal/replay, safe upgrade planning, multi-agent soak/canary tooling, and detached acceptance refresh.\n\nv0.12.0 | 2026-08-13T16:19:50.810Z | user\n\nP0-P3 release: Human-Gate Lifecycle v2, action idempotency and reservations, multi-agent typed todo control plane, and read-only Operator Dashboard.\n\nv0.10.0 | 2026-08-11T17:21:23.517Z | user\n\nAdd English/Chinese installation adaptation, complete English conversation routing semantics, fail-closed delivery metadata checks, and notification-backed terminal delivery.\n\nv0.9.0 | 2026-08-08T19:42:11.067Z | user\n\nAdd Hermes Agent install, doctor, smoke, source-bound delivery, managed scheduler, and fail-closed platform confirmation summaries for both OpenClaw and Hermes.\n\nv0.8.5 | 2026-08-08T03:57:20.825Z | user\n\nClarify upgrade intent: product-level Loop Engineering upgrades now mean the complete managed Skill, npm/CLI, OpenClaw integration/queue, and scheduler lifecycle by default; only explicit Skill-only requests remain limited to ClawHub content, with per-layer verification required.\n\nv0.8.4 | 2026-08-07T19:45:39.284Z | user\n\nReclaim orphaned dead-PID queue locks; preserve non-sensitive human attestations while keeping secrets one-time; prevent historical gate resurrection; support normal requeue from superseded waiting gates.\n\nv0.8.3 | 2026-08-07T19:05:38.720Z | user\n\nFix durable checkpoint recency and blocked human-gate reconciliation; prevent legacy cp9 reviews from overriding blocked cp46+ checkpoints and move blocked tasks into waiting_for_human.\n\nv0.8.2 | 2026-08-07T18:16:30.400Z | user\n\nRecover compaction and transport interruptions with bounded fresh-session resume; proactively rotate long project sessions; install the recovery policy through managed OpenClaw upgrades.\n\nv0.8.1 | 2026-08-07T14:25:12.930Z | user\n\nAutomatically install, enable, verify, upgrade, and uninstall the managed per-queue scheduler so project loops cannot remain queued indefinitely.\n\nv0.8.0 | 2026-08-07T13:58:58.286Z | user\n\nProject-aware completion and checkpoint lineage; durable redacted human gates; orphan active-task recovery; fail-closed scheduler heartbeat health checks.\n\nv0.7.2 | 2026-08-06T13:43:07.126Z | user\n\nPreserve explicit human acceptance gates, fail closed on missing delivery routing, and complete tasks only after approval.\n\nv0.7.1 | 2026-08-05T17:42:55.454Z | user\n\nAdd official npm/GitHub installation details and complete OpenClaw integration verification commands so a standalone ClawHub skill can bootstrap the CLI.\n\nv0.7.0 | 2026-08-05T09:28:30.774Z | user\n\nRename Loop Engineering to Taskforce Loop Engineering while preserving the established task/project loop workflow, immediate execution semantics, amendment and supersede handling, and strict project completion contracts.\n\nArchive index:\n\nArchive v0.15.21: 4 files, 11145 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (1874b), SKILL.md (19972b), _meta.json (147b)\n\nFile v0.15.21:SKILL.md\n\n---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` address, and fails closed rather than binding all interfaces. Tailnet mode relies on Tailscale ACLs/Grants and does not add application-level login. The plan must declare the selected mode before writes, and the doctor must verify the Dashboard service and gateway drop-in. Use `loop-engineering-dashboard-autostart-install --listen localhost|tailscale` only for standalone install or repair.\n\nThe installer never creates the worker agent. After installation, verify wiring before using a real task:\n\n```bash\nloop-engineering-openclaw-doctor \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n\nloop-engineering-openclaw-smoke \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n```\n\nIf the CLI or integration is missing and the user requested installation or repair, install it within the authorized host/workspace scope, then run doctor and the disposable smoke. If the user only asked what is missing, report the exact package, repository, commands, and current deployment state without mutating the system.\n\n### Hermes Agent Integration\n\nThe core CLI is platform-neutral, but Hermes conversation routing requires its own dispatcher and notifier. Generate a plan and verify its installation confirmation summary identifies Hermes, the absolute Hermes CLI path, intended workspace and queue, systemd scheduler, source-bound notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Confirm installation only after that review, then run the read-only doctor and disposable smoke:\n\n```bash\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks \\\n --confirm-install\n\nloop-engineering-hermes-doctor \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-smoke \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n```\n\nThe confirmed Hermes install creates the same Dashboard service and couples it to `hermes-gateway.service`. It accepts `--dashboard-listen localhost|tailscale` with the same default-local, Tailnet-only binding, fail-closed resolution, and ACL/Grant boundary as OpenClaw. The plan and doctor must expose and verify this coupling.\n\nThe generated worker uses `hermes -z` (`--oneshot`); the notifier uses `hermes send` without\nan LLM call. Preserve source metadata and pass `--source-target` in Hermes\n`platform:chat_id[:thread_id]` format. The managed systemd scheduler owns wakeups\nso durable queue continuity does not depend on resuming a Hermes Cron session.\n\n## Cross-interface Human Gates\n\nDashboard and chat approvals use one Gate Command core and one authoritative gate artifact. Cards must show project/task, Gate ID, action, reason, impact, risk, cost/budget, evidence, Dashboard URL, expiry and generation; processed cards are refreshed disabled. Only card buttons or exact card-bound `/approve gate_`, `/reject gate_` and `/request_revision gate_ ` replies may mutate a gate. Ordinary chat, quotes, forwards, screenshots and ordinal phrases fail closed as `ignored_untrusted_chat`; `/show_gate gate_` is display-only.\n\nThe OpenClaw installer generates `scripts/loops/openclaw-loop-gate.mjs`. A trusted Feishu callback/plugin transport must verify the official signature or encrypted-event envelope, timestamp/nonce and secret before invoking it with `LOOP_GATE_CHANNEL=feishu` and `LOOP_FEISHU_SIGNATURE_VERIFIED=1`; missing verification fails with `feishu_signature_unverified`. The bridge itself performs no delivery. Other channel transports pass normalized, source-bound events. Dashboard and chat commands share actor/source binding, generation fencing, idempotency receipts, confirmation escalation and synchronized card state.\n\nAfter installation, run `loop-engineering-openclaw-doctor` and `loop-engineering-openclaw-smoke`. Doctor syntax-checks and locally self-tests the Gate bridge; smoke remains disposable and uses dry-run notifications. Neither command sends an online test message.\n\n## Conversation Contract\n\nInterpret explicit loop language as follows:\n\n- `走 loop：`: enqueue and immediately execute one runner tick with notification.\n- `走 loop 并立刻执行`: synonym for the default above.\n- `走 loop，只入队`, `只排队`, `暂不执行`, or `不立即执行`: enqueue without starting a tick.\n- `继续当前 loop，补充要求：…`: amend the active task in place. Preserve the task id and worker session, write a versioned amendment, update the task contract/dev plan/acceptance plan, and require the worker to reread the latest amendment before checkpoints and completion.\n- A new explicit `走 loop` request while another task is active is a correction/replacement, not ordinary backlog. Supersede the active task at a safe boundary, retain its evidence and lineage, then start the replacement after the lock is released.\n- Status, progress, evidence, or failure questions are read-only and must not start another tick unless the user explicitly asks to continue/run.\n\nDo not infer a queue or dispatcher from this skill. Use the integration installed in the current workspace. For OpenClaw, inspect the generated queue configuration under `configs/loops/queues/` and use the managed wrapper when present. A default installation uses queue `agent-tasks` and the generic wrapper below; an operator may choose another queue or worker during installation.\n\n```bash\nnode scripts/loops/openclaw-loop.mjs route --message \"\" [source options]\nnode scripts/loops/openclaw-loop.mjs run-once\nloop-engineering queue-status --queue --root . --json\nloop-engineering queue-peek --queue --root . --json\n```\n\nIf the managed wrapper or queue configuration is absent, stop and run the platform installer/doctor workflow above. Product names, personal agent names, and host-specific dispatchers belong in local workspace instructions, never in this distributed skill.\n\nPass the original request faithfully. Preserve source channel, target, account, message id, and reply-to metadata so progress, human gates, and terminal results return to the originating conversation. Missing delivery routing must fail closed.\n\n## Task vs Project Classification\n\nClassify scope before enqueueing.\n\n### Scoped task\n\nA bounded change, diagnosis, review, or deliverable with a clear local acceptance target can use one task contract.\n\n### Project-level objective\n\nTreat a request as project-level when the user asks to build/develop/finish a complete product or system, achieve an overall outcome, or otherwise describes a multi-milestone terminal goal.\n\nFor a project-level objective:\n\n1. Run project intake and create a project spec.\n2. Write an explicit terminal-state/completion contract.\n3. Build a complete backlog covering every requirement and known acceptance dimension.\n4. Link queue tasks to the project backlog and terminal contract.\n5. Continue through implementation, verification, revisions, and the next actionable backlog item within the authorized safety boundary.\n6. Stop only when total project acceptance passes, or a genuine human authorization/product decision/external-state blocker prevents meaningful progress.\n\nNever silently narrow a complete-project request into “first milestone” and call that the Loop complete. A single queue task or milestone may be complete while the project remains active.\n\nRecommended commands:\n\n```bash\nloop-engineering project-intake --root --name --brief \"\" --type auto\nloop-engineering project-plan --root --project \nloop-engineering project-status --root --project \n```\n\nThe project completion contract must contain:\n\n- terminal user-visible outcome;\n- in-scope and explicitly out-of-scope capabilities;\n- complete requirement/backlog mapping;\n- acceptance checks and evidence locations;\n- operational/security/data/deployment requirements when relevant;\n- unresolved decisions and required authority;\n- a rule that milestone completion cannot satisfy project completion;\n- final acceptance status with unmet items and blockers.\n\nIf implementation reveals missing work, amend the project backlog/contract before continuing. Do not redefine the terminal goal downward to fit completed work.\n\n## Completion Semantics\n\nUse precise language:\n\n- `阶段完成` or `任务完成`: one task/milestone passed its own acceptance checks.\n- `项目完成` or `Loop 跑完`: only when the project completion contract is fully accepted and no required work remains.\n- `blocked`: only for a concrete blocker requiring human authority/input or an external state change, with evidence and a specific unblock request.\n- `needs_revision`: acceptance found actionable gaps; create a changed-strategy revision rather than claiming completion.\n- `superseded`: a newer explicit loop request replaced the task; preserve lineage and evidence.\n\nFinal reporting for project work must always state both task/milestone status and total-project status.\n\n## Safety and Authority\n\nLoop invocation authorizes the requested workflow, not unlimited external action.\n\nRequire separate explicit confirmation for:\n\n- external messages, publication, social posting, or outreach;\n- destructive deletion or difficult-to-recover changes;\n- production configuration/deployment changes not already clearly requested;\n- credential creation/change/exposure;\n- paid model/API usage beyond an established budget;\n- memory deletion or migration;\n- device/process instrumentation such as `frida`, `tcpdump`, `adb`, `mitmproxy`, hooks, attach/spawn, decrypt, `su`, `kill`, or `pkill`.\n\nHuman permission prompts and missing authorization are stop conditions, not retryable failures. `INSTALL_FAILED_USER_RESTRICTED`, device unauthorized, permission denied, and equivalent states require a concrete human-action gate.\n\nTimeouts must terminate the spawned process group. After instrumentation timeouts, verify that no child instrumentation/proxy process remains.\n\n## Operating Flow\n\n1. Read existing project docs, loop configs, queue state, and relevant dirty worktree state.\n2. Classify task vs project and define the correct contract before execution.\n3. Use `route-message` or the installed conversation wrapper to preserve source metadata and apply immediate/queue-only/amend/supersede semantics.\n4. Run preflight before mutable work.\n5. Execute one bounded tick or the project’s next actionable backlog item.\n6. Emit ordered progress: planning, preflight, worker start, checkpoints, verification, acceptance, final judgement.\n7. Inspect run artifacts; never infer success only from dispatcher exit code.\n8. If acceptance fails, write a revision request with changed diagnosis/tactic/evidence/verification.\n9. Run `doctor` after configuration or queue changes.\n10. For projects, re-read project status and completion contract, then automatically advance to the next safe actionable item.\n11. Report terminal status with evidence, unmet items, blockers, and next action.\n\nDo not add cron/timers until one manual tick passes.\n\n## Core CLI\n\nPrefer the installed CLI:\n\n```bash\nloop-engineering verify --root \nloop-engineering doctor --root [--json]\nloop-engineering summarize --root --limit 20\nloop-engineering route-message --root --message \"\" --queue --route --confirm-execute [--supersede-active | --amend-active] [source options]\nloop-engineering queue-status --root --queue \nloop-engineering queue-peek --root --queue \nloop-engineering run-queue --root --config configs/loops/queues/.json\nloop-engineering queue-revision-next --root --queue --task-id \nloop-engineering queue-lineage --root --queue --task-id \nloop-engineering queue-lineage-bundle --root --queue --task-id \nloop-engineering queue-human-decision --root --queue --task-id --decision approve|request_changes|reject\nloop-engineering queue-human-input-resolve --root --queue --gate-id --input \"\" [--secret-input|--non-secret-input]\nloop-engineering queue-terminal-notify --root --queue (--notify-command \"\" | --dry-run)\nloop-engineering queue-human-input-notify --root --queue (--notify-command \"\" | --dry-run)\n```\n\nIf the package is available only in the workspace:\n\n```bash\nnode packages/loop-engineering/bin/loop-engineering.mjs \n```\n\nUse `run-queue-drain` only when batch draining is explicitly intended. Conversation routing normally runs one task/tick and uses supersede/amend behavior.\n\n## Revision Discipline\n\nA dispatcher-successful run is not automatically accepted. Inspect `final_judgement.json`, acceptance reviews, checkpoints, and verification evidence.\n\nWhen acceptance needs changes:\n\n- mark `needs_revision`;\n- retain the failed source task;\n- use `queue-revision-next`;\n- require a changed diagnosis, implementation tactic, evidence source, or verification step;\n- inspect lineage before forcing repeated attempts.\n\nDefault revision policy may stop after three rounds, two repeated goal signatures, or repeated unchanged strategy. `--force` requires an explicit human override after lineage review.\n\n## Code Work\n\nFor L2 code-changing tasks, prefer isolated worktrees. The runner prepares reviewable local changes and verification evidence; it does not implicitly commit, push, publish, deploy, merge, or delete branches.\n\nSafe review flow:\n\n```bash\nloop-engineering code-task-status --root --queue \nloop-engineering code-worktree-inspect --root --queue --task-id \nloop-engineering code-worktree-diff --root --queue --task-id \nloop-engineering code-task-autoflow --root --queue --task-id --until closeout\nloop-engineering code-patch-apply-plan --root --patch --json\n```\n\nApplying a patch and cleaning a worktree require their explicit confirmation flags. Preserve unrelated user changes and never treat a dirty worktree as disposable.\n\n## Observability and Artifacts\n\nUse read-only diagnostics before mutation:\n\n```bash\nloop-engineering doctor --root --json\nloop-engineering summarize --root --queue --limit 20\nloop-engineering project-status --root --project \n```\n\nTask artifacts live under:\n\n```text\nruntime/loops//tasks//\nruntime/loops//runs/\nruntime/loops//{inbox,active,done,failed,canceled}/\n```\n\nExpected evidence includes `task_contract.json`, `acceptance_plan.json`, `dev_plan.json`, checkpoints, acceptance reviews, `final_judgement.json`, revision requests, amendments, supersede markers, progress notifications, and lineage bundles.\n\nProject artifacts live under:\n\n```text\nconfigs/loops/projects/.json\nruntime/loops/projects//\n```\n\nSummaries must cite the latest run/task/project evidence, verification performed, unmet checks, and blocker reason. Keep raw noisy logs in runtime artifacts; durable memory receives only distilled decisions, recurring failures, accepted safety rules, and verified completion facts.\n\n## Scheduler Policy\n\nUse scheduler ticks only after manual verification. Adaptive schedules may speed up with successful queued work and back off on empty queues, failures, long runs, or human gates.\n\n`queue-scheduler-tick` is adaptive cadence logic, not a resident daemon. A cron, systemd timer, or equivalent external scheduler must wake it regularly. For project queues that promise automatic continuation, set `scheduler.required=true` and a bounded `scheduler.heartbeatMaxAge`; `doctor` must fail with `scheduler_missing` whenever queued work exists without a fresh scheduler heartbeat.\n\nProgress notification must be scoped and idempotent. Report failures, human gates, status changes, and terminal completion promptly; throttle routine progress and idle updates.\n\n## Final Checklist\n\nBefore saying a loop is finished, verify:\n\n- Was this a scoped task or project-level objective?\n- Is the correct contract present and current?\n- Were all amendments applied?\n- Did verification and acceptance pass?\n- Is `final_judgement.json` acceptable?\n- For a project, are all completion-contract items accepted and the backlog terminal?\n- Are there any unmet requirements, pending revisions, gates, or external-write confirmations?\n- Does the report distinguish milestone status from total-project status?\n- Are evidence paths and next actions included?\n\nIf any project requirement remains, report a phase/task result and continue with the next authorized item; do not claim the project or Loop is complete.\n\nFile v0.15.21:_meta.json\n\n{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.21\",\n \"publishedAt\": 1790788211202\n}\n\nFile v0.15.21:references/npm-package.md\n\n# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.19`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks --confirm-install\nloop-engineering-hermes-doctor --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-smoke --root /path/to/hermes/workspace --queue agent-tasks\n```\n\nInstalled commands:\n\n```bash\nloop-engineering init --root /path/to/workspace\nloop-engineering verify --root /path/to/workspace\nloop-engineering run --root /path/to/workspace --config configs/loops/.json\nloop-engineering status --root /path/to/workspace\nloop-engineering doctor --root /path/to/workspace\nloop-engineering summarize --root /path/to/workspace --limit 20\nloop-engineering project-intake --root /path/to/workspace --name --brief \"Project brief\"\nloop-engineering project-plan --root /path/to/workspace --project \nloop-engineering project-status --root /path/to/workspace --project \nloop-engineering enqueue --root /path/to/workspace --queue --title \"Title\" --task \"Task body\"\nloop-engineering queue-init --root /path/to/workspace --queue \nloop-engineering code-queue-init --root /path/to/workspace --queue \nloop-engineering run-queue --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-status --root /path/to/workspace --queue \nloop-engineering queue-scheduler-tick --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-peek --root /path/to/workspace --queue \nloop-engineering queue-cancel --root /path/to/workspace --queue --task-id \nloop-engineering queue-requeue --root /path/to/workspace --queue --task-id \nloop-engineering queue-revision-next --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage-bundle --root /path/to/workspace --queue --task-id \nloop-engineering queue-human-decision --root /path/to/workspace --queue --task-id --decision approve|request_changes|reject\nloop-engineering code-worktree-list --root /path/to/workspace --queue \nloop-engineering code-worktree-inspect --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-diff --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-export --root /path/to/workspace --queue --task-id \nloop-engineering code-patch-verify --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply-plan --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply --root /path/to/workspace --patch runtime/loops//patches/.patch --confirm-apply\nloop-engineering code-review-bundle --root /path/to/workspace --queue --task-id \nloop-engineering code-task-closeout --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --all-actionable --until closeout\nloop-engineering code-task-finish --root /path/to/workspace --queue --task-id --confirm-apply --confirm-cleanup\nloop-engineering code-task-run --root /path/to/workspace --queue --title \"Title\" --task \"Task body\" --confirm-apply --confirm-cleanup\nloop-engineering code-task-dashboard --root /path/to/workspace --queue \nloop-engineering code-task-status --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup-plan --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup --root /path/to/workspace --queue --confirm-cleanup\nagent-loop status --root /path/to/workspace\nLOOP_WORKDIR=/path/to/workspace run-loop-cron.sh configs/loops/.json\n```\n\n`code-queue-init` creates an L2 assisted code queue config. Each task runs in\nan isolated git worktree and branch, then runs configured verification commands\nand records diff/status summaries. It does not push, merge, or delete\nworktrees.\n\n`queue-scheduler-tick` is the adaptive queue cadence command. It treats 10\nminutes as the bootstrap interval, writes live cadence state to\n`runtime/loops//scheduler/state.json`, speeds up after successful work\nwhen tasks remain queued, and backs off for empty queues, failures, human gates,\nor long runs.\n\n`project-intake` is the high-level entry for fuzzy project briefs. It writes a\ndeterministic project spec draft, human-readable plan, action policy, checks,\nand initial backlog under `runtime/loops/projects//` without enqueuing\nor executing work. `project-plan` solidifies that draft into\n`configs/loops/projects/.json`, generates the queue config, and writes\nthe initial backlog artifact. `project-status` aggregates the project queues\nwithout changing queue state.\n\n`code-worktree-list`, `code-worktree-inspect`, `code-worktree-diff`,\n`code-worktree-export`, `code-patch-verify`, `code-patch-apply-plan`,\n`code-patch-apply`, `code-review-bundle`, `code-task-closeout`,\n`code-task-autoflow`, `code-task-finish`, `code-task-run`, `code-task-dashboard`,\n`code-task-status`, `code-worktree-cleanup-plan`, and\n`code-worktree-cleanup`\nare review and\nhandoff commands for code queues.\nThey report branch, path, dirty status, verification status, diff summaries,\npatch output, exported patch artifacts, untracked files, whether an exported\npatch still passes `git apply --check --binary`, whether it is safe to apply,\nreview bundle files, which retained worktrees are cleanup candidates, and\nconfirmation-gated cleanup of reviewed worktrees. Closeout artifacts summarize\nthe task's final review, patch, apply-plan, cleanup, and next-action state.\nStatus ledgers summarize task-level queue, worktree, patch, review, closeout,\ncleanup, and next-action state without writing artifacts.\nDashboards summarize queue counts, task counts, next-action counts,\ncleanup/orphan state, priority tasks, and recommended commands without writing\nartifacts.\nFinish applies one reviewed patch to the main workspace and removes that one\nreviewed worktree only after default patch, review, and closeout artifacts are\npresent and both `--confirm-apply` and `--confirm-cleanup` are supplied; it\nalso writes a finish artifact. Status and dashboard views read finish artifacts:\ntasks ready to land report `ready_to_finish`, and successfully finished tasks\nreport `landed` with finish status, patch-applied, and worktree-cleaned fields.\nTask run enqueues one code task, processes one worktree queue run, runs\nautoflow through closeout, finishes the reviewed task, and reruns configured\nworktree verification commands in the main workspace.\nAutoflow runs export, patch verification, apply-plan, and review generation by\ndefault, and can also write closeout artifacts with `--until closeout`; it skips\nexisting artifacts unless `--force` is supplied. Batch autoflow with\n`--all-actionable` reads the status ledger and runs the same safe flow across\ntasks that need export, review, or closeout artifacts.\nActual patch application requires `--confirm-apply` and still does not stage,\ncommit, push, merge, or change queue state.\nActual worktree cleanup requires `--confirm-cleanup`; dirty worktrees require a\ndefault exported patch, passing patch verification, and an existing review\nbundle.\n\nThe package contains `bin/`, `lib/`, `scripts/`, `templates/`, and\n`skills/taskforce-loop-engineering/`.\n\nFile v0.15.21:skill-card.md\n\n## Description:\n\nDurable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ambitioncn](https://clawhub.ai/user/ambitioncn)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and other users explicitly invoking a task or project loop use this skill to coordinate queued work, track progress, verify outcomes, and manage revisions and approval gates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing the CLI or integration can change workspace files, scheduler configuration, and dashboard availability.\n\nMitigation: Trust and pin a reviewed package version; inspect the installation plan and confirm changes only for the intended workspace and host account.\n\nRisk: An active loop may perform work beyond what the user intended.\n\nMitigation: Require explicit loop invocation and separate approval for external communication, destructive actions, sensitive changes, and spending beyond an established budget.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering)\n- [npm Package](artifact/references/npm-package.md)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration instructions]\n\n**Output Format:** [Markdown with inline shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include task status, verification evidence, and next actions.]\n\n## Skill Version(s):\n\n0.15.21 (source: server-resolved release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.15.20: 4 files, 11098 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (1841b), SKILL.md (19972b), _meta.json (147b)\n\nFile v0.15.20:SKILL.md\n\n---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` address, and fails closed rather than binding all interfaces. Tailnet mode relies on Tailscale ACLs/Grants and does not add application-level login. The plan must declare the selected mode before writes, and the doctor must verify the Dashboard service and gateway drop-in. Use `loop-engineering-dashboard-autostart-install --listen localhost|tailscale` only for standalone install or repair.\n\nThe installer never creates the worker agent. After installation, verify wiring before using a real task:\n\n```bash\nloop-engineering-openclaw-doctor \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n\nloop-engineering-openclaw-smoke \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n```\n\nIf the CLI or integration is missing and the user requested installation or repair, install it within the authorized host/workspace scope, then run doctor and the disposable smoke. If the user only asked what is missing, report the exact package, repository, commands, and current deployment state without mutating the system.\n\n### Hermes Agent Integration\n\nThe core CLI is platform-neutral, but Hermes conversation routing requires its own dispatcher and notifier. Generate a plan and verify its installation confirmation summary identifies Hermes, the absolute Hermes CLI path, intended workspace and queue, systemd scheduler, source-bound notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Confirm installation only after that review, then run the read-only doctor and disposable smoke:\n\n```bash\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks \\\n --confirm-install\n\nloop-engineering-hermes-doctor \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-smoke \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n```\n\nThe confirmed Hermes install creates the same Dashboard service and couples it to `hermes-gateway.service`. It accepts `--dashboard-listen localhost|tailscale` with the same default-local, Tailnet-only binding, fail-closed resolution, and ACL/Grant boundary as OpenClaw. The plan and doctor must expose and verify this coupling.\n\nThe generated worker uses `hermes -z` (`--oneshot`); the notifier uses `hermes send` without\nan LLM call. Preserve source metadata and pass `--source-target` in Hermes\n`platform:chat_id[:thread_id]` format. The managed systemd scheduler owns wakeups\nso durable queue continuity does not depend on resuming a Hermes Cron session.\n\n## Cross-interface Human Gates\n\nDashboard and chat approvals use one Gate Command core and one authoritative gate artifact. Cards must show project/task, Gate ID, action, reason, impact, risk, cost/budget, evidence, Dashboard URL, expiry and generation; processed cards are refreshed disabled. Only card buttons or exact card-bound `/approve gate_`, `/reject gate_` and `/request_revision gate_ ` replies may mutate a gate. Ordinary chat, quotes, forwards, screenshots and ordinal phrases fail closed as `ignored_untrusted_chat`; `/show_gate gate_` is display-only.\n\nThe OpenClaw installer generates `scripts/loops/openclaw-loop-gate.mjs`. A trusted Feishu callback/plugin transport must verify the official signature or encrypted-event envelope, timestamp/nonce and secret before invoking it with `LOOP_GATE_CHANNEL=feishu` and `LOOP_FEISHU_SIGNATURE_VERIFIED=1`; missing verification fails with `feishu_signature_unverified`. The bridge itself performs no delivery. Other channel transports pass normalized, source-bound events. Dashboard and chat commands share actor/source binding, generation fencing, idempotency receipts, confirmation escalation and synchronized card state.\n\nAfter installation, run `loop-engineering-openclaw-doctor` and `loop-engineering-openclaw-smoke`. Doctor syntax-checks and locally self-tests the Gate bridge; smoke remains disposable and uses dry-run notifications. Neither command sends an online test message.\n\n## Conversation Contract\n\nInterpret explicit loop language as follows:\n\n- `走 loop：`: enqueue and immediately execute one runner tick with notification.\n- `走 loop 并立刻执行`: synonym for the default above.\n- `走 loop，只入队`, `只排队`, `暂不执行`, or `不立即执行`: enqueue without starting a tick.\n- `继续当前 loop，补充要求：…`: amend the active task in place. Preserve the task id and worker session, write a versioned amendment, update the task contract/dev plan/acceptance plan, and require the worker to reread the latest amendment before checkpoints and completion.\n- A new explicit `走 loop` request while another task is active is a correction/replacement, not ordinary backlog. Supersede the active task at a safe boundary, retain its evidence and lineage, then start the replacement after the lock is released.\n- Status, progress, evidence, or failure questions are read-only and must not start another tick unless the user explicitly asks to continue/run.\n\nDo not infer a queue or dispatcher from this skill. Use the integration installed in the current workspace. For OpenClaw, inspect the generated queue configuration under `configs/loops/queues/` and use the managed wrapper when present. A default installation uses queue `agent-tasks` and the generic wrapper below; an operator may choose another queue or worker during installation.\n\n```bash\nnode scripts/loops/openclaw-loop.mjs route --message \"\" [source options]\nnode scripts/loops/openclaw-loop.mjs run-once\nloop-engineering queue-status --queue --root . --json\nloop-engineering queue-peek --queue --root . --json\n```\n\nIf the managed wrapper or queue configuration is absent, stop and run the platform installer/doctor workflow above. Product names, personal agent names, and host-specific dispatchers belong in local workspace instructions, never in this distributed skill.\n\nPass the original request faithfully. Preserve source channel, target, account, message id, and reply-to metadata so progress, human gates, and terminal results return to the originating conversation. Missing delivery routing must fail closed.\n\n## Task vs Project Classification\n\nClassify scope before enqueueing.\n\n### Scoped task\n\nA bounded change, diagnosis, review, or deliverable with a clear local acceptance target can use one task contract.\n\n### Project-level objective\n\nTreat a request as project-level when the user asks to build/develop/finish a complete product or system, achieve an overall outcome, or otherwise describes a multi-milestone terminal goal.\n\nFor a project-level objective:\n\n1. Run project intake and create a project spec.\n2. Write an explicit terminal-state/completion contract.\n3. Build a complete backlog covering every requirement and known acceptance dimension.\n4. Link queue tasks to the project backlog and terminal contract.\n5. Continue through implementation, verification, revisions, and the next actionable backlog item within the authorized safety boundary.\n6. Stop only when total project acceptance passes, or a genuine human authorization/product decision/external-state blocker prevents meaningful progress.\n\nNever silently narrow a complete-project request into “first milestone” and call that the Loop complete. A single queue task or milestone may be complete while the project remains active.\n\nRecommended commands:\n\n```bash\nloop-engineering project-intake --root --name --brief \"\" --type auto\nloop-engineering project-plan --root --project \nloop-engineering project-status --root --project \n```\n\nThe project completion contract must contain:\n\n- terminal user-visible outcome;\n- in-scope and explicitly out-of-scope capabilities;\n- complete requirement/backlog mapping;\n- acceptance checks and evidence locations;\n- operational/security/data/deployment requirements when relevant;\n- unresolved decisions and required authority;\n- a rule that milestone completion cannot satisfy project completion;\n- final acceptance status with unmet items and blockers.\n\nIf implementation reveals missing work, amend the project backlog/contract before continuing. Do not redefine the terminal goal downward to fit completed work.\n\n## Completion Semantics\n\nUse precise language:\n\n- `阶段完成` or `任务完成`: one task/milestone passed its own acceptance checks.\n- `项目完成` or `Loop 跑完`: only when the project completion contract is fully accepted and no required work remains.\n- `blocked`: only for a concrete blocker requiring human authority/input or an external state change, with evidence and a specific unblock request.\n- `needs_revision`: acceptance found actionable gaps; create a changed-strategy revision rather than claiming completion.\n- `superseded`: a newer explicit loop request replaced the task; preserve lineage and evidence.\n\nFinal reporting for project work must always state both task/milestone status and total-project status.\n\n## Safety and Authority\n\nLoop invocation authorizes the requested workflow, not unlimited external action.\n\nRequire separate explicit confirmation for:\n\n- external messages, publication, social posting, or outreach;\n- destructive deletion or difficult-to-recover changes;\n- production configuration/deployment changes not already clearly requested;\n- credential creation/change/exposure;\n- paid model/API usage beyond an established budget;\n- memory deletion or migration;\n- device/process instrumentation such as `frida`, `tcpdump`, `adb`, `mitmproxy`, hooks, attach/spawn, decrypt, `su`, `kill`, or `pkill`.\n\nHuman permission prompts and missing authorization are stop conditions, not retryable failures. `INSTALL_FAILED_USER_RESTRICTED`, device unauthorized, permission denied, and equivalent states require a concrete human-action gate.\n\nTimeouts must terminate the spawned process group. After instrumentation timeouts, verify that no child instrumentation/proxy process remains.\n\n## Operating Flow\n\n1. Read existing project docs, loop configs, queue state, and relevant dirty worktree state.\n2. Classify task vs project and define the correct contract before execution.\n3. Use `route-message` or the installed conversation wrapper to preserve source metadata and apply immediate/queue-only/amend/supersede semantics.\n4. Run preflight before mutable work.\n5. Execute one bounded tick or the project’s next actionable backlog item.\n6. Emit ordered progress: planning, preflight, worker start, checkpoints, verification, acceptance, final judgement.\n7. Inspect run artifacts; never infer success only from dispatcher exit code.\n8. If acceptance fails, write a revision request with changed diagnosis/tactic/evidence/verification.\n9. Run `doctor` after configuration or queue changes.\n10. For projects, re-read project status and completion contract, then automatically advance to the next safe actionable item.\n11. Report terminal status with evidence, unmet items, blockers, and next action.\n\nDo not add cron/timers until one manual tick passes.\n\n## Core CLI\n\nPrefer the installed CLI:\n\n```bash\nloop-engineering verify --root \nloop-engineering doctor --root [--json]\nloop-engineering summarize --root --limit 20\nloop-engineering route-message --root --message \"\" --queue --route --confirm-execute [--supersede-active | --amend-active] [source options]\nloop-engineering queue-status --root --queue \nloop-engineering queue-peek --root --queue \nloop-engineering run-queue --root --config configs/loops/queues/.json\nloop-engineering queue-revision-next --root --queue --task-id \nloop-engineering queue-lineage --root --queue --task-id \nloop-engineering queue-lineage-bundle --root --queue --task-id \nloop-engineering queue-human-decision --root --queue --task-id --decision approve|request_changes|reject\nloop-engineering queue-human-input-resolve --root --queue --gate-id --input \"\" [--secret-input|--non-secret-input]\nloop-engineering queue-terminal-notify --root --queue (--notify-command \"\" | --dry-run)\nloop-engineering queue-human-input-notify --root --queue (--notify-command \"\" | --dry-run)\n```\n\nIf the package is available only in the workspace:\n\n```bash\nnode packages/loop-engineering/bin/loop-engineering.mjs \n```\n\nUse `run-queue-drain` only when batch draining is explicitly intended. Conversation routing normally runs one task/tick and uses supersede/amend behavior.\n\n## Revision Discipline\n\nA dispatcher-successful run is not automatically accepted. Inspect `final_judgement.json`, acceptance reviews, checkpoints, and verification evidence.\n\nWhen acceptance needs changes:\n\n- mark `needs_revision`;\n- retain the failed source task;\n- use `queue-revision-next`;\n- require a changed diagnosis, implementation tactic, evidence source, or verification step;\n- inspect lineage before forcing repeated attempts.\n\nDefault revision policy may stop after three rounds, two repeated goal signatures, or repeated unchanged strategy. `--force` requires an explicit human override after lineage review.\n\n## Code Work\n\nFor L2 code-changing tasks, prefer isolated worktrees. The runner prepares reviewable local changes and verification evidence; it does not implicitly commit, push, publish, deploy, merge, or delete branches.\n\nSafe review flow:\n\n```bash\nloop-engineering code-task-status --root --queue \nloop-engineering code-worktree-inspect --root --queue --task-id \nloop-engineering code-worktree-diff --root --queue --task-id \nloop-engineering code-task-autoflow --root --queue --task-id --until closeout\nloop-engineering code-patch-apply-plan --root --patch --json\n```\n\nApplying a patch and cleaning a worktree require their explicit confirmation flags. Preserve unrelated user changes and never treat a dirty worktree as disposable.\n\n## Observability and Artifacts\n\nUse read-only diagnostics before mutation:\n\n```bash\nloop-engineering doctor --root --json\nloop-engineering summarize --root --queue --limit 20\nloop-engineering project-status --root --project \n```\n\nTask artifacts live under:\n\n```text\nruntime/loops//tasks//\nruntime/loops//runs/\nruntime/loops//{inbox,active,done,failed,canceled}/\n```\n\nExpected evidence includes `task_contract.json`, `acceptance_plan.json`, `dev_plan.json`, checkpoints, acceptance reviews, `final_judgement.json`, revision requests, amendments, supersede markers, progress notifications, and lineage bundles.\n\nProject artifacts live under:\n\n```text\nconfigs/loops/projects/.json\nruntime/loops/projects//\n```\n\nSummaries must cite the latest run/task/project evidence, verification performed, unmet checks, and blocker reason. Keep raw noisy logs in runtime artifacts; durable memory receives only distilled decisions, recurring failures, accepted safety rules, and verified completion facts.\n\n## Scheduler Policy\n\nUse scheduler ticks only after manual verification. Adaptive schedules may speed up with successful queued work and back off on empty queues, failures, long runs, or human gates.\n\n`queue-scheduler-tick` is adaptive cadence logic, not a resident daemon. A cron, systemd timer, or equivalent external scheduler must wake it regularly. For project queues that promise automatic continuation, set `scheduler.required=true` and a bounded `scheduler.heartbeatMaxAge`; `doctor` must fail with `scheduler_missing` whenever queued work exists without a fresh scheduler heartbeat.\n\nProgress notification must be scoped and idempotent. Report failures, human gates, status changes, and terminal completion promptly; throttle routine progress and idle updates.\n\n## Final Checklist\n\nBefore saying a loop is finished, verify:\n\n- Was this a scoped task or project-level objective?\n- Is the correct contract present and current?\n- Were all amendments applied?\n- Did verification and acceptance pass?\n- Is `final_judgement.json` acceptable?\n- For a project, are all completion-contract items accepted and the backlog terminal?\n- Are there any unmet requirements, pending revisions, gates, or external-write confirmations?\n- Does the report distinguish milestone status from total-project status?\n- Are evidence paths and next actions included?\n\nIf any project requirement remains, report a phase/task result and continue with the next authorized item; do not claim the project or Loop is complete.\n\nFile v0.15.20:_meta.json\n\n{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.20\",\n \"publishedAt\": 1790658599141\n}\n\nFile v0.15.20:references/npm-package.md\n\n# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.19`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks --confirm-install\nloop-engineering-hermes-doctor --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-smoke --root /path/to/hermes/workspace --queue agent-tasks\n```\n\nInstalled commands:\n\n```bash\nloop-engineering init --root /path/to/workspace\nloop-engineering verify --root /path/to/workspace\nloop-engineering run --root /path/to/workspace --config configs/loops/.json\nloop-engineering status --root /path/to/workspace\nloop-engineering doctor --root /path/to/workspace\nloop-engineering summarize --root /path/to/workspace --limit 20\nloop-engineering project-intake --root /path/to/workspace --name --brief \"Project brief\"\nloop-engineering project-plan --root /path/to/workspace --project \nloop-engineering project-status --root /path/to/workspace --project \nloop-engineering enqueue --root /path/to/workspace --queue --title \"Title\" --task \"Task body\"\nloop-engineering queue-init --root /path/to/workspace --queue \nloop-engineering code-queue-init --root /path/to/workspace --queue \nloop-engineering run-queue --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-status --root /path/to/workspace --queue \nloop-engineering queue-scheduler-tick --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-peek --root /path/to/workspace --queue \nloop-engineering queue-cancel --root /path/to/workspace --queue --task-id \nloop-engineering queue-requeue --root /path/to/workspace --queue --task-id \nloop-engineering queue-revision-next --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage-bundle --root /path/to/workspace --queue --task-id \nloop-engineering queue-human-decision --root /path/to/workspace --queue --task-id --decision approve|request_changes|reject\nloop-engineering code-worktree-list --root /path/to/workspace --queue \nloop-engineering code-worktree-inspect --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-diff --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-export --root /path/to/workspace --queue --task-id \nloop-engineering code-patch-verify --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply-plan --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply --root /path/to/workspace --patch runtime/loops//patches/.patch --confirm-apply\nloop-engineering code-review-bundle --root /path/to/workspace --queue --task-id \nloop-engineering code-task-closeout --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --all-actionable --until closeout\nloop-engineering code-task-finish --root /path/to/workspace --queue --task-id --confirm-apply --confirm-cleanup\nloop-engineering code-task-run --root /path/to/workspace --queue --title \"Title\" --task \"Task body\" --confirm-apply --confirm-cleanup\nloop-engineering code-task-dashboard --root /path/to/workspace --queue \nloop-engineering code-task-status --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup-plan --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup --root /path/to/workspace --queue --confirm-cleanup\nagent-loop status --root /path/to/workspace\nLOOP_WORKDIR=/path/to/workspace run-loop-cron.sh configs/loops/.json\n```\n\n`code-queue-init` creates an L2 assisted code queue config. Each task runs in\nan isolated git worktree and branch, then runs configured verification commands\nand records diff/status summaries. It does not push, merge, or delete\nworktrees.\n\n`queue-scheduler-tick` is the adaptive queue cadence command. It treats 10\nminutes as the bootstrap interval, writes live cadence state to\n`runtime/loops//scheduler/state.json`, speeds up after successful work\nwhen tasks remain queued, and backs off for empty queues, failures, human gates,\nor long runs.\n\n`project-intake` is the high-level entry for fuzzy project briefs. It writes a\ndeterministic project spec draft, human-readable plan, action policy, checks,\nand initial backlog under `runtime/loops/projects//` without enqueuing\nor executing work. `project-plan` solidifies that draft into\n`configs/loops/projects/.json`, generates the queue config, and writes\nthe initial backlog artifact. `project-status` aggregates the project queues\nwithout changing queue state.\n\n`code-worktree-list`, `code-worktree-inspect`, `code-worktree-diff`,\n`code-worktree-export`, `code-patch-verify`, `code-patch-apply-plan`,\n`code-patch-apply`, `code-review-bundle`, `code-task-closeout`,\n`code-task-autoflow`, `code-task-finish`, `code-task-run`, `code-task-dashboard`,\n`code-task-status`, `code-worktree-cleanup-plan`, and\n`code-worktree-cleanup`\nare review and\nhandoff commands for code queues.\nThey report branch, path, dirty status, verification status, diff summaries,\npatch output, exported patch artifacts, untracked files, whether an exported\npatch still passes `git apply --check --binary`, whether it is safe to apply,\nreview bundle files, which retained worktrees are cleanup candidates, and\nconfirmation-gated cleanup of reviewed worktrees. Closeout artifacts summarize\nthe task's final review, patch, apply-plan, cleanup, and next-action state.\nStatus ledgers summarize task-level queue, worktree, patch, review, closeout,\ncleanup, and next-action state without writing artifacts.\nDashboards summarize queue counts, task counts, next-action counts,\ncleanup/orphan state, priority tasks, and recommended commands without writing\nartifacts.\nFinish applies one reviewed patch to the main workspace and removes that one\nreviewed worktree only after default patch, review, and closeout artifacts are\npresent and both `--confirm-apply` and `--confirm-cleanup` are supplied; it\nalso writes a finish artifact. Status and dashboard views read finish artifacts:\ntasks ready to land report `ready_to_finish`, and successfully finished tasks\nreport `landed` with finish status, patch-applied, and worktree-cleaned fields.\nTask run enqueues one code task, processes one worktree queue run, runs\nautoflow through closeout, finishes the reviewed task, and reruns configured\nworktree verification commands in the main workspace.\nAutoflow runs export, patch verification, apply-plan, and review generation by\ndefault, and can also write closeout artifacts with `--until closeout`; it skips\nexisting artifacts unless `--force` is supplied. Batch autoflow with\n`--all-actionable` reads the status ledger and runs the same safe flow across\ntasks that need export, review, or closeout artifacts.\nActual patch application requires `--confirm-apply` and still does not stage,\ncommit, push, merge, or change queue state.\nActual worktree cleanup requires `--confirm-cleanup`; dirty worktrees require a\ndefault exported patch, passing patch verification, and an existing review\nbundle.\n\nThe package contains `bin/`, `lib/`, `scripts/`, `templates/`, and\n`skills/taskforce-loop-engineering/`.\n\nFile v0.15.20:skill-card.md\n\n## Description:\n\nDurable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ambitioncn](https://clawhub.ai/user/ambitioncn)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and teams use this skill to run explicitly requested task and project loops with progress updates, verification, revisions, and human approval before sensitive actions.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installation can create workspace queues, runtime artifacts, dashboard services, gateway coupling, and scheduled wakeups.\n\nMitigation: Review the installation plan and destination before confirming writes; use a pinned package version or vetted source checkout in sensitive environments.\n\nRisk: Exposing the dashboard can make loop controls reachable over a network.\n\nMitigation: Keep dashboard access local or protect network access with appropriate controls.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering)\n- [npm package commands](references/npm-package.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration guidance]\n\n**Output Format:** [Markdown status reports and setup guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Task and project status with verification evidence and next actions]\n\n## Skill Version(s):\n\n0.15.20 (source: server-resolved release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.15.19: 4 files, 11270 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (2280b), SKILL.md (19972b), _meta.json (147b)\n\nFile v0.15.19:SKILL.md\n\n---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` address, and fails closed rather than binding all interfaces. Tailnet mode relies on Tailscale ACLs/Grants and does not add application-level login. The plan must declare the selected mode before writes, and the doctor must verify the Dashboard service and gateway drop-in. Use `loop-engineering-dashboard-autostart-install --listen localhost|tailscale` only for standalone install or repair.\n\nThe installer never creates the worker agent. After installation, verify wiring before using a real task:\n\n```bash\nloop-engineering-openclaw-doctor \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n\nloop-engineering-openclaw-smoke \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n```\n\nIf the CLI or integration is missing and the user requested installation or repair, install it within the authorized host/workspace scope, then run doctor and the disposable smoke. If the user only asked what is missing, report the exact package, repository, commands, and current deployment state without mutating the system.\n\n### Hermes Agent Integration\n\nThe core CLI is platform-neutral, but Hermes conversation routing requires its own dispatcher and notifier. Generate a plan and verify its installation confirmation summary identifies Hermes, the absolute Hermes CLI path, intended workspace and queue, systemd scheduler, source-bound notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Confirm installation only after that review, then run the read-only doctor and disposable smoke:\n\n```bash\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks \\\n --confirm-install\n\nloop-engineering-hermes-doctor \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-smoke \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n```\n\nThe confirmed Hermes install creates the same Dashboard service and couples it to `hermes-gateway.service`. It accepts `--dashboard-listen localhost|tailscale` with the same default-local, Tailnet-only binding, fail-closed resolution, and ACL/Grant boundary as OpenClaw. The plan and doctor must expose and verify this coupling.\n\nThe generated worker uses `hermes -z` (`--oneshot`); the notifier uses `hermes send` without\nan LLM call. Preserve source metadata and pass `--source-target` in Hermes\n`platform:chat_id[:thread_id]` format. The managed systemd scheduler owns wakeups\nso durable queue continuity does not depend on resuming a Hermes Cron session.\n\n## Cross-interface Human Gates\n\nDashboard and chat approvals use one Gate Command core and one authoritative gate artifact. Cards must show project/task, Gate ID, action, reason, impact, risk, cost/budget, evidence, Dashboard URL, expiry and generation; processed cards are refreshed disabled. Only card buttons or exact card-bound `/approve gate_`, `/reject gate_` and `/request_revision gate_ ` replies may mutate a gate. Ordinary chat, quotes, forwards, screenshots and ordinal phrases fail closed as `ignored_untrusted_chat`; `/show_gate gate_` is display-only.\n\nThe OpenClaw installer generates `scripts/loops/openclaw-loop-gate.mjs`. A trusted Feishu callback/plugin transport must verify the official signature or encrypted-event envelope, timestamp/nonce and secret before invoking it with `LOOP_GATE_CHANNEL=feishu` and `LOOP_FEISHU_SIGNATURE_VERIFIED=1`; missing verification fails with `feishu_signature_unverified`. The bridge itself performs no delivery. Other channel transports pass normalized, source-bound events. Dashboard and chat commands share actor/source binding, generation fencing, idempotency receipts, confirmation escalation and synchronized card state.\n\nAfter installation, run `loop-engineering-openclaw-doctor` and `loop-engineering-openclaw-smoke`. Doctor syntax-checks and locally self-tests the Gate bridge; smoke remains disposable and uses dry-run notifications. Neither command sends an online test message.\n\n## Conversation Contract\n\nInterpret explicit loop language as follows:\n\n- `走 loop：`: enqueue and immediately execute one runner tick with notification.\n- `走 loop 并立刻执行`: synonym for the default above.\n- `走 loop，只入队`, `只排队`, `暂不执行`, or `不立即执行`: enqueue without starting a tick.\n- `继续当前 loop，补充要求：…`: amend the active task in place. Preserve the task id and worker session, write a versioned amendment, update the task contract/dev plan/acceptance plan, and require the worker to reread the latest amendment before checkpoints and completion.\n- A new explicit `走 loop` request while another task is active is a correction/replacement, not ordinary backlog. Supersede the active task at a safe boundary, retain its evidence and lineage, then start the replacement after the lock is released.\n- Status, progress, evidence, or failure questions are read-only and must not start another tick unless the user explicitly asks to continue/run.\n\nDo not infer a queue or dispatcher from this skill. Use the integration installed in the current workspace. For OpenClaw, inspect the generated queue configuration under `configs/loops/queues/` and use the managed wrapper when present. A default installation uses queue `agent-tasks` and the generic wrapper below; an operator may choose another queue or worker during installation.\n\n```bash\nnode scripts/loops/openclaw-loop.mjs route --message \"\" [source options]\nnode scripts/loops/openclaw-loop.mjs run-once\nloop-engineering queue-status --queue --root . --json\nloop-engineering queue-peek --queue --root . --json\n```\n\nIf the managed wrapper or queue configuration is absent, stop and run the platform installer/doctor workflow above. Product names, personal agent names, and host-specific dispatchers belong in local workspace instructions, never in this distributed skill.\n\nPass the original request faithfully. Preserve source channel, target, account, message id, and reply-to metadata so progress, human gates, and terminal results return to the originating conversation. Missing delivery routing must fail closed.\n\n## Task vs Project Classification\n\nClassify scope before enqueueing.\n\n### Scoped task\n\nA bounded change, diagnosis, review, or deliverable with a clear local acceptance target can use one task contract.\n\n### Project-level objective\n\nTreat a request as project-level when the user asks to build/develop/finish a complete product or system, achieve an overall outcome, or otherwise describes a multi-milestone terminal goal.\n\nFor a project-level objective:\n\n1. Run project intake and create a project spec.\n2. Write an explicit terminal-state/completion contract.\n3. Build a complete backlog covering every requirement and known acceptance dimension.\n4. Link queue tasks to the project backlog and terminal contract.\n5. Continue through implementation, verification, revisions, and the next actionable backlog item within the authorized safety boundary.\n6. Stop only when total project acceptance passes, or a genuine human authorization/product decision/external-state blocker prevents meaningful progress.\n\nNever silently narrow a complete-project request into “first milestone” and call that the Loop complete. A single queue task or milestone may be complete while the project remains active.\n\nRecommended commands:\n\n```bash\nloop-engineering project-intake --root --name --brief \"\" --type auto\nloop-engineering project-plan --root --project \nloop-engineering project-status --root --project \n```\n\nThe project completion contract must contain:\n\n- terminal user-visible outcome;\n- in-scope and explicitly out-of-scope capabilities;\n- complete requirement/backlog mapping;\n- acceptance checks and evidence locations;\n- operational/security/data/deployment requirements when relevant;\n- unresolved decisions and required authority;\n- a rule that milestone completion cannot satisfy project completion;\n- final acceptance status with unmet items and blockers.\n\nIf implementation reveals missing work, amend the project backlog/contract before continuing. Do not redefine the terminal goal downward to fit completed work.\n\n## Completion Semantics\n\nUse precise language:\n\n- `阶段完成` or `任务完成`: one task/milestone passed its own acceptance checks.\n- `项目完成` or `Loop 跑完`: only when the project completion contract is fully accepted and no required work remains.\n- `blocked`: only for a concrete blocker requiring human authority/input or an external state change, with evidence and a specific unblock request.\n- `needs_revision`: acceptance found actionable gaps; create a changed-strategy revision rather than claiming completion.\n- `superseded`: a newer explicit loop request replaced the task; preserve lineage and evidence.\n\nFinal reporting for project work must always state both task/milestone status and total-project status.\n\n## Safety and Authority\n\nLoop invocation authorizes the requested workflow, not unlimited external action.\n\nRequire separate explicit confirmation for:\n\n- external messages, publication, social posting, or outreach;\n- destructive deletion or difficult-to-recover changes;\n- production configuration/deployment changes not already clearly requested;\n- credential creation/change/exposure;\n- paid model/API usage beyond an established budget;\n- memory deletion or migration;\n- device/process instrumentation such as `frida`, `tcpdump`, `adb`, `mitmproxy`, hooks, attach/spawn, decrypt, `su`, `kill`, or `pkill`.\n\nHuman permission prompts and missing authorization are stop conditions, not retryable failures. `INSTALL_FAILED_USER_RESTRICTED`, device unauthorized, permission denied, and equivalent states require a concrete human-action gate.\n\nTimeouts must terminate the spawned process group. After instrumentation timeouts, verify that no child instrumentation/proxy process remains.\n\n## Operating Flow\n\n1. Read existing project docs, loop configs, queue state, and relevant dirty worktree state.\n2. Classify task vs project and define the correct contract before execution.\n3. Use `route-message` or the installed conversation wrapper to preserve source metadata and apply immediate/queue-only/amend/supersede semantics.\n4. Run preflight before mutable work.\n5. Execute one bounded tick or the project’s next actionable backlog item.\n6. Emit ordered progress: planning, preflight, worker start, checkpoints, verification, acceptance, final judgement.\n7. Inspect run artifacts; never infer success only from dispatcher exit code.\n8. If acceptance fails, write a revision request with changed diagnosis/tactic/evidence/verification.\n9. Run `doctor` after configuration or queue changes.\n10. For projects, re-read project status and completion contract, then automatically advance to the next safe actionable item.\n11. Report terminal status with evidence, unmet items, blockers, and next action.\n\nDo not add cron/timers until one manual tick passes.\n\n## Core CLI\n\nPrefer the installed CLI:\n\n```bash\nloop-engineering verify --root \nloop-engineering doctor --root [--json]\nloop-engineering summarize --root --limit 20\nloop-engineering route-message --root --message \"\" --queue --route --confirm-execute [--supersede-active | --amend-active] [source options]\nloop-engineering queue-status --root --queue \nloop-engineering queue-peek --root --queue \nloop-engineering run-queue --root --config configs/loops/queues/.json\nloop-engineering queue-revision-next --root --queue --task-id \nloop-engineering queue-lineage --root --queue --task-id \nloop-engineering queue-lineage-bundle --root --queue --task-id \nloop-engineering queue-human-decision --root --queue --task-id --decision approve|request_changes|reject\nloop-engineering queue-human-input-resolve --root --queue --gate-id --input \"\" [--secret-input|--non-secret-input]\nloop-engineering queue-terminal-notify --root --queue (--notify-command \"\" | --dry-run)\nloop-engineering queue-human-input-notify --root --queue (--notify-command \"\" | --dry-run)\n```\n\nIf the package is available only in the workspace:\n\n```bash\nnode packages/loop-engineering/bin/loop-engineering.mjs \n```\n\nUse `run-queue-drain` only when batch draining is explicitly intended. Conversation routing normally runs one task/tick and uses supersede/amend behavior.\n\n## Revision Discipline\n\nA dispatcher-successful run is not automatically accepted. Inspect `final_judgement.json`, acceptance reviews, checkpoints, and verification evidence.\n\nWhen acceptance needs changes:\n\n- mark `needs_revision`;\n- retain the failed source task;\n- use `queue-revision-next`;\n- require a changed diagnosis, implementation tactic, evidence source, or verification step;\n- inspect lineage before forcing repeated attempts.\n\nDefault revision policy may stop after three rounds, two repeated goal signatures, or repeated unchanged strategy. `--force` requires an explicit human override after lineage review.\n\n## Code Work\n\nFor L2 code-changing tasks, prefer isolated worktrees. The runner prepares reviewable local changes and verification evidence; it does not implicitly commit, push, publish, deploy, merge, or delete branches.\n\nSafe review flow:\n\n```bash\nloop-engineering code-task-status --root --queue \nloop-engineering code-worktree-inspect --root --queue --task-id \nloop-engineering code-worktree-diff --root --queue --task-id \nloop-engineering code-task-autoflow --root --queue --task-id --until closeout\nloop-engineering code-patch-apply-plan --root --patch --json\n```\n\nApplying a patch and cleaning a worktree require their explicit confirmation flags. Preserve unrelated user changes and never treat a dirty worktree as disposable.\n\n## Observability and Artifacts\n\nUse read-only diagnostics before mutation:\n\n```bash\nloop-engineering doctor --root --json\nloop-engineering summarize --root --queue --limit 20\nloop-engineering project-status --root --project \n```\n\nTask artifacts live under:\n\n```text\nruntime/loops//tasks//\nruntime/loops//runs/\nruntime/loops//{inbox,active,done,failed,canceled}/\n```\n\nExpected evidence includes `task_contract.json`, `acceptance_plan.json`, `dev_plan.json`, checkpoints, acceptance reviews, `final_judgement.json`, revision requests, amendments, supersede markers, progress notifications, and lineage bundles.\n\nProject artifacts live under:\n\n```text\nconfigs/loops/projects/.json\nruntime/loops/projects//\n```\n\nSummaries must cite the latest run/task/project evidence, verification performed, unmet checks, and blocker reason. Keep raw noisy logs in runtime artifacts; durable memory receives only distilled decisions, recurring failures, accepted safety rules, and verified completion facts.\n\n## Scheduler Policy\n\nUse scheduler ticks only after manual verification. Adaptive schedules may speed up with successful queued work and back off on empty queues, failures, long runs, or human gates.\n\n`queue-scheduler-tick` is adaptive cadence logic, not a resident daemon. A cron, systemd timer, or equivalent external scheduler must wake it regularly. For project queues that promise automatic continuation, set `scheduler.required=true` and a bounded `scheduler.heartbeatMaxAge`; `doctor` must fail with `scheduler_missing` whenever queued work exists without a fresh scheduler heartbeat.\n\nProgress notification must be scoped and idempotent. Report failures, human gates, status changes, and terminal completion promptly; throttle routine progress and idle updates.\n\n## Final Checklist\n\nBefore saying a loop is finished, verify:\n\n- Was this a scoped task or project-level objective?\n- Is the correct contract present and current?\n- Were all amendments applied?\n- Did verification and acceptance pass?\n- Is `final_judgement.json` acceptable?\n- For a project, are all completion-contract items accepted and the backlog terminal?\n- Are there any unmet requirements, pending revisions, gates, or external-write confirmations?\n- Does the report distinguish milestone status from total-project status?\n- Are evidence paths and next actions included?\n\nIf any project requirement remains, report a phase/task result and continue with the next authorized item; do not claim the project or Loop is complete.\n\nFile v0.15.19:_meta.json\n\n{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.19\",\n \"publishedAt\": 1789814090501\n}\n\nFile v0.15.19:references/npm-package.md\n\n# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.19`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks --confirm-install\nloop-engineering-hermes-doctor --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-smoke --root /path/to/hermes/workspace --queue agent-tasks\n```\n\nInstalled commands:\n\n```bash\nloop-engineering init --root /path/to/workspace\nloop-engineering verify --root /path/to/workspace\nloop-engineering run --root /path/to/workspace --config configs/loops/.json\nloop-engineering status --root /path/to/workspace\nloop-engineering doctor --root /path/to/workspace\nloop-engineering summarize --root /path/to/workspace --limit 20\nloop-engineering project-intake --root /path/to/workspace --name --brief \"Project brief\"\nloop-engineering project-plan --root /path/to/workspace --project \nloop-engineering project-status --root /path/to/workspace --project \nloop-engineering enqueue --root /path/to/workspace --queue --title \"Title\" --task \"Task body\"\nloop-engineering queue-init --root /path/to/workspace --queue \nloop-engineering code-queue-init --root /path/to/workspace --queue \nloop-engineering run-queue --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-status --root /path/to/workspace --queue \nloop-engineering queue-scheduler-tick --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-peek --root /path/to/workspace --queue \nloop-engineering queue-cancel --root /path/to/workspace --queue --task-id \nloop-engineering queue-requeue --root /path/to/workspace --queue --task-id \nloop-engineering queue-revision-next --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage-bundle --root /path/to/workspace --queue --task-id \nloop-engineering queue-human-decision --root /path/to/workspace --queue --task-id --decision approve|request_changes|reject\nloop-engineering code-worktree-list --root /path/to/workspace --queue \nloop-engineering code-worktree-inspect --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-diff --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-export --root /path/to/workspace --queue --task-id \nloop-engineering code-patch-verify --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply-plan --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply --root /path/to/workspace --patch runtime/loops//patches/.patch --confirm-apply\nloop-engineering code-review-bundle --root /path/to/workspace --queue --task-id \nloop-engineering code-task-closeout --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --all-actionable --until closeout\nloop-engineering code-task-finish --root /path/to/workspace --queue --task-id --confirm-apply --confirm-cleanup\nloop-engineering code-task-run --root /path/to/workspace --queue --title \"Title\" --task \"Task body\" --confirm-apply --confirm-cleanup\nloop-engineering code-task-dashboard --root /path/to/workspace --queue \nloop-engineering code-task-status --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup-plan --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup --root /path/to/workspace --queue --confirm-cleanup\nagent-loop status --root /path/to/workspace\nLOOP_WORKDIR=/path/to/workspace run-loop-cron.sh configs/loops/.json\n```\n\n`code-queue-init` creates an L2 assisted code queue config. Each task runs in\nan isolated git worktree and branch, then runs configured verification commands\nand records diff/status summaries. It does not push, merge, or delete\nworktrees.\n\n`queue-scheduler-tick` is the adaptive queue cadence command. It treats 10\nminutes as the bootstrap interval, writes live cadence state to\n`runtime/loops//scheduler/state.json`, speeds up after successful work\nwhen tasks remain queued, and backs off for empty queues, failures, human gates,\nor long runs.\n\n`project-intake` is the high-level entry for fuzzy project briefs. It writes a\ndeterministic project spec draft, human-readable plan, action policy, checks,\nand initial backlog under `runtime/loops/projects//` without enqueuing\nor executing work. `project-plan` solidifies that draft into\n`configs/loops/projects/.json`, generates the queue config, and writes\nthe initial backlog artifact. `project-status` aggregates the project queues\nwithout changing queue state.\n\n`code-worktree-list`, `code-worktree-inspect`, `code-worktree-diff`,\n`code-worktree-export`, `code-patch-verify`, `code-patch-apply-plan`,\n`code-patch-apply`, `code-review-bundle`, `code-task-closeout`,\n`code-task-autoflow`, `code-task-finish`, `code-task-run`, `code-task-dashboard`,\n`code-task-status`, `code-worktree-cleanup-plan`, and\n`code-worktree-cleanup`\nare review and\nhandoff commands for code queues.\nThey report branch, path, dirty status, verification status, diff summaries,\npatch output, exported patch artifacts, untracked files, whether an exported\npatch still passes `git apply --check --binary`, whether it is safe to apply,\nreview bundle files, which retained worktrees are cleanup candidates, and\nconfirmation-gated cleanup of reviewed worktrees. Closeout artifacts summarize\nthe task's final review, patch, apply-plan, cleanup, and next-action state.\nStatus ledgers summarize task-level queue, worktree, patch, review, closeout,\ncleanup, and next-action state without writing artifacts.\nDashboards summarize queue counts, task counts, next-action counts,\ncleanup/orphan state, priority tasks, and recommended commands without writing\nartifacts.\nFinish applies one reviewed patch to the main workspace and removes that one\nreviewed worktree only after default patch, review, and closeout artifacts are\npresent and both `--confirm-apply` and `--confirm-cleanup` are supplied; it\nalso writes a finish artifact. Status and dashboard views read finish artifacts:\ntasks ready to land report `ready_to_finish`, and successfully finished tasks\nreport `landed` with finish status, patch-applied, and worktree-cleaned fields.\nTask run enqueues one code task, processes one worktree queue run, runs\nautoflow through closeout, finishes the reviewed task, and reruns configured\nworktree verification commands in the main workspace.\nAutoflow runs export, patch verification, apply-plan, and review generation by\ndefault, and can also write closeout artifacts with `--until closeout`; it skips\nexisting artifacts unless `--force` is supplied. Batch autoflow with\n`--all-actionable` reads the status ledger and runs the same safe flow across\ntasks that need export, review, or closeout artifacts.\nActual patch application requires `--confirm-apply` and still does not stage,\ncommit, push, merge, or change queue state.\nActual worktree cleanup requires `--confirm-cleanup`; dirty worktrees require a\ndefault exported patch, passing patch verification, and an existing review\nbundle.\n\nThe package contains `bin/`, `lib/`, `scripts/`, `templates/`, and\n`skills/taskforce-loop-engineering/`.\n\nFile v0.15.19:skill-card.md\n\n## Description:\n\nDurable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ambitioncn](https://clawhub.ai/user/ambitioncn)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to operate durable task and project loops for agent work, including queueing, verification, revision handling, progress reporting, and governed completion.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Durable loop orchestration can add persistent queue, scheduler, dashboard, or service behavior to a workspace.\n\nMitigation: Install only in the intended workspace, review the generated install plan before confirmation, and run doctor and smoke checks before enabling scheduler or service setup.\n\nRisk: An unpinned or unreviewed npm package install could introduce unexpected CLI behavior.\n\nMitigation: Pin or otherwise verify the npm package version before installation and prefer read-only help or plan commands before mutable operations.\n\nRisk: Dashboard exposure beyond localhost may depend on Tailnet ACLs rather than application-level login.\n\nMitigation: Keep the dashboard bound to localhost unless Tailnet access controls are explicitly acceptable for the deployment.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering)\n- [npm Package Reference](references/npm-package.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with inline shell commands and configuration steps]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce installation plans, status summaries, verification commands, and risk-aware next steps; mutable operations are gated by explicit confirmation.]\n\n## Skill Version(s):\n\n0.15.19 (source: server release metadata and npm package reference)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.15.18: 4 files, 11331 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (2442b), SKILL.md (19972b), _meta.json (147b)\n\nFile v0.15.18:SKILL.md\n\n---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` address, and fails closed rather than binding all interfaces. Tailnet mode relies on Tailscale ACLs/Grants and does not add application-level login. The plan must declare the selected mode before writes, and the doctor must verify the Dashboard service and gateway drop-in. Use `loop-engineering-dashboard-autostart-install --listen localhost|tailscale` only for standalone install or repair.\n\nThe installer never creates the worker agent. After installation, verify wiring before using a real task:\n\n```bash\nloop-engineering-openclaw-doctor \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n\nloop-engineering-openclaw-smoke \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n```\n\nIf the CLI or integration is missing and the user requested installation or repair, install it within the authorized host/workspace scope, then run doctor and the disposable smoke. If the user only asked what is missing, report the exact package, repository, commands, and current deployment state without mutating the system.\n\n### Hermes Agent Integration\n\nThe core CLI is platform-neutral, but Hermes conversation routing requires its own dispatcher and notifier. Generate a plan and verify its installation confirmation summary identifies Hermes, the absolute Hermes CLI path, intended workspace and queue, systemd scheduler, source-bound notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Confirm installation only after that review, then run the read-only doctor and disposable smoke:\n\n```bash\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks \\\n --confirm-install\n\nloop-engineering-hermes-doctor \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-smoke \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n```\n\nThe confirmed Hermes install creates the same Dashboard service and couples it to `hermes-gateway.service`. It accepts `--dashboard-listen localhost|tailscale` with the same default-local, Tailnet-only binding, fail-closed resolution, and ACL/Grant boundary as OpenClaw. The plan and doctor must expose and verify this coupling.\n\nThe generated worker uses `hermes -z` (`--oneshot`); the notifier uses `hermes send` without\nan LLM call. Preserve source metadata and pass `--source-target` in Hermes\n`platform:chat_id[:thread_id]` format. The managed systemd scheduler owns wakeups\nso durable queue continuity does not depend on resuming a Hermes Cron session.\n\n## Cross-interface Human Gates\n\nDashboard and chat approvals use one Gate Command core and one authoritative gate artifact. Cards must show project/task, Gate ID, action, reason, impact, risk, cost/budget, evidence, Dashboard URL, expiry and generation; processed cards are refreshed disabled. Only card buttons or exact card-bound `/approve gate_`, `/reject gate_` and `/request_revision gate_ ` replies may mutate a gate. Ordinary chat, quotes, forwards, screenshots and ordinal phrases fail closed as `ignored_untrusted_chat`; `/show_gate gate_` is display-only.\n\nThe OpenClaw installer generates `scripts/loops/openclaw-loop-gate.mjs`. A trusted Feishu callback/plugin transport must verify the official signature or encrypted-event envelope, timestamp/nonce and secret before invoking it with `LOOP_GATE_CHANNEL=feishu` and `LOOP_FEISHU_SIGNATURE_VERIFIED=1`; missing verification fails with `feishu_signature_unverified`. The bridge itself performs no delivery. Other channel transports pass normalized, source-bound events. Dashboard and chat commands share actor/source binding, generation fencing, idempotency receipts, confirmation escalation and synchronized card state.\n\nAfter installation, run `loop-engineering-openclaw-doctor` and `loop-engineering-openclaw-smoke`. Doctor syntax-checks and locally self-tests the Gate bridge; smoke remains disposable and uses dry-run notifications. Neither command sends an online test message.\n\n## Conversation Contract\n\nInterpret explicit loop language as follows:\n\n- `走 loop：`: enqueue and immediately execute one runner tick with notification.\n- `走 loop 并立刻执行`: synonym for the default above.\n- `走 loop，只入队`, `只排队`, `暂不执行`, or `不立即执行`: enqueue without starting a tick.\n- `继续当前 loop，补充要求：…`: amend the active task in place. Preserve the task id and worker session, write a versioned amendment, update the task contract/dev plan/acceptance plan, and require the worker to reread the latest amendment before checkpoints and completion.\n- A new explicit `走 loop` request while another task is active is a correction/replacement, not ordinary backlog. Supersede the active task at a safe boundary, retain its evidence and lineage, then start the replacement after the lock is released.\n- Status, progress, evidence, or failure questions are read-only and must not start another tick unless the user explicitly asks to continue/run.\n\nDo not infer a queue or dispatcher from this skill. Use the integration installed in the current workspace. For OpenClaw, inspect the generated queue configuration under `configs/loops/queues/` and use the managed wrapper when present. A default installation uses queue `agent-tasks` and the generic wrapper below; an operator may choose another queue or worker during installation.\n\n```bash\nnode scripts/loops/openclaw-loop.mjs route --message \"\" [source options]\nnode scripts/loops/openclaw-loop.mjs run-once\nloop-engineering queue-status --queue --root . --json\nloop-engineering queue-peek --queue --root . --json\n```\n\nIf the managed wrapper or queue configuration is absent, stop and run the platform installer/doctor workflow above. Product names, personal agent names, and host-specific dispatchers belong in local workspace instructions, never in this distributed skill.\n\nPass the original request faithfully. Preserve source channel, target, account, message id, and reply-to metadata so progress, human gates, and terminal results return to the originating conversation. Missing delivery routing must fail closed.\n\n## Task vs Project Classification\n\nClassify scope before enqueueing.\n\n### Scoped task\n\nA bounded change, diagnosis, review, or deliverable with a clear local acceptance target can use one task contract.\n\n### Project-level objective\n\nTreat a request as project-level when the user asks to build/develop/finish a complete product or system, achieve an overall outcome, or otherwise describes a multi-milestone terminal goal.\n\nFor a project-level objective:\n\n1. Run project intake and create a project spec.\n2. Write an explicit terminal-state/completion contract.\n3. Build a complete backlog covering every requirement and known acceptance dimension.\n4. Link queue tasks to the project backlog and terminal contract.\n5. Continue through implementation, verification, revisions, and the next actionable backlog item within the authorized safety boundary.\n6. Stop only when total project acceptance passes, or a genuine human authorization/product decision/external-state blocker prevents meaningful progress.\n\nNever silently narrow a complete-project request into “first milestone” and call that the Loop complete. A single queue task or milestone may be complete while the project remains active.\n\nRecommended commands:\n\n```bash\nloop-engineering project-intake --root --name --brief \"\" --type auto\nloop-engineering project-plan --root --project \nloop-engineering project-status --root --project \n```\n\nThe project completion contract must contain:\n\n- terminal user-visible outcome;\n- in-scope and explicitly out-of-scope capabilities;\n- complete requirement/backlog mapping;\n- acceptance checks and evidence locations;\n- operational/security/data/deployment requirements when relevant;\n- unresolved decisions and required authority;\n- a rule that milestone completion cannot satisfy project completion;\n- final acceptance status with unmet items and blockers.\n\nIf implementation reveals missing work, amend the project backlog/contract before continuing. Do not redefine the terminal goal downward to fit completed work.\n\n## Completion Semantics\n\nUse precise language:\n\n- `阶段完成` or `任务完成`: one task/milestone passed its own acceptance checks.\n- `项目完成` or `Loop 跑完`: only when the project completion contract is fully accepted and no required work remains.\n- `blocked`: only for a concrete blocker requiring human authority/input or an external state change, with evidence and a specific unblock request.\n- `needs_revision`: acceptance found actionable gaps; create a changed-strategy revision rather than claiming completion.\n- `superseded`: a newer explicit loop request replaced the task; preserve lineage and evidence.\n\nFinal reporting for project work must always state both task/milestone status and total-project status.\n\n## Safety and Authority\n\nLoop invocation authorizes the requested workflow, not unlimited external action.\n\nRequire separate explicit confirmation for:\n\n- external messages, publication, social posting, or outreach;\n- destructive deletion or difficult-to-recover changes;\n- production configuration/deployment changes not already clearly requested;\n- credential creation/change/exposure;\n- paid model/API usage beyond an established budget;\n- memory deletion or migration;\n- device/process instrumentation such as `frida`, `tcpdump`, `adb`, `mitmproxy`, hooks, attach/spawn, decrypt, `su`, `kill`, or `pkill`.\n\nHuman permission prompts and missing authorization are stop conditions, not retryable failures. `INSTALL_FAILED_USER_RESTRICTED`, device unauthorized, permission denied, and equivalent states require a concrete human-action gate.\n\nTimeouts must terminate the spawned process group. After instrumentation timeouts, verify that no child instrumentation/proxy process remains.\n\n## Operating Flow\n\n1. Read existing project docs, loop configs, queue state, and relevant dirty worktree state.\n2. Classify task vs project and define the correct contract before execution.\n3. Use `route-message` or the installed conversation wrapper to preserve source metadata and apply immediate/queue-only/amend/supersede semantics.\n4. Run preflight before mutable work.\n5. Execute one bounded tick or the project’s next actionable backlog item.\n6. Emit ordered progress: planning, preflight, worker start, checkpoints, verification, acceptance, final judgement.\n7. Inspect run artifacts; never infer success only from dispatcher exit code.\n8. If acceptance fails, write a revision request with changed diagnosis/tactic/evidence/verification.\n9. Run `doctor` after configuration or queue changes.\n10. For projects, re-read project status and completion contract, then automatically advance to the next safe actionable item.\n11. Report terminal status with evidence, unmet items, blockers, and next action.\n\nDo not add cron/timers until one manual tick passes.\n\n## Core CLI\n\nPrefer the installed CLI:\n\n```bash\nloop-engineering verify --root \nloop-engineering doctor --root [--json]\nloop-engineering summarize --root --limit 20\nloop-engineering route-message --root --message \"\" --queue --route --confirm-execute [--supersede-active | --amend-active] [source options]\nloop-engineering queue-status --root --queue \nloop-engineering queue-peek --root --queue \nloop-engineering run-queue --root --config configs/loops/queues/.json\nloop-engineering queue-revision-next --root --queue --task-id \nloop-engineering queue-lineage --root --queue --task-id \nloop-engineering queue-lineage-bundle --root --queue --task-id \nloop-engineering queue-human-decision --root --queue --task-id --decision approve|request_changes|reject\nloop-engineering queue-human-input-resolve --root --queue --gate-id --input \"\" [--secret-input|--non-secret-input]\nloop-engineering queue-terminal-notify --root --queue (--notify-command \"\" | --dry-run)\nloop-engineering queue-human-input-notify --root --queue (--notify-command \"\" | --dry-run)\n```\n\nIf the package is available only in the workspace:\n\n```bash\nnode packages/loop-engineering/bin/loop-engineering.mjs \n```\n\nUse `run-queue-drain` only when batch draining is explicitly intended. Conversation routing normally runs one task/tick and uses supersede/amend behavior.\n\n## Revision Discipline\n\nA dispatcher-successful run is not automatically accepted. Inspect `final_judgement.json`, acceptance reviews, checkpoints, and verification evidence.\n\nWhen acceptance needs changes:\n\n- mark `needs_revision`;\n- retain the failed source task;\n- use `queue-revision-next`;\n- require a changed diagnosis, implementation tactic, evidence source, or verification step;\n- inspect lineage before forcing repeated attempts.\n\nDefault revision policy may stop after three rounds, two repeated goal signatures, or repeated unchanged strategy. `--force` requires an explicit human override after lineage review.\n\n## Code Work\n\nFor L2 code-changing tasks, prefer isolated worktrees. The runner prepares reviewable local changes and verification evidence; it does not implicitly commit, push, publish, deploy, merge, or delete branches.\n\nSafe review flow:\n\n```bash\nloop-engineering code-task-status --root --queue \nloop-engineering code-worktree-inspect --root --queue --task-id \nloop-engineering code-worktree-diff --root --queue --task-id \nloop-engineering code-task-autoflow --root --queue --task-id --until closeout\nloop-engineering code-patch-apply-plan --root --patch --json\n```\n\nApplying a patch and cleaning a worktree require their explicit confirmation flags. Preserve unrelated user changes and never treat a dirty worktree as disposable.\n\n## Observability and Artifacts\n\nUse read-only diagnostics before mutation:\n\n```bash\nloop-engineering doctor --root --json\nloop-engineering summarize --root --queue --limit 20\nloop-engineering project-status --root --project \n```\n\nTask artifacts live under:\n\n```text\nruntime/loops//tasks//\nruntime/loops//runs/\nruntime/loops//{inbox,active,done,failed,canceled}/\n```\n\nExpected evidence includes `task_contract.json`, `acceptance_plan.json`, `dev_plan.json`, checkpoints, acceptance reviews, `final_judgement.json`, revision requests, amendments, supersede markers, progress notifications, and lineage bundles.\n\nProject artifacts live under:\n\n```text\nconfigs/loops/projects/.json\nruntime/loops/projects//\n```\n\nSummaries must cite the latest run/task/project evidence, verification performed, unmet checks, and blocker reason. Keep raw noisy logs in runtime artifacts; durable memory receives only distilled decisions, recurring failures, accepted safety rules, and verified completion facts.\n\n## Scheduler Policy\n\nUse scheduler ticks only after manual verification. Adaptive schedules may speed up with successful queued work and back off on empty queues, failures, long runs, or human gates.\n\n`queue-scheduler-tick` is adaptive cadence logic, not a resident daemon. A cron, systemd timer, or equivalent external scheduler must wake it regularly. For project queues that promise automatic continuation, set `scheduler.required=true` and a bounded `scheduler.heartbeatMaxAge`; `doctor` must fail with `scheduler_missing` whenever queued work exists without a fresh scheduler heartbeat.\n\nProgress notification must be scoped and idempotent. Report failures, human gates, status changes, and terminal completion promptly; throttle routine progress and idle updates.\n\n## Final Checklist\n\nBefore saying a loop is finished, verify:\n\n- Was this a scoped task or project-level objective?\n- Is the correct contract present and current?\n- Were all amendments applied?\n- Did verification and acceptance pass?\n- Is `final_judgement.json` acceptable?\n- For a project, are all completion-contract items accepted and the backlog terminal?\n- Are there any unmet requirements, pending revisions, gates, or external-write confirmations?\n- Does the report distinguish milestone status from total-project status?\n- Are evidence paths and next actions included?\n\nIf any project requirement remains, report a phase/task result and continue with the next authorized item; do not claim the project or Loop is complete.\n\nFile v0.15.18:_meta.json\n\n{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.18\",\n \"publishedAt\": 1789694004246\n}\n\nFile v0.15.18:references/npm-package.md\n\n# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.18`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks --confirm-install\nloop-engineering-hermes-doctor --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-smoke --root /path/to/hermes/workspace --queue agent-tasks\n```\n\nInstalled commands:\n\n```bash\nloop-engineering init --root /path/to/workspace\nloop-engineering verify --root /path/to/workspace\nloop-engineering run --root /path/to/workspace --config configs/loops/.json\nloop-engineering status --root /path/to/workspace\nloop-engineering doctor --root /path/to/workspace\nloop-engineering summarize --root /path/to/workspace --limit 20\nloop-engineering project-intake --root /path/to/workspace --name --brief \"Project brief\"\nloop-engineering project-plan --root /path/to/workspace --project \nloop-engineering project-status --root /path/to/workspace --project \nloop-engineering enqueue --root /path/to/workspace --queue --title \"Title\" --task \"Task body\"\nloop-engineering queue-init --root /path/to/workspace --queue \nloop-engineering code-queue-init --root /path/to/workspace --queue \nloop-engineering run-queue --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-status --root /path/to/workspace --queue \nloop-engineering queue-scheduler-tick --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-peek --root /path/to/workspace --queue \nloop-engineering queue-cancel --root /path/to/workspace --queue --task-id \nloop-engineering queue-requeue --root /path/to/workspace --queue --task-id \nloop-engineering queue-revision-next --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage-bundle --root /path/to/workspace --queue --task-id \nloop-engineering queue-human-decision --root /path/to/workspace --queue --task-id --decision approve|request_changes|reject\nloop-engineering code-worktree-list --root /path/to/workspace --queue \nloop-engineering code-worktree-inspect --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-diff --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-export --root /path/to/workspace --queue --task-id \nloop-engineering code-patch-verify --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply-plan --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply --root /path/to/workspace --patch runtime/loops//patches/.patch --confirm-apply\nloop-engineering code-review-bundle --root /path/to/workspace --queue --task-id \nloop-engineering code-task-closeout --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --task-id \nloop-engineering code-task-autoflow --root /path/to/workspace --queue --all-actionable --until closeout\nloop-engineering code-task-finish --root /path/to/workspace --queue --task-id --confirm-apply --confirm-cleanup\nloop-engineering code-task-run --root /path/to/workspace --queue --title \"Title\" --task \"Task body\" --confirm-apply --confirm-cleanup\nloop-engineering code-task-dashboard --root /path/to/workspace --queue \nloop-engineering code-task-status --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup-plan --root /path/to/workspace --queue \nloop-engineering code-worktree-cleanup --root /path/to/workspace --queue --confirm-cleanup\nagent-loop status --root /path/to/workspace\nLOOP_WORKDIR=/path/to/workspace run-loop-cron.sh configs/loops/.json\n```\n\n`code-queue-init` creates an L2 assisted code queue config. Each task runs in\nan isolated git worktree and branch, then runs configured verification commands\nand records diff/status summaries. It does not push, merge, or delete\nworktrees.\n\n`queue-scheduler-tick` is the adaptive queue cadence command. It treats 10\nminutes as the bootstrap interval, writes live cadence state to\n`runtime/loops//scheduler/state.json`, speeds up after successful work\nwhen tasks remain queued, and backs off for empty queues, failures, human gates,\nor long runs.\n\n`project-intake` is the high-level entry for fuzzy project briefs. It writes a\ndeterministic project spec draft, human-readable plan, action policy, checks,\nand initial backlog under `runtime/loops/projects//` without enqueuing\nor executing work. `project-plan` solidifies that draft into\n`configs/loops/projects/.json`, generates the queue config, and writes\nthe initial backlog artifact. `project-status` aggregates the project queues\nwithout changing queue state.\n\n`code-worktree-list`, `code-worktree-inspect`, `code-worktree-diff`,\n`code-worktree-export`, `code-patch-verify`, `code-patch-apply-plan`,\n`code-patch-apply`, `code-review-bundle`, `code-task-closeout`,\n`code-task-autoflow`, `code-task-finish`, `code-task-run`, `code-task-dashboard`,\n`code-task-status`, `code-worktree-cleanup-plan`, and\n`code-worktree-cleanup`\nare review and\nhandoff commands for code queues.\nThey report branch, path, dirty status, verification status, diff summaries,\npatch output, exported patch artifacts, untracked files, whether an exported\npatch still passes `git apply --check --binary`, whether it is safe to apply,\nreview bundle files, which retained worktrees are cleanup candidates, and\nconfirmation-gated cleanup of reviewed worktrees. Closeout artifacts summarize\nthe task's final review, patch, apply-plan, cleanup, and next-action state.\nStatus ledgers summarize task-level queue, worktree, patch, review, closeout,\ncleanup, and next-action state without writing artifacts.\nDashboards summarize queue counts, task counts, next-action counts,\ncleanup/orphan state, priority tasks, and recommended commands without writing\nartifacts.\nFinish applies one reviewed patch to the main workspace and removes that one\nreviewed worktree only after default patch, review, and closeout artifacts are\npresent and both `--confirm-apply` and `--confirm-cleanup` are supplied; it\nalso writes a finish artifact. Status and dashboard views read finish artifacts:\ntasks ready to land report `ready_to_finish`, and successfully finished tasks\nreport `landed` with finish status, patch-applied, and worktree-cleaned fields.\nTask run enqueues one code task, processes one worktree queue run, runs\nautoflow through closeout, finishes the reviewed task, and reruns configured\nworktree verification commands in the main workspace.\nAutoflow runs export, patch verification, apply-plan, and review generation by\ndefault, and can also write closeout artifacts with `--until closeout`; it skips\nexisting artifacts unless `--force` is supplied. Batch autoflow with\n`--all-actionable` reads the status ledger and runs the same safe flow across\ntasks that need export, review, or closeout artifacts.\nActual patch application requires `--confirm-apply` and still does not stage,\ncommit, push, merge, or change queue state.\nActual worktree cleanup requires `--confirm-cleanup`; dirty worktrees require a\ndefault exported patch, passing patch verification, and an existing review\nbundle.\n\nThe package contains `bin/`, `lib/`, `scripts/`, `templates/`, and\n`skills/taskforce-loop-engineering/`.\n\nFile v0.15.18:skill-card.md\n\n## Description:\n\nDurable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ambitioncn](https://clawhub.ai/user/ambitioncn)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and operators use this skill to route explicit loop requests into durable task or project queues with verification, revisions, progress reporting, human gates, and code-worktree workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The npm package and scheduler can create durable local services, wakeups, queue artifacts, and code-worktree workflows.\n\nMitigation: Review package provenance, prefer a pinned version, inspect the read-only install plan before confirming writes, and verify doctor or smoke output before running real tasks.\n\nRisk: Dashboard exposure can extend access beyond localhost if Tailnet mode is selected.\n\nMitigation: Keep the dashboard on localhost by default; use Tailscale mode only intentionally and rely on the operator's Tailnet ACL or Grant controls.\n\nRisk: Loop runs can prepare code patches and cleanup actions that affect a workspace.\n\nMitigation: Use the skill's confirmation-gated apply and cleanup flow, inspect generated evidence and patch plans, and preserve unrelated user changes.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering)\n- [GitHub repository](https://github.com/ambitioncn/taskforce-loop-engineering)\n- [npm package reference](references/npm-package.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown guidance with inline shell commands, configuration paths, and status or evidence summaries]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce queue artifacts, project/task evidence, local service plans, scheduler wakeups, and isolated code-worktree artifacts when the CLI is installed and explicitly confirmed.]\n\n## Skill Version(s):\n\n0.15.18 (source: server release metadata and npm package reference)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.15.17: 4 files, 11235 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (2135b), SKILL.md (19972b), _meta.json (147b)\n\nFile v0.15.17:SKILL.md\n\n---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` address, and fails closed rather than binding all interfaces. Tailnet mode relies on Tailscale ACLs/Grants and does not add application-level login. The plan must declare the selected mode before writes, and the doctor must verify the Dashboard service and gateway drop-in. Use `loop-engineering-dashboard-autostart-install --listen localhost|tailscale` only for standalone install or repair.\n\nThe installer never creates the worker agent. After installation, verify wiring before using a real task:\n\n```bash\nloop-engineering-openclaw-doctor \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n\nloop-engineering-openclaw-smoke \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main\n```\n\nIf the CLI or integration is missing and the user requested installation or repair, install it within the authorized host/workspace scope, then run doctor and the disposable smoke. If the user only asked what is missing, report the exact package, repository, commands, and current deployment state without mutating the system.\n\n### Hermes Agent Integration\n\nThe core CLI is platform-neutral, but Hermes conversation routing requires its own dispatcher and notifier. Generate a plan and verify its installation confirmation summary identifies Hermes, the absolute Hermes CLI path, intended workspace and queue, systemd scheduler, source-bound notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Confirm installation only after that review, then run the read-only doctor and disposable smoke:\n\n```bash\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-install \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks \\\n --confirm-install\n\nloop-engineering-hermes-doctor \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n\nloop-engineering-hermes-smoke \\\n --root /path/to/hermes/workspace \\\n --queue agent-tasks\n```\n\nThe confirmed Hermes install creates the same Dashboard service and couples it to `hermes-gateway.service`. It accepts `--dashboard-listen localhost|tailscale` with the same default-local, Tailnet-only binding, fail-closed resolution, and ACL/Grant boundary as OpenClaw. The plan and doctor must expose and verify this coupling.\n\nThe generated worker uses `hermes -z` (`--oneshot`); the notifier uses `hermes send` without\nan LLM call. Preserve source metadata and pass `--source-target` in Hermes\n`platform:chat_id[:thread_id]` format. The managed systemd scheduler owns wakeups\nso durable queue continuity does not depend on resuming a Hermes Cron session.\n\n## Cross-interface Human Gates\n\nDashboard and chat approvals use one Gate Command core and one authoritative gate artifact. Cards must show project/task, Gate ID, action, reason, impact, risk, cost/budget, evidence, Dashboard URL, expiry and generation; processed cards are refreshed disabled. Only card buttons or exact card-bound `/approve gate_`, `/reject gate_` and `/request_revision gate_ ` replies may mutate a gate. Ordinary chat, quotes, forwards, screenshots and ordinal phrases fail closed as `ignored_untrusted_chat`; `/show_gate gate_` is display-only.\n\nThe OpenClaw installer generates `scripts/loops/openclaw-loop-gate.mjs`. A trusted Feishu callback/plugin transport must verify the official signature or encrypted-event envelope, timestamp/nonce and secret before invoking it with `LOOP_GATE_CHANNEL=feishu` and `LOOP_FEISHU_SIGNATURE_VERIFIED=1`; missing verification fails with `feishu_signature_unverified`. The bridge itself performs no delivery. Other channel transports pass normalized, source-bound events. Dashboard and chat commands share actor/source binding, generation fencing, idempotency receipts, confirmation escalation and synchronized card state.\n\nAfter installation, run `loop-engineering-openclaw-doctor` and `loop-engineering-openclaw-smoke`. Doctor syntax-checks and locally self-tests the Gate bridge; smoke remains disposable and uses dry-run notifications. Neither command sends an online test message.\n\n## Conversation Contract\n\nInterpret explicit loop language as follows:\n\n- `走 loop：`: enqueue and immediately execute one runner tick with notification.\n- `走 loop 并立刻执行`: synonym for the default above.\n- `走 loop，只入队`, `只排队`, `暂不执行`, or `不立即执行`: enqueue without starting a tick.\n- `继续当前 loop，补充要求：…`: amend the active task in place. Preserve the task id and worker session, write a versioned amendment, update the task contract/dev plan/acceptance plan, and require the worker to reread the latest amendment before checkpoints and completion.\n- A new explicit `走 loop` request while another task is active is a correction/replacement, not ordinary backlog. Supersede the active task at a safe boundary, retain its evidence and lineage, then start the replacement after the lock is released.\n- Status, progress, evidence, or failure questions are read-only and must not start another tick unless the user explicitly asks to continue/run.\n\nDo not infer a queue or dispatcher from this skill. Use the integration installed in the current workspace. For OpenClaw, inspect the generated queue configuration under `configs/loops/queues/` and use the managed wrapper when present. A default installation uses queue `agent-tasks` and the generic wrapper below; an operator may choose another queue or worker during installation.\n\n```bash\nnode scripts/loops/openclaw-loop.mjs route --message \"\" [source options]\nnode scripts/loops/openclaw-loop.mjs run-once\nloop-engineering queue-status --queue --root . --json\nloop-engineering queue-peek --queue --root . --json\n```\n\nIf the managed wrapper or queue configuration is absent, stop and run the platform installer/doctor workflow above. Product names, personal agent names, and host-specific dispatchers belong in local workspace instructions, never in this distributed skill.\n\nPass the original request faithfully. Preserve source channel, target, account, message id, and reply-to metadata so progress, human gates, and terminal results return to the originating conversation. Missing delivery routing must fail closed.\n\n## Task vs Project Classification\n\nClassify scope before enqueueing.\n\n### Scoped task\n\nA bounded change, diagnosis, review, or deliverable with a clear local acceptance target can use one task contract.\n\n### Project-level objective\n\nTreat a request as project-level when the user asks to build/develop/finish a complete product or system, achieve an overall outcome, or otherwise describes a multi-milestone terminal goal.\n\nFor a project-level objective:\n\n1. Run project intake and create a project spec.\n2. Write an explicit terminal-state/completion contract.\n3. Build a complete backlog covering every requirement and known acceptance dimension.\n4. Link queue tasks to the project backlog and terminal contract.\n5. Continue through implementation, verification, revisions, and the next actionable backlog item within the authorized safety boundary.\n6. Stop only when total project acceptance passes, or a genuine human authorization/product decision/external-state blocker prevents meaningful progress.\n\nNever silently narrow a complete-project request into “first milestone” and call that the Loop complete. A single queue task or milestone may be complete while the project remains active.\n\nRecommended commands:\n\n```bash\nloop-engineering project-intake --root --name --brief \"\" --type auto\nloop-engineering project-plan --root --project \nloop-engineering project-status --root --project \n```\n\nThe project completion contract must contain:\n\n- terminal user-visible outcome;\n- in-scope and explicitly out-of-scope capabilities;\n- complete requirement/backlog mapping;\n- acceptance checks and evidence locations;\n- operational/security/data/deployment requirements when relevant;\n- unresolved decisions and required authority;\n- a rule that milestone completion cannot satisfy project completion;\n- final acceptance status with unmet items and blockers.\n\nIf implementation reveals missing work, amend the project backlog/contract before continuing. Do not redefine the terminal goal downward to fit completed work.\n\n## Completion Semantics\n\nUse precise language:\n\n- `阶段完成` or `任务完成`: one task/milestone passed its own acceptance checks.\n- `项目完成` or `Loop 跑完`: only when the project completion contract is fully accepted and no required work remains.\n- `blocked`: only for a concrete blocker requiring human authority/input or an external state change, with evidence and a specific unblock request.\n- `needs_revision`: acceptance found actionable gaps; create a changed-strategy revision rather than claiming completion.\n- `superseded`: a newer explicit loop request replaced the task; preserve lineage and evidence.\n\nFinal reporting for project work must always state both task/milestone status and total-project status.\n\n## Safety and Authority\n\nLoop invocation authorizes the requested workflow, not unlimited external action.\n\nRequire separate explicit confirmation for:\n\n- external messages, publication, social posting, or outreach;\n- destructive deletion or difficult-to-recover changes;\n- production configuration/deployment changes not already clearly requested;\n- credential creation/change/exposure;\n- paid model/API usage beyond an established budget;\n- memory deletion or migration;\n- device/process instrumentation such as `frida`, `tcpdump`, `adb`, `mitmproxy`, hooks, attach/spawn, decrypt, `su`, `kill`, or `pkill`.\n\nHuman permission prompts and missing authorization are stop conditions, not retryable failures. `INSTALL_FAILED_USER_RESTRICTED`, device unauthorized, permission denied, and equivalent states require a concrete human-action gate.\n\nTimeouts must terminate the spawned process group. After instrumentation timeouts, verify that no child instrumentation/proxy process remains.\n\n## Operating Flow\n\n1. Read existing project docs, loop configs, queue state, and relevant dirty worktree state.\n2. Classify task vs project and define the correct contract before execution.\n3. Use `route-message` or the installed conversation wrapper to preserve source metadata and apply immediate/queue-only/amend/supersede semantics.\n4. Run preflight before mutable work.\n5. Execute one bounded tick or the project’s next actionable backlog item.\n6. Emit ordered progress: planning, preflight, worker start, checkpoints, verification, acceptance, final judgement.\n7. Inspect run artifacts; never infer success only from dispatcher exit code.\n8. If acceptance fails, write a revision request with changed diagnosis/tactic/evidence/verification.\n9. Run `doctor` after configuration or queue changes.\n10. For projects, re-read project status and completion contract, then automatically advance to the next safe actionable item.\n11. Report terminal status with evidence, unmet items, blockers, and next action.\n\nDo not add cron/timers until one manual tick passes.\n\n## Core CLI\n\nPrefer the installed CLI:\n\n```bash\nloop-engineering verify --root \nloop-engineering doctor --root [--json]\nloop-engineering summarize --root --limit 20\nloop-engineering route-message --root --message \"\" --queue --route --confirm-execute [--supersede-active | --amend-active] [source options]\nloop-engineering queue-status --root --queue \nloop-engineering queue-peek --root --queue \nloop-engineering run-queue --root --config configs/loops/queues/.json\nloop-engineering queue-revision-next --root --queue --task-id \nloop-engineering queue-lineage --root --queue --task-id \nloop-engineering queue-lineage-bundle --root --queue --task-id \nloop-engineering queue-human-decision --root --queue --task-id --decision approve|request_changes|reject\nloop-engineering queue-human-input-resolve --root --queue --gate-id --input \"\" [--secret-input|--non-secret-input]\nloop-engineering queue-terminal-notify --root --queue (--notify-command \"\" | --dry-run)\nloop-engineering queue-human-input-notify --root --queue (--notify-command \"\" | --dry-run)\n```\n\nIf the package is available only in the workspace:\n\n```bash\nnode packages/loop-engineering/bin/loop-engineering.mjs \n```\n\nUse `run-queue-drain` only when batch draining is explicitly intended. Conversation routing normally runs one task/tick and uses supersede/amend behavior.\n\n## Revision Discipline\n\nA dispatcher-successful run is not automatically accepted. Inspect `final_judgement.json`, acceptance reviews, checkpoints, and verification evidence.\n\nWhen acceptance needs changes:\n\n- mark `needs_revision`;\n- retain the failed source task;\n- use `queue-revision-next`;\n- require a changed diagnosis, implementation tactic, evidence source, or verification step;\n- inspect lineage before forcing repeated attempts.\n\nDefault revision policy may stop after three rounds, two repeated goal signatures, or repeated unchanged strategy. `--force` requires an explicit human override after lineage review.\n\n## Code Work\n\nFor L2 code-changing tasks, prefer isolated worktrees. The runner prepares reviewable local changes and verification evidence; it does not implicitly commit, push, publish, deploy, merge, or delete branches.\n\nSafe review flow:\n\n```bash\nloop-engineering code-task-status --root --queue \nloop-engineering code-worktree-inspect --root --queue --task-id \nloop-engineering code-worktree-diff --root --queue --task-id \nloop-engineering code-task-autoflow --root --queue --task-id --until closeout\nloop-engineering code-patch-apply-plan --root --patch --json\n```\n\nApplying a patch and cleaning a worktree require their explicit confirmation flags. Preserve unrelated user changes and never treat a dirty worktree as disposable.\n\n## Observability and Artifacts\n\nUse read-only diagnostics before mutation:\n\n```bash\nloop-engineering doctor --root --json\nloop-engineering summarize --root --queue --limit 20\nloop-engineering project-status --root --project \n```\n\nTask artifacts live under:\n\n```text\nruntime/loops//tasks//\nruntime/loops//runs/\nruntime/loops//{inbox,active,done,failed,canceled}/\n```\n\nExpected evidence includes `task_contract.json`, `acceptance_plan.json`, `dev_plan.json`, checkpoints, acceptance reviews, `final_judgement.json`, revision requests, amendments, supersede markers, progress notifications, and lineage bundles.\n\nProject artifacts live under:\n\n```text\nconfigs/loops/projects/.json\nruntime/loops/projects//\n```\n\nSummaries must cite the latest run/task/project evidence, verification performed, unmet checks, and blocker reason. Keep raw noisy logs in runtime artifacts; durable memory receives only distilled decisions, recurring failures, accepted safety rules, and verified completion facts.\n\n## Scheduler Policy\n\nUse scheduler ticks only after manual verification. Adaptive schedules may speed up with successful queued work and back off on empty queues, failures, long runs, or human gates.\n\n`queue-scheduler-tick` is adaptive cadence logic, not a resident daemon. A cron, systemd timer, or equivalent external scheduler must wake it regularly. For project queues that promise automatic continuation, set `scheduler.required=true` and a bounded `scheduler.heartbeatMaxAge`; `doctor` must fail with `scheduler_missing` whenever queued work exists without a fresh scheduler heartbeat.\n\nProgress notification must be scoped and idempotent. Report failures, human gates, status changes, and terminal completion promptly; throttle routine progress and idle updates.\n\n## Final Checklist\n\nBefore saying a loop is finished, verify:\n\n- Was this a scoped task or project-level objective?\n- Is the correct contract present and current?\n- Were all amendments applied?\n- Did verification and acceptance pass?\n- Is `final_judgement.json` acceptable?\n- For a project, are all completion-contract items accepted and the backlog terminal?\n- Are there any unmet requirements, pending revisions, gates, or external-write confirmations?\n- Does the report distinguish milestone status from total-project status?\n- Are evidence paths and next actions included?\n\nIf any project requirement remains, report a phase/task result and continue with the next authorized item; do not claim the project or Loop is complete.\n\nFile v0.15.17:_meta.json\n\n{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.17\",\n \"publishedAt\": 1789333652811\n}\n\nFile v0.15.17:references/npm-package.md\n\n# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.17`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/\n\nArchive v0.15.16: 4 files, 11297 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (2362b), SKILL.md (19972b), _meta.json (147b)\n\nArchive v0.15.15: 4 files, 11214 bytes\n\nFiles: references/npm-package.md (7825b), skill-card.md (2139b), SKILL.md (19972b), _meta.json (147b)\n\nArchive v0.15.14: 4 files, 11184 bytes\n\nFiles: references/npm-package.md (7823b), skill-card.md (2058b), SKILL.md (19972b), _meta.json (147b)\n\nArchive v0.15.13: 4 files, 10593 bytes\n\nFiles: references/npm-package.md (7823b), skill-card.md (2182b), SKILL.md (18502b), _meta.json (147b)\n\nArchive v0.15.12: 4 files, 10144 bytes\n\nFiles: references/npm-package.md (7823b), skill-card.md (2056b), SKILL.md (17459b), _meta.json (147b)","readmeExcerpt":"Skill: taskforce-loop-engineering Owner: ambitioncn Summary: Durable explicit task/project loops with verification, revisions, live progress, and governed completion. Tags: latest:0.15.21 Version history: v0.15.21 | 2026-09-30T17:10:11.202Z | user Opt-in backlog status reconciliation with fail-closed project and task-binding safeguards; deferred internal relay routing. v0.15.20 | 2026-09-29T05:09:59.141Z | user Relea","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"command -v loop-engineering\nloop-engineering --help"},{"language":"bash","snippet":"node --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help"},{"language":"bash","snippet":"npx -p taskforce-loop-engineering loop-engineering --help"},{"language":"bash","snippet":"git clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help"},{"language":"bash","snippet":"loop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks"},{"language":"bash","snippet":"loop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: \"taskforce-loop-engineering\"\ndescription: \"Durable explicit task/project loops with verification, revisions, live progress, and governed completion.\"\n---\n\n# Taskforce Loop Engineering\n\nUse this skill only when the user explicitly invokes Loop Engineering, says `走 loop`, `loop engineering`, `丢进 Ironman loop`, `loop Ironman`, `task-runner`, names a loop queue, or asks to operate an existing loop.\n\nDo not route ordinary chat, research, explanations, or simple direct tasks into a loop unless the user explicitly invokes it.\n\n## Distribution and CLI Installation\n\nA skill installation may provide only this `SKILL.md`; it does **not** prove that the Loop Engineering CLI or an OpenClaw/Hermes integration is installed. Before running loop commands, check the deployment explicitly:\n\n```bash\ncommand -v loop-engineering\nloop-engineering --help\n```\n\nOfficial distribution:\n\n- npm package: `taskforce-loop-engineering`\n- GitHub repository: `https://github.com/ambitioncn/taskforce-loop-engineering`\n- ClawHub skill: `https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering`\n- license: Apache-2.0\n- runtime requirement: Node.js 22 or newer\n\nInstall the CLI globally from npm:\n\n```bash\nnode --version\nnpm install -g taskforce-loop-engineering\nloop-engineering --help\n```\n\nFor a temporary read-only invocation without a global install:\n\n```bash\nnpx -p taskforce-loop-engineering loop-engineering --help\n```\n\nFor source-based development, clone the official repository and install its dependencies:\n\n```bash\ngit clone https://github.com/ambitioncn/taskforce-loop-engineering.git\ncd taskforce-loop-engineering\nnpm install\nnpm run check\nnode bin/loop-engineering.mjs --help\n```\n\nDo not guess a workspace source path. Use `node packages/loop-engineering/bin/loop-engineering.mjs ...` only after confirming that exact path exists in the current workspace.\n\n### OpenClaw Integration\n\nInstalling the npm package exposes the CLI, but it does not automatically route conversations, select a worker agent, or create queue wrappers. First generate a read-only installation plan:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks\n```\n\nReview the installation confirmation summary before proceeding. It must show the target platform, absolute platform CLI path, workspace, queue, scheduler, notification routing, and `writes enabled: no (plan only)`. If any field identifies the wrong platform or destination, stop. Then install with an existing worker-agent id:\n\n```bash\nloop-engineering-openclaw-install \\\n --root /path/to/openclaw/workspace \\\n --queue agent-tasks \\\n --worker-agent main \\\n --confirm-install\n```\n\nThe confirmed install also creates `loop-engineering-dashboard.service` on port `4174` and couples it to `openclaw-gateway.service`. Dashboard listening defaults to local-only `127.0.0.1`. To permit Tailnet clients, pass `--dashboard-listen tailscale`; the installer resolves `tailscale ip -4`, binds only that `100.x` addres"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn72t03qbte90ag4sev5yhkg1185722d\",\n \"slug\": \"taskforce-loop-engineering\",\n \"version\": \"0.15.21\",\n \"publishedAt\": 1790788211202\n}"},{"path":"references/npm-package.md","content":"# npm Package\n\nPackage name: `taskforce-loop-engineering`\nVersion: `0.15.19`\n\nInstall from npm:\n\n```bash\nnpm install -g taskforce-loop-engineering\n```\n\nHermes Agent integration commands:\n\n```bash\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-install --root /path/to/hermes/workspace --queue agent-tasks --confirm-install\nloop-engineering-hermes-doctor --root /path/to/hermes/workspace --queue agent-tasks\nloop-engineering-hermes-smoke --root /path/to/hermes/workspace --queue agent-tasks\n```\n\nInstalled commands:\n\n```bash\nloop-engineering init --root /path/to/workspace\nloop-engineering verify --root /path/to/workspace\nloop-engineering run --root /path/to/workspace --config configs/loops/.json\nloop-engineering status --root /path/to/workspace\nloop-engineering doctor --root /path/to/workspace\nloop-engineering summarize --root /path/to/workspace --limit 20\nloop-engineering project-intake --root /path/to/workspace --name --brief \"Project brief\"\nloop-engineering project-plan --root /path/to/workspace --project \nloop-engineering project-status --root /path/to/workspace --project \nloop-engineering enqueue --root /path/to/workspace --queue --title \"Title\" --task \"Task body\"\nloop-engineering queue-init --root /path/to/workspace --queue \nloop-engineering code-queue-init --root /path/to/workspace --queue \nloop-engineering run-queue --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-status --root /path/to/workspace --queue \nloop-engineering queue-scheduler-tick --root /path/to/workspace --config configs/loops/queues/.json\nloop-engineering queue-peek --root /path/to/workspace --queue \nloop-engineering queue-cancel --root /path/to/workspace --queue --task-id \nloop-engineering queue-requeue --root /path/to/workspace --queue --task-id \nloop-engineering queue-revision-next --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage --root /path/to/workspace --queue --task-id \nloop-engineering queue-lineage-bundle --root /path/to/workspace --queue --task-id \nloop-engineering queue-human-decision --root /path/to/workspace --queue --task-id --decision approve|request_changes|reject\nloop-engineering code-worktree-list --root /path/to/workspace --queue \nloop-engineering code-worktree-inspect --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-diff --root /path/to/workspace --queue --task-id \nloop-engineering code-worktree-export --root /path/to/workspace --queue --task-id \nloop-engineering code-patch-verify --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply-plan --root /path/to/workspace --patch runtime/loops//patches/.patch\nloop-engineering code-patch-apply --root /path/to/wor"},{"path":"skill-card.md","content":"## Description:\n\nDurable explicit task/project loops with verification, revisions, live progress, and governed completion.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ambitioncn](https://clawhub.ai/user/ambitioncn)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and other users explicitly invoking a task or project loop use this skill to coordinate queued work, track progress, verify outcomes, and manage revisions and approval gates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing the CLI or integration can change workspace files, scheduler configuration, and dashboard availability.\n\nMitigation: Trust and pin a reviewed package version; inspect the installation plan and confirm changes only for the intended workspace and host account.\n\nRisk: An active loop may perform work beyond what the user intended.\n\nMitigation: Require explicit loop invocation and separate approval for external communication, destructive actions, sensitive changes, and spending beyond an established budget.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/ambitioncn/skills/taskforce-loop-engineering)\n- [npm Package](artifact/references/npm-package.md)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration instructions]\n\n**Output Format:** [Markdown with inline shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include task status, verification evidence, and next actions.]\n\n## Skill Version(s):\n\n0.15.21 (source: server-resolved release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1499,"uniquenessScore":44,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T22:01:48.220Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:42:09.473Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}