---
name: configure-rules
description: Deploys decision logic, content variants, and delivery rules across personalization channels.
usage: /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.

---