From baseloop-gtm
This command should be used when the user wants to design a Baseloop data workflow from a goal description. It analyzes requirements, surveys available tools, and produces a step-by-step workflow architecture without creating anything.
How this command is triggered — by the user, by Claude, or both
Slash command
/baseloop-gtm:plan [workflow goal, e.g. 'Import HubSpot companies, qualify B2B, find founders, sync contacts back']This command is limited to the following tools:
The summary Claude sees in its command listing — used to decide when to auto-load this command
# Design a GTM Workflow ## Goal <workflow_goal>$ARGUMENTS</workflow_goal> If the goal above is empty, ask: "What workflow do you want to build? Describe the data flow you want to achieve." Do not proceed until you have a clear goal. ## Phase 1: Survey the Environment Before designing anything, gather context by calling these MCP tools: 1. **`list_tables`** — See what tables already exist. The user may have existing data to build on. 2. **`get_connected_platforms`** — See which integrations are connected (HubSpot, Slack, LinkedIn, etc.). This determines which actions are available. 3....
<workflow_goal>$ARGUMENTS</workflow_goal>
If the goal above is empty, ask: "What workflow do you want to build? Describe the data flow you want to achieve."
Do not proceed until you have a clear goal.
Before designing anything, gather context by calling these MCP tools:
list_tables — See what tables already exist. The user may have existing data to build on.get_connected_platforms — See which integrations are connected (HubSpot, Slack, LinkedIn, etc.). This determines which actions are available.list_actions — Get the full action catalog. Note which have hasDetailedGuide: true.If relevant tables already exist, also call get_table_schema on each to understand current fields, data types, and what's already been built.
If the user mentions specific actions or integrations, call get_action_schema to read the aiDescription for those actions now — you'll need this context for the design.
Based on the goal and available tools, design the workflow:
What data entities are involved? Companies, contacts, deals? Each gets its own table.
For each table, define the field chain in order:
li_find_people_at_company onlycustom_ai_agent with web search + JSON Schema onlyisNotFoundWhich fields gate on which upstream results? Apply the "filter cheap before expensive" principle:
Any CRM sync MUST follow the lookup-before-create pattern. Verify that:
isNotFoundassociateWithObject: true pointing to the company's HubSpot ID.Output the workflow architecture in this format:
For each table:
Show the table-to-table flow:
[Companies] --send_to_table(send_for_each_item)--> [Contacts] --hubspot_create_object--> HubSpot
Approximate credit cost per row flowing through the full workflow. Note which actions are free vs. paid.
Flag any concerns: missing integrations, data quality requirements, rate limits, non-deterministic steps.
Standard risk items to check:
companyWebsite, the plan must include an AI domain resolution step (custom_ai_agent with web search, ~4 credits per row) before HubSpot company lookup. Flag this cost in the estimate.Define how the workflow will be validated before running on the full dataset:
list_row_ids (with hasNotRun filter) to paginate row IDs, then batch through run_fields with custom_range (100 rows per batch).Do NOT create any tables or fields. This command is plan-only.
Present three options to the user:
/baseloop-gtm:build — Create tables and fields one at a time, verifying each step before proceeding./baseloop-gtm:lfg — Plan, build, and test (Rung 1 + Rung 2) autonomously. Pauses for your approval before running on the full dataset (Rung 3).Ask: "Ready to build? Choose build for step-by-step, lfg for autonomous end-to-end, or tell me what to adjust."
npx claudepluginhub baseloop-hq/baseloop-gtm-plugin --plugin baseloop-gtm/planCreates a step-by-step implementation plan from requirements or a PRD markdown file, then waits for user confirmation before any code changes.
/planBreaks project into small verifiable tasks with acceptance criteria, dependencies, checkpoints. Reads spec/codebase, presents plan for review, saves to tasks/plan.md and tasks/todo.md.
/planStarts Manus-style file-based planning: creates task_plan.md, findings.md, progress.md if missing, invokes planning skill, and guides through workflow.
/planInteractively builds Goal, Scope, Metric, and Verify command for an autoresearch run from provided goal description.
/planRestates requirements, assesses risks, creates step-by-step implementation plan with phases, dependencies, complexity estimates, and waits for user confirmation.
/planCaptures user intent, analyzes requirements, and generates a weighted execution plan saved to .claude/session-plan.md. Does not execute — plans are saved for review or later execution via /octo:embrace.