> ## Documentation Index > Fetch the complete documentation index at: https://docs.keldyn.ai/llms.txt > Use this file to discover all available pages before exploring further. # Stay compliant through the SDLC > Example prompts for using the Keldyn MCP server so your code is control-aligned from the first commit, through design, review, evidence, and release. 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](/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](/responsible-use). ## How to use this guide * **Copy a prompt, fill the placeholders**, then send it to your agent. Replace `` 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 Follow [Keldyn MCP server](/keldyn-mcp-server) and sign in to the team that owns the system you are building. Run the agent from the repo (or monorepo package) that implements the system, so it can read code, diffs, and tests. 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. ```text theme={null} Run the start-dev prompt for use case . 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): ```text theme={null} 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: ```text theme={null} Run start-dev for use case . 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. ```text theme={null} 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): ```text theme={null} Call list-frameworks with scope use_case. Recommend which frameworks belong on use case 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](/frameworks-and-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](/guides/generate-architecture). ```text theme={null} Use the generate-architecture prompt for use case , 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: ```text theme={null} Run analyze-use-case-architecture for use case 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): ```text theme={null} 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. ```text theme={null} Using Keldyn MCP for use case , 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: ```text theme={null} I am adding in . After start-dev for use case , 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: ```text theme={null} 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. ```text theme={null} Run review-changes for use case 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: ```text theme={null} Run review-changes for use case , target "changes vs main". Flag any Implemented control whose prior evidence this branch weakens or removes. ``` ```text theme={null} 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: ```text theme={null} 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](/guides/mcp-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. ```text theme={null} Run review-codebase for use case . 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: ```text theme={null} Run review-codebase for use case , scope apps/api. Prioritize auth, secrets, data handling, and external I/O. ``` Turn the report into tracking (the [controls-to-code](/guides/mcp-controls-to-code) loop): ```text theme={null} Using that review for use case : 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. ```text theme={null} Run collect-evidence for use case 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: ```text theme={null} Run remediate-insufficient-evidence for use case 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](/guides/address-and-evidence-controls). ```text theme={null} For every in-scope AppSec control on use case 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 ```text theme={null} Run review-changes for use case , 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 ```text theme={null} The change for task / control is merged. Update-task to done. Then update-control for use case 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. ```text theme={null} Re-run generate-architecture for use case 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](/guides/resolve-architecture-risks). ```text theme={null} Run analyze-use-case-architecture for use case 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 ```text theme={null} For use case : 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 . 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 , 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 against my current changes.` | | Inherited repo / new framework | `Run review-codebase for use case . Do not update Keldyn until I approve.` | | After implementation lands | `Run collect-evidence for use case and framework "". Wait before update-control.` | | Evidence failed the checker | `Run remediate-insufficient-evidence for use case .` | | 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 Connect your client and see the full tool and prompt catalog. Read controls, analyze the repo, mark what's done, and open tasks for gaps. Implement each code-relevant control and back it with a test plus evidence paths. Infer a Threagile model from the repository and analyze it. Give every CWE a documented disposition: fixed, accepted, or out of scope. What KC is for, what it isn't, and where judgement stays with a person.