@wowok/skills 3.0.3 → 3.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +146 -122
- package/dist/cli.d.ts +6 -0
- package/dist/cli.d.ts.map +1 -1
- package/dist/cli.js +223 -837
- package/dist/cli.js.map +1 -1
- package/dist/index.d.ts +4 -0
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +24 -1
- package/dist/index.js.map +1 -1
- package/dist/installer.d.ts +121 -0
- package/dist/installer.d.ts.map +1 -0
- package/dist/installer.js +802 -0
- package/dist/installer.js.map +1 -0
- package/dist/skills.d.ts +5 -2
- package/dist/skills.d.ts.map +1 -1
- package/dist/skills.js +86 -62
- package/dist/skills.js.map +1 -1
- package/dist/targets.d.ts +94 -0
- package/dist/targets.d.ts.map +1 -0
- package/dist/targets.js +421 -0
- package/dist/targets.js.map +1 -0
- package/dist/types.d.ts +5 -4
- package/dist/types.d.ts.map +1 -1
- package/dist/types.js +0 -32
- package/dist/types.js.map +1 -1
- package/package.json +7 -4
- package/scripts/install.js +21 -858
- package/wowok-arbitrator/SKILL.md +5 -12
- package/wowok-auditor/SKILL.md +5 -17
- package/wowok-collaborator/SKILL.md +5 -17
- package/wowok-governance/SKILL.md +95 -0
- package/wowok-machine/SKILL.md +5 -18
- package/wowok-market/SKILL.md +82 -0
- package/wowok-messenger/SKILL.md +5 -18
- package/wowok-onboard/SKILL.md +5 -22
- package/wowok-order/SKILL.md +5 -18
- package/wowok-output/SKILL.md +5 -10
- package/wowok-planner/SKILL.md +5 -19
- package/wowok-provider/SKILL.md +5 -17
- package/wowok-supplier/SKILL.md +5 -16
- package/examples/Insurance/Insurance.md +0 -1245
- package/examples/MyShop/MyShop.md +0 -2003
- package/examples/MyShop/myshop_machine_nodes.json +0 -93
- package/examples/MyShop_Advanced/MyShop_Advanced.md +0 -2874
- package/examples/ThreeBody_Signature/ThreeBody_Signature.md +0 -1831
- package/examples/Travel/Travel.md +0 -1849
- package/examples/Travel/calc-weather-timestamps.js +0 -12
|
@@ -1,17 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-arbitrator
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
Core value: achieve trust consensus between merchants and users through
|
|
9
|
-
transparent, fair, and efficient dispute resolution.
|
|
10
|
-
when_to_use:
|
|
11
|
-
- User wants to create/configure an Arbitration service
|
|
12
|
-
- User needs to handle dispute cases and voting processes
|
|
13
|
-
- User wants to design voter eligibility and weight mechanisms
|
|
14
|
-
- User mentions "arbitration", "dispute", "voting", "arb", "judge"
|
|
3
|
+
description: "WoWok Arbitrator — build and operate on-chain arbitration services. Create Arbitration objects, configure voting rules (open or guard-based weighted), manage dispute cases through their full lifecycle, and earn fees from resolution. Core value: achieve trust consensus between merchants and users through transparent, fair, and efficient dispute resolution. Use when: User wants to create/configure an Arbitration service; User needs to handle dispute cases and voting processes; User wants to design voter eligibility and weight mechanisms; User mentions \"arbitration\", \"dispute\", \"voting\", \"arb\", \"judge\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: arbitrator
|
|
7
|
+
related: "wowok-order, wowok-messenger"
|
|
15
8
|
---
|
|
16
9
|
|
|
17
10
|
# WoWok Arbitrator Guide
|
package/wowok-auditor/SKILL.md
CHANGED
|
@@ -1,22 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-auditor
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
This Skill is the knowledge base for the L4 Harness Verify Loop. It does
|
|
10
|
-
not mutate objects. It queries, exports, and rules — emitting a
|
|
11
|
-
pass/warn/fail audit report plus a publish decision.
|
|
12
|
-
when_to_use:
|
|
13
|
-
- User is about to publish a Service, Machine, or lock an Allocator set
|
|
14
|
-
- User asks to "audit", "verify", "review", "check before publish"
|
|
15
|
-
- L4 Harness Verify Loop is invoked before an irreversible operation
|
|
16
|
-
- User mentions "fund flow", "refund path", "allocation sum", "guard completeness"
|
|
17
|
-
- User mentions "machine cycle", "unreachable state", "permission index conflict"
|
|
18
|
-
- User wants a pre-publish go/no-go decision
|
|
19
|
-
- A publish operation failed and root-cause analysis is needed
|
|
3
|
+
description: "WoWok pre-publish auditor — the static-analysis Skill that verifies Guard completeness, Machine soundness, fund-flow safety, permission consistency, and publish readiness BEFORE any irreversible publish operation (Service publish, Machine publish, Allocator binding freeze). This Skill is the knowledge base for the L4 Harness Verify Loop. It does not mutate objects. It queries, exports, and rules — emitting a pass/warn/fail audit report plus a publish decision. Use when: User is about to publish a Service, Machine, or lock an Allocator set; User asks to \"audit\", \"verify\", \"review\", \"check before publish\"; L4 Harness Verify Loop is invoked before an irreversible operation; User mentions \"fund flow\", \"refund path\", \"allocation sum\", \"guard completeness\"; User mentions \"machine cycle\", \"unreachable state\", \"permission index conflict\"; User wants a pre-publish go/no-go decision; A publish operation failed and root-cause analysis is needed."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-planner, wowok-provider, wowok-machine"
|
|
20
8
|
---
|
|
21
9
|
|
|
22
10
|
# WoWok Pre-Publish Auditor
|
|
@@ -1,22 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-collaborator
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
Covers permission-index and named-operator routing, guard-gated evidence
|
|
9
|
-
submission, and reputation protection. The collaborator carries PROCESS
|
|
10
|
-
responsibility (no direct settlement stake) — the goal is to keep the workflow
|
|
11
|
-
flowing and avoid stall blame.
|
|
12
|
-
|
|
13
|
-
For the merchant who owns the Service, see wowok-provider. For the supplier who
|
|
14
|
-
presents to Demands, see wowok-supplier.
|
|
15
|
-
when_to_use:
|
|
16
|
-
- User is an operator/employee executing workflow steps (permission index)
|
|
17
|
-
- User is an external named operator advancing a Machine forward
|
|
18
|
-
- User wants to submit guard evidence (proof/repository) for a forward
|
|
19
|
-
- User mentions "collaborator", "operator", "permission index", "named operator", "execute forward"
|
|
3
|
+
description: "WoWok Collaborator — the canonical skill for process collaborators who execute workflow forwards on behalf of a merchant: internal staff (permission entities) and external operators (named operators). Covers permission-index and named-operator routing, guard-gated evidence submission, and reputation protection. The collaborator carries PROCESS responsibility (no direct settlement stake) — the goal is to keep the workflow flowing and avoid stall blame. For the merchant who owns the Service, see wowok-provider. For the supplier who presents to Demands, see wowok-supplier. Use when: User is an operator/employee executing workflow steps (permission index); User is an external named operator advancing a Machine forward; User wants to submit guard evidence (proof/repository) for a forward; User mentions \"collaborator\", \"operator\", \"permission index\", \"named operator\", \"execute forward\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: collaborator
|
|
7
|
+
related: "wowok-provider, wowok-machine, wowok-messenger"
|
|
20
8
|
---
|
|
21
9
|
|
|
22
10
|
# WoWok Collaborator Guide
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: wowok-governance
|
|
3
|
+
description: "WoWok Governance — the canonical skill for on-chain permission, data, and financial governance: the account that OWNS the objects keeps them healthy after setup. Covers Permission lifecycle (indexes, role assignment, entity table, admin transfer), Treasury/Allocation fund stewardship (deposit/withdraw, history audit, unclaimed payments), and Personal data boundaries (public identity, profile records). Governance is a continuous loop — inventory, decide, execute, audit — not a one-time setup. For building services, see wowok-provider. For market operations, see wowok-market. Use when: User wants to manage who can operate their objects (permission indexes, entity table); User wants to deposit/withdraw treasury funds or audit fund history; User has unclaimed payments or wants to check claimable balances; User wants to update their public on-chain profile or personal data; User mentions \"permission\", \"treasury\", \"governance\", \"manage assets\", \"audit funds\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "1.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-provider, wowok-market, wowok-messenger"
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# WoWok Governance Guide
|
|
11
|
+
|
|
12
|
+
> **Role**: Object owner/admin — the account that carries administrative responsibility for Permission, Treasury, and Personal objects
|
|
13
|
+
> **Related Skills**: [wowok-provider](../wowok-provider/SKILL.md) (service build), [wowok-market](../wowok-market/SKILL.md) (market ops), [wowok-messenger](../wowok-messenger/SKILL.md) (contact)
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## MCP Knowledge Layer
|
|
18
|
+
|
|
19
|
+
The following content has been pushed down to the MCP knowledge layer and is applied automatically — this Skill does NOT duplicate it:
|
|
20
|
+
|
|
21
|
+
| Content | Access via (MCP action) | Applied Via |
|
|
22
|
+
|---------|--------------------------|-------------|
|
|
23
|
+
| Permission safety rules (owner/admin/entity hierarchy) | `schema_query` action='get_safety_rules' | `onchain_operations` permission |
|
|
24
|
+
| Treasury/Permission/Personal object schema | `schema_query` action='get_schema' | governance operations |
|
|
25
|
+
| Unclaimed-payment detection | `keeper_operation` (payment_unclaimed scan) | monitor loop |
|
|
26
|
+
| Fund-flow event meanings (TreasuryEvent / AllocationEvent / RewardClaimEvent / RewardFundEvent) | event semantic registry | audit & monitor |
|
|
27
|
+
|
|
28
|
+
This Skill keeps the governance **conversation flow** — what to inventory, what to decide, what to execute, and how to audit.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Governance Is a Loop, Not a Setup
|
|
33
|
+
|
|
34
|
+
Inventory → Decide → Execute → Audit. Governance objects are LIVE: a permission change takes effect on the next call, a withdraw is irreversible, a personal profile record is permanently public. Every change deserves an audit pass after execution.
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Domain 1: Permission Governance
|
|
39
|
+
|
|
40
|
+
A Permission object defines WHO can perform WHICH operations on your business objects (Service / Machine / Treasury …).
|
|
41
|
+
|
|
42
|
+
- **Indexes** (`permission.index_create`): create named role indexes (e.g. operator=1, finance=2) before assigning.
|
|
43
|
+
- **Role assignment** (`permission.role_assign`): bind indexes onto target objects — a mis-assigned role grants unintended operational authority immediately.
|
|
44
|
+
- **Entity table**: add/remove addresses per index. Review-first: list current entities before mutating (`query_objects` on the Permission object).
|
|
45
|
+
- **Audit**: `query_toolkit` query_type='onchain_table_item_permission_perm' checks what a specific address may do; query_type='address_profile' shows an address's permission memberships across all objects.
|
|
46
|
+
|
|
47
|
+
Rules of thumb:
|
|
48
|
+
- One Permission per business object family; reuse named indexes, don't proliferate unnamed ones.
|
|
49
|
+
- Removing an entity is immediate — the next operation by that address fails with "Permission denied" (abort code 5).
|
|
50
|
+
- Admin transfer is a high-trust operation: the new admin controls the whole table.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Domain 2: Financial Governance
|
|
55
|
+
|
|
56
|
+
Fund stewardship across Treasury / Allocation / Reward / Payment.
|
|
57
|
+
|
|
58
|
+
- **Treasury**: deposit joins coins in (a Payment receipt is minted); withdraw splits balance out — irreversible, and when an `external_guard` is set the guard must validate first. `query_toolkit` query_type='onchain_table_item_treasury_history' audits every flow (op 0 Withdraw / 1 Deposit / 2 Receive) with amount + guard + timestamp.
|
|
59
|
+
- **Allocation**: runs distribute pool funds per sharing mode (Amount / Rate ‰ / Surplus). Review allocator guards periodically — a stale guard blocks legitimate distributions.
|
|
60
|
+
- **Unclaimed payments**: recipients hold frozen CoinWrappers until they unwrap. The keeper `payment_unclaimed` scan owns this reminder surface — run `keeper_operation` to list claimable payments and nudge recipients via Messenger. NewPaymentEvent is deliberately NOT push-bridged, to avoid duplicate reminders (P2-4 channel split).
|
|
61
|
+
- **Reward pools**: RewardFundEvent in / RewardClaimEvent out; a dry pool blocks claims — watch balances before announcing campaigns.
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## Domain 3: Data Governance
|
|
66
|
+
|
|
67
|
+
- **Personal profile** (`personal` operations): your public on-chain identity. Everything here is PERMANENTLY PUBLIC — never anchor private data. Review-first: show the current record before every mutation.
|
|
68
|
+
- **Entity info**: description/info updates re-emit NewEntityEvent — counterparties' cached profiles refresh; keep descriptions accurate.
|
|
69
|
+
- **Repository data**: contribution/usage policies are designed at Repository level (see wowok-provider); governance audits consumption through the event stream.
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Monitor Loop
|
|
74
|
+
|
|
75
|
+
Governance goals close the loop through three channels:
|
|
76
|
+
|
|
77
|
+
- **Push**: fund-flow events (TreasuryEvent / AllocationEvent / RewardClaimEvent / RewardFundEvent) become goal-bound suggestions via SuggestionBridge.
|
|
78
|
+
- **Pull**: keeper scans (payment_unclaimed, balance thresholds) repeat reminders until resolved.
|
|
79
|
+
- **Audit**: after every governance write, re-query the object and confirm the post-state matches the intent.
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Core Interaction Principles
|
|
84
|
+
|
|
85
|
+
1. **Review-first**: always show current state + the exact delta before executing.
|
|
86
|
+
2. **User-driven**: surface options, never auto-execute — withdraw and admin transfer are irreversible.
|
|
87
|
+
3. **Disclose irreversibility**: say it explicitly for withdraw, admin transfer, and any personal-data write.
|
|
88
|
+
4. **Audit after**: every governance write ends with a re-query confirmation.
|
|
89
|
+
|
|
90
|
+
## Quick Reference
|
|
91
|
+
|
|
92
|
+
- Permission: indexes → role assignment → entity table; audit via permission_perm + address_profile.
|
|
93
|
+
- Treasury: deposit/withdraw + history audit; external_guard gates withdrawals.
|
|
94
|
+
- Unclaimed payments: keeper scan owns reminders; recipients unwrap CoinWrappers.
|
|
95
|
+
- Personal data: permanently public — review before every write.
|
package/wowok-machine/SKILL.md
CHANGED
|
@@ -1,23 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-machine
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
Covers Machine architecture (Nodes, Pairs, Forwards, Guards, Thresholds),
|
|
10
|
-
lifecycle management (create, configure, publish, pause), node operations
|
|
11
|
-
(add, exchange, rename, granular forward/prior-node manipulation),
|
|
12
|
-
Progress integration, cross-Machine supply chain composition via Guard verification, privacy-preserving
|
|
13
|
-
consensus patterns, and export/import workflows via machineNode2file.
|
|
14
|
-
when_to_use:
|
|
15
|
-
- User wants to create or modify a Machine workflow
|
|
16
|
-
- User asks about workflow steps, state transitions, or progress
|
|
17
|
-
- User needs to design order processing pipelines
|
|
18
|
-
- User mentions "machine", "workflow", "progress", "state machine", "pipeline"
|
|
19
|
-
- User wants to export Machine nodes to a file or import from a file
|
|
20
|
-
- User needs to understand threshold mechanics, forward permissions, or guard bindings
|
|
3
|
+
description: "WoWok Machine Workflow Design — design, build and operate workflow templates (Machines): directed graphs that define how orders progress through stages, who can advance them, and what conditions must be met at each step. Covers Nodes/Pairs/Forwards/Guards/Thresholds, lifecycle (create, configure, publish, pause), node and forward operations, Progress integration, cross-Machine supply chains via Guard verification, and machineNode2file import/export. Use when: User wants to create or modify a Machine workflow; User asks about workflow steps, state transitions, or progress; User needs to design order processing pipelines; User mentions \"machine\", \"workflow\", \"progress\", \"state machine\", \"pipeline\"; User wants to export/import Machine nodes via a file; User needs threshold mechanics, forward permissions, or guard bindings."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: provider
|
|
7
|
+
related: "wowok-provider"
|
|
21
8
|
---
|
|
22
9
|
|
|
23
10
|
# WoWok Machine Workflow Design
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: wowok-market
|
|
3
|
+
description: "WoWok Market — market discovery and operations (the matchmaking layer): how a demand finds candidate services, how a merchant picks a trustworthy arbitrator, how the account's on-chain attention is surfaced, and how the market is measured and governed. Covers match_discover/discover_services/discover_demands, arbitration_score (trust selection), account_events (attention), market_metrics, anti_cheat, market_operations (journey funnel / referral / CRM) and category match rules. Use when: User wants to discover services for an intent (\"find a plumber in Shanghai\"); Merchant wants to find open Demands to present to; Merchant wants to pick or compare arbitrators; User wants their on-chain attention items surfaced; User wants market metrics, anti-cheat signals, journey funnel, referral or CRM; User mentions \"market\", \"match\", \"discover\", \"matchmaking\", \"funnel\", \"referral\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "1.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-provider, wowok-order, wowok-arbitrator"
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# WoWok Market Guide
|
|
11
|
+
|
|
12
|
+
> **Role**: Market discovery & operations (matchmaking + Observe layer)
|
|
13
|
+
> **Related Skills**: [wowok-provider](../wowok-provider/SKILL.md) (merchant), [wowok-order](../wowok-order/SKILL.md) (customer), [wowok-arbitrator](../wowok-arbitrator/SKILL.md) (arbitrator), [wowok-supplier](../wowok-supplier/SKILL.md) (demand presenter)
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## MCP Knowledge Layer
|
|
18
|
+
|
|
19
|
+
The matching/routing/aggregation logic is pushed down to MCP and applied automatically — this Skill does NOT duplicate it. All market actions live under `evaluation_operation`:
|
|
20
|
+
|
|
21
|
+
| Capability | MCP action | Purpose |
|
|
22
|
+
|------------|------------|---------|
|
|
23
|
+
| Service discovery (intent → candidates) | `match_discover` / `discover_services` | enumerate + location gate + 6-dim score |
|
|
24
|
+
| Demand discovery (merchant → open demand) | `discover_demands` | enumerate shared Demands |
|
|
25
|
+
| Arbitrator trust selection | `arbitration_score` | dual-perspective trust/fairness |
|
|
26
|
+
| Account attention | `account_events` | unread messenger / collectible / arbitrable |
|
|
27
|
+
| Market metrics | `market_metrics` | supply / demand / trust counts |
|
|
28
|
+
| Anti-cheat | `anti_cheat` | fake order / fake review / shell merchant |
|
|
29
|
+
| Operational aggregation | `market_operations` | journey funnel / referral / CRM |
|
|
30
|
+
|
|
31
|
+
This Skill keeps the **market conversation flow** — discover → compare → trust → act → measure. The MCP layer handles enumeration, scoring, and chain-derived aggregation.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Core Interaction Principles
|
|
36
|
+
|
|
37
|
+
1. **Review-first**: State (a) what the AI understood, (b) the decision order, and (c) the interaction contract — before the first choice.
|
|
38
|
+
2. **User-driven**: Every step is an explicit user decision; the AI provides a `recommend` but never auto-advances.
|
|
39
|
+
3. **Neutrality**: the AI surfaces trade-offs and scores, never chooses the branch for the user.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Phase 1: Discover (intent → candidates)
|
|
44
|
+
|
|
45
|
+
**Demand side** — `evaluation_operation` action=`match_discover`:
|
|
46
|
+
- Provide `description` + `location` (+ optional `budget`, `required_capabilities`, `category`).
|
|
47
|
+
- Returns location-gated, 6-dimension-scored services + recommendation reasons.
|
|
48
|
+
- `category` (e.g. `life_service` / `retail`) applies hard-constraint filtering + weight re-anchoring (K3 15 §3).
|
|
49
|
+
|
|
50
|
+
**Merchant side** — `evaluation_operation` action=`discover_demands`:
|
|
51
|
+
- Enumerate open Demands (optional `location` filter).
|
|
52
|
+
- A Demand carries rewards (incentive pointers); read the Reward objects by id for amounts.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Phase 2: Compare & Trust
|
|
57
|
+
|
|
58
|
+
- **Compare**: the `match_discover` result already surfaces per-service scores + reasons. Surface the top-N side-by-side; highlight differences, never force a single pick.
|
|
59
|
+
- **Arbitrator trust**: `evaluation_operation` action=`arbitration_score` with the Arbitration `object` (history auto-fetched via `query_arbs`). Returns `trust` + `fairness` + `combined`. Use it when a merchant chooses which Arbitration to bind, or a customer judges a Service's arbitration guarantee.
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## Phase 3: Act
|
|
64
|
+
|
|
65
|
+
- **Attention**: `evaluation_operation` action=`account_events` with the account — surfaces actionable items (unread messages, collectible payments, demand presented). Let the user act on each, never auto-act.
|
|
66
|
+
- **Discovery → order**: hand off to [wowok-order](../wowok-order/SKILL.md) for due diligence + order placement once the user picks a service.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## Phase 4: Measure & Govern
|
|
71
|
+
|
|
72
|
+
- **Metrics**: `evaluation_operation` action=`market_metrics` → active services / open demands / disputes / supply-demand ratio.
|
|
73
|
+
- **Anti-cheat**: `evaluation_operation` action=`anti_cheat` with a Service's orders/reviews/object-stack → returns negative-factor signals (fake order / fake review / shell merchant).
|
|
74
|
+
- **Operations**: `evaluation_operation` action=`market_operations` with `op` = `journey_funnel` / `referral_attribution` / `customer_relationship`.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Design Principles
|
|
79
|
+
|
|
80
|
+
- **Events signal opportunities only**: chain events are emitted only for participatable/profitable opportunities (K3 13 §6.7) — not for create/pause/noise.
|
|
81
|
+
- **Read the object for authority**: event previews (description ≤260 chars, reward addresses) are routing hints; amounts and authoritative state are read from the object by id.
|
|
82
|
+
- **No fabricated matching**: always run the MCP enumeration/scoring; never invent candidates or scores.
|
package/wowok-messenger/SKILL.md
CHANGED
|
@@ -1,23 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-messenger
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
verify message authenticity, manage conversations with anti-spam controls, and
|
|
9
|
-
integrate with arbitration workflows.
|
|
10
|
-
|
|
11
|
-
Used by customers, service providers, and arbitrators for secure off-chain
|
|
12
|
-
communication that creates tamper-proof audit trails.
|
|
13
|
-
when_to_use:
|
|
14
|
-
- User needs to communicate with another party (buyer, seller, arbitrator)
|
|
15
|
-
- User wants to send encrypted messages for negotiation
|
|
16
|
-
- User needs to generate WTS evidence files from conversations
|
|
17
|
-
- User wants to verify message authenticity
|
|
18
|
-
- User needs to manage conversation lists (friends, blacklist, guard)
|
|
19
|
-
- User mentions "messenger", "message", "chat", "communication", "WTS", "evidence"
|
|
20
|
-
always: false
|
|
3
|
+
description: "WoWok Messenger — end-to-end encrypted communication for pre-order negotiation, evidence collection, and dispute resolution. Core features: send/receive encrypted messages, generate WTS evidence files, verify message authenticity, manage conversations with anti-spam controls, and integrate with arbitration workflows. Used by customers, service providers, and arbitrators for secure off-chain communication that creates tamper-proof audit trails. Use when: User needs to communicate with another party (buyer, seller, arbitrator); User wants to send encrypted messages for negotiation; User needs to generate WTS evidence files from conversations; User wants to verify message authenticity; User needs to manage conversation lists (friends, blacklist, guard); User mentions \"messenger\", \"message\", \"chat\", \"communication\", \"WTS\", \"evidence\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-order, wowok-provider, wowok-arbitrator"
|
|
21
8
|
---
|
|
22
9
|
|
|
23
10
|
# WoWok Messenger Guide
|
package/wowok-onboard/SKILL.md
CHANGED
|
@@ -1,27 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-onboard
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
the technical components. Every business decision (industry, network, location,
|
|
9
|
-
payment token, pricing, workflow, fund distribution, arbitration) is framed in
|
|
10
|
-
terms of who-wins-what and why — not which field to fill.
|
|
11
|
-
|
|
12
|
-
Use when a new user says "I want to open a shop", "I want to sell something",
|
|
13
|
-
"how do I start", or has no published Service yet. Produces a complete merchant
|
|
14
|
-
capability stack: Permission + Service (published) + Machine (published) +
|
|
15
|
-
Progress (bound) + Guards + Allocation + Contact + Arbitration, verified by a
|
|
16
|
-
user-driven test order.
|
|
17
|
-
|
|
18
|
-
Not for existing merchants tuning operations — hand off to wowok-provider.
|
|
19
|
-
when_to_use:
|
|
20
|
-
- User is new to WoWok and wants to set up a service
|
|
21
|
-
- User says "open a shop", "create a service", "start selling", "onboard"
|
|
22
|
-
- User has no published Service yet on the current account
|
|
23
|
-
- User completed account creation and asks "what's next"
|
|
24
|
-
- User resumes an interrupted onboarding (read checkpoint state)
|
|
3
|
+
description: "WoWok First-Touch Onboarding — guides a NEW user from a vague first prompt to their first published Service: a Review opening, then AT MOST 8 mandatory business questions (never technical field prompts), then a dependency-aware auto-build (reuse / customize / discover). Every decision (industry, network, location, token, pricing, workflow, fund distribution, arbitration) is framed as who-wins-what and why. Produces Permission + Service + Machine + Progress + Guards + Allocation + Contact + Arbitration, verified by a test order. Not for existing merchants tuning operations — use wowok-provider. Use when: User is new to WoWok and wants to set up a service; User says \"open a shop\", \"create a service\", \"start selling\", \"onboard\"; User has no published Service yet; User asks \"what's next\" after account creation; User resumes an interrupted onboarding."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-provider, wowok-machine"
|
|
25
8
|
---
|
|
26
9
|
|
|
27
10
|
# WoWok First-Touch Onboarding
|
package/wowok-order/SKILL.md
CHANGED
|
@@ -1,23 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-order
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
2. CUSTOMER (in-order fulfillment, post-order): order creation, progress advancement,
|
|
9
|
-
fund management, and arbitration.
|
|
10
|
-
|
|
11
|
-
For suppliers presenting to Demands, see wowok-supplier. For process
|
|
12
|
-
operators executing workflow forwards, see wowok-collaborator.
|
|
13
|
-
when_to_use:
|
|
14
|
-
- User is a potential buyer evaluating a service BEFORE purchasing (prospect)
|
|
15
|
-
- User is a customer/buyer placing or managing orders (customer)
|
|
16
|
-
- User wants to evaluate services, WIP, guards, allocations, arbitration
|
|
17
|
-
- User needs to communicate with sellers via Messenger
|
|
18
|
-
- User asks about order progress, payments, or refunds
|
|
19
|
-
- User wants to file disputes or arbitration claims
|
|
20
|
-
- User mentions "buy", "order", "purchase", "refund", "dispute", "arbitration", "due diligence"
|
|
3
|
+
description: "WoWok Buyer Guide — TWO lifecycles in one skill: 1. PROSPECT (prospect due diligence, pre-purchase): E1-E11 due diligence + consensus building + trust-score synthesis, ending in a buy/no-buy decision. 2. CUSTOMER (in-order fulfillment, post-order): order creation, progress advancement, fund management, and arbitration. For suppliers presenting to Demands, see wowok-supplier. For process operators executing workflow forwards, see wowok-collaborator. Use when: User is a potential buyer evaluating a service BEFORE purchasing (prospect); User is a customer/buyer placing or managing orders (customer); User wants to evaluate services, WIP, guards, allocations, arbitration; User needs to communicate with sellers via Messenger; User asks about order progress, payments, or refunds; User wants to file disputes or arbitration claims; User mentions \"buy\", \"order\", \"purchase\", \"refund\", \"dispute\", \"arbitration\", \"due diligence\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: customer
|
|
7
|
+
related: "wowok-provider, wowok-arbitrator, wowok-messenger"
|
|
21
8
|
---
|
|
22
9
|
|
|
23
10
|
# WoWok Buyer Guide
|
package/wowok-output/SKILL.md
CHANGED
|
@@ -1,15 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-output
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
- AI has received response from any WoWok MCP tool
|
|
9
|
-
- Response contains addresses requiring name resolution
|
|
10
|
-
- Response contains amounts requiring human-readable formatting
|
|
11
|
-
- User queries on-chain data (events, objects, tables)
|
|
12
|
-
always: true
|
|
3
|
+
description: "WoWok output processing and display — post-processes all WoWok tool responses for human-readable presentation. Handles address resolution, name mapping, amount formatting, and data visualization. Use when: AI has received response from any WoWok MCP tool; Response contains addresses requiring name resolution; Response contains amounts requiring human-readable formatting; User queries on-chain data (events, objects, tables)."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
loading: always
|
|
13
8
|
---
|
|
14
9
|
|
|
15
10
|
# Address Display Rules
|
package/wowok-planner/SKILL.md
CHANGED
|
@@ -1,24 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-planner
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
Use when a user says "I want to build...", "plan a service", "help me set up X",
|
|
10
|
-
or when the L4 Harness opens a new planning cycle. Produces an ODG JSON document
|
|
11
|
-
consumed by the Harness execution loop, with checkpoints between phases.
|
|
12
|
-
|
|
13
|
-
Not for direct execution — hand off to wowok-onboard or wowok-provider for
|
|
14
|
-
step-by-step MCP orchestration once the ODG is confirmed.
|
|
15
|
-
when_to_use:
|
|
16
|
-
- User describes a new service intent and needs a build plan
|
|
17
|
-
- L4 Harness opens a Plan Loop cycle (fresh task)
|
|
18
|
-
- User asks "what do I need to create to support X"
|
|
19
|
-
- User wants to reuse existing objects for a new service
|
|
20
|
-
- User asks for a dependency graph or execution phases
|
|
21
|
-
- User resumes an interrupted planning session (read ODG checkpoint)
|
|
3
|
+
description: "WoWok Planning Skill — the planning component of the L4 Harness Plan Loop. Converts natural-language intent into an executable Object Dependency Graph (ODG) plus a phased plan. Deterministic-first: rule tables and scenario templates drive planning; the LLM only clarifies intent. Produces an ODG consumed by the Harness execution loop, with checkpoints between phases. Not for direct execution — hand off to wowok-onboard or wowok-provider once the ODG is confirmed. Use when: User describes a new service intent and needs a build plan; the Harness opens a Plan Loop cycle; User asks \"what do I need to create to support X\"; User wants to reuse existing objects for a new service; User asks for a dependency graph or execution phases; User resumes an interrupted planning session."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: shared
|
|
7
|
+
related: "wowok-onboard, wowok-auditor, wowok-provider"
|
|
22
8
|
---
|
|
23
9
|
|
|
24
10
|
# WoWok Planning Skill
|
package/wowok-provider/SKILL.md
CHANGED
|
@@ -1,22 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-provider
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
trust mechanisms (compensation funds, arbitration), customer attraction
|
|
9
|
-
(discounts, rewards, supply chain promises), and order fulfillment.
|
|
10
|
-
|
|
11
|
-
For customers placing orders, see wowok-order. For arbitrators, see wowok-arbitrator.
|
|
12
|
-
when_to_use:
|
|
13
|
-
- User is a service provider/merchant/seller on WoWok
|
|
14
|
-
- User wants to create a commercial service/marketplace
|
|
15
|
-
- User wants to design workflow (Machine) for order processing
|
|
16
|
-
- User wants to set up fund distribution strategies (Allocators)
|
|
17
|
-
- User wants to configure trust mechanisms (compensation, arbitration)
|
|
18
|
-
- User wants to handle order fulfillment and customer service
|
|
19
|
-
- User mentions "create service", "merchant", "seller", "provider", "workflow design", "compensation", "arbitration"
|
|
3
|
+
description: "WoWok Service Provider — the canonical skill for service providers (merchants, sellers) to build, operate, and manage commercial services on WoWok. Covers service design (WIP products, Machine workflows, Allocator strategies), trust mechanisms (compensation funds, arbitration), customer attraction (discounts, rewards, supply chain promises), and order fulfillment. For customers placing orders, see wowok-order. For arbitrators, see wowok-arbitrator. Use when: User is a service provider/merchant/seller on WoWok; User wants to create a commercial service/marketplace; User wants to design workflow (Machine) for order processing; User wants to set up fund distribution strategies (Allocators); User wants to configure trust mechanisms (compensation, arbitration); User wants to handle order fulfillment and customer service; User mentions \"create service\", \"merchant\", \"seller\", \"provider\", \"workflow design\", \"compensation\", \"arbitration\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: provider
|
|
7
|
+
related: "wowok-machine, wowok-messenger"
|
|
20
8
|
---
|
|
21
9
|
|
|
22
10
|
# WoWok Service Provider Guide
|
package/wowok-supplier/SKILL.md
CHANGED
|
@@ -1,21 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wowok-supplier
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
sub-order fulfillment via Progress, and settlement collection. The supplier
|
|
9
|
-
is a PEER role with a two-sided position: deliver (to get paid) + collect
|
|
10
|
-
(from the upstream merchant).
|
|
11
|
-
|
|
12
|
-
For the merchant who owns the main Service, see wowok-provider. For the
|
|
13
|
-
process operators executing the workflow, see wowok-collaborator.
|
|
14
|
-
when_to_use:
|
|
15
|
-
- User wants to present their service to a Demand (open RFP or gated call)
|
|
16
|
-
- User is a sub-order provider / supplier fulfilling part of a transaction
|
|
17
|
-
- User wants to collect settlement from an upstream merchant
|
|
18
|
-
- User mentions "supplier", "sub-order", "demand", "present service", "RFP", "fulfill sub-order"
|
|
3
|
+
description: "WoWok Supplier — the canonical skill for suppliers (sub-order providers) who present their service to a Demand and fulfill the resulting sub-order. Covers demand discovery, service presentation (open or passport-gated), sub-order fulfillment via Progress, and settlement collection. The supplier is a PEER role with a two-sided position: deliver (to get paid) + collect (from the upstream merchant). For the merchant who owns the main Service, see wowok-provider. For the process operators executing the workflow, see wowok-collaborator. Use when: User wants to present their service to a Demand (open RFP or gated call); User is a sub-order provider / supplier fulfilling part of a transaction; User wants to collect settlement from an upstream merchant; User mentions \"supplier\", \"sub-order\", \"demand\", \"present service\", \"RFP\", \"fulfill sub-order\"."
|
|
4
|
+
metadata:
|
|
5
|
+
version: "2.0.0"
|
|
6
|
+
role: supplier
|
|
7
|
+
related: "wowok-provider, wowok-machine, wowok-messenger"
|
|
19
8
|
---
|
|
20
9
|
|
|
21
10
|
# WoWok Supplier Guide
|