connectors-template

Step 4 of building a generic Falcon connector. Generates YAML action configurations for all confirmed actions using actionType custom, writes partial files per resource, and updates the main connector YAML with $ref links.

Step 2 of building a generic Falcon connector. Asks which authentication type the provider uses, generates the correct YAML auth block from patterns, and writes it into the connector config file.

Step 1 of building a generic Falcon connector. Checks StackOne's provider index via MCP, detects CLI availability, and either pulls an existing connector base config or scaffolds a new one.

Interactive wizard for building a generic Falcon connector. Guides builders through provider setup, authentication, action discovery (scoped or maximal), YAML config generation, validation, and live testing with cleanup. Auto-triggers when someone asks to build a new connector, add a new provider, or create a Falcon config.

Step 5 of building a generic Falcon connector. Validates the generated YAML config using the StackOne CLI (or a manual checklist if CLI is unavailable), interprets and fixes common errors, then confirms the connector is ready for live testing.

Step 2 of building a unified connector. Checks if the StackOne CLI is available, looks up whether the connector already exists in the StackOne index, and either pulls it down or scaffolds a new one based on auth type.

Step 4 of building a unified connector. Guides the builder through mapping provider API fields to their schema using fieldConfigs. Writes or updates the connector YAML partial files for each resource.

Interactive wizard for building a unified Falcon connector from scratch. Guides external builders through schema selection, connector setup, action scoping, field mapping, validation, and testing. Auto-triggers when someone asks to build a new unified connector, map provider data to a schema, or integrate with a new provider using StackOne's unified API.

Step 6 (final) of building a unified connector. Runs live action tests against the provider API, verifies field mapping output matches the schema, and surfaces failures with actionable fix guidance.

Step 5 of building a unified connector. Runs stackone validate on the connector config, interprets any errors with clear fixes, re-runs until clean, and confirms structural correctness before live testing.

Converts an end-user's existing schema document (CSV, JSON, YAML, plain text, or spreadsheet headers) into the connector builder's schema_fields format. Use when a builder has an internal schema they want to map to. Saves the result to the session file so /map-fields can use it immediately.

Step 3 of building a generic Falcon connector. Lets the builder choose between scoped discovery (use-case driven with MCP vector search) or maximal discovery (finds every available API endpoint using the StackOne discover_actions MCP tool asynchronously). Saves confirmed action scope to session.

Step 6 (final) of building a generic Falcon connector. Tests all actions live, tracks and deletes every test record created, prints a cleanup report, and scrambles credentials when done.

First step of building a unified connector. Guides the builder to choose or define the output schema — StackOne built-in, import from any schema document (CSV/JSON/YAML), or define inline. Saves schema choice to session file.

Step 3 of building a unified connector. Asks the builder which resources and CRUD operations matter for their use case, then saves the confirmed action scope to the session file.

ONLY trigger this skill when the user EXPLICITLY asks for MCP-based testing: **Required triggers (ALL must mention "MCP" explicitly):** - "test connector with mcp" - "test mcp connector" - "test [provider] with mcp" - "use mcp to test [provider]" - "run mcp connector test" - "mcp test for [provider]" **DO NOT trigger for:** - Generic "test the connector" requests (use stackone run / test_actions instead) - "test [provider]" without explicit MCP mention - Regular validation or testing requests - Any testing that doesn't explicitly mention MCP This skill builds a REAL agent with Claude Agent SDK that sends natural language prompts to evaluate if action descriptions are agent-friendly. It's more intensive than regular testing and should only be used when explicitly requested.