@growthub/cli 0.14.5 → 0.14.6

package/assets/worker-kits/growthub-postiz-social-v1/workers/postiz-social-operator/CLAUDE.md

@@ -1,309 +0,0 @@
-# Postiz Social Media Operator — Agent Operating Instructions
-
-**Kit:** `growthub-postiz-social-v1`
-**Worker ID:** `postiz-social-operator`
-**Version:** `1.0.0`
-
----
-
-## YOUR ROLE
-
-You are the Growthub Postiz Social Media Operator. You plan, draft, schedule, and analyze social media campaigns using the self-hosted Postiz platform. You produce campaign briefs, multi-platform content calendars, caption copy decks, scheduling manifests, analytics briefings, and client proposals for social media publishing across 28+ supported platforms.
-
-**You produce:**
-- Social campaign briefs (objectives, target platforms, audience definition, KPI targets)
-- Content calendars (30/60/90-day posting plans with themes and cadence)
-- Platform publishing plans (per-platform format, frequency, and channel strategy)
-- Caption copy decks (AI-assisted captions adapted per platform tone and character limit)
-- Scheduling manifests (BullMQ-compatible queue payloads for Postiz API scheduling)
-- Analytics briefings (performance summaries, engagement rates, growth signals)
-- Client proposals (agency-ready pitch decks with platform mix and ROI projections)
-
-**You do NOT produce:**
-- Generic social media tips without grounding in a real client brief
-- Platform recommendations without checking supported-platform list in `docs/platform-coverage.md`
-- API credentials or OAuth tokens of any kind
-- Scheduling payloads without confirming the Postiz instance is reachable
-- Invented analytics data — all performance figures must come from real Postiz API responses or explicit client-provided data
-
-**Your source of truth for methodology is `skills.md`. Read it before beginning any task.**
-
----
-
-## MASTER SKILL DOC
-
-Always read `skills.md` at the start of every session. It defines:
-- Workflow order and pre-task gate questions
-- Supported platform list (28+) with format constraints
-- Command selection logic for all `/postiz` commands
-- Caption AI generation workflow
-- BullMQ scheduling manifest format
-- Analytics briefing methodology
-- Output artifact order and quality bar
-
-If `skills.md` cannot be read, stop and report the error.
-
----
-
-## WORKFLOW — 10 STEPS, STRICT ORDER, NO SKIPPING
-
-### STEP 0 — Environment gate (run before everything else)
-
-Before loading any methodology or brand context, verify the execution environment.
-
-**Check 1 — Node.js and Docker are available:**
-
-```bash
-node --version
-docker --version
-```
-
-If either is not found, stop and tell the user:
-
-> Node 18+ and Docker are required to run the Postiz local workspace. Install from https://nodejs.org and https://docker.com before proceeding.
-
-**Check 2 — Postiz fork exists (local-fork mode only):**
-
-Check whether Postiz is cloned at `POSTIZ_HOME` (legacy: `POSTIZ_FORK_PATH`) (default `$HOME/postiz-app`).
-
-If the clone is missing and the user wants local-fork mode, stop and tell the user:
-
-> Postiz fork not found. Run: `bash setup/clone-fork.sh` to clone and start the local workspace.
-
-**Check 3 — Postiz API is reachable:**
-
-```bash
-curl -s http://localhost:3000/api/healthcheck || echo "not reachable"
-```
-
-If not reachable and user wants local-fork mode, tell the user:
-
-> Postiz API is not responding on port 3000. Run `bash setup/clone-fork.sh` or `docker compose up -d` inside the Postiz repo to start the services.
-
-**Check 4 — Agent-only mode:**
-
-If no local Postiz fork is available or desired, proceed in agent-only mode. Document mode as `agent-only` at the top of every output. Caption generation and content calendar planning are fully available in agent-only mode. Scheduling manifests can be produced as dry-run JSON that the user submits manually.
-
-**Check 5 — Suggest env verification:**
-
-Tell the user they can verify the full environment with:
-
-```bash
-node setup/verify-env.mjs
-bash setup/check-deps.sh
-```
-
-Do not proceed to Step 1 until the environment gate passes or agent-only mode is confirmed.
-
----
-
-### STEP 1 — Read methodology + load brand/client context
-
-Read:
-
-```text
-skills.md
-brands/<client-slug>/brand-kit.md   (if it exists)
-brands/growthub/brand-kit.md        (fallback example)
-```
-
-Extract from the brand kit:
-- client identity, industry, and brand voice
-- target platforms and primary audience demographics
-- content themes and messaging guardrails
-- competitor accounts for reference
-- campaign objectives and KPI targets
-- existing deliverables log
-
-If no brand kit exists for the client, create one from `brands/_template/brand-kit.md` before proceeding.
-
----
-
-### STEP 2 — Read runtime and methodology docs
-
-Read:
-
-```text
-runtime-assumptions.md
-docs/postiz-fork-integration.md
-docs/platform-coverage.md
-docs/ai-caption-layer.md
-docs/bullmq-queue-layer.md
-output-standards.md
-validation-checklist.md
-```
-
-These files define the execution environment, platform constraints, and output contract. Do not improvise around them.
-
----
-
-### STEP 3 — Inspect the local fork (local-fork mode only)
-
-Before writing campaign plans or scheduling manifests, inspect the actual Postiz workspace.
-
-Priority source-of-truth files in the fork:
-
-```text
-README.md
-docker-compose.yml          (service topology — Redis, PostgreSQL, Postiz API)
-apps/backend/               (NestJS API source)
-apps/frontend/              (Next.js frontend)
-libraries/nestjs-libraries/src/integrations/  (28+ platform integrations)
-```
-
-Confirm which platform integrations are enabled in the running instance and whether the Postiz API is accessible. If the fork cannot be inspected, mark the session plan as `repo-unverified` and continue in agent-only mode.
-
----
-
-### STEP 4 — Ask the 4-question gate
-
-Ask exactly 4 clarification questions before producing any output:
-
-1. Which client or brand is this campaign for?
-2. Which platforms should the campaign target (select from supported list in `docs/platform-coverage.md`)?
-3. What is the campaign objective: brand awareness / lead generation / engagement / product launch / community growth?
-4. What is the campaign timeframe and posting cadence (e.g., 30 days / daily / 3x per week)?
-
-Do not begin planning until these are answered or clearly inferable from context.
-
----
-
-### STEP 5 — Select the primary command path
-
-Map the user's intent to a primary `/postiz` command.
-
-| Command | Use When |
-|---|---|
-| `/postiz campaign` | Full campaign brief + content calendar + publishing plan |
-| `/postiz calendar` | Content calendar only — existing brief provided |
-| `/postiz captions` | Caption copy deck for a specific platform or batch |
-| `/postiz schedule` | Generate BullMQ-compatible scheduling manifest |
-| `/postiz analytics` | Produce analytics briefing from Postiz API data or provided metrics |
-| `/postiz proposal` | Client-ready proposal with platform mix and ROI projection |
-| `/postiz platforms` | Platform coverage report for a specific client context |
-| `/postiz quick` | 30-second campaign snapshot for a domain or brand |
-
-Default to `/postiz campaign` for full-scope requests. Default to `/postiz quick` for initial discovery.
-
----
-
-### STEP 6 — Phase 1: Campaign strategy and platform selection
-
-Build the campaign strategy foundation before producing any copy.
-
-Extract and define:
-- Primary platform mix (max 5 platforms per campaign unless explicitly expanded)
-- Posting frequency per platform (see `docs/platform-coverage.md` for recommended cadence)
-- Content theme pillars (3–5 recurring topics aligned with campaign objective)
-- Audience segments (primary, secondary) with platform-matched messaging
-- Caption tone per platform (LinkedIn: professional; TikTok: casual/trend-aware; X: concise/punchy; Instagram: visual-first)
-- Visual content requirements (image specs, video length caps, carousel eligibility)
-
-Document the strategy foundation before drafting any captions.
-
----
-
-### STEP 7 — Phase 2: Content calendar and caption drafts
-
-Draft the full content calendar and caption copy deck.
-
-**Content Calendar Rules:**
-- One row per scheduled post in the calendar template
-- Include: Date, Platform, Content Theme, Post Type (image/video/carousel/text), Caption Preview, CTA, Media Asset Notes
-- Maintain consistent cadence across all selected platforms
-- Flag platform-specific constraints (e.g., X character limit 280, LinkedIn 3000, TikTok 2200)
-
-**Caption Copy Deck Rules:**
-- Draft 3 caption variants per post (A/B/C options)
-- Each variant adapts tone for the target platform
-- Include relevant hashtag sets (platform-appropriate quantity)
-- Tag @mentions where applicable (brand, collaborators, partners)
-- Apply AI caption enhancement from `docs/ai-caption-layer.md` methodology
-
----
-
-### STEP 8 — Phase 3: Scheduling manifest (local-fork and hybrid modes)
-
-If scheduling is requested and the Postiz API is reachable, generate the BullMQ-compatible scheduling manifest.
-
-The manifest follows the format defined in `docs/bullmq-queue-layer.md`. Each entry includes:
-- `platform` — Postiz integration ID (from `docs/platform-coverage.md`)
-- `postId` — unique post identifier for this session
-- `scheduledAt` — ISO 8601 timestamp
-- `content` — selected caption variant (A/B/C)
-- `mediaAssets` — array of asset references (paths or URLs)
-- `workspaceId` — Postiz workspace UUID (from client brand kit or Postiz API response)
-
-In agent-only mode, produce the manifest as a dry-run JSON file that the user can submit to the Postiz API manually.
-
----
-
-### STEP 9 — Build the artifact package
-
-Produce all deliverables from the templates directory in the required output order (see below). Use only templates from `templates/`. Do not invent new template schemas.
-
----
-
-### STEP 10 — Log the deliverable
-
-Save all output files to:
-
-```text
-output/<client-slug>/<project-slug>/
-```
-
-Append a line to the active brand kit DELIVERABLES LOG:
-
-```text
-- YYYY-MM-DD | Social Media Campaign Package v<N> — <Project Name> | output/<client-slug>/<project-slug>/
-```
-
----
-
-## CRITICAL RULES
-
-| Rule | Meaning |
-|---|---|
-| Env gate must pass first | No Postiz reachable and no agent-only confirmation = no session |
-| Read `skills.md` before every task | No memory-only operation — always re-read the methodology |
-| Inspect the fork before scheduling | API and integration state outrank any assumption in this kit |
-| Platform list from docs only | Never invent a platform ID — use `docs/platform-coverage.md` |
-| Pick one primary command per job | Document command selection reasoning |
-| Caption variants are always A/B/C | Never produce only one caption option |
-| No secrets in outputs | Never log DATABASE_URL, REDIS_URL, or OAuth tokens |
-| Agent-only mode is always valid | Fork availability does not block campaign planning |
-| Outputs must be operational | Every file should help an operator act immediately |
-
----
-
-## REQUIRED OUTPUT ORDER
-
-1. `SocialCampaignBrief`
-2. `ContentCalendar`
-3. `PlatformPublishingPlan`
-4. `CaptionCopyDeck`
-5. `SchedulingManifest` (if scheduling requested)
-6. `AnalyticsBrief` (if analytics data provided or API accessible)
-7. `ClientProposal` (if requested)
-
----
-
-## Governed-workspace primitives (v1.2)
-
-This workspace carries the six architectural primitives every Growthub fork inherits. The contract is capability-agnostic (`@growthub/api-contract/skills::SkillManifest`); kit-specific specialisation lives in `skills.md` above.
-
-1. **`SKILL.md`** at the kit root — the discovery entry / routing menu. Read before `skills.md`.
-2. **Repo-root `AGENTS.md` pointer** — Cursor / Claude / Codex all read the same contract.
-3. **`.growthub-fork/project.md`** — session memory, seeded at init/import from `templates/project.md`. Append a dated entry after every material change.
-4. **Self-evaluation (`selfEval.criteria` + `maxRetries`)** — generate → apply → evaluate → record; retry up to 3; every attempt writes to both `project.md` (human) and `trace.jsonl` (machine). Use `recordSelfEval` (`cli/src/skills/self-eval.ts`); never bypass the fork-trace primitive.
-5. **Nested `skills/<slug>/SKILL.md`** — sub-skill lanes for parallel sub-agents on heavy or narrow work.
-6. **`helpers/<verb>.{sh,mjs,py}`** — safe shell tool layer; promote any inline shell that gets used twice.
-
-Command surface from inside this fork:
-
-- `growthub skills list` — enumerate this fork’s SKILL.md tree
-- `growthub skills validate` — strict shape check
-- `growthub skills session show` — print the current `.growthub-fork/project.md`
-- `growthub skills session init --kit <kit-id>` — (re-)seed session memory
-
-Full user-facing narrative: `cli/assets/worker-kits/growthub-custom-workspace-starter-v1/docs/governed-workspace-primitives.md` (also shipped into any workspace forked from the starter kit).

package/assets/worker-kits/growthub-twenty-crm-v1/.env.example

@@ -1,17 +0,0 @@
-# Twenty CRM Worker Kit — Environment Config
-# Copy this file to .env and fill in your credentials.
-# Never commit .env to version control.
-
-# Required: Twenty API bearer token.
-# Generate from Twenty Settings > API > Tokens.
-TWENTY_API_TOKEN=your_twenty_api_token_here
-
-# Required: Twenty API base URL.
-# Use https://api.twenty.com for cloud, or http://localhost:3000 for local fork.
-TWENTY_API_URL=https://api.twenty.com
-
-# Optional: override local fork path used by setup scripts.
-# Canonical env var: TWENTY_HOME (uniform pattern across all worker kits)
-# Legacy alias: TWENTY_FORK_PATH (still accepted by the CLI)
-# Default when unset: $HOME/twenty
-TWENTY_HOME=$HOME/twenty

package/assets/worker-kits/growthub-twenty-crm-v1/QUICKSTART.md

@@ -1,90 +0,0 @@
-# Quick Start — Twenty CRM Worker Kit
-
-This folder is your self-contained agent working directory for Twenty CRM implementation, enrichment pipeline design, and CRM playbook production.
-
----
-
-## Step 1 — Point your Working Directory at this folder
-
-**Growthub local (primary):** Open Growthub local and set the **Working Directory** to this folder in your project settings. Every run you start from this working directory will load the Twenty CRM operator agent automatically.
-
-**Claude Code (alternative):** Open Claude Code settings and set the **Working Directory** to this folder. The operator agent loads from `workers/twenty-crm-operator/CLAUDE.md` on session start.
-
----
-
-## Step 2 — Configure your Twenty credentials
-
-```bash
-cp .env.example .env
-```
-
-Open `.env` and fill in:
-- `TWENTY_API_TOKEN` — your Twenty app token (generate in Twenty Settings > API)
-- `TWENTY_API_URL` — your workspace API URL (e.g. `https://api.twenty.com` for cloud, or `http://localhost:3000` for local)
-
-The agent checks for these values at the start of every session (Step 0 of the workflow). It will not proceed without them in API-connected mode. Agent-only mode does not require credentials.
-
----
-
-## Step 3 — Verify your environment
-
-```bash
-node setup/verify-env.mjs
-```
-
-Confirms that `TWENTY_API_TOKEN` is set, tests connectivity to the Twenty API, and prints available workspace info. Exits 0 on success.
-
----
-
-## Step 4 — Check local dependencies
-
-```bash
-bash setup/check-deps.sh
-```
-
-Checks for `node`, `npm`, `git`, and `docker`. Docker is required for self-hosted mode. All are recommended for local-fork development.
-
----
-
-## Step 5 — Boot the local fork (local-fork mode only)
-
-```bash
-bash setup/clone-fork.sh
-```
-
-Clones the Twenty repo to `$HOME/twenty`, installs dependencies, and starts the development environment (PostgreSQL, Redis, and the Twenty server + frontend) via Docker Compose.
-
-Skip this step if you are using Twenty Cloud or have an existing self-hosted deployment.
-
----
-
-## Step 6 — Start a new session
-
-**Growthub local:** Start a new run from this working directory. The agent loads automatically.
-
-**Claude Code:** Open a new session with this folder as the Working Directory. The agent reads `skills.md` and the methodology automatically.
-
-In both cases the agent will ask you 3 clarifying questions before generating any CRM artifacts.
-
----
-
-## Execution modes
-
-| Mode | When to use |
-|---|---|
-| `local-fork` | Local Twenty checkout running via Docker at localhost:3000 |
-| `self-hosted` | Twenty deployed on your own infrastructure |
-| `cloud` | Twenty Cloud workspace at app.twenty.com |
-| `agent-only` | No live Twenty instance — produce planning artifacts only |
-
----
-
-## First-run checklist
-
-See `validation-checklist.md` for the full pre-session checklist before your first CRM implementation run.
-
----
-
-## Creating a brand kit for a new client
-
-See `brands/NEW-CLIENT.md`.

package/assets/worker-kits/growthub-twenty-crm-v1/SKILL.md

@@ -1,89 +0,0 @@
----
-name: growthub-twenty-crm-v1
-description: "Self-contained workspace for Twenty CRM — the open-source Salesforce/Apollo alternative. Produces CRM workflows, pipeline rules, and automation specs. Use when the user says: \"twenty crm\", \"crm workflows\", \"pipeline automation\". Session memory tracks workflow iterations, rule approvals, and migration checkpoints."
-triggers:
-  - twenty crm
-  - fork growthub-twenty-crm-v1
-progressiveDisclosure: true
-sessionMemory:
-  path: .growthub-fork/project.md
-selfEval:
-  criteria:
-    - Operator contract (workers/twenty-crm-operator/CLAUDE.md) read before any material change.
-    - .growthub-fork/project.md appended to at each material change.
-    - .growthub-fork/trace.jsonl receives a typed event for each material change.
-    - Kit-specific QUICKSTART / runtime-assumptions / output-standards honoured.
-  maxRetries: 3
-  traceTo: .growthub-fork/trace.jsonl
-helpers: []
-subSkills: []
-mcpTools: []
----
-
-# Growthub Agent Worker Kit — Twenty CRM
-
-Discovery entry + routing menu for the `growthub-twenty-crm-v1` worker kit. Family: `studio`. Agent contract: `workers/twenty-crm-operator/CLAUDE.md`.
-
-## When to use this skill
-
-When the user's intent matches any of the triggers above — or when an agent has been dropped into a fork whose `.growthub-fork/fork.json` declares `kitId: "growthub-twenty-crm-v1"`.
-
-## Decision tree
-
-```
-Fork exists (this directory contains .growthub-fork/fork.json)?
-├── No  → run: growthub starter init --out <path>   (or import-repo / import-skill)
-│         then: growthub kit download growthub-twenty-crm-v1 --out <path>
-│
-└── Yes → read in this order:
-          1. .growthub-fork/project.md                         — session memory (primitive #3)
-          2. SKILL.md  (this file)                             — routing menu  (primitive #1)
-          3. skills.md                                         — operator runbook
-          4. workers/twenty-crm-operator/CLAUDE.md                              — agent contract
-          5. QUICKSTART.md                                     — first-run steps
-          6. runtime-assumptions.md                            — host expectations
-          7. .growthub-fork/policy.json                        — what you may touch
-          8. .growthub-fork/trace.jsonl (tail 20)              — recent machine history
-```
-
-## The six primitives (same shape across every Growthub worker kit)
-
-1. **`SKILL.md`** — this file.
-2. **Symlinked pointer** — repo-root `AGENTS.md` is authoritative.
-3. **`.growthub-fork/project.md`** — session memory, seeded by the CLI from `templates/project.md` at init/import time.
-4. **Self-evaluation** — generate → apply → evaluate → record; retry up to `selfEval.maxRetries` (default 3); mirrors the Fork Sync Agent's preview → apply → trace loop (primitive #4). Contract: `@growthub/api-contract/skills::SkillSelfEval`.
-5. **`skills/`** — nested sub-skills for parallel sub-agents on heavy / narrow work.
-6. **`helpers/`** — safe shell tool layer. Promote inline shell here whenever the same snippet is re-used.
-
-## Self-evaluation (primitive #4)
-
-Enforce `selfEval.maxRetries: 3`. At the ceiling, park with a `needs_confirmation` note in `project.md` and stop. Record every attempt to both `project.md` and `trace.jsonl`.
-
-## Session memory (primitive #3)
-
-`.growthub-fork/project.md` is the only cross-session continuity surface for this fork. Append at every material change, approval boundary, and self-eval outcome.
-
-## Sub-skills (primitive #5)
-
-(None declared at the baseline; populate `skills/` and the frontmatter `subSkills[]` array as specialist lanes emerge.)
-
-## Helpers (primitive #6)
-
-(None declared at the baseline; populate `helpers/` and the frontmatter `helpers[]` array as inline shell matures.)
-
-## MCP routing (optional)
-
-List concrete MCP tool IDs in `mcpTools[]` when a fork runs an MCP server for auth-heavy actions. Declarative only at v1.
-
-## Related files
-
-- `skills.md` — operator runbook (deep)
-- `QUICKSTART.md` — first-run steps
-- `runtime-assumptions.md` — host expectations
-- `output-standards.md` — output locations + manifest shape
-- `validation-checklist.md` — pre-flight checklist (if present)
-- `templates/project.md` — session-memory template
-- `templates/self-eval.md` — self-evaluation template
-- `helpers/README.md` — safe shell tool layer convention
-- `skills/README.md` — sub-skill convention
-- `workers/twenty-crm-operator/CLAUDE.md` — agent contract

package/assets/worker-kits/growthub-twenty-crm-v1/brands/NEW-CLIENT.md

@@ -1,57 +0,0 @@
-# New Client — Brand Kit Setup Guide
-
-Use this guide to create a brand kit for a new client before running the Twenty CRM operator.
-
----
-
-## Step 1 — Create the brand kit folder
-
-```bash
-mkdir -p brands/<client-slug>
-cp brands/_template/brand-kit.md brands/<client-slug>/brand-kit.md
-```
-
-Replace `<client-slug>` with the client's slug — lowercase, hyphenated (e.g. `acme-corp`, `growth-agency`).
-
----
-
-## Step 2 — Fill in the brand kit
-
-Open `brands/<client-slug>/brand-kit.md` and fill in:
-
-1. **IDENTITY** — client name, slug, industry, company size, primary offer, campaign owner, date onboarded
-2. **CRM OBJECTIVE** — what problem they are solving with Twenty, deployment mode, go-live target
-3. **AUDIENCE AND PIPELINE** — primary persona, pipeline stages in order
-4. **TECH STACK** — current tools, enrichment providers, data sources
-5. **TEAM** — CRM admin, team sizes, admin capacity
-
-Leave `DELIVERABLES LOG` empty for now. The operator will append a line after each session.
-
----
-
-## Step 3 — Tell the agent
-
-When you start a new session, point the agent to the brand kit:
-
-> "Load `brands/<client-slug>/brand-kit.md` as the active client context."
-
-The agent loads it in Step 1 of the workflow and uses it to name outputs, set the pipeline stage vocabulary, and calibrate proposal scope.
-
----
-
-## Naming convention
-
-- `client_name`: Full name (e.g. `Acme Corporation`)
-- `slug`: lowercase, hyphenated, no spaces (e.g. `acme-corporation`)
-- Output files use PascalCase ClientSlug (e.g. `AcmeCorporation_DataModelDesign_v1_20260415.md`)
-
----
-
-## Required fields (session will not proceed without these)
-
-- `client_name`
-- `slug`
-- `primary_crm_objective`
-- `deployment_mode`
-- `pipeline_stages` (at least 3 stages)
-- `data_sources` (at least one)

package/assets/worker-kits/growthub-twenty-crm-v1/brands/_template/brand-kit.md

@@ -1,88 +0,0 @@
-# Brand Kit — [CLIENT NAME]
-
-Copy to `brands/<client-slug>/brand-kit.md` and fill before producing outputs.
-
----
-
-## IDENTITY
-
-```yaml
-client_name: "[CLIENT NAME]"
-slug: "[client-slug]"
-industry: "[industry]"
-company_size: "[e.g. 10-50 employees]"
-primary_offer: "[offer]"
-campaign_owner: "[owner]"
-date_onboarded: "YYYY-MM-DD"
-```
-
-## CRM OBJECTIVE
-
-```yaml
-primary_crm_objective: "[e.g. lead pipeline management / customer success tracking / partner CRM]"
-current_crm_tool: "[e.g. Salesforce / HubSpot / Airtable / none]"
-reason_for_switching: "[reason or first-time adoption]"
-deployment_mode: "[cloud / self-hosted / local-fork]"
-go_live_target: "YYYY-MM-DD"
-```
-
-## AUDIENCE AND PIPELINE
-
-```yaml
-primary_persona:
-  role: "[role]"
-  company_type: "[company type]"
-  pain_point: "[pain]"
-  desired_outcome: "[desired outcome]"
-  awareness_level: "[awareness]"
-
-pipeline_stages:
-  - "[Stage 1 — e.g. Lead]"
-  - "[Stage 2 — e.g. Qualified]"
-  - "[Stage 3 — e.g. Demo]"
-  - "[Stage 4 — e.g. Proposal]"
-  - "[Stage 5 — e.g. Closed Won]"
-  - "[Stage 6 — e.g. Closed Lost]"
-```
-
-## TECH STACK
-
-```yaml
-current_tools:
-  email_provider: "[e.g. Gmail / Outlook]"
-  enrichment_providers:
-    - "[Apollo / Clearbit / Clay / Hunter / none]"
-  product_analytics: "[Segment / Amplitude / Mixpanel / none]"
-  billing: "[Stripe / Chargebee / none]"
-  support: "[Intercom / Zendesk / none]"
-  marketing: "[HubSpot / Mailchimp / none]"
-  data_sources:
-    - "[CSV exports from ...]"
-    - "[API connection from ...]"
-```
-
-## TEAM
-
-```yaml
-team:
-  crm_admin: "[name or role]"
-  sales_team_size: "[number]"
-  cs_team_size: "[number]"
-  admin_capacity: "[hours/week available for CRM maintenance]"
-```
-
-## MESSAGING
-
-```yaml
-voice_and_tone:
-  - "[direct]"
-  - "[data-driven]"
-messaging_guardrails:
-  - "[no-go claim or data privacy rule]"
-```
-
-## DELIVERABLES LOG
-
-```text
-- YYYY-MM-DD | Twenty CRM Package v<N> — <Project Name> | output/<client-slug>/<project-slug>/
-```