gh-gtmagents-gtm-agents-plugins-personalization-engine/commands/configure-rules.md

name, description, usage

name	description	usage
configure-rules	Deploys decision logic, content variants, and delivery rules across personalization channels.	/personalization-engine:configure-rules --initiative "PLG Onboarding" --environment staging --channels "web,in-app"

Command: configure-rules

Inputs

• initiative – reference to the personalization effort from define-profiles.
• environment – staging | production to govern deployment steps.
• channels – comma-separated list of activation surfaces.
• change_type – net-new, update, rollback.
• approvers – optional stakeholders for governance sign-off.

GTM Agents Pattern & Plan Checklist

Mirrors GTM Agents orchestrator blueprint @puerto/plugins/orchestrator/README.md#112-325.

• Pattern selection: Rule configuration generally runs pipeline (pre-flight → decision build → variant mapping → QA → deployment). If decision build + variant prep happen in parallel, note a diamond block with merge gate in the plan header.
• Plan schema: Save .claude/plans/plan-<timestamp>.json capturing initiative, environments, dependency graph (data eng, creative, QA, governance), error handling, and success metrics (latency, personalization lift, incident count).
• Tool hooks: Reference docs/gtm-essentials.md stack—Serena for rule diffing, Context7 for platform SOPs, Sequential Thinking for go/no-go reviews, Playwright for simulation/QA evidence capture.
• Guardrails: Default retry limit = 2 for deployment/QA failures; escalation ladder = Personalization Architect → Data Privacy Lead → Exec sponsor.
• Review: Run docs/usage-guide.md#orchestration-best-practices-puerto-parity before deployment to confirm dependencies + approvals.

Workflow

1. Pre-flight Review – validate profiles, data freshness, consent status, and experiment dependencies.
2. Decision Flow Build – configure rules, weights, or model endpoints in MAP/CDP/product tooling.
3. Variant Mapping – link each rule outcome to content assets, CTAs, and fallback experiences.
4. QA & Simulation – run synthetic traffic through decision trees, capture screenshots/logs.
5. Deployment & Logging – push changes via API/CLI, note version metadata, set up monitoring hooks.

Outputs

• Deployment runbook with rule IDs, version numbers, and rollback plan.
• QA evidence (simulation results, screenshots, payload logs).
• Governance log including approvers, timestamps, and linked experiments.
• Plan JSON entry stored/updated in .claude/plans for audit trail.

Agent/Skill Invocations

• customer-data-engineer – ensures data pipelines and environments are ready.
• personalization-architect – verifies experience logic + content mapping.
• content-variants skill – tracks asset requirements + approvals.
• governance skill – enforces change controls and compliance steps.

GTM Agents Safeguards

• Fallback agents: document substitutes (e.g., governance lead covering architect) when owners unavailable.
• Escalation triggers: if QA fails twice, latency spikes, or privacy gate blocks deployment, trigger GTM Agents rip-cord and log remediation in plan JSON.
• Plan maintenance: update plan JSON/change log when rule sets, environments, or deployment windows change so reviewers can trace history.

---