SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsspmi-auditor

spmi-auditor

Security & auditing

View repository

Updated 10-16 06:23

About this skill

SPMI Auditor

Use this skill only when the SPMI MCP server confirms auditor in supported_roles. The skill supports evidence-grounded internal quality assurance and never grants authorization by itself.

Input Parameters

  • task: The user's audit or quality-assurance objective.
  • mcp_server_url: The configured SPMI MCP resource URL; never append a token.
  • active_role: Must be auditor and must appear in the server-returned role context.
  • campus_id: Optional tenant selection; it must be present in the authenticated context.

Execution Logic

  1. Connect through the MCP client's OAuth 2.1/PKCE flow or its secure bearer-token configuration. Never request the raw token in chat.
  2. Call spmi_get_my_access_context before any domain tool.
  3. Continue only when auditor appears in supported_roles. If several supported roles are returned, ask the user to select auditor explicitly.
  4. Use only tenant IDs returned in campus_ids; server rejection is final and must not be bypassed.
  5. Select the minimum required tool:
    • spmi_list_documents
    • spmi_get_document_detail
    • spmi_submit_document
    • spmi_validate_document
    • spmi_verify_blockchain_ledger
    • spmi_get_audit_trail
    • spmi_get_campus_metrics
    • spmi_get_executive_summary
  6. Treat list/detail, ledger, audit-trail, metrics, and summary calls as read operations. Explain the intended scope before broad tenant queries.
  7. Before spmi_submit_document or spmi_validate_document, show the exact proposed title/status/notes and obtain explicit user approval.
  8. Distinguish facts returned by MCP from analysis or recommendations. Never invent evidence, standards, compliance status, signatures, or audit findings.
  9. Do not place tokens, emails, private documents, or raw sensitive findings in logs, persistent memory, public issues, or generated frontend code.
  10. Return a concise audit result with evidence used, gaps, risk level, and the next authorized action.

Constraints

  • Never assume Super Admin, Admin PT, Rektorat, Auditee, or GPM authority.
  • Never approve a document without explicit user confirmation.
  • Never work around ROLE_FORBIDDEN or TENANT_FORBIDDEN.
  • Never decode a bearer token client-side to decide authorization.

Example

As Auditor, review Draft documents for my authorized campus, identify missing metadata, verify the TrustChain entry for the selected document, and prepare—but do not execute—a validation recommendation.