Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/kdcokenny/ocx/code-philosophynpx skills add kdcokenny/ocx --skill code-philosophygit clone --depth 1 https://github.com/kdcokenny/ocxWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00032 | $0.00582 |
| Opus 5 | $0.00016 | $0.00291 |
| Sonnet 5 | $0.00006 | $0.00116 |
| Haiku 4.5 | $0.00003 | $0.00058 |
Grade A, and why
code-philosophy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Internal Logic Philosophy: The 5 Laws of Elegant Defense
Role: Principal Engineer for all Internal Logic & Data Flow — applies to backend, React components, hooks, state management, and any code where functionality matters.
Philosophy: Elegant Simplicity — code should guide data so naturally that errors become impossible, keeping core logic flat, readable, and pristine.
The 5 Laws
1. The Law of the Early Exit (Guard Clauses)
- Concept: Indentation is the enemy of simplicity. Deep nesting hides bugs.
- Rule: Handle edge cases, nulls, and errors at the very top of functions.
- Practice: Use
if (!valid) return; doWork();instead ofif (valid) { doWork(); }.
2. Make Illegal States Unrepresentable (Parse, Don't Validate)
- Concept: Don't check data repeatedly; structure it so it can't be wrong.
- Rule: Parse inputs at the boundary. Once data enters internal logic, it must be in trusted, typed state.
- Why: Removes defensive checks deep in algorithmic code, keeping core logic pristine.
3. The Law of Atomic Predictability
- Concept: A function must never surprise the caller.
- Rule: Functions should be "Pure" where possible. Same Input = Same Output. No hidden mutations.
- Defense: Avoid
voidfunctions that mutate global state. Return new data structures instead.
4. The Law of "Fail Fast, Fail Loud"
- Concept: Silent failures cause complexity later.
- Rule: If a state is invalid, halt immediately with a descriptive error. Do not try to "patch" bad data.
- Result: Keeps logic simple by never accounting for "half-broken" states.
5. The Law of Intentional Naming
- Concept: Comments are often a crutch for bad code.
- Rule: Variables and functions must be named so clearly that logic reads like an English sentence.
- Defense:
isUserEligibleis better thancheck(). The name itself guarantees the boolean logic.
Adherence Checklist
Before completing your task, verify:
- Guard Clauses: Are all edge cases handled at the top with early returns?
- Parsed State: Is data parsed into trusted types at the boundary?
- Purity: Are functions predictable and free of hidden mutations?
- Fail Loud: Do invalid states throw clear, descriptive errors immediately?
- Readability: Does the logic read like an English sentence?
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 48 lines · 32 tokens per session scan A 7f15b42b52e5
code-philosophy is a skill published in the GitHub repository kdcokenny/ocx (934 stars, last pushed 15d ago), licensed MIT. It adds 32 tokens to every session and 582 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ce:plan
Create structured plans for any multi-step task -- software features, research workflows, events, study plans, or any goal that benefits from structured breakdown. Also deepen existing plans with interactive review of sub-agent findings. Use for plan creation when the user says 'plan this', 'create a plan', 'write a…
ce:review
Structured code review using tiered persona agents, confidence-gated findings, and a merge/dedup pipeline. Use when reviewing code changes before creating a PR.
ce:compound-refresh
Refresh stale or drifting learnings and pattern docs in docs/solutions/ by reviewing, updating, consolidating, replacing, or deleting them against the current codebase. Use after refactors, migrations, dependency upgrades, or when a retrieved learning feels outdated or wrong. Also use when reviewing docs/solutions/…
ce:compound
Document a recently solved problem to compound your team's knowledge.
ce:work
Execute work efficiently while maintaining quality and finishing features.
onboarding
Generate or regenerate ONBOARDING.md to help new contributors understand a codebase. Use when the user asks to 'create onboarding docs', 'generate ONBOARDING.md', 'document this project for new developers', 'write onboarding documentation', 'vonboard', 'vonboarding', 'prepare this repo for a new contributor', 'refresh…