50 lines
3.3 KiB
Markdown
50 lines
3.3 KiB
Markdown
---
|
||
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.
|
||
|
||
---
|