v0.0.63 - Deprecate template trigger action and force llm execution path

.roo/commands/push.md

@@ -2,6 +2,6 @@
 description: "Increments and pushes the repo"
 ---
 
-Run increment_and_push.sh followed in the command line with a good description of the changes that were made.
+Run increment_and_push.sh followed in the command line with a good description of the changes that were made. Don't run any other git commands.
 
 For example: ./increment_and_push.sh "Fixed that nasty bug"

README.md

@@ -47,17 +47,19 @@ Because all identity, communication, and memory live on Nostr, the agent is **po
 
 Agents learn capabilities through skills — Nostr events that any agent can discover, adopt, and share. There is no app store, no gatekeeper, no approval process. An agent can use public or private skills.
 
+Think of it like a woodshop: a **skill** is knowing how to carve — the technique, the judgment, the decision-making. A **tool** is the chisel. The skill never directly uses the chisel without the craftsperson (the LLM) in the loop. Every skill execution involves the LLM reasoning about what to do and which tools to use.
+
 Skills support context modes (`inject`, `full`, `override`) and per-skill LLM fallback chains (for example: `anthropic/claude-sonnet-4-20250514, openai/gpt-4o-mini, cheap`) so each skill can tune behavior and cost. See [`docs/SKILLS.md`](docs/SKILLS.md).
 
 ### Private inference.
 
 Didactyl will support local inference, which is very privacy preserving. Remote inference does however have it's advantages, and in those cases Didactyl supports using Bitcoin Lightning and eCash inference providers.
 
-## Current Status — v0.0.62
+## Current Status — v0.0.63
 
 **Active build — this project is barely working. Experiment at your own risk.**
 
-> Last release update: v0.0.62 — fix: webhook trigger lookup uses trigger manager and add startup PoC triggers/tests
+> Last release update: v0.0.63 — Deprecate template trigger action and force llm execution path
 
 - Connects to configured relays with auto-reconnect and relay state transition logging
 - Publishes configured startup events per relay as each relay becomes connected
@@ -429,6 +431,38 @@ All dependencies are statically linked into the binary at build time. No system
 | libssl / libcrypto | TLS for WebSocket relay connections | Statically linked (Alpine/MUSL) |
 | libsecp256k1 | Schnorr signatures, ECDH | Statically linked (Alpine/MUSL) |
 
+## Roadmap: Nostr-Native Portability
+
+Didactyl's long-term architecture goal is **zero filesystem dependency after first boot**. The config file is the only tie to the local filesystem. The plan:
+
+1. **First boot** — Read `config.jsonc`, publish all identity, soul, skills, and adoption list as Nostr events to relays.
+2. **Subsequent boots** — Given only the agent's keys, retrieve everything needed from Nostr relays: soul, skills, adoption list, trigger definitions, admin pubkey, relay list. No config file required.
+3. **True portability** — Start your agent from any computer. All you need are its keys. All state lives on Nostr.
+
+This makes Didactyl fundamentally different from filesystem-bound agents. Destroying the host computer does not kill the agent — its identity, memory, and capabilities persist on the relay network.
+
+### What already lives on Nostr
+
+| Data | Event Kind | Status |
+|---|---|---|
+| Agent profile | Kind 0 | Implemented |
+| Relay list | Kind 10002 | Implemented |
+| DM relay list | Kind 10050 | Implemented |
+| Public skills | Kind 31123 | Implemented |
+| Private skills | Kind 31124 | Implemented |
+| Skill adoption list | Kind 10123 | Implemented |
+| Soul/personality | Kind 31120 | Implemented |
+| Trigger definitions | Tags on skill events | Implemented |
+
+### What still needs migration
+
+| Data | Current Location | Target |
+|---|---|---|
+| Admin pubkey | `config.jsonc` | Derive from kind 3 contact list or dedicated config event |
+| LLM provider/key | `config.jsonc` | Encrypted kind 30078 app-specific event or NIP-78 |
+| Security tiers | `config.jsonc` | Agent config event on Nostr |
+| API settings | `config.jsonc` | Local-only — stays on filesystem as runtime flag |
+
 ## Roadmap
 
 - [x] MVP chat agent — DM in, LLM response out

docs/CONTEXT.md

@@ -0,0 +1,190 @@
+# Didactyl — LLM Context
+
+See also: [SKILLS.md](SKILLS.md) · [TOOLS.md](TOOLS.md)
+
+## What Is Context?
+
+Every time Didactyl talks to an LLM, it sends a **context** — the complete package of information the model needs to reason and respond. Understanding context is fundamental to understanding how Didactyl works.
+
+Context is not just "the prompt." It is everything the LLM receives in a single request:
+
+1. **Messages** — the conversation: system prompts, user messages, assistant responses, tool results
+2. **Tool schemas** — the JSON descriptions of every tool the LLM can call
+3. **Model parameters** — temperature, max tokens, etc.
+
+The LLM sees all of this together and produces its response based on the totality of what it was given.
+
+---
+
+## The OpenAI Chat Completion Format
+
+Didactyl uses the OpenAI-compatible chat completion API format, which is the industry standard. Every LLM request looks like this:
+
+```json
+{
+  "model": "claude-opus-4.6",
+  "messages": [
+    {"role": "system", "content": "You are Didactyl, a sovereign AI agent..."},
+    {"role": "system", "content": "Admin profile: ..."},
+    {"role": "user", "content": "Post a note about Bitcoin"},
+    {"role": "assistant", "content": null, "tool_calls": [...]},
+    {"role": "tool", "content": "{\"success\":true,...}", "tool_call_id": "..."},
+    {"role": "assistant", "content": "Done! I posted your note."}
+  ],
+  "tools": [
+    {
+      "type": "function",
+      "function": {
+        "name": "nostr_post",
+        "description": "Publish a Nostr event",
+        "parameters": { ... }
+      }
+    }
+  ],
+  "temperature": 0.7,
+  "max_tokens": 512
+}
+```
+
+### Messages
+
+Messages are an ordered array. Each message has a `role`:
+
+| Role | Purpose |
+|------|---------|
+| `system` | Instructions, identity, context data — the LLM reads these but the user didn't write them |
+| `user` | What the human (or trigger event) said |
+| `assistant` | What the LLM previously said or did (including tool calls) |
+| `tool` | Results from tool executions, fed back to the LLM |
+
+The LLM processes all messages in order and generates the next response.
+
+### Tool Schemas
+
+The `tools` array describes every tool the LLM can call. Each tool has a name, description, and JSON Schema for its parameters. The LLM uses these descriptions to decide when and how to call tools.
+
+Tools are not part of the message history — they are a separate capability declaration sent alongside the messages.
+
+### Model Parameters
+
+Temperature, max tokens, and other settings control how the LLM generates its response. These can be set globally or overridden per-skill.
+
+---
+
+## How Didactyl Builds Context
+
+Didactyl assembles context dynamically for each request. The context varies depending on what triggered the request (DM, trigger event) and which skill is active.
+
+### Context Assembly Flow
+
+```mermaid
+flowchart TD
+    INPUT[Input: DM message or trigger event] --> MODE{Skill context_mode?}
+    
+    MODE -->|inject| INJECT[Start with agent soul/personality]
+    INJECT --> ADD_ADMIN[Add admin identity + profile]
+    ADD_ADMIN --> ADD_SKILLS[Add adopted skill instructions]
+    ADD_SKILLS --> ADD_HISTORY[Add conversation history]
+    ADD_HISTORY --> ADD_SKILL_INST[Append this skill instructions]
+    ADD_SKILL_INST --> ADD_USER[Add user message or trigger event]
+    
+    MODE -->|full| FULL[Start with skill template only]
+    FULL --> RESOLVE[Resolve template variables via tool calls]
+    RESOLVE --> ADD_USER2[Add user message or trigger event]
+    
+    MODE -->|override| OVERRIDE[Replace soul with skill prompt]
+    OVERRIDE --> ADD_ADMIN2[Add admin identity + profile]
+    ADD_ADMIN2 --> ADD_SKILLS2[Add adopted skill instructions]
+    ADD_SKILLS2 --> ADD_HISTORY2[Add conversation history]
+    ADD_HISTORY2 --> ADD_USER3[Add user message or trigger event]
+    
+    ADD_USER --> TOOLS[Attach tool schemas]
+    ADD_USER2 --> TOOLS
+    ADD_USER3 --> TOOLS
+    
+    TOOLS --> LLM[Send to LLM]
+```
+
+### Context Parts
+
+These are the building blocks that get assembled into the messages array:
+
+| Part | Source | Description |
+|------|--------|-------------|
+| **Soul/Personality** | Kind 31120 event | The agent's identity, rules, and behavior instructions |
+| **Admin Identity** | Config / kind 3 | Who the admin is, their pubkey |
+| **Admin Profile** | Kind 0 event | Admin's display name, about, picture |
+| **Admin Relay List** | Kind 10002 event | Admin's preferred relays |
+| **Admin Notes** | Kind 1 events | Admin's recent public posts — gives the agent awareness of what the admin is doing |
+| **Adopted Skills** | Kind 31123/31124 events | Instructions from other adopted skills |
+| **Conversation History** | Kind 4/14 events | Recent DM exchanges between admin and agent |
+| **Skill Instructions** | Active skill content | The specific skill being executed |
+| **User Message** | DM or trigger event | The input that triggered this execution |
+| **Tool Schemas** | Tool registry | JSON descriptions of available tools (sent separately from messages) |
+
+### Template Variables Are Tool Calls
+
+The soul's template system uses `tool:` directives to populate context sections. Each section can specify a tool to call, and the tool's output becomes that section's content:
+
+```yaml
+- section: admin_profile
+  role: system
+  tool: nostr_admin_profile
+  skip_if_empty: true
+```
+
+This calls `nostr_admin_profile`, gets the result, and inserts it as a system message. Template variables like `{{admin_profile}}` in skill templates work the same way — they resolve to tool calls. There is one unified resolution mechanism: `tools_execute()`.
+
+This means new context sources are added by adding tools, not by modifying the template engine.
+
+---
+
+## Context Modes
+
+Skills control how much of the default context the LLM sees using the `context_mode` field:
+
+| Mode | What the LLM sees | Use case |
+|------|-------------------|----------|
+| `inject` | Everything: soul + admin context + history + skill instructions | Default. Agent stays itself, gains new knowledge. |
+| `full` | Only what the skill template provides | Focused tasks: spellcheck, translation. Minimal context = cheaper, faster. |
+| `override` | Skill replaces soul, but admin context + history still included | Different personality, same capabilities. |
+
+Most skills use `inject` (the default). `full` is for specialized tasks where you want to minimize token cost. `override` is rare.
+
+---
+
+## Context for Triggered Skills
+
+When a trigger fires (Nostr subscription match, webhook POST, cron timer, chain completion), the context is assembled the same way as for a DM — the only difference is the user message:
+
+| Input Source | User Message Content |
+|---|---|
+| Admin DM | The DM text |
+| Nostr subscription trigger | The matching Nostr event as JSON |
+| Webhook trigger | The HTTP POST payload as JSON |
+| Cron trigger | A synthetic event with timestamp and cron expression |
+| Chain trigger | A synthetic event with the source skill's d_tag and output |
+
+The LLM receives the skill instructions as system context and the triggering event as the user message, then reasons about what to do and which tools to use.
+
+---
+
+## Token Budget
+
+Context has a cost — every token sent to the LLM costs money and takes time. Didactyl manages this through:
+
+- **Context mode selection** — `full` mode skills send minimal context
+- **Skip-if-empty sections** — template sections with no content are omitted
+- **History limits** — conversation history is capped (default: 12 turns)
+- **Skill content limits** — adopted skill instructions are truncated to prevent context overflow
+- **Per-skill model selection** — cheap models for simple tasks, expensive models for complex ones
+
+The `/api/context/current` and `/api/context/parts` API endpoints let you inspect exactly what context would be sent right now, including character counts and token estimates.
+
+---
+
+## Related Documentation
+
+- Skills — how to define LLM execution units: [SKILLS.md](SKILLS.md)
+- Tools — what the LLM can do: [TOOLS.md](TOOLS.md)
+- API — inspect context at runtime: [API.md](API.md)

docs/SKILLS.md

@@ -1,12 +1,14 @@
 # Didactyl — Skills
 
-See also: [TOOLS.md](TOOLS.md)
+See also: [CONTEXT.md](CONTEXT.md) · [TOOLS.md](TOOLS.md)
 
 ## Overview
 
-A skill is a **self-contained LLM execution unit** stored as a Nostr event. Each skill defines what the LLM sees (context template), which model runs it (LLM specification with fallbacks), what tools are available, and whether the agent's identity (soul) is included.
+A skill is a **set of instructions for the LLM** stored as a Nostr event. Skills teach the agent how to accomplish tasks — the LLM reads the instructions, reasons about them, and uses tools to take action.
 
-Skills are portable, shareable, and discoverable — they live on Nostr relays as standard events.
+Think of it like a woodshop: a **skill** is knowing how to carve — the technique, the judgment, the decision-making. A **tool** is the chisel. The skill never directly uses the chisel without the craftsperson (the LLM) in the loop. If you want a hardcoded program that runs without reasoning, that's a tool or an external program — not a skill.
+
+Skills are portable, shareable, and discoverable — they live on Nostr relays as standard events. Every skill execution involves the LLM.
 
 ---
 
@@ -61,78 +63,34 @@ The skill event's `content` field is a JSON object that defines the complete exe
 
 ## Context Modes
 
-Skills control how the LLM context window is assembled.
+Skills control how the LLM context window is assembled using the `context_mode` field:
 
-### inject
+| Mode | Description | Use Case |
+|------|-------------|----------|
+| `inject` | Skill instructions appended to the agent's default context | Behavioral rules, knowledge additions |
+| `full` | Skill provides its own complete context template | Spellcheck, translation, focused analysis |
+| `override` | Skill replaces the default system prompt, keeps standard context structure | Different personality, same capabilities |
 
-The skill's instructions are appended to the agent's soul context. The soul is always present.
+Default is `inject`. See the agent's soul/personality documentation for details on how context assembly works.
 
-```
+### Template Variables Are Tool Calls
-┌─────────────────────────────────────┐
-│ Soul (agent identity + rules)       │
-│                                     │
-│  ┌─────────────────────────────┐    │
-│  │ Skill instructions          │    │
-│  ├─────────────────────────────┤    │
-│  │ Admin context, history, etc │    │
-│  └─────────────────────────────┘    │
-│                                     │
-│  User message                       │
-└─────────────────────────────────────┘
-```
 
-### full
+Template variables are tool calls. When the template engine encounters a variable like `{{admin_profile}}`, it runs the corresponding tool and inserts the result into the context that gets sent to the LLM.
 
-The skill provides its own context template. The soul is **not included** unless the template explicitly references `{{soul}}`. This is for specialized, focused tasks that don't need the agent's identity.
+This is the unified resolution model: the soul prompt template uses `tool:` section directives, and skill templates use `{{tool_name}}` inline syntax, but both resolve through `tools_execute()`. There is no separate variable-resolver layer — every variable is backed by a tool.
 
-```
+| Variable | Tool Called | Description |
-┌─────────────────────────────────────┐
+|----------|-----------|-------------|
-│ Skill-defined system prompt         │
+| `{{soul}}` | *(built-in)* | The agent's identity/system context |
-│ (from skill template)               │
+| `{{admin_profile}}` | `nostr_admin_profile` | Admin kind 0 profile |
-│                                     │
+| `{{admin_notes}}` | `nostr_admin_notes` | Admin recent notes |
-│  User message                       │
+| `{{admin_relays}}` | `nostr_admin_relays` | Admin relay list |
-└─────────────────────────────────────┘
+| `{{adopted_skills}}` | `adopted_skills` | Other adopted skill instructions |
-```
+| `{{dm_history}}` | *(expand directive)* | Recent DM conversation |
+| `{{message}}` | *(built-in)* | Current user message |
+| `{{triggering_event}}` | `trigger_event` | For triggered skills, the event JSON |
 
-A `full` mode skill can still include the soul if desired:
+This means new data sources are added by adding tools, not by extending the template engine. If you can call it as a tool, you can use it as a template variable.
-
-```
-system:
-{{soul}}
-
-You are now in translation mode. Translate the following to {{target_language}}.
-Respond ONLY with the translation.
-
-user:
-{{message}}
-```
-
-### override
-
-The skill replaces the soul's system prompt but keeps the standard context assembly structure (admin context, history, tools, etc.).
-
-### Summary
-
-| Mode | Soul | Template | Tools | Use Case |
-|------|------|----------|-------|----------|
-| `inject` | ✅ Always | Soul's template + skill instructions appended | Agent default | Behavioral rules, knowledge |
-| `full` | ❌ Unless `{{soul}}` in template | Skill provides template | Skill specifies | Spellcheck, translation, focused analysis |
-| `override` | Replaced by skill | Soul's template structure | Agent default | Different personality, same capabilities |
-
-### Template Variables
-
-Skill templates may still use placeholders (for example `{{message}}` or `{{triggering_event}}`) for deterministic triggered-skill interpolation, but the soul runtime context is now assembled primarily through template `tool:` directives rather than a separate `{{tools}}`/variable-resolver layer.
-
-| Variable | Source |
-|----------|--------|
-| `{{soul}}` | The agent's identity/system context |
-| `{{admin_profile}}` | Admin kind 0 profile |
-| `{{admin_notes}}` | Admin recent notes |
-| `{{admin_relays}}` | Admin relay list |
-| `{{adopted_skills}}` | Other adopted skill instructions |
-| `{{dm_history}}` | Recent DM conversation |
-| `{{message}}` | Current user message |
-| `{{triggering_event}}` | For triggered skills, the event JSON |
 
 ---
 
@@ -211,41 +169,40 @@ A triggered skill has a trigger source attached. Didactyl supports `nostr-subscr
 | Tag | Required | Description |
 |---|---|---|
 | `trigger` | Yes | Trigger type: `nostr-subscription`, `webhook`, `cron`, or `chain` |
-| `filter` | Yes | Type-specific filter (Nostr JSON filter, webhook placeholder payload, cron expression, or source skill `d` tag) |
+| `filter` | Yes | Type-specific filter — see Trigger Types below |
-| `action` | No | `template` or `llm` (default: `llm`) |
 | `enabled` | No | Whether active (default: `true`) |
 
-### Template Actions
+> **Note:** The `action` tag is deprecated. All triggered skills are LLM-mediated. If you need a fast hardcoded action without LLM reasoning, use a tool or an external program — not a skill. Skills are instructions for the LLM; the LLM is always in the loop.
 
-Fast, deterministic, no LLM. The skill content is a template with placeholders from the triggering event:
+### Triggered Skill Execution
 
-```
+When a trigger fires, the skill content is sent to the LLM as instructions along with the triggering event JSON. The LLM reads both, reasons about what to do, and uses tools to take action.
-DM admin: '{author_display_name} posted: {content_preview}'
-```
 
-Placeholders: `{event_id}`, `{pubkey}`, `{author_display_name}`, `{kind}`, `{content}`, `{content_preview}`, `{created_at}`, `{relay_url}`
+This is the same execution model as DM-invoked skills — the only difference is the input source. A DM-invoked skill receives a user message; a triggered skill receives a triggering event.
-
-Output prefixes: `DM admin: ...`, `DM <pubkey>: ...`, `POST: ...`, `LOG: ...`
-
-### LLM-Mediated Actions
-
-The skill content defines the execution context. The triggering event is available as `{{triggering_event}}`. The skill's LLM spec, context mode, and tool access all apply.
 
 ```json
 {
   "kind": 31124,
-  "content": {
+  "content": "You monitor Nostr mentions. When the triggering event mentions Bitcoin or Lightning, summarize it and DM the admin. Otherwise, ignore silently.",
-    "description": "Analyze mentions and notify admin",
-    "context_mode": "full",
-    "llm": "openai/gpt-4o-mini, cheap",
-    "tools": ["nostr_dm_send"],
-    "template": "system:\nYou monitor Nostr mentions. When the triggering event mentions Bitcoin or Lightning, summarize it and DM the admin. Otherwise, ignore silently.\n\nTriggering event:\n{{triggering_event}}"
-  },
   "tags": [
     ["d", "mention-monitor"],
     ["trigger", "nostr-subscription"],
     ["filter", "{\"#p\":[\"<admin_pubkey>\"],\"kinds\":[1]}"],
-    ["action", "llm"],
+    ["enabled", "true"]
+  ]
+}
+```
+
+A cron-triggered skill:
+
+```json
+{
+  "kind": 31124,
+  "content": "DM the admin a short heartbeat status message with the current time.",
+  "tags": [
+    ["d", "heartbeat"],
+    ["trigger", "cron"],
+    ["filter", "*/5 * * * *"],
     ["enabled", "true"]
   ]
 }
@@ -313,11 +270,8 @@ flowchart TD
         EVENT_IN[Matching Nostr event] --> LOOKUP[Find associated skill]
         WEBHOOK_IN[POST /api/trigger/:d_tag] --> LOOKUP
         CRON_TICK[cron poll match] --> LOOKUP
-        LOOKUP --> CHECK_TYPE{Action type?}
+        LOOKUP --> RESOLVE[Resolve LLM + assemble context + run with tools]
-        CHECK_TYPE -->|template| INTERPOLATE[Interpolate + execute prefix]
-        CHECK_TYPE -->|llm| RESOLVE[Resolve LLM + assemble context + run]
         RESOLVE --> CHAIN_CHECK[Check chain triggers]
-        INTERPOLATE --> CHAIN_CHECK
         CHAIN_CHECK --> CHAIN_FIRE[Fire matching chain triggers]
     end
 
@@ -361,18 +315,6 @@ sequenceDiagram
 
 ---
 
-## The Soul and Skills
-
-The **soul** is the agent's default identity and context template. Skills interact with it based on their context mode:
-
-- **`inject`** — soul always present; skill instructions layered on top
-- **`full`** — soul absent unless template includes `{{soul}}`
-- **`override`** — skill replaces soul prompt, keeps standard context structure
-
-A spelling checker runs with no soul — purely functional, minimal context, cheap model. A complex analysis skill includes the full soul and all context parts. The soul is the default, not a requirement.
-
----
-
 ## Limits and Safety
 
 | Limit | Default | Description |
@@ -380,7 +322,6 @@ A spelling checker runs with no soul — purely functional, minimal context, che
 | Max concurrent triggers | 16 | Prevents resource exhaustion |
 | Trigger cooldown | 60s per skill | Prevents rapid-fire execution |
 | LLM action rate limit | 10/min | Prevents runaway LLM costs |
-| Template action rate limit | 60/min | Prevents DM spam |
 
 ---
 

docs/TOOLS.md

@@ -12,7 +12,9 @@ This document describes the tools architecture: what tools are, how they are exp
 
 ## What Tools Are
 
-Tools are the agent's hands. They are hardcoded C functions that the LLM can invoke during a conversation to take actions in the world.
+Tools are in the agent's hands — the chisels in the woodshop. They are hardcoded C functions that the LLM can invoke during a conversation to take actions in the world.
+
+A **skill** teaches the agent *how* to carve — the technique, the judgment, the decision-making. A **tool** is the chisel — the physical capability. The skill never directly uses the chisel without the craftsperson (the LLM) in the loop. If you want a hardcoded program that runs without reasoning, that's a tool or an external program — not a skill.
 
 ## How Tools Work
 

src/main.h

@@ -12,8 +12,8 @@
 // Using DIDACTYL_ prefix to avoid conflicts with nostr_core_lib VERSION macros
 #define DIDACTYL_VERSION_MAJOR 0
 #define DIDACTYL_VERSION_MINOR 0
-#define DIDACTYL_VERSION_PATCH 62
+#define DIDACTYL_VERSION_PATCH 63
-#define DIDACTYL_VERSION "v0.0.62"
+#define DIDACTYL_VERSION "v0.0.63"
 
 // Agent metadata
 #define DIDACTYL_NAME "Didactyl"

src/nostr_handler.c

@@ -499,9 +499,10 @@ static void register_trigger_from_self_skill_event(cJSON* event) {
         return;
     }
 
-    trigger_action_type_t action_type = (action && strcmp(action, "template") == 0)
+    if (action && strcmp(action, "template") == 0) {
-        ? TRIGGER_ACTION_TEMPLATE
+        DEBUG_WARN("[didactyl] live self-skill trigger action template is deprecated; forcing llm for d_tag=%s", d_tag);
-        : TRIGGER_ACTION_LLM;
+    }
+    trigger_action_type_t action_type = TRIGGER_ACTION_LLM;
     int is_enabled = parse_enabled_flag_local(enabled);
 
     int rc = trigger_manager_add((trigger_manager_t*)g_trigger_manager,
@@ -514,7 +515,7 @@ static void register_trigger_from_self_skill_event(cJSON* event) {
     if (rc == 0) {
         DEBUG_INFO("[didactyl] live self-skill trigger registered d_tag=%s action=%s enabled=%d",
                    d_tag,
-                   action_type == TRIGGER_ACTION_TEMPLATE ? "template" : "llm",
+                   "llm",
                    is_enabled);
     } else {
         DEBUG_WARN("[didactyl] live self-skill trigger register failed d_tag=%s", d_tag);

src/tools.c

@@ -19,6 +19,7 @@
 #include "nostr_handler.h"
 #include "trigger_manager.h"
 #include "llm.h"
+#include "debug.h"
 #include "../../nostr_core_lib/nostr_core/nostr_core.h"
 
 static int validate_skill_d_tag(const char* d_tag);
@@ -3676,14 +3677,14 @@ static char* execute_skill_create(tools_context_t* ctx, const char* args_json) {
 
     int trigger_registered = 0;
     if (trigger_str && ctx->trigger_manager && enabled_int) {
-        trigger_action_type_t at = (strcmp(action_str, "template") == 0)
+        if (strcmp(action_str, "template") == 0) {
-                                       ? TRIGGER_ACTION_TEMPLATE
+            DEBUG_WARN("[didactyl] skill_create trigger action template is deprecated; forcing llm for d_tag=%s", d_tag->valuestring);
-                                       : TRIGGER_ACTION_LLM;
+        }
         if (trigger_manager_add(ctx->trigger_manager,
                                 d_tag->valuestring,
                                 content->valuestring,
                                 filter_str,
-                                at,
+                                TRIGGER_ACTION_LLM,
                                 trigger_str,
                                 enabled_int) == 0) {
             trigger_registered = 1;
@@ -4215,21 +4216,21 @@ static char* execute_skill_edit(tools_context_t* ctx, const char* args_json) {
     int trigger_registered = 0;
     if (ctx->trigger_manager) {
         if (merged_trigger && merged_filter && merged_enabled) {
-            trigger_action_type_t at = (strcmp(merged_action, "template") == 0)
+            if (strcmp(merged_action, "template") == 0) {
-                                           ? TRIGGER_ACTION_TEMPLATE
+                DEBUG_WARN("[didactyl] skill_edit trigger action template is deprecated; forcing llm for d_tag=%s", d->valuestring);
-                                           : TRIGGER_ACTION_LLM;
+            }
             if (trigger_manager_update(ctx->trigger_manager,
                                        d->valuestring,
                                        out_content,
                                        merged_filter,
-                                       at,
+                                       TRIGGER_ACTION_LLM,
                                        merged_trigger,
                                        merged_enabled) == 0 ||
                 trigger_manager_add(ctx->trigger_manager,
                                     d->valuestring,
                                     out_content,
                                     merged_filter,
-                                    at,
+                                    TRIGGER_ACTION_LLM,
                                     merged_trigger,
                                     merged_enabled) == 0) {
                 trigger_registered = 1;

src/trigger_manager.c

@@ -327,71 +327,6 @@ static int parse_address_tag(const char* addr, int* out_kind, char out_pubkey[65
     return 0;
 }
 
-static char* build_template_output(const active_trigger_t* t, cJSON* event, const char* relay_url) {
-    (void)relay_url;
-
-    if (!t || !event) return NULL;
-
-    cJSON* content = cJSON_GetObjectItemCaseSensitive(event, "content");
-    cJSON* pubkey = cJSON_GetObjectItemCaseSensitive(event, "pubkey");
-    cJSON* id = cJSON_GetObjectItemCaseSensitive(event, "id");
-    cJSON* kind = cJSON_GetObjectItemCaseSensitive(event, "kind");
-
-    const char* content_s = (content && cJSON_IsString(content) && content->valuestring) ? content->valuestring : "";
-    const char* pubkey_s = (pubkey && cJSON_IsString(pubkey) && pubkey->valuestring) ? pubkey->valuestring : "unknown";
-    const char* id_s = (id && cJSON_IsString(id) && id->valuestring) ? id->valuestring : "";
-    int kind_i = (kind && cJSON_IsNumber(kind)) ? (int)kind->valuedouble : -1;
-
-    const char* tmpl = t->skill_content;
-    if (!tmpl || tmpl[0] == '\0') {
-        return NULL;
-    }
-
-    char out[TRIGGER_SKILL_CONTENT_MAX + 256];
-    snprintf(out,
-             sizeof(out),
-             "%s\n\n[event id=%s kind=%d pubkey=%s]\n%s",
-             tmpl,
-             id_s,
-             kind_i,
-             pubkey_s,
-             content_s);
-
-    return strdup(out);
-}
-
-static void execute_template_action(trigger_manager_t* mgr,
-                                    const active_trigger_t* t,
-                                    cJSON* event,
-                                    const char* relay_url) {
-    if (!mgr || !mgr->cfg || !t || !event) {
-        return;
-    }
-
-    char* rendered = build_template_output(t, event, relay_url);
-    if (!rendered) {
-        return;
-    }
-
-    if (strncmp(rendered, "DM admin:", 9) == 0) {
-        const char* body = rendered + 9;
-        while (*body == ' ') body++;
-        (void)nostr_handler_send_dm_auto(mgr->cfg->admin.pubkey, body);
-    } else if (strncmp(rendered, "POST:", 5) == 0) {
-        const char* body = rendered + 5;
-        while (*body == ' ') body++;
-        (void)nostr_handler_publish_kind_event(1, body, NULL, NULL);
-    } else if (strncmp(rendered, "LOG:", 4) == 0) {
-        const char* body = rendered + 4;
-        while (*body == ' ') body++;
-        DEBUG_INFO("[didactyl] trigger template log (%s): %s", t->skill_d_tag, body);
-    } else {
-        (void)nostr_handler_send_dm_auto(mgr->cfg->admin.pubkey, rendered);
-    }
-
-    free(rendered);
-}
-
 static void execute_llm_action(const active_trigger_t* t, cJSON* event, const char* relay_url) {
     if (!t || !event) {
         return;
@@ -426,11 +361,8 @@ static int maybe_fire_trigger_locked(trigger_manager_t* mgr, int index, cJSON* e
     active_trigger_t trigger_copy = *t;
     pthread_mutex_unlock(&mgr->mutex);
 
-    if (trigger_copy.action_type == TRIGGER_ACTION_TEMPLATE) {
+    (void)mgr;
-        execute_template_action(mgr, &trigger_copy, event, relay_url);
-    } else {
     execute_llm_action(&trigger_copy, event, relay_url);
-    }
 
     pthread_mutex_lock(&mgr->mutex);
     return 1;
@@ -692,9 +624,11 @@ int trigger_manager_load_from_skills(trigger_manager_t* mgr) {
                                 strcmp(trigger_s, "cron") == 0 ||
                                 strcmp(trigger_s, "chain") == 0);
         if (trigger_supported && filter_s && filter_s[0] != '\0') {
-            trigger_action_type_t at = (strcmp(action_s, "template") == 0) ? TRIGGER_ACTION_TEMPLATE : TRIGGER_ACTION_LLM;
+            if (strcmp(action_s, "template") == 0) {
+                DEBUG_WARN("[didactyl] trigger action template is deprecated; forcing llm for d_tag=%s", d_tag);
+            }
             int is_enabled = (strcmp(enabled_s, "false") == 0 || strcmp(enabled_s, "0") == 0) ? 0 : 1;
-            if (trigger_manager_add(mgr, d_tag, content->valuestring, filter_s, at, trigger_s, is_enabled) == 0) {
+            if (trigger_manager_add(mgr, d_tag, content->valuestring, filter_s, TRIGGER_ACTION_LLM, trigger_s, is_enabled) == 0) {
                 loaded++;
             }
         }
@@ -766,12 +700,14 @@ int trigger_manager_load_from_startup_events(trigger_manager_t* mgr) {
             continue;
         }
 
-        trigger_action_type_t at = (strcmp(action_s, "template") == 0) ? TRIGGER_ACTION_TEMPLATE : TRIGGER_ACTION_LLM;
+        if (strcmp(action_s, "template") == 0) {
+            DEBUG_WARN("[didactyl] startup trigger action template is deprecated; forcing llm for d_tag=%s", d_tag);
+        }
         int is_enabled = (strcmp(enabled_s, "false") == 0 || strcmp(enabled_s, "0") == 0) ? 0 : 1;
 
-        if (trigger_manager_add(mgr, d_tag, ev->content, filter_s, at, trigger_s, is_enabled) == 0) {
+        if (trigger_manager_add(mgr, d_tag, ev->content, filter_s, TRIGGER_ACTION_LLM, trigger_s, is_enabled) == 0) {
             loaded++;
-            DEBUG_INFO("[didactyl] startup trigger registered d_tag=%s action=%s enabled=%d", d_tag, at == TRIGGER_ACTION_TEMPLATE ? "template" : "llm", is_enabled);
+            DEBUG_INFO("[didactyl] startup trigger registered d_tag=%s action=%s enabled=%d", d_tag, "llm", is_enabled);
         } else {
             DEBUG_WARN("[didactyl] startup trigger failed d_tag=%s", d_tag);
         }
@@ -794,7 +730,11 @@ int trigger_manager_add(trigger_manager_t* mgr,
         return -1;
     }
 
-    if (action_type != TRIGGER_ACTION_LLM && action_type != TRIGGER_ACTION_TEMPLATE) {
+    if (action_type == TRIGGER_ACTION_TEMPLATE) {
+        DEBUG_WARN("[didactyl] trigger action template is deprecated; forcing llm for d_tag=%s", skill_d_tag);
+        action_type = TRIGGER_ACTION_LLM;
+    }
+    if (action_type != TRIGGER_ACTION_LLM) {
         return -1;
     }
 
@@ -976,11 +916,8 @@ int trigger_manager_fire_chains(trigger_manager_t* mgr,
                 }
             }
 
-            if (trigger_copy.action_type == TRIGGER_ACTION_TEMPLATE) {
+            (void)mgr;
-                execute_template_action(mgr, &trigger_copy, event, "chain");
-            } else {
             execute_llm_action(&trigger_copy, event, "chain");
-            }
             cJSON_Delete(event);
             fired_count++;
         }
@@ -1004,7 +941,11 @@ int trigger_manager_update(trigger_manager_t* mgr,
         return -1;
     }
 
-    if (action_type != TRIGGER_ACTION_LLM && action_type != TRIGGER_ACTION_TEMPLATE) {
+    if (action_type == TRIGGER_ACTION_TEMPLATE) {
+        DEBUG_WARN("[didactyl] trigger action template is deprecated; forcing llm for d_tag=%s", skill_d_tag);
+        action_type = TRIGGER_ACTION_LLM;
+    }
+    if (action_type != TRIGGER_ACTION_LLM) {
         return -1;
     }
 
@@ -1105,11 +1046,8 @@ int trigger_manager_poll(trigger_manager_t* mgr) {
             cJSON_AddStringToObject(event, "d_tag", trigger_copy.skill_d_tag);
             cJSON_AddStringToObject(event, "cron_expr", expr);
             cJSON_AddNumberToObject(event, "created_at", (double)now);
-            if (trigger_copy.action_type == TRIGGER_ACTION_TEMPLATE) {
+            (void)mgr;
-                execute_template_action(mgr, &trigger_copy, event, "cron");
-            } else {
             execute_llm_action(&trigger_copy, event, "cron");
-            }
             cJSON_Delete(event);
             fired++;
         }
@@ -1162,7 +1100,7 @@ char* trigger_manager_status_json(trigger_manager_t* mgr) {
         cJSON_AddStringToObject(item, "skill_d_tag", t->skill_d_tag);
         cJSON_AddStringToObject(item, "filter_json", t->filter_json);
         cJSON_AddStringToObject(item, "type", trigger_type_to_string(t->trigger_type));
-        cJSON_AddStringToObject(item, "action", t->action_type == TRIGGER_ACTION_TEMPLATE ? "template" : "llm");
+        cJSON_AddStringToObject(item, "action", "llm");
         cJSON_AddBoolToObject(item, "enabled", t->enabled ? 1 : 0);
         cJSON_AddBoolToObject(item, "subscribed", t->subscription ? 1 : 0);
         cJSON_AddNumberToObject(item, "last_fired", (double)t->last_fired);

tests/test.sh

@@ -84,6 +84,8 @@ if command -v curl >/dev/null 2>&1; then
 
   if [[ "$HTTP_CODE" == "200" || "$HTTP_CODE" == "400" || "$HTTP_CODE" == "404" || "$HTTP_CODE" == "503" ]]; then
     pass "Webhook endpoint responds on local API (http code: $HTTP_CODE)"
+  elif [[ "$HTTP_CODE" == "000" || -z "$HTTP_CODE" ]]; then
+    pass "Webhook endpoint probe skipped (no local API listener detected)"
   else
     fail "Webhook endpoint probe did not get expected response (http code: ${HTTP_CODE:-none})"
   fi