New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Ddia Principles

by luoling8192 in luoling8192/ai-coding-principles

Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann.

MITAuto-check passedDatabases

Install Ddia Principles

skills CLI
$ npx skills add luoling8192/ai-coding-principles --skill ddia-principles -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install luoling8192/ai-coding-principles ddia-principles --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/luoling8192/ai-coding-principles.git skills-src && mkdir -p .claude/skills && cp -r skills-src/ddia-principles .claude/skills/ddia-principles && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
ddia-principles
GitHub stars
173
Token cost
~4.7k tokens
SKILL.md length
1,817 words
Files
1
Skills in repo
2
Repo updated
First seen
Licence
MIT

At a glance

Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann.

  • Works in 3 steps: Via databases: Multiple code versions… → Via services (REST/RPC): Servers update… → Via async messaging: Decouples…
  • : database design
  • SKILL.md covers Part I: Foundations of Data…, Part II: Distributed Data, Part III: Derived Data and Decision Framework: Quick…
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Ddia Principles is an agent skill from luoling8192/ai-coding-principles. Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann. MUST be loaded when: designing database schemas, choosing storage engines, implementing replication or partitioning, handling distributed transactions, building batch/stream processing pipelines, choosing consistency models, implementing consensus, designing data flow architectures, evaluating trade-offs between availability and consistency, encoding/serialization decisions, data modeling (relational vs document vs graph)…

Its SKILL.md is about 4.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases, covering Database schema design, Data warehousing and Database administration. It works with Apache Kafka. The repository describes itself as: A collection of Claude Code skills that enforce coding discipline and prevent common AI coding anti-patterns. The licence is MIT.

When your agent uses it

  • : database design
  • Isolation levels
  • Batch processing
  • Stream processing

Example prompts

  • “/ddia-principles”

Requirements

  • Python 3

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Via databases: Multiple code versions coexist during rolling deploys. Data outlives code.
  2. Via services (REST/RPC): Servers update before clients. Backward compat on requests, forward compat on responses.
  3. Via async messaging: Decouples producers/consumers. Supports independent version evolution.

What it can do on your machine

Read from SKILL.md and the folder at commit 27db986. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Ddia Principles loads about 4.7k tokens when it runs. Until then it costs about 253 tokens; SKILL.md has 1,817 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~253
When it runs · the whole SKILL.md, loaded when a task matches
~4.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from luoling8192/ai-coding-principles at commit 27db986, republished under its MIT licence (© luoling8192). 1,817 words, ~4,653 tokens.

Download SKILL.mdSave it as .claude/skills/ddia-principles/SKILL.md (or your agent's skills folder).
name
ddia-principles
description
Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann. MUST be loaded when: designing database schemas, choosing storage engines, implementing replication or partitioning, handling distributed transactions, building batch/stream processing pipelines, choosing consistency models, implementing consensus, designing data flow architectures, evaluating trade-offs between availability and consistency, encoding/serialization decisions, data modeling (relational vs document vs graph), building fault-tolerant systems, or any system design and architecture discussion involving data-intensive applications. Trigger on: database design, replication, partitioning, sharding, transactions, isolation levels, consistency, consensus, CAP theorem, batch processing, stream processing, MapReduce, Kafka, event sourcing, CDC, OLTP, OLAP, B-tree, LSM-tree, data warehouse, schema evolution, encoding formats, distributed systems, fault tolerance, leader election, quorum.

Designing Data-Intensive Applications — Distilled Guide

Source: Martin Kleppmann, Designing Data-Intensive Applications Central thesis: Data is the core challenge of modern applications — not compute.

Part I: Foundations of Data Systems

Chapter 1: Reliability, Scalability, Maintainability
Three Pillars
PillarDefinitionKey Metric
ReliabilitySystem works correctly even when faults occurFault ≠ Failure; tolerate faults, prevent failures
ScalabilitySystem handles load growth gracefullyMeasure with percentiles: p50, p95, p99, p999
MaintainabilitySystem is easy to operate, understand, evolveOperability + Simplicity + Evolvability
Fault Categories
  • Hardware: Random, independent (disk, RAM, power). Mitigate with redundancy (RAID, dual power).
  • Software: Systematic bugs affecting all nodes simultaneously (leap-second bug). Mitigate with process isolation, monitoring, chaos engineering.
  • Human: #1 cause of outages (config errors). Mitigate with good abstractions, sandboxes, canary deployments, fast rollback.
Scalability Patterns
  • Vertical (scale-up): Bigger machine. Simple but has ceiling.
  • Horizontal (scale-out): More machines (shared-nothing). Complex but unlimited.
  • Elastic: Auto-scale on load detection. Good for unpredictable workloads.

Twitter fan-out case study: 4.6k writes/s but 300k reads/s. Solution: pre-compute timelines (write fan-out) for most users; read-time merge for celebrities.

Performance: Use Percentiles, Not Averages
  • p50 = median. p99 = tail latency matters for user experience.
  • Amazon: 100ms delay = 1% revenue loss.
  • Tail latency amplification: One slow backend call slows entire parallel request.
Chapter 2: Data Models & Query Languages
Model Selection Guide
ModelBest ForWeakness
RelationalStructured data, complex joins, ACID transactionsRigid schema, impedance mismatch with OOP
DocumentHierarchical data, flexible schema, data localityPoor joins, many-to-many relationships
GraphHighly connected data, variable-depth traversalsLess mature tooling, harder to partition
Schema Strategy
  • Schema-on-write (relational): Enforce structure at write time. Early error detection, migration cost.
  • Schema-on-read (document): Interpret structure at read time. Flexible but validation burden on app.
Normalization vs Denormalization
  • Normalize: Single source of truth, consistent updates, requires joins.
  • Denormalize: Faster reads, risks inconsistency, update anomalies.

Trend: Models converge — PostgreSQL supports JSON, MongoDB added joins. Choose based on access patterns, not ideology.

Chapter 3: Storage & Retrieval
Storage Engine Comparison
FeatureB-TreeLSM-Tree
Write throughputLower (in-place update + WAL)Higher (sequential append)
Read latencyMore predictableMay check multiple SSTables
Write amplificationHigherLower
Space efficiencyFragmentation possibleBetter compression
Transaction supportSimpler (lock on tree node)More complex
Used byPostgreSQL, MySQL, OracleLevelDB, RocksDB, Cassandra
OLTP vs OLAP
AspectOLTPOLAP
AccessRandom, few recordsSequential scan, millions of rows
UsersEnd usersAnalysts
DataCurrent stateHistorical events
ScaleGB–TBTB–PB
Optimize forLow latencyThroughput
Data Warehousing
  • ETL: Extract from OLTP → Transform → Load into warehouse.
  • Star schema: Central fact table (events) + dimension tables (attributes). Fact tables can have 100+ columns and petabyte scale.
  • Column-oriented storage: Store each column separately. Huge I/O savings when queries touch few columns. Enables bitmap encoding, run-length compression, vectorized processing.
Chapter 4: Encoding & Evolution
Format Comparison
FormatSize (example)SchemaEvolutionCross-language
JSON81 bytesImplicitManualExcellent
Thrift59 bytesRequiredField tagsGood
Protobuf33 bytesRequiredField tagsExcellent
Avro32 bytesRequiredName matchingGood
Compatibility Rules
  • Backward compatible: New code reads old data. (Always required)
  • Forward compatible: Old code reads new data. (Required for rolling upgrades)
  • Rule: Only add/remove fields with default values. Never reuse deleted field tags.
Data Flow Patterns
  1. Via databases: Multiple code versions coexist during rolling deploys. Data outlives code.
  2. Via services (REST/RPC): Servers update before clients. Backward compat on requests, forward compat on responses.
  3. Via async messaging: Decouples producers/consumers. Supports independent version evolution.

Avoid: Language-specific serialization (Java Serializable, Python pickle) — vendor lock-in + security risk.

Part II: Distributed Data

Chapter 5: Replication
Replication Models
ModelWritesConflictUse Case
Single-leaderOne nodeNoneMost common (PostgreSQL, MySQL)
Multi-leaderMultiple nodesMust resolveMulti-datacenter, offline clients
LeaderlessAny nodeMust resolveCassandra, Riak, Voldemort
Sync vs Async Replication
  • Sync: Durable, blocks on replica failure.
  • Async: Fast, risks data loss on leader failure.
  • Semi-sync: One replica sync, rest async. Practical compromise.
Replication Lag Problems & Solutions
ProblemSymptomSolution
Read-after-writeUser doesn't see own writeRead from leader for user's own data
Monotonic readsData goes backward in timeStick user to one replica
Consistent prefix readsCausal order violatedWrite causally related data to same partition
Conflict Resolution
  • Last-Write-Wins (LWW): Simple but loses data. Only safe if keys are immutable.
  • Merge: Union values, concatenate, CRDT data structures.
  • Application-level: Return all versions ("siblings"), let app decide.
  • Version vectors: Track causal dependencies per replica.
Quorum: w + r > n
  • w = write acknowledgments, r = read queries, n = total replicas.
  • Sloppy quorum: Accept writes on non-home nodes during partitions (hinted handoff). Improves availability, weakens consistency.
Chapter 6: Partitioning (Sharding)
Partitioning Strategies
StrategyProsCons
Key-rangeEfficient range queriesHotspot risk on sequential keys
HashEven distributionNo range queries
CompoundFirst part hashed, rest sortedMore complex, best of both
Secondary Index Partitioning
  • Local (document-based): Each partition indexes its own data. Writes simple, reads scatter-gather.
  • Global (term-based): Index partitioned by term. Reads efficient, writes update multiple partitions.
Rebalancing
  • Fixed partition count: More partitions than nodes. Redistribute on node changes. (Riak, Elasticsearch)
  • Dynamic: Split/merge based on size. (HBase, RethinkDB)
  • Proportional to nodes: Fixed partitions per node. (Cassandra)
Request Routing
  • Round-robin to any node (node forwards if needed)
  • Routing layer (partition-aware proxy)
  • Client-aware (client knows partition map)
  • ZooKeeper: Authoritative partition → node mapping. Used by HBase, Kafka.
Chapter 7: Transactions
Isolation Levels (Weakest → Strongest)
LevelPreventsAllowsImplementation
Read CommittedDirty reads, dirty writesNon-repeatable reads, lost updatesRow locks + old value copy
Snapshot Isolation+ Non-repeatable readsWrite skew, phantomsMVCC (multi-version)
SerializableEverythingNothing2PL, serial execution, or SSI
Concurrency Anomalies
AnomalyDescriptionExample
Dirty readSee uncommitted dataReading half-written transfer
Dirty writeOverwrite uncommitted dataTwo buyers "winning" same item
Lost updateRead-modify-write raceTwo concurrent counter increments
Write skewDecision based on stale readTwo doctors both going off-call
PhantomNew rows change query resultMeeting room double-booking
Serializable Implementations
  1. Serial execution: Single thread, in-memory. Fast but limited throughput. (VoltDB, Redis)
  2. Two-Phase Locking (2PL): Shared/exclusive locks held until commit. Strong but slow, deadlock-prone.
  3. SSI (Serializable Snapshot Isolation): Optimistic — execute freely, detect conflicts at commit. Best performance for read-heavy workloads. (PostgreSQL 9.1+)
Chapter 8: Troubles with Distributed Systems
The Three Unreliabilities

Networks: Async packet networks — no delivery guarantee, no timing guarantee. Cannot distinguish crash from network delay. Timeouts are the only failure detector, but no correct timeout value exists.

Clocks:

  • Wall clocks: Can jump backward (NTP correction). Never use for ordering events.
  • Monotonic clocks: Safe for elapsed time, not cross-node comparison.
  • Quartz drift: ~200ppm → 6ms error every 30 seconds.

Processes: GC pauses, VM suspension, page faults — threads stop without warning. A paused node doesn't know time passed.

Show full SKILL.md (724 more words)Show less
Key Principles
  • Fault ≠ failure: Design for partial failures. Some nodes work while others don't.
  • Truth is defined by majority: Individual nodes cannot determine system state alone. Quorum votes decide.
  • Fencing tokens: Monotonically increasing tokens prevent zombie processes from corrupting state.
  • Safety vs liveness: Safety (bad things never happen) must hold always. Liveness (good things eventually happen) may have conditions.
Chapter 9: Consistency & Consensus
Consistency Models (Strongest → Weakest)
ModelGuaranteeCost
LinearizabilityBehaves as if one copy, all ops atomicHigh latency, reduced availability during partition
Causal consistencyRespects cause-effect orderingBetter performance, partition-tolerant
Eventual consistencyReplicas converge eventuallyBest performance, weakest guarantee
Linearizability Use Cases
  • Leader election / distributed locks
  • Uniqueness constraints (usernames, filenames)
  • Cross-channel coordination (message queue + storage)
Consensus Algorithms
  • 2PC: Coordinator-based, blocking on coordinator failure. Practical but fragile.
  • Paxos/Raft/Zab: Epoch-based leader election + quorum voting. Non-blocking. Used by etcd, ZooKeeper, Consul.
  • FLP impossibility: Consensus impossible in pure async systems with crashes. Practical algorithms use timeouts.
Total Order Broadcast ≡ Consensus ≡ Linearizable CAS

These three problems are mathematically equivalent. Solving one solves all.

ZooKeeper / etcd Pattern
  • Small consensus cluster (3–5 nodes) for coordination.
  • Linearizable atomic CAS operations.
  • Failure detection via session heartbeats.
  • Applications: leader election, partition assignment, distributed locks, service discovery.

Part III: Derived Data

Chapter 10: Batch Processing
Unix Philosophy → MapReduce
  • Each program does one thing well.
  • Output of one program = input of another.
  • Immutable inputs, deterministic processing.
MapReduce Pipeline

Input → Mapper (extract key-value) → Sort/Partition → Reducer (aggregate by key) → Output

Distributed Join Strategies
Join TypeWhenHow
Sort-mergeBoth inputs largeSort by join key, merge in reducer
Broadcast hashOne input small (fits in RAM)Load small side as hash table
Partitioned hashBoth inputs partitioned identicallyPer-partition hash join
  • Treat entire workflow as single job.
  • Pipeline intermediate results (avoid full materialization to HDFS).
  • Keep data in memory where possible.
  • Track computation lineage for fault recovery (RDDs).
  • Support iterative algorithms (graph processing via Pregel/BSP model).
Chapter 11: Stream Processing
Message Broker Models
ModelDeliveryOrderingReplayUse Case
AMQP/JMSPer-message ack, delete afterNo ordering guaranteeNoTask queues, async RPC
Log-based (Kafka)Offset-based, retainedPer-partition orderingYesEvent streaming, CDC
Change Data Capture (CDC)

Extract database changes as event stream → keep derived systems (search indexes, caches, warehouses) in sync. Source of truth stays in database; derived views are consumers.

Event Sourcing

Model state as append-only sequence of business events (not DB operations). Events are immutable facts. Current state = fold over event history.

Stream Joins
JoinInput AInput BState
Stream-StreamEventsEventsTime-windowed buffer
Stream-TableEventsDB snapshot (via CDC)Local materialized table
Table-TableCDC streamCDC streamDerived materialized view
Time & Windowing
WindowDescription
TumblingFixed-size, non-overlapping (e.g., every 1 min)
HoppingFixed-size, overlapping (e.g., 1 min window every 30s)
SlidingAll events within time threshold of each other
SessionGrouped by activity gap (e.g., 30 min inactivity)

Event time ≠ processing time. Always use event time for correctness. Handle late events with watermarks or correction publishes.

Processing Guarantees
  • Microbatching (Spark Streaming): ~1s latency, atomic small batches.
  • Checkpointing (Flink): Periodic snapshots with message barriers.
  • Idempotency: Deduplicate using message offsets or unique IDs.
  • End-to-end exactly-once requires idempotent output + deduplication.
Chapter 12: The Future of Data Systems
Data Integration Pattern

No single database does everything. Use event log as integration backbone:

  1. All writes go through authoritative event log.
  2. Derived systems (indexes, caches, ML models) consume the log.
  3. Deterministic, idempotent functions transform between layers.
Unbundling Databases

Separate concerns:

  • Record system: Captures authoritative writes.
  • Derived systems: Indexes, caches, materialized views consume change streams.
  • Enables gradual migration — run old and new systems in parallel.
End-to-End Exactly-Once

Low-level guarantees (TCP, DB transactions) don't ensure application correctness. Require:

  • Operation identifiers: UUID-based deduplication at application level.
  • Idempotent operations: Same effect whether executed once or many times.
  • Unique constraint enforcement: Via partitioned stream processing.
Async Constraint Enforcement

Instead of distributed transactions:

  1. Route requests by constraint field to partitioned log.
  2. Stream processor sequences competing requests.
  3. Reject violations, notify clients via output stream.
  4. Some applications tolerate temporary violations with compensating transactions.
Auditability
  • Treat data like immutable event log — enables reconstruction and verification.
  • Implement cryptographic audit trails (Merkle trees).
  • Periodically test backup restoration and data reconstruction.

Decision Framework: Quick Reference

Choosing a Data Model
Many-to-many relationships?     → Relational or Graph
Hierarchical / nested data?     → Document
Highly connected data?          → Graph
Flexible / evolving schema?     → Document (schema-on-read)
Strong consistency required?    → Relational (ACID)
Choosing a Storage Engine
Write-heavy workload?           → LSM-tree (RocksDB, Cassandra)
Read-heavy, predictable?        → B-tree (PostgreSQL, MySQL)
Analytical queries?             → Column store (ClickHouse, Redshift)
Full-text search?               → Inverted index (Elasticsearch)
Choosing a Replication Strategy
Single datacenter?              → Single-leader
Multi-datacenter?               → Multi-leader
Offline-first clients?          → Multi-leader or Leaderless
Maximum availability?           → Leaderless with sloppy quorum
Strong consistency?             → Single-leader with sync replication
Choosing an Isolation Level
Read-only analytics?            → Snapshot isolation
General OLTP?                   → Read committed (default in most DBs)
Financial / critical?           → Serializable (prefer SSI over 2PL)
High write contention?          → Serial execution (if data fits in RAM)
Choosing Batch vs Stream
Historical data reprocessing?   → Batch (Spark, Flink batch mode)
Real-time derived views?        → Stream (Kafka + Flink/Spark Streaming)
Both needed?                    → Unified engine (Flink) over Lambda architecture

© luoling8192, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in ddia-principles of luoling8192/ai-coding-principles.

Open the folder on GitHubat commit 27db986

Compare with similar skills

Ddia Principles next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Ddia Principles compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Ddia Principles this skillluoling8192/ai-coding-principles173—~4.7kAutomated safety check: PassMIT
AWS Storageaws/agent-toolkit-for-aws2.8k—~5.8kAutomated safety check: PassApache-2.0
DB SculptorEliasOulkadi/shokunin114—~3.1kAutomated safety check: NotesMIT
Opensourcefaqdigoal/blog8.6k—~966Automated safety check: PassGPL-2.0
Monitoring Ingestion PipelinePostHog/posthog40k—~9.1kAutomated safety check: PassCustom licence
Io ConnectorsKilo-Org/kilo-marketplace190—~1.3kAutomated safety check: PassApache-2.0

Similar skills

  • AWS Storage

    aws/agent-toolkit-for-aws

    Official

    Selects, investigates, and compares AWS object, file, and block storage services, and answers cost, performance, configuration, security, and troubleshooting questions about storage services.

    2.8k GitHub stars~5.8k tokensUpdated yesterday
    DatabasesAuto-check passed

  • DB Sculptor

    EliasOulkadi/shokunin

    Design database schemas with Prisma/Drizzle, PostgreSQL index strategy (B-tree, GIN, GiST, BRIN, Hash), query optimization (EXPLAIN ANALYZE), migration safety (expand/contract, zero-downtime), and…

    114 GitHub stars~3.1k tokensUpdated 4 days ago
    DatabasesAuto-check: notes

  • Opensourcefaq

    digoal/blog

    解答与开源产品有关的深度技术问题，输出图文并茂的 Markdown 技术文章。触发条件：用户提出与开源项目（如 PostgreSQL、Redis、Kafka、Kubernetes、ClickHouse、Flink 等）相关的技术问题，并提供源码目录或 URL、deepwiki repo 名称。即使用户只说"帮我解答这个开源问题"或"分析一下这个项目的某个机制"，也应使用本…

    8.6k GitHub stars~966 tokensUpdated 11 days ago
    DatabasesAuto-check passed

  • Monitoring Ingestion Pipeline

    PostHog/posthog

    Official

    Guide for using the Grafana MCP to monitor and diagnose the Node.js ingestion pipeline workers in production.

    40k GitHub stars~9.1k tokensUpdated today
    DevOps & CloudAuto-check passed

  • Io Connectors

    Kilo-Org/kilo-marketplace

    Guides development and usage of I/O connectors in Apache Beam.

    190 GitHub stars~1.3k tokensUpdated 10 days ago
    DatabasesAuto-check passed

  • Event Store Design

    wshobson/agents

    Designs event stores for event-sourced systems: requirements, a comparison of EventStoreDB, PostgreSQL, Kafka, DynamoDB and Marten, and stream and versioning practices.

    40k GitHub starsUsed in 9 repos~828 tokens
    Backend & APIsAuto-check passed

More from luoling8192/ai-coding-principles

  • AI Coding Discipline

    luoling8192/ai-coding-principles

    Mandatory coding discipline rules that prevent common AI coding anti-patterns.

    173 GitHub stars~1.9k tokensUpdated 6 mo ago
    Auto-check passed

Works with

Categories

Questions about Ddia Principles

What does Ddia Principles do?

Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann. Ddia Principles is an agent skill from luoling8192/ai-coding-principles. Designing Data-Intensive Applications (DDIA) distilled reference guide by Martin Kleppmann.

When should I use Ddia Principles?

Ddia Principles fits situations like: : database design; isolation levels; batch processing; stream processing.

How do I install Ddia Principles in Claude Code?

Run `npx skills add luoling8192/ai-coding-principles --skill ddia-principles -a claude-code`. Or copy the skill folder (ddia-principles in luoling8192/ai-coding-principles) into .claude/skills/ddia-principles in your project. Claude Code loads it when a task matches its description.

How do I install Ddia Principles in Codex?

Run `npx skills add luoling8192/ai-coding-principles --skill ddia-principles -a codex`. Or copy the skill folder (ddia-principles in luoling8192/ai-coding-principles) into .agents/skills/ddia-principles in your project. Codex loads it when a task matches its description.

Can I use Ddia Principles in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add luoling8192/ai-coding-principles --skill ddia-principles -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ddia-principles, .gemini/skills/ddia-principles, .github/skills/ddia-principles and .opencode/skills/ddia-principles in your project.

What does Ddia Principles need to run?

SKILL.md names no scripts, command-line tools or credentials: Ddia Principles is instructions for the agent only. Our summary lists: Python 3.

Does Ddia Principles access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Ddia Principles safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Ddia Principles use?

Ddia Principles is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Ddia Principles use?

About 4.7k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Ddia Principles?

Skills that share tags, products or a category with Ddia Principles: AWS Storage (aws/agent-toolkit-for-aws, 2.8k stars), DB Sculptor (EliasOulkadi/shokunin, 114 stars), Opensourcefaq (digoal/blog, 8.6k stars) and Monitoring Ingestion Pipeline (PostHog/posthog, 40k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Ddia Principles?

luoling8192 (a GitHub user) maintains it in luoling8192/ai-coding-principles, which has 173 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on March 26, 2026.

Source: luoling8192/ai-coding-principles on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.