@apex-inc/mcp-server 0.41.0 → 0.41.1
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/dist/api-client.d.ts +4 -4
- package/dist/api-client.d.ts.map +1 -1
- package/dist/api-client.js +3 -3
- package/dist/api-client.js.map +1 -1
- package/dist/index.js +1 -1
- package/dist/index.js.map +1 -1
- package/dist/prompts.js +1 -1
- package/dist/prompts.js.map +1 -1
- package/dist/repo-binding.d.ts +2 -2
- package/dist/repo-binding.js +4 -4
- package/dist/repo-binding.js.map +1 -1
- package/dist/setup-catchup-tools.js +29 -29
- package/dist/setup-catchup-tools.js.map +1 -1
- package/dist/setup-checklist.js +1 -1
- package/dist/setup-checklist.js.map +1 -1
- package/dist/setup-flow.js +6 -6
- package/dist/setup-flow.js.map +1 -1
- package/dist/tool-shared.js +4 -4
- package/dist/tool-shared.js.map +1 -1
- package/dist/tools/ad-platforms.d.ts +1 -1
- package/dist/tools/ad-platforms.js +23 -23
- package/dist/tools/ad-platforms.js.map +1 -1
- package/dist/tools/adoption.js +2 -2
- package/dist/tools/adoption.js.map +1 -1
- package/dist/tools/context.js +1 -1
- package/dist/tools/context.js.map +1 -1
- package/dist/tools/experiments.js +19 -19
- package/dist/tools/experiments.js.map +1 -1
- package/dist/tools/letters.js +1 -1
- package/dist/tools/letters.js.map +1 -1
- package/dist/tools.d.ts.map +1 -1
- package/package.json +1 -1
- package/skills/apex-adoption/SKILL.md +1 -1
- package/skills/apex-communications/SKILL.md +2 -2
- package/skills/apex-experimentation/SKILL.md +6 -6
- package/skills/apex-growth-intelligence/SKILL.md +6 -6
- package/skills/apex-growth-tracking/SKILL.md +4 -4
- package/skills/apex-integration-cookbook/SKILL.md +9 -9
- package/skills/apex-journeys/SKILL.md +3 -3
- package/skills/apex-partner-network/SKILL.md +1 -1
- package/skills/apex-setup/SKILL.md +12 -12
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: apex-setup
|
|
3
|
-
description: Set up Apex in a repo from the editor. Sign in by browser approval, find or create the
|
|
3
|
+
description: Set up Apex in a repo from the editor. Sign in by browser approval, find or create the workspace this repo belongs to, name it, install and wire events, pick the conversion, work the Set up Apex checklist, stop for browser steps, and end on a first experiment or message. Use when someone says "set up Apex", "install Apex", "connect Apex", or runs /setup-apex.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Set up Apex in this repo
|
|
@@ -11,21 +11,21 @@ Three rules hold the whole way:
|
|
|
11
11
|
|
|
12
12
|
- **No tool marks a step done.** Steps finish when the real thing happens: the name is saved, events arrive, the domain verifies. If a step looks stuck, the thing it waits on has not happened.
|
|
13
13
|
- **The owner's "no" is theirs.** Record a skip or decline only after they say so, in their words.
|
|
14
|
-
- **Every setup reply names the
|
|
14
|
+
- **Every setup reply names the workspace it wrote to** (`workspace`). If it is not this repo's workspace, stop and switch before the next write.
|
|
15
15
|
|
|
16
16
|
The same steps run as the `/setup-apex` prompt.
|
|
17
17
|
|
|
18
18
|
## 1. Sign in
|
|
19
19
|
Call get_setup_state. If Apex is not connected yet, the reply carries an approval link: show it, call wait_for_apex_approval, then carry on. Sign-in is browser approval only. Never ask for, paste, or save an API key to set up. If a reply starts with APEX_WAITING_FOR_ACCESS, say so in one sentence, give the link it names, and stop.
|
|
20
20
|
|
|
21
|
-
## 2. Which
|
|
22
|
-
Read .apex/workspace.json. If it exists, switch_workspace to its workspace_key. If not, look for an Apex snippet or SDK workspace key in the code; that key is the
|
|
21
|
+
## 2. Which workspace is this repo
|
|
22
|
+
Read .apex/workspace.json. If it exists, switch_workspace to its workspace_key. If not, look for an Apex snippet or SDK workspace key in the code; that key is the workspace, and you write the file. If neither, ask the owner once: one of their workspaces (list_orgs shows them by organization), a new workspace in one of their organizations (create_workspace), or a separate company (create_organization). Ask "separate company, or another site of the same business?" before creating either. Write and commit the file. Every setup reply names the workspace it wrote to; if it is not this repo's workspace, stop and switch.
|
|
23
23
|
|
|
24
|
-
## 3. Name the
|
|
25
|
-
If get_setup_state shows first-run incomplete, name the merchant before inventing events. Read the repo (package name, README, site config) and propose the organization name, workspace name, what the
|
|
24
|
+
## 3. Name the workspace from the repo
|
|
25
|
+
If get_setup_state shows first-run incomplete, name the merchant before inventing events. Read the repo (package name, README, site config) and propose the organization name, workspace name, what the organization does, how people convert, and the website. Confirm with the owner, then save with update_organization and update_workspace. Set site_install to codebase when you install from this repo.
|
|
26
26
|
|
|
27
27
|
## 4. Install and wire events
|
|
28
|
-
Install the SDK or snippet the checklist names. Read get_event_spec before writing track calls, scan the code for what the
|
|
28
|
+
Install the SDK or snippet the checklist names. Read get_event_spec before writing track calls, scan the code for what the site actually does, and report it with propose_wiring_plan. Wire those events. Do not invent event names to make a step look done. Then watch them arrive with apex_recent_events and get_wiring_status before moving on.
|
|
29
29
|
|
|
30
30
|
## 5. Pick what counts as a conversion
|
|
31
31
|
Ask the owner which event is the sale, signup, or lead that matters. Save it with create_conversion and set_primary_conversion.
|
|
@@ -37,7 +37,7 @@ Call get_setup_state after every write and work the next step with the tool it n
|
|
|
37
37
|
When the next step needs a person (payment, an ad or app store console, DNS, legal acknowledgements), give the link and the reason from the checklist and wait. Use start_integration_install for GitHub, Stripe, ad platforms, and Google Analytics; it polls until connected. After ads are connected, make a paid Apex Link before inventing UTMs.
|
|
38
38
|
|
|
39
39
|
## 8. First value
|
|
40
|
-
Once events are live, show the owner what arrived with apex_recent_events, and give them the live stream link it returns so they can watch their own site talk to Apex. Then propose exactly one first step from what you learned about the
|
|
40
|
+
Once events are live, show the owner what arrived with apex_recent_events, and give them the live stream link it returns so they can watch their own site talk to Apex. Then propose exactly one first step from what you learned about the organization: one experiment with plan_experiment, or one message with recommend_communications. Say why it fits this workspace in a sentence. Create nothing live without the owner's yes; a draft they can open is fine.
|
|
41
41
|
|
|
42
42
|
## Things that look done and are not
|
|
43
43
|
|
|
@@ -52,17 +52,17 @@ Once events are live, show the owner what arrived with apex_recent_events, and g
|
|
|
52
52
|
|
|
53
53
|
```json
|
|
54
54
|
{
|
|
55
|
-
"workspace_key": "
|
|
56
|
-
"workspace_name": "
|
|
55
|
+
"workspace_key": "atlas-provisions-x1",
|
|
56
|
+
"workspace_name": "Atlas Provisions",
|
|
57
57
|
"org_name": "Acme Co"
|
|
58
58
|
}
|
|
59
59
|
```
|
|
60
60
|
|
|
61
|
-
The workspace key is not a secret; it already ships in the site's snippet. One editor install serves every
|
|
61
|
+
The workspace key is not a secret; it already ships in the site's snippet. One editor install serves every workspace the person can reach, and each repo's file decides which one it is. `create_workspace` and `create_organization` return this file's contents in `repo_binding`.
|
|
62
62
|
|
|
63
63
|
## Example: two companies, one person
|
|
64
64
|
|
|
65
|
-
Noah is signed in with his personal workspace. He opens his company's repo and says "set up Apex in this repo." There is no binding file and no snippet, so the agent asks which
|
|
65
|
+
Noah is signed in with his personal workspace. He opens his company's repo and says "set up Apex in this repo." There is no binding file and no snippet, so the agent asks which workspace. He picks "a separate company". The agent creates the "Acme Co" organization, switches to its workspace, writes `.apex/workspace.json`, and runs setup. Back in his personal repo, that repo's file sends the agent to his personal workspace with no question asked.
|
|
66
66
|
|
|
67
67
|
## Keys are for servers
|
|
68
68
|
|