[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70GKNC2PVCMRBXQRWAYN6VV":3,"skill-same:01M70GKNC2PVCMRBXQRWAYN6VV":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M70GKNC2PVCMRBXQRWAYN6VV","operator-approval-loop",null,"Operator approval contract with internal filing notices for agent-drafted outbound messages, hashed drafts, epoch-keyed decisions, durable delivery claims and receipts, and a pre-draft baseline gate. Use when an agent drafts messages to external counterparties and a human operator must approve, reject, or steer each send before it leaves.","mdnaimul22\u002Fhuman-skills","mdnaimul22","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F64520358?v=4","01M70FH95MH2H796Q01TYSFZ03","Naimul","01M70FH96798CQR4YHA13F17GA",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Foperator-approval-loop\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"operator","operator approval loop","approval","loop","steer","approve","decisions","use","contract","for","receipts","drafts","delivery","human","claims","outbound","when","filing","send","messages","2026-11-10 10:12:30",false,"---\nname: operator-approval-loop\ndescription: Operator approval contract with internal filing notices for agent-drafted outbound messages, hashed drafts, epoch-keyed decisions, durable delivery claims and receipts, and a pre-draft baseline gate. Use when an agent drafts messages to external counterparties and a human operator must approve, reject, or steer each send before it leaves.\n---\n\n# Operator Approval Loop\n\nAn agent that talks to external counterparties should never send on its own\njudgment and should keep the operator informed internally. This skill defines\nthe contract: every outbound draft is filed as an obligation, an operator\ndecides on the exact text, and a delivery ledger proves what went out.\n\n## When to Use\n\n- An agent drafts replies to customers, suppliers, investors, or partners in\n  a shared channel, email, or chat, and a human must approve before send.\n- You need an audit trail that links each sent message to the exact draft\n  text, the operator who approved it, and the decision time.\n- You have seen a stale approval release a rewritten draft, or two workers\n  deliver the same approved message twice.\n- Drafts keep re-asking counterparties for facts the ledger already holds.\n\n## How It Works\n\n### Objects\n\n| Object | Meaning |\n| --- | --- |\n| Obligation | One thing we owe a counterparty. Status moves `drafted`, then `approved` or `rejected`, then `sent`. Carries `direction`, `counterparty`, `channel`, and an `updated_at` epoch. |\n| Draft | Sidecar row holding the exact draft text, a sha256 of that text, origin coordinates (platform, channel, thread, user), and priority (P0 to P3). One per obligation, replaced on re-file. |\n| Decision | An operator's approve or reject, recorded with the operator id, a nonce, and the draft epoch it was made against. |\n| Approval snapshot | Immutable text, hash, epoch and destination recorded by the already-authorized decision writer. Missing snapshots cannot grant dispatch. |\n| Claim | Durable reservation with a random token and state; at most one active claim per obligation. |\n| Delivery | Ledger row proving one send or notice for one (obligation, decision) pair. |\n\nThe reference schema is in [references\u002Fapproval-ledger.sql](references\u002Fapproval-ledger.sql).\n\n### Filing a draft\n\n1. Clean inputs. Strip control characters, collapse whitespace in single-line\n   fields, and enforce length caps (draft, summary, context, counterparty).\n   Empty or oversized fields are refused, not truncated silently.\n2. Run the baseline gate (below). It may refuse the filing.\n3. Hash the draft text with sha256. The hash prefix goes into the summary so\n   the approval panel shows which text it is approving.\n4. Upsert. If an open drafted obligation already exists for the same\n   (counterparty, channel), replace the draft sidecar and advance the\n   obligation's `updated_at`. That advance is the epoch rotation: any\n   decision keyed to the old epoch can no longer release the new text.\n   Otherwise insert a new obligation with status `drafted`.\n5. Route the filing receipt only to a configured, verified internal ops\n   destination. If the origin is that internal destination, acknowledge there.\n   Never-silent means internal reporting, not an automatic external reply.\n   Keep draft hashes, approval status, operator identity and workflow metadata\n   out of counterparty-visible channels. Unknown or unclassified origins stay\n   quiet; a direct message is not automatically internal.\n\nIf a verified internal destination is unavailable, retain the filing result\nin the internal tool result or operator surface. Never fall back to an external\nor unknown origin. A tool result exposed to outsiders is not an internal surface.\n\nFiling a draft does not authorize an external response. Any policy-permitted\nclarifying question or neutral response is a separate outbound decision, subject\nto the existing mention, channel, draft-only, frozen and never constraints in\ncounterparty-channel-discipline. It must not disclose internal approval metadata.\n\n### Baseline gate\n\nBefore any draft is filed, query the current baseline for the counterparty\n(a temporal ledger, contract store, or CRM):\n\n- Signed or delivered contract on record: refuse the filing with the evidence\n  and a recommendation. Asking a counterparty about specs after signing is the\n  exact failure this gate exists to stop.\n- Operator override: `force_despite_signed_contract` lets the filing through\n  and stamps `[BASELINE_OVERRIDE_SIGNED_CONTRACT]` into the draft context.\n- Gate service unreachable: the filing proceeds and the context is stamped\n  `[BASELINE_CHECK_UNAVAILABLE]`. The panel sees that the guard was off.\n  Failures never silently disable the gate.\n- When facts are available, attach the freshest few to the context as a\n  `[BASELINE FACTS: ...]` digest so the draft lands with current truth.\n\n### Deciding\n\nThe approval panel lists obligations with status `drafted` and direction\n`we_owe_them`. Approve or reject writes a decision row carrying the draft\nepoch (`draft_updated_ts`) and flips the obligation status in the same\ntransaction. A decision whose epoch does not match the current `updated_at`\nis stale and must not release anything.\n\nFor an already-authorized approve decision, the same transaction inserts an\nimmutable `obligation_approval_snapshots` row: decision and obligation IDs,\ncurrent draft epoch, exact text and SHA-256, platform\u002Fchannel\u002Fthread, and kind\n`draft_sent`. The decision writer must establish authorization before writing;\nthe reference never authenticates an operator or manufactures a decision.\nAutomatic approval policy is not enabled or expanded by the reference.\nLegacy decisions without snapshots require explicit reconciliation or a new\napproval; never backfill permission from the current mutable draft.\n\n### Delivering\n\nThe SQLite reference is [references\u002Fapproval_claims.py](references\u002Fapproval_claims.py).\nIt grants dispatch permission but never calls transport. Use an existing local\nreference database initialized from the SQL fixture; the module does not apply\nschema or production migrations. Only a trusted decision writer may populate\napproval records. All writers must enable foreign keys and recursive triggers\nand honor the schema guards; administrative database tampering is outside this model.\n\n1. Discover bound approved drafts. Discovery is not permission. `claim()` opens\n   its own `BEGIN IMMEDIATE` transaction, validates the current approved epoch,\n   exact text, computed SHA-256 and full destination against the snapshot, and\n   inserts a unique claim before returning its token. A conflict stops the worker\n   before transport. Completed receipts cannot be claimed again.\n2. `begin_dispatch()` revalidates the binding and atomically changes `claimed`\n   to `dispatching` using the token. Only its winning caller receives\n   the exact `draft_text` and destination after commit. Never regenerate text, reread a\n   mutable sidecar for transport, or reuse the payload for another attempt.\n   A nested caller transaction is refused; permission cannot depend on a later\n   caller commit. No database transaction remains open across transport.\n3. A confirmed successful result goes to `complete()`, which atomically records\n   the delivery coordinate, marks the claim delivered and flips the obligation\n   to `sent`. Identical completion is a no-op; conflicting coordinates fail.\n   The receipt UNIQUE key deduplicates records, not prior external effects.\n4. Exceptions, timeouts, worker death after begin-dispatch, or failed receipt\n   persistence leave a blocked attempt. `mark_unknown()` records uncertainty.\n   Unknown claims never expire, reopen, auto-retry or allow another decision for\n   that obligation to bypass them. A trusted caller may use `reconcile()` with\n   confirmed successful coordinate and evidence; the module does not verify\n   that evidence. An absent receipt is not proof of non-delivery.\n\nThe guarantee is one automatic dispatch attempt per approved decision, not\nexactly-once external delivery. A crash after begin-dispatch but before transport\ncan leave zero sends and a held claim. Releasing an unknown outcome for a new\nattempt would require fencing the original executor and verifying provider\nsemantics; this reference deliberately provides no such retry operation.\n\n| Claim state | Allowed next states |\n| --- | --- |\n| claimed | dispatching or cancelled before dispatch |\n| dispatching | delivered or unknown |\n| unknown | delivered through trusted reconciliation only |\n| delivered, cancelled | terminal; decision key cannot be reused |\n\nWhile a claim is active, database guards freeze obligation, draft and decision\nwrites, including replacements. Snapshots and claims cannot be erased. Cancel a\nclaimed operation with its token before re-filing; the stale token then grants\nnothing. After dispatch begins, hold new edits or revocation for reconciliation.\nThis serializes changes instead of pretending to recall an in-flight operation.\n\nRejected decisions and legacy rows without draft sidecars\u002Fsnapshots never enter\nthis external draft-send path. Report them on the internal operator surface for\nmanual handling. Internal receipt footers remain internal:\n`approved by \u003Coperator> · receipt \u003Cdecision_id> · draft sha256 \u003Cprefix>`.\nNever alter already-approved external text to append workflow metadata.\n\nFocused local validation uses temporary databases, separate connections and a\nsimulated attempt counter, not a provider or real message:\n`python3 -m unittest discover -s tests\u002Fskills -p 'test_approval_delivery_claims.py'`.\nThe tests require Python 3.11+ with SQLite serialization support; the reference\nuses only the standard library. The existing desk-pattern contract checks remain\na separate compatibility check.\n\n### Time-boxed auto-approval (optional)\n\nA draft may carry `auto_send_after` (epoch seconds). A sweep approves drafts\nwhose deadline passed with no decision, recording operator `auto-ttl`, then\ndelivery proceeds through the normal path. Operator actions always win: a\ndecision flips status before the sweep sees it, and a re-file rotates the\nepoch and moves or clears the deadline. The sweep re-checks status and epoch\ninside the write transaction so a race resolves as a no-op. Drafts without a\ndeadline stay hard-gated forever.\n\n### Signal linkage\n\nA draft can name the inbound obligation it answers (`signal_obligation_id`).\nThis is the only truthful link for latency measurement (inbound signal to\ndrafted response) and lets the SLA scan treat that inbound item as answered.\nReject the filing if the referenced row does not exist.\n\n## Examples\n\n### File a draft\n\n```text\nfile_request(\n  draft=\"Thanks, we can hold the slot until Friday. Which start date works?\",\n  counterparty=\"acme-supplier\",\n  context=\"reply to delivery window question\",\n  origin_platform=\"slack\", origin_channel=\"#acme-shared\",\n  origin_thread=\"1712345678.000100\", priority=\"P1\",\n  signal_obligation_id=412)\n-> {obligation_id: 431, draft_sha256: \"9f2c...\", refiled: false}\n```\n\nThe configured, verified internal ops destination sees:\n`Draft filed for approval (P1, sha 9f2c8a1b). Waiting on operator.`\nThe counterparty-visible origin channel receives no filing notice. If no verified\ninternal destination is available, the receipt stays in the internal tool result\nor operator surface, with no external fallback.\n\n### Re-file after a steer\n\nThe operator asks for a shorter draft. Filing again for the same\n(counterparty, channel) returns `refiled: true`, the sidecar text and hash\nchange, and `updated_at` advances. An approve clicked on the old panel row\ncarries the old epoch and is ignored.\n\n### Gate refusal\n\n```text\nDeskApprovalError: baseline gate refused this draft: the ledger shows a\nsigned contract for 'acme-supplier'. Evidence: master agreement executed\n2026-08-14. Recommendation: do not ask. Re-file with\nforce_despite_signed_contract=true if this is genuinely a new thread.\n```\n\n### Delivery footer in an internal channel\n\n```text\nConfirmed for Friday, start date 2026-09-08.\napproved by operator-a · receipt 118 · draft sha256 9f2c8a1b2d3e4f50\n```\n\n## Invariants to test\n\n- Filing receipts go only to configured, verified internal ops; the origin\n  receives one only when it is that verified internal destination.\n- An unknown origin stays quiet. An unavailable internal destination uses the\n  internal tool result or operator surface, with no external fallback.\n- Same (counterparty, channel) filed twice yields one obligation, two epochs.\n- A decision with a stale epoch never results in a delivery row.\n- Two concurrent claimants yield one dispatch permission; losers never attempt transport.\n- Unknown outcomes and failed receipt persistence never enable an automatic retry.\n- Successful completion records the receipt and sent status in one transaction.\n- An altered epoch, text, hash or destination cannot acquire or begin a claim.\n- Active claims block re-file; only pre-dispatch cancellation can release that hold.\n- Gate unavailable stamps the marker; gate signed refuses without force.\n- Auto-ttl never fires against text the operator has since re-filed.\n","# Operator Approval Loop\n\nAn agent that talks to external counterparties should never send on its own\njudgment and should keep the operator informed internally. This skill defines\nthe contract: every outbound draft is filed as an obligation, an operator\ndecides on the exact text, and a delivery ledger proves what went out.\n\n## When to Use\n\n- An agent drafts replies to customers, suppliers, investors, or partners in\n  a shared channel, email, or chat, and a human must approve before send.\n- You need an audit trail that links each sent message to the exact draft\n  text, the operator who approved it, and the decision time.\n- You have seen a stale approval release a rewritten draft, or two workers\n  deliver the same approved message twice.\n- Drafts keep re-asking counterparties for facts the ledger already holds.\n\n## How It Works\n\n### Objects\n\n| Object | Meaning |\n| --- | --- |\n| Obligation | One thing we owe a counterparty. Status moves `drafted`, then `approved` or `rejected`, then `sent`. Carries `direction`, `counterparty`, `channel`, and an `updated_at` epoch. |\n| Draft | Sidecar row holding the exact draft text, a sha256 of that text, origin coordinates (platform, channel, thread, user), and priority (P0 to P3). One per obligation, replaced on re-file. |\n| Decision | An operator's approve or reject, recorded with the operator id, a nonce, and the draft epoch it was made against. |\n| Approval snapshot | Immutable text, hash, epoch and destination recorded by the already-authorized decision writer. Missing snapshots cannot grant dispatch. |\n| Claim | Durable reservation with a random token and state; at most one active claim per obligation. |\n| Delivery | Ledger row proving one send or notice for one (obligation, decision) pair. |\n\nThe reference schema is in [references\u002Fapproval-ledger.sql](references\u002Fapproval-ledger.sql).\n\n### Filing a draft\n\n1. Clean inputs. Strip control characters, collapse whitespace in single-line\n   fields, and enforce length caps (draft, summary, context, counterparty).\n   Empty or oversized fields are refused, not truncated silently.\n2. Run the baseline gate (below). It may refuse the filing.\n3. Hash the draft text with sha256. The hash prefix goes into the summary so\n   the approval panel shows which text it is approving.\n4. Upsert. If an open drafted obligation already exists for the same\n   (counterparty, channel), replace the draft sidecar and advance the\n   obligation's `updated_at`. That advance is the epoch rotation: any\n   decision keyed to the old epoch can no longer release the new text.\n   Otherwise insert a new obligation with status `drafted`.\n5. Route the filing receipt only to a configured, verified internal ops\n   destination. If the origin is that internal destination, acknowledge there.\n   Never-silent means internal reporting, not an automatic external reply.\n   Keep draft hashes, approval status, operator identity and workflow metadata\n   out of counterparty-visible channels. Unknown or unclassified origins stay\n   quiet; a direct message is not automatically internal.\n\nIf a verified internal destination is unavailable, retain the filing result\nin the internal tool result or operator surface. Never fall back to an external\nor unknown origin. A tool result exposed to outsiders is not an internal surface.\n\nFiling a draft does not authorize an external response. Any policy-permitted\nclarifying question or neutral response is a separate outbound decision, subject\nto the existing mention, channel, draft-only, frozen and never constraints in\ncounterparty-channel-discipline. It must not disclose internal approval metadata.\n\n### Baseline gate\n\nBefore any draft is filed, query the current baseline for the counterparty\n(a temporal ledger, contract store, or CRM):\n\n- Signed or delivered contract on record: refuse the filing with the evidence\n  and a recommendation. Asking a counterparty about specs after signing is the\n  exact failure this gate exists to stop.\n- Operator override: `force_despite_signed_contract` lets the filing through\n  and stamps `[BASELINE_OVERRIDE_SIGNED_CONTRACT]` into the draft context.\n- Gate service unreachable: the filing proceeds and the context is stamped\n  `[BASELINE_CHECK_UNAVAILABLE]`. The panel sees that the guard was off.\n  Failures never silently disable the gate.\n- When facts are available, attach the freshest few to the context as a\n  `[BASELINE FACTS: ...]` digest so the draft lands with current truth.\n\n### Deciding\n\nThe approval panel lists obligations with status `drafted` and direction\n`we_owe_them`. Approve or reject writes a decision row carrying the draft\nepoch (`draft_updated_ts`) and flips the obligation status in the same\ntransaction. A decision whose epoch does not match the current `updated_at`\nis stale and must not release anything.\n\nFor an already-authorized approve decision, the same transaction inserts an\nimmutable `obligation_approval_snapshots` row: decision and obligation IDs,\ncurrent draft epoch, exact text and SHA-256, platform\u002Fchannel\u002Fthread, and kind\n`draft_sent`. The decision writer must establish authorization before writing;\nthe reference never authenticates an operator or manufactures a decision.\nAutomatic approval policy is not enabled or expanded by the reference.\nLegacy decisions without snapshots require explicit reconciliation or a new\napproval; never backfill permission from the current mutable draft.\n\n### Delivering\n\nThe SQLite reference is [references\u002Fapproval_claims.py](references\u002Fapproval_claims.py).\nIt grants dispatch permission but never calls transport. Use an existing local\nreference database initialized from the SQL fixture; the module does not apply\nschema or production migrations. Only a trusted decision writer may populate\napproval records. All writers must enable foreign keys and recursive triggers\nand honor the schema guards; administrative database tampering is outside this model.\n\n1. Discover bound approved drafts. Discovery is not permission. `claim()` opens\n   its own `BEGIN IMMEDIATE` transaction, validates the current approved epoch,\n   exact text, computed SHA-256 and full destination against the snapshot, and\n   inserts a unique claim before returning its token. A conflict stops the worker\n   before transport. Completed receipts cannot be claimed again.\n2. `begin_dispatch()` revalidates the binding and atomically changes `claimed`\n   to `dispatching` using the token. Only its winning caller receives\n   the exact `draft_text` and destination after commit. Never regenerate text, reread a\n   mutable sidecar for transport, or reuse the payload for another attempt.\n   A nested caller transaction is refused; permission cannot depend on a later\n   caller commit. No database transaction remains open across transport.\n3. A confirmed successful result goes to `complete()`, which atomically records\n   the delivery coordinate, marks the claim delivered and flips the obligation\n   to `sent`. Identical completion is a no-op; conflicting coordinates fail.\n   The receipt UNIQUE key deduplicates records, not prior external effects.\n4. Exceptions, timeouts, worker death after begin-dispatch, or failed receipt\n   persistence leave a blocked attempt. `mark_unknown()` records uncertainty.\n   Unknown claims never expire, reopen, auto-retry or allow another decision for\n   that obligation to bypass them. A trusted caller may use `reconcile()` with\n   confirmed successful coordinate and evidence; the module does not verify\n   that evidence. An absent receipt is not proof of non-delivery.\n\nThe guarantee is one automatic dispatch attempt per approved decision, not\nexactly-once external delivery. A crash after begin-dispatch but before transport\ncan leave zero sends and a held claim. Releasing an unknown outcome for a new\nattempt would require fencing the original executor and verifying provider\nsemantics; this reference deliberately provides no such retry operation.\n\n| Claim state | Allowed next states |\n| --- | --- |\n| claimed | dispatching or cancelled before dispatch |\n| dispatching | delivered or unknown |\n| unknown | delivered through trusted reconciliation only |\n| delivered, cancelled | terminal; decision key cannot be reused |\n\nWhile a claim is active, database guards freeze obligation, draft and decision\nwrites, including replacements. Snapshots and claims cannot be erased. Cancel a\nclaimed operation with its token before re-filing; the stale token then grants\nnothing. After dispatch begins, hold new edits or revocation for reconciliation.\nThis serializes changes instead of pretending to recall an in-flight operation.\n\nRejected decisions and legacy rows without draft sidecars\u002Fsnapshots never enter\nthis external draft-send path. Report them on the internal operator surface for\nmanual handling. Internal receipt footers remain internal:\n`approved by \u003Coperator> · receipt \u003Cdecision_id> · draft sha256 \u003Cprefix>`.\nNever alter already-approved external text to append workflow metadata.\n\nFocused local validation uses temporary databases, separate connections and a\nsimulated attempt counter, not a provider or real message:\n`python3 -m unittest discover -s tests\u002Fskills -p 'test_approval_delivery_claims.py'`.\nThe tests require Python 3.11+ with SQLite serialization support; the reference\nuses only the standard library. The existing desk-pattern contract checks remain\na separate compatibility check.\n\n### Time-boxed auto-approval (optional)\n\nA draft may carry `auto_send_after` (epoch seconds). A sweep approves drafts\nwhose deadline passed with no decision, recording operator `auto-ttl`, then\ndelivery proceeds through the normal path. Operator actions always win: a\ndecision flips status before the sweep sees it, and a re-file rotates the\nepoch and moves or clears the deadline. The sweep re-checks status and epoch\ninside the write transaction so a race resolves as a no-op. Drafts without a\ndeadline stay hard-gated forever.\n\n### Signal linkage\n\nA draft can name the inbound obligation it answers (`signal_obligation_id`).\nThis is the only truthful link for latency measurement (inbound signal to\ndrafted response) and lets the SLA scan treat that inbound item as answered.\nReject the filing if the referenced row does not exist.\n\n## Examples\n\n### File a draft\n\n```text\nfile_request(\n  draft=\"Thanks, we can hold the slot until Friday. Which start date works?\",\n  counterparty=\"acme-supplier\",\n  context=\"reply to delivery window question\",\n  origin_platform=\"slack\", origin_channel=\"#acme-shared\",\n  origin_thread=\"1712345678.000100\", priority=\"P1\",\n  signal_obligation_id=412)\n-> {obligation_id: 431, draft_sha256: \"9f2c...\", refiled: false}\n```\n\nThe configured, verified internal ops destination sees:\n`Draft filed for approval (P1, sha 9f2c8a1b). Waiting on operator.`\nThe counterparty-visible origin channel receives no filing notice. If no verified\ninternal destination is available, the receipt stays in the internal tool result\nor operator surface, with no external fallback.\n\n### Re-file after a steer\n\nThe operator asks for a shorter draft. Filing again for the same\n(counterparty, channel) returns `refiled: true`, the sidecar text and hash\nchange, and `updated_at` advances. An approve clicked on the old panel row\ncarries the old epoch and is ignored.\n\n### Gate refusal\n\n```text\nDeskApprovalError: baseline gate refused this draft: the ledger shows a\nsigned contract for 'acme-supplier'. Evidence: master agreement executed\n2026-08-14. Recommendation: do not ask. Re-file with\nforce_despite_signed_contract=true if this is genuinely a new thread.\n```\n\n### Delivery footer in an internal channel\n\n```text\nConfirmed for Friday, start date 2026-09-08.\napproved by operator-a · receipt 118 · draft sha256 9f2c8a1b2d3e4f50\n```\n\n## Invariants to test\n\n- Filing receipts go only to configured, verified internal ops; the origin\n  receives one only when it is that verified internal destination.\n- An unknown origin stays quiet. An unavailable internal destination uses the\n  internal tool result or operator surface, with no external fallback.\n- Same (counterparty, channel) filed twice yields one obligation, two epochs.\n- A decision with a stale epoch never results in a delivery row.\n- Two concurrent claimants yield one dispatch permission; losers never attempt transport.\n- Unknown outcomes and failed receipt persistence never enable an automatic retry.\n- Successful completion records the receipt and sent status in one transaction.\n- An altered epoch, text, hash or destination cannot acquire or begin a claim.\n- Active claims block re-file; only pre-dispatch cancellation can release that hold.\n- Gate unavailable stamps the marker; gate signed refuses without force.\n- Auto-ttl never fires against text the operator has since re-filed.\n",{"name":5,"description":7},"main","74715deacdc69119d739f38916f8ee4f0f979ebf","skills\u002Fstorage\u002Faffaan-m_ECC\u002Foperator-approval-loop",0,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills","https:\u002F\u002Fgithub.com\u002Fmdnaimul22","AI Agents Workflows Automation | Specializing in Python, FastAPI, MCP Agents & Custom ERP.","2026-11-11 21:16:57",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add mdnaimul22\u002Fhuman-skills --skill operator-approval-loop",{"tool":63,"command":64},"bunx","bunx skills add mdnaimul22\u002Fhuman-skills --skill operator-approval-loop",{"tool":66,"command":67},"pnpm","pnpm dlx skills add mdnaimul22\u002Fhuman-skills --skill operator-approval-loop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Foperator-approval-loop\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fapproval_claims.py","SCRIPT","脚本",7629,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Foperator-approval-loop\u002Freferences\u002Fapproval_claims.py",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fapproval-ledger.sql","REFERENCE","参考文档",14330,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Foperator-approval-loop\u002Freferences\u002Fapproval-ledger.sql",[84,92,118,139,157,172],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":91},"01M72JT3YP1SQHD0MANGDXQ4RT","higgsfield-websites","Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1\u002FR2\u002FKV\u002FDO\u002FContainers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references\u002Fwebsite-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references\u002Fapp-flow.md), `game` (realtime multiplayer rooms — references\u002Fgame-flow.md). Routes to the right flow; each carries its own rules and deploy\u002Fpublish gates.\nUse when: \"build me a website\", \"make a landing page\", \"create a web app\", \"build a SaaS dashboard \u002F portfolio\", \"make me a game\", \"deploy this site\", \"publish\". Also owns GAME ART: \"make a spritesheet\", \"tileable texture\", \"animate a 3D character\", game music\u002FSFX — see the game-* references.\nNOT for: single image\u002Fvideo\u002Faudio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fhiggsfield-ai_skills\u002Fhiggsfield-websites\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":110,"publishedAt":44},"01M70JPK8HAXXA85P7Q8NKZZYG","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-skills\u002FSKILL.md",[98,101,106,107],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[111,112,113,114,31,115,116,40,117],"writing","writing skills","editing","deployment","Existing","new","work",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":129,"publishedAt":44},"01M70JP4PHBH1CQVVDWZ94W159","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-plans\u002FSKILL.md",[124,125,126],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":127,"categoryName":128,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000030","开发工程师",[111,130,131,132,40,133,33,31,134,135,136,137,138],"writing plans","plans","you","code","requirements","task","multi","spec","multi-step task",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":44},"01M70JNTYVGXFZT8PASZ844TH8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fverification-before-completion\u002FSKILL.md",[],[146,147,148,149,150,151,31,152,153,154,40,38,117,155,156],"verification","verification before completion","complete","about","output","assertions","prs","evidence","claim","commands","running",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":44},"01M70JNGVSQDESWN0Q5BPJ875V","using-superpowers","Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-superpowers\u002FSKILL.md",[163],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[165,166,167,168,31,40,169,170,171],"using superpowers","superpowers","conversation","how to","how","find","questions",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":44},"01M70JN57CE588NPYPYTWH1DWG","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-git-worktrees\u002FSKILL.md",[],[179,180,181,182,183,184,40,117,185,186,187,188,189,190,191,131,31,192,193],"using git worktrees","Using git","git","worktrees","git worktrees","implementation","git worktree","worktree","native","Tools","isolation","fallback","feature","via","workspace"]