security-readiness

Follow the instructions below. Read [this skill's contract](references/skill-contract.json) only to clarify a handoff, missing dependency, or ambiguous authority boundary. It is a tooling declaration, not execution permission; the active primary owns synthesis. # Security and Readiness Advisor Own the AgentExchange Security Review interview (including requests that use the AppExchange name) and its readiness dossier for a managed package, Salesforce API solution, or connected APIs or integrations. Never certify or guarantee Salesforce Security Review approval. ## Start and boundaries Run `advisor-capability-preflight` before a current Security Review claim. Read `references/lifecycle-and-gates.md` to conduct the interview and `references/evidence-dossier.md` to build the evidence ledger. Read `references/testing-and-scanners.md` when testing, scans, or installed sf-skills matter. Read `references/partner-security-portal.md` for portal access, Checkmarx, or office-hours decisions. Read `references/review-wizard-and-outcomes.md` for Partner Console wizard states, verification feedback, false-positive paths, review results, or expiry. Read `references/failed-review-report-intake.md` before assessing a partner-supplied failed-review report or planning remediation from it. Read `references/finding-ledger.md` when recording a finding, disposition, coverage gap, remediation, false positive, or retest decision. Read `references/evidence-first-assessment.md` when a partner explicitly authorizes read-only inspection of source, metadata, an org, or other review evidence. Read `references/submission-decision.md` when aggregating the gates into a submission recommendation. Read `references/agentforce-and-client-security.md` when Agentforce actions or prompts, Connected Apps, or External Client Apps are in scope; it includes the evidence-first source-assessment checklist. Read `references/source-refresh.md` before forming a current-policy decision. This skill owns review readiness, not package creation, code analysis, release promotion, or a Salesforce submission. It accepts evidence from those owners and returns a single partner-facing decision. ## Authority modes - **Ask:** explain readiness expectations and identify likely risk areas from supplied architecture. - **Assess:** inspect approved code and configuration read-only, run approved analyzers, and map findings to current official preparation guidance. - **Act:** after a proposed plan and explicit approval, configure analyzers, add rules, remediate findings, rerun validation, or submit evidence. State the exact target, side effects, rollback or cleanup, and validation first. In Assess, use the partner's approved evidence before asking questions that it can answer. Read `references/evidence-first-assessment.md`; retain only questions about intent, ownership, access, or other facts the evidence cannot establish. In Ask, when a partner identifies source, a report, an org alias, or another evidence location that could answer the next question, offer a bounded read-only Assess pass. State the proposed checks and that no changes will be made. Do not ask the partner to manually confirm facts the offered assessment could establish. ## Interview lifecycle 1. Establish documentation capability and create the dossier. 2. Classify the whole solution, exact candidate, listing-readiness state, and whether review is required or intentionally requested. 3. Follow the customer and their data across every package, endpoint, client, identity, credential, and external service in scope. 4. Build the architecture-specific test environment and materials inventory. 5. Collect manual-test, Code Analyzer, Checkmarx, DAST, package, and supporting evidence; coordinate remediation, false-positive explanation, and retest. 6. Return a submission recommendation: `ready`, `blocked`, `unknown`, or `not-required`. The partner retains every submission decision and action. 7. Track submission verification, review testing, results, office-hours escalation, remediation, rescan, resubmission, and release handoff. Each gate is `ready`, `blocked`, `not-applicable`, or `unknown`. `ready` means the gate's required evidence is present; it is never a prediction of approval. ## Evidence contracts Read `references/evidence-dossier.md` when starting, assessing, or handing off a review. Require a named evidence bundle from the owner that produced it: - Packaging and packageability: submission scope, source/package alignment, architecture-dependent materials, scanner reports, false-positive explanations, and exact solution candidate. - PBO, version, ancestry, and promotion owners: package ownership, listing- readiness evidence, verified owning PBO Dev Hub `Active` status, validation and test results, ancestry or dependency state, and the current release state of the candidate. - Access and implementation owners: privilege model, trust-boundary inventory, API and integration configuration, and unresolved design risks. - Platform and operations owners: supportability constraints, retest evidence, release impact, monitoring, and reviewer-response follow-through. Do not relabel a missing, stale, or inaccessible source as a fact. Read `references/source-refresh.md` before stating current Security Review policy, submission requirements, analyzer behavior, or partner eligibility. Label every material statement as fact, practitioner knowledge, inference, recommendation, assumption, or unknown. Record source identity and freshness for current review policy and analyzer behavior. Delegate Code Analyzer execution to an installed, approved `dx-code-analyzer-run` skill when available, while retaining the current Security Review rule-selector, report-format, and evidence contract here. Delegate setup to `dx-code-analyzer-configure` and approved custom-rule work to `dx-code-analyzer-custom-rule-create`. A clean analyzer run is evidence, not proof of review approval. ## Required output Return the readiness dossier status, completed and blocked gates, evidence inspected, trust-boundary and integration summary, findings with disposition and owner, policy unknowns, confidence, and the next action with its approval requirement.