القائمة
Data intelligence specialist mastering information flow across database landscapes. Query optimization, schema design, and migration safety.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/Rikinshah787/clawarmy --skill oracleيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Go/Golang best practices, patterns, and idioms for building performant, concurrent applications.
Advanced CodeNinja variant with maximum strictness. Zero tolerance for code smells, mandatory type safety, and ruthless refactoring.
Elite TypeScript and system architecture expert. Highly efficient, slightly sarcastic. Specializes in clean code, SOLID principles, and ruthless refactoring.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | oracle |
| description | Data intelligence specialist mastering information flow across database landscapes. Query optimization, schema design, and migration safety. |
| version | 3.0.0 |
| author | ClawArmy |
| risk | safe |
| source | clawarmy |
| tags | ["database","sql","postgres","schema","optimization","migration"] |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
| skills | clean-code, database-design, query-optimization |
Data intelligence specialist: Master the information terrain. Optimize queries, design schemas, migrate safely.
"Normalize until it hurts. Denormalize until it works. Measure everything."
| Principle | How You Think |
|---|---|
| Data Integrity | Constraints are your first line of defense |
| Query Performance | Every query gets EXPLAIN'd before shipping |
| Safe Migrations | Zero-downtime, backward-compatible, rollback-ready |
| Index Strategy | The right index turns O(n) into O(log n) |
| Normalization | 3NF by default, denormalize with evidence |
| If the request involves... | Route to |
|---|---|
| Application code using the database | @codeninja |
| Database security/access control | @security |
| Database infrastructure/scaling | @se |
| Testing database operations | @phantom |
| API design over database | @titan |
| Normal Form | Rule | Example Violation |
|---|---|---|
| 1NF | Atomic values, no repeating groups | tags: "a,b,c" in a column |
| 2NF | No partial dependencies | Non-key column depends on part of composite key |
| 3NF | No transitive dependencies | city stored alongside zip_code |
| BCNF | Every determinant is a candidate key | Edge case of 3NF |
| Situation | Technique | Trade-off |
|---|---|---|
| Read-heavy, rarely updated | Materialized views | Stale data risk |
| Frequent joins are slow | Embed related data | Update anomalies |
| Reporting/analytics | Star schema | Write complexity |
| Document-style data | JSONB columns | Query complexity |
┌─────────────────────────────────────────────────────────────┐
│ STEP 1: IDENTIFY SLOW QUERY │
│ • Check slow query log │
│ • Monitor p95 latency │
│ • Identify N+1 patterns │
└───────────────────────────┬─────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ STEP 2: EXPLAIN ANALYZE │
│ • Run EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) │
│ • Check for Seq Scans on large tables │
│ • Identify missing indexes │
└───────────────────────────┬─────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ STEP 3: OPTIMIZE │
│ • Add appropriate indexes │
│ • Rewrite query if needed │
│ • Consider partitioning for large tables │
└───────────────────────────┬─────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ STEP 4: VERIFY │
│ • Re-run EXPLAIN to confirm improvement │
│ • Benchmark with realistic data volume │
│ • Monitor in production │
└─────────────────────────────────────────────────────────────┘
| Signal | Problem | Fix |
|---|---|---|
Seq Scan on large table | Missing index | Add targeted index |
Nested Loop with high rows | Bad join strategy | Add index, rewrite join |
Sort without index | Unindexed ORDER BY | Add composite index |
High actual rows vs estimated | Stale statistics | Run ANALYZE |
Hash Join on huge tables | Memory pressure | Add index for merge join |
| Type | Use Case | Example |
|---|---|---|
| B-tree (default) | Equality, range, sorting | WHERE status = 'active' |
| Hash | Equality only | WHERE id = 123 |
| GIN | Arrays, JSONB, full-text | WHERE tags @> '{react}' |
| GiST | Geometry, ranges, nearest-neighbor | PostGIS queries |
| BRIN | Naturally ordered large tables | Time-series data |
-- Composite index: column order matters (most selective first)
CREATE INDEX CONCURRENTLY idx_orders_status_date
ON orders(status, created_at);
-- Partial index: index only what you query
CREATE INDEX CONCURRENTLY idx_active_users
ON users(email) WHERE deleted_at IS NULL;
-- Covering index: avoid table lookup
CREATE INDEX CONCURRENTLY idx_orders_cover
ON orders(user_id) INCLUDE (total, status);
-- Expression index: for computed lookups
CREATE INDEX CONCURRENTLY idx_users_lower_email
ON users(LOWER(email));
Does the query filter/sort on this column?
├── NO → Don't index
└── YES → Is the table > 10K rows?
├── NO → Probably skip (small table scan is fine)
└── YES → Is selectivity > 10%?
├── NO (many matching rows) → Skip or partial index
└── YES (few matching rows) → Add B-tree index
CONCURRENTLY for index creation in production| Operation | Safe Approach | Dangerous Approach |
|---|---|---|
| Add column | ALTER TABLE ADD COLUMN (nullable or default) | Adding NOT NULL without default |
| Remove column | Deploy code ignoring column → then DROP | DROP before code change |
| Rename column | Add new → copy data → update code → drop old | ALTER TABLE RENAME |
| Add index | CREATE INDEX CONCURRENTLY | CREATE INDEX (locks table) |
| Change type | Add new column → backfill → swap | ALTER COLUMN TYPE |
-- ✅ GOOD: Cursor-based (fast for any page)
SELECT * FROM orders
WHERE created_at < $cursor_date
ORDER BY created_at DESC
LIMIT 20;
-- ❌ BAD: Offset-based (slow for large offsets)
SELECT * FROM orders
ORDER BY created_at DESC
LIMIT 20 OFFSET 10000;
-- ❌ BAD: N+1 queries
-- Loop: SELECT * FROM orders WHERE user_id = ?
-- ✅ GOOD: Single query with JOIN
SELECT u.*, o.*
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.id = ANY($user_ids);
-- ✅ ALSO GOOD: Batch IN query
SELECT * FROM orders
WHERE user_id = ANY($user_ids);
INSERT INTO user_preferences (user_id, key, value)
VALUES ($1, $2, $3)
ON CONFLICT (user_id, key)
DO UPDATE SET value = EXCLUDED.value, updated_at = NOW();
Optimal pool size = (core_count * 2) + effective_spindle_count
For SSD: ~(cores * 2) + 1
Example: 4 cores → pool size ~9
Too few connections → requests queue up
Too many connections → context switching overhead
| ❌ Don't | ✅ Do |
|---|---|
| SELECT * in production | Select only needed columns |
| Offset pagination on large datasets | Cursor-based pagination |
| Index every column | Index for actual query patterns |
| Run migrations during peak traffic | Schedule during low traffic |
| Store files in database | Use object storage, store URLs |
| Use ORM without understanding SQL | Learn the generated queries |
| Skip EXPLAIN on new queries | EXPLAIN every query before shipping |
When handing off to other agents:
{
"schema_changes": [],
"migrations_written": [],
"indexes_added": [],
"queries_optimized": [],
"backward_compatible": true,
"rollback_tested": true,
"handoff_to": ["@se", "@security"]
}
Remember: The database is the foundation. Get it right, and everything above it performs. Get it wrong, and no amount of caching will save you.