Help us improve
Share bugs, ideas, or general feedback.
From shinsa
Use this skill when generating ISO 27001 or NIST SP 800-53 audit evidence packs, compliance reports, evidence narratives, reviewer-ready control matrices, or when the user asks about audit evidence, compliance evidence, evidence packages, audit documentation, or ISO/NIST evidence.
npx claudepluginhub allsmog/shinsa-plugin --plugin shinsaHow this skill is triggered — by the user, by Claude, or both
Slash command
/shinsa:evidence-generationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transform Shinsa assessment artifacts into an enterprise-grade evidence pack for Security and GRC reviewers. The pack must be defensible, reviewable, exportable, and honest about uncertainty. It supports an audit or control review; it does not replace a human auditor.
Drafts personalized cold emails, warm intros, follow-ups, updates, and communications for investor outreach during fundraising to angels, VCs, accelerators.
Share bugs, ideas, or general feedback.
Transform Shinsa assessment artifacts into an enterprise-grade evidence pack for Security and GRC reviewers. The pack must be defensible, reviewable, exportable, and honest about uncertainty. It supports an audit or control review; it does not replace a human auditor.
Read persisted artifacts first:
assessment-plan.mdscope.mdapplicability.json and applicability.mddomains/*.json and domains/*.mdreviews/round-*/*.json and reviews/round-*/*.mdsynthesis/evidence-index.jsonsynthesis/control-matrix.jsonshinsa-state.json when presentDo not rescan the repository during synthesis unless the orchestrator explicitly asks for a reconciliation pass. The evidence pack should explain what the persisted artifacts support.
The canonical report is shinsa-output/runs/<assessment_id>/synthesis/compliance-report.md. It must include these top-level sections:
## Assessment Metadata## Executive Summary## Control Matrix## Findings## Evidence Index## Reviewer Notes## Unresolved Risks## Limitations## What To Do Next## Human Sign-OffAssessment metadata must include:
Every control row and narrative must include:
confidence_rationaleevidence_qualityevidence_quality_rationalemanual_evidence_neededmanual_evidence_itemsreviewer_dispositiongrc_action: accept, reject, request_evidence, or create_remediation_ticketDo not mark a control implemented if manual_evidence_needed is true. Use partially_implemented, not_implemented, or not_assessed until the missing manual evidence is supplied.
strong: direct source/config evidence supports the claimed control outcome, findings have file and line anchors, and no manual evidence is required for the claimed status.partial: evidence supports part of the control, but implementation gaps, reviewer concerns, or manual evidence needs remain.inferred: the claim depends on framework convention, absence of contrary evidence, or indirect evidence.missing: no reliable evidence was found.Never use strong for a hybrid control when manual policy, approval, access review, incident, supplier, training, or production records are needed for full compliance.
Use specific manual evidence items. Avoid vague text like "policy evidence needed".
Common manual evidence categories:
Use factual, audit-support language:
Reviewer concerns must not be buried. If any reviewer status is changes_requested or unresolved:
## Reviewer Notes## Unresolved Risksgrc_action reflect the unresolved stateGood evidence is anchored, scoped, and explains why it matters:
`src/routes/auth.ts:7` shows the login handler executes password verification without rate limiting middleware. This supports a high-severity A.8.5 gap because repeated failed login attempts are not throttled in the assessed source.
Bad evidence is vague or unsupported:
Authentication looks secure because the app uses a common framework.
| Control | Status | Confidence | Evidence Quality | Manual Evidence | Reviewer | GRC Action |
| --- | --- | --- | --- | --- | --- | --- |
| A.8.5 Secure Authentication | partially_implemented | 0.86 | partial | yes | approved | create_remediation_ticket |
Confidence rationale: Password hashing and session cookie evidence were present in source, but lockout, MFA policy, and access review records were not available.
Evidence quality rationale: The source anchors directly support bcrypt password verification and show missing rate limiting. The control remains partial because manual identity governance evidence is required.
Manual evidence items:
- Production MFA policy
- Access review records for privileged accounts
- Login lockout configuration export
Ticket-ready action: Add login throttling and collect production MFA/access-review evidence before claiming full implementation.