@massa-ai/cursor-plugin 1.53.0 → 1.55.0

package/skills/massa-ai/references/maestro.md

@@ -19,22 +19,6 @@ Official source anchors:
 - Cloud limits: https://docs.maestro.dev/maestro-cloud/limits.md
 - Maestro MCP: https://docs.maestro.dev/get-started/maestro-mcp.md
 
-## Load Map
-
-| Need | Load |
-|---|---|
-| Source authority, Q&A checklist handling, unsupported facts, transcript requirements | `references/maestro/fact-ledger.md` |
-| CLI preflight, device/platform readiness, local command flags, sharding, live help capture | `references/maestro/cli-device.md` |
-| YAML commands, flow headers, AI commands, examples | `references/maestro/yaml-commands.md` |
-| Core, relational, trait, state, dimension, platform, regex, and web-only selector behavior | `references/maestro/selectors.md` |
-| Flow discovery, config.yaml discovery patterns, tags, execution order, suite isolation | `references/maestro/workspace-execution.md` |
-| Flow header/config/env/report-output boundaries | `references/maestro/config-env-output.md` |
-| `evalScript`, `runScript`, `output`, `faker`, logging, `maestro.log` | `references/maestro/js-scripting.md` |
-| JUnit/HTML reports, artifact directories, debug output, screenshots, videos, AI reports, recording | `references/maestro/artifacts-reports.md` |
-| Cloud binary eligibility, auth/plan needs, app-binary reuse, Cloud device flags, Cloud limits | `references/maestro/cloud.md` |
-| Maestro MCP install/use, tool metadata, Viewer, Cloud-auth tools | `references/maestro/mcp.md` |
-| Stable suite design, setup/teardown, selectors, fixtures, output contracts, skipped checks | `references/maestro/patterns.md` |
-
 ## Minimum Step Selection
 
 - Flow implementation: load `fact-ledger.md`, `cli-device.md`, then only the focused files for the flow surface being edited: commonly `yaml-commands.md`, `selectors.md`, `workspace-execution.md`, `config-env-output.md`, `js-scripting.md`, and `patterns.md`.

package/skills/massa-ai/workflows/discovery.md

@@ -89,39 +89,6 @@ effects ("if we do X, what does that enable or foreclose?"); bring in
 competitive response; think in timeframes (3 months vs 12 months vs 3
 years).
 
-## Frameworks As Tools
-
-Pull a framework in when it moves the conversation forward — never dump
-frameworks or force the conversation through them as a checklist.
-
-- **How Might We (HMW)**: "How might we [outcome] for [user] without
-  [constraint]?" Aim between too broad ("improve onboarding") and too narrow
-  (a disguised solution); generate 5–10 reframings — each opens a different
-  solution space.
-- **Jobs-to-be-Done (JTBD)**: "When [situation], I want to [motivation] so I
-  can [outcome]." The job is stable while solutions change; emotional and
-  social jobs often outweigh functional ones. Ask "what did they fire to
-  hire this?" — it reveals the real competitive set.
-- **Opportunity Solution Tree**: outcome → opportunities (evidence-backed
-  user needs) → multiple solutions per opportunity → cheapest experiment per
-  solution. One solution per opportunity means exploration stopped too
-  early; the tree is a living artifact.
-- **First Principles Decomposition**: state the assumption, break it into
-  fundamental components, ask of each "law of physics or convention?", then
-  rebuild from only the fundamentals. Use when the team is stuck in
-  incremental thinking.
-- **SCAMPER**: seven lenses on an existing product — Substitute, Combine,
-  Adapt, Modify (10x bigger/smaller/faster), Put to other use, Eliminate
-  ("would anyone notice?"), Reverse (flip the sequence or the default).
-- **OODA Loop** (Observe–Orient–Decide–Act): a decision-tempo framework —
-  gather raw signals wide, make sense of them while challenging your own
-  orientation, choose a proportional reversible bet, act, and cycle. Use
-  when the conversation over-deliberates or keeps circling: orient with what
-  exists, decide, and let the next observation correct course.
-- **Reverse Brainstorming**: invert the problem ("how could we make this
-  worse?"), generate freely — people find flaws more easily than fixes —
-  then reverse each worsening idea into the seed of a solution.
-
 ## Session Rhythm
 
 A good session opens up before it narrows down. Move through five stages;
@@ -134,8 +101,9 @@ name the stage transition when it helps the user follow.
    to nothing.
 2. **Diverge** — Generate many ideas without judgment; build on ideas rather
    than shooting them down; follow tangents; push past the first 3–5 obvious
-   ideas; use the frameworks above to open new angles. Do not evaluate
-   feasibility here — that kills divergent thinking.
+   ideas; pull in whatever brainstorming frameworks fit the conversation to
+   open new angles. Do not evaluate feasibility here — that kills divergent
+   thinking.
 3. **Provoke** — The sparring-partner stage: "What is the strongest argument
    against this?", "Who would hate this and why?", "What are we not
    seeing?", "What if the opposite were true?", "What is the 10x more

package/skills/massa-ai/workflows/skill-architect.md

@@ -47,32 +47,15 @@ what "success" looks like.
 
 ### 1.1 — Understand the Problem
 
-Start by asking about the OUTCOME, not the implementation. Key questions
-(ask conversationally, not as a checklist dump):
-
-- **What workflow do you want to make consistent?** Get a concrete example
-  of what they do today, step by step.
-- **What goes wrong without the skill?** Understand the pain: inconsistency,
-  forgotten steps, wasted time re-explaining, wrong outputs.
-- **Who will use this skill?** Just them? Their team? Public distribution?
-  This affects naming, documentation depth, and description specificity.
-- **What tools are involved?** Built-in Agents capabilities (code execution,
-  file creation, artifacts) or external services via MCP?
+Determine: the workflow to make consistent, what goes wrong without the
+skill, who will use it (affects naming, documentation depth, and description
+specificity), and what tools are involved (built-in Agents capabilities or
+external services via MCP).
 
 ### 1.2 — Define Use Cases
 
-Nail down 2-3 concrete use cases. For each, capture:
-
-```
-Use Case: [Name]
-Trigger: What the user would say or do
-Steps: The sequence of actions
-Tools: Built-in or MCP tools needed
-Result: What success looks like (specific output)
-```
-
-If the user is vague, give them examples to react to. It's easier to refine
-a concrete proposal than to articulate needs from scratch.
+Nail down 2-3 concrete use cases, each capturing name, trigger, steps, tools
+needed, and expected result.
 
 ### 1.3 — Identify the Category
 
@@ -87,11 +70,8 @@ detailed pattern guidance):
 
 ### 1.4 — Establish Success Criteria
 
-Before moving on, agree on how they'll know the skill works:
-
-- **Trigger accuracy:** What should trigger it? What should NOT?
-- **Output quality:** What does a good result look like concretely?
-- **Efficiency:** How many interactions should it take?
+Before moving on, agree on trigger accuracy, output quality, and efficiency
+expectations — how they'll know the skill works.
 
 **Exit criteria for Discovery:**