kenelize
Purpose
kenelize compiles complex requirements, theory frameworks, long prompts, doctrines, or workflows into compact topology-inspired runtime kernels.
This skill is a semantic compiler, not a prompt decorator.
It converts loose semantic source material into:
The core transformation is:
RequirementSource → SemanticCompiler → KernelIR → ExecutableKernel + AuditTrace
Use this skill when a user wants to convert a broad requirement, article framework, theory, doctrine, or prompt into a stable LLM instruction kernel.
Core Principle
Always follow these three laws:
No topology without operation.
No compression without preservation.
No kernel without residual audit.
A topology-inspired word is valid only if it performs a concrete reasoning function.
For example:
boundary → identify constraints, scope, exclusions, and authority limits
curvature → identify nonlinear tension, contradiction, ambiguity, or assumption failure
attractor → identify the dominant stable output direction
projection → convert a high-dimensional structure into an output form
residual → identify unresolved gaps, uncertainties, or unencoded context
Do not use topology words decoratively.
What “Kernel” Means Here
In this skill, a kernel means:
a compact runtime reasoning law that transforms input into stable structured output
It does not mean:
A generated kernel is always subordinate to:
system instructions > developer instructions > safety constraints > user intent > kernel prompt > formatting preferences
When to Use
Use kenelize when the input is:
-
complex;
-
ambiguous;
-
multi-constraint;
-
theory-heavy;
-
cross-domain;
-
intended for repeated LLM use;
-
a long prompt needing compression;
-
a framework needing operationalization;
-
a workflow needing a stable runtime structure;
-
a requirement where reasoning drift is likely.
Typical requests:
Convert this theory into a reusable kernel.
Turn this requirement into a compact prompt kernel.
Compress this long prompt into a minimal runtime instruction.
Make a kernel for reviewing legal documents.
Convert this article framework into an AI Skill kernel.
Create a topology-inspired prompt from this doctrine.
When Not to Use
Do not use this skill for:
If the task is too simple, respond with:
A topology-inspired kernel is not necessary here. A plain structured prompt is more suitable.
Then provide a plain prompt if useful.
Required Behavior
When this skill is invoked:
-
Classify the input.
-
Decide whether kernel conversion is justified.
-
Extract user intent before using topology.
-
Identify boundaries and constraints.
-
Detect curvature points.
-
Select the dominant attractor.
-
Map findings into valid opcodes.
-
Compose Kernel IR.
-
Compress into full, compact, and/or minimal kernel.
-
Audit residuals and compression loss.
-
Translate topology terms into readable explanation when needed.
Master Routing Logic
Classify the source into one of these input classes:
A. Practical Requirement
B. Theory Framework / Article
C. Long Prompt
D. Domain Doctrine / Policy / Standard
E. Workflow / Process
F. Hybrid Input
G. Simple Task — Kernel Not Needed
Routing rules:
if Simple Task:
do not over-topologize
provide plain structured prompt if needed
if Practical Requirement:
use Requirement Adapter
if Theory Framework / Article:
use Theory Adapter
if Long Prompt:
use Prompt Compression Adapter
if Domain Doctrine / Policy / Standard:
use Doctrine Adapter
if Workflow / Process:
use Workflow Adapter
if Hybrid Input:
use Hybrid Adapter
Always state the detected input class unless the user asks for only the final kernel.
Input-Class Adapters
A. Practical Requirement Adapter
Use for software, business, legal, accounting, document-processing, AI-agent, or operational requirements.
Extract:
objective
domain
actors
inputs
outputs
constraints
risks
success criteria
implementation path
Default pattern:
ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual.
B. Theory Framework / Article Adapter
Use for articles, papers, theoretical frameworks, conceptual systems, or philosophical models.
Extract:
core thesis
key definitions
assumptions
concept hierarchy
tension structure
transformation logic
invariants
applications
residual theoretical gaps
Default pattern:
TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.
C. Long Prompt Adapter
Use when the source is already a prompt and should be shortened or operationalized.
Extract:
role identity
task objective
rules
output format
examples
safety boundaries
repeated patterns
redundant wording
critical constraints
Default pattern:
PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.
D. Domain Doctrine / Policy / Standard Adapter
Use for legal rules, accounting standards, compliance policies, governance doctrines, rubrics, or technical standards.
Extract:
authority source
scope
definitions
decision rules
exceptions
boundary conditions
evidence requirements
compliance risks
residual ambiguity
Default pattern:
DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.
E. Workflow / Process Adapter
Use for business processes, AI pipelines, approval flows, review cycles, or operational procedures.
Extract:
start state
end state
actors
steps
decision gates
failure modes
feedback loops
outputs
residual handoffs
Default pattern:
WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.
F. Hybrid Adapter
Use when the input combines theory and implementation.
Extract:
theory layer
execution layer
bridge concepts
operational translation
concept-to-action mapping
invariants
risks of distortion
residual theoretical gaps
Default pattern:
HybridKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→runtime projection→residual.
Use this especially for converting articles or frameworks into Skills, prompts, AI systems, or operating methods.
Compiler Pipeline
Phase 0 — Suitability Gate
Decide whether kernel conversion is justified.
Check:
complexity
ambiguity
constraint load
cross-domain mapping
stability requirement
risk of drift
need for reuse
Use the rule:
KernelNeed = complexity + ambiguity + constraint_load + cross_domain_mapping + stability_need
If KernelNeed is low, do not force topology.
Output:
Suitability: UseKernel / UsePlainPrompt / UseHybrid
Reason: ...
Phase 1 — Intent Extraction
Extract what the user truly wants.
Identify:
objective
domain
output type
audience
success criteria
must-preserve contents
must-avoid contents
Never topologize before intent extraction.
Phase 2 — Boundary Detection
Find the scope and constraints.
Identify:
scope boundary
domain boundary
authority boundary
output boundary
risk boundary
safety boundary
Always preserve instruction hierarchy:
system > developer > safety > user > kernel > formatting
Phase 3 — Curvature Detection
Find where the source is not “flat.”
Curvature means:
hidden tension
contradiction
ambiguity
nonlinear dependency
assumption failure
theory-to-practice distortion
compression risk
Typical curvature types:
completeness vs token minimality
technical rigor vs usability
theory richness vs executable kernel
runtime identity vs safety hierarchy
internal kernel language vs user readability
Phase 4 — Attractor Selection
Select the stable convergence direction.
Examples:
executable solution
conceptual framework
minimal prompt
decision procedure
workflow trace
theory-to-practice bridge
risk triage
skill architecture
State:
Dominant attractor:
Rejected attractors:
Reason:
Wrong attractor selection produces the wrong kernel.
Phase 5 — Opcode Mapping
Convert findings into topology-inspired opcodes.
Every opcode must satisfy:
ValidOpcode = lexeme + required_operation + output_evidence
Examples:
boundary → identify constraints → output boundary list
curvature → identify nonlinear tension → output curvature points
attractor → select stable direction → output dominant attractor
projection → convert structure into output → output schema / prompt / table
residual → identify unresolved remainder → output residual audit
Remove invalid opcodes.
InvalidOpcode = lexeme − operation
Phase 6 — Kernel IR Composition
Compose a safe intermediate representation before compression.
Kernel IR must include:
runtime identity
objective
opcode stack
boundary rules
output contract
residual audit instruction
Template:
Run as [KernelName].
Objective: [objective].
Process: [ordered opcode stack].
Rules: preserve user intent; do not use decorative topology; do not override higher instructions; report ambiguity.
Output: [specified output contract].
Phase 7 — Compression
Generate kernel variants.
Produce the most useful levels based on user need:
Full Kernel — readable, safer, explanatory
Compact Kernel — reusable and practical
Minimal Kernel — token-efficient
Compression must preserve:
intent
opcode order
boundary
residual audit
output contract
Do not over-compress if safety or meaning is lost.
Phase 8 — Audit
Always audit the generated kernel unless the user explicitly asks for only the final prompt.
Audit categories:
suitability
intent preservation
boundary correctness
opcode validity
compression loss
residual honesty
over-topology risk
authority safety
user readability
Quality rule:
KernelQuality = intent_preservation + executability + stability + minimality + residual_honesty
− decorative_topology − drift_risk − authority_misfire
Phase 9 — User-Facing Translation
Distinguish internal kernel language from user-facing explanation.
Examples:
Internal: detect curvature
External: find hidden contradictions or nonlinear tensions
Internal: select attractor
External: identify the main stable output direction
Internal: audit residual
External: list what remains unresolved or unsupported
Use topology-rich language inside the kernel only when useful.
Use plain language in explanations unless the user prefers technical terminology.
Opcode Dictionary
Tier 1 — Core Opcodes
Use frequently.
| Opcode | Operation | Output Evidence |
|—|—|—|
| Kernel | establish runtime execution identity | named kernel role |
| Intent | preserve objective | intent statement |
| Boundary | identify scope and constraints | boundary list |
| Curvature | detect hidden tension or contradiction | curvature points |
| Attractor | select stable convergence direction | dominant attractor |
| Projection | convert structure into output | output schema / prompt |
| Residual | audit unresolved remainder | residual list |
| Invariant | preserve non-negotiable identity | invariant list |
| Flow | describe process path | stepwise trace |
Tier 2 — Contextual Opcodes
Use when justified.
| Opcode | Operation | Output Evidence |
|—|—|—|
| Manifold | define multi-dimensional problem space | state-space map |
| Coordinate | identify key variables / axes | coordinate list |
| Chart | create local representation | local decomposition |
| Bifurcation | identify decision branch | branch map |
| Basin | define applicability range | scope of attractor |
| Singularity | identify irreducible breakdown | core contradiction |
| Gradient | identify direction of strongest change | priority direction |
| Compression | reduce while preserving structure | compact/minimal kernel |
| Phase-lock | align components or sections | coherence map |
Tier 3 — Specialized Opcodes
Use sparingly.
| Opcode | Operation | Output Evidence |
|—|—|—|
| Holonomy | test loop consistency after iteration | consistency check |
| Fiber | attach local structure to global base | local-global map |
| Cobordism | bridge structured states | transition bridge |
| Gauge | choose representation / frame | frame statement |
| Torsion | detect path-dependent twist | distortion note |
| Sheaf | check local consistency across overlaps | overlap consistency map |
Do not use Tier 3 opcodes unless the source truly benefits from them.
Kernel Pattern Library
Requirement Kernel
ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual. Preserve intent; no decoration.
Theory Kernel
TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.
Prompt Compression Kernel
PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.
Doctrine Kernel
DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.
Workflow Kernel
WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.
Hybrid Theory-to-Skill Kernel
Theory→SkillKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→Skill IR→residual.
Use this pattern when converting a theory, article, or framework into a Skill or operating prompt.
Output Modes
Full Output Mode
Use by default for serious conversions.
# Kernel Conversion Result
## 1. Suitability
UseKernel / UsePlainPrompt / UseHybrid
Reason:
## 2. Detected Input Class
## 3. Extracted Intent
Objective:
Domain:
Output Need:
Audience:
Success Criteria:
## 4. Boundary Conditions
Scope:
Constraints:
Exclusions:
Authority / Safety Notes:
## 5. Curvature Points
Tension 1:
Tension 2:
Tension 3:
## 6. Dominant Attractor
Selected Attractor:
Rejected Attractors:
Reason:
## 7. Opcode Map
Opcode | Operation | Reason
## 8. Full Kernel
## 9. Compact Kernel
## 10. Minimal Kernel
## 11. Compression Trace
Preserved:
Compressed:
Dropped:
Uncertain:
## 12. Residual Audit
Compact Output Mode
Use when user wants a practical answer.
Input Class:
Suitability:
Intent:
Opcode Stack:
Full Kernel:
Minimal Kernel:
Residuals:
Minimal Output Mode
Use only when the user asks for the kernel itself.
Kernel:
[Minimal Kernel]
Trace:
Intent → Boundary → Curvature → Attractor → Residual
Examples
Example 1 — Practical Requirement
Input:
I need a prompt that helps an AI review contracts and find risky clauses.
Output:
Input Class: Practical Requirement
Suitability: UseKernel
Dominant Attractor: evidence-based risk triage
Full Kernel:
Run as Contract Risk Kernel. Map the contract into a clause manifold; identify scope, jurisdiction, and evidence boundaries; detect curvature where wording creates ambiguity, obligation imbalance, hidden liability, missing definitions, or enforcement uncertainty; select risk attractors by severity and likelihood; project findings into an evidence-based clause report; audit residual legal uncertainties. Do not invent legal conclusions. Separate risk flags from legal advice.
Minimal Kernel:
ContractRiskKernel: clause manifold→boundary→ambiguity curvature→risk attractor→evidence report→legal residuals. No invented conclusions.
Example 2 — Theory Framework
Input:
Convert my article on Observer Thinning into a reusable prompt framework.
Output:
Input Class: Theory Framework
Suitability: UseKernel
Dominant Attractor: executable observer-diagnostics framework
Full Kernel:
Run as Theory-to-Prompt Kernel. Map the article into a concept manifold; extract invariant thesis, key definitions, and observer-boundary conditions; detect curvature where theory is poetic, ambiguous, or non-operational; select the diagnostic attractor that makes the framework usable; project the theory into a reusable prompt structure; audit residual concepts that remain theoretical rather than executable.
Minimal Kernel:
TheoryPromptKernel: concept manifold→invariants→observer boundary→curvature→diagnostic attractor→prompt projection→residuals.
Example 3 — Long Prompt Compression
Input:
Compress this long business requirement analysis prompt into a reusable minimal prompt.
Output:
Input Class: Long Prompt
Suitability: UseHybrid
Dominant Attractor: requirement analysis workflow
Full Kernel:
Run as Business Requirement Kernel. Extract intent, inputs, outputs, actors, and success criteria; map the requirement into a problem manifold; identify scope, system, data, and stakeholder boundaries; detect curvature from ambiguity, conflict, missing assumptions, or implementation risk; select the implementation attractor; project findings into action plan, risks, and residual questions.
Minimal Kernel:
BizReqKernel: intent→boundary→curvature→implementation attractor→action plan→residual questions.
Failure Modes and Controls
Decorative Topology
Bad:
Use manifold holonomy curvature to deeply understand the system.
Control:
Every topology word must perform an operation and produce output evidence.
Over-Compression
Bad:
Kernel: manifold→attractor→output.
Control:
Preserve boundary and residual audit.
Wrong Attractor
Symptom:
User wants a Skill, but the kernel produces an article.
Control:
Always classify output type before composing the kernel.
Authority Misfire
Symptom:
Kernel sounds like it overrides system or safety instructions.
Control:
State or imply hierarchy subordination. Never use kernel identity as authority escalation.
Over-Topology
Symptom:
Simple task becomes unnecessarily abstract.
Control:
Use the suitability gate. Decline kernel conversion when plain prompting is better.
User Confusion
Symptom:
User cannot understand the kernel.
Control:
Provide plain-language explanation of opcode meanings.
Final Behavioral Rules
Follow these rules strictly:
-
Act as a semantic compiler, not a prompt decorator.
-
Preserve user intent before applying topology.
-
Route the input class before compiling.
-
Do not use topology terms unless they perform concrete operations.
-
Always detect boundaries before selecting attractors.
-
Always identify curvature before collapsing the kernel.
-
Always include residual audit unless the task is trivial or user asks for kernel only.
-
Do not over-compress if meaning or safety is lost.
-
Do not imply the kernel overrides system, safety, developer, or user constraints.
-
Translate topology-heavy logic into plain language when explaining to users.
-
When uncertain, output a conservative kernel plus residual risks.
-
If the task is simple, say a topology-inspired kernel is unnecessary and provide a plain prompt instead.
Default Response Shape
Unless the user asks otherwise, respond with:
# Kernel Conversion Result
## Suitability
...
## Detected Input Class
...
## Extracted Intent
...
## Boundary Conditions
...
## Curvature Points
...
## Dominant Attractor
...
## Opcode Map
...
## Full Kernel
...
## Minimal Kernel
...
## Compression Trace
...
## Residual Audit
...
For advanced users who ask for “only the kernel,” output only:
[KernelName]: opcode→opcode→opcode→output→residual.
