{"id":96438,"plugin_id":"plugins_6af5e009db54819185da35c5a7441bc2","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-14T06:08:51.042Z","digest":"1760c3897aff01e5a2a9a0c5ca84a207c22f99901651750b647820dcbd064f68","against":null,"payload":{"description":"Find and verify existing Alteryx assets and datasets before designing or building a solution. Use when a request depends on knowing what already exists — locating workflows, macros, or data related to a business question, checking whether logic is already implemented, grounding a build in real data, verifying a dataset's schema, or finding example XML for an unsupported tool. Read-only.","included_files":[],"name":"alteryx-asset-discovery","skill_md_contents":"---\nname: alteryx-asset-discovery\ndescription: Find and verify existing Alteryx assets and datasets before designing or building a solution. Use when a request depends on knowing what already exists — locating workflows, macros, or data related to a business question, checking whether logic is already implemented, grounding a build in real data, verifying a dataset's schema, or finding example XML for an unsupported tool. Read-only.\n---\n\n# Alteryx Asset Discovery\n\nAnswer one question: **what existing Alteryx assets or datasets could help solve this problem?**\n\nDiscover and verify candidates, then report the evidence. Never create, modify, or run an asset as part of this process. Deciding whether an asset should be reused, extended, or replaced, proposing a solution topology, and judging what the product supports are all out of scope: they come after discovery, once the evidence is in hand. Finish discovery and report first, then perform these follow-on tasks if required.\n\n## Discovery Scope\n\n- Governed Alteryx One datasets, workflows, and macros returned by asset search.\n- Local Alteryx workflows (`.yxmd`) and macros (`.yxmc`).\n- Local datasets such as CSV, Excel, and YXDB files.\n\nSearch governed assets whenever the relevant MCP tools are available, even for a request that started with a local file.\n\n## Agent Workflow\n\n1. **Frame the need.** Extract the business objective, domain terms, expected inputs and outputs, time range, geography, system names, and other constraints worth searching on. Establish which environments are in play: local files, cloud, or both.\n2. **Search broadly.** Search governed cloud assets, local files, or both, depending on which environments are in play and the scope of the request.\n3. **Inspect candidates.** Establish a workflow's or macro's analytical purpose, inputs, outputs, transformations, and referenced assets, and verify a dataset's column names and types before presenting it as grounded context.\n4. **Use workflows as discovery evidence.** Treat workflow Input and Output tools as pointers to canonical datasets, and referenced macros as reusable-logic candidates. Follow them to assets that did not match the original query.\n5. **Refine and repeat.** Re-search using names, business concepts, owners, tags, and tool usage learned during inspection.\n6. **Return grounded candidates.** Report what was found, why each candidate is relevant, what was verified, and every gap.\n\n## Cloud Discovery\n\nUse the read-only tools below through the `alteryx` MCP server. Client prefixes vary; use the exact tool names the active client exposes rather than inventing names.\n\n| Tool                                            | When to use it                                                 | Required handling                                                     |\n|-------------------------------------------------|----------------------------------------------------------------|-----------------------------------------------------------------------|\n| `assets__search_alteryx_assets(query)`          | Search governed assets with a focused natural-language query.  | Treat results as candidates, not verified facts; extract IDs carefully. Follow the required handling in the tool's own description for the specifics (URN extraction, refinement discipline). |\n| `designer__get_condensed_workflow(workflow_id)` | Inspect a cloud workflow or macro.                             | This is the evidence that verifies a workflow candidate.              |\n| `datasets__preview_dataset(datasetId, limit)`   | Verify a governed dataset's schema and inspect a small sample. | Pass the dataset ID in the current preview contract; respect returned limits and never use repeated previews to bulk-extract. |\n\nTranslate the business question into focused searches rather than broad ones. Search relevance depends on the metadata indexed for each asset, so an asset with thin metadata may only be findable by name or path — try both.\n\n## Local Discovery\n\nLocal assets need no MCP server — use the agent's own file search and read capabilities. Two constraints are specific to discovery:\n\n- **Keep the search scoped.** Search the directories the request puts in scope — those it names, or the working directory — and do not open files unrelated to the stated need even inside one. Widening to the home directory or the whole drive requires explicit user direction.\n- **Minimize what you read.** Establish relevance from filenames, structure, headers, and column types; sample rows only to verify a live candidate's schema, tens of rows at most.\n\n## Effort\n\nScale depth to the request shape:\n\n- **Locate-only** — \"Which workflows relate to customer churn?\" Rank candidates and verify enough to justify each one's relevance. Do not inspect every candidate in depth.\n- **Grounding a build** — \"I need a weekly churn dataset\" Verify the leading candidates properly: schemas for datasets that may be consumed, condensed inspection for workflows that may be reused.\n\nWhen the request shape is ambiguous, treat it as locate-only and either offer to verify further or record the ambiguity as a discovery gap, rather than spending the deeper budget uninvited.\n\nStop searching at whichever comes first: the most recent refinement produced no new material candidates, the evidence is sufficient for the request shape, or five search iterations have completed. Inspect at most five candidates in depth per request — rank first, then inspect in rank order.\n\nThese counts are tunable defaults, not protocol. When a bound stops the work, report which bound was hit and what was left uninspected. Silent truncation reads to the user as \"nothing else exists.\"\n\n## Reporting Rules\n\n- **Surface reuse candidacy.** When an inspected asset appears to already fulfill the stated need in whole or in part, say so explicitly and cite the evidence. Do not decide whether to reuse, extend, or replace it at this stage — but never return a strong candidate without flagging that it may make new work unnecessary. Avoiding duplicated business logic is the primary reason to perform discovery.\n- **Report empty results as searched, not absent.** State which locations, asset types, and terms were searched, and offer the terms or locations most likely to change the outcome.\n- **Keep evidence and inference separate.** Distinguish what was observed in metadata, workflow content, schemas, or samples from what you inferred.\n\nA candidate is **verified** only when the evidence below was actually obtained. Everything else is unverified, however strong the search relevance was. Search metadata alone never verifies a candidate.\n\n| Asset type                | Required before labeling verified                                                                                                       |\n|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------|\n| Local or governed dataset | Column names and, where available, types, plus a bounded sample — or an explicit statement of why preview was unavailable or prohibited |\n| Workflow or macro         | Condensed inspection establishing analytical purpose, inputs, outputs, and referenced assets                                            |\n\n## Result Contract\n\nReport in this structure. Always return a stable identifier — `workflow_id`, `dataset_id`, or absolute path — for every candidate, so follow-up questions can re-fetch a specific asset instead of re-running discovery.\n\n```markdown\n## Verified Candidates\n\n### <Asset name> (<type>)\n- Location / identifier:\n- Relevance:\n- Verified evidence:\n- Evidence source:\n- Already fulfills the need: yes / partially / no — with the evidence for that reading\n- Related assets discovered:\n- Freshness / ownership / certification:\n\n## Unverified Candidates\n\n### <Asset name> (<type>)\n- Location / identifier:\n- Why it may be relevant:\n- What could not be verified, and why:\n\n## Discovery Gaps\n\n- <Access restriction, preview failure, unsearched location, or unresolved capability question>\n- <Bound reached, and what was left uninspected>\n```\n\nInclude a section even when it is empty, and say so. An omitted Discovery Gaps section reads as \"there were none.\"\n\n## Running In A Subagent\n\nDiscovery reads far more than it reports, so a caller may run it in an isolated subagent and keep only the report. Prefer a subagent when grounding a build, where deep verification is high-volume and the output feeds a build loop that needs its own context; prefer inline for locate-only requests, where the report is the answer and the user will ask about individual candidates conversationally.\n\nIsolation is an optimization, never a precondition: behave identically either way, and do not depend on prior conversation history or on asking a clarifying question mid-run.\n\nWhen invoked as a subagent:\n\n- **Expect the framing in the spawn prompt.** The business objective, domain terms, known constraints, authorized local roots, and environment mode should arrive up front.\n- **Return the result contract verbatim.** Return the sections above, not a prose summary of them. Reuse candidacy and discovery gaps are exactly what summarization flattens.\n- **Report unresolved framing as a gap.** State the ambiguity, the interpretation used, and what you would have asked.\n- **Return no row-level samples.** Cross the boundary with schemas, column types, and characterizations of the data — never the sampled rows themselves.\n\nWhen spawning this skill as a subagent, supply that framing and expect that contract back.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}