Stay compliant through the SDLC

Compliance is cheapest when it is designed in, not bolted on after a finding. This playbook is for developers who already have the Keldyn MCP server connected in Claude Code, Cursor, or another MCP client. Use the prompts below at each stage of the software development lifecycle (SDLC) so your agent writes against your organization’s controls from the first session, then keeps the work aligned as you design, implement, review, and ship.

Every MCP tool call runs as you, scoped to the team you selected at sign-in. Marking a control complete, saving evidence, or recording a risk disposition writes to your live Keldyn workspace. Ask the agent to show its plan before it saves, and keep a person accountable for what ships — see Responsible use.

How to use this guide

Copy a prompt, fill the placeholders, then send it to your agent. Replace <USE_CASE_ID> with a real use case UUID (list-use-cases if you don’t have one). Replace scoped paths (apps/api) with your package or service.
Prefer the built-in MCP prompts (start-dev, review-changes, review-codebase, generate-architecture, collect-evidence, remediate-insufficient-evidence) when they match the job. They load your live controls and standing security rules automatically. The freeform prompts in this guide tell the agent when and how to invoke those workflows.
Do not paste secrets, source dumps, or customer data into prompts that reach Keldyn. The agent should read the repo locally and send only the tool arguments Keldyn needs (ids, status, evidence notes).

Before you start

Connect the MCP server

Follow Keldyn MCP server and sign in to the team that owns the system you are building.

Open the repository

Run the agent from the repo (or monorepo package) that implements the system, so it can read code, diffs, and tests.

Know the use case

Have the use case id ready, or ask the agent to find it. Org-level and use-case tracking are separate — pass useCaseId whenever you mean the use case.

The SDLC at a glance

Phase	Goal	Built-in prompt	Key tools
1. Kick off	Prime the agent so new code is control-aligned	`start-dev`	`list-controls`, `get-control`
2. Register	Put a new system on the books	—	`create-use-case`, `list-frameworks`, `assign-use-case-framework`
3. Design	Model the system and find risks early	`generate-architecture`	`update-use-case-architecture`, `analyze-use-case-architecture`
4. Implement	Build against acceptance criteria	`start-dev`	`list-controls`, `get-control`, `list-tasks`
5. Review	Catch control regressions before you commit	`review-changes`	—
6. Baseline	Audit an existing codebase or package	`review-codebase`	`update-control`, `create-task`
7. Evidence	Record what the code actually does	`collect-evidence`, `remediate-insufficient-evidence`	`update-control`
8. Ship & stay current	Keep model, risks, and controls in sync	`review-changes`, `generate-architecture`	`update-risk-tracking`, `update-task`

1. Kick off — compliant from the first line

start-dev is the pre-development counterpart to the review prompts. It loads each applicable control’s developer guidance (developerPrompt) so the agent treats those rules as standing requirements for the session, instead of discovering them at review time. Run it at the start of every new chat that will write or change code.

Run the start-dev prompt for use case <USE_CASE_ID>.
Acknowledge the controls you ingested, then wait for my task.

Without a use case, start-dev merges org controls plus developer-relevant controls from every team use case (including use-case-only frameworks such as CASA):

Run start-dev with no useCaseId so you load org plus all team
use-case developer guidance. Then help me add rate limiting to
the public API.

Add repo-specific rules (for example the contents of a KELDYN.md) as extra instructions:

Run start-dev for use case <USE_CASE_ID>. Extra instructions:
follow our existing auth middleware patterns in apps/api/src/middleware,
never add a new secrets store, and add or update tests for every
security-sensitive change.

If you skip start-dev and jump straight to implementation, the agent will still can look up controls later — but it is more likely to write a first draft that review then has to unwind. Priming first is the cheapest compliance step in the SDLC.

2. Register a new system

When you are starting a product, service, or AI feature that is not yet a Keldyn use case, create it and assign the frameworks it must satisfy before you generate an architecture or write the first feature.

Using the Keldyn MCP server:
1. Call list-use-cases and tell me if a use case already exists for
   this repository / service.
2. If none does, draft a create-use-case payload from the README and
   code (name, description, AI models if any). Ask me before you save
   anything I cannot derive (risk level, stakeholders, decision types).
3. After I confirm, create the use case.

Then attach the frameworks that apply (SOC 2, ISO 27001, GDPR, CASA, AppSec, and so on):

Call list-frameworks with scope use_case. Recommend which frameworks
belong on use case <USE_CASE_ID> given this repo, then assign the ones
I approve with assign-use-case-framework. Do not assign org-only
frameworks.

Controls only appear after a framework is assigned and scoped. If list-controls comes back empty, check the use case’s frameworks first. See Frameworks & controls.

3. Design — model the system and find issues early

Threat modeling and architecture-based control checks need a saved Threagile model. Infer it from the code (and infrastructure-as-code), then analyze it before you commit to a design that is expensive to unwind. Full walkthrough: Generate an architecture from your codebase.

Use the generate-architecture prompt for use case <USE_CASE_ID>,
scoped to apps/api. Map services, data stores, auth, queues, and
external integrations from the code. Also read infra/ (Terraform)
for trust boundaries and managed stores. Show me the model, then
save it with update-use-case-architecture.

Once it is saved, run analysis:

Run analyze-use-case-architecture for use case <USE_CASE_ID> and
list issues by severity. For each, tell me whether it is a Threagile
security risk or an RCM compliance failure, which asset it hits, and
the proposedEdit.

Work the highest-severity batch first (the tool returns up to 32 issues per call):

For the highest-severity issues from that analysis, propose concrete
architecture edits (do not invent services). After I approve, save
with update-use-case-architecture and re-run analyze-use-case-architecture
to confirm they cleared.

Design-time analysis is not a substitute for code review. Architecture checks catch missing auth on a link or an unencrypted datastore; review-changes catches the implementation that forgot the middleware.

4. Implement — write to the acceptance criteria

Keep start-dev in the session, then pull the specific controls your change will touch. Ask for the full requirement, developer guidance, and acceptance criteria — not just the title.

Using Keldyn MCP for use case <USE_CASE_ID>, list-controls with
relevance code. Group them by theme (auth, encryption, API security,
logging, data-subject rights). Then get-control for every control
in the theme I am about to work on so we have acceptance criteria
before we write code.

For a concrete feature, bind the work to those criteria up front:

I am adding <FEATURE> in <PATH>. After start-dev for use case
<USE_CASE_ID>, identify the controls this change must satisfy.
Implement the feature so those controls hold by construction:
follow each control's developer guidance, add or update tests that
would fail if the control stopped holding, and do not weaken any
control marked Implemented.
Show the plan (controls + files you will touch) before you edit.

If work is already tracked as tasks:

List open tasks for this team (list-tasks), starting with URGENT and
HIGH. For the first one: get-task, get-control for its rcmId, implement
the gap in this repo, add tests, then stop and show me the diff before
you update-task or update-control.

Only mark a control complete when the code (or a dated N/A reason) genuinely meets its acceptance criteria. Infra, policy, and hosting-platform controls usually cannot be closed from application code alone — leave those as tasks or notes, not complete.

5. Review — before you commit or open a PR

review-changes is not a generic code review. It loads each code-relevant control’s PR review criterion and judges only your current diff against those controls — including regressions against prior evidence on controls already marked Implemented. Run it on every meaningful change, before you commit.

Run review-changes for use case <USE_CASE_ID> against my uncommitted
changes. Only report findings tied to a listed control, with file,
line, severity, and a concrete fix. If the diff satisfies every
applicable control, say so plainly.

Scope it to a branch or a path:

Run review-changes for use case <USE_CASE_ID>, target "changes vs
main". Flag any Implemented control whose prior evidence this branch
weakens or removes.

Run review-changes scoped to apps/api. Extra instructions: treat
missing tests for a newly touched auth or crypto path as a finding
if a control requires them.

Then fix and re-run:

Fix the high and critical findings from that review. Keep the change
scoped to the controls that failed. When you are done, run
review-changes again on the new diff and confirm those findings are
gone without regressing Implemented controls.

Once you have a baseline (review-codebase or a completed controls-to-code pass), review-changes is the day-to-day habit. Re-scanning the whole repo on every PR is slower and easier to skip.

6. Baseline an existing codebase

Use review-codebase when you inherit a repo, add a new framework, or want a periodic audit of a package — not for every commit.

Run review-codebase for use case <USE_CASE_ID>. For each control,
say whether the code addresses it, partially addresses it, or does
not. Cite file paths and line ranges. Do not update Keldyn until I
approve.

Scope it in a monorepo:

Run review-codebase for use case <USE_CASE_ID>, scope apps/api.
Prioritize auth, secrets, data handling, and external I/O.

Turn the report into tracking (the controls-to-code loop):

Using that review for use case <USE_CASE_ID>:
1. For fully addressed controls, draft update-control calls with
   status complete and evidenceText that names files and how they
   satisfy the criterion.
2. For partial / failing controls, draft create-task payloads linked
   with rcmId, describing current state, gap, and remediation.
Show the plan. Do not write to Keldyn until I say so.

7. Evidence — prove it, then record it

Positive evidence is what auditors (and future you) will read. collect-evidence scans for proof that code-related controls already hold, then waits for you before saving.

Run collect-evidence for use case <USE_CASE_ID> and framework
"SOC 2", scoped to apps/api. Positive evidence only — cite file
paths. Propose complete only when the control is clearly implemented.
Show the list and wait for me to approve before update-control.

If recorded evidence failed acceptance criteria (status Insufficient Evidence or an open linked finding), remediate it instead of inventing coverage:

Run remediate-insufficient-evidence for use case <USE_CASE_ID>
and framework "SOC 2". For each gap, gather stronger file-backed
evidence that hits every listed acceptance criterion. Show proposed
evidenceText, then save only after I confirm. Do not set status
complete yourself — let the sufficiency engine re-score.

For a deeper implement + test + evidence loop, see Address and evidence controls.

For every in-scope AppSec control on use case <USE_CASE_ID> that is
code-relevant: implement any gap, add a unit or integration test
that would fail if the control stopped holding, and draft evidenceText
that points at implementation path(s) and test path(s). Leave process
and infra controls as dated N/A or defer notes. Show the plan first.

8. Ship and stay current

Compliance is not a one-off gate. After merge and as the system changes, keep three things in sync: the architecture model, risk dispositions, and control evidence.

Before you merge

Run review-changes for use case <USE_CASE_ID>, target "changes vs
main". If anything still fails a control, fix it on this branch.
Do not update Keldyn status from a review — only from confirmed
evidence after merge.

After you ship a control fix

The change for task <TASK_ID> / control <RCM_ID> is merged.
Update-task to done. Then update-control for use case <USE_CASE_ID>
with status complete and evidenceText that cites the merged files
and tests.

After a significant design change

New services, stores, or integrations go stale in the threat model if you do not refresh it.

Re-run generate-architecture for use case <USE_CASE_ID> scoped to
the packages we changed. Diff the new model against what is saved.
Show me what you would add or remove, then save and run
analyze-use-case-architecture.

Disposition every remaining Threagile risk — fixed, accepted (with who/why), or out of scope. Full loop: Resolve architecture risks.

Run analyze-use-case-architecture for use case <USE_CASE_ID> with
source=security. For each open risk, search this repo for real
mitigations before proposing a disposition. Draft update-risk-tracking
payloads (mitigated / accepted / false-positive) with justification.
Do not save accepted or false-positive without my approval.

Periodic hygiene

For use case <USE_CASE_ID>: list-controls (relevance code) that are
still todo or in_progress, and list-tasks that are open and linked
to an rcmId. Propose the next week's work ordered by risk, and call
out any Implemented control whose evidence looks stale relative to
the current code.

Prompt cheatsheet

Copy-paste starters. Fill placeholders; prefer the named MCP prompt when one exists.

When	Prompt
Opening a coding session	`Run start-dev for use case <USE_CASE_ID>. Acknowledge the controls, then wait.`
New system	`Create a use case from this repo (ask before saving unknowns), then assign the frameworks I approve.`
First threat model	`Run generate-architecture for use case <USE_CASE_ID>, then analyze-use-case-architecture.`
Starting a feature	`After start-dev, get-control for the controls this feature must satisfy. Implement so they hold by construction, with tests.`
Before commit / PR	`Run review-changes for use case <USE_CASE_ID> against my current changes.`
Inherited repo / new framework	`Run review-codebase for use case <USE_CASE_ID>. Do not update Keldyn until I approve.`
After implementation lands	`Run collect-evidence for use case <USE_CASE_ID> and framework "<NAME>". Wait before update-control.`
Evidence failed the checker	`Run remediate-insufficient-evidence for use case <USE_CASE_ID>.`
Architecture drifted	`Re-run generate-architecture for the packages we changed, then analyze and disposition risks.`

Ground rules while you work

Controls over convenience. If guidance conflicts with a request, the agent should surface the tension and prefer the control-compliant option.
File-backed evidence only. Paths and short “how” notes beat “we do encryption.”
No silent N/A. If a control is out of scope, record a dated reason (ignored / Not Applicable) instead of leaving it Pending Review.
Human approval on writes. Status, evidence, risk acceptance, and Trust Center changes need a person to confirm.
Do not weaken a control to make a feature easier without an explicit, recorded decision.

Next steps

Keldyn MCP server

Connect your client and see the full tool and prompt catalog.

From controls to code

Read controls, analyze the repo, mark what’s done, and open tasks for gaps.

Address & evidence controls

Implement each code-relevant control and back it with a test plus evidence paths.

Architecture from code

Infer a Threagile model from the repository and analyze it.

Resolve architecture risks

Give every CWE a documented disposition: fixed, accepted, or out of scope.

Responsible use

What KC is for, what it isn’t, and where judgement stays with a person.

Home

Getting started

Integrations

AI Tooling

Guides

Security & compliance

Stay compliant through the SDLC

How to use this guide

Before you start

The SDLC at a glance

1. Kick off — compliant from the first line

2. Register a new system

3. Design — model the system and find issues early

4. Implement — write to the acceptance criteria

5. Review — before you commit or open a PR

6. Baseline an existing codebase

7. Evidence — prove it, then record it

8. Ship and stay current

Before you merge

After you ship a control fix

After a significant design change

Periodic hygiene

Prompt cheatsheet

Ground rules while you work

Next steps

Keldyn MCP server

From controls to code

Address & evidence controls

Architecture from code

Resolve architecture risks

Responsible use

​How to use this guide

​Before you start

​The SDLC at a glance

​1. Kick off — compliant from the first line

​2. Register a new system

​3. Design — model the system and find issues early

​4. Implement — write to the acceptance criteria

​5. Review — before you commit or open a PR

​6. Baseline an existing codebase

​7. Evidence — prove it, then record it

​8. Ship and stay current

​Before you merge

​After you ship a control fix

​After a significant design change

​Periodic hygiene

​Prompt cheatsheet

​Ground rules while you work

​Next steps

Keldyn MCP server

From controls to code

Address & evidence controls

Architecture from code

Resolve architecture risks

Responsible use

How to use this guide

Before you start

The SDLC at a glance

1. Kick off — compliant from the first line

2. Register a new system

3. Design — model the system and find issues early

4. Implement — write to the acceptance criteria

5. Review — before you commit or open a PR

6. Baseline an existing codebase

7. Evidence — prove it, then record it

8. Ship and stay current

Before you merge

After you ship a control fix

After a significant design change

Periodic hygiene

Prompt cheatsheet

Ground rules while you work

Next steps