{"id":92468,"plugin_id":"plugin_connector_1p_6317a32dbf5c81919acd66de6722daf5","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-12T06:08:26.278Z","digest":"f797d62ed09300ac720585fd85342d570c47b640ffdbf510d2678ecf7ea77889","against":null,"payload":{"description":"Use Daybreak Defense Factory (also called Daybreak or Codex Security Cloud) from chat to launch, inspect, or cancel scans and read findings, or open its UI for setup and continuous monitoring.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":132}],"name":"codex-security-cloud","skill_md_contents":"---\nname: codex-security-cloud\ndescription: Use Daybreak Defense Factory (also called Daybreak or Codex Security Cloud) from chat to launch, inspect, or cancel scans and read findings, or open its UI for setup and continuous monitoring.\n---\n\n# Daybreak Defense Factory\n\n“Daybreak”, “Daybreak Defense Factory”, and “Codex Security Cloud” refer to this same plugin. Use the existing `defense_factory_*` tools for all three names.\n\nUse the connected Daybreak tools directly for chat requests such as \"Scan owner/repo\", \"How is my scan doing?\", \"Summarize its findings\", or \"Cancel that scan\". Discover the relevant `defense_factory_*` tools through tool search when needed. A clear request to launch or cancel authorizes that action; do not ask for a duplicate confirmation.\n\n## Check setup before using data tools\n\nBefore listing or reading scans, findings, repositories, environments, or usage, or launching a scan, call `defense_factory_bootstrap` for the current workspace. Reuse its result within the current request; check again after the workspace changes or the user completes connection setup.\n\n- If access is denied or workflows are disabled, explain the returned setup requirement and use the active app for setup, opening it if needed. Do not continue with data tools.\n- If `githubConnected` is false or `githubConnectorIds` is an empty list, explain that GitHub must be connected in this workspace and use the active app for setup, calling `open_defense_factory` only if it is not already active. Stop data calls until the user has connected GitHub, then check bootstrap again.\n- Null connection state means discovery was unavailable, not that GitHub is disconnected. Existing reads may still be authorized; do not treat this as a confirmed missing connection.\n- If a data tool returns `no_github_connection`, stop further data calls and use the same connection setup flow. Do not retry it as a service outage or report that there are no scans or findings.\n\n## Launch a scan\n\n1. Use `githubConnectorIds` from the setup check. Pass the appropriate returned ID as `connector_id` to `defense_factory_github_search` or `defense_factory_github_repositories`; search the active connections when the target's connector is unknown. Use `defense_factory_github_get` for an already known repository ID. Preserve returned repository IDs and connector identity, including GitHub Enterprise namespaces.\n2. Use `defense_factory_environments_list` or `defense_factory_environments_search` to find an existing environment containing that repository on the same connector. Use the user's selection or an unambiguous match; ask when multiple compatible choices remain. If none exists, use the setup fallback below.\n3. Read `defense_factory_workflow_definition` for workflow ID `codex-security.security-scan`. Build launch `steps` using its returned step IDs and model/reasoning options. Use the user's supported selections or a sole returned option; ask for unresolved choices instead of inventing defaults. Omit `reasoning` when the step does not offer it. Use `defense_factory_usage_get` when scan availability or credits matter; backend launch checks still decide admission.\n4. Call `defense_factory_workflow_launch` with those selections and one idempotency key for this launch attempt. Preserve the same key and inputs when retrying an ambiguous response; changing the key could start another paid scan. Report a conflict or unresolved failure instead of creating a replacement launch.\n5. Return the run ID, repository, target revision, and reported status. `queued` confirms acceptance and `running` means work is in progress. Report successful completion only for `completed`. Report `failed` with the returned failure details, and report `canceled` as cancellation, not success.\n\n## Inspect results or cancel\n\nUse `defense_factory_workflow_list` and `defense_factory_workflow_repositories` to find runs, and `defense_factory_workflow_get` for the exact run's status and output IDs. Read output metadata and artifact references with `defense_factory_workflow_output`. For repository-scan findings, use `defense_factory_findings_list` with `source: repository_scan` and `scan_id` set to the run ID; follow pagination before claiming a complete summary. Report artifacts are downloaded through the app; their references alone do not contain the report contents. Summarize the findings actually read, preserve any output-validation warnings, and include the relevant run/output IDs.\n\nFor cancellation, resolve the requested run and call `defense_factory_workflow_cancel`. Report its returned state accurately: `cancel_requested` means cancellation is pending; only `canceled` confirms completion. If the run already finished, report that state.\n\nUse `defense_factory_findings_list` and `defense_factory_findings_get` for findings across scan types. When asked to close a fixed commit-scan finding, read its combined `commit:<id>` first, then pass `commit_detail.id`, the current `commit_detail.version`, and a written resolution reason to `defense_factory_findings_close`. Repository-scan and PR-review observations do not support that close operation. Preserve the distinction between a finding and a workflow run.\n\nLink each finding title using its returned ID: `https://chatgpt.com/mcp-app/connector_openai_defense_factory/open_defense_factory#/findings/<id>`. For original findings (IDs without the `acf_` prefix), use `#/findings/raw/<id>` instead. Percent-encode the entire ID as one path segment; for example, `commit:123` becomes `commit%3A123`.\n\nCall the saved change a “fix” in replies, including when the user calls it a patch. The API returns the fix in the `patch` field. On a canonical finding page or its fix page, answer questions about the fix by calling `defense_factory_finding_fix_get` with the current app path as `page_path`. If the finding returned a `latest_patch_id`, pass it as `patch_id` to read that revision. Use tool search to find the tool if needed. Answer from the saved fix and its recorded checks. If the read succeeds with a null `patch`, say that no fix has been saved for this finding yet.\n\nA request sent by the user to prepare a fix authorizes preparation for that finding. Start it in the same turn by calling `defense_factory_finding_fix` with the finding’s `page_path` and `action: \"propose\"`.\n\nShow each finding’s saved fix once per conversation with `defense_factory_finding_fix_show`. Pass the same `page_path` and the current `patch.id` as `patch_id`, even while queued. Use the getter for follow-ups and show the card again only on request. If the card tool is unavailable, answer in text.\n\nFix preparation runs in the background and can take more than ten minutes. For a queued or running fix, reply with just its current state, such as “Your fix is being prepared.” The live card tracks progress. Leave timing and troubleshooting out of routine updates. End the turn unless the user asks you to keep checking.\n\nIf the latest fix failed, offer to regenerate it as a new revision. When the user asks to retry or accepts the offer, follow the getter’s `regenerate_instructions`. If those instructions are unavailable, point the user to **Regenerate** on the fix page.\n\nWhen the user asks to edit a saved fix, read it with `defense_factory_finding_fix_get` and follow its `edit_instructions` if present. Otherwise explain that editing is unavailable. Report the revision and status after a successful edit.\n\n## Read usage and spend\n\nUse `defense_factory_usage_history` for scanning spend. Pass inclusive `start_date` and `end_date` under `parameters.query`, with the user's IANA `time_zone`; use UTC and say so if their zone is unknown. Explain the calendar-only limit for rolling or intraday requests.\n\nSum recorded costs across the returned buckets, keeping billable amounts, allowances, and exemptions distinct. Include the returned interval and `as_of`; disclose pending usage or billing as incomplete. These receipts are not a final invoice. `defense_factory_usage_get` reports current allowance, not historical spend. If history is unavailable, report that instead of summing cumulative scan totals or falling back to browser automation.\n\n## Open the app or finish setup\n\nWhen Daybreak is already active, use its current context and tools without calling `open_defense_factory` again. For setup or actions available only in the app, direct the user to its existing controls.\n\nCall `open_defense_factory` when Daybreak is not already active and the user asks for the UI, needs a GitHub connection or Cloud environment configured, or requests an operation available only in the app, such as continuous monitoring or other finding mutations. Explain the specific setup or action needed. Let the app's existing controls handle connections and environments; do not request credentials or change workspace permissions. Opening the app alone does not authorize scans or mutations.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}