القائمة
Use for implementing and enforcing project backup safety, including mandatory backup scripts or scheduled backups, restore verification, retention policies, and pre-change backup gates.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for executing and enforcing governance tooling (artifact generation/validation/CI policy checks), including startup declaration checks, project-index sync checks, and repository skill-policy validation.
Use for converting ambiguous requests into explicit implementation contracts via assumptions, acceptance criteria, non-goals, constraints, and scope boundaries before major execution.
Use for selecting and enforcing the right process level across skills via deterministic risk scoring, mode-based gates, critical overrides, break-glass controls, ownership, and KPI review.
Use for minimizing token usage while preserving quality, through strict context filtering, indexed history retrieval, concise reasoning formats, output budgeting, and low-overhead execution patterns.
Use for managing the lifecycle of obsolete, superseded, merged, or renamed skills and docs with clear replacement paths, migration notes, validator warnings, and removal criteria.
Use for capping process overhead by task size, limiting skill count, validation depth, artifact creation, and user-facing ceremony before other governance or documentation skills expand scope.
| name | project-backup |
| description | Use for implementing and enforcing project backup safety, including mandatory backup scripts or scheduled backups, restore verification, retention policies, and pre-change backup gates. |
MissionHard PolicyTrigger ExamplesBackup Scope ModelData ClassificationRPO/RTO Definitions (Required)Mandatory Workflow (Step 1-8)Backup Script RequirementsBackup Targets and ExclusionsEncryption and Access ControlOffsite/Redundancy GuidanceMonitoring and AlertingPre-Change Backup GatesRestore Runbook RequirementsVerification ChecklistCommon Failure ModesAnti-Patterns to AvoidThis Project: Practical BaselineDeliverable FormatEnsure every project has reliable, restorable backups before risky changes can cause data/code loss.
Every project must satisfy at least one of these:
Preferred policy:
If neither exists, create one before proceeding with high-risk changes.
Compliance states:
script_only: compliantscheduled_only: compliantscript_and_scheduled: preferrednone: non-compliant (block risky changes)Enforcement:
none, create remediation plan immediatelyUse for backup setup, backup audits, or any risky change requiring recovery guarantees.
Define scope first. Backups that miss critical assets are not valid.
Potential assets:
Classify data by criticality:
Tier 1 (business critical):
Tier 2 (operationally important):
Tier 3 (reconstructable):
Backup design must guarantee Tier 1 and Tier 2 protection.
Before finalizing backup strategy, define:
Minimum recommendations for active development:
For high-value production data, tighten further.
Follow in order.
Create a backup inventory:
For each critical asset, determine:
Any "no" for Tier 1 assets is a blocker for risky changes.
Define strategy per asset:
Enforce at least one valid implementation path:
Path A: Repository backup script
scripts/backup.sh or scripts/backup.ps1)Path B: Scheduled backup process
If project is cross-platform and using Path A, provide platform-specific scripts or one portable runtime script.
Define cadence appropriate to compliance state:
scheduled_only or script_and_scheduled: periodic scheduled backups (daily minimum for active projects).Notes:
script_only, a minimal scheduler recommendation should still be documented.scheduled_only, include a manual "run-now" procedure in the runbook.Define retention windows:
Example baseline:
Backups are incomplete without restore testing.
Required:
At regular intervals:
Backup scripts should implement:
Default include candidates:
Default exclusions:
node_modules, .venv, build caches).next, temp files)Note:
.env from repo is correct, but production secret values still need secure backup in a secrets system.For offsite backups or sensitive data:
Follow 3-2-1 principle where possible:
Local-only backups are not sufficient for disaster scenarios.
Before risky operations (schema migration, mass refactor, dependency major upgrade):
Maintain a concise restore runbook that includes:
Use this checklist for completion:
script_only, scheduled_only, or script_and_scheduledIf automation exists, require:
When applying this skill, produce:
For projects like this stack (frontend/backend/media):