Dev Time Integration¶
At dev time, RCG injects regulatory context into your coding agent's prompt so that every code change it makes is compliant by construction — before a single line ships.
How It Works¶
When a developer asks a coding agent (e.g., Claude Code) to implement a feature, the agent normally operates with only internal context: the codebase, the PRD, existing docs. It has no awareness of what regulators permit or prohibit for that feature.
With RCG, the RCG.md file for the feature is included in the agent's context. Every prompt the agent processes now carries the regulatory dos and don'ts. The agent writes code that accounts for disclosure requirements, data-handling constraints, and scope boundaries — not because a human caught a gap, but because the regulatory context was there from the first prompt.
The /rcg Skill in Claude Code¶
The /rcg skill is a Claude Code slash command that automates the full intake-to-generation workflow inside your coding session.
Running an intake interview¶
When you start building a new feature, run /rcg and point it at your PRD:
Claude Code will:
- Read your PRD, product description, and README
- Assess the feature against the five regulatory primitives
- Identify gaps (data posture, consent mechanisms, AI disclosure, data flow, scope boundaries)
- Propose a
rcg.yamlenvelope with reasoned regulator selection - Ask clarifying questions before writing any files
A typical gap analysis output looks like:

- G1 — Data posture: PRD says inputs are discarded at session end, but doesn't describe the UX mechanism — passive grey notice or affirmative checkbox?
- G2 — Decisioning posture: PRD labels the response as "AI-generated coaching" in a post-output label, but is silent on what happens before the user clicks Submit
- G3 — Flow direction: PRD acknowledges financial inputs go to third-party model providers, but there's no mention of a data processing agreement or CFPB service-provider oversight expectations
Confirming and generating¶
After the intake interview, confirm the proposed envelope:
G1: patch — affirmative checkbox required before submit
G2: patch — pre-submit modal with "AI coaching, not financial advice" language
G3: scope-out — provider agreement is an infra/legal concern, not this feature's scope
regulators: ["FTC", "CFPB", "NYDFS"]
recency_window_days: 365
Claude Code writes rcg.yaml, runs rcg generate, validates with a dry-run, and produces RCG.md. It then reads the context bundle and synthesizes the compliance requirements back into the implementation plan before writing any code.
What Changes in the Code¶
With RCG.md in context, the agent produces measurably different output. For a consumer financial AI feature, this typically means:
- A pre-submit disclosure modal (FTC AI disclosure requirement)
- An affirmative consent checkbox before financial data is submitted (CFPB data-rights)
- A "not financial advice" label on AI-generated responses (FTC deceptive practices)
- Session-scoped data handling with no persistence (data minimization)
- Scope-out of third-party model provider agreements to infra/legal (not baked into the feature)
These aren't post-hoc patches — they're part of the initial implementation, because the regulatory context was present when the agent wrote the first draft.
Demo: MeridianPay Budgetly Feature¶
The walkthrough below shows the difference between a feature built without RCG and the same feature built with it.
Without RCG — the budgetly tab: a monthly budget snapshot tool that collects income and spend data. Functional, but no disclosure, no consent mechanism, no AI labeling.

With RCG — the Budgetly-with-RCG tab: the same tool, now governed by REGULATORY.md. Before the user can submit their data, they see a mandatory disclosure modal:

The modal is tagged RCG-GOVERNED · PER REGULATORY.MD §DISCLOSURES & CONSENT and clearly states that the response is AI-generated coaching — not financial advice — and that inputs will not be stored or shared. After acknowledging, the user sees the form with an affirmative consent checkbox required before submission:

None of this was written by a compliance lawyer after a review. It was generated by the coding agent from the dos and don'ts in RCG.md, during the original implementation.