@rayburst/cc 1.0.31 → 1.0.32

package/commands/rb/discover.md

@@ -202,10 +202,10 @@ Initialize:
 
 3. From the accessibility tree, record:
    - **Page name** — derive from `<title>` tag or the main heading visible (e.g. "Board View", "Settings > Integrations", "Card Detail")
-   - **Behaviors** — list of interactive elements (buttons, forms, modals, sidebars) and their apparent purpose, expressed as user-facing actions:
-     - "User can create a new card using the + button"
-     - "User can filter cards by label"
-     - "User can drag cards between columns"
+   - **Behaviors** — list of interactive elements (buttons, forms, modals, sidebars) and their apparent purpose, expressed as Gherkin scenarios:
+     - "Given the user is on the board page\nWhen the user clicks the + button\nThen a new card creation form appears"
+     - "Given cards exist on the board\nWhen the user selects a label filter\nThen only cards with that label are visible"
+     - "Given a card is in one column\nWhen the user drags the card to another column\nThen the card moves to the target column"
    - **Links** — all `<a href>` values and navigation elements pointing to internal pages
 
 4. For any clearly interactive element that opens a modal or panel (e.g. "+ New Card", "Settings", "Detail view"):
@@ -256,17 +256,25 @@ For each `new_candidate`, create a feature:
 })
 ```
 
-Immediately after `create_feature`, add 4–8 acceptance criteria in batches of 4–5. Each criterion must describe a **testable, user-facing behavior**:
+Immediately after `create_feature`, add 4–8 acceptance criteria in batches of 4–5. Each criterion must be written in **Gherkin syntax** (Given/When/Then) to describe a testable, user-facing behavior:
 
 ```
 <MCP_PREFIX>add_criterion({
   featureId: "<new feature ID>",
-  description: "<testable behavior — e.g. 'User can remove a dependency by clicking the × icon'>",
+  description: "<Gherkin scenario — e.g. 'Given a card exists in a column\\nWhen the user clicks the × icon on a dependency\\nThen the dependency is removed from the card'>",
   status: "pass",
   tagIds: ["<tag IDs from Step 2 cache or newly created tags>"]
 })
 ```
 
+**Gherkin format rules:**
+- Always use `Given / When / Then` structure, with optional `And` for additional steps
+- `Given` — the precondition or starting state (e.g. "Given the user is on the board page")
+- `When` — the user action or system event (e.g. "When the user clicks + New Card")
+- `Then` — the observable outcome (e.g. "Then a new card appears in the first column")
+- Keep each scenario focused on one behavior — one Given/When/Then block per criterion
+- Use `\n` to separate Given/When/Then lines within the description string
+
 **After creating a feature's criteria**, search for related already-tracked features (both from the existing atlas loaded in Step 2 and from features created earlier in this same discovery run) and link them:
 
 ```
@@ -326,7 +334,7 @@ For each `existing_feature` with observed behaviors not yet tracked as criteria:
 ```
 <MCP_PREFIX>add_criterion({
   featureId: "<existing feature ID>",
-  description: "<newly observed behavior not yet in criteria>",
+  description: "<Gherkin scenario — Given [precondition]\\nWhen [action]\\nThen [outcome]>",
   status: "pass",
   tagIds: ["<relevant tag IDs>"]
 })
@@ -399,6 +407,6 @@ New tags:
 5. **Batch MCP calls** in groups of 4–5 to stay within the 60 req/min rate limit.
 6. **Do not create tags for every page** — reuse existing tags aggressively; create new ones only for genuinely new UI contexts.
 7. **Feature titles = Noun Phrases** (e.g. "Card Label Management", "GitHub OAuth Integration", "Swimlane Board View") — not verb phrases or sentences.
-8. **Criteria = user-facing behaviors** — write in the form "User can…" or "System displays…". Avoid implementation details.
+8. **Criteria = Gherkin scenarios** — write in `Given / When / Then` format. Each criterion must have exactly one Given (precondition), one When (action), and one Then (observable outcome). Use `And` for additional steps. Avoid implementation details — focus on observable user-facing behavior.
 9. **Login only once** — after Step 4, reuse the authenticated browser session for all navigation in Step 5.
 10. **Depth limit = 30 pages** — prioritize pages reachable from the main navigation over deeply nested sub-pages.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rayburst/cc",
-  "version": "1.0.31",
+  "version": "1.0.32",
   "description": "Rayburst slash commands for Claude Code — /rb:init, /rb:plan, /rb:sync, /rb:status, /rb:validate-feature, /rb:validate-card, /rb:implement, /rb:discover",
   "bin": {
     "rayburst-cc": "bin/install.js"