zhongwei/gh-gtmagents-gtm-agents-plugins-analytics-pipeline-orchestration
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 18:29:43 +08:00
commit d16ebac7ef
12 changed files with 424 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
commands/build-model.md Normal file
View File

@@ -0,0 +1,48 @@
---
name: build-model
description: Generates a modeling plan detailing transforms, tests, and deployment schedule for analytics use cases.
usage: /analytics-pipeline-orchestration:build-model --use_case "pipeline velocity" --stack "dbt" --refresh daily
---
# Command: build-model
## Inputs
- **use_case** – name of metric or dashboard relying on the model.
- **stack** – modeling tool (dbt, LookML, Metrics Layer, SQL Runner, Python jobs).
- **refresh** – cadence (hourly, daily, weekly) or cron.
- **dependencies** – optional upstream tables or APIs.
- **tests** – optional list of validations to enforce.
### GTM Agents Pattern & Plan Checklist
> Mirrors GTM Agents orchestrator blueprint @puerto/plugins/orchestrator/README.md#112-325.
- **Pattern selection**: Modeling often runs **pipeline** (spec → blueprint → testing → deployment → docs). If testing + deployment prep can parallelize, log a **diamond** segment with merge gate.
- **Plan schema**: Save `.claude/plans/plan-<timestamp>.json` with objective, data lineage, task IDs, parallel groups, dependency matrix, error handling, and success metrics (freshness %, defect ceiling, SLA adherence).
- **Tool hooks**: Reference `docs/gtm-essentials.md` stack—Serena for repo diffs/dbt patches, Context7 for platform docs, Sequential Thinking for review cadences, Playwright for UI validations tied to modeled data.
- **Guardrails**: Default retry limit = 2 for failed tests/deployments; escalation path = Analytics Modeling Lead → Data Engineering Lead → RevOps.
- **Review**: Run `docs/usage-guide.md#orchestration-best-practices-puerto-parity` before execution to confirm agents, dependencies, deliverables.
## Workflow
1. **Spec Alignment** – review event/tracking plan, KPI definitions, stakeholders.
2. **Model Blueprint** – outline staging, intermediate, mart layers, join keys, surrogate IDs.
3. **Testing Strategy** – define schema, freshness, unique, accepted value, and custom tests.
4. **Deployment Plan** – schedule jobs, resource configs, backfill strategy, rollback steps.
5. **Documentation & Handoff** – update dbt docs / catalog, change log, owner assignments.
## Outputs
- Modeling spec (diagram, SQL pseudocode, dependencies).
- Test plan + configuration snippets.
- Deployment checklist with monitoring hooks and rollback instructions.
- Plan JSON entry stored/updated in `.claude/plans` for audit trail.
## Agent/Skill Invocations
- `analytics-modeling-lead` – architects model + tests.
- `quality-gates` skill – ensures validation coverage.
- `instrumentation` skill – confirms data contracts stay intact.
## GTM Agents Safeguards
- **Fallback agents**: document substitutes (e.g., BI Publisher covering modeling reviews) when specialists unavailable.
- **Escalation triggers**: if freshness, defect, or SLA guardrails breach twice within 24h, escalate to Data + RevOps leadership per GTM Agents runbook and consider rollback.
- **Plan maintenance**: update plan JSON whenever dependencies, owners, or deployment cadence changes, keeping audit alignment with GTM Agents standards.
---

48
commands/define-events.md Normal file
View File

@@ -0,0 +1,48 @@
---
name: define-events
description: Produces instrumentation specification with events, properties, owners, and QA steps.
usage: /analytics-pipeline-orchestration:define-events --use_case "pipeline velocity" --sources "product,crm" --tools "Segment,dbt"
---
# Command: define-events
## Inputs
- **use_case** – business question or KPI the events support.
- **sources** – data sources involved (product, web, CRM, MAP, billing).
- **tools** – instrumentation stack (CDP, product analytics, warehouse, dbt).
- **constraints** – optional legal/compliance requirements.
- **timeline** – optional delivery date.
### GTM Agents Pattern & Plan Checklist
> Mirrors GTM Agents orchestrator blueprint @puerto/plugins/orchestrator/README.md#112-325.
- **Pattern selection**: Instrumentation typically runs **pipeline** (requirements → catalog → governance → QA → change mgmt). If governance + QA can run parallel, log a **diamond** segment with merge gate in the plan header.
- **Plan schema**: Save `.claude/plans/plan-<timestamp>.json` capturing objective, data sources, task IDs, dependencies, context passing (schemas, privacy notes), error handling, and success metrics (coverage %, defect ceiling).
- **Tool hooks**: Reference `docs/gtm-essentials.md` stack (Serena for repo diffs, Context7 for platform/legal docs, Sequential Thinking for review flows, Playwright for front-end event QA when applicable).
- **Guardrails**: Default retry limit = 2 for QA failures; escalation ladder = Analytics Data Strategist → Data Engineering Lead → RevOps.
- **Review**: Run `docs/usage-guide.md#orchestration-best-practices-puerto-parity` before execution to confirm agents, dependencies, deliverables.
## Workflow
1. **Requirement Gathering** – clarify KPIs, dimensions, and downstream consumers.
2. **Event Cataloging** – list events, payloads, properties, IDs, sampling rate, ownership.
3. **Governance Mapping** – document naming conventions, consent handling, retention policies.
4. **QA Plan** – outline testing methods (unit tests, replay, observability dashboards).
5. **Change Management** – define review/approval steps, rollout plan, and version control.
## Outputs
- Instrumentation spec (event name, description, properties, source, owner, status).
- Tracking plan (CSV/JSON/YAML) aligned with CDP or analytics tool requirements.
- QA checklist + evidence plan (logs, dashboards, sample payloads).
- Plan JSON entry stored/updated in `.claude/plans` for audit trail.
## Agent/Skill Invocations
- `analytics-data-strategist` – leads requirements + governance.
- `instrumentation` skill – enforces schema + consent rules.
- `quality-gates` skill – defines QA expectations.
## GTM Agents Safeguards
- **Fallback agents**: document substitutes (e.g., BI Publisher covering QA) if specialists unavailable.
- **Escalation triggers**: if instrumentation defects or compliance blockers breach guardrails twice in 48h, escalate to Data + Legal leadership, triggering GTM Agents-style rip-cord.
- **Plan maintenance**: update plan JSON/change log whenever events, schemas, or governance rules change to keep analytics audit-ready.
---

48
commands/ship-dashboards.md Normal file
View File

@@ -0,0 +1,48 @@
---
name: ship-dashboards
description: Creates a dashboard launch plan with visualization specs, enablement steps, and monitoring.
usage: /analytics-pipeline-orchestration:ship-dashboards --use_case "pipeline velocity" --tool looker --audience "exec,sales"
---
# Command: ship-dashboards
## Inputs
- **use_case** – dashboard or report purpose.
- **tool** – BI platform (Looker, Tableau, Mode, Sigma, PowerBI).
- **audience** – comma-separated audiences.
- **access** – optional role-based access requirements.
- **alerts** – optional alert thresholds or anomaly rules.
### GTM Agents Pattern & Plan Checklist
> Based on GTM Agents orchestrator blueprint @puerto/plugins/orchestrator/README.md#112-325.
- **Pattern selection**: Dashboard launches typically run **pipeline** (requirements → visualization → publishing → enablement → monitoring). If publishing + enablement can proceed in parallel, log a **diamond** segment and merge gate.
- **Plan schema**: Save `.claude/plans/plan-<timestamp>.json` with objective, visualization stages, task IDs, parallel groups, dependency graph (models, permissions), error handling, and success metrics (adoption %, freshness, alert SLA).
- **Tool hooks**: Reference `docs/gtm-essentials.md` stack—Serena for repo/LookML diffs, Context7 for BI platform docs, Sequential Thinking for rollout retros, Playwright for UI QA of embedded dashboards.
- **Guardrails**: Default retry limit = 2 for failed publishes/alerts; escalation path = BI Publisher → Analytics Modeling Lead → RevOps/Exec sponsor.
- **Review**: Use `docs/usage-guide.md#orchestration-best-practices-puerto-parity` before execution to confirm agents, dependencies, deliverables.
## Workflow
1. **Requirement Review** – confirm metrics, filters, drill paths, narrative structure.
2. **Visualization Spec** – define layout, chart types, color systems, accessibility notes.
3. **Publishing Steps** – build dashboards, set permissions, schedule refreshes, configure alerts.
4. **Enablement & Rollout** – plan walkthroughs, documentation, office hours, feedback channels.
5. **Monitoring** – track usage analytics, data freshness, dashboard performance, enhancement backlog.
## Outputs
- Dashboard spec (wireframe, chart list, metrics dictionary).
- Enablement kit (loom/video, doc, FAQ, adoption plan).
- Monitoring + enhancement tracker.
- Plan JSON entry stored/updated in `.claude/plans` for audit trail.
## Agent/Skill Invocations
- `bi-publisher` – leads visualization + enablement.
- `visualization-patterns` skill – enforces design best practices.
- `quality-gates` skill – ensures data + refresh checks.
## GTM Agents Safeguards
- **Fallback agents**: document substitutes (e.g., Analytics Data Strategist covering BI Publisher) when specialists unavailable.
- **Escalation triggers**: if adoption, freshness, or alert guardrails breach twice in 48h, escalate to Analytics + GTM leadership and trigger rollback plan.
- **Plan maintenance**: update plan JSON/change log whenever visual specs, access rules, or monitoring hooks change to maintain GTM Agents-grade auditability.
---