Notes
Open source · Agentic tooling

RePPIT Health A compliance-aware coding agent workflow.

Nils Widal···8 min read

Agentic coding has collapsed the distance between a feature request and a merged diff. In most domains that compression is a gift. In healthcare it is a liability. When a model can plan, edit, and commit across a clinical codebase in a single session, every compliance obligation that used to live in a quarterly audit now lives on the diff. HIPAA, SOC2, HITRUST: they are no longer paperwork the security team handles after launch. They are properties the code either has or does not have, every time the agent ships.

That is the problem RePPIT Health sets out to solve. It is an open-source Claude Code plugin, built by Cara (the team behind Widal), that wraps agentic development in a compliance-aware workflow. Six phases, approval gates between each, and a security pass that knows the difference between a HIPAA control it can verify from the diff and one it cannot. We wrote about compliance as a code property already. RePPIT Health is what enforcing that thesis looks like in a working tool.

A compliance-aware agent does not audit at the end. It audits at every gate.

RePPIT, and what we added

The methodology comes from Mihail Eric, head of AI and the creator of Stanford's first AI software engineering course, published at themodernsoftware.dev. RePPIT stands for Research, Propose, Plan, Implement, Test. It is a disciplined way to keep an agent from skipping straight to code, which is the failure mode that produces convincing but wrong implementations. RePPIT forces the agent to first describe what exists, then propose what could change, then commit to a plan, then write the code, then prove it works.

RePPIT Health adds an S. Secure. A sixth phase, executed against the diff, that runs HIPAA, SOC2, and HITRUST checklists and produces a report the agent itself cannot wave away. The full flow becomes RePPITS: Research, Propose, Plan, Implement, Test, Secure. Each phase has an approval gate. Each gate is something a human can stop or accept. The agent does not get to silently move from research to merged.

Six phases, six gates

  1. Research. Document the codebase as it actually is. No suggestions. No root-cause analysis. No improvements. The goal is shared ground truth before anyone proposes anything.
  2. Propose. Up to two solution proposals, grounded in the research output. Two is a deliberate ceiling. It forces a choice instead of a menu.
  3. Plan. Convert the chosen proposal into ordered Linear issues, or local plan files if Linear MCP is not wired up. The plan is the unit a human approves before a single line of code is written.
  4. Implement. Execute a single planned issue at a time. An optional Ralph Loop mode runs the implement-test-review cycle until the issue is genuinely done.
  5. Test. Review uncommitted changes, post findings back to Linear, and gate the merge on what the review surfaces.
  6. Secure. Run HIPAA, SOC2, and HITRUST checklists against the diff. Separate code-verifiable findings from organizational controls. Surface both, conflate neither.

The plugin ships seven slash commands, one per phase plus an orchestrator that runs them in order.

/reppit <topic-or-issue>   # full flow, with approval gates
/research-codebase        # document as-is, no suggestions
/make-proposals           # up to two grounded options
/make-plan                # ordered Linear issues (or plans/*.md)
/implement <issue>        # single issue, optional Ralph Loop
/review-code              # uncommitted diff, findings to Linear
/secure                   # HIPAA + SOC2 + HITRUST against the diff

Why /secure is the interesting one

The first five phases are good engineering hygiene. They would help any team shipping any software. The sixth phase is what makes the plugin healthcare-specific, and it is where most compliance tooling gets the architecture wrong.

Compliance frameworks contain two very different kinds of requirements. Some are properties of the code: encryption at rest, audit logging on PHI access, session timeouts, input validation, secret management, transport security. An agent reading a diff can verify these or fail them with high confidence. Other requirements are properties of the organization: a signed BAA with every subprocessor, board-level oversight of the security program, documented physical safeguards in the data center, an incident response drill in the last twelve months. No diff can prove these. No agent should pretend to.

The agent does not pretend to verify what it cannot. That restraint is the whole point.

/secure runs four checklists, all of which live in the plugin's compliance/ directory and can be overridden per workspace at .claude/compliance/<framework>-checklist.md.

  • hipaa-checklist.md. §164.308 to §164.312 administrative, physical, and technical safeguards. PHI detection in the diff. Minimum necessary. BAA posture. Breach notification readiness. Telehealth-specific guidance.
  • soc2-checklist.md. Trust Service Criteria CC1 through CC9. Availability (A1), Confidentiality (C1), Processing Integrity (PI1), Privacy (P1). The framework most SaaS-side healthcare buyers ask about first.
  • hitrust-checklist.md. All fourteen CSF v11 control categories, 00 through 13. The framework most enterprise health systems ask about second.
  • org-controls-audit.md. Everything that cannot be verified from code alone, surfaced as a separate report so it does not auto-pass on a clean diff.

Each checklist item resolves to one of four states: PASS, WARN, FAIL, or SKIPPED. Items tagged [org] are partitioned into a separate section of the report. They never silently pass. A green diff does not mean a green organization, and the tool refuses to imply otherwise.

The threat model the workflow assumes

A compliance-aware agent has to defend against the way agentic coding fails in healthcare specifically, not just the way it fails in general.

  1. Plausible-but-wrong implementations. The model writes code that compiles and runs but logs PHI to a service with no BAA. RePPIT's research and plan phases give a human a chance to catch this before code exists.
  2. Silent control regression. A refactor removes session timeout enforcement or weakens a permission check. /secure reads the diff against the HIPAA technical safeguards checklist and surfaces the regression.
  3. Framework conflation. An agent claims HIPAA compliance based on SOC2 evidence, or HITRUST coverage based on HIPAA controls. Three distinct checklists, separately reported, prevent this.
  4. Org-control hallucination. The agent asserts a BAA exists, or a physical safeguard is in place. The org-controls audit refuses to mark these as passed without external evidence.
  5. Compliance theater. A green report that nobody reads. The plan phase forces Linear issues, the test phase posts findings back, and the security phase produces a report attached to the diff under review.

Why we open-sourced it

We considered keeping this internal. It is genuinely useful scaffolding and we use it on every client engagement. We decided against gatekeeping it for two reasons.

The first is that the asymmetry is bad for patients. Every healthtech team is going to ship AI-written code over the next two years. Most will not have the time, budget, or in-house compliance expertise to build a workflow like this. If the tooling stays proprietary, the median piece of clinical software gets less safe, not more. That is not a market we want to operate in.

The second is more practical. A compliance workflow improves when adversarial teams use it, file issues, and contribute checklist refinements. Apache 2.0, public repository, real issue tracker. We would rather have a thousand teams running this and pushing back on its blind spots than have ten teams running it and us pretending it is finished. Cara wants healthtech teams shipping compliance-aware AI code with or without engaging us. We will still be here when a team wants hands-on HIPAA work beyond what a checklist can give them.

Install

Two commands. Apache 2.0. No license keys, no telemetry, no account.

/plugin marketplace add carainc/reppit-health
/plugin install reppit-health@carainc-reppit-health

Then invoke the full flow against a topic, an issue title, or a Linear ticket.

/reppit add patient-facing appointment reminders with SMS opt-in

The agent will research the existing scheduling and messaging code, propose up to two implementation paths, ask for your choice, write a Linear plan, implement one issue at a time, run the review, and finally run /secure against the resulting diff before anything merges. You get to stop it at any gate.

The principle

A safer healthtech development loop is not achieved by asking the agent to be more careful. It is achieved by giving the agent a workflow where carefulness is structural: shared research before proposals, proposals before plans, plans before code, code before tests, and explicit compliance gates before merge. The model proposes. The workflow disposes.

That is the same architectural instinct behind every other piece of Widal's clinical AI work. Move authority out of natural language and into typed, gated, auditable steps. The difference here is that the audience is the engineers, not the patients. The principle holds.

Source

RePPIT Health is open source at carainc/reppit-health · GitHub · Apache 2.0. The underlying RePPIT methodology is the work of Mihail Eric, head of AI and creator of Stanford's first AI software engineering course, published at themodernsoftware.dev. RePPIT Health adds the Secure phase and the HIPAA, SOC2, and HITRUST checklists.