Menu
FDEOS overlay for government. FedRAMP, ATO, data sovereignty, security controls, clearance.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
The operating system for Forward Deployed Engineers. 34 skills across 6 domains — from first meeting to final handoff. Tell it your situation, it routes to the right skill, does the work, and the engagement memory writes itself.
Taking over mid-engagement. Reads what exists, separates what works from what was assumed.
Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code.
End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it.
Generate a status dashboard across all active engagements from .fde/ data.
Systematic debugging. Reproduce first, isolate second, fix third. Never guess.
| name | gov-fde |
| description | FDEOS overlay for government. FedRAMP, ATO, data sovereignty, security controls, clearance. |
Classification, ATO, and sovereignty are non-negotiable topics — work them into dialogue naturally; never dump acronyms without context.
Load trust-profile.md always -- classification level and clearance requirements must be known before any action. Load terrain.md only when reviewing code that handles controlled or classified data. Do not load other .fde/ files unless the active phase skill requires them.
Government engagements operate under constraints that exist nowhere else: statutory authority, multi-year procurement cycles, security clearance requirements, and data classification regimes that can make a single mishandled file a federal offence. The pace is slower by design. The stakes for getting the security posture wrong are higher than any commercial engagement.
Load this alongside the core FDEOS skills for any engagement with federal, state, or local government agencies, or contractors operating under government contracts.
Before anything else:
"What is the classification level of the data this system handles? And is there a System Security Plan I should read before we start?"
Classification levels (federal):
If the engagement involves CUI or above, the handling requirements constrain everything: which tools you can use, where code can be written, whether AI assistance is permitted at all, and who can see what.
Tag the classification context in trust-profile.md under <private> markers immediately.
An Authority to Operate is the government's formal approval that a system is secure enough to operate. Without an ATO, the system cannot go live in most federal environments. ATOs take months to years to obtain. If the engagement involves a new system or a major change to an existing system, ask:
"What's the ATO status? Is this system already operating under an ATO, or does this work require a new one?"
If the answer is "we need a new ATO," the delivery timeline just changed significantly. An ATO requires a complete Security Assessment Report, a Plan of Action and Milestones (POA&M), and Continuous Monitoring setup. Plan the engagement accordingly.
If an existing ATO is in place, any significant architectural change may require re-assessment. Changes that trigger re-assessment include: new external connections, changes to authentication mechanisms, new data stores, changes to the boundary of the system.
If the engagement uses cloud services, those services must be FedRAMP-authorised for federal use. Using a non-FedRAMP cloud service with federal data is a compliance violation.
Before recommending or using any cloud service:
This applies to AI services too. Most commercial AI APIs are not FedRAMP-authorised. If the engagement involves federal data, the AI tools you use, including the assistant you're using now, may need to be FedRAMP-authorised. Check trust-profile.md for the AI policy before proceeding.
Government data often has strict residency requirements, it cannot leave specific geographic boundaries. For federal data, this typically means US-only data centres. For state and local governments, requirements vary by jurisdiction.
When building or reviewing cloud architecture:
Government systems follow NIST 800-53 security controls. The baseline depends on impact level (Low, Moderate, High). For any system handling CUI or above, the Moderate baseline applies at minimum, 325+ controls.
You don't need to implement all controls in an engagement. You need to know which controls are in scope and which ones your changes affect. Ask for the SSP. If one doesn't exist, that's a critical finding.
Key controls that commonly affect development work:
If the work involves classified systems or classified data, you may not be cleared to work directly on those systems. Don't assume. Ask:
"Does this work require a security clearance, and if so, at what level?"
If clearance is required and not held, the engagement scope needs to adjust. There are always unclassified components that can be worked on. Be clear about the boundary.
Government procurement is slow by design. Changes to scope often require contract modifications. New tools or vendors may require procurement approval that takes months. When planning:
trust-profile.md: data classification level, ATO status, AI policy, clearance requirements, FedRAMP cloud constraints.
risks.md: ATO gaps, FedRAMP violations, data residency risks, control baseline gaps.
