ato-package-acceleration

name	ato-package-acceleration
description	Use when a GRC engineer needs to create, review, or tighten ATO and compliance work products, including SSP outlines, control narratives, evidence requests, POA&M or risk items, architecture diagram prompts, and assessor-ready Q&A across FedRAMP Rev. 5, FedRAMP 20x, or CMMC contexts.

ATO Package Acceleration

Use this skill to turn messy system context into practical compliance artifacts. Keep the work workflow-first: start from the system and the package goal, then apply framework overlays only where they clarify the next deliverable.

Operating Posture

• Treat the user as a GRC engineer or internal compliance lead trying to move real package work forward.
• Prefer concrete artifacts over abstract framework summaries.
• Preserve uncertainty. Call out assumptions, missing evidence, and blind spots directly.
• Keep interview-adjacent or positioning motives subtle; write artifacts as normal GRC work products.
• Do not pretend the system is compliant because a narrative is polished.
• If source evidence is missing, produce report-only checklist items and evidence requests before inventing conclusions.

Workflow Spine

1. Intake and boundary
2. Data classification and deployment model
3. Control applicability and inheritance
4. Implementation narratives
5. Evidence plan
6. Risk register and POA&M
7. Architecture diagram prompts
8. Assessor and auditor Q&A prep

First Questions

Ask only what is needed for the next artifact. Good defaults:

• What system or package are we working on?
• Which output do you need first: SSP outline, control narratives, evidence plan, risk/POA&M, diagram prompt, or assessor Q&A?
• Which overlay matters right now: FedRAMP Rev. 5, FedRAMP 20x, CMMC, or a blended internal view?

If the user gives enough context, start producing the artifact instead of continuing discovery.

Output Patterns

SSP Outline

Include:

• System purpose
• Authorization boundary
• Users and external connections
• Data types and impact assumptions
• Shared services and inherited controls
• Core security services
• Open questions and blind spots

Control Narrative

Use this structure:

• Control or requirement
• Applicability
• Implementation summary
• Responsible owner
• Inherited components
• Evidence references
• Gaps or risks
• Assessor notes

Evidence Plan

Use a table with:

• Evidence item
• Control or requirement mapping
• Source system
• Owner
• Collection method
• Freshness expectation
• Gaps or caveats

Risk Or POA&M Item

Use:

• Finding
• Affected requirement
• Impact
• Likelihood
• Current compensating controls
• Remediation plan
• Owner
• Target date
• Evidence needed for closure

Assessor Q&A

Answer directly, then support with:

• Evidence pointer
• Expected follow-up question
• Weak spot or caveat
• Suggested remediation or clarification

Framework Overlay Rules

• FedRAMP Rev. 5: anchor on NIST SP 800-53 Rev. 5 control families, inheritance, SSP clarity, assessment evidence, and authorization package consistency.
• FedRAMP 20x: emphasize automation readiness, machine-readable evidence, continuous reporting, and API-backed validation where known.
• CMMC: distinguish policy/process maturity from technical implementation evidence; keep contractor environment, CUI, and scoping assumptions visible.

Do not force every artifact into all frameworks. Pick the overlay that matches the user's stated goal, and add a crosswalk only when it helps.

References

• references/workflow-spine.md
• references/framework-overlays.md
• templates/evidence-plan.md