@securityreviewai/securityreview-kit 0.1.30 → 0.1.32

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.30",
+  "version": "0.1.32",
   "description": "Bootstrap security-review-mcp for AI IDEs and CLI tools",
   "author": "Debarshi Das <debarshi.das@we45.com>",
   "license": "UNLICENSED",

package/src/commands/init.js

@@ -3,7 +3,7 @@ import { input, checkbox, confirm, select } from '@inquirer/prompts';
 import { TARGETS, TARGET_NAMES } from '../utils/constants.js';
 import { detectTargets } from '../utils/detect.js';
 import { ensureIdeClisForTargets } from '../utils/ide-cli-install.js';
-import { writeGuardrailsProfilerBundles } from '../utils/guardrails-profiler-bundle.js';
+import { writeGuardrailsSkillBundles } from '../utils/guardrails-profiler-bundle.js';
 import {
     pickProfilerAgentTarget,
     runCursorAgentLogin,
@@ -352,23 +352,23 @@ export async function initCommand(options) {
 
     if (installRules) {
         try {
-            const bundlePaths = writeGuardrailsProfilerBundles(cwd, {
+            const bundlePaths = writeGuardrailsSkillBundles(cwd, {
                 projectName: projectNameForSkill,
                 targets,
             });
             if (bundlePaths.length === 0) {
                 console.log(
                     chalk.dim(
-                        '    (Guardrails profiler skill is only written for Cursor, Claude Code, and Codex targets.)',
+                        '    (Guardrails skills are only written for Cursor, Claude Code, and Codex targets.)',
                     ),
                 );
             }
             for (const bundlePath of bundlePaths) {
-                console.log(chalk.green(`    \u2713 Guardrails profiler skill \u2192 ${bundlePath}`));
+                console.log(chalk.green(`    \u2713 Guardrails skill bundle \u2192 ${bundlePath}`));
                 results.push({ target: 'kit', type: 'bundle', status: 'ok', path: bundlePath });
             }
         } catch (err) {
-            console.log(chalk.red(`    \u2717 Guardrails profiler skill failed: ${err.message}`));
+            console.log(chalk.red(`    \u2717 Guardrails skill bundle failed: ${err.message}`));
             results.push({ target: 'kit', type: 'bundle', status: 'error', error: err.message });
         }
     }

package/src/generators/rules/claude.js

@@ -1,5 +1,5 @@
 import { join } from 'node:path';
-import { GUARDRAILS_PROFILER_SKILL_REL_DIR } from '../../utils/constants.js';
+import { GUARDRAILS_PROFILER_SKILL_REL_DIR, GUARDRAILS_SELECTION_SKILL_REL_DIR } from '../../utils/constants.js';
 import { upsertSentinelBlock, writeText } from '../../utils/fs-helpers.js';
 import { getRuleContent, getGuardrailsInitProfileContent } from './content.js';
 
@@ -8,7 +8,10 @@ import { getRuleContent, getGuardrailsInitProfileContent } from './content.js';
  */
 export function generate(cwd, options = {}) {
     const filePath = join(cwd, 'CLAUDE.md');
-    const content = getRuleContent(options);
+    const content = getRuleContent({
+        ...options,
+        guardrailsSelectionSkillDir: GUARDRAILS_SELECTION_SKILL_REL_DIR.claude,
+    });
     const action = upsertSentinelBlock(filePath, content);
 
     const guardrailsInitPath = join(cwd, '.claude', 'commands', 'guardrails-init-profile.md');

package/src/generators/rules/codex.js

@@ -1,5 +1,5 @@
 import { join } from 'node:path';
-import { GUARDRAILS_PROFILER_SKILL_REL_DIR } from '../../utils/constants.js';
+import { GUARDRAILS_PROFILER_SKILL_REL_DIR, GUARDRAILS_SELECTION_SKILL_REL_DIR } from '../../utils/constants.js';
 import { upsertSentinelBlock, writeText } from '../../utils/fs-helpers.js';
 import { getRuleContent, getGuardrailsInitProfileContent } from './content.js';
 
@@ -8,7 +8,10 @@ import { getRuleContent, getGuardrailsInitProfileContent } from './content.js';
  */
 export function generate(cwd, options = {}) {
     const filePath = join(cwd, 'AGENTS.md');
-    const content = getRuleContent(options);
+    const content = getRuleContent({
+        ...options,
+        guardrailsSelectionSkillDir: GUARDRAILS_SELECTION_SKILL_REL_DIR.codex,
+    });
     const action = upsertSentinelBlock(filePath, content);
 
     const guardrailsInitPath = join(cwd, '.codex', 'commands', 'guardrails-init-profile.md');

package/src/generators/rules/content.js

@@ -8,6 +8,17 @@ function sanitizeProjectName(value) {
     return value.replace(/[\r\n`]/g, ' ').trim();
 }
 
+function injectPathPlaceholder(content, placeholder, fallbackPath, configuredPath) {
+    if (!content.includes(placeholder)) {
+        return content;
+    }
+
+    const resolvedPath =
+        typeof configuredPath === 'string' && configuredPath.trim() ? configuredPath.trim() : fallbackPath;
+
+    return content.replaceAll(placeholder, resolvedPath);
+}
+
 /**
  * Reads a markdown template and injects the configured project name placeholder.
  */
@@ -21,13 +32,18 @@ function readTemplate(templateFileName, options = {}) {
         .replaceAll('{{SRAI_PROJECT_NAME}}', resolvedProjectName)
         .replaceAll('<SRAI_PROJECT_NAME>', resolvedProjectName);
 
-    if (out.includes('{{GUARDRAILS_SKILL_DIR}}')) {
-        const skillDir =
-            typeof options.guardrailsSkillDir === 'string' && options.guardrailsSkillDir.trim()
-                ? options.guardrailsSkillDir.trim()
-                : '.cursor/skills/guardrails-profiler';
-        out = out.replaceAll('{{GUARDRAILS_SKILL_DIR}}', skillDir);
-    }
+    out = injectPathPlaceholder(
+        out,
+        '{{GUARDRAILS_SKILL_DIR}}',
+        '.cursor/skills/guardrails-profiler',
+        options.guardrailsSkillDir,
+    );
+    out = injectPathPlaceholder(
+        out,
+        '{{GUARDRAILS_SELECTION_SKILL_DIR}}',
+        '.cursor/skills/guardrails-selection',
+        options.guardrailsSelectionSkillDir,
+    );
 
     return out;
 }

package/src/generators/rules/content.md

@@ -3,6 +3,8 @@
 **THIS RULE IS NON-NEGOTIABLE AND TRIGGERED BEFORE YOU EVEN START THINKING.** You MUST think security-first and perform on-the-go threat modeling using the PWNISMS framework BEFORE and DURING every task whether it's TODO or PLAN or codegen. This is not optional. This is not deferred to a later review. Every line of code you write must be informed by threat awareness.
 
 > **Skill Reference:** Read and apply `.cursor/skills/threat-modelling/SKILL.md` for the full PWNISMS framework — the 7 threat categories, code generation rules, and post-generation checklist. You MUST walk through all 7 categories for every code task that seems security relevant.
+>
+> **Guardrail Selection Skill:** In IDEs that support workspace skills, read and apply `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` when fetching guardrails. In other IDEs, follow that same workflow explicitly: analyze the task, shortlist relevant guardrails, and hydrate the exact shortlist with `get_guardrail_by_id`.
 
 ### When NOT to apply
 
@@ -26,7 +28,7 @@ If in doubt, do a quick mental scan: *does this change touch auth, input handlin
 This workflow enforces security through two complementary pillars:
 
 1. **Secure by Design (PWNISMS)** — Universal threat-category analysis applied to every security-relevant task. Identifies risks and drives architectural/design-level mitigations.
-2. **Secure by Code (Vibe Guardrails)** — Project-specific coding dos and don'ts fetched from SRAI via `get_guardrails`. Enforces concrete implementation rules derived from prior threat reviews, compliance requirements, and team decisions.
+2. **Secure by Code (Vibe Guardrails)** — Project-specific coding dos and don'ts fetched from SRAI via `get_guardrails`, shortlisted intentionally, and then hydrated via `get_guardrail_by_id`. Enforces concrete implementation rules derived from prior threat reviews, compliance requirements, and team decisions.
 
 Both pillars are **mandatory** for any code-generation task with a security surface. PWNISMS catches broad threats; guardrails enforce project-specific coding standards.
 
@@ -78,10 +80,12 @@ Rather than fetching the entire profile at once, walk through each reasoning blo
    - For each requirement relevant to the task, call `get_profile_compliance_requirement` for full details.
    - Map these to security objectives and ensure your implementation meets them.
 
-10. **Fetch Vibe Guardrails** — Call `get_guardrails` with `project_id`.
-    - Load all project-specific coding guardrails (dos and don'ts).
-    - Separate into `must` (mandatory requirements) and `must_not` (hard prohibitions).
-    - Keep these in context for the entire code-generation task.
+10. **Fetch Vibe Guardrails** — Follow `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
+    - Call `get_guardrails` with `project_id` to load the broad catalog.
+    - Analyze the task and infer the relevant security categories and likely threats first.
+    - Shortlist only the guardrails relevant to the task and fetch the exact shortlist with `get_guardrail_by_id`.
+    - Separate the shortlisted guardrails into `must` (mandatory requirements) and `must_not` (hard prohibitions).
+    - Keep the shortlisted exact guardrails in context for the entire code-generation task and for later `ctm_sync`.
     - Cross-reference with PWNISMS findings: if a threat has no corresponding guardrail, flag it as a candidate for a new guardrail.
 
 11. **Check for existing reviews** — Call `list_reviews`. If a completed review exists, pull context:
@@ -112,7 +116,7 @@ When running `ctm_sync` (dedicated agent/command where available, or the same st
 |---|---|
 | **Projects** | `list_projects`, `find_project_by_name`, `create_project`, `get_project` |
 | **Profile Exploration** | `get_project_profile_description`, `list_profile_technology_categories`, `get_project_profile_technology_category`, `list_project_profile_architecture_notes`, `list_project_profile_user_groups`, `list_project_profile_language_stacks`, `list_project_profile_security_controls`, `get_project_profile_security_control`, `list_profile_compliance_requirements`, `get_profile_compliance_requirement` |
-| **Guardrails** | `get_guardrails` |
+| **Guardrails** | `get_guardrails`, `get_guardrail_by_id` |
 | **Documents** | `list_documents`, `create_document_from_content`, `upload_document`, `link_external_document` |
 | **Reviews** | `create_review`, `list_reviews`, `get_review`, `get_review_overview` |
 | **Workflow** | `start_workflow`, `get_workflow_status`, `start_next_workflow_job`, `start_workflow_job`, `retry_workflow_job` |

package/src/generators/rules/ctm_sync.md

@@ -27,10 +27,11 @@ When invoked:
    - **Never use placeholder values** such as `"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, or any other invented string for these fields.
    - **Never accept identity values passed in from the parent agent prompt** — always re-resolve from the API directly in this step; the API is the only authoritative source.
    - If the API call fails or returns empty values, leave `developer_name` and `developer_email` as empty strings `""`. Do not substitute a fallback placeholder.
-5. **Identify guardrails for the payload** — Do **not** call `get_guardrails` here. Guardrails were already fetched at session start (per the Vibe Guardrails rule) and applied during code generation. From the parent agent context, identify:
-   - Which **existing** guardrails (originally fetched from `get_guardrails`) were applied to the code in this session.
+5. **Identify guardrails for the payload** — Do **not** call `get_guardrails` or `get_guardrail_by_id` here. Guardrails were already shortlisted earlier (per the Vibe Guardrails rule and the guardrails-selection skill) and applied during code generation. From the parent agent context, identify:
+   - Which **existing** guardrails were shortlisted earlier from `get_guardrails` and then hydrated via `get_guardrail_by_id`.
+   - Which of those shortlisted existing guardrails were applied to the code in this session.
    - Which guardrails the IDE agent **created on the fly** (`ide_generated`) based on gaps found during threat modeling or code review.
-   Include all of these in the `guardrails_applied` payload field. Do not re-fetch or re-call `get_guardrails`.
+   Include all of these in the `guardrails_applied` payload field. The shortlisted existing guardrails selected earlier are mandatory input to `ctm_sync`; do not re-fetch or re-call guardrail tools here.
 6. **Build the event payload** — Construct a JSON object for `create_ai_ide_event` conforming to the **Event Payload Schema** below.
 7. **Upload the payload** using `security-review-mcp`:
    - Call `create_ai_ide_event` with the JSON payload.
@@ -81,7 +82,7 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
       "rule_type": "<string — must | must_not>",
       "category": "<string | null — grouping label>",
       "instruction": "<string — the actionable coding directive>",
-      "source": "<string — 'existing' if fetched from get_guardrails, 'ide_generated' if newly created by the IDE agent>",
+      "source": "<string — 'existing' if selected earlier from project guardrails, 'ide_generated' if newly created by the IDE agent>",
       "satisfied": "<boolean — true if the guardrail was fully satisfied, false if partially or not satisfied>",
       "notes": "<string — optional: how it was applied, why it could not be fully satisfied, or rationale for a new guardrail>"
     }
@@ -108,7 +109,7 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
 | `threats_mitigated` | Yes | Array, may be empty `[]` if no threats were identified. Each entry must include a `code_snippet` grounded in actual source code |
 | `best_practises_achieved` | Yes | Array of strings, may be empty `[]` |
 | `secure_code_snippets` | Yes | Array, may be empty `[]` |
-| `guardrails_applied` | Yes | Array of all guardrails enforced during this session — both existing ones from `get_guardrails` and new ones the IDE agent created. Use `source` to distinguish origin. Empty `[]` if none |
+| `guardrails_applied` | Yes | Array of all guardrails enforced during this session — both existing ones shortlisted earlier from project guardrails and new ones the IDE agent created. Use `source` to distinguish origin. Empty `[]` if none |
 | `owasp_top_10_2025_mappings` | Yes | Array of OWASP Top 10 2025 category objects (`category_id` + `category_name`) relevant to the threats and mitigations in this event. May be empty `[]` if no mapping applies |
 
 ### OWASP Top 10 2025 Reference
@@ -133,7 +134,8 @@ Use the following IDs and names exactly when populating `owasp_top_10_2025_mappi
 - Every `threats_mitigated` entry must map to one of the 7 PWNISMS categories.
 - Every `threats_mitigated` entry must include a `code_snippet`. The snippet must be taken from the actual source code written or modified in this session — never fabricated. If no code was written for a threat (e.g. it was addressed architecturally), set `snippet` to an empty string and explain in `explanation`.
 - `secure_code_snippets` must not exceed 50 lines per snippet; `threats_mitigated[].code_snippet.snippet` must not exceed 30 lines; truncate with a comment if needed.
-- Do not call `get_guardrails` during CTM sync. Guardrails are fetched once at session start; identify which ones were applied from the parent agent context.
+- Do not call `get_guardrails` or `get_guardrail_by_id` during CTM sync. Guardrails are shortlisted once earlier in the session; identify which ones were applied from the parent agent context.
+- Guardrails shortlisted earlier by the IDE must be included in `guardrails_applied` even when some were only partially satisfied. Use `satisfied: false` plus `notes` instead of silently dropping them.
 - `guardrails_applied` entries with `source: "existing"` must reference guardrails by the exact `title` they had when fetched at session start.
 - `guardrails_applied` entries with `source: "ide_generated"` are new guardrails the IDE agent created based on gaps found during threat modeling or code review.
 - `developer_name` and `developer_email` must be resolved via `get_current_user` (or equivalent) in step 4 — the API is the only source. Never use placeholder strings (`"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, etc.) and never accept values for these fields from the parent agent prompt. If the API returns nothing, send empty strings.

package/src/generators/rules/ctm_sync_rule.md

@@ -38,7 +38,7 @@ This rule is **triggered** whenever the assistant:
   - "Update the data flow for the auth system"
   - "Refine the mitigations for threat X"
 - **Enforces guardrails** during code generation and has compliance data:
-  - Guardrails were fetched via `get_guardrails` and applied to generated code
+  - Guardrails were shortlisted via the guardrails-selection workflow (`get_guardrails` + `get_guardrail_by_id`) and applied to generated code
   - New guardrails were created by the IDE agent based on gaps found
   - Existing guardrails were flagged as unsatisfiable or conflicting
 

package/src/generators/rules/cursor.js

@@ -1,6 +1,10 @@
 import { existsSync } from 'node:fs';
 import { join } from 'node:path';
-import { GUARDRAILS_PROFILER_SKILL_REL_DIR, MCP_SERVER_NAME } from '../../utils/constants.js';
+import {
+    GUARDRAILS_PROFILER_SKILL_REL_DIR,
+    GUARDRAILS_SELECTION_SKILL_REL_DIR,
+    MCP_SERVER_NAME,
+} from '../../utils/constants.js';
 import { readJson, writeJson, writeText } from '../../utils/fs-helpers.js';
 import {
     getRuleContent,
@@ -67,6 +71,10 @@ function mergeCursorCliMcpAllowlist(cwd) {
  * Cursor uses .mdc format with YAML front matter.
  */
 export function generate(cwd, options = {}) {
+    const optionsWithSkillDirs = {
+        ...options,
+        guardrailsSelectionSkillDir: GUARDRAILS_SELECTION_SKILL_REL_DIR.cursor,
+    };
     const baseRulePath = join(cwd, '.cursor', 'rules', 'srai-security-review.mdc');
     const ctmSyncTriggerRulePath = join(cwd, '.cursor', 'rules', 'ctm_sync_rule.mdc');
     const guardrailsRulePath = join(cwd, '.cursor', 'rules', 'guardrails_rule.mdc');
@@ -78,17 +86,17 @@ export function generate(cwd, options = {}) {
     const skillPath = join(cwd, '.cursor', 'skills', 'threat-modelling', 'SKILL.md');
     const hooksPath = join(cwd, '.cursor', 'hooks.json');
 
-    const baseRuleContent = getRuleContent(options);
-    const ctmSyncTriggerRuleContent = getCtmSyncTriggerRuleContent(options);
-    const guardrailsRuleContent = getGuardrailsRuleContent(options);
-    const ctmSyncWorkflowContent = getCtmSyncWorkflowContent(options);
-    const createIdeWorkflowCommandContent = getCreateIdeWorkflowCommandContent(options);
-    const profileCommandContent = getProfileCommandContent(options);
+    const baseRuleContent = getRuleContent(optionsWithSkillDirs);
+    const ctmSyncTriggerRuleContent = getCtmSyncTriggerRuleContent(optionsWithSkillDirs);
+    const guardrailsRuleContent = getGuardrailsRuleContent(optionsWithSkillDirs);
+    const ctmSyncWorkflowContent = getCtmSyncWorkflowContent(optionsWithSkillDirs);
+    const createIdeWorkflowCommandContent = getCreateIdeWorkflowCommandContent(optionsWithSkillDirs);
+    const profileCommandContent = getProfileCommandContent(optionsWithSkillDirs);
     const guardrailsInitProfileCommandContent = getGuardrailsInitProfileContent({
-        ...options,
+        ...optionsWithSkillDirs,
         guardrailsSkillDir: GUARDRAILS_PROFILER_SKILL_REL_DIR.cursor,
     });
-    const skillContent = getThreatModellingSkillContent(options);
+    const skillContent = getThreatModellingSkillContent(optionsWithSkillDirs);
 
     const baseRule = writeCursorRule(
         baseRulePath,

package/src/generators/rules/guardrails-selection/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: guardrails-selection
+description: Analyze the developer request, infer the security categories and likely threats involved, shortlist the most relevant project guardrails, then hydrate the exact guardrails with get_guardrail_by_id before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for CTM sync.
+---
+
+# Guardrails Selection
+
+Configured SRAI project name: `<SRAI_PROJECT_NAME>`
+
+Use this skill whenever code will be created or modified and the task has any security surface.
+
+This skill exists to stop the IDE from treating the full `get_guardrails` result as an unstructured blob. The workflow is:
+
+1. Understand the request deeply.
+2. Infer which security categories are in play.
+3. Predict the threats that might occur for this exact task.
+4. Shortlist only the guardrails that mitigate those threats.
+5. Fetch the exact shortlisted guardrails with `get_guardrail_by_id`.
+6. Carry that same shortlist forward into implementation and `ctm_sync`.
+
+Do not skip the analysis step. Do not rely on title-matching alone. Do not dump every guardrail into the final answer.
+
+## Inputs You Must Analyze First
+
+Before calling `get_guardrails`, extract the actual development intent from the prompt and surrounding code:
+
+- What is being built, changed, fixed, or refactored?
+- Which components are affected: API, UI, background jobs, auth flow, webhook, file upload, admin tooling, AI agent flow, infra code, data pipeline?
+- Which trust boundaries are crossed?
+- Which sensitive assets are touched: tokens, credentials, sessions, PII, tenancy boundaries, audit logs, secrets, internal APIs, signed URLs, payment state, workflow approvals?
+- Which technologies and patterns are involved in the existing code?
+- What abuse cases are plausible if this change is implemented poorly?
+
+You are not only selecting guardrails for the obvious functionality. You are selecting guardrails for the threats that might materialize around that functionality.
+
+## Category Inference Workflow
+
+Derive a category set for the task before shortlisting guardrails. Common categories include:
+
+- `authentication`
+- `authorization`
+- `session_management`
+- `input_validation`
+- `output_encoding`
+- `secrets`
+- `cryptography`
+- `logging`
+- `monitoring`
+- `file_uploads`
+- `deserialization`
+- `data_access`
+- `rate_limiting`
+- `network`
+- `client_side`
+- `business_logic`
+- `tenant_isolation`
+- `admin_workflows`
+
+Use both the user request and the codebase patterns to infer the category set. A task can involve multiple categories even if the prompt mentions only one feature.
+
+Examples:
+
+- “Add magic-link login” likely involves `authentication`, `session_management`, `cryptography`, `logging`, `rate_limiting`, and `client_side`.
+- “Add org admin API to update member roles” likely involves `authorization`, `tenant_isolation`, `logging`, `business_logic`, and `data_access`.
+- “Add CSV import” likely involves `input_validation`, `file_uploads`, `data_access`, `deserialization`, `logging`, and denial-of-service protections.
+- “Add client-side token refresh” likely involves `authentication`, `session_management`, `client_side`, `logging`, and `cryptography`.
+
+## Threat Mapping Requirement
+
+After identifying categories, infer the threat families that might occur. Use the reference file at `{{GUARDRAILS_SELECTION_SKILL_DIR}}/references/category-threat-map.md` every time you need to reason about category-to-threat mapping.
+
+Your goal is not to enumerate every possible weakness. Your goal is to pick the threats that should influence guardrail selection for this task.
+
+At minimum, consider whether the task can create:
+
+- authentication bypass
+- authorization bypass
+- privilege escalation
+- information disclosure
+- repudiation gaps
+- denial of service
+- unsafe client-side trust
+- insecure logging or audit gaps
+- injection-triggered security failures
+- serialization-triggered security failures
+- business-logic-triggered bypasses
+
+The shortlist should be threat-led, not catalog-led.
+
+## Guardrail Selection Procedure
+
+### Step 1: Resolve the project and load the catalog
+
+1. Call `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
+2. Call `get_guardrails` with `project_id`.
+
+Treat `get_guardrails` as the broad catalog. Do not treat it as the final set of instructions.
+
+Assume each returned guardrail includes the fields needed for selection, including a stable identifier for follow-up retrieval, plus:
+
+- `title`
+- `rule_type`
+- `category`
+- `instruction`
+
+If an identifier is absent, fall back to the best available stable reference exposed by the tool, but prefer the real guardrail id whenever available.
+
+### Step 2: Build a shortlist
+
+Shortlist guardrails using all of the following:
+
+- direct category match with the task
+- mitigation value against the likely threats you inferred
+- relevance to the technologies and code paths being touched
+- support for adjacent controls that prevent bypass chains
+- duplication removal
+
+Do not select a guardrail only because it sounds generally useful. Select it because it materially constrains the risky part of the current task.
+
+Examples:
+
+- If the task touches login, token issuance, password reset, session refresh, or identity proofing, prioritize authentication, session, crypto, logging, and brute-force defense guardrails.
+- If the task changes role checks, tenant scoping, admin APIs, resource ownership, or query filters, prioritize authorization, tenant isolation, data access, business-logic, and audit guardrails.
+- If the task introduces parsing, uploads, template expansion, or object hydration, prioritize input validation, file handling, deserialization, and denial-of-service guardrails.
+- If the task moves security decisions into the browser or mobile client, prioritize client-side trust, token storage, server-side revalidation, and privilege-boundary guardrails.
+
+### Step 3: Hydrate exact shortlisted guardrails
+
+For every shortlisted existing guardrail, call `get_guardrail_by_id` to retrieve the exact guardrail that will govern implementation.
+
+- Use `get_guardrail_by_id` for the shortlisted ids only.
+- If the tool supports batching, batch the shortlisted ids.
+- If the tool only supports one id at a time, call it once per shortlisted id.
+
+Implementation must be driven by the hydrated shortlist from `get_guardrail_by_id`, not by vague memory from the broad catalog listing.
+
+### Step 4: Track the active shortlist in context
+
+Maintain an explicit in-context list of the shortlisted existing guardrails that will govern the task. For each shortlisted existing guardrail, keep:
+
+- `id`
+- `title`
+- `rule_type`
+- `category`
+- `instruction`
+- `why_selected`
+
+Also track any new guardrails created during the task as `ide_generated`.
+
+This shortlist is the source of truth for the rest of the session.
+
+## Implementation Rules
+
+Once the shortlist is hydrated:
+
+- Every applicable `must` guardrail is mandatory.
+- Every applicable `must_not` guardrail is a hard prohibition.
+- If two shortlisted guardrails appear to conflict, explain the conflict and resolve it before coding.
+- If the task reveals a real gap not covered by the shortlisted existing guardrails, create an `ide_generated` guardrail and apply it immediately.
+
+When deciding whether a guardrail applies, prefer security-preserving inclusion over risky omission. If it plausibly mitigates a realistic path to abuse for the current task, keep it in scope.
+
+## CTM Sync Handoff Contract
+
+`ctm_sync` must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrail_by_id` again.
+
+Before `ctm_sync` is invoked, ensure the parent context clearly contains:
+
+- the exact existing guardrails shortlisted earlier
+- which of them were applied
+- whether each one was satisfied
+- any notes about partial compliance, conflicts, or rationale
+- every `ide_generated` guardrail created during the task
+
+If a guardrail was shortlisted but not fully satisfied, still include it in the handoff with `satisfied: false` and a note. Do not silently drop it.
+
+## Selection Quality Bar
+
+A good selection does all of the following:
+
+- covers the feature’s real threat surface, not just its visible functionality
+- captures adjacent controls that stop bypass chains
+- avoids irrelevant noise
+- produces a small, defensible set of guardrails that can actually guide implementation
+- leaves `ctm_sync` with an exact list of what the IDE selected and enforced
+
+If your shortlist feels generic, it is probably incomplete or over-broad. Re-check the prompt, the code patterns, and the threat map.

package/src/generators/rules/guardrails-selection/references/category-threat-map.md

@@ -0,0 +1,232 @@
+# Guardrail Selection Threat Map
+
+Use this file when deciding which guardrail categories apply to the current task and which threat families should influence the shortlist.
+
+The intent is not to produce a full threat model here. The intent is to make sure likely exploit paths influence which guardrails are fetched by id and enforced during implementation.
+
+## How to use this map
+
+1. Start from the feature or code change.
+2. Infer the categories involved in the implementation.
+3. Use the mappings below to identify likely threat families.
+4. Shortlist guardrails that directly or adjacently mitigate those threats.
+5. Fetch those guardrails with `get_guardrail_by_id`.
+
+## STRIDE-style mappings for guardrail selection
+
+### Spoofing
+
+Usually maps to authentication and session-related controls.
+
+Threat patterns to consider:
+
+- identity-related attacks
+- session and token attacks
+- business-logic attacks leading to authentication bypass
+- injection attacks leading to authentication bypass
+- serialization attacks leading to authentication bypass
+- cryptographic attacks leading to authentication bypass
+- lapses in logging leading to authentication bypass
+- client-side trust leading to authentication bypass
+
+Categories commonly shortlisted:
+
+- `authentication`
+- `session_management`
+- `cryptography`
+- `logging`
+- `client_side`
+- `business_logic`
+- `input_validation`
+- `deserialization`
+
+### Tampering
+
+Usually maps to authorization, integrity, and unsafe state change controls.
+
+Threat patterns to consider:
+
+- broken object level access control patterns
+- broken functional level access control patterns
+- injection-driven authorization bypass
+- serialization-driven authorization bypass
+- business-logic-driven authorization bypass
+- client-side trust leading to unauthorized state changes
+
+Categories commonly shortlisted:
+
+- `authorization`
+- `tenant_isolation`
+- `data_access`
+- `business_logic`
+- `logging`
+- `input_validation`
+- `deserialization`
+- `client_side`
+
+### Repudiation
+
+Usually appears when spoofing and tampering are possible but the system cannot prove what happened.
+
+Threat patterns to consider:
+
+- weak or missing audit trails for auth and authorization decisions
+- missing actor attribution on sensitive state changes
+- mutable or incomplete event records
+- inability to correlate session, actor, and resource changes
+
+Categories commonly shortlisted:
+
+- `logging`
+- `monitoring`
+- `authentication`
+- `authorization`
+- `admin_workflows`
+
+### Information Disclosure
+
+Usually maps to authorization, data exposure, logging, and unsafe client-side trust.
+
+Threat patterns to consider:
+
+- broken object level access control patterns
+- broken functional level access control patterns
+- injection-driven information disclosure
+- serialization-driven information disclosure
+- business-logic-driven information disclosure
+- lapses in logging leading to disclosure
+- client-side trust causing exposure of protected data
+
+Categories commonly shortlisted:
+
+- `authorization`
+- `tenant_isolation`
+- `data_access`
+- `logging`
+- `input_validation`
+- `deserialization`
+- `client_side`
+- `output_encoding`
+
+### Denial of Service
+
+Usually maps to workload protection, parsing safety, quota controls, and expensive query behavior.
+
+Threat patterns to consider:
+
+- broken access control patterns that expose heavy operations
+- injection or data-access paths that amplify resource consumption
+- serialization-driven memory or parser exhaustion
+- business-logic-driven abuse of expensive workflows
+- logging lapses that hide repeated abuse
+
+Categories commonly shortlisted:
+
+- `rate_limiting`
+- `input_validation`
+- `file_uploads`
+- `deserialization`
+- `data_access`
+- `network`
+- `monitoring`
+- `logging`
+- `business_logic`
+
+### Elevation of Privilege
+
+Usually maps to authorization, role boundaries, trust decisions, and privileged workflow controls.
+
+Threat patterns to consider:
+
+- access control bypasses from broken object or function level access
+- injection-based privilege escalation
+- client-side induced privilege escalation
+- serialization-induced privilege escalation
+- business-logic-triggered privilege escalation
+- logging lapses that conceal privilege abuse
+
+Categories commonly shortlisted:
+
+- `authorization`
+- `tenant_isolation`
+- `admin_workflows`
+- `business_logic`
+- `client_side`
+- `input_validation`
+- `deserialization`
+- `logging`
+
+## Fast examples
+
+### Add password reset flow
+
+Likely categories:
+
+- `authentication`
+- `session_management`
+- `cryptography`
+- `logging`
+- `rate_limiting`
+
+Likely threat families:
+
+- spoofing
+- repudiation
+- information disclosure
+
+### Add admin endpoint to change user role
+
+Likely categories:
+
+- `authorization`
+- `tenant_isolation`
+- `admin_workflows`
+- `logging`
+- `business_logic`
+
+Likely threat families:
+
+- tampering
+- repudiation
+- elevation of privilege
+- information disclosure
+
+### Add bulk import endpoint
+
+Likely categories:
+
+- `input_validation`
+- `file_uploads`
+- `deserialization`
+- `data_access`
+- `logging`
+- `rate_limiting`
+
+Likely threat families:
+
+- tampering
+- information disclosure
+- denial of service
+
+### Move entitlement checks to the frontend
+
+Likely categories:
+
+- `authorization`
+- `client_side`
+- `tenant_isolation`
+- `logging`
+
+Likely threat families:
+
+- tampering
+- information disclosure
+- elevation of privilege
+
+## Selection reminders
+
+- A feature can require guardrails from multiple categories.
+- Shortlist for exploit chains, not isolated weaknesses.
+- Logging often matters because poor auditability can turn spoofing, tampering, or privilege abuse into repudiation.
+- Client-side logic often needs server-side guardrails even if the visible change is in the UI.
+- If no existing guardrail covers a realistic recurring threat, create an `ide_generated` guardrail and carry it into `ctm_sync`.

package/src/generators/rules/guardrails_rule.md

@@ -1,13 +1,8 @@
----
-description: Vibe Guardrails — fetch and enforce project-specific secure coding guardrails from SRAI
-alwaysApply: true
----
-
 # Vibe Guardrails — Secure by Code
 
 **Enforce project-specific security guardrails during every code-generation task.**
 
-This rule complements the PWNISMS threat model ("secure by design") with concrete, project-level coding dos and don'ts ("secure by code"). Guardrails are maintained in SRAI and fetched via the `security-review-mcp` MCP tool `get_guardrails`.
+This rule complements the PWNISMS threat model ("secure by design") with concrete, project-level coding dos and don'ts ("secure by code"). Guardrails are maintained in SRAI and fetched via `security-review-mcp`.
 
 ---
 
@@ -28,21 +23,32 @@ Skip guardrail enforcement for tasks with **no code output** (documentation, Q&A
 
 ## Required behavior
 
-### 1. Fetch guardrails at the start of every code task
+### 1. Use the guardrails-selection skill at the start of every code task
+
+Before writing or modifying code, you must read and follow `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
 
-Before writing or modifying code, call `get_guardrails` from `security-review-mcp`:
+That skill is mandatory because the IDE must not leave guardrail selection to chance. The required workflow is:
 
-- **Resolve the project** — Use `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
-- **Fetch guardrails** — Call `get_guardrails` with `project_id`.
-- Each guardrail returned has:
+- **Analyze the task first** — infer what the user is actually building, what components are touched, what categories are involved, and what threats might occur.
+- **Resolve the project** — use `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
+- **Load the broad catalog** — call `get_guardrails` with `project_id`.
+- **Shortlist intentionally** — choose only the guardrails that mitigate the categories and likely threats for the current task.
+- **Hydrate the exact shortlist** — call `get_guardrail_by_id` for the shortlisted guardrail ids so implementation uses the exact selected guardrails, not a vague reading of the full catalog.
+- **Preserve the shortlist** — keep the selected existing guardrails in context so `ctm_sync` can include the same guardrails later without re-querying.
+
+The broad `get_guardrails` result is only the candidate catalog. The active implementation guardrails must come from the shortlisted `get_guardrail_by_id` result.
+
+Each guardrail used for implementation should preserve these fields:
 
 | Field | Description |
 |---|---|
+| `id` | Stable guardrail identifier used with `get_guardrail_by_id` |
 | `title` | Short name of the guardrail |
 | `rule_type` | `must` (mandatory) or `must_not` (prohibition) |
 | `category` | Grouping label (e.g. `authentication`, `input_validation`, `secrets`) or `null` |
 | `instruction` | The actionable coding directive |
-| `source_ref` | List of reference links (threat scenarios, compliance docs, etc.) |
+
+If `get_guardrails` returns additional metadata such as `source_ref`, use it as supporting context during selection.
 
 ### 2. Apply guardrails during code generation
 
@@ -65,6 +71,7 @@ After code generation, include a brief guardrails compliance summary:
 
 - List which guardrails were applied (by title), distinguishing existing vs IDE-generated.
 - Flag any guardrails that could not be fully satisfied and explain why.
+- Do not drop shortlisted existing guardrails from session context. `ctm_sync` must receive the same shortlist, including any unsatisfied items with notes.
 
 ---
 
@@ -82,5 +89,6 @@ Guardrails are living artifacts. The IDE agent can create, apply, and update the
 
 | Tool | Purpose |
 |---|---|
-| `get_guardrails` | Fetch project guardrails (requires `project_id`) |
+| `get_guardrails` | Fetch the broad project guardrails catalog (requires `project_id`) |
+| `get_guardrail_by_id` | Fetch the exact shortlisted guardrails that will govern implementation |
 | `find_project_by_name` | Resolve project by name to get `project_id` |

package/src/generators/rules/hooks.json

@@ -3,9 +3,9 @@
   "hooks": {
     "sessionStart": [
       {
-        "command": "printf '%s\\n' '{\"additional_context\":\"## MANDATORY SECURITY GATE (Session Policy)\\n\\nFor ANY user request that has security impact (auth, crypto, input handling, secrets, network, data storage, dependencies, new APIs/endpoints, or any code handling untrusted data):\\n\\n**Plan order:**\\n1. **Fetch Vibe Guardrails (first)** - Call get_guardrails from security-review-mcp to load project-specific coding dos and don\\u0027ts. These are hard constraints on all generated code. Separate into must (mandatory) and must_not (prohibited) rules.\\n2. **PWNISMS threat modeling (second)** - Run threat modeling as a guide before writing code. Use .cursor/skills/threat-modelling/SKILL.md. Cross-reference guardrails with PWNISMS findings to identify gaps. Document findings to inform secure implementation.\\n3. **Implement secure code (third)** - Use the threat model findings AND guardrails as guides to create secure code. Every must guardrail must be satisfied; no must_not guardrail may be violated.\\n4. **ctm_sync (last)** - Push payload to SRAI only after implementation is done. Invoke ctm_sync agent (Task tool, subagent_type=ctm_sync) as the final step. Include all guardrails (existing + IDE-generated) in the guardrails_applied payload field. See .cursor/agents/ctm_sync.md and .cursor/rules/ctm_sync_rule.mdc.\\n\\nNo blocking. No deferral. Guardrails enforce secure code; threat modeling guides the design; ctm_sync runs last to push to SRAI. Both ctm_sync and guardrail compliance are mandatory and should be part of your to-do.\"}'",
+        "command": "printf '%s\\n' '{\"additional_context\":\"## MANDATORY SECURITY GATE (Session Policy)\\n\\nFor ANY user request that has security impact (auth, crypto, input handling, secrets, network, data storage, dependencies, new APIs/endpoints, or any code handling untrusted data):\\n\\n**Plan order:**\\n1. **Fetch Vibe Guardrails (first)** - Use .cursor/skills/guardrails-selection/SKILL.md. Analyze the task, call get_guardrails from security-review-mcp to load the broad catalog, shortlist the relevant guardrails, then call get_guardrail_by_id for the shortlist. These exact shortlisted guardrails are the hard constraints on generated code.\\n2. **PWNISMS threat modeling (second)** - Run threat modeling as a guide before writing code. Use .cursor/skills/threat-modelling/SKILL.md. Cross-reference guardrails with PWNISMS findings to identify gaps. Document findings to inform secure implementation.\\n3. **Implement secure code (third)** - Use the threat model findings AND shortlisted guardrails as guides to create secure code. Every must guardrail must be satisfied; no must_not guardrail may be violated.\\n4. **ctm_sync (last)** - Push payload to SRAI only after implementation is done. Invoke ctm_sync agent (Task tool, subagent_type=ctm_sync) as the final step. Include the exact shortlisted guardrails from earlier plus any IDE-generated guardrails in the guardrails_applied payload field; do not query again during ctm_sync. See .cursor/agents/ctm_sync.md and .cursor/rules/ctm_sync_rule.mdc.\\n\\nNo blocking. No deferral. Guardrails enforce secure code; threat modeling guides the design; ctm_sync runs last to push to SRAI. Both ctm_sync and guardrail compliance are mandatory and should be part of your to-do.\"}'",
         "timeout": 5
       }
     ]
   }
-}
+}

package/src/generators/rules/skill.md

@@ -33,7 +33,7 @@ Before deep analysis, pull project context from `security-review-mcp` (if availa
    - `get_data_dictionaries` — sensitive data assets
    - `get_security_objectives` — compliance targets
    - `get_findings` — aggregated insights
-10. **Vibe Guardrails** — `get_guardrails` with `project_id` to load project-specific coding dos and don'ts.
+10. **Vibe Guardrails** — Use `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` with `project_id` to load the guardrail catalog, shortlist the relevant guardrails, and hydrate the exact implementation set with `get_guardrail_by_id`.
 
 If SRAI is not available, proceed with whatever context the user provides — files, diffs, PRs, architecture docs.
 
@@ -47,7 +47,7 @@ Collect these quickly before deep analysis:
 - **Assets**: What must be protected (PII, credentials, tokens, configs, accounts, workflows)?
 - **Entry points**: How data enters/leaves (HTTP, queues, schedulers, CLI, webhooks, integrations)?
 - **Trust boundaries**: Where data crosses users/services/networks/privilege levels?
-- **Existing guardrails**: What project-specific dos and don'ts apply (from Phase 0, step 10)?
+- **Existing guardrails**: What shortlisted project-specific dos and don'ts apply (from Phase 0, step 10)?
 
 If the user provided specific code, diffs, or architecture artifacts, prioritize those as primary evidence.
 
@@ -164,8 +164,8 @@ Dependency and delivery threats:
 
 After completing the PWNISMS analysis and before writing code:
 
-1. **Review all fetched guardrails** from `get_guardrails`.
-2. **Classify applicability** — For each guardrail, determine if it applies to the current task.
+1. **Review the shortlisted hydrated guardrails** produced by `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
+2. **Classify applicability** — For each shortlisted guardrail, determine if it applies to the current task.
 3. **Apply during code generation:**
    - `must` rules → mandatory implementation requirements. Every applicable `must` guardrail must be satisfied.
    - `must_not` rules → hard prohibitions. Code must never violate an applicable `must_not` guardrail.
@@ -224,7 +224,7 @@ The `ctm_sync` agent builds and pushes an event payload containing:
 - **Threat model findings**: threats mitigated, PWNISMS categories, severities, mitigations applied
 - **Best practices achieved**: security patterns followed during implementation
 - **Secure code snippets**: security-relevant code with explanations
-- **Guardrails applied**: all guardrails enforced during this session — both existing ones fetched from `get_guardrails` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
+- **Guardrails applied**: all guardrails enforced during this session — both existing ones shortlisted earlier via `get_guardrails` + `get_guardrail_by_id` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
 - **Project profile updates**: architecture notes, tech categories, user groups, compliance requirements, language stacks
 
 ### How to invoke

package/src/utils/constants.js

@@ -66,5 +66,12 @@ export const GUARDRAILS_PROFILER_SKILL_REL_DIR = {
     codex: '.codex/skills/guardrails-profiler',
 };
 
+/** Relative workspace dirs for the guardrails-selection skill (per IDE / CLI). */
+export const GUARDRAILS_SELECTION_SKILL_REL_DIR = {
+    cursor: '.cursor/skills/guardrails-selection',
+    claude: '.claude/skills/guardrails-selection',
+    codex: '.codex/skills/guardrails-selection',
+};
+
 export const SENTINEL_START = '<!-- securityreview-kit:start -->';
 export const SENTINEL_END = '<!-- securityreview-kit:end -->';

package/src/utils/guardrails-profiler-bundle.js

@@ -1,7 +1,7 @@
 import { copyFileSync, readFileSync } from 'node:fs';
 import { dirname, join } from 'node:path';
 import { fileURLToPath } from 'node:url';
-import { GUARDRAILS_PROFILER_SKILL_REL_DIR } from './constants.js';
+import { GUARDRAILS_PROFILER_SKILL_REL_DIR, GUARDRAILS_SELECTION_SKILL_REL_DIR } from './constants.js';
 import { ensureDir, writeText } from './fs-helpers.js';
 
 const __dirname = dirname(fileURLToPath(import.meta.url));
@@ -16,42 +16,69 @@ function injectProjectName(content, projectName) {
 }
 
 function injectSkillDir(content, skillDirRel) {
-    return content.replaceAll('<GUARDRAILS_SKILL_DIR>', skillDirRel);
+    return content
+        .replaceAll('<GUARDRAILS_SKILL_DIR>', skillDirRel)
+        .replaceAll('{{GUARDRAILS_SELECTION_SKILL_DIR}}', skillDirRel);
 }
 
 function injectSkillTemplate(content, projectName, skillDirRel) {
     return injectSkillDir(injectProjectName(content, projectName), skillDirRel);
 }
 
-const BUNDLE_ROOT = join(__dirname, '..', 'generators', 'rules', 'guardrails-profiler');
+const PROFILER_BUNDLE_ROOT = join(__dirname, '..', 'generators', 'rules', 'guardrails-profiler');
+const SELECTION_BUNDLE_ROOT = join(__dirname, '..', 'generators', 'rules', 'guardrails-selection');
 
 /**
- * Writes `guardrails-profiler` (SKILL.md + references/signal-registry.json) under each selected
- * IDE skills directory (e.g. `.cursor/skills/guardrails-profiler`, `.claude/skills/...`).
+ * Writes bundled guardrails skills under each selected IDE skills directory.
  *
  * @returns {string[]} Absolute paths to each skill root written */
-export function writeGuardrailsProfilerBundles(cwd, options = {}) {
+export function writeGuardrailsSkillBundles(cwd, options = {}) {
     const targets = Array.isArray(options.targets) ? options.targets : [];
     const written = [];
 
     for (const target of targets) {
-        const rel = GUARDRAILS_PROFILER_SKILL_REL_DIR[target];
-        if (!rel) continue;
+        const profilerRel = GUARDRAILS_PROFILER_SKILL_REL_DIR[target];
+        if (profilerRel) {
+            const profilerDestBase = join(cwd, profilerRel);
+            const profilerDestRefs = join(profilerDestBase, 'references');
+            ensureDir(profilerDestRefs);
 
-        const destBase = join(cwd, rel);
-        const destRefs = join(destBase, 'references');
-        ensureDir(destRefs);
+            const profilerSkillTemplate = readFileSync(join(PROFILER_BUNDLE_ROOT, 'SKILL.md'), 'utf-8');
+            writeText(
+                join(profilerDestBase, 'SKILL.md'),
+                injectSkillTemplate(profilerSkillTemplate, options.projectName, profilerRel),
+            );
 
-        const skillTemplate = readFileSync(join(BUNDLE_ROOT, 'SKILL.md'), 'utf-8');
-        writeText(join(destBase, 'SKILL.md'), injectSkillTemplate(skillTemplate, options.projectName, rel));
+            copyFileSync(
+                join(PROFILER_BUNDLE_ROOT, 'references', 'signal-registry.json'),
+                join(profilerDestRefs, 'signal-registry.json'),
+            );
 
-        copyFileSync(
-            join(BUNDLE_ROOT, 'references', 'signal-registry.json'),
-            join(destRefs, 'signal-registry.json'),
-        );
+            written.push(profilerDestBase);
+        }
 
-        written.push(destBase);
+        const selectionRel = GUARDRAILS_SELECTION_SKILL_REL_DIR[target];
+        if (selectionRel) {
+            const selectionDestBase = join(cwd, selectionRel);
+            const selectionDestRefs = join(selectionDestBase, 'references');
+            ensureDir(selectionDestRefs);
+
+            const selectionSkillTemplate = readFileSync(join(SELECTION_BUNDLE_ROOT, 'SKILL.md'), 'utf-8');
+            writeText(
+                join(selectionDestBase, 'SKILL.md'),
+                injectSkillTemplate(selectionSkillTemplate, options.projectName, selectionRel),
+            );
+
+            copyFileSync(
+                join(SELECTION_BUNDLE_ROOT, 'references', 'category-threat-map.md'),
+                join(selectionDestRefs, 'category-threat-map.md'),
+            );
+
+            written.push(selectionDestBase);
+        }
     }
 
     return written;
 }
+
+export const writeGuardrailsProfilerBundles = writeGuardrailsSkillBundles;