Back to blog
Codex Skills

Update Skills

Controlled self-learning for Codex after completed real work

Reusable lesson triage, strict rejection, narrow ownership and no-change defaults

n8n Skill Update as the reference model for global skill maintenance
Codex skills, learning loop and reusable workflow guidance
Main topicupdate skill
System focusReusable Lesson Triage
Work statusMANUAL / CONTROLLED
n8n update skill controlled self-learning loop
Controlled learning loop for Codex skills
n8n skill update log
$ n8n-skill-update --after-session

scan completed workflow work
extract reusable failure modes
patch one skill or report no change
Engineering notes

The Role of an Update Skill

Maintenance after real work is complete

An update skill is a maintenance skill. It does not solve the user's primary task. It runs after meaningful work is finished and asks a narrower question: did this session reveal a reusable lesson that should improve future Codex behavior?

Not Memory, Not Notes

Learning is a gated write operation

The goal is not to store everything Codex saw. Raw project memory quickly becomes noisy: local field names, temporary workarounds, private URLs, one company's business rules, and already-known patterns all get mixed together. Update skills prevent that by treating learning as a gated write operation.

Default to No Change

The safest output is often no update

The safest default is no update. Work being completed is not evidence that a global skill should change. A patch is justified only when the session produced a lesson likely to help future unrelated projects. If nothing survives that filter, the correct output is an explicit no-change result.

N8N Update as the Reference Model

A concrete updater family pattern

n8n Skill Update is the reference implementation of this pattern. It does not build n8n workflows. It inspects completed n8n work, extracts reusable workflow lessons, and decides whether to update n8n Core, update one focused n8n-* skill, create one new focused skill, or leave the family unchanged.

The n8n Skill Family

Ownership split by reusable mechanism

The current n8n family is split by ownership. n8n Core holds broad workflow design principles. Focused skills own repeated mechanisms: protected-site fetching, Loop Over Items wiring, Code node transformations, item linking, Telegram formatting, Data Table dedupe, and Wappi WhatsApp workflows. n8n Skill Update maintains the map.

What Counts as a Lesson

Portable patterns that change future work

A valid lesson is portable. In n8n, that means reusable workflow patterns, recurring failure modes, debugging heuristics, stable node-ordering rules, Code node patterns, item-shape rules, sink formatter rules, batching heuristics, and rate-limit behavior. The lesson should change how future workflows are designed or debugged.

What Must Be Rejected

Project-only material stays out

The updater rejects minor wording preferences, one-off business logic, project-specific field names, isolated hacks, private endpoints, credentials, tokens, payloads, and duplicate guidance. A lesson that only explains one client's workflow is not a global skill update. A lesson already covered well enough is also not an update.

Core vs Focused Ownership

Narrowest owner wins

n8n Core should change only when the lesson affects general n8n thinking: item semantics, where loops belong, when to use Set versus Code, how to debug step by step, or how to reason about node order. A focused skill should change when the lesson belongs to one repeated mechanism, such as pairedItem recovery or Telegram chunking.

New Skill Creation

Rare path for recurring mechanisms

Creating a new n8n-* skill is the rare path. It requires a reusable lesson that does not fit an existing owner, represents a recurring mechanism, and can remain narrow. Good candidates are mechanism-shaped. Bad candidates are project-shaped: a company's HR screening logic, a CRM-specific field map, or one workflow's decision table.

Smallest Useful Patch

Minimal change over broad rewrite

Update skills should avoid broad rewrites. The patch should be the smallest change that improves future behavior: one rule, one decision heuristic, one warning, one routing clarification, or one example cleanup. This keeps global skills practical instead of turning them into long theory documents.

Self-Update Requirement

Updater maps must stay accurate

If the skill family changes, the updater must update itself. For n8n Skill Update, this means refreshing the current skill list, routing guidance, and reusable prompt section whenever an n8n-* skill is created, renamed, merged, or removed. A stale updater makes future routing decisions against the wrong map.

Reusable Prompt Contract

Always emit the refreshed operating prompt

A good update skill can always emit a refreshed reusable prompt. That prompt lists the current family, explains when to update an existing skill, when to create a focused skill, when to update core, and when to do nothing. It also instructs future Codex runs to keep the family map accurate.

Manual Learning Loop

Reviewable learning instead of uncontrolled memory

The manual trigger matters. Automatic updates after every session would create noise and increase the risk of storing local context. A user-initiated update step turns learning into reviewable maintenance: inspect, filter, route, patch, and report. The AI learns, but not by writing uncontrolled memory.

Technical Value

Concrete guidance for known failure modes

The value is operational. Future Codex runs start with better instructions for known failure modes. The model gets more precise about n8n item shapes, loop placement, formatter behavior, API fetch strategy, and debugging order. The improvement is not stored as vague experience; it becomes concrete executable guidance.

Final Model

Strict filtering, narrow ownership and explicit no-change

An update skill is a controlled self-learning mechanism. It converts real work into durable guidance only when the lesson is reusable, scoped, and owned by the right skill. n8n Skill Update demonstrates the architecture: strict filtering, narrow ownership, minimal patches, explicit no-change behavior, and self-maintained family routing.

Controlled learning flow
inspect completed work
extract candidate lessons
discard project-only material
match each survivor to the narrowest owner skill
apply the smallest useful patch
refresh updater map if the family changed