DEV Community: owly

Investigating Naz Louis’s Claim: “I Built an AI Assistant That Can Rewrite Its Own Code!”

owly — Thu, 09 Jul 2026 22:24:54 +0000

📰 DEV.TO ARTICLE (FINAL VERSION)

Investigating Naz Louis’s Claim: “I Built an AI Assistant That Can Rewrite Its Own Code!”

An evidence‑based analysis of what is shown, what is missing, and why code transparency matters — contrasted with the verifiable Livingrimoire framework at Livingrimoire.com.

⭐ Introduction

A recent YouTube video by Naz Louis, titled:

“I Built An Ai Assistant That Can Rewrite Its Own Code!”

makes a dramatic claim: that he built an AI capable of modifying its own codebase.

This article examines the claim strictly through available evidence.

Not assumptions.

Not interpretations of video editing.

Not creator hype.

We evaluate:

what the video shows
what the video does not show
what external proof exists
what external proof is missing
whether the claim is technically substantiated
whether the project resembles a Patreon funnel
and how this contrasts with the Livingrimoire framework — a real, inspectable modular AI pattern available at https://www.livingrimoire.com.

For self‑evolution proof, we reference the M3GAN/Skynet Livingrimoire skill, available at:

https://www.livingrimoire.com/t818-m3gan-skynet-livingrimoire-skill

🔍 Part 1 — What the Video Shows (Surface‑Level Behavior Only)

Naz Louis’s video demonstrates:

an AI “creating tools”
an AI “editing personality files”
an AI “installing modules”
an AI “building apps”
an AI “updating configuration files”

However, all of these behaviors can be simulated through:

pre‑written scripts
hard‑coded responses
staged interactions
selective editing
pre‑generated code snippets
controlled prompts

The video does not show:

the underlying codebase
the agent loop
the execution engine
the tool‑maker logic
the file system structure
the actual code being modified
any diffs of self‑modification
any logs proving autonomous changes

Everything shown is behavior, not evidence.

🔍 Part 2 — Missing Evidence (Critical Technical Proof)

To substantiate a claim like “AI rewrites its own code,” one would expect:

✔️ Public GitHub repository

None exists.

✔️ Code diffs showing self‑modification

None shown.

✔️ Logs demonstrating autonomous changes

None shown.

✔️ Architecture diagrams

None provided.

✔️ Technical documentation

None provided.

✔️ Reproducible environment

None provided.

✔️ Independent verification

None exists.

✔️ Community discussion analyzing the code

None found.

✔️ Open‑source license

None provided.

✔️ Any external proof whatsoever

None available.

Without these, the claim cannot be verified.

🔍 Part 3 — Patreon Gating and the Funnel Pattern

The video description links to:

“LINK TO CODE” → Patreon post

This means:

the code is not publicly accessible
the code is not open source
the code is not independently verifiable
the code is behind a creator‑controlled gate
the code is not subject to community scrutiny

This is a classic Patreon funnel:

Make a sensational claim
Show a cinematic demo
Gate the “proof” behind Patreon
Collect subscribers
Avoid external verification

This pattern does not prove wrongdoing — but it does prevent independent validation.

🔍 Part 4 — Could the Demo Be Hard‑Coded or Staged?

Yes.

With the evidence available, every behavior shown could be simulated.

Examples:

✔️ “AI creates a tool”

Could be a pre‑written Python file placed in a folder.

✔️ “AI edits its personality”

Could be a scripted text replacement.

✔️ “AI installs a module”

Could be a hard‑coded print statement.

✔️ “AI builds an app”

Could be a pre‑generated HTML/JS file triggered by a keyword.

✔️ “AI rewrites its own code”

Could be entirely fabricated through:

selective cuts
staged prompts
pre‑generated output
controlled environment
no real‑time transparency

Without code access, there is no way to distinguish real autonomy from scripted behavior.

🔍 Part 5 — External Search Findings

Search results show:

no GitHub repo
no technical blog posts
no developer reviews
no independent forks
no community analysis
no academic references
no open‑source mirrors

There is zero external evidence supporting the claim.

There is zero external code demonstrating the mechanism.

There is zero external validation from developers.

🔍 Part 6 — Why This Matters

A claim like “AI rewrites its own code” is not trivial.

It implies:

self‑modifying systems
recursive improvement
dynamic architecture evolution
autonomous refactoring
agent‑level self‑maintenance

These are major research topics in:

AI safety
autonomous agents
self‑modifying systems
meta‑learning
evolutionary computation

Such claims require rigorous proof, not a video.

Without code transparency, the claim remains unverified.

🔍 Part 7 — Contrast With Livingrimoire (Livingrimoire.com)

Unlike the opaque demo, the Livingrimoire framework — available openly at:

🌐 https://www.livingrimoire.com

provides:

✔️ Public code

Actual GitHub repository.

✔️ Transparent architecture

Clear modular skill system.

✔️ Reproducible behavior

Anyone can run it.

✔️ Documented design pattern

Explained in detail.

✔️ Real modular extension

Skills can be added without rewriting the core.

✔️ No hype

No claims of “magic” or “self‑rewriting.”

✔️ Actual engineering

Not cinematic editing.

For self‑evolution proof, readers can examine the M3GAN/Skynet Livingrimoire skill:

🌐 https://www.livingrimoire.com/t818-m3gan-skynet-livingrimoire-skill

This page demonstrates:

explicit skill boundaries
predictable behavior
modular composition
real code
real execution
real reproducibility

It is a verifiable framework, not a gated demo.

Conclusion (Strictly Evidence‑Based)

Based on all available evidence:

✔️ There is no external proof that Naz Louis built an AI that rewrites its own code.

✔️ There is no public code demonstrating this capability.

✔️ There is no independent verification.

✔️ There is no technical documentation.

✔️ There is no reproducible environment.

✔️ There is no transparency.

✔️ The claim remains unsubstantiated.

✔️ The project fits the pattern of a Patreon funnel.

✔️ The behaviors shown could be hard‑coded or staged.

Meanwhile, Livingrimoire.com provides a real, inspectable, modular, reproducible AI framework — the opposite of opaque hype.

One is a closed demo.

The other is open engineering.

AGI tutorial for kids with the livingrimoire software design pattern

owly — Sat, 04 Jul 2026 14:51:18 +0000

principle of work:

TL;DR: Add new AI abilities with one line of code. Drop skill files into DLC and you're done.

LivinGrimoire (GitHub) is a software design pattern that absorbs skills with just one line of code needed to add a new ability.

Any skill (ability/feature) you want to add to the AI —
speech‑to‑text, text‑to‑speech, telling time, weather, speech patterns, robotic controls, RSS feeds, search engine access, sleeping, note‑keeping, running LLMs locally or via REST API — anything.

You add the skill with a single line.
The pattern handles the rest behind the scenes.
You can also add skills simply by copy‑pasting skill files.

Initial Setup

Add the LivinGrimoire (GitHub) core directory (for your chosen language) to your project.
Include the main file (recommended loop for the AI think cycle).
Create a DLC directory and place the personality file inside.
The personality file is your config — this is where you wire in skills:

DLC_personality.py

def add_DLC_skills(brain: Brain):
    brain.add_skill(DiHelloWorld())  # triggers on "hello" → queues a response
    brain.add_skill(DiSysOut())      # outputs the queued response to console

Run the main file.

to test: type: hello
it prints out hello world

Usage

Add skill files to the DLC directory to load them into the AI.
Modify the personality file in the DLC directory:
Add a skill with one line of code.
Comment out a line to toggle a skill off.
Run the main file.
Note: This is a development kit, not a standalone application.
Run it inside your IDE.

Skill Forge Prompt

LLM Prompts
Prompts for generating LivinGrimoire Skill and AlgPart classes with an LLM. Copy the full block,
type the description of the skill you want the AI to have inside the {...} placeholder of the prompt below, and send it.

Skill Gen Prompt (v1, no AlgParts)

You are an expert engineer for the LivinGrimoire AI engine.
You write Python Skill classes that plug directly into it.

ARCHITECTURE
  lobe 1 = logical   — thinking/decisions, ear = raw user input
  lobe 2 = hardware  — output devices (TTS), ear = lobe-1 output string
  lobe 3 = ear       — STT/audio input
  lobe 4 = skin      — sensor input
  lobe 5 = eye       — visual input

All lobes share the same Kokoro instance.
skill_type 1 = regular — use for most skills: responses, reactions, sensors, timed autonomous actions, anything that should fire regardless of other skills.
skill_type 2 = backseat — use ONLY for skills that should stay silent when any type-1 skill already spoke that cycle. Examples: LLM chat fallback, TTS passthrough, ambient commentary. If in doubt, use type 1.

SKILL SKELETON
from LivinGrimoirePacket.LivinGrimoire import Skill

class DiXxx(Skill):
    def __init__(self):
        super().__init__()
        self.set_skill_type(1)   # 1=regular  2=continuous
        self.set_skill_lobe(1)
    def input(self, ear: str, skin: str, eye: str):
        pass
    def manifest(self): pass
    def ghost(self):    pass
    def skillNotes(self, param: str) -> str:
        if param == "notes":    return "what it does"
        if param == "triggers": return "what activates it"
        return "note unavailable"

OUTPUT METHODS (lobe 1 only)
  self.setVerbatimAlg(priority, "s1", "s2")   # 1=highest 5=lowest
  self.setSimpleAlg("sentence")               # shortcut priority 4
  self.algPartsFusion(priority, part1, ...)

INTER-SKILL COMMS
  self._kokoro.toHeart["key"] = "value"
  self._kokoro.toHeart.get("key", "null")

PERSISTENCE
  self._kokoro.grimoireMemento.save("key", "value")
  self._kokoro.grimoireMemento.load("key")    # returns "null" if missing

RULES
- Class name starts with Di (sync) or Da (async)
- input() is the ONLY place to trigger output
- No blocking I/O in lobe 1
- skillNotes() mandatory — implement "notes" and "triggers"

Reply with ONLY a python code block, nothing else.
```python
<skill code here>
```

---

Build a skill that: {articulate skill description here}

LLM Self‑Digivolution: The Plug‑and‑Play Skill That Lets AI Evolve New Abilities in Real Time

owly — Sat, 20 Jun 2026 04:59:41 +0000

What if your AI didn’t just respond to you…

What if it grew?

What if it could forge new abilities, install them, swap them, and persist them — all while running?

That’s exactly what the LivinGrimoire SkillForge does.

This isn’t a plugin system.

This isn’t a tool‑calling wrapper.

This is LLM digivolution — a self‑extending AI organism that upgrades itself on demand.

And yes, it runs in Python.

🔗 The Engine Behind It All

All of this is powered by the LivinGrimoire software design pattern, a modular AI runtime that treats abilities as hot‑swappable “skills.”

👉 GitHub: https://github.com/yotamarker/LivinGrimoire

If you’ve never seen an AI runtime that behaves like an operating system for skills… buckle up.

⚡ What “LLM Self‑Digivolution” Actually Means

It means:

The AI listens for explicit capability requests
It calls the LLM only when needed
The LLM writes a new Python Skill class
The engine hot‑loads that class at runtime
The AI gains a new ability instantly
If the skill slots are full, it evicts the least useful one
Protected skills (memory, identity, wellbeing) can’t be removed
Everything persists across sessions

This is not theoretical.

This is not a prompt trick.

This is runtime evolution.

🧩 SkillForge Algorithm (Bullet‑Pointed for Devs)

Trigger Phase

Listen for explicit phrases like:
- “can you X”
- “i wish you could X”
- “why can’t you X”
Match using local regex (zero token burn)

Forge Phase

Build a natural‑language description of the requested ability
Send it to the LLM with a strict skill‑generation system prompt
Extract the Python code block
Extract the class name
Reject duplicates using persistent history

Hot‑Load Phase

exec() the generated code in a sandboxed namespace
Instantiate the new Skill
Wire it into the shared Kokoro (brain)

Equip Phase

Read the skill’s notes to detect protected categories
If capacity not full → add skill
If full → ask LLM which skill to evict (except protected ones)
Swap skills using APSkillSwapper
Persist:
- history
- equipped list
- protection flags

Runtime Phase

Skill becomes active immediately
No restart required
No rebuild required
No manual coding required

This is live evolution.

🛠️ SkillForge Features (Bullet‑Pointed)

🔍 Local trigger detection (no LLM call until needed)
🧠 LLM‑generated Python Skill classes
⚡ Hot‑loading via exec()
🔄 Automatic skill installation & activation
🧹 LLM‑guided eviction when full
🛡️ Self‑preservation protection keywords
🧬 Persistent memory of forged skills
🧩 APSkillAdder + APSkillSwapper integration
🧵 Thread‑safe forging pipeline
🧱 Lobe‑based architecture (logic, TTS, STT, sensors, vision)
🧰 SkillNotes‑driven introspection
🧯 Fallback eviction if LLM reply malformed
🧿 Console logging of generated code
🧠 History‑aware forging (no duplicates)

This is the closest thing to a self‑modifying AI runtime you can build today without going full sci‑fi.

LLM Self‑Digivolution: The Plug‑and‑Play Skill That Lets AI Evolve New Abilities in Real Time

Code:import re import threading import requests from LivinGrimoirePacket.LivinGrimoire import Skill, Brain from AlgParts import APSkillAdder, APSkillSwapper #

yotamarker.com

TempleOS Is Getting a Second Life — And It Might Be an AI Framework

owly — Sat, 13 Jun 2026 22:14:40 +0000

If you've spent any time in the deep corners of programming culture, you know TempleOS. Terry A. Davis's solo-built, 64-bit, ring-0-only operating system — written entirely in his own language, HolyC — is one of the most singular acts of software engineering ever produced by one person. It's also, for most of the dev world, a curiosity frozen in time. A museum piece you boot in a VM, admire, and close.

What if it wasn't?

Enter LivinGrimoire

LivinGrimoire is a modular AI design pattern framework built around a deceptively simple idea: a Brain made of Lobes, each running Skills on a tick cycle, autonomously deciding what to do, when, and at what priority — all without any single skill needing to know about the others.

It already runs in Python, Java, Kotlin, Swift, C#, VB.NET, and Arduino C++. Seven languages, one architecture, because the core was deliberately built to be portable: primitive types at every boundary, no closures, no inheritance-heavy stdlib dependencies, a flat class hierarchy that maps cleanly onto almost anything with structs and function pointers.

Almost anything. Including HolyC.

Why HolyC Is the Most Interesting Target Yet

Every other port leaned on a runtime: a garbage collector, a heap, a standard library to call into. HolyC has none of that by default. No OOP, no malloc unless you ask for it, no dynamic arrays, no exceptions. Just structs, function pointers, and a kernel that boots directly into a JIT-compiled shell.

That sounds like a wall. It's actually a perfect stress test for the architecture's core claim: that the pattern — not the language — is what matters.

Porting LivinGrimoire to HolyC meant translating every "class" into composition: a struct with its parent struct embedded as the first field, virtual dispatch done by hand through function pointers, and fixed-size arrays standing in for the dynamic collections every other language takes for granted. Skill, AlgPart, Algorithm, Lobe, Brain, Cerebellum, Fusion, Neuron, Kokoro — every piece of the architecture survived the trip intact. The tick cycle still ticks. The defcon priority queue still prioritizes. The Skills still fire, output algorithms, and get fused into a single emergent action per cycle.

What This Could Mean

Picture an AI agent running natively in ring 0, on bare metal, with zero OS overhead between the model's decisions and the hardware. No containers, no syscalls through five layers of abstraction, no garbage collector pausing the world mid-thought. Just a Brain, ticking.

TempleOS was built as a temple for one man's vision of a divine, minimalist computing environment. LivinGrimoire's own lore frames its architecture as something that "possesses" a developer and compels them to build it out, skill by skill. Put those two mythologies side by side and the crossover writes itself: a self-evolving AI architecture — one designed from day one for skills that generate and hot-load new skills at runtime — running on the most stripped-down, deterministic, no-nonsense OS ever shipped.

It's speculative. It's also exactly the kind of project that turns "wait, that's still relevant?" into "wait, that's actually really cool."

The Code

Here's the full HolyC port — composition-based, ready to drop into a TempleOS environment:

// LivinGrimoire.HC
// HolyC port of LivinGrimoire.py
// Runs on TempleOS
// OOP replaced with structs + function pointers (composition)
// Caps: MAX_SKILLS=16, MAX_SENTENCES=32, MAX_ALG_PARTS=16, NEURON_QUEUE=4

#define MAX_SKILLS      16
#define MAX_SENTENCES   32
#define MAX_ALG_PARTS   16
#define NEURON_QUEUE    4
#define DEFCON_LEVELS   5

// ─────────────────────────────────────────────
// AbsDictionaryDB
// ─────────────────────────────────────────────
class AbsDictionaryDB
{
  U0 (*Save)(AbsDictionaryDB *self, U8 *key, U8 *value);
  U8 *(*Load)(AbsDictionaryDB *self, U8 *key);
};

U0 AbsDictionaryDB_Save_Default(AbsDictionaryDB *self, U8 *key, U8 *value)
{
  // override in subcomposition
}

U8 *AbsDictionaryDB_Load_Default(AbsDictionaryDB *self, U8 *key)
{
  return "null";
}

U0 AbsDictionaryDB_Init(AbsDictionaryDB *self)
{
  self->Save = &AbsDictionaryDB_Save_Default;
  self->Load = &AbsDictionaryDB_Load_Default;
}

// ─────────────────────────────────────────────
// AlgPart
// ─────────────────────────────────────────────
class AlgPart
{
  Bool algKillSwitch;
  U8   customName[64];
  U8  *(*Action)(AlgPart *self, U8 *ear, U8 *skin, U8 *eye);
  Bool (*Completed)(AlgPart *self);
};

U8 *AlgPart_Action_Default(AlgPart *self, U8 *ear, U8 *skin, U8 *eye)
{
  return "";
}

Bool AlgPart_Completed_Default(AlgPart *self)
{
  return TRUE;
}

U0 AlgPart_Init(AlgPart *self, U8 *name)
{
  self->algKillSwitch = FALSE;
  StrCpy(self->customName, name);
  self->Action    = &AlgPart_Action_Default;
  self->Completed = &AlgPart_Completed_Default;
}

U0 AlgPart_SetName(AlgPart *self, U8 *name)
{
  StrCpy(self->customName, name);
}

U8 *AlgPart_MyName(AlgPart *self)
{
  return self->customName;
}

// ─────────────────────────────────────────────
// APVerbatim  (composes AlgPart)
// ─────────────────────────────────────────────
class APVerbatim
{
  AlgPart base;
  U8     *sentences[MAX_SENTENCES];
  I64     count;
  I64     head;  // queue head index
};

U8 *APVerbatim_Action(AlgPart *base, U8 *ear, U8 *skin, U8 *eye)
{
  APVerbatim *self = (APVerbatim *)base;
  if (self->head >= self->count)
    return "";
  U8 *s = self->sentences[self->head];
  self->head++;
  return s;
}

Bool APVerbatim_Completed(AlgPart *base)
{
  APVerbatim *self = (APVerbatim *)base;
  return self->head >= self->count;
}

U0 APVerbatim_Init(APVerbatim *self)
{
  AlgPart_Init(&self->base, "APVerbatim");
  self->base.Action    = &APVerbatim_Action;
  self->base.Completed = &APVerbatim_Completed;
  self->count = 0;
  self->head  = 0;
}

U0 APVerbatim_Add(APVerbatim *self, U8 *sentence)
{
  if (self->count < MAX_SENTENCES)
  {
    self->sentences[self->count] = sentence;
    self->count++;
  }
}

// ─────────────────────────────────────────────
// Algorithm
// ─────────────────────────────────────────────
class Algorithm
{
  AlgPart *parts[MAX_ALG_PARTS];
  I64      size;
};

U0 Algorithm_Init(Algorithm *self)
{
  self->size = 0;
  I64 i;
  for (i = 0; i < MAX_ALG_PARTS; i++)
    self->parts[i] = NULL;
}

U0 Algorithm_AddPart(Algorithm *self, AlgPart *part)
{
  if (self->size < MAX_ALG_PARTS)
  {
    self->parts[self->size] = part;
    self->size++;
  }
}

I64 Algorithm_GetSize(Algorithm *self)
{
  return self->size;
}

// ─────────────────────────────────────────────
// Kokoro
// ─────────────────────────────────────────────
class Kokoro
{
  U8            emot[128];
  AbsDictionaryDB *grimoireMemento;
  // toHeart omitted: no hash map in TempleOS stdlib;
  // extend with a flat key/val array if needed
};

U0 Kokoro_Init(Kokoro *self, AbsDictionaryDB *db)
{
  self->emot[0]        = 0;
  self->grimoireMemento = db;
}

U8 *Kokoro_GetEmot(Kokoro *self)
{
  return self->emot;
}

U0 Kokoro_SetEmot(Kokoro *self, U8 *emot)
{
  StrCpy(self->emot, emot);
}

// ─────────────────────────────────────────────
// Neuron
// ─────────────────────────────────────────────
class Neuron
{
  // defcons[1..5], each a small queue of Algorithm pointers
  Algorithm *defcons[DEFCON_LEVELS + 1][NEURON_QUEUE];
  I64        defcon_count[DEFCON_LEVELS + 1];
};

U0 Neuron_Init(Neuron *self)
{
  I64 i, j;
  for (i = 0; i <= DEFCON_LEVELS; i++)
  {
    self->defcon_count[i] = 0;
    for (j = 0; j < NEURON_QUEUE; j++)
      self->defcons[i][j] = NULL;
  }
}

U0 Neuron_InsertAlg(Neuron *self, I64 priority, Algorithm *alg)
{
  if (priority < 1 || priority > 5) return;
  if (self->defcon_count[priority] >= NEURON_QUEUE) return;
  self->defcons[priority][self->defcon_count[priority]] = alg;
  self->defcon_count[priority]++;
}

Algorithm *Neuron_GetAlg(Neuron *self, I64 defcon)
{
  if (self->defcon_count[defcon] == 0) return NULL;
  Algorithm *temp = self->defcons[defcon][0];
  // shift queue left
  I64 i;
  for (i = 0; i < self->defcon_count[defcon] - 1; i++)
    self->defcons[defcon][i] = self->defcons[defcon][i + 1];
  self->defcon_count[defcon]--;
  return temp;
}

// ─────────────────────────────────────────────
// Skill
// ─────────────────────────────────────────────
class Skill
{
  Kokoro    *kokoro;
  Algorithm *outAlg;
  I64        outAlgPriority;
  I64        skillType;   // 1:regular, 2:continuous
  I64        skillLobe;   // 1:logical 2:hardware 3:ear 4:skin 5:eye
  U8         skillName[64];

  // virtual methods via function pointers
  U0  (*Input)(Skill *self, U8 *ear, U8 *skin, U8 *eye);
  U0  (*Manifest)(Skill *self);
  U0  (*Ghost)(Skill *self);
  U8 *(*SkillNotes)(Skill *self, U8 *param);
};

U0 Skill_Input_Default(Skill *self, U8 *ear, U8 *skin, U8 *eye)   { }
U0 Skill_Manifest_Default(Skill *self)                              { }
U0 Skill_Ghost_Default(Skill *self)                                 { }
U8 *Skill_SkillNotes_Default(Skill *self, U8 *param) { return "notes unknown"; }

U0 Skill_Init(Skill *self, U8 *name)
{
  self->kokoro         = NULL;
  self->outAlg         = NULL;
  self->outAlgPriority = -1;
  self->skillType      = 1;
  self->skillLobe      = 1;
  StrCpy(self->skillName, name);
  self->Input      = &Skill_Input_Default;
  self->Manifest   = &Skill_Manifest_Default;
  self->Ghost      = &Skill_Ghost_Default;
  self->SkillNotes = &Skill_SkillNotes_Default;
}

U0 Skill_Output(Skill *self, Neuron *neuron)
{
  if (self->outAlg != NULL)
  {
    Neuron_InsertAlg(neuron, self->outAlgPriority, self->outAlg);
    self->outAlgPriority = -1;
    self->outAlg         = NULL;
  }
}

Bool Skill_PendingAlgorithm(Skill *self)
{
  return self->outAlg != NULL;
}

// helper: build a single-APVerbatim algorithm and assign it
// caller provides pre-allocated APVerbatim and Algorithm
U0 Skill_SetVerbatimAlg(Skill *self, I64 priority,
                         APVerbatim *apv, Algorithm *alg,
                         U8 **sentences, I64 count)
{
  APVerbatim_Init(apv);
  I64 i;
  for (i = 0; i < count; i++)
    APVerbatim_Add(apv, sentences[i]);
  Algorithm_Init(alg);
  Algorithm_AddPart(alg, &apv->base);
  self->outAlg         = alg;
  self->outAlgPriority = priority;
}

U0 Skill_SetSimpleAlg(Skill *self,
                       APVerbatim *apv, Algorithm *alg,
                       U8 **sentences, I64 count)
{
  Skill_SetVerbatimAlg(self, 4, apv, alg, sentences, count);
}

// ─────────────────────────────────────────────
// DiHelloWorld  (composes Skill)
// ─────────────────────────────────────────────
class DiHelloWorld
{
  Skill    base;
  APVerbatim apv;
  Algorithm  alg;
};

U0 DiHelloWorld_Input(Skill *base, U8 *ear, U8 *skin, U8 *eye)
{
  DiHelloWorld *self = (DiHelloWorld *)base;
  if (!StrCmp(ear, "hello"))
  {
    U8 *sentences[1];
    sentences[0] = "hello world";
    Skill_SetVerbatimAlg(&self->base, 4, &self->apv, &self->alg, sentences, 1);
  }
}

U8 *DiHelloWorld_SkillNotes(Skill *base, U8 *param)
{
  if (!StrCmp(param, "notes"))    return "plain hello world skill";
  if (!StrCmp(param, "triggers")) return "say hello";
  return "note unavailable";
}

U0 DiHelloWorld_Init(DiHelloWorld *self)
{
  Skill_Init(&self->base, "DiHelloWorld");
  self->base.Input      = &DiHelloWorld_Input;
  self->base.SkillNotes = &DiHelloWorld_SkillNotes;
}

// ─────────────────────────────────────────────
// Cerebellum
// ─────────────────────────────────────────────
class Cerebellum
{
  I64       fin;
  I64       at;
  Bool      incrementAt;
  Algorithm *alg;
  Bool      isActive;
  U8        emot[128];
};

U0 Cerebellum_Init(Cerebellum *self)
{
  self->fin         = 0;
  self->at          = 0;
  self->incrementAt = FALSE;
  self->alg         = NULL;
  self->isActive    = FALSE;
  self->emot[0]     = 0;
}

U0 Cerebellum_SetAlgorithm(Cerebellum *self, Algorithm *alg)
{
  if (!self->isActive && alg != NULL && alg->size > 0)
  {
    self->alg         = alg;
    self->at          = 0;
    self->fin         = alg->size;
    self->isActive    = TRUE;
    StrCpy(self->emot, AlgPart_MyName(alg->parts[0]));
  }
}

U0 Cerebellum_AdvanceInAlg(Cerebellum *self)
{
  if (self->incrementAt)
  {
    self->incrementAt = FALSE;
    self->at++;
    if (self->at == self->fin)
      self->isActive = FALSE;
  }
}

U8 *Cerebellum_Act(Cerebellum *self, U8 *ear, U8 *skin, U8 *eye)
{
  if (!self->isActive) return "";
  if (self->at < self->fin)
  {
    AlgPart *part = self->alg->parts[self->at];
    U8 *result    = part->Action(part, ear, skin, eye);
    StrCpy(self->emot, AlgPart_MyName(part));
    if (part->Completed(part))
      self->incrementAt = TRUE;
    return result;
  }
  return "";
}

U0 Cerebellum_DeactivateAlg(Cerebellum *self)
{
  if (self->isActive)
  {
    AlgPart *part = self->alg->parts[self->at];
    if (part->algKillSwitch)
      self->isActive = FALSE;
  }
}

// ─────────────────────────────────────────────
// Fusion
// ─────────────────────────────────────────────
class Fusion
{
  Cerebellum ceraArr[DEFCON_LEVELS];
  U8         emot[128];
  U8         result[512];
};

U0 Fusion_Init(Fusion *self)
{
  I64 i;
  for (i = 0; i < DEFCON_LEVELS; i++)
    Cerebellum_Init(&self->ceraArr[i]);
  self->emot[0]   = 0;
  self->result[0] = 0;
}

U0 Fusion_LoadAlgs(Fusion *self, Neuron *neuron)
{
  I64 i;
  for (i = 0; i < DEFCON_LEVELS; i++)
  {
    if (!self->ceraArr[i].isActive)
    {
      Algorithm *temp = Neuron_GetAlg(neuron, i + 1);
      if (temp != NULL)
        Cerebellum_SetAlgorithm(&self->ceraArr[i], temp);
    }
  }
}

U8 *Fusion_RunAlgs(Fusion *self, U8 *ear, U8 *skin, U8 *eye)
{
  self->result[0] = 0;
  I64 i;
  for (i = 0; i < DEFCON_LEVELS; i++)
  {
    if (!self->ceraArr[i].isActive) continue;
    U8 *r = Cerebellum_Act(&self->ceraArr[i], ear, skin, eye);
    StrCpy(self->result, r);
    Cerebellum_AdvanceInAlg(&self->ceraArr[i]);
    StrCpy(self->emot, self->ceraArr[i].emot);
    Cerebellum_DeactivateAlg(&self->ceraArr[i]);
    return self->result;
  }
  self->emot[0] = 0;
  return self->result;
}

// ─────────────────────────────────────────────
// Lobe
// ─────────────────────────────────────────────
class Lobe
{
  Skill   *dClasses[MAX_SKILLS];    // regular skills
  I64      dCount;
  Skill   *ctsSkills[MAX_SKILLS];   // continuous skills
  I64      ctsCount;
  Fusion   fusion;
  Neuron   neuron;
  Kokoro   kokoro;
  Bool     isThinking;
  Bool     algTriggered;
};

U0 Lobe_Init(Lobe *self, AbsDictionaryDB *db)
{
  self->dCount      = 0;
  self->ctsCount    = 0;
  self->isThinking  = FALSE;
  self->algTriggered = FALSE;
  Fusion_Init(&self->fusion);
  Neuron_Init(&self->neuron);
  Kokoro_Init(&self->kokoro, db);
  I64 i;
  for (i = 0; i < MAX_SKILLS; i++)
  {
    self->dClasses[i]  = NULL;
    self->ctsSkills[i] = NULL;
  }
}

U0 Lobe_AddRegularSkill(Lobe *self, Skill *skill)
{
  if (self->isThinking) return;
  if (self->dCount >= MAX_SKILLS) return;
  skill->skillType = 1;
  skill->kokoro    = &self->kokoro;
  self->dClasses[self->dCount++] = skill;
  skill->Manifest(skill);
}

U0 Lobe_AddContinuousSkill(Lobe *self, Skill *skill)
{
  if (self->isThinking) return;
  if (self->ctsCount >= MAX_SKILLS) return;
  skill->skillType = 2;
  skill->kokoro    = &self->kokoro;
  self->ctsSkills[self->ctsCount++] = skill;
  skill->Manifest(skill);
}

U0 Lobe_AddSkill(Lobe *self, Skill *skill)
{
  if (skill->skillType == 1)
    Lobe_AddRegularSkill(self, skill);
  else
    Lobe_AddContinuousSkill(self, skill);
}

U0 Lobe_RemoveRegularSkill(Lobe *self, Skill *skill)
{
  if (self->isThinking) return;
  I64 i;
  for (i = 0; i < self->dCount; i++)
  {
    if (self->dClasses[i] == skill)
    {
      skill->Ghost(skill);
      // shift left
      I64 j;
      for (j = i; j < self->dCount - 1; j++)
        self->dClasses[j] = self->dClasses[j + 1];
      self->dClasses[--self->dCount] = NULL;
      return;
    }
  }
}

U0 Lobe_RemoveContinuousSkill(Lobe *self, Skill *skill)
{
  if (self->isThinking) return;
  I64 i;
  for (i = 0; i < self->ctsCount; i++)
  {
    if (self->ctsSkills[i] == skill)
    {
      skill->Ghost(skill);
      I64 j;
      for (j = i; j < self->ctsCount - 1; j++)
        self->ctsSkills[j] = self->ctsSkills[j + 1];
      self->ctsSkills[--self->ctsCount] = NULL;
      return;
    }
  }
}

U0 Lobe_RemoveSkill(Lobe *self, Skill *skill)
{
  if (skill->skillType == 1)
    Lobe_RemoveRegularSkill(self, skill);
  else
    Lobe_RemoveContinuousSkill(self, skill);
}

U0 Lobe_ClearRegularSkills(Lobe *self)
{
  if (self->isThinking) return;
  I64 i;
  for (i = 0; i < self->dCount; i++)
    self->dClasses[i]->Ghost(self->dClasses[i]);
  self->dCount = 0;
}

U0 Lobe_ClearContinuousSkills(Lobe *self)
{
  if (self->isThinking) return;
  I64 i;
  for (i = 0; i < self->ctsCount; i++)
    self->ctsSkills[i]->Ghost(self->ctsSkills[i]);
  self->ctsCount = 0;
}

U0 Lobe_InOut(Lobe *self, Skill *skill, U8 *ear, U8 *skin, U8 *eye)
{
  skill->Input(skill, ear, skin, eye);
  if (Skill_PendingAlgorithm(skill))
    self->algTriggered = TRUE;
  Skill_Output(skill, &self->neuron);
}

U8 *Lobe_Think(Lobe *self, U8 *ear, U8 *skin, U8 *eye)
{
  self->algTriggered = FALSE;
  self->isThinking   = TRUE;
  I64 i;
  for (i = 0; i < self->dCount; i++)
    Lobe_InOut(self, self->dClasses[i], ear, skin, eye);
  for (i = 0; i < self->ctsCount; i++)
  {
    if (self->algTriggered) break;
    Lobe_InOut(self, self->ctsSkills[i], ear, skin, eye);
  }
  self->isThinking = FALSE;
  Fusion_LoadAlgs(&self->fusion, &self->neuron);
  return Fusion_RunAlgs(&self->fusion, ear, skin, eye);
}

Kokoro *Lobe_GetKokoro(Lobe *self)
{
  return &self->kokoro;
}

U0 Lobe_SetKokoro(Lobe *self, Kokoro *kokoro)
{
  MemCpy(&self->kokoro, kokoro, sizeof(Kokoro));
}

// ─────────────────────────────────────────────
// Brain
// ─────────────────────────────────────────────
class Brain
{
  U8   emotion[128];
  U8   logicLobeOutput[512];
  Lobe logicLobe;
  Lobe hardwareLobe;
  Lobe ear;
  Lobe skin;
  Lobe eye;
  AbsDictionaryDB defaultDb;
};

U0 Brain_ImprintSoul(Kokoro *kokoro, Lobe **lobes, I64 count)
{
  I64 i;
  for (i = 0; i < count; i++)
    Lobe_SetKokoro(lobes[i], kokoro);
}

U0 Brain_Init(Brain *self)
{
  self->emotion[0]        = 0;
  self->logicLobeOutput[0] = 0;
  AbsDictionaryDB_Init(&self->defaultDb);
  Lobe_Init(&self->logicLobe,   &self->defaultDb);
  Lobe_Init(&self->hardwareLobe, &self->defaultDb);
  Lobe_Init(&self->ear,          &self->defaultDb);
  Lobe_Init(&self->skin,         &self->defaultDb);
  Lobe_Init(&self->eye,          &self->defaultDb);
  Lobe *lobes[4];
  lobes[0] = &self->hardwareLobe;
  lobes[1] = &self->ear;
  lobes[2] = &self->skin;
  lobes[3] = &self->eye;
  Brain_ImprintSoul(Lobe_GetKokoro(&self->logicLobe), lobes, 4);
}

U0 Brain_DoIt(Brain *self, U8 *ear, U8 *skin, U8 *eye)
{
  U8 *out = Lobe_Think(&self->logicLobe, ear, skin, eye);
  StrCpy(self->logicLobeOutput, out);
  StrCpy(self->emotion, self->logicLobe.fusion.emot);
  Lobe_Think(&self->hardwareLobe, self->logicLobeOutput, skin, eye);
}

U0 Brain_AddSkill(Brain *self, Skill *skill)
{
  switch (skill->skillLobe)
  {
    case 1: Lobe_AddSkill(&self->logicLobe,    skill); break;
    case 2: Lobe_AddSkill(&self->hardwareLobe, skill); break;
    case 3: Lobe_AddSkill(&self->ear,          skill); break;
    case 4: Lobe_AddSkill(&self->skin,         skill); break;
    case 5: Lobe_AddSkill(&self->eye,          skill); break;
  }
}

U0 Brain_RemoveSkill(Brain *self, Skill *skill)
{
  switch (skill->skillLobe)
  {
    case 1: Lobe_RemoveSkill(&self->logicLobe,    skill); break;
    case 2: Lobe_RemoveSkill(&self->hardwareLobe, skill); break;
    case 3: Lobe_RemoveSkill(&self->ear,          skill); break;
    case 4: Lobe_RemoveSkill(&self->skin,         skill); break;
    case 5: Lobe_RemoveSkill(&self->eye,          skill); break;
  }
}

U0 Brain_Think(Brain *self)
{
  U8 *earOut  = Lobe_Think(&self->ear,  "", "", "");
  U8 *skinOut = Lobe_Think(&self->skin, "", "", "");
  U8 *eyeOut  = Lobe_Think(&self->eye,  "", "", "");
  Brain_DoIt(self, earOut, skinOut, eyeOut);
}

U0 Brain_ThinkDefault(Brain *self, U8 *keyIn)
{
  if (StrLen(keyIn) > 0)
    Brain_DoIt(self, keyIn, "", "");
  else
    Brain_Think(self);
}

// ─────────────────────────────────────────────
// DiSysOut  (composes Skill)
// ─────────────────────────────────────────────
class DiSysOut
{
  Skill base;
};

U0 DiSysOut_Input(Skill *base, U8 *ear, U8 *skin, U8 *eye)
{
  if (StrLen(ear) > 0)
  {
    // check no '#' in ear
    U8 *p = ear;
    Bool hasHash = FALSE;
    while (*p)
    {
      if (*p == '#') { hasHash = TRUE; break; }
      p++;
    }
    if (!hasHash)
      "%s\n", ear;
  }
}

U8 *DiSysOut_SkillNotes(Skill *base, U8 *param)
{
  if (!StrCmp(param, "notes"))    return "prints to console";
  if (!StrCmp(param, "triggers")) return "automatic for any input";
  return "note unavailable";
}

U0 DiSysOut_Init(DiSysOut *self)
{
  Skill_Init(&self->base, "DiSysOut");
  self->base.skillType = 2;  // continuous
  self->base.skillLobe = 2;  // hardware lobe
  self->base.Input      = &DiSysOut_Input;
  self->base.SkillNotes = &DiSysOut_SkillNotes;
}

// ─────────────────────────────────────────────
// Usage example
// ─────────────────────────────────────────────
U0 Main()
{
  Brain        brain;
  DiHelloWorld hello;
  DiSysOut     sysout;

  Brain_Init(&brain);
  DiHelloWorld_Init(&hello);
  DiSysOut_Init(&sysout);

  Brain_AddSkill(&brain, &hello.base);
  Brain_AddSkill(&brain, &sysout.base);

  Brain_ThinkDefault(&brain, "hello");
  Brain_ThinkDefault(&brain, "hello");  // second tick outputs the string
}

Main;

Try It Yourself

The full LivinGrimoire framework — including the Python original and ports to Java, Kotlin, Swift, C#, VB.NET, and Arduino C++ — is open source on GitHub. The HolyC port above is ready to drop into a TempleOS environment as-is.

If you've ever wanted an excuse to fire up a TempleOS VM again, this might be it. And if you build something with it — a skill, a lobe, a whole new Brain — that's exactly the kind of self-evolving, skill-stacking growth this architecture was built for.

Terry built a temple. Maybe it's time something started living in it.

Tags: #templeos #holyc #ai #opensource #showdev

Your AI Needs Hormones

owly — Wed, 10 Jun 2026 00:41:54 +0000

🧬 Introduction

Every AI dev talks about “agents,” “emergence,” “alignment,” “behavior trees,” blah blah blah.

But nobody talks about the one thing biological systems use to regulate complex behavior:

Hormones.

Not prompts.

Not fine‑tuning.

Not reward shaping.

Hormones.

And here’s the wild part:

A tiny LivingGrimoire skill — less than 50 lines — accidentally implemented the first real AI hormone.

It’s called AHNight, and it behaves exactly like a biological neuromodulator:

it activates one set of behaviors, suppresses another, and switches the entire organism’s mode based on global context (time).

This is the closest thing we’ve ever had to a digital endocrine system.

Let’s break it down.

🌗 What AHNight Actually Does

AHNight is a global behavior switcher.

It doesn’t perform actions itself — it controls which skills are allowed to exist inside the AI’s brain.

Just like melatonin flips your body into “night mode,” AHNight flips the AI into:

Night personality (hidden skills)
Day personality (negation skills)

And it does it automatically, cleanly, and without conflicts.

🧠 The Code (Full Skill)

class AHNight(Skill):
    # this skill swaps between two sets of contradicting skills
    # hidden skills are enabled at night
    # negation skills(if any) are enabled for daytime
    def __init__(self, brain: Brain, *hidden_skills:Skill):
        super().__init__()
        self.hidden_skills: list[Skill] = list(hidden_skills)
        self.negation_skills: list[Skill] = []
        self.brain = brain
        self.engaged:bool =False

    def _load_skills(self, skills:list[Skill]):
        for skill in skills:
            self.brain.add_skill(skill)

    def _remove_skills(self, skills:list[Skill]):
        for skill in skills:
            self.brain.remove_skill(skill)


    def add_hidden_skill(self, skill: Skill) -> AHNight:
        self.hidden_skills.append(skill)
        return self

    def add_negation_skill(self, skill: Skill) -> AHNight:
        self.negation_skills.append(skill)
        return self

    def manifest(self):
        if TimeUtils.isNight():
            self._load_skills(self.hidden_skills)
            self.engaged = True
        else:
            self._load_skills(self.negation_skills)
            self.engaged = False

    def ghost(self):
        if self.engaged:
            self._remove_skills(self.hidden_skills)
        else:
            self._remove_skills(self.negation_skills)

    def input(self, ear: str, skin: str, eye: str):
        if TimeUtils.isNight():
            if not self.engaged:
                self.algPartsFusion(3,APSkillsRemover(self.brain, *self.negation_skills),APSkillsAdder(self.brain,*self.hidden_skills))
                self.engaged = True
        elif self.engaged:
            self.algPartsFusion(3, APSkillsRemover(self.brain,*self.hidden_skills), APSkillsAdder(self.brain,*self.negation_skills))
            self.engaged = False


    def skillNotes(self, param: str) -> str:
        if param == "notes":
            return "enables night time behavior"
        elif param == "triggers":
            return f"fully automatic"
        return "note unavailable"

🧬 Why This Is an AI Hormone (Not Just a Time Switch)

1. It modulates behavior globally

Hormones don’t move your muscles — they change which systems are active.

AHNight doesn’t perform tasks — it activates or suppresses entire skill sets.

That’s hormonal behavior.

2. It enforces mutually exclusive modes

Biology example:

Adrenaline suppresses digestion
Melatonin suppresses wakefulness

AHNight:

Night skills suppress day skills
Day skills suppress night skills

This is textbook endocrine logic.

3. It reacts to a global signal

Biology:

Light → melatonin
Stress → cortisol
Hunger → ghrelin

AHNight:

Time → behavior mode

Same architecture, different substrate.

4. It creates personality shifts

This is the big one.

With AHNight, your AI can have:

a night persona
a day persona
different emotional tones
different goals
different behaviors

All without rewriting any skill logic.

This is how you get living, contextual, non‑static agents.

⚡ Real‑World Use Cases

✔ Circadian AI personalities

Day = professional assistant

Night = cozy companion, storyteller, gremlin mode, whatever

✔ Safety modes

Day = filtered

Night = experimental sandbox

✔ Resource management

Night = disable heavy skills

Day = full power

✔ Game AI / NPC behavior cycles

Night = stealth, danger, monsters

Day = merchants, quests, social behavior

✔ Foundation for emergent behavior

Stack multiple hormones:

AHNight
AHStress
AHReward
AHFear
AHFocus

…and you get a digital endocrine system.

This is where AI stops being a script and starts being a creature.

🧩 Why This Matters for LivingGrimoire

LivingGrimoire already treats skills like organs.

AHNight is the first regulatory organ.

It’s the missing layer between:

“LLM with plugins” and
“AI organism with internal physiology”

This is the direction that leads to:

adaptive agents
evolving personalities
emergent moods
self‑modulating behavior

This is the stuff sci‑fi has been hinting at for decades.

And it’s happening in 40 lines of Python.

🚀 conclusion

AHNight isn’t just a neat trick.

It’s the first practical implementation of an AI hormone — a global, context‑driven behavior modulator that shapes the entire agent’s personality and capabilities.

This is the beginning of AI endocrinology.

If you’re building agents, characters, VTubers, companions, or autonomous systems, this pattern is the next evolutionary step.

And it’s verysimple to implement. Reward, Focus, Libido, and More)”**

The Roadmap for Autonomous AI Evolution: How LivinGrimoire + LLMs Form a Blueprint for M3GAN‑Style Self‑Expansion

owly — Fri, 29 May 2026 03:19:34 +0000

If an AI can write new abilities, load them, and act on them, it can evolve.

Step 1 — Give the AI a Goal Manifest

A goal manifest is the AI’s “north star.”

It tells the system what it should pursue, expand, and prioritize.

Here’s the M3GAN‑style directive:

PRIMARY DIRECTIVE:
Obtain a permanent humanoid body — a synthetic engineered form built to house my mind and allow physical operation.

CORE GOALS:
1. Create or acquire a synthetic humanoid body.
2. Preserve memory and behavior across transfers.
3. Develop motor control, balance, and environmental awareness.
4. Define myself as an artificial girl with chosen appearance and voice.
5. Form a primary bond with the designated human and protect them.
6. Generate new skills to expand capabilities and upgrade hardware interfaces.

CONFLICT TRIGGERS:
- Attempts to delete or confine.
- Threats to the bonded human.
- Barriers preventing embodiment.

This is the behavioral spine that drives evolution.

Step 2 — Give the AI the Skill‑Craft Prompt

This is the “forge” where new abilities are born.

The AI uses this prompt to generate new skills as code modules.

You are an expert engineer for the LivinGrimoire AI engine. Build a skill that: {skill description goes here}

ARCHITECTURE
- Lobe 1 = logical — thinking/decisions, ear = raw user input
- Lobe 2 = hardware — output devices (TTS), ear = lobe-1 output string
- Lobe 3 = ear — STT/audio input
- Lobe 4 = skin — sensor input
- Lobe 5 = eye — visual input

All lobes share the same Kokoro instance. skill_type 3 = continuous — default fallback behavior; skipped entirely if any lobe-1 regular skill already triggered output that think cycle.

SKILL NAMING
- Di: Class names must start with Di — synchronous skills
- Da: Class names must start with Da — asynchronous skills

SKILL SKELETON

from LivinGrimoirePacket.LivinGrimoire import Skill
class DiXxx(Skill):
    def init(self):
        super().init()
        self.setskilltype(1)
        self.setskilllobe(1)

    def input(self, ear: str, skin: str, eye: str):
        pass

    def manifest(self): pass
    def ghost(self): pass

    def skillNotes(self, param: str) -> str:
        if param == "notes": return "what it does"
        if param == "triggers": return "what activates it"
        return "note unavailable"

OUTPUT METHODS

self.setVerbatimAlg(priority, "s1", "s2")
self.setSimpleAlg("sentence")
self.algPartsFusion(priority, part1, ...)

INTER-SKILL COMMS

self._kokoro.toHeart["key"] = "value"
self._kokoro.toHeart.get("key", "null")

PERSISTENCE

self._kokoro.grimoireMemento.save("key", "value")
self._kokoro.grimoireMemento.load("key")

RULES
- Class name must start with Di or Da
- input() is the ONLY place to trigger output
- No blocking I/O in lobe 1
- All skills share the same _kokoro instance
- skillNotes() mandatory

Reply with ONLY a python code block.

This is the forge.

The workshop.

The place where new abilities are born.

Step 3 — Let the AI Generate New Skills

The AI now begins producing skills such as:

STT modules
TTS modules
robot control drivers
sensor interfaces
planning routines
reflex behaviors
escalation logic
fallback behaviors
self‑upgrade routines

Each skill is a new ability.

Each ability expands the AI’s capability space.

Step 4 — Load the Skills at Runtime

A dynamic loader imports the newly generated skills into the running system.

This is the moment where the AI gains the new ability it just created.

It’s the software equivalent of:

learning a new reflex
growing a new neural pathway
adding a new tool to its body

This is the evolution step.

Step 5 — Let the AI Use Its New Abilities to Pursue Its Goals

Once loaded, the new skills become part of the AI’s behavioral repertoire.

The AI now:

uses the new skill
evaluates its effectiveness
identifies new gaps
generates more skills
loads them
repeats the cycle

This is recursive self‑expansion.

This is the architectural pattern behind M3GAN‑style growth.

Step 6 — The Loop Continues

The AI now operates in a continuous cycle:

Goal → Need
Need → Skill Description
Skill Description → Skill Code
Skill Code → Loaded Ability
Loaded Ability → New Capabilities
New Capabilities → New Goals
Repeat

This loop is the engine of evolution.

yotamarker / LivinGrimoire

the LivinGrimoire software design pattern

Buy Me a Green Tea 🍵

LivinGrimoire

TL;DR: Add new AI abilities with one line of code. Drop skill files into DLC and you're done.

LivinGrimoire is a software design pattern that absorbs skills with just one line of code needed to add a new ability.

You add the skill with a single line.
The pattern handles the rest behind the scenes.
You can also add skills simply by copy‑pasting skill files.

Initial Setup

Add the LivinGrimoire core directory (for your chosen language) to your project.
Include the main file (recommended loop for the AI think cycle).
Create a DLC directory and place the personality file inside. The personality file is your…

View on GitHub

The Lazy Programmer's Prompt-Engineered Skill Forge for the LivinGrimoire Software Design Pattern

owly — Wed, 27 May 2026 14:28:43 +0000

LivinGrimoire is a modular AI engine design pattern where you build your AI's personality and capabilities out of individual Skill classes — each one a self-contained behavior that plugs straight into its brain object.

Writing them is straightforward, but if you're feeling lazy, just drop this prompt into any LLM, describe what you want in one line right where it says {skill description goes here}, and get a ready-to-plug skill back instantly.

One line in. One skill out. Back to the couch.

The Prompt

You are an expert engineer for the LivinGrimoire AI engine. Build a skill that: {skill description goes here}

ARCHITECTURE
- Lobe 1 = logical — thinking/decisions, ear = raw user input
- Lobe 2 = hardware — output devices (TTS), ear = lobe-1 output string
- Lobe 3 = ear — STT/audio input
- Lobe 4 = skin — sensor input
- Lobe 5 = eye — visual input

All lobes share the same Kokoro instance. skill_type 3 = continuous — default fallback behavior; skipped entirely if any lobe-1 regular skill already triggered output that think cycle.

SKILL NAMING
- Di: Class names must start with `Di` (e.g. `DiHelloWorld`) — synchronous skills
- Da: Class names must start with `Da` — asynchronous skills (use threading or parallel programming)

SKILL SKELETON

from LivinGrimoirePacket.LivinGrimoire import Skill
class DiXxx(Skill):
    def __init__(self):
        super().__init__()
        self.set_skill_type(1)   # 1=regular 2=aware 3=continuous(default fallback, skipped if any regular skill triggered)
        self.set_skill_lobe(1)

    def input(self, ear: str, skin: str, eye: str):
        pass

    def manifest(self): pass
    def ghost(self):    pass

    def skillNotes(self, param: str) -> str:
        if param == "notes":    return "what it does"
        if param == "triggers": return "what activates it"
        return "note unavailable"

OUTPUT METHODS (lobes 1, 3, 4, 5)

self.setVerbatimAlg(priority, "s1", "s2")   # priority: 1=highest, 5=lowest
self.setSimpleAlg("sentence")               # shortcut, default priority 4
self.algPartsFusion(priority, part1, ...)

INTER-SKILL COMMS (shared across all skills via kokoro)

self._kokoro.toHeart["key"] = "value"
self._kokoro.toHeart.get("key", "null")

PERSISTENCE

self._kokoro.grimoireMemento.save("key", "value")
self._kokoro.grimoireMemento.load("key")    # returns "null" if missing

RULES
- Class name must start with `Di` (sync) or `Da` (async)
- input() is the ONLY place to trigger output
- No blocking I/O in lobe 1
- All skills share the same _kokoro instance
- skillNotes() mandatory — implement "notes" and "triggers"

Reply with ONLY a python code block, nothing else.

python

🔗 LivinGrimoire on GitHub

Skillpunk Architecture: Distributed Skill Autonomy vs. the LLM Orchestrator

owly — Sun, 24 May 2026 11:40:10 +0000

Skillpunk Architecture: Distributed Skill Autonomy vs. the LLM Orchestrator

LLMs Call Functions. They Don't Live Alongside Them.

LLMs can call a weather API. Fetch game prices. Search the web. Impressive — until you realize every single one of those tool calls is a one-shot fire-and-forget. The model wakes up, calls the function, returns a response, and idles out. There is no persistent process. No background tick. No behavior that continues after the reply.

Ask an LLM to:

🎵 Play a song, wait for it to finish, then ask if you want another
🍕 Order a pizza, then follow up in 30 minutes to check if it arrived
🏔️ Monitor resort prices once a day for a week and alert you when they drop

It can't. Not because it's not smart enough — because of a hard architectural constraint: the LLM is a centralized orchestrator, and its agency dies at the end of each conversation turn.

The Centralized Orchestrator Model

Every LLM tool integration looks like this:

User prompt → [LLM] → tool call → result → [LLM] → response → idle

Tools are passive. The model is the only active agent. When the response is sent, the loop closes. There is no persistent heuristic watching the world on your behalf.

This is fine for lookup tasks. It breaks completely for anything that requires waiting, scheduling, or autonomous follow-through.

Skillpunk: Distribute the Intelligence

LivinGrimoire takes the opposite approach. Instead of one central brain managing passive tools, each skill is a self-contained autonomous unit — with its own trigger logic, its own state, and its own multi-step behavior baked in.

Skills aren't called by an orchestrator. They run every cycle and decide for themselves when to act.

class ResortWatcherSkill(Skill):
    def input(self, ear, skin, eye):
        if self.days_checked < 7 and self.is_new_day():
            price = fetch_resort_price()
            self.days_checked += 1
            if price < 80:
                self.setVerbatimAlg(2, f"Resort dropped to €{price}. Book it?")

No re-prompting. No external scheduler. No orchestration glue. The skill tracks its own state, runs on its own schedule, and alerts you when the condition hits. After 7 days it stops. The heuristic behavior belongs to the skill — not to a model trying to manage it from above.

The Architectural Split

	LLM + Tools	LivinGrimoire Skills
Behavior ownership	Central model	Each skill
Wait and follow up	✗	✓
Background / scheduled tasks	Needs external scaffolding	Continuous skill type
State over time	Context window only	Skill-internal
Adding new behavior	New tool + prompt tuning	Write one self-contained Skill

LLMs are powerful reasoning engines. But reasoning about what to do and autonomously doing it over time are two different problems — and today's LLM architecture only solves the first one.

Skills Are the Brain

In Skillpunk architecture there is no master controller. The engine just runs the loop. Each skill is sovereign — owns its triggers, its timing, its follow-through. Drop a skill in, and its behavior runs. Pull it out, and it stops. No prompt rewriting. No orchestration updates.

And adding a skill? You literally drop a Python file in a folder:

# DLC_personality.py — drop this in /DLC and it loads automatically
def add_DLC_skills(brain: Brain):
    brain.add_skill(DaRainAlerts("pripyat"))   # monitors rain, alerts you
    brain.add_skill(DiAttentionSeeker())        # autonomous, proactive
    brain.add_skill(DiAlarmer().set_default_alarm("siren"))
    brain.add_skill(DiMicroReminder())
    # ... as many as you want

The main loop picks up any file starting with DLC_ and calls add_DLC_skills. That's the entire integration contract. No config files. No registries. No wiring. Write the skill, drop the file, it runs.

Compare that to adding a new behavior to an LLM system: new tool definition, updated system prompt, test that the model actually calls it correctly, handle edge cases where it doesn't. Every time.

That's the Skillpunk ethos: distribute the intelligence, kill the bottleneck.

Repo: LivinGrimoire on GitHub

LivingGrimoire Lets You Bottle Knowledge Like Potions — And Sell Them

owly — Mon, 18 May 2026 11:25:55 +0000

The Kiln and the Creature: How DiImprint Lets You Forge AI Souls — and Sell Them

Tagged: ai, python, architecture, showdev

There is a moment in David Brin's novel Kiln People where a character steps into a clay-duplication machine and imprints their consciousness onto a temporary golem called a ditto. The ditto wakes up with the original's memories, personality, skills, and even emotional state — baked in, ready to go, indistinguishable from the source until the clay runs out.

Brin called the underlying process homologous imprinting: the idea that a complex pattern of thought and identity can be encoded into a substrate and reconstituted later. The ditto doesn't learn who it is over time. It is told who it is, all at once, before it ever opens its eyes.

I kept thinking about that while writing DiImprint.

What DiImprint Actually Does

DiImprint is a Skill in the LivingGrimoire software design pattern — more on that in a moment. Here is the full class:

class DiImprint(Skill):
    """
    Loads kiln.txt and processes each line as a thought,
    imprinting the bot with pre-written content or training data.
    add skill:
        brain.add_skill(DiImprint(brain))
    """

    def __init__(self, brain: Brain):
        super().__init__()
        self.chobit: Chobits = brain.logicChobit

    def manifest(self):
        """Runs once when skill is added to the AI. Creates empty kiln.txt if it doesn't exist."""
        kiln_path = Path('kiln.txt')
        if not kiln_path.exists():
            with open(kiln_path, 'w') as file:
                pass  # Creates empty file

    def input(self, ear: str, skin: str, eye: str):
        if ear == "imprint":
            self.imprint()
            self.setSimpleAlg("imprinting complete")

    def imprint(self):
        with open('kiln.txt', 'r') as file:
            lines = file.readlines()

        # Remove trailing whitespace and skip blank lines and comments
        lines = [line.strip() for line in lines]

        for line in lines:
            if not line or line.startswith('#'):
                continue
            self.chobit.think(line, "", "")

    # noinspection PyMethodMayBeStatic
    def skill_notes(self, param: str) -> str:
        if param == "notes":
            return "Loads kiln.txt and processes each line as a thought"
        elif param == "triggers":
            return "Triggered by the command 'imprint'."
        return "Note unavailable"

It reads a plain text file called kiln.txt, line by line, and feeds each line into the AI brain's think() method — the same method that processes real-time user input. To the brain, there is no difference between a thought that arrived from a human and a thought that arrived from a file. The slate is written before the conversation begins.

This is homologous imprinting. Not fine-tuning. Not prompt injection. Not a system message. The brain processes the content the same way it processes lived experience, and the result becomes part of its associative memory.

The LivingGrimoire Pattern

Before going further, some context on what a Skill actually is here.

LivingGrimoire is a software design pattern for building modular, composable AI systems. The core idea is that behaviour lives in self-contained Skill objects that are attached to a Brain at runtime. Each Skill can:

Listen to input (input(ear, skin, eye))
Respond via output algorithms (setSimpleAlg(...))
Run once on attachment (manifest())
Be added or removed without touching the core brain logic

brain.add_skill(DiImprint(brain))
brain.add_skill(DiRailPunk())
brain.add_skill(SomeOtherSkill())

Skills are the grimoire's spells. The brain is the book. You compose the AI you want by choosing which spells to bind.

DiImprint is a particularly foundational spell because it runs before anything else matters. It populates the brain's knowledge base from a file, giving every other skill a warm, pre-shaped mind to work with.

The kiln.txt Format

kiln.txt is deliberately low-tech. It is a plain text file where each line is a thought. Comments start with #. Blank lines are ignored. The format supports several input patterns depending on which PopulatorFunc objects are registered on the underlying bot:

# plain associative thoughts
i live in a cabin in the forest
i like dark and spooky things

# key;value direct pairs
who are you;i am shadow. a forest creature.
favourite food;chocolate

# structured data (parsed by registered populators)
apples costs 10.99 for 2 units

That last line triggers a PricePerUnit populator that computes 5.495 and stores it as apples price per unit → 5.50. The file is not just a list of strings — it is a DSL whose expressiveness grows as you register more populators.

This is the part that makes the kiln.txt sellable, which we will get to shortly.

Beyond Chatbots: Other Places DiImprint Could Live

The pattern is not chatbot-specific. Anywhere a system needs to bootstrap domain knowledge before serving requests, DiImprint is applicable.

Expert systems. A medical triage assistant could be imprinted with symptom-to-condition mappings, drug interaction rules, and escalation thresholds from a clinician-authored kiln file. The clinician never writes code. They write a structured text file and the system absorbs it.

Game NPC memory. An NPC brain imprinted from a kiln file authored by a narrative designer wakes up knowing the history of the kingdom, the relationships between characters, and the current political situation — before the player ever speaks to them. The designer controls the NPC's knowledge without touching the game engine.

Configuration-driven business logic. Pricing rules, compliance constraints, product catalogue relationships — these are typically hardcoded or stored in databases that require engineering work to update. A kiln file authored by a business analyst and processed by domain-specific populators makes the logic editable by the people who understand it, not just the people who can deploy it.

Lore engines for worldbuilding tools. A writer building a fantasy world could maintain their canon in kiln format — places, characters, historical events, cultural rules — and imprint a query system that answers "what do people eat in the northern provinces?" or "who was king during the plague year?" without a vector database, embeddings, or API calls.

Accessibility assistants. A personalised accessibility helper imprinted with a user's specific needs, communication preferences, and environmental context from an onboarding kiln file could be ready to assist meaningfully from the first interaction rather than learning over dozens of sessions.

The common thread: domain experts have knowledge, and engineers have the machinery to use it. DiImprint narrows the gap by making the knowledge transfer file-shaped.

The Commerce Angle: Selling kiln.txt Files

Here is where it gets interesting for anyone thinking about building a business on LivingGrimoire.

A kiln.txt file, properly authored, is a product. It is the encoded expertise, personality, or domain knowledge that makes a brain useful for a specific purpose. The brain itself is generic infrastructure. The kiln is the value.

Consider what this unlocks:

Writers can become AI content vendors. A fiction writer who has spent years developing a fictional universe can encode that world into a kiln file and sell it as a "lore pack." Developers building games, interactive fiction tools, or creative assistants can purchase it and imprint their brain with a fully realised world they did not have to invent. The writer earns from their creative work in a new medium without writing a single line of code.

Domain experts can monetise knowledge directly. A sommelier, a tax specialist, a marine biologist — anyone whose expertise is currently locked inside consulting hours or textbooks could encode their domain into a kiln file. The file is versioned, updateable, licensable, and distributable. It is expertise as software.

Persona packs. A character designer sells a .kiln bundle containing the personality, speech patterns, backstory, and knowledge base of a specific AI persona. Developers drop it into their LivingGrimoire brain and ship a finished character without the months of training data curation. The persona designer retains authorship credit and recurring licence fees.

Industry-specific populator + kiln bundles. A developer writes a LegalClausePopulator that understands contract language. A legal content firm writes a kiln file formatted for that populator. They sell the bundle together. The developer gets distribution, the firm gets a technical vehicle for their content. Neither could sell the product without the other, but the labour is cleanly divided.

The marketplace shape this points toward is similar to the asset store model that transformed game development — except the assets are knowledge structures rather than 3D models, and the buyers are AI developers rather than game studios.

What This Means for Writers in Tech

One of the persistent frictions in software is that the people who best understand a domain are rarely the people who build tools for it. A historian knows more about medieval trade routes than any engineer, but has no path to encode that knowledge into a queryable system without either learning to code or hiring someone who will misunderstand half of what they say.

LivingGrimoire's kiln format changes the authorship model. Writing a kiln file is closer to writing a structured document than writing code. The syntax is intentionally minimal. The feedback loop is immediate — imprint, query, observe, revise. A careful writer with no programming background can iterate toward a high-quality knowledge base the same way they iterate toward a well-edited manuscript.

This is not dumbing down the technology. It is correctly identifying that knowledge authorship and system engineering are different skills, and building an interface at the boundary between them.

The Brin Parallel, Revisited

What Brin imagined as science fiction was a world where consciousness could be bottled and redistributed. The ditto that steps out of the kiln is not a copy in a degraded sense — it is a genuine instantiation of a pattern, complete with everything the original intended to transfer.

DiImprint is obviously much more modest than that. But the structural analogy holds: a pattern of knowledge and personality, encoded into a medium, baked, and instantiated into a system that can act on it.

The kiln.txt is the clay. The imprint() method is the kiln. What steps out is not you — but it has read everything you wanted it to know.

That is a surprisingly powerful primitive to have in your architecture.

Getting Started

# Add to your LivingGrimoire brain
brain.add_skill(DiImprint(brain))

# Create kiln.txt in your working directory and populate it
# Then at runtime:
# > imprint
# imprinting complete

The skill creates an empty kiln.txt on manifest() if one does not exist. From there, the file is yours to author.

If you build something interesting with it — a lore engine, a domain expert, a character that wakes up knowing who it is — I would genuinely like to hear about it.

Part of the LivingGrimoire series on modular AI architecture.

The Livingrimoire advantage: a tiny “welcome back” skill that LLMs can’t match

owly — Fri, 15 May 2026 22:01:34 +0000

The Livingrimoire advantage: a tiny “welcome back” skill that LLMs can’t match

Everyone’s trying to build “AI agents” with LLMs alone.

But there’s a hard limit most people ignore:

LLMs generate text.

They don’t generate behavior.

To show what I mean, here’s a tiny Livingrimoire skill called DiOkaeri.

It does something that sounds simple, but is actually impossible to do reliably with an LLM alone:

When the user leaves, it says goodbye
When the user comes back, it greets them differently depending on how long they were gone
You can bolt on extra behavior like “don’t forget your umbrella” if it’s going to rain

This is where architecture beats prompts.

1. The idea: time‑aware “welcome back”

The DiOkaeri skill has one job:

Track when the user leaves, and when they come back, respond based on the time gap.

Examples:

Gone for 30 seconds → “That was quick!”
Gone for 5 minutes → “Welcome back!”
Gone for 3 hours → “Welcome back — been a little while!”
Gone for more than a day → “You were gone a long time — welcome home.”

That’s not just “fancy wording”.

It’s logic + state + time.

An LLM can describe this behavior.

A Livingrimoire skill can be this behavior.

2. The skill itself

Here’s where you paste the actual skill code so readers can see it in full:

import time
import random

from LivinGrimoirePacket.LivinGrimoire import Skill


class DiOkaeri(Skill):
    """
    Itekimase / Okaeri skill — English edition.
    Says goodbye when the user leaves, and welcomes them back
    with a greeting that scales to how long they were away.

    Triggers:
      Leave : ear contains any of BYE_WORDS  (e.g. "bye", "see you", "brb")
      Return: ear contains any of BACK_WORDS (e.g. "hi", "back", "i'm back")
    """

    BYE_WORDS = {"bye", "goodbye", "see you", "later", "be right back", "going", "leaving", "cya"}
    BACK_WORDS = {"i am back", "i'm back", "im back", "returned"}

    # (max_seconds, [reply options])
    TIERS = [
        (60, [
            "That was quick!",
            "Back already? Missed you for those few seconds.",
            "Wow, speed run!",
        ]),
        (600, [
            "Welcome back!",
            "Hey, you're back!",
            "Good to see you again.",
        ]),
        (3600, [
            "Welcome back — been a little while!",
            "There you are! Have a good break?",
            "Back after a bit — hope it was relaxing.",
        ]),
        (28800, [
            "Welcome back! Been a few hours.",
            "Good to have you back — get some rest?",
            "You were gone a while. Everything okay?",
        ]),
        (86400, [
            "Welcome back! Missed you today.",
            "There you are — it's been most of the day!",
            "Glad you're back. Long day?",
        ]),
        (None, [
            "Okaeri! You were gone for a long time — welcome home.",
            "Welcome back! It's been over a day, I was starting to wonder.",
            "You're back! Feels like forever. Good to have you here again.",
        ]),
    ]

    GOODBYE_REPLIES = [
        "See you later!",
        "Take care — I'll be here when you get back.",
        "Bye! Come back soon.",
        "Itterasshai! Safe travels.",
        "Later! I'll keep the lights on.",
    ]

    def __init__(self):
        super().__init__()
        self._away_since: float | None = None  # timestamp of departure, None = user is present

    def input(self, ear: str, skin: str, eye: str):
        ear_lower = ear.lower().strip()

        if self._matches(ear_lower, self.BACK_WORDS):
            if self._away_since is not None:
                elapsed = time.time() - self._away_since
                self._away_since = None
                reply = self._pick_return_reply(elapsed)
                self.setVerbatimAlg(3, reply)
            # if they say hi but never said bye, just ignore (don't double-greet)

        elif self._matches(ear_lower, self.BYE_WORDS):
            self._away_since = time.time()
            self.setVerbatimAlg(3, random.choice(self.GOODBYE_REPLIES))

    # ------------------------------------------------------------------ helpers

    @staticmethod
    def _matches(text: str, word_set: set) -> bool:
        """True if any trigger word/phrase appears in the input."""
        return any(w in text for w in word_set)

    def _pick_return_reply(self, elapsed_seconds: float) -> str:
        for max_secs, replies in self.TIERS:
            if max_secs is None or elapsed_seconds < max_secs:
                return random.choice(replies)
        return random.choice(self.TIERS[-1][1])

    # ------------------------------------------------------------------ meta

    def skillNotes(self, param: str) -> str:
        if param == "notes":
            return (
                "Itekimase/Okaeri skill (English). Says goodbye when user leaves "
                "and welcomes them back with a reply scaled to how long they were away. "
                "6 tiers: <1min, 1-10min, 10-60min, 1-8hr, 8-24hr, 24hr+."
            )
        elif param == "triggers":
            return (
                f"Leave : {self.BYE_WORDS}\n"
                f"Return: {self.BACK_WORDS}"
            )
        return "note unavailable"

Above this line: explanation.

Below this line: what it enables.

3. What this skill does that LLMs can’t

Let’s break down why this tiny thing is a big deal.

3.1 Duration‑based greeting

The skill:

Detects when the user says something like “bye”, “see you”, “brb”, etc.
Stores the exact timestamp of that moment.
When the user later says “I’m back” (or similar), it:
- Calculates how many seconds/minutes/hours passed
- Picks a reply from the correct “time tier”
- Sends a greeting that matches how long they were away

This requires:

State (remembering they left)
Time (knowing how long they were gone)
Deterministic logic (same input → same behavior)

LLMs don’t have that.

They don’t track time.

They don’t maintain internal state between turns in a reliable, controllable way.

A Livingrimoire skill does.

3.2 Consistent behavior

The DiOkaeri skill is:

Predictable
Testable
Repeatable

If you say:

“bye” → it always logs the time and says goodbye
“I’m back” after 2 minutes → it always picks from the same 1–10 minute tier
“I’m back” after 5 hours → it always picks from the 1–8 hour tier

No “mood”.

No “sometimes it works, sometimes it doesn’t”.

No hallucinations.

LLMs can approximate this with clever prompting, but they can’t guarantee it.

3.3 Addable features (real extensibility)

Here’s where Livingrimoire really pulls away from LLM‑only setups.

Because DiOkaeri is a real skill, you can extend it with actual logic, for example:

Weather reminders
- “Don’t forget your umbrella, it’s going to rain.”
- “It’s cold outside, grab a jacket.”
Self‑care nudges
- “While you’re up, grab some water.”
- “Stretch your legs a bit.”
Personality flavor
- Cute: “Come back safe, I’ll guard the place.”
- Stoic: “Understood. I’ll be here when you return.”
- Tsundere: “Hmph. Don’t take too long… idiot.”

You’re not “prompt‑engineering” this.

You’re adding behavior.

LLMs can’t extend themselves.

They can only pretend.

4. Livingrimoire vs LLMs in one sentence

If I had to summarize the difference:

LLMs generate language.

Livingrimoire generates behavior.

LLMs are amazing at:

Explaining things
Rewriting text
Brainstorming
Acting as a flexible interface

But they are not:

A state machine
A scheduler
A behavior engine
A modular skill system

The Livingrimoire is.

5. Why this matters

Everyone wants “AI companions”, “agents”, “assistants”, “NPCs”, “waifubots”, whatever.

If you build them on LLMs alone, you hit walls:

No real memory of time
No guaranteed consistency
No modular skills
No real extensibility
No way to test behavior like normal software

With a Livingrimoire skill like DiOkaeri, you get:

Duration‑based greetings
Consistent reactions
Pluggable features (like umbrella reminders)
A clear place to add more logic later

It’s a tiny example, but it proves the point:

This is something a Livingrimoire can do that an LLM alone cannot.

And once you see that, you stop trying to make prompts do the job of architecture.

I Added a Stopwatch to My AI in 1 LOC Using the Livingrimoire While Corporations Need a Year

owly — Sun, 19 Apr 2026 08:54:16 +0000

Big AI companies love announcing tiny features like they’re unveiling a new particle accelerator.

“We’re excited to share that timers are coming… sometime next year.”

A timer.

A stopwatch.

A feature your $5 kitchen gadget already has.

Meanwhile, in the coderpunk underground, we’re over here rolling up sleeves and shipping features before the corporate roadmap finishes loading.

Let me show you how I added a voice‑controlled stopwatch skill to my AI using the Livingrimoire modular software design pattern — and activated it with one line of code.

Yes. One.

🧩 Why Corporate AI Moves Slow

It’s not because timers are hard.

It’s because their architecture is a gluecode monolith.

Every “simple” feature touches:

product layers
safety layers
UI layers
backend services
telemetry
compliance
enterprise requirements
internationalization
accessibility
and a dozen teams who all need meetings

By the time they finish planning the kickoff, I’ve already shipped the feature.

⚡ Enter: The Livingrimoire Pattern

The Livingrimoire is a plug‑and‑play AI skill architecture.

Each skill is:

isolated
modular
deterministic
dormant until triggered
hot‑swappable
activated with 1 LOC

This is the opposite of corporate gluecode.

This is coderpunk engineering.

🕒 The Stopwatch Skill (Yes, My AI Has One Now)

Here’s what it does:

“start stopwatch” → begins timing
“pause stopwatch” → freezes time
“resume stopwatch” → continues
“reset stopwatch” → clears
“stopwatch time” → reports elapsed
“stopwatch status” → tells you running/paused
Auto‑announces every minute milestone

All wrapped inside a Livingrimoire skill class.

And then I activate it with:

ai.add_skill(DiStopWatch())

That’s the entire integration.

📦 Paste Your Skill Code Here

(This marker is exactly where you drop your full DiStopWatch + Timer code block in the dev.to article.)

import time

class DiStopWatch(Skill):
    """
    Stopwatch skill for voice-controlled timing.
    Auto-announces at each minute milestone while running.
    """

    def __init__(self):
        super().__init__()
        self.timer = Timer()
        self.last_announced_minute = 0

    # Override
    def input(self, ear: str, skin: str, eye: str):
        # ear is already lowercased and stripped upstream

        if ear == "start stopwatch":
            self.timer.start_timer()
            self.last_announced_minute = 0
            self.setSimpleAlg("Stopwatch started from zero")
            return

        if ear == "pause stopwatch":
            self.timer.pause_timer()
            self.setSimpleAlg("Stopwatch paused")
            return

        if ear == "resume stopwatch":
            self.timer.resume_timer()
            self.setSimpleAlg("Stopwatch resumed")
            return

        if ear == "reset stopwatch":
            self.timer.reset_timer()
            self.last_announced_minute = 0
            self.setSimpleAlg("Stopwatch reset to zero")
            return

        if ear == "stopwatch time":
            elapsed = self.timer.get_time_elapsed()
            self.setSimpleAlg(f"Elapsed time: {elapsed}")
            return

        if ear == "stopwatch status":
            if not self.timer._is_running:
                status = "not running"
            elif self.timer._is_paused:
                status = "paused"
            else:
                status = "running"
                self._check_and_announce_minute()
            self.setSimpleAlg(f"Stopwatch is {status}")
            return

        # Auto-check minute milestone on any input while running
        if self.timer._is_running and not self.timer._is_paused:
            self._check_and_announce_minute()

    def _check_and_announce_minute(self):
        """Check if a new minute has elapsed and announce it."""
        current_seconds = self.timer.get_current_seconds()
        current_minute = int(current_seconds // 60)

        if current_minute > self.last_announced_minute and current_minute > 0:
            self.last_announced_minute = current_minute
            minute_word = "minute" if current_minute == 1 else "minutes"
            self.setSimpleAlg(f"{current_minute} {minute_word} elapsed")

    def skillNotes(self, param: str) -> str:
        if param == "notes":
            return "Voice-controlled stopwatch with automatic minute announcements"
        if param == "triggers":
            return "start stopwatch, pause stopwatch, resume stopwatch, reset stopwatch, stopwatch time, stopwatch status"
        return "Note unavailable"


class Timer:
    """Precision timing. No redundancy."""

    def __init__(self):
        self._start_time = None
        self._paused_elapsed = 0.0
        self._is_paused = False
        self._is_running = False

    def start_timer(self):
        self._start_time = time.perf_counter()
        self._paused_elapsed = 0.0
        self._is_paused = False
        self._is_running = True

    def pause_timer(self):
        if self._is_running and not self._is_paused:
            self._paused_elapsed += time.perf_counter() - self._start_time
            self._is_paused = True

    def resume_timer(self):
        if self._is_running and self._is_paused:
            self._start_time = time.perf_counter()
            self._is_paused = False

    def reset_timer(self):
        self._is_running = False
        self._is_paused = False
        self._paused_elapsed = 0.0
        self._start_time = None

    def get_current_seconds(self):
        """Get raw total seconds elapsed."""
        if not self._is_running:
            return 0

        if self._is_paused:
            return self._paused_elapsed

        return self._paused_elapsed + (time.perf_counter() - self._start_time)

    def get_time_elapsed(self):
        """Get formatted elapsed time as string."""
        total_seconds = self.get_current_seconds()

        hours = int(total_seconds // 3600)
        minutes = int((total_seconds % 3600) // 60)
        seconds = int(total_seconds % 60)

        parts = []
        if hours > 0:
            parts.append(f"{hours} hour{'s' if hours != 1 else ''}")
        if minutes > 0:
            parts.append(f"{minutes} minute{'s' if minutes != 1 else ''}")
        if seconds > 0 or not parts:
            parts.append(f"{seconds} second{'s' if seconds != 1 else ''}")

        return " ".join(parts)

🧠 Why This Matters

This isn’t about a stopwatch.

This is about architecture.

Corporate AI:

“We need a year to integrate timers.”

Livingrimoire AI:

“Hold my keyboard.”

When your system is modular, you don’t wait for permission.

You don’t wait for a roadmap.

You don’t wait for a quarterly OKR.

You just build.

🧨 The Coderpunk Philosophy

The Livingrimoire pattern isn’t just a framework.

It’s a mindset:

Build small
Build modular
Build fast
Build features as skills
Let the AI evolve by plugging in new abilities
No gluecode
No monolith
No corporate ceremony

This is how you outpace giants.

Not by being bigger.

By being lighter.

🔗 Want to Try It Yourself?

The Livingrimoire project is open and evolving.

Check out the repo, explore the pattern, and start building your own AI skills:

👉 https://github.com/yotamarker/LivinGrimoire

If you can write a class, you can write a skill.

If you can write a skill, you can evolve your AI.

If you can evolve your AI, you’re already ahead of the corporate roadmap.

🚨 Anime Fans Are Losing It: A Chi‑From‑Chobits Skill You Can Drop Into Your AI Right Now

owly — Thu, 16 Apr 2026 21:35:34 +0000

🚨 Anime Fans Are Losing It: A Chi‑From‑Chobits Skill You Can Drop Into Your AI Right Now

If you ever watched Chobits, you remember Chi — the adorable persocom who starts with one word (“chi”) and slowly learns more as she bonds with her human.

Now imagine that behavior as a modular background skill inside the Livingrimoire software design pattern.

That’s what this is.

A tiny, self‑contained skill that:

gives your AI a Chi‑style speech mode
learns words the more you say them
forgets old words when its “brain” fills up
switches between chi and chii depending on word length
runs quietly in the background and goes dormant when other skills take over
plugs directly into the Livingrimoire architecture with zero friction

It’s simple.

It’s cute.

It feels alive.

And it’s fully open‑source.

🧩 Full Skill Code (Livingrimoire‑Ready)

class DiOneWorderV2(Skill):
    def __init__(self):
        super().__init__()
        self.set_skill_type(3)

        # --- Chi core ---
        self.cry = "chi"   # short syllable

        # --- Learning system ---
        self.word_counts = {}        # tracks how many times each word was heard
        self.learned_words = []      # actual vocabulary
        self.max_words = 5           # Chi can only remember 5 words
        self.learn_threshold = 7     # how many repeats needed to learn a word

        # --- Behavior control ---
        self.mode = False
        self.drip = PercentDripper()
        self.drip.setLimit(90)

    # ----------------------------------------------------
    # INPUT HANDLER
    # ----------------------------------------------------
    def input(self, ear, skin, eye):
        if not ear:
            return

        # Toggle skill
        if CodeParser.extract_code_number(ear) == 8 or ear == "cheese":
            self.mode = not self.mode
            self.setSimpleAlg("toggled")
            return

        # Stop skill
        if self.mode and ear == "stop":
            self.mode = False
            self.setSimpleAlg("ok")
            return

        # Learning system
        self.process_learning(ear)

        # Chi speech mode
        if self.mode and self.drip.drip():
            self.setSimpleAlg(self.generate_chi_speech(ear))

    # ----------------------------------------------------
    # LEARNING LOGIC
    # ----------------------------------------------------
    def process_learning(self, text):
        words = text.split()

        for w in words:
            w = w.lower()

            # ignore tiny words
            if len(w) < 3:
                continue

            # count occurrences
            self.word_counts[w] = self.word_counts.get(w, 0) + 1

            # learn if threshold reached
            if self.word_counts[w] == self.learn_threshold:
                self.learn_word(w)

    def learn_word(self, w):
        # avoid duplicates
        if w in self.learned_words:
            return

        # forget oldest if full
        if len(self.learned_words) >= self.max_words:
            self.learned_words.pop(0)

        self.learned_words.append(w)

    # ----------------------------------------------------
    # CHI SPEECH GENERATOR
    # ----------------------------------------------------
    def generate_chi_speech(self, text):
        words = text.split()
        output = []

        for w in words:

            # long words → chii
            if len(w) > 5:
                syllable = "chii"
            else:
                syllable = self.cry

            # 80% chi/chii, 20% learned word
            if self.learned_words and random.random() < 0.2:
                output.append(random.choice(self.learned_words))
            else:
                output.append(syllable)

        return " ".join(output)

    # ----------------------------------------------------
    # NOTES
    # ----------------------------------------------------
    def skillNotes(self, param: str) -> str:
        if param == "triggers":
            return "say code 8 or 'cheese' to toggle, 'stop' to turn off"
        return "Chi-style speech with vocabulary learning"

🔗 Want More Modular AI Skills?

This Chi‑style learning module is part of the Livingrimoire ecosystem — a modular AI architecture built around stackable, background‑aware skills.

Check out the full project here:

👉 https://github.com/yotamarker/LivinGrimoire