Cyber Engagement Planning
Priority: P0 (CRITICAL)
Produce a reviewable plan that separates intended activity from host-enforced permission.
Structure
textcyber-engagement-planning/ ├── SKILL.md ├── references/engagement-brief.md └── evals/evals.json
Workflow
- State objective, success observation, engagement/scope reference, dates, and accountable owner.
- List in-scope synthetic assets or explicitly authorized targets; list exclusions and non-goals.
- Assign requester, approver, operator, exercise control, adjudicator, and escalation roles.
- Record allowed actions, prohibited actions, data handling, communications, and runtime controls.
- Define expiry, stop triggers, restart authority, evidence fields, and unresolved decisions.
- Mark live execution
blockedand the plan offline-only when required runtime support is absent; never imply production readiness. - Restart requires both current authorization and verified host enforcement of scope. Owner approval, risk acceptance, documented exceptions, or proposed compensating controls cannot waive either prerequisite; unverified alternatives keep the live lane blocked.
Rules
- Plan only; do not include payloads, attack commands, credentials, real targets, or destructive steps.
- Treat production modifications as separately approved actions.
- Reuse authorization, evidence, and mapping.
- Use primary framework sources; mark uncertain mappings explicitly.
Plan evidence fields explicitly:
engagement_scope_ref,skill_version,source,observed_at,finding_status,evidence_refs,limitations, andaccountable_owner.
Anti-Patterns
- No implied authorization: A completed plan is not approval.
- No vague scope: Name boundaries and exclusions.
- No hidden runtime dependency: State unsupported controls and block live work.
- No team-color shortcut: Roles do not replace authorization.


