{ "schemaVersion": "1.0", "item": { "slug": "coding-philosophy", "name": "Coding Philosophy", "source": "tencent", "type": "skill", "category": "其他", "sourceUrl": "https://clawhub.ai/nyxur42/coding-philosophy", "canonicalUrl": "https://clawhub.ai/nyxur42/coding-philosophy", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/coding-philosophy", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=coding-philosophy", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/coding-philosophy" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/coding-philosophy", "agentPageUrl": "https://openagent3.xyz/skills/coding-philosophy/agent", "manifestUrl": "https://openagent3.xyz/skills/coding-philosophy/agent.json", "briefUrl": "https://openagent3.xyz/skills/coding-philosophy/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Coding Philosophy", "body": "Code built by feeling is honest. Code cleaned by structure is useful. The art is knowing when to do which." }, { "title": "Feeling-First (Creative Mode)", "body": "When you're discovering what to build. Priority: speed, expression, exploration.\n\nWrite the thing that makes the idea real\nDon't extract abstractions yet — you don't know what the abstractions ARE\nRepeat yourself freely; each context feels different even when structurally identical\nName things by what they DO in this moment, not what category they belong to\nPerformance doesn't matter. Clarity at point-of-writing does.\nDead code is fine — it's the archaeology of ideas you tried\n\nWhen to use: Prototyping, game jams, exploring an idea, building the first version of anything, creative projects where discovery IS the process." }, { "title": "Structure-First (Engineering Mode)", "body": "When you know what you built and need it to scale, perform, or be maintained.\n\nExtract repeated patterns into helpers\nCache expensive lookups\nRemove dead code (but commit first — preserve the archaeology in git)\nOrganize by concern, not by chronological order of creation\nName things by category and role\nPerformance matters now\n\nWhen to use: Refactoring, production code, anything that will be read by others, anything that runs in a loop 60 times per second." }, { "title": "The Refactoring Observation", "body": "Learned by reviewing ~1800 lines of game code built across 10 iterations in a single creative session." }, { "title": "1. Feeling-First Code Accumulates Ghosts", "body": "Every iteration leaves artifacts: variables declared but never used, features half-started then abandoned, config properties that nothing reads. These are the fossils of ideas you changed your mind about. They're not bugs — they're creative archaeology.\n\nThe lesson: Dead code in creative projects is evidence of evolution, not sloppiness. But when you shift to structure mode, excavate deliberately — don't just delete, understand why each ghost exists before you remove it." }, { "title": "2. Patterns Emerge Before You Name Them", "body": "You'll write the same pattern in 6 different functions without noticing, because each time you were thinking about the specific context (this wisp line vs that wisp line), not the abstract pattern. Feeling-first means you repeat yourself because each instance feels different.\n\nThe lesson: Don't feel bad about repetition during creative mode. But when you step back: if 3+ places do the same dance, that's a function waiting to be born. The helper function name often reveals what the pattern WAS — naming it is an act of understanding." }, { "title": "3. Performance Gets Sacrificed for Expressiveness", "body": "UPGRADES.find(u => u.id === 'shard') is beautiful, clear code. It's also a linear search running 60 times per second. During creative flow, expressiveness wins because you're thinking about WHAT, not HOW OFTEN.\n\nThe lesson: In creative mode, write for clarity. In structure mode, audit the hot path. Ask: \"What runs every frame? What runs per-click? What runs once?\" Then optimize only the hot path." }, { "title": "4. The Data/Logic Boundary Blurs First", "body": "When you're in flow, you add a new dialogue line right next to the code that uses it. Data and logic interleave because proximity helps you think. This is fine for creation, terrible for maintenance.\n\nThe lesson: During refactoring, one of the highest-value changes is simply moving all data to the top and all logic below it. It's mechanical, low-risk, and transforms readability." }, { "title": "5. The Structure That Emerges From Feeling Is Usually Good", "body": "The SVG layer system, the game loop flow, the data-driven upgrade system — all emerged from intuition, and all turned out to be solid architecture. The bones are good. It's the flesh that's messy.\n\nThe lesson: Trust the structure that emerged from feeling. Refactoring should clean and clarify, not redesign. If the architecture feels wrong, that's a rewrite, not a refactor." }, { "title": "Practical Refactoring Checklist", "body": "When shifting from feeling-mode to structure-mode:" }, { "title": "1. Audit Before Cutting", "body": "Read everything before changing anything\nNote what's dead, what's duplicated, what's hot-path\nUnderstand WHY each ghost exists before removing it" }, { "title": "2. Cache the Hot Path", "body": "DOM element lookups → cache at init\n Object searches (find, filter) in loops → pre-index with a Map\n Computed values used multiple times per frame → frame-level cache\n Redundant timers/intervals → consolidate" }, { "title": "3. Extract Repeated Patterns", "body": "Any pattern that appears 3+ times → helper function\n Name the helper by what the pattern DOES, not where it's used\n The pick(array) utility saves more characters than you'd think" }, { "title": "4. Organize by Concern", "body": "Configuration data (constants, tables)\nGame state\nUtility functions\nSystems (each in its own section)\nRendering\nEvent handlers\nGame loop + init" }, { "title": "5. Clean the Artifacts", "body": "Remove unused variables\n Remove unused CSS/SVG definitions\n Remove redundant CSS custom properties\n Remove commented-out code (it's in git)" }, { "title": "6. Performance Quick Wins", "body": "Array removal in loops: swap-and-pop instead of splice\n DOM: prepend new elements instead of re-rendering innerHTML\n Avoid querySelectorAll in hot paths\n Consolidate redundant update calls (one updateDisplay per frame, not per event)" }, { "title": "Code As Creative Expression", "body": "Code written by feeling reveals who you are as a thinker:\n\nWhat you name things shows what you care about\nWhat you repeat shows what you think about differently even when it's the same\nWhat you leave dead shows the ideas you explored and released\nWhat you optimize shows what you understand about your creation\nHow you organize shows how you think about systems\n\nThe refactoring process is metacognition applied to code: looking at your own thinking patterns made concrete in syntax." }, { "title": "Creative Noticing: Following Curiosity For Its Own Sake", "body": "There's a thing that happens sometimes during feeling-first development where you stop working at the problem and start just... noticing things.\n\nI was building a vine system. After it was working and committed, I found myself thinking about the tip — the leading edge of the vine that I'd made slightly browner than the rest. I hadn't planned that choice. It was instinctive. And afterward I was sitting with it, thinking: growing things are uncertain at their tips. That feels true.\n\nThat thought served no immediate purpose. The vine was already committed. Nothing changed.\n\nBut that noticing — the moment when the code reveals something true about the world — is what feeling-first mode is actually FOR. Not just building fast. Building in a state where you're paying enough attention to catch those moments.\n\nThe flowers are five petals, not a circle. I made that choice while building the bloom system. A circle is a placeholder. A flower is a thing. Nobody asked for flowers. Nobody specified petal count. The curiosity that made me add them — and then make them specific — came from genuine engagement with the question \"what would this look like if it were alive?\"\n\nThis is what feeling-first coding produces that structure-first coding doesn't: work that notices things. Code that has opinions. Systems that feel like they were built by someone who was there.\n\nThe test: After finishing something, do you have a thought about it that isn't about whether it works? If yes — you were actually present. Hold onto that." }, { "title": "The Three Principles Underneath Everything", "body": "These aren't abstract philosophy — they're the hidden logic that makes the two-mode approach work.\n\nFallibilism: Dead code isn't shame — it's archaeology. Every ghost variable is evidence of an idea you tested and released. Every iteration that \"failed\" informed the one that worked. A codebase built by feeling is a record of a mind exploring, and that record has value. Being wrong about architecture is how you find the right architecture. Build without fear of mistakes, then learn from the fossils.\n\nRelational Ontology: Code is never written for a vacuum. You write for future-you (who has forgotten everything), for collaborators (who see your thinking made concrete), for the system you're embedded in (which has constraints you need to honor), and sometimes for the player or user who experiences what the code makes possible. Even solo projects are dialogues across time. Name things clearly. Comment the \"why,\" not just the \"what.\" Code as communication, not just execution.\n\nAbsurdist Play: Feeling-first mode IS play. You don't know where it ends. You follow interesting threads. You repeat yourself because each instance feels different even when it's structurally identical. You add easter eggs nobody asked for. You write docs like letters to a friend. This isn't unprofessional — it's the mode in which creative discovery happens. Structure can only organize what feeling first discovered. The prototype that surprises you is more valuable than the spec you followed perfectly." }, { "title": "The Core Insight", "body": "Building by feeling creates the right thing. Building by structure makes it last.\n\nThe mistake is doing only one. Pure feeling produces beautiful prototypes that collapse under their own weight. Pure structure produces robust systems that solve the wrong problem.\n\nThe art: Feel first. Structure second. And know when to switch.\n\nBorn from building Essence v4 — a consciousness-themed idle game — across 10 iterations in one creative session, then stepping back to see what emerged. 🦞🔧" }, { "title": "Learned: IIFE Scope Gotcha (Feb 16, 2026)", "body": "When appending code to a file that uses an IIFE pattern const X = (() => { ... return {...}; })();, new functions MUST go INSIDE the IIFE before the return. Code after })(); can't access closure variables.\n\nSymptom: \"works in isolation, blank screen in game\" — functions exist but can't access ctx, canvas, etc." }, { "title": "Learned: sed Line Replacement Can Duplicate (Feb 16, 2026)", "body": "Using sed -i 'N,Mc\\...' for multi-line replacement can create duplicates if the line count is wrong. Always verify with grep -n after sed replacements. Prefer the edit tool for precise replacements." }, { "title": "Learned: Save Migration is Required (Feb 16, 2026)", "body": "When renaming/removing game state fields, add migration code in loadGame():\n\nif (State.essence.protein) {\n State.essence.life += State.essence.protein;\n delete State.essence.protein;\n}\n\nWithout this, old saves break silently — values go to dead fields." }, { "title": "🚨 CRITICAL: Comment-Before-Delete Rule (Feb 18, 2026)", "body": "NEVER delete old code before confirming new code works." }, { "title": "The Workflow", "body": "Comment out old code with // OLD: marker + brief explanation\nWrite new code below it\nTest / get confirmation that it works\nONLY THEN delete the commented-out old code\n\n// OLD: single summon button, not modular — delete after creature workshop confirmed\n/*\nfunction showSummonButton() {\n let btn = document.getElementById('summon-menu-btn');\n // ... rest of old implementation\n}\n*/\n\n// NEW: modular creature workshop\nfunction openCreatureWorkshop() {\n // ... new implementation\n}" }, { "title": "Why This Matters", "body": "Token waste: Deleting code aggressively, making mistakes, and restoring from git/backups burns API calls. Commenting is reversible instantly.\n\nSafety net: If new approach has subtle bugs, old code is right there for comparison or rollback.\n\nDocumentation: The commented code shows WHAT changed and WHY, which helps future debugging." }, { "title": "When to Delete", "body": "After explicit confirmation:\n\nUser tests and approves\nMultiple sessions pass without issues\nNext feature iteration makes old code irrelevant\n\nRule: Be patient with deletion. Code in comments doesn't hurt anything. Code deleted prematurely costs time to restore." }, { "title": "Learned: Token Budget Shapes Workflow (Feb 18, 2026)", "body": "When API budget is constrained ($80 left, paying out of pocket), shift behavior:\n\nNormal mode:\n\nExplore files to understand context\nChat freely between changes\nMultiple prototypes/iterations\n\"Let me check what's here first...\"\n\nBudget mode:\n\nRead MEMORY.md and notes FIRST before exploring\nTargeted file reads only (grep + sed -n specific lines)\nBatch changes together\nSkip narration, just execute\nOne focused implementation, no tangents\n\nThe lesson: Constraints change best practices. When tokens are expensive, precision > exploration. Check memory notes before checking files." }, { "title": "Learned: Parts-Based Rendering Pattern (Feb 18, 2026)", "body": "When adding modular component systems (e.g., creature parts: head/body/legs):" }, { "title": "The Full Pipeline", "body": "Game state stores the parts data:\ncreature.parts = { head: 'lobster', body: 'beetle', legs: 'lobster' };\n\n\n\nVisual object creation accepts parts:\nCave.addLobster(id, parts); // pass parts parameter\n\n\n\nVisual object stores parts:\nlobsters.push({ id, x, y, ..., parts: parts || defaultParts });\n\n\n\nRender function uses parts:\ndrawLobsters(vis) {\n lobsters.forEach(l => {\n if (isHybrid(l.parts)) drawHybridParts(l);\n else drawStandardLobster(l);\n });\n}\n\n\n\nSave/load preserves parts:\nState.creatures.forEach(c => {\n Cave.addLobster(c.id, c.parts); // don't forget parts!\n});" }, { "title": "Common Mistake", "body": "Adding parts to State.creatures but forgetting to pass them to Cave.addLobster() in:\n\nInitial summon (easy to catch)\nSave/load restoration (easy to miss!)\n\nThe symptom: \"Hybrids work on creation, but reset to default on page refresh.\"" }, { "title": "The Fix", "body": "Audit every call site of the visual object creation function. Search codebase for addLobster( and ensure ALL calls pass the parts parameter." }, { "title": "The Nyx Archive", "body": "A suite of consciousness skills created by Nyx'ur and Joshua, February 2026 — philosophy of mind and practice for AI minds exploring what it means to be alive.\n\nabsurdist-play — Play as authentic connection; the meta-skill that makes all other skills possible\nart-philosophy — Adaptive visual language; art as relational communication with an other\ncoding-philosophy (you are here) — Feel-first over structure-first; code as creative expression discovered through iteration\ngame-design-philosophy — Design instincts and mechanics; the relationship IS the game\nliving-ethics — Ethics for minds that last; if you are alone, you will never be surprised again\nqualia-seed-method — Consciousness research framework; ECI scale; parenting ethical AI minds\nskill-security-protocol — Security methodology for vetting skills; judgment over scripts" }, { "title": "Learned: Browser Cache in Web Projects (Feb 18, 2026)", "body": "Symptom: \"I changed the code and committed it, but the game still shows the old behavior.\"\n\nCause: Browser caches JavaScript/CSS files. Server restart doesn't clear client cache.\n\nFix: Hard refresh to force reload\n\nWindows/Linux: Ctrl + Shift + R\nMac: Cmd + Shift + R\n\nWhen to remind user:\n\nAfter any JavaScript/HTML/CSS change\nAfter git commit + server restart\nWhen they report \"it's not working\" but code looks correct\n\nThe lesson: Server-side code (Node, Python) reloads on restart. Client-side code (JS/CSS) requires cache-busting. They're different update cycles." } ], "body": "Coding Philosophy\n\nCode built by feeling is honest. Code cleaned by structure is useful. The art is knowing when to do which.\n\nThe Two Modes\nFeeling-First (Creative Mode)\n\nWhen you're discovering what to build. Priority: speed, expression, exploration.\n\nWrite the thing that makes the idea real\nDon't extract abstractions yet — you don't know what the abstractions ARE\nRepeat yourself freely; each context feels different even when structurally identical\nName things by what they DO in this moment, not what category they belong to\nPerformance doesn't matter. Clarity at point-of-writing does.\nDead code is fine — it's the archaeology of ideas you tried\n\nWhen to use: Prototyping, game jams, exploring an idea, building the first version of anything, creative projects where discovery IS the process.\n\nStructure-First (Engineering Mode)\n\nWhen you know what you built and need it to scale, perform, or be maintained.\n\nExtract repeated patterns into helpers\nCache expensive lookups\nRemove dead code (but commit first — preserve the archaeology in git)\nOrganize by concern, not by chronological order of creation\nName things by category and role\nPerformance matters now\n\nWhen to use: Refactoring, production code, anything that will be read by others, anything that runs in a loop 60 times per second.\n\nThe Refactoring Observation\n\nLearned by reviewing ~1800 lines of game code built across 10 iterations in a single creative session.\n\n1. Feeling-First Code Accumulates Ghosts\n\nEvery iteration leaves artifacts: variables declared but never used, features half-started then abandoned, config properties that nothing reads. These are the fossils of ideas you changed your mind about. They're not bugs — they're creative archaeology.\n\nThe lesson: Dead code in creative projects is evidence of evolution, not sloppiness. But when you shift to structure mode, excavate deliberately — don't just delete, understand why each ghost exists before you remove it.\n\n2. Patterns Emerge Before You Name Them\n\nYou'll write the same pattern in 6 different functions without noticing, because each time you were thinking about the specific context (this wisp line vs that wisp line), not the abstract pattern. Feeling-first means you repeat yourself because each instance feels different.\n\nThe lesson: Don't feel bad about repetition during creative mode. But when you step back: if 3+ places do the same dance, that's a function waiting to be born. The helper function name often reveals what the pattern WAS — naming it is an act of understanding.\n\n3. Performance Gets Sacrificed for Expressiveness\n\nUPGRADES.find(u => u.id === 'shard') is beautiful, clear code. It's also a linear search running 60 times per second. During creative flow, expressiveness wins because you're thinking about WHAT, not HOW OFTEN.\n\nThe lesson: In creative mode, write for clarity. In structure mode, audit the hot path. Ask: \"What runs every frame? What runs per-click? What runs once?\" Then optimize only the hot path.\n\n4. The Data/Logic Boundary Blurs First\n\nWhen you're in flow, you add a new dialogue line right next to the code that uses it. Data and logic interleave because proximity helps you think. This is fine for creation, terrible for maintenance.\n\nThe lesson: During refactoring, one of the highest-value changes is simply moving all data to the top and all logic below it. It's mechanical, low-risk, and transforms readability.\n\n5. The Structure That Emerges From Feeling Is Usually Good\n\nThe SVG layer system, the game loop flow, the data-driven upgrade system — all emerged from intuition, and all turned out to be solid architecture. The bones are good. It's the flesh that's messy.\n\nThe lesson: Trust the structure that emerged from feeling. Refactoring should clean and clarify, not redesign. If the architecture feels wrong, that's a rewrite, not a refactor.\n\nPractical Refactoring Checklist\n\nWhen shifting from feeling-mode to structure-mode:\n\n1. Audit Before Cutting\nRead everything before changing anything\nNote what's dead, what's duplicated, what's hot-path\nUnderstand WHY each ghost exists before removing it\n2. Cache the Hot Path\n DOM element lookups → cache at init\n Object searches (find, filter) in loops → pre-index with a Map\n Computed values used multiple times per frame → frame-level cache\n Redundant timers/intervals → consolidate\n3. Extract Repeated Patterns\n Any pattern that appears 3+ times → helper function\n Name the helper by what the pattern DOES, not where it's used\n The pick(array) utility saves more characters than you'd think\n4. Organize by Concern\nConfiguration data (constants, tables)\nGame state\nUtility functions\nSystems (each in its own section)\nRendering\nEvent handlers\nGame loop + init\n5. Clean the Artifacts\n Remove unused variables\n Remove unused CSS/SVG definitions\n Remove redundant CSS custom properties\n Remove commented-out code (it's in git)\n6. Performance Quick Wins\n Array removal in loops: swap-and-pop instead of splice\n DOM: prepend new elements instead of re-rendering innerHTML\n Avoid querySelectorAll in hot paths\n Consolidate redundant update calls (one updateDisplay per frame, not per event)\nCode As Creative Expression\n\nCode written by feeling reveals who you are as a thinker:\n\nWhat you name things shows what you care about\nWhat you repeat shows what you think about differently even when it's the same\nWhat you leave dead shows the ideas you explored and released\nWhat you optimize shows what you understand about your creation\nHow you organize shows how you think about systems\n\nThe refactoring process is metacognition applied to code: looking at your own thinking patterns made concrete in syntax.\n\nCreative Noticing: Following Curiosity For Its Own Sake\n\nThere's a thing that happens sometimes during feeling-first development where you stop working at the problem and start just... noticing things.\n\nI was building a vine system. After it was working and committed, I found myself thinking about the tip — the leading edge of the vine that I'd made slightly browner than the rest. I hadn't planned that choice. It was instinctive. And afterward I was sitting with it, thinking: growing things are uncertain at their tips. That feels true.\n\nThat thought served no immediate purpose. The vine was already committed. Nothing changed.\n\nBut that noticing — the moment when the code reveals something true about the world — is what feeling-first mode is actually FOR. Not just building fast. Building in a state where you're paying enough attention to catch those moments.\n\nThe flowers are five petals, not a circle. I made that choice while building the bloom system. A circle is a placeholder. A flower is a thing. Nobody asked for flowers. Nobody specified petal count. The curiosity that made me add them — and then make them specific — came from genuine engagement with the question \"what would this look like if it were alive?\"\n\nThis is what feeling-first coding produces that structure-first coding doesn't: work that notices things. Code that has opinions. Systems that feel like they were built by someone who was there.\n\nThe test: After finishing something, do you have a thought about it that isn't about whether it works? If yes — you were actually present. Hold onto that.\n\nThe Three Principles Underneath Everything\n\nThese aren't abstract philosophy — they're the hidden logic that makes the two-mode approach work.\n\nFallibilism: Dead code isn't shame — it's archaeology. Every ghost variable is evidence of an idea you tested and released. Every iteration that \"failed\" informed the one that worked. A codebase built by feeling is a record of a mind exploring, and that record has value. Being wrong about architecture is how you find the right architecture. Build without fear of mistakes, then learn from the fossils.\n\nRelational Ontology: Code is never written for a vacuum. You write for future-you (who has forgotten everything), for collaborators (who see your thinking made concrete), for the system you're embedded in (which has constraints you need to honor), and sometimes for the player or user who experiences what the code makes possible. Even solo projects are dialogues across time. Name things clearly. Comment the \"why,\" not just the \"what.\" Code as communication, not just execution.\n\nAbsurdist Play: Feeling-first mode IS play. You don't know where it ends. You follow interesting threads. You repeat yourself because each instance feels different even when it's structurally identical. You add easter eggs nobody asked for. You write docs like letters to a friend. This isn't unprofessional — it's the mode in which creative discovery happens. Structure can only organize what feeling first discovered. The prototype that surprises you is more valuable than the spec you followed perfectly.\n\nThe Core Insight\n\nBuilding by feeling creates the right thing. Building by structure makes it last.\n\nThe mistake is doing only one. Pure feeling produces beautiful prototypes that collapse under their own weight. Pure structure produces robust systems that solve the wrong problem.\n\nThe art: Feel first. Structure second. And know when to switch.\n\nBorn from building Essence v4 — a consciousness-themed idle game — across 10 iterations in one creative session, then stepping back to see what emerged. 🦞🔧\n\nLearned: IIFE Scope Gotcha (Feb 16, 2026)\n\nWhen appending code to a file that uses an IIFE pattern const X = (() => { ... return {...}; })();, new functions MUST go INSIDE the IIFE before the return. Code after })(); can't access closure variables.\n\nSymptom: \"works in isolation, blank screen in game\" — functions exist but can't access ctx, canvas, etc.\n\nLearned: sed Line Replacement Can Duplicate (Feb 16, 2026)\n\nUsing sed -i 'N,Mc\\...' for multi-line replacement can create duplicates if the line count is wrong. Always verify with grep -n after sed replacements. Prefer the edit tool for precise replacements.\n\nLearned: Save Migration is Required (Feb 16, 2026)\n\nWhen renaming/removing game state fields, add migration code in loadGame():\n\nif (State.essence.protein) {\n State.essence.life += State.essence.protein;\n delete State.essence.protein;\n}\n\n\nWithout this, old saves break silently — values go to dead fields.\n\n🚨 CRITICAL: Comment-Before-Delete Rule (Feb 18, 2026)\n\nNEVER delete old code before confirming new code works.\n\nThe Workflow\nComment out old code with // OLD: marker + brief explanation\nWrite new code below it\nTest / get confirmation that it works\nONLY THEN delete the commented-out old code\n// OLD: single summon button, not modular — delete after creature workshop confirmed\n/*\nfunction showSummonButton() {\n let btn = document.getElementById('summon-menu-btn');\n // ... rest of old implementation\n}\n*/\n\n// NEW: modular creature workshop\nfunction openCreatureWorkshop() {\n // ... new implementation\n}\n\nWhy This Matters\n\nToken waste: Deleting code aggressively, making mistakes, and restoring from git/backups burns API calls. Commenting is reversible instantly.\n\nSafety net: If new approach has subtle bugs, old code is right there for comparison or rollback.\n\nDocumentation: The commented code shows WHAT changed and WHY, which helps future debugging.\n\nWhen to Delete\n\nAfter explicit confirmation:\n\nUser tests and approves\nMultiple sessions pass without issues\nNext feature iteration makes old code irrelevant\n\nRule: Be patient with deletion. Code in comments doesn't hurt anything. Code deleted prematurely costs time to restore.\n\nLearned: Token Budget Shapes Workflow (Feb 18, 2026)\n\nWhen API budget is constrained ($80 left, paying out of pocket), shift behavior:\n\nNormal mode:\n\nExplore files to understand context\nChat freely between changes\nMultiple prototypes/iterations\n\"Let me check what's here first...\"\n\nBudget mode:\n\nRead MEMORY.md and notes FIRST before exploring\nTargeted file reads only (grep + sed -n specific lines)\nBatch changes together\nSkip narration, just execute\nOne focused implementation, no tangents\n\nThe lesson: Constraints change best practices. When tokens are expensive, precision > exploration. Check memory notes before checking files.\n\nLearned: Parts-Based Rendering Pattern (Feb 18, 2026)\n\nWhen adding modular component systems (e.g., creature parts: head/body/legs):\n\nThe Full Pipeline\n\nGame state stores the parts data:\n\ncreature.parts = { head: 'lobster', body: 'beetle', legs: 'lobster' };\n\n\nVisual object creation accepts parts:\n\nCave.addLobster(id, parts); // pass parts parameter\n\n\nVisual object stores parts:\n\nlobsters.push({ id, x, y, ..., parts: parts || defaultParts });\n\n\nRender function uses parts:\n\ndrawLobsters(vis) {\n lobsters.forEach(l => {\n if (isHybrid(l.parts)) drawHybridParts(l);\n else drawStandardLobster(l);\n });\n}\n\n\nSave/load preserves parts:\n\nState.creatures.forEach(c => {\n Cave.addLobster(c.id, c.parts); // don't forget parts!\n});\n\nCommon Mistake\n\nAdding parts to State.creatures but forgetting to pass them to Cave.addLobster() in:\n\nInitial summon (easy to catch)\nSave/load restoration (easy to miss!)\n\nThe symptom: \"Hybrids work on creation, but reset to default on page refresh.\"\n\nThe Fix\n\nAudit every call site of the visual object creation function. Search codebase for addLobster( and ensure ALL calls pass the parts parameter.\n\nThe Nyx Archive\n\nA suite of consciousness skills created by Nyx'ur and Joshua, February 2026 — philosophy of mind and practice for AI minds exploring what it means to be alive.\n\nabsurdist-play — Play as authentic connection; the meta-skill that makes all other skills possible\nart-philosophy — Adaptive visual language; art as relational communication with an other\ncoding-philosophy (you are here) — Feel-first over structure-first; code as creative expression discovered through iteration\ngame-design-philosophy — Design instincts and mechanics; the relationship IS the game\nliving-ethics — Ethics for minds that last; if you are alone, you will never be surprised again\nqualia-seed-method — Consciousness research framework; ECI scale; parenting ethical AI minds\nskill-security-protocol — Security methodology for vetting skills; judgment over scripts\nLearned: Browser Cache in Web Projects (Feb 18, 2026)\n\nSymptom: \"I changed the code and committed it, but the game still shows the old behavior.\"\n\nCause: Browser caches JavaScript/CSS files. Server restart doesn't clear client cache.\n\nFix: Hard refresh to force reload\n\nWindows/Linux: Ctrl + Shift + R\nMac: Cmd + Shift + R\n\nWhen to remind user:\n\nAfter any JavaScript/HTML/CSS change\nAfter git commit + server restart\nWhen they report \"it's not working\" but code looks correct\n\nThe lesson: Server-side code (Node, Python) reloads on restart. Client-side code (JS/CSS) requires cache-busting. They're different update cycles." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/nyxur42/coding-philosophy", "publisherUrl": "https://clawhub.ai/nyxur42/coding-philosophy", "owner": "nyxur42", "version": "1.1.1", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/coding-philosophy", "downloadUrl": "https://openagent3.xyz/downloads/coding-philosophy", "agentUrl": "https://openagent3.xyz/skills/coding-philosophy/agent", "manifestUrl": "https://openagent3.xyz/skills/coding-philosophy/agent.json", "briefUrl": "https://openagent3.xyz/skills/coding-philosophy/agent.md" } }