feedbackbasket-cli 0.9.3 → 0.11.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "feedbackbasket-cli",
-  "version": "0.9.3",
-  "description": "Command-line interface for FeedbackBasket — manage feedback from your terminal",
+  "version": "0.11.0",
+  "description": "Command-line interface for FeedbackBasket — manage feedback and waitlists from your terminal",
   "type": "module",
   "main": "dist/src/cli.js",
   "bin": {
@@ -9,6 +9,7 @@
   },
   "scripts": {
     "build": "tsc",
+    "test": "tsx --test tests/*.test.ts",
     "dev": "tsx bin/feedbackbasket.ts",
     "start": "node dist/bin/feedbackbasket.js",
     "prepublishOnly": "npm run build"
@@ -28,14 +29,13 @@
   },
   "homepage": "https://feedbackbasket.com",
   "dependencies": {
-    "axios": "1.7.0",
     "chalk": "^5.3.0",
     "commander": "^13.1.0",
     "open": "^10.1.0"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",
-    "tsx": "^4.0.0",
+    "tsx": "^4.23.0",
     "typescript": "^5.7.0"
   },
   "engines": {

package/skills/feedbackbasket/SKILL.md

@@ -1,21 +1,11 @@
 ---
-name: FeedbackBasket
-description: Manage FeedbackBasket projects, feedback, bugs, widgets, and team from the command line
-triggers:
-  - feedbackbasket
-  - feedback
-  - bugs
-  - bug reports
-  - user feedback
-  - widget
-  - feedback widget
-invocable: true
-argument-hint: "<command> [options]"
+name: feedbackbasket
+description: Manage FeedbackBasket projects, feedback, bugs, website widgets, mobile app feedback, waitlist capture, and teams from the command line. Use whenever an agent needs to configure FeedbackBasket in a web or mobile app, install its Swift SDK or hosted mobile form, collect feedback or waitlist signups, query feedback, or manage a FeedbackBasket project.
 ---
 
 # FeedbackBasket CLI
 
-Full command-line interface for managing feedback, bug reports, projects, widgets, and team in FeedbackBasket. Works with any AI agent that can run shell commands.
+Full command-line interface for managing feedback, waitlist signups, bug reports, projects, widgets, and teams in FeedbackBasket. Works with any AI agent that can run shell commands.
 
 ## Authentication
 
@@ -63,6 +53,61 @@ All project commands accept **name or ID**. Names are matched case-insensitively
 
 **Project URL rule for agents:** confirm the real website URL before creating or updating a project. Never use `localhost`, `127.0.0.1`, `0.0.0.0`, `::1`, or a local dev server URL unless the user explicitly says the project is only for local testing. If the repo only exposes a local URL, ask for the production, staging, preview, or intended public URL. Do not guess a public domain from package names, git remotes, or environment variables. For an explicitly local-only test project, pass `--allow-local-url`.
 
+**Capture-mode decision:** if the user asks for feedback, a feedback bubble, bug reports, or feature requests, use `--capture-mode feedback`. If they ask for a waitlist, launch list, early access, or email capture, use `--capture-mode waitlist`. If they ask to set up FeedbackBasket without choosing, explain both options and ask which they want. Do not switch an existing project without confirmation because only one capture mode is active at a time.
+
+**Mobile project selection rule:** resolve the FeedbackBasket project for the current app before running mobile commands. Prefer a clearly matching existing project name or product URL. If multiple projects are plausible, ask the user. If none exists, confirm a real product, support, marketing, or App Store URL before creating one; do not invent a URL or use a local development address.
+
+### Mobile App Feedback
+
+```bash
+feedbackbasket mobile status <project> --agent
+feedbackbasket mobile setup <project> --bundle-id com.example.app --agent
+feedbackbasket mobile setup <project> --bundle-id com.example.app --include-publishable-key --agent
+feedbackbasket mobile bundle-ids <project> --add com.example.app.beta --agent
+feedbackbasket mobile bundle-ids <project> --remove com.example.app.beta --agent
+feedbackbasket mobile verify <project> --bundle-id com.example.app --wait 120 --agent
+feedbackbasket mobile disable <project> --yes --agent
+feedbackbasket mobile rotate-key <project> --yes --include-publishable-key --agent
+```
+
+The `fb_mobile_` project key is a publishable, write-only identifier designed to ship in the app. It cannot read feedback or administer the project. It is still masked by default to reduce accidental disclosure in logs and transcripts. Use `--include-publishable-key` only while performing a mobile setup the user authorized, and never repeat the full value in the final response.
+
+Never put an `fb_cli_` CLI token or `fb_key_` MCP/API key in application source, build settings, prompts, logs, or generated configuration. Those are private credentials and are not interchangeable with the publishable mobile key.
+
+For SwiftUI apps targeting iOS 16 or later, use the Swift package returned by `mobile setup` and its native feedback sheet. For UIKit, use the package API or host the SwiftUI sheet. For React Native, Flutter, or unsupported stacks, use the returned hosted form URL in the app's existing in-app browser when available.
+
+Configure the Swift package once at app startup with the returned publishable key:
+
+```swift
+import FeedbackBasket
+
+FeedbackBasket.configure(
+    projectKey: "fb_mobile_returned_by_mobile_setup"
+)
+```
+
+Present its standard SwiftUI sheet from the selected Settings, Help, or Support view:
+
+```swift
+@State private var showingFeedback = false
+
+Button("Send feedback") {
+    showingFeedback = true
+}
+.feedbackBasketSheet(
+    isPresented: $showingFeedback,
+    context: ["screen": "Settings"]
+)
+```
+
+The native SDK stores each submission's reply-thread credential in the app Keychain and shows team replies in the same feedback sheet when it is opened again. Do not build a separate inbox, polling client, or token store in the host app. Hosted-form integrations remain email-only.
+
+Add an accessible Send feedback action to an appropriate existing Settings, Help, or Support screen. Attach only useful non-sensitive context. Do not send passwords, authentication tokens, payment information, private form contents, crash reports, analytics, session recordings, or automatic logs.
+
+Treat a supplied project key as production unless the user explicitly confirms a staging key and base URL. Build and launch the app so the SDK can send its heartbeat, then use `mobile verify`; do not submit test feedback to production. A prior matching heartbeat is a valid connection result because the SDK throttles successful heartbeat attempts.
+
+`mobile setup` is idempotent and adds bundle IDs without replacing existing entries. Do not rotate a key or disable mobile feedback unless the user explicitly requested that disruptive action. Rotation stops every released app using the previous key.
+
 ### Feedback
 ```bash
 # Read
@@ -79,9 +124,10 @@ feedbackbasket feedback note <id> "Investigating — appears related to auth flo
 feedbackbasket feedback delete <id> --yes
 feedbackbasket feedback bulk-update --status CLOSED --ids id1,id2,id3
 
-# Reply to submitter by email, widget thread, or both
+# Reply to submitter by email, widget/in-app thread, or both
 feedbackbasket feedback reply <id> "Thanks for reporting — we pushed a fix!" --delivery email --reply-to support@example.com
 feedbackbasket feedback reply <id> "<content>" --delivery widget
+feedbackbasket feedback reply <id> "<content>" --delivery in-app
 feedbackbasket feedback reply <id> "<content>" --delivery both --reply-to support@example.com
 feedbackbasket feedback replies <id>                                          # list past replies
 
@@ -104,6 +150,8 @@ feedbackbasket widget script <project>
 
 # View settings
 feedbackbasket widget settings <project>
+feedbackbasket widget settings <project> --capture-mode waitlist
+feedbackbasket widget settings <project> --capture-mode feedback
 
 # Customize
 feedbackbasket widget settings <project> --color "#22c55e" --label "Send Feedback"
@@ -111,6 +159,7 @@ feedbackbasket widget settings <project> --position bottom-left --display modal
 feedbackbasket widget settings <project> --email-required --intro "How can we improve?"
 feedbackbasket widget settings <project> --show-email --allow-attachments
 feedbackbasket widget settings <project> --email-read-only --hide-email-when-prefilled
+feedbackbasket widget settings <project> --error-tracking --allow-console-errors
 
 # Guided feedback types and follow-up questions
 feedbackbasket widget flow <project>
@@ -119,6 +168,29 @@ feedbackbasket widget flow <project> --reset-default --enable  # only when the u
 feedbackbasket widget flow <project> --config ./feedback-flow.json
 ```
 
+Waitlist mode keeps the same project script and binds to the host app's own annotated form:
+
+```html
+<form data-feedbackbasket-waitlist>
+  <input name="name" autocomplete="name">
+  <input name="email" type="email" autocomplete="email" required>
+  <button type="submit">Join the waitlist</button>
+</form>
+```
+
+Email is required and name is optional. Use `data-feedbackbasket-state="loading|success|error"` for custom UI, or listen for the bubbling `feedbackbasket:waitlist:success` and `feedbackbasket:waitlist:error` events. Do not add a competing submit handler.
+
+### Waitlist Signups
+
+```bash
+feedbackbasket waitlist list <project>
+feedbackbasket waitlist list <project> --search "@example.com" --limit 50 --offset 0
+feedbackbasket waitlist list <project> --agent
+feedbackbasket waitlist export <project>
+```
+
+Agent output includes signup emails, optional names, captured/referrer pages, total counts, active capture mode, and pagination. Use `waitlist export` for the same CSV export available in the dashboard.
+
 For inline trigger mode, load the widget once and call the public API from the host app's custom button:
 
 ```html
@@ -137,6 +209,8 @@ In React:
 
 Passing the trigger element lets popup mode open beside the custom button. Calling `window.FeedbackWidget.openFeedbackForm()` with no arguments still uses the configured widget position.
 
+Use only the public `openFeedbackForm()` API from the snippet. Do not call internal or undocumented methods such as `open()`, `openModal()`, or direct modal element manipulation; those can exist in the widget bundle but are not stable integration points.
+
 `email-read-only` and `hide-email-when-prefilled` control behavior only when the host app passes a runtime `userEmail` value. Do not store visitor emails in widget settings.
 
 Use the basic widget experience by default: `displayMode` stays `modal`, and guided feedback stays disabled. Ask the user before switching to `popup` or enabling guided feedback. If the user does not care, keep modal + basic feedback.
@@ -168,6 +242,8 @@ feedbackbasket projects create "My App" --url https://myapp.com --agent
 feedbackbasket widget script "My App" --agent
 # Agent gets the embed code, adds it to the HTML
 feedbackbasket widget settings "My App" --color "#22c55e" --label "Feedback" --agent
+# Optional, when the user wants a waitlist instead of feedback capture
+# feedbackbasket widget settings "My App" --capture-mode waitlist --agent
 # Optional, only when requested: enable the guided wizard with Bug, Feature, and General templates
 # feedbackbasket widget flow "My App" --reset-default --enable --agent
 ```
@@ -235,17 +311,18 @@ feedbackbasket feedback show <id> --agent
 ### Close the loop — reply to the submitter
 ```bash
 # Agent reads context, asks which delivery method to use, then sends it
-feedbackbasket feedback show <id> --agent                    # read email, hasWidgetAccess, project.replyToEmail
+feedbackbasket feedback show <id> --agent                    # read email, replyChannel, project.replyToEmail
 feedbackbasket feedback reply <id> "<drafted response>" --delivery widget --agent
+feedbackbasket feedback reply <id> "<drafted response>" --delivery in-app --agent
 feedbackbasket feedback reply <id> "<drafted response>" --delivery email --reply-to support@example.com --agent
 feedbackbasket feedback reply <id> "<drafted response>" --delivery both --reply-to support@example.com --agent
 feedbackbasket feedback update <id> --status COMPLETE --agent
 feedbackbasket feedback note <id> "Replied via CLI" --agent
 ```
 **Important reply safety rules:**
-- Before replying, the agent MUST inspect `feedback show --agent`, then ask the human which delivery method to use: `email`, `widget`, or `both`, unless the human already specified it in the current conversation.
-- If `feedback show` returns `email: null`, do not use `--delivery email` or `--delivery both`. If `hasWidgetAccess: true`, use `--delivery widget`; otherwise ask the human how they want to respond.
-- If `hasWidgetAccess: false`, do not use `--delivery widget` or `--delivery both`.
+- Before replying, the agent MUST inspect `feedback show --agent`, including `replyChannel`, then ask the human which available delivery method to use unless the human already specified it in the current conversation.
+- If `replyChannel: "in_app"`, use `--delivery in-app`. If `replyChannel: "widget"`, use `--delivery widget`. Use `--delivery both` only when an email address and a reply channel are both available.
+- If `feedback show` returns `email: null`, do not use `--delivery email` or `--delivery both`. If `replyChannel: null`, do not use thread delivery.
 - If the delivery includes email and `project.replyToEmail: null`, the agent MUST ask the human which reply-to email to use before sending. Do not use the account owner's email, token owner's email, or any remembered address without explicit confirmation in the current conversation.
 - After the human confirms a reply-to address, pass it explicitly with `--reply-to <email>`, or set a project default first with `feedbackbasket projects update <project> --reply-to <email>`.