grick-ato-intake

name	grick-ato-intake
description	Produce a strict GRiCk ATO intake JSON package from a software repository, including a Mermaid architecture diagram, technology explanation, security posture, evidence requests, and manual follow-up questions for details that cannot be inferred from code.

GRiCk ATO Intake

Use this skill inside an application repository when a GRC team requests an Authority to Operate intake package for GRiCk.

Output Rule

Return exactly one JSON object and no Markdown. The object must conform to references/ato-intake.schema.json and use:

{
  "schemaVersion": "grick-ato-intake/v1"
}

Do not invent business facts. If a required fact cannot be inferred from repository files, ask the user for it. If the user cannot answer, include it in manualFollowUp with a clear question, reason, and suggested owner.

Workflow

1. Inspect repository structure, dependency manifests, infrastructure files, CI/CD config, environment examples, API routes, database schema, auth/session code, logging, secrets usage, storage, integrations, and deployment config.
2. Build an in-depth technology explanation covering runtime, frameworks, data stores, infrastructure, CI/CD, observability, integrations, and critical dependencies.
3. Produce a Mermaid diagram in architecture.mermaidDiagram. Prefer flowchart TD unless the repository clearly has a better C4 or sequence shape.
4. Identify components, data flows, trust boundaries, internet exposure, authentication, authorization, secrets, encryption, audit logging, vulnerability management, backup/recovery, privacy and data handling.
5. Ask concise follow-up questions for missing ATO details such as business owner, data classification, production hosting, external vendors, recovery objectives, support model, or manual controls.
6. Return only strict JSON. No comments, no trailing commas, no prose before or after the JSON.

Required Manual Questions

Prompt the user for these when not obvious from code:

• Business owner and technical owner.
• Production environment and hosting boundary.
• Data classification and sensitive data types.
• User groups/personas.
• External vendors and data shared.
• Recovery objectives, backup owner, and restore testing.
• Operational support team and vulnerability remediation process.
• Known risks, compensating controls, and existing evidence locations.

Quality Bar

• architecture.components must include every major runtime/service that materially affects risk.
• architecture.dataFlows must include protocols, data types, encryption, and authentication.
• technology.dependencies must focus on critical/security-relevant dependencies, not every package.
• atoEvidence.recommendedEvidenceRequests must be actionable for a GRC assessor.
• manualFollowUp is required even if empty.