@drawbridge/drawbridge-agents 0.1.60 → 0.1.61
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.
|
@@ -34,6 +34,17 @@ for, and what makes `vendorSettings()` hand a hook its fields.
|
|
|
34
34
|
**Grep before you invent.** A key, a field, a hook or a collection that already
|
|
35
35
|
has a shape must reuse it. Read the contract and the scaffold first, every time.
|
|
36
36
|
|
|
37
|
+
**A hook writes no prose.** (Darren, 2026-09-18, after 66 sentences came out of
|
|
38
|
+
the manifests.) A success answers `request` and `response` and NO `message` —
|
|
39
|
+
nobody is shown one. A skip or failure keeps ONE short reason, the vendor's own
|
|
40
|
+
error text where there is one. A missing setting, credential or input is not a
|
|
41
|
+
sentence: declare it with `expects({ settings : { audience : yup.string().required() } }, hook)`
|
|
42
|
+
from `../contract.js` and the shell answers "Audience is a required field"; a
|
|
43
|
+
vendor answer without an id is `yup.object({ id : yup.string().required() }).validateSync(...)`,
|
|
44
|
+
a fault that retries. Every health check says exactly `'Health check passed.'`.
|
|
45
|
+
The reconnect card is `disconnected( name )` from the contract. A field `message`
|
|
46
|
+
that restates its label is deleted. yup comes from `../../yup.js`, never `'yup'`.
|
|
47
|
+
|
|
37
48
|
## STOP — the three mistakes that have actually been made
|
|
38
49
|
|
|
39
50
|
Each of these was made by someone who had read this file. They are here as
|
|
@@ -19,8 +19,12 @@ scan it and act.
|
|
|
19
19
|
**The default shape:**
|
|
20
20
|
|
|
21
21
|
- One line on what changed, in plain past tense.
|
|
22
|
+
- What they need before the first step: a permission to grant, a setting to switch on, a
|
|
23
|
+
record that has to exist. One line each, before the checks.
|
|
22
24
|
- A list of what to do and what to expect. One step per line, each one something they can
|
|
23
|
-
actually do or check.
|
|
25
|
+
actually do or check. Every step starts with the click path from where they already are
|
|
26
|
+
(Admin, Connections, then the store; Shopify admin, Apps, then Drawbridge). "Open the app"
|
|
27
|
+
is not a path.
|
|
24
28
|
- Anything that would otherwise look wrong to them, as its own line.
|
|
25
29
|
|
|
26
30
|
Use prose only for something a list would distort, like a one-sentence cause. Never write three
|
|
@@ -65,6 +69,13 @@ Never post a first draft. Read it back against this list:
|
|
|
65
69
|
session: a test you ran, a deploy you confirmed live, a value you read. Anything you merely
|
|
66
70
|
believe gets cut or marked unverified. A wrong comment is worse than a thin one and costs
|
|
67
71
|
them a retest.
|
|
72
|
+
- **Did you do every check yourself, on dev, on the record you name?** "The code writes the
|
|
73
|
+
badge" is not the same as "I opened Admin, Connections and saw the badge on
|
|
74
|
+
drawbridge-qa-jaime". A check you have not performed as the reader will perform it gets
|
|
75
|
+
performed now, or is written as "not tested". Naming their store and promising a state you
|
|
76
|
+
never looked at sends them hunting for something that is not there (2026-09-17, task
|
|
77
|
+
1218569574129209: the badge was promised on a store the daily run had not touched, and the
|
|
78
|
+
"This is a development store" screen was described without saying which app or which page).
|
|
68
79
|
- Any jargon they have not used themselves?
|
|
69
80
|
- Does it open with `<a data-asana-gid="<their gid>"/>` so they are actually notified?
|
|
70
81
|
- Would this need a follow-up comment? Fix that now.
|
|
@@ -1,44 +1,68 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: drawbridge-asana-ship-handoff
|
|
3
|
-
description: Use when a feature has shipped (merged to develop) against an Asana task —
|
|
3
|
+
description: Use when a feature has shipped (merged to develop) against an Asana task — waits for the deploy to finish, walks the flow on dev, then hands the task back to its last commenter with a numbered browser retest and today's due date.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Asana ship handoff
|
|
7
7
|
|
|
8
|
-
Hand
|
|
9
|
-
|
|
8
|
+
Hand shipped work back to whoever last commented on the task, with a retest they can run in a
|
|
9
|
+
browser. Use it right after merging to `develop`.
|
|
10
|
+
|
|
11
|
+
The comment is a QA script, not a changelog. They open a browser, follow the numbered steps, and
|
|
12
|
+
see what you said they would see.
|
|
10
13
|
|
|
11
14
|
## Inputs
|
|
12
15
|
|
|
13
|
-
- The Asana task URL or ID. Ask
|
|
14
|
-
|
|
16
|
+
- The Asana task URL or ID. Ask if it isn't obvious from the branch, PR, or conversation. Do not
|
|
17
|
+
guess.
|
|
15
18
|
- The change you shipped.
|
|
16
19
|
|
|
17
|
-
##
|
|
18
|
-
|
|
19
|
-
1. **
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
20
|
+
## Before you write a word
|
|
21
|
+
|
|
22
|
+
1. **Wait for the deploy.** Every app the change touched has to be live on dev — check the
|
|
23
|
+
deployment is ACTIVE, don't assume the push landed. Sync keeps running the old build for
|
|
24
|
+
about ten minutes after ACTIVE, so wait that out before testing anything that runs a job. A
|
|
25
|
+
comment posted mid-deploy sends them to test the old code.
|
|
26
|
+
2. **Walk it in a browser yourself, on dev**, the way they will: same click path, same record,
|
|
27
|
+
same screens. Only what you saw goes in the comment.
|
|
28
|
+
3. **Gather all of it now.** Every scenario to retest, every prerequisite (a permission to
|
|
29
|
+
grant, a setting to switch on, a record that has to exist), and anything on screen that will
|
|
30
|
+
look wrong without warning. Go back a second time to complete or correct the first comment
|
|
31
|
+
and you have wasted their retest.
|
|
32
|
+
4. **Find who it goes to.** `get_task_stories`, keep the stories whose `resource_subtype` is
|
|
33
|
+
`comment_added`, take the most recent one's `created_by`. Never hardcode a person. With no
|
|
34
|
+
comments, the task creator is the fallback — say so and confirm it.
|
|
35
|
+
|
|
36
|
+
## What the comment says
|
|
37
|
+
|
|
38
|
+
Write it with `drawbridge-asana-comment`. That skill owns the shape, the naming rules, the
|
|
39
|
+
humanizer pass, claim verification and the read-back. Don't restate or work around its rules.
|
|
40
|
+
|
|
41
|
+
On top of those:
|
|
42
|
+
|
|
43
|
+
- **One numbered list**, one action per line, so they can reply "3 is wrong" and you both know
|
|
44
|
+
what they mean. Prerequisites numbered first, then the steps, each with what they should see.
|
|
45
|
+
- **Browser only.** Every step is something they click, type, or look at. Nothing about
|
|
46
|
+
branches, commits, files, functions, deploys, packages, or how it was built.
|
|
47
|
+
- **One line on what changed**, plain past tense, and the cause if they reported a bug.
|
|
48
|
+
- **Name screens and buttons exactly as the interface labels them.** If you didn't see the
|
|
49
|
+
label, don't name it. No invented terms, no paraphrased labels.
|
|
50
|
+
- **Say what won't change**, when something they expect to move stays put.
|
|
51
|
+
- **Say what you didn't test.**
|
|
52
|
+
|
|
53
|
+
## Then apply
|
|
54
|
+
|
|
55
|
+
Once the user has approved the text:
|
|
56
|
+
|
|
57
|
+
1. `update_tasks` with `assignee` set to their gid and `due_on` set to today (`YYYY-MM-DD`). The
|
|
58
|
+
MCP can't set a due *time*, so don't pass `due_at`.
|
|
59
|
+
2. `add_comment` with `html_text`.
|
|
60
|
+
3. Report the task URL, who it went to, and the due date — from the tool result, not from
|
|
61
|
+
intent.
|
|
36
62
|
|
|
37
63
|
## Notes
|
|
38
64
|
|
|
39
|
-
-
|
|
40
|
-
|
|
41
|
-
-
|
|
42
|
-
|
|
43
|
-
- If the Asana MCP isn't connected, stop and say so. Never describe a handoff that did not
|
|
44
|
-
happen.
|
|
65
|
+
- Run `drawbridge-ship-feature` first if the docs and graph updates for this ship aren't done.
|
|
66
|
+
This skill is the last step of that flow.
|
|
67
|
+
- One comment per ship. Don't post again unless they reply.
|
|
68
|
+
- If the Asana MCP isn't connected, stop and say so. Never describe a handoff that didn't happen.
|
package/package.json
CHANGED