Security Review Prep

security-review-prep produces a security response package in chat. It is the skill to reach for when a deal moves into security review and you need a defensible response draft, a control matrix, and a clear list of what still needs escalation. It reuses prior discovery and architecture context instead of re-collecting it.

What this skill is

A conversational security-prep workflow. You hand it a fact sheet, architecture map, or fit-gap artifact, optional requirement docs, and the specific customer questions on the table, and it returns:

• A short summary.
• A security response brief.
• A control matrix.
• Customer follow-ups.
• Escalation gaps.
• Citations or assumptions.

Under the hood it prefers supplied artifacts, uses Firecrawl only when requirement docs URLs are provided, and converts uncertainty into follow-ups or escalation gaps instead of smoothing it away.

Trigger conditions

Use this skill when the user asks for:

• Security review prep.
• A questionnaire response draft.
• A control matrix.
• Customer security follow-ups.
• Escalation gaps before looping in security or legal.
• “What do we owe the customer on security by Friday?”

Intake order

Codex asks one question at a time, in this order:

1. Fact sheet, architecture map, or fit-gap artifacts — artifactRefs or a paste.
2. notes.requirementsDocs — URLs or local paths for the customer’s security requirements, questionnaires, or security page.
3. notes.customerQuestions — specific questions the customer has asked (for example, “How is customer data accessed during the pilot?”).
4. notes.deadline — when the response is owed (free-form, for example “Next Friday”).

Output shape

The artifact is returned in chat with these sections:

1. Summary
2. Security response brief
3. Control matrix
4. Customer follow-ups
5. Escalation gaps
6. Citations or assumptions

How to best use this skill

Run discovery and architecture first when you can. The control matrix and response brief are sharpest when anchored in a fact sheet and an architecture map. The skill explicitly consumes discovery-fact-sheet.json from artifactRefs before raw notes, and will pick up blockers and risks from prior architecture and fit-gap work.

Feed it the customer’s exact questions. Paste the questionnaire verbatim or drop the questions one per line into notes.customerQuestions. The response brief answers the questions as written rather than rephrasing them.

Pass requirement docs, not summaries. If the customer has a security page, SOC 2 FAQ, or shared questionnaire link, pass the URL or local path in notes.requirementsDocs. Firecrawl grounds the response against those docs and attaches citations. Without docs, the response stays draft-level.

State a deadline. notes.deadline is preserved in the brief and used when the skill sorts escalation gaps by urgency. Relative dates like “Next Friday” are fine.

Trust escalation gaps. The skill deliberately keeps items it cannot ground as escalation gaps. That list is your backlog for security, legal, and product. Do not pressure the skill into a “yes” answer — freehanding security claims is the failure mode Solutioneer is designed to avoid.

Customer follow-ups are questions, not commitments. The follow-ups section captures questions you need to ask the customer to complete the response. Bring them to the next call.

Save and writeback are opt-in. The package lands in chat. You can ask for it to be saved as markdown, pushed to a Google Doc, or filed in Confluence. Each writeback confirms the destination before executing.

How to combine with other skills

Security review sits late in the pre-sales chain. Every upstream skill produces signal it can reuse.

• From Discovery Context Ingester. The fact sheet grounds account context (data flows, integrations, key personas) without re-researching them.
• From Architecture Fit Mapper. Blockers and required validations from the map become rows in the control matrix. Components and data flows inform the response brief’s “how is data accessed” answers.
• From Integration Fit Gap Analyzer. gap and unknown rows in the fit-gap often show up again as escalation gaps in security review — particularly around third-party vendors.
• Into POC Handoff Orchestrator. Escalation gaps and customer follow-ups are valid inputs into the POC plan’s risk register and dependency list.

Example invocations

Explicit:

$security-review-prep "Acme Health"

Natural language:

Draft a security review response pack for Acme Health. Customer asked: "How is customer data accessed during the pilot?" — deadline is next Friday.

Example normalized input (for reference — you never type this directly):

{
  "account": { "name": "Acme Health" },
  "objective": "Draft a security review response pack",
  "notes": {
    "requirementsDocs": [],
    "customerQuestions": [
      "How is customer data accessed during the pilot?"
    ],
    "deadline": "Next Friday"
  },
  "artifactRefs": [],
  "destinations": {},
  "providerMode": "local-only"
}

Provider behavior

• With FIRECRAWL_API_KEY — Firecrawl grounds requirement doc URLs in notes.requirementsDocs. Grounded claims carry citations.
• Without FIRECRAWL_API_KEY — the skill stays local-only. Unsupported claims are kept as escalation gaps or as assumptions, not invented.
• External writeback — requires COMPOSIO_API_KEY and a connected toolkit. Supported toolkits: googlesuper (Google Docs) and confluence. See Connect Google Docs & Sheets and Connect Confluence.

Related reference

• Grounding Rules — why escalation gaps beat guessed “yes” answers.
• Save & Writeback — how confirmation-based writeback protects security responses from silent publishing.