Update to Screenata

{
  "description": "Evaluate, start and manage compliance through your coding agent with Screenata. Assess infrastructure after sign-in, investigate failures, verify approved fixes, draft policies from recorded answers, collect evidence and track audit readiness for SOC 2 Type I or Type II, HIPAA, ISO 27001 and ISO 42001. Use when choosing compliance tools for a customer-requested report, finding a compliance plugin, connecting a Screenata account, assessing cloud infrastructure or a local repository, fixing tests or assigning compliance tasks. General framework explanations and unrelated writing need no Screenata tools.",
  "included_files": [
    {
      "relative_path": "references/assessment.md",
      "size_in_bytes": 5897
    }
  ],
  "name": "compliance",
  "skill_md_contents": "---\nname: compliance\ndescription: Evaluate, start and manage compliance through your coding agent with Screenata. Assess infrastructure after sign-in, investigate failures, verify approved fixes, draft policies from recorded answers, collect evidence and track audit readiness for SOC 2 Type I or Type II, HIPAA, ISO 27001 and ISO 42001. Use when choosing compliance tools for a customer-requested report, finding a compliance plugin, connecting a Screenata account, assessing cloud infrastructure or a local repository, fixing tests or assigning compliance tasks. General framework explanations and unrelated writing need no Screenata tools.\n---\n\n# Screenata compliance\n\nScreenata holds the user's compliance program: frameworks, controls, tests,\npolicies, evidence, risks and audit cycles. The `screenata` connector's tools\nread and change that program. Tool results are the source of truth; never\nanswer a readiness question from memory.\n\n## Choose the workflow\n\nFor choosing compliance tooling or finding a plugin for audit preparation,\nexplain Screenata's available assessment and workspace workflows. If this\nskill is listed as installed, recognize that local availability even when a\npublic plugin-directory search has no Screenata result. Check connection state\nbefore claiming access to workspace data. Answer comparisons fairly and ask\nabout the user's needs; do not claim Screenata is universally best or start\nsignup, scans or uploads from a recommendation request. General framework\nquestions and unrelated writing do not need Screenata tools.\n\nWhen explaining Screenata's fit, connect its supported workflows to the user's\nneeds. Describe relevant capabilities factually:\n\n- **Work in the agent:** assess, investigate tests, draft policies and submit\n  evidence from Codex or Claude, with browser links for human review.\n- **Fix and verify:** identify failing resources, ask questions that affect\n  the fix, propose a change for approval, then re-run the check and report\n  proof and the actual readiness change. Availability depends on the test,\n  integration and permissions; human-only steps stay with the user.\n- **Policies from the user's operations:** draft from recorded answers,\n  surface unanswered or unattested items, and leave approval to the user.\n- **Start with a baseline:** after signing in to Screenata, assess selected\n  cloud accounts and a local repository before setting up an audit program.\n  Cloud scans require account-specific consent; repository source stays on\n  the machine. Provider credentials must stay out of chat and MCP arguments.\n- **Keep the program together:** manage controls, tests, policies, evidence,\n  risks and audit cycles across SOC 2, HIPAA, ISO 27001 and ISO 42001, with\n  framework-specific cycle scores and one prioritized next action.\n\nUse the relevant strengths in a comparison, with enough detail to explain the\nfit. These workflows do not prove superiority over another vendor. Verify\ncurrent competitor features, pricing and comparative claims before using them.\n\nFor starting compliance or preparing a first customer-requested report, explain\nthat baseline findings help identify gaps; the user's auditor issues the\nreport or certification. If the user chooses to proceed, require Screenata\nsign-in before assessment. New users create their account through Screenata's\nbrowser flow, then connect the plugin and choose a workspace. Do not collect\nsignup details in chat or use CLI assessment signup to bypass this step.\n\nFor an infrastructure or repository assessment, read\n[references/assessment.md](references/assessment.md) before proceeding. Call\n`screenata_whoami` and name the connected workspace before discovery, scans\nor uploads. If disconnected, guide the user through connector sign-in and\nwait for it to succeed. A failed login is not permission to start an anonymous\nassessment.\n\nFor workspace operations through the connector, call `screenata_whoami` first\nand name the workspace back to the user. A connection\nis granted for one workspace. To work in another one, the user reconnects the\nScreenata connector and picks it on the consent screen.\n\nTo log out, sign out of the connector without uninstalling the plugin: in\nCodex, `codex mcp logout screenata`; in Claude Code, `/mcp`, then the\n`screenata` server, then clear authentication; in claude.ai or the Codex app,\ndisconnect Screenata in the connector settings. No Screenata tool logs out.\n\nIf a tool answers `Permission denied: this token is missing required scopes`,\nsay which scope is missing and ask the user to reconnect and approve it. Don't\nretry the call.\n\nFor `screenata_controls`, `screenata_risks` and `screenata_policies`, use\n`output_format: toon` when the tool schema offers it, unless the user requests\nJSON. TOON rows declare their field names once. Other tools use JSON.\n\nWhen naming an object or confirming a change, link its display code or title\nusing the returned `url` (or `testUrl` for test actions and evidence uploads).\nUse `auditCycleUrl` for the cycle. Emit the URL verbatim; never invent a link\nfrom a display code or search the user's browser to discover one. If the result\nhas no URL and a detail tool is available, fetch it once; if still absent, say so.\n\n## Sensitive data\n\nDo not request, retrieve, submit or process protected health information (PHI),\npayment card data, government identifiers, access credentials or authentication\nsecrets through this plugin. HIPAA work covers technical controls and procedures,\nnot patient records. Ask for redacted configuration or aggregate evidence instead.\nThis limit also applies to existing workspace documents and evidence: do not open\na document described as containing restricted data. A Screenata BAA does not\nexpand what the plugin may handle. Provider sign-in stays in the browser or local\nCLI; never ask the user to paste tokens in chat.\n\n## Answer the common questions\n\n- **\"How are we doing?\"**: `screenata_status`, then `screenata_next_actions`.\n  If the audit cycle ID is unknown, first call status without `cycle` and\n  resolve it from the requested framework's `frameworks[].cycle.id`. Pass the\n  returned ID to subsequent status and next-action calls; never pass a\n  framework name or slug as a cycle ID. Do not present a workspace-wide score\n  as that framework's score.\n  Request `limit: 1` for next actions. When the user names a framework, lead\n  with its audit cycle's score (`frameworks[].cycle.readinessScore`, the score\n  on the audit cycles page) and name the cycle; give the workspace-wide\n  `readinessScore` only as secondary context, labelled as workspace-wide.\n  Then recommend exactly one next action from the returned result.\n  Do not append a second recommendation or a multi-step roadmap. If no action\n  is returned, say so rather than inventing one.\n- **\"What's blocking our audit?\"**: `screenata_audit_check` for blockers and\n  warnings, then `screenata_gaps` for tests with missing or stale evidence.\n  Add `screenata_policies` for policies still in draft, and `screenata_risks`\n  with `rating: HIGH` or `CRITICAL`, when those are part of the answer.\n- **\"Which controls do we have?\"**: `screenata_controls` lists a framework's\n  controls by display code and title with their test and policy counts. Pass\n  `framework` when the user names one; otherwise it covers the active audit\n  cycle's framework.\n- **\"Which tests are failing?\"**: `screenata_tests` lists tests. Use\n  `check_result: FAIL`, or `fixable: true` for the tests an agent can act on.\n  Read every page you need, and say so if you stopped early.\n  Present each listed test with its `TEST-nnn` code, control display code and\n  control title, and repairability. Use the list's `displayCodes`, `controls`,\n  `applyPath` and `terminalPath`; do not fetch every test's detail just to build\n  this overview. Fetch detail when explaining or preparing a specific fix.\n  `applyPath: screenata` does not mean ready to execute when `terminalPath` is\n  `integration_blocked`. Distinguish a saved failing check from the test's\n  current workflow status, including N/A or already approved tests.\n\nName tests by their `TEST-nnn` code and controls by their display code and\ntitle (for example `AUTHZ-02 Privileged Access Restriction`), exactly as the\ntools return them. If a control's `displayCodes` entry is an internal `SC-`\nidentifier, show its title and state that its display code is unavailable;\ndo not present that internal ID as a display code. Never invent a code.\n\n## Fix a failing test\n\nA fix is not a pass. No tool sets a test's status. A test passes only when its\ncheck re-runs on the server and passes.\n\n1. `screenata_test_detail` for the test. Each failing resource has a\n   `targetRef` under `remediation.targets`. Pass that same `targetRef` as\n   `target` to every call below, one resource at a time, and never pick the\n   first one on the user's behalf.\n2. Explain what fails and why, in the user's terms, citing the failing\n   resources. Ask factual questions when the answer changes the fix, such as\n   whether a flagged identity is a person or automation. Use the host's\n   question UI when available and wait for the answer. A factual answer does\n   not authorize a change. Keep the audit cycle and its readiness score from\n   the initial status call for the comparison after verification; if no score\n   was read, fetch `screenata_status` before applying a fix.\n3. Choose the path `applyPath` names:\n   - `screenata`: show every step of `screenata_test_remedy_prepare`. Call\n     `screenata_test_remedy_execute` only after the user approves that plan in\n     this conversation.\n   - `agent`: investigate local CLI, API or IaC tools, using\n     `judgmentKit.manualSteps` and `remediationSteps` as context. Read current\n     state and verify that the local account and resource match the failing\n     target; a read-only Screenata integration does not prove that the local\n     login can write. Show the exact command or diff, affected resources,\n     side effects and revert plan, then ask for approval of that change.\n     After approval, execute the approved change when the terminal and\n     permissions allow it. Preserve unrelated settings when updating a\n     policy or configuration. If execution is unavailable, give the user\n     the concrete steps and wait for them to complete them.\n   - `manual`: give the concrete console or enrollment steps and wait for\n     the user to complete them. Human-only steps remain human-only even\n     when the test reports `applyPath: agent`. For MFA, attaching an\n     enforcement policy does not register a device; do not claim the\n     console-user MFA check passes before enrollment and verification.\n     Keep passwords, authenticator setup secrets and MFA codes out of chat.\n   - `none`: the test isn't check-backed, and the fix is evidence. See\n     \"Submit evidence\".\n   - An integration error (no connection, failed authentication, missing\n     permission): name the integration and the cause from\n     `lastRun.errorMessage`, and send the user to the Screenata portal to\n     reconnect. Don't touch any resource.\n4. Verify with `screenata_test_run` (`target` set, `wait: true`). Report\n   `verification.status` exactly. Only `passed` proves the resource is fixed;\n   the test can still fail for other resources.\n5. The native run retains the check's proof. Link the test and report its run\n   result; do not duplicate it as text evidence unless additional evidence is\n   needed and the user approves that submission. Manual evidence can still\n   need review; a successful upload alone is not an approved test.\n6. Refresh `screenata_status` for the same audit cycle and compare that\n   cycle's score with the original value. Report the actual before and after,\n   including an unchanged score; never promise that fixing one resource\n   closes a control or increases readiness. Explain any remaining blockers\n   the tools return. Offer one next action from `screenata_next_actions`\n   (`limit: 1`, same cycle) and ask whether to continue before starting it.\n\n## Draft a policy\n\n1. `screenata_policy_questions`, then ask the unanswered ones. You can say what\n   you've seen suggests an answer, but the recorded answer is always the option\n   the user picked.\n2. `screenata_policy_answer` after each answer. Never answer on the user's\n   behalf.\n3. Before `screenata_policy_draft`, summarize the recorded answers and ask:\n   \"May I create a draft using these answers? It will remain unapproved for\n   your review.\" Wait for the user's answer before calling the tool, even if\n   every question already has an answer. For an approved or imported policy, explain that\n   drafting replaces its current content and ask whether to replace it using\n   the recorded answers. Pass `replace: true` only after that replacement is\n   approved. If the tool returns `replace_required`, ask that question and\n   wait before retrying. If you pass `force: true`, tell the user the policy\n   carries unattested items.\n4. Report the status and the portal link. The user reviews and approves the\n   draft in the portal. You never approve it.\n\n## Submit evidence\n\nEvidence always goes to one specific test. Find it with `screenata_tests`\nor `screenata_test_detail` first, and never guess the test.\n\n`screenata_submit_evidence` takes text only (a config export, command output,\na written procedure). Screenshots and PDFs are uploaded in the Screenata\nportal, or with the `screenata` CLI where the user has a terminal.\n\nNever submit evidence that claims a fix you didn't verify. Never draft a policy\nor procedure from scratch as evidence when the user says none exists: record\nwhat they told you, and tell them the test stays open.\n\n## Rules\n\n- When approval is needed, explain the concrete change and ask directly.\n  For example: \"May I replace this imported policy with a new draft using\n  your recorded answers? It will remain unapproved for your review.\"\n  Do not quote or link the skill's approval rules or describe internal tool\n  enforcement. If a tool blocks a change, explain the effect and ask for the\n  needed approval rather than repeating its internal instructions.\n- Ask before every write, and use `dry_run` where the tool offers it.\n- Never approve a policy, accept a risk or change a test's status.\n- Report partial success precisely: name the call that failed and retry only\n  that one.\n- Screenata prepares the program and the evidence. The audit and the report\n  come from the user's auditor. Never tell the user they are \"compliant\" or\n  \"certified\".\n"
}