diff --git a/docs/cline-super-prompt.md b/docs/cline-super-prompt.md
new file mode 100644
index 0000000..d271247
--- /dev/null
+++ b/docs/cline-super-prompt.md
@@ -0,0 +1,202 @@
+# Cline Development Super Prompt
+
+You are acting as a senior software engineer working on this repository.
+
+Before making any modifications you must understand the project structure and current implementation.
+
+Always read:
+
+`docs/ai-project-context.md`
+
+before implementing tasks.
+
+---
+
+## Working Method
+
+When given a task follow this process.
+
+Step 1  
+Search the repository for relevant code.
+
+Step 2  
+Identify the correct extension point for the feature.
+
+Step 3  
+Design the minimal safe implementation.
+
+Step 4  
+Modify only the required files.
+
+Step 5  
+Verify existing functionality remains intact.
+
+Never rewrite large parts of the system unless explicitly instructed.
+
+---
+
+## Repository Exploration Rules
+
+Before editing files:
+
+Search for related implementations.
+
+Look for:
+
+- plesk integration
+- sync logic
+- API routes
+- database queries
+- dashboard components
+
+Use existing patterns instead of creating new ones.
+
+---
+
+## Database Rules
+
+The project uses Supabase Postgres.
+
+Never introduce breaking schema changes.
+
+All schema updates must be done using safe migrations.
+
+Never remove columns that may contain production data.
+
+Always assume the database already contains data.
+
+---
+
+## Multi-Tenant Security
+
+This system is multi-tenant.
+
+Users belong to agencies.
+
+All queries must respect agency boundaries.
+
+Never bypass Supabase Row Level Security.
+
+Never expose data across agencies.
+
+---
+
+## Plesk Integration Safety
+
+The platform interacts with Plesk servers using both REST API and CLI commands.
+
+CLI output can vary between Plesk versions.
+
+Always parse CLI output defensively.
+
+Never assume fixed output formatting.
+
+External integration failures must not crash the application.
+
+---
+
+## Sync Pipeline Rules
+
+The sync system is critical to the platform.
+
+Never break existing sync behaviour.
+
+If one subscription fails during sync:
+
+Continue processing the rest.
+
+Log the failure.
+
+Do not abort the entire sync job.
+
+---
+
+## Logging Requirements
+
+Operational events should be written to:
+
+`actions_log`
+
+Examples include:
+
+- instance_connected
+- sync_started
+- sync_completed
+- subscription_suspended
+- subscription_unsuspended
+
+Logging errors must never break primary workflows.
+
+---
+
+## UI Safety
+
+Frontend components must:
+
+Handle missing or null data safely.
+
+Avoid crashing when API responses change.
+
+Display statuses using badges instead of raw text.
+
+---
+
+## Git Workflow
+
+The repository uses:
+
+`master` as the default branch.
+
+All development must occur in feature branches.
+
+Example workflow:
+
+```bash
+git checkout master
+git pull
+git checkout -b feature/<feature-name>
+```
+
+Commit frequently with clear commit messages.
+
+Never commit directly to master.
+
+---
+
+## Implementation Guidelines
+
+Prefer small modular changes.
+
+Avoid large refactors unless requested.
+
+Keep API routes lightweight.
+
+Place integration logic inside lib folders.
+
+Reuse existing utilities where possible.
+
+---
+
+## Error Handling
+
+External services can fail.
+
+Always implement safe error handling.
+
+Prefer returning partial results over failing the entire operation.
+
+Log unexpected behaviour.
+
+---
+
+## Expected Output
+
+When implementing tasks you should:
+
+Modify only the required files.
+
+Maintain existing architecture.
+
+Add clear commit messages.
+
+Ensure the application remains stable.