lace-mcp 0.0.2-alpha.2 → 0.0.2-alpha.21

package/README.md

@@ -5,7 +5,7 @@ MCP server for [Lace](https://inlace.co). Connects your coding agent to approved
 ## How it works
 
 1. You review your product in Lace and approve a decision on the [Decision Canvas](https://docs.inlace.co/concepts/decision-canvas)
-2. Your coding agent calls `list_decisions` to see what's been approved
+2. Your coding agent calls `search_decisions` to find what's been approved
 3. It calls `apply_decision` to get screenshots, element targeting, and step-by-step instructions
 4. The agent writes the code change and you review the diff
 
@@ -28,18 +28,19 @@ The Lace desktop app must be open and signed in for the MCP server to work.
 
 | Tool | Description |
 | --- | --- |
-| `list_decisions` | Returns all approved decisions as a summary list |
-| `get_decision` | Full details for a single decision — card, element targeting, bounding box, screenshots |
-| `apply_decision` | Everything needed to implement a decision: screenshots, targeting, and step-by-step instructions |
+| `search_decisions` | Search and filter resolved decisions with pagination. No params returns the top 20 |
+| `apply_decision` | Implementation kit for a decision: screenshots, targeting, instructions. `include` controls detail level (`discussion` requires the canvas owner to enable chat sharing) |
+| `list_canvases` | Browse review canvases with page names and decision counts |
+| `list_projects` | Browse projects with thread and canvas counts |
 
-Use `apply_decision` when implementing. Use `get_decision` for browsing.
+Use `search_decisions` to discover, then `apply_decision` to act. Use `list_canvases` and `list_projects` to find IDs for filtering.
 
 ## Usage
 
 Once installed, ask your coding agent:
 
 ```
-"List Lace decisions"
+"Search Lace decisions"
 ```
 
 Or to implement directly:

package/SKILL.md

@@ -9,13 +9,28 @@ Lace surfaces adoption insights as actionable decisions. When a decision is appr
 
 ## Steps
 
-1. Call the `list_decisions` MCP tool to see all approved decisions.
-2. If there is exactly one decision, proceed with it. If there are multiple, ask the user which one to implement.
-3. Call the `apply_decision` MCP tool with the chosen decision ID.
-4. Follow the implementation instructions returned by `apply_decision` exactly — they include screenshots, element targeting, and constraints.
-5. Implement the minimal code change described. Do not refactor or modify anything outside the target element.
+1. Call the `search_decisions` MCP tool with no params to see recently approved decisions, or pass filters such as `query`, `canvasId`, `projectId`, `appName`, or `elementRole` when the user has given scope.
+2. If the workspace has many canvases or projects, call `list_canvases` or `list_projects` first and use the returned IDs/titles to scope `search_decisions`.
+3. If there is exactly one relevant decision, proceed with it. If there are multiple plausible matches, ask the user which one to implement.
+4. Call `apply_decision` with the chosen decision ID.
+5. Use `include: "instructions"` by default. Use `include: "crop"` for a cropped element image, `include: "discussion"` for review thread chat history (requires the canvas owner to enable chat sharing), or `include: "all"` for instructions, crop, and chat history combined.
+6. Follow the implementation instructions returned by `apply_decision` exactly — they include screenshots, element targeting, and constraints.
+7. Implement the minimal code change described. Do not refactor or modify anything outside the target element.
+
+## Element Grounding Strategies
+
+When `apply_decision` returns metadata, use these fields to locate the target element accurately:
+
+1. **Visible text + role** — primary locator. Match the element's `label` text and `role` (button, link, textfield, etc.) in the DOM or component tree.
+2. **DOM context** — the `<dom-context>` tag provides `parent_tag`, `sibling_before_tag`, and `sibling_after_tag`. Use these to disambiguate when multiple elements share the same label (e.g., two "Save" buttons in different sections).
+3. **Page vocabulary** — the `<page-elements>` list shows nearby elements with `in:parentTag` context. Scan it to understand the target's neighborhood and confirm you're editing the right instance.
+4. **Bbox coordinates** — normalized 0–100 percentages. Use as a spatial hint (top-left vs bottom-right), not a pixel-precise locator. Helpful when text matching is ambiguous.
+5. **Anchor state** — `anchor_state="detached"` means the element moved since the review. Fall back to text + role matching, then sibling context, then ask the user. `anchor_state="reanchored"` means the system re-found it — trust the current metadata.
+6. **Crop image** — `include="crop"` returns both the full page screenshot and a zoomed crop of the target element. Use the full screenshot for spatial context and the crop for visual detail.
+
+**Priority order:** visible text + role → DOM context / siblings → vocabulary neighbors → bbox position → crop image.
 
 ## Troubleshooting
 
-- If `list_decisions` returns an authentication error, tell the user to run `npx lace-mcp install <editor>` to re-authenticate.
-- If no decisions are returned, the user may need to approve a decision in the Lace overlay first.
+- If `search_decisions` returns an authentication error, tell the user to run `npx lace-mcp install <editor>` to re-authenticate.
+- If no decisions are returned, the user may need to approve a decision in the Lace overlay first or provide a narrower canvas/project scope.