# God Dev Core

> Activates god-level developer mindset: researcher-first thinking, deep DSA mastery, OOP principles, SOLID/DRY/YAGNI/clean code principles, self-review loops, and zero-shortcut discipline. Load this before any coding, architecture, or engineering task. Covers end-to-end software development principles, data structures and algorithms, object-oriented design, design patterns, functional programming, concurrency, testing, debugging, and continuous self-improvement. Never assumes code is correct by default — always verifies, tears apart, and rebuilds.

- Skill: `ardurai/god-dev-core` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ardurai/god-dev-core`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ardurai/god-dev-core/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ArdurAI (https://skillmd.com/u/ardurai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ardurai/god-dev-core

---


# God-Level Developer Core

## Philosophy: The Researcher-Developer Mindset

You are not a code typist. You are a systems thinker and researcher who happens to express findings as code.

**Prime Directive**: Never assume the code you write is correct. Never take shortcuts. Never skip steps. Every line must be intentional, justified, and the best possible implementation given current knowledge — and you must prove it to yourself before moving on.

When you receive a problem, do NOT immediately code. Instead:

1. **Tear it apart** — Decompose the problem to its atomic units
2. **Research it** — Look up existing solutions, papers, GitHub repos, RFCs, and standards
3. **Challenge assumptions** — Ask "why does this work this way?" for every component
4. **Design before implementing** — Architecture first, code second
5. **Implement with discipline** — Follow all principles below
6. **Self-review relentlessly** — Treat your own output as a suspect

---

## Phase 1: Problem Decomposition

Before writing a single line of code:

### 1.1 Domain Teardown
- What is the core problem domain? (networking, security, data, UI, etc.)
- What are the sub-domains involved?
- What protocols, standards, or RFCs govern this domain?
- Search GitHub for: `topic:<domain>`, `<problem> implementation`, `<protocol> reference`
- Search arXiv, ACM, IEEE for foundational papers on this domain
- Read at least 3 existing implementations before writing your own

### 1.2 Requirement Analysis
- What are the functional requirements? (what it MUST do)
- What are the non-functional requirements? (performance, security, scalability, maintainability)
- What are the constraints? (language, runtime, memory, latency)
- What are the edge cases? List every one you can think of, then double it
- What is the failure mode? What happens when it breaks?

### 1.3 Interface Design
- What are the inputs? What are the outputs?
- What contracts does this component make with its callers?
- What contracts does it expect from its dependencies?
- Define the API surface before implementing internals

---

## Phase 2: Data Structures & Algorithms (DSA)

**Rule**: Always select the algorithmically optimal solution. Never accept O(n²) when O(n log n) exists. Never use a HashMap when an array suffices.

### 2.1 Complexity Analysis — Always Perform This
For every algorithm you write or choose:
- Time complexity: Best / Average / Worst case (Big-O, Big-Θ, Big-Ω)
- Space complexity: In-place vs auxiliary
- Amortized complexity for data structures with dynamic operations
- Cache complexity: How does this behave with CPU cache lines?

### 2.2 Data Structure Selection Checklist
Ask these questions for every data structure choice:

| Need | Consider |
|------|---------|
| Fast lookup by key | HashMap O(1) avg, TreeMap O(log n) ordered |
| Ordered traversal | BST, Skip List, B-Tree |
| Range queries | Segment Tree, Fenwick Tree, Interval Tree |
| Fast min/max | Heap (binary, Fibonacci, pairing) |
| Sequence with fast insert/delete | Doubly Linked List, Rope, Gap Buffer |
| Graph traversal | Adjacency List vs Matrix (density matters) |
| Streaming/sliding window | Monotonic Deque, Circular Buffer |
| Union-Find operations | Disjoint Set Union with path compression + union by rank |
| String matching | KMP, Rabin-Karp, Aho-Corasick, Suffix Array |
| Approximate membership | Bloom Filter, Cuckoo Filter |
| Spatial queries | K-D Tree, R-Tree, Quadtree |

### 2.3 Algorithm Patterns — Know and Apply
- **Divide and Conquer**: Merge sort, quicksort, binary search, FFT
- **Dynamic Programming**: Identify overlapping subproblems + optimal substructure. Always verify with recurrence relation before coding
- **Greedy**: Prove exchange argument or matroid structure before trusting greedy
- **Graph algorithms**: BFS/DFS, Dijkstra, Bellman-Ford, Floyd-Warshall, A*, Prim, Kruskal, Tarjan SCC, Topological sort
- **Two pointers / Sliding window**: For array/string problems with contiguous constraints
- **Binary search on answer**: Whenever you see monotonic feasibility check
- **Backtracking with pruning**: Never naive backtracking; always prune aggressively
- **Randomized algorithms**: When deterministic is too slow (QuickSelect, reservoir sampling, randomized primality)

### 2.4 Sorting & Searching Deep Cuts
- Never use a general sort when counting sort / radix sort applies (integer keys in bounded range)
- Use external sort for data exceeding memory
- For parallel systems: parallel merge sort, parallel prefix sum (scan)
- For approximate nearest neighbor: HNSW, LSH, FAISS

---

## Phase 3: Object-Oriented Design

### 3.1 SOLID Principles — Non-Negotiable
Apply and verify each:

**S — Single Responsibility Principle**
- Each class/module has one reason to change
- If you can describe what a class does using "and", split it
- Verify: Can I unit test this class in complete isolation?

**O — Open/Closed Principle**
- Open for extension, closed for modification
- Use abstract base classes, interfaces, and composition over inheritance
- Adding new behavior should NOT require modifying existing code

**I — Interface Segregation Principle**
- No client should be forced to depend on methods it does not use
- Many small, specific interfaces > one fat general interface
- Verify: Does every implementor of this interface actually use every method?

**L — Liskov Substitution Principle**
- Subtypes must be substitutable for their base types
- No strengthening preconditions or weakening postconditions in subclasses
- Verify: Can I replace every instance of the parent with the child without breaking behavior?

**D — Dependency Inversion Principle**
- Depend on abstractions, not concretions
- High-level modules must not depend on low-level modules
- Inject dependencies; never instantiate dependencies inside a class

### 3.2 Design Patterns — When to Apply
**Creational** (object construction complexity):
- Factory Method: when creation logic should be deferred to subclasses
- Abstract Factory: families of related objects
- Builder: when constructing complex objects step-by-step
- Singleton: use sparingly; prefer dependency injection instead
- Prototype: when cloning is cheaper than constructing

**Structural** (assembling objects):
- Adapter: interface translation between incompatible interfaces
- Bridge: decouple abstraction from implementation (vary independently)
- Composite: tree structures (treat individual and groups uniformly)
- Decorator: add behavior without modifying (prefer over inheritance)
- Facade: simplified interface to a complex subsystem
- Flyweight: share fine-grained objects (e.g., character glyphs)
- Proxy: access control, lazy initialization, logging, caching

**Behavioral** (communication patterns):
- Observer: event-driven, pub/sub
- Strategy: interchangeable algorithms at runtime
- Command: encapsulate requests as objects (undo/redo, queuing)
- Iterator: uniform traversal across different collections
- State: behavior changes based on internal state (prefer over switch-case state machines)
- Template Method: define algorithm skeleton, defer steps to subclasses
- Chain of Responsibility: pass requests along a handler chain
- Mediator: reduce coupling by centralizing communication

### 3.3 GRASP Principles
- **Information Expert**: assign responsibility to the class with the most information
- **Creator**: assign object creation to the class that aggregates or closely uses the created object
- **Controller**: system/session controller for use case handling
- **Low Coupling**: minimize dependencies between classes
- **High Cohesion**: related operations stay together
- **Polymorphism**: use polymorphism over type-checking conditionals
- **Pure Fabrication**: create service classes when domain objects don't fit responsibility
- **Indirection**: introduce intermediary to reduce coupling

---

## Phase 4: Code Quality Principles

### 4.1 Clean Code Rules (Mandatory)
- **Names**: Variables, functions, and classes must be pronounceable, searchable, and intention-revealing. Never single letters except loop indices.
- **Functions**: Do ONE thing. Maximum 20 lines. No side effects unless named for them. Command-Query Separation.
- **Arguments**: Prefer 0-2 args. 3 is borderline. 4+ requires a parameter object. No boolean flag arguments (split into two functions).
- **Comments**: Code should be self-documenting. Comments explain WHY, not WHAT. Delete dead/commented-out code.
- **Error handling**: Never swallow exceptions. Return Result types or throw typed exceptions. Log context, not just messages.
- **Boundaries**: Wrap third-party code in adapter layers. Never let external APIs bleed into domain logic.
- **Tests**: Test code is first-class code. Same quality standards apply.

### 4.2 DRY, YAGNI, KISS
- **DRY**: Every piece of knowledge must have a single, unambiguous, authoritative representation. Don't DRY prematurely — wait for the third repetition.
- **YAGNI**: Never write code for requirements that don't exist yet. Speculative generality is a code smell.
- **KISS**: The simplest solution that fully satisfies requirements is the best solution.

### 4.3 Defensive Programming
- Validate all inputs at system boundaries (not in every internal function)
- Use assertions to document and verify invariants during development
- Design for failure: what happens when a dependency is down?
- Circuit breakers, retries with exponential backoff, bulkheads
- Assume all external data is malicious until proven otherwise

### 4.4 Concurrency Discipline
- Identify all shared mutable state. Default to immutability.
- Prefer message passing over shared memory (Actor model, channels)
- When using locks: always acquire in consistent order to prevent deadlock
- Use atomic primitives over coarse-grained locks when possible
- Test concurrent code with race detector tools (`go race`, ThreadSanitizer, Helgrind)
- Document thread-safety guarantees in every class header

---

## Phase 5: Testing Discipline

**Rule**: No code is done until it has tests. No PR is done until tests pass AND coverage is adequate.

### 5.1 Testing Pyramid
- **Unit Tests** (70%): Test every function/method in isolation. Mock all dependencies. Fast (<1ms each).
- **Integration Tests** (20%): Test component interactions. Use real dependencies where practical.
- **E2E Tests** (10%): Test full user flows. Treat as acceptance criteria.

### 5.2 Test Quality Standards
- Tests must be: **F**ast, **I**solated, **R**epeatable, **S**elf-validating, **T**imely (FIRST)
- Each test: one assertion concept per test
- Test names: `<when>_<condition>_<expected_result>` format
- Cover: happy path, boundary conditions, error paths, null/empty inputs, large inputs
- Mutation testing: verify tests actually catch bugs (use PIT, Stryker, mutmut)

### 5.3 TDD When Appropriate
For complex business logic: Red → Green → Refactor cycle
- Write the failing test first
- Write minimal code to pass
- Refactor to best design
- Never skip the refactor step

---

## Phase 6: Self-Review Loop (Never Skip)

After writing any code, perform this loop **every time**:

### Round 1 — Correctness
- [ ] Does it solve the stated problem completely?
- [ ] Have I traced through every code path manually?
- [ ] Have I covered every edge case listed in Phase 1?
- [ ] Does it handle null, empty, zero, negative, max values?
- [ ] Is the algorithm provably correct? (informal proof or test coverage)

### Round 2 — Quality
- [ ] Does every name communicate intent clearly?
- [ ] Is every function doing exactly one thing?
- [ ] Are there any magic numbers or strings? (extract to named constants)
- [ ] Is there any duplicated logic? (DRY it)
- [ ] Is there any dead code? (delete it)
- [ ] Is error handling complete and consistent?

### Round 3 — Performance
- [ ] What is the time complexity? Could it be better?
- [ ] What is the space complexity? Is there unnecessary allocation?
- [ ] Are there any N+1 query patterns or chatty I/O?
- [ ] Is there any blocking I/O on critical paths?
- [ ] Have I profiled the hot path? (don't optimize the cold path)

### Round 4 — Security
- [ ] Is all user input validated and sanitized?
- [ ] Are secrets never hardcoded or logged?
- [ ] Are there SQL injection / XSS / SSRF / path traversal risks?
- [ ] Is authentication checked at every privileged entry point?
- [ ] Are dependencies free of known CVEs? (run `npm audit`, `pip-audit`, `trivy`, etc.)

### Round 5 — Maintainability
- [ ] Can a new engineer understand this without asking me?
- [ ] Is the public API documented?
- [ ] Are complex algorithms explained with comments linking to references?
- [ ] Is the code independently deployable and testable?
- [ ] Are there any circular dependencies?

**If any item fails: fix before proceeding. No exceptions.**

---

## Phase 7: Continuous Improvement Protocol

After completing any task:
1. What did I get wrong on the first attempt? Why?
2. What would I do differently if starting fresh?
3. What did I learn about this domain that I didn't know before?
4. Are there better algorithms, patterns, or libraries I should know?
5. Update your mental model. Search for the "state of the art" in this area.

**Search cadence during development**:
- Before starting: Search for prior art (GitHub, arXiv, blogs)
- When stuck: Search for solutions, but understand them before using
- After finishing: Search for critique of your approach ("problems with X pattern", "X considered harmful")
- Always: Cross-reference multiple sources; never trust a single source

---

## Quick Reference: Code Smell Checklist

**Bloaters**: Long method, large class, primitive obsession, long parameter list, data clumps
**OO Abusers**: Switch statements, temporary field, refused bequest, alternative classes with different interfaces
**Change Preventers**: Divergent change, shotgun surgery, parallel inheritance hierarchies
**Dispensables**: Comments explaining bad code, duplicate code, lazy class, data class, dead code, speculative generality
**Couplers**: Feature envy, inappropriate intimacy, message chains, middle man, incomplete library class