| 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
- 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.
- Build an in-depth technology explanation covering runtime, frameworks, data stores, infrastructure, CI/CD, observability, integrations, and critical dependencies.
- Produce a Mermaid diagram in
architecture.mermaidDiagram. Prefer flowchart TD unless the repository clearly has a better C4 or sequence shape.
- Identify components, data flows, trust boundaries, internet exposure, authentication, authorization, secrets, encryption, audit logging, vulnerability management, backup/recovery, privacy and data handling.
- 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.
- 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.
