Forem: Ted Enjtorian

[POG-Task-06] What is the "AI Native Task Governance Model"?

Ted Enjtorian — Tue, 14 Apr 2026 16:59:11 +0000

With the popularity of Large Language Models (LLMs), many development teams have started delegating daily tasks to AI. However, we often find that collaboration with AI lacks stability: the quality of output is inconsistent, and the process is difficult to track, turning the entire workflow into an indecipherable "black box."

To address the pain points of fragmented chat records and lack of management, we proposed the concept of the AI Native Task Governance Model.

This article explores the core mechanisms of this model and how it reshapes the future of software engineering collaboration.

Why do we need an "AI Native" Governance Model?

Traditional project management tools (such as Jira, Trello, etc.) were originally designed for human readers.
A task card might only have a brief description, like "Implement forgot password feature." Human engineers possess domain knowledge and contextual awareness; they can understand, research, and develop with just a simple prompt.

However, when we try to treat AI Agents as "first-class citizens" in the development process, the flaws of legacy systems become apparent. AI lacks the implicit knowledge and project background of humans and cannot quickly and accurately parse blurred task boards filled with the natural language ambiguities of humans.

To this end, we need a new communication framework that is both human-machine readable and explicitly interpretable by machines. This is the core background behind the birth of the "AI Native Task Governance Model."

Core Foundations: Treat Task as Code and Treat Prompt as Code

To enable AI to participate in project development stably and reliably, the AI Native Task Governance Model discards traditional loose task cards and introduces the rigor of software engineering into AI collaboration, establishing two major pillars:

1. Treat Task as Code: Transforming Tasks into "Units of Intention"

Under this governance framework, tasks are no longer just a few lines of free-form text on an interface but are physical files treated just like source code.

Structured Definition: Through standardized data formats (such as YAML combined with JSON Schema), fuzzy human requirements are translated into specification contracts with execution constraints. AI executes within extremely clear boundaries and goals, significantly reducing unpredictable deviations.
Version Control and Review: Task files are stored in Git repositories. This means that task changes, assignments, and status transitions all have a traceable history and can be peer-reviewed through Pull Requests (PRs), ensuring the quality of the "task" itself.

2. Treat Prompt as Code: Transforming Prompts into Maintained Assets

The model emphasizes that Prompts should not be temporary conversations scattered across individual chat windows but should be software assets with lifecycle management.

Standardization and Modularization: Extract the team's best practices into prompt templates. Developers no longer rely on luck to write prompts but invoke verified, versioned "Prompt Libraries" to execute specific tasks.
Continuously Evolving Knowledge Base: When AI performance falls short of expectations, engineers fix more than just the output code; they go back to optimize the prompt templates. Through Git, these "communication skills" are transformed into cumulative and inheritable corporate technical assets.

3. Establishing Auditable and Traceable "Reasoning Traces"

Traditional human-AI collaboration often focuses only on the final output of the AI, while ignoring the value of its logical deduction process. The AI Native Task Governance Model requires that AI's problem-solving logic, reference background, and decision-making basis be recorded completely and systematically through physical files (such as Record.md).

Contexts that used to disappear in temporary chat windows are now transformed into core assets that can be detected by the system and accessed and debugged by the team at any time.

Seamless Collaboration for Cumulative Experience

In summary, the core mission of the AI Native Task Governance Model (such as the POG Task framework) is to establish a set of disciplined and standardized work protocols for development teams adopting AI.

After implementing this model, development teams no longer rely on trial-and-error prompts. Instead, they perform "structured task dispatching." This means moving from "conversational collaboration" to "programmatic task governance," upgrading AI Agents from casual digital assistants to professional development collaborators who follow Standard Operating Procedures (SOPs).

We are transitioning from the old era of "documents written only for humans" to a new era of "human-machine shared standard task protocols." Through the practice of Treat Task/Prompt as Code, we not only improve the precision of AI collaboration but also allow the team's experience to accumulate sustainably through physical "code."

Embracing the AI-native collaboration era and establishing an institutionalized task governance framework will be the indispensable key for enterprises to improve R&D efficiency.

Full Document : https://enjtorian.github.io/pog-task/

Get Pog Task Manager : https://marketplace.visualstudio.com/items?itemName=enjtorian.pog-task-manager

[POG-Task-05] Treat Tasks and Prompts as Code

Ted Enjtorian — Mon, 13 Apr 2026 16:30:19 +0000

AI Native Task Governance Model: Making AI collaboration painless and enabling experience accumulation!

What Was Valuable in the Past? What's Most Expensive Now?

Think back—what did we consider most valuable in the past?

Beautifully written and detailed documentation
Smoothly running, bug-free codebase
Small tools that saved us tons of time

Yes, these are all great. But entering this era of working alongside AI, a new gold standard has emerged: The "Tasks" you define and the "Prompts" you write are extremely valuable!

Unfortunately, many haven't realized this yet. We often treat our communication with AI like disposable chopsticks. Once the chat window is closed, that perfect, thoughtfully refined piece of Prompt simply vanishes into the sea of history.

Let's Look at Our Current "Ungoverned" Workflow

This is the common daily development routine across many teams today (especially within an IDE x Git collaborative environment):

Requirements come in.
They turn into a Project, then get stuffed into Jira & Excel for tracking.
We proceed with Assignment.
Inside the IDE, developers begin navigating through Source Code, SA Docs, SD Docs, and Analytics trying to find context.
Entering the Execution Phase: The developer inputs a Prompt, letting the AI Agent help write code and execute the task.
During this process, the AI Agent is quietly recording the following in the background, deep within "hidden chat blocks":
- Session Context
- Plan Formulation
- Walkthrough (Execution Summary)
- Task Breakdown

Sounds smooth, right? But here is the problem: These precious records meticulously generated by the Agent are buried deep within chat histories, making them extremely difficult to find and retrieve! When the team encounters a similar task next time, they can't locate previous records and are forced to draft a Prompt from scratch and make the AI break down the task all over again. Your distilled "experience" is simply wasted.

Enter the Improved Workflow: Introducing POG-Task

If code can be version-controlled and documentation can be preserved, why can't tasks and prompts?
This is the core concept we want to share: "Treat Tasks and Prompts as Code!"

In POG-Task's design philosophy, we give tasks and prompts an entirely new definition:

Evolving into "Units of Intention": A task is no longer a fleeting chat message. It becomes a structured, human-and-machine-readable, and Agent-governed explicit intention. This ensures that AI has clear, unambiguous boundaries when executing.
Elevated to "First-Class Assets": Your Prompt, task breakdown logic, and the invaluable AI execution history (Record.md) are no longer disposable transition products. They carry the same weight as Source Code—living, Git-versioned assets that accumulate team knowledge.

So, how do we operationalize these philosophies? POG-Task introduces two indispensable "gatekeepers":

task.schema.json (The Law of Tasks): This is a JSON Schema defining exactly what a task should look like. It acts as the legal code for your development environment, strictly standardizing task structures. If a generated task doesn't match the format, the system (or AI) simply ignores it, ensuring all requirements stay within a predictable framework.
pog-task-agent-instructions.md (Agent Instruction Manual): This is a system protocol written explicitly for AI to read. Before starting any work, the AI must consult this guide to ensure its behavioral standards remain consistent and reliable, preventing it from wildly guessing or diverging.

Let's look at the evolved workflow after introducing POG-Task:

Requirements come in.
First, integrate with Project / Jira & Excel / Assignment.
Next, enter the pog-task governance framework.
This time, when you start working in your IDE, alongside your source code and specs, your project now includes:
- Task.yaml (Structured Task)
- docs.md (Comprehensive Task Documentation)
- Record.md (Invaluable AI Execution Records)
The same AI Agent continues to unleash its power (Context, Plan, Walkthrough, Task).
Finally, execute by inputting the Prompt.

Notice the difference? Through Task.yaml and Record.md, your task breakdown logic and the ultimate Prompt tested through AI interactions are entirely materialized, documented, and codified!

Even better, this improved workflow brings two major breakthroughs:

Transparent and Git-Versioned Agent Records: The context that used to be hidden in conversations is now transformed into traceable, version-controllable physical files. Say goodbye to lost history.
Distilling and Reusing Skills: You can re-analyze Record.md at any time to extract the AI's problem-solving methods and experience into reusable "Skills", continuously evolving your entire team's capabilities!

Preserve Your Personal Value, Starting Now!

Every Prompt you create is an intangible asset. To help you seamlessly transition into this workflow, we have developed a dedicated developer tool:

Download the VSCode Plugin Now: POG Task Manager
Search for it in the marketplace to explicitly turbocharge your AI collaboration with these three core features:

Visual Task List Management Use an intuitive tree view in the sidebar to grasp all structured tasks. It actively monitors file changes in real-time and supports status filtering, giving your team perfect visibility over all work.
Built-in Agent Prompt Templates Provides standardized dialogue instructions (e.g., creating a new task, executing a task). It automatically injects project context and supports "one-click copy," saving you from writing lengthy Prompts from scratch.
Task Detail & Reasoning Record Inspection Review or edit task details effortlessly via a user-friendly Webview interface. With a single click, open the corresponding Record.md to instantly trace back the AI Agent's thought processes and execution context.

Initialize Immediately (Init): After installation, the extension will automatically detect your project status and proactively prompt you. One click, and your workspace is fully initialized in seconds!

Stop letting your hard-earned wisdom disappear into the endless river of chat histories. Starting today, manage and reuse your Tasks and Prompts just like you do your Code!

Full Document : https://enjtorian.github.io/pog-task/

Get Pog Task Manager : https://marketplace.visualstudio.com/items?itemName=enjtorian.pog-task-manager

[TOK-02] What is TOCA? The Core Loop of Task-Oriented Cognitive Architecture

Ted Enjtorian — Sun, 08 Mar 2026 14:24:10 +0000

Defining tasks is just the beginning. Making tasks continuously operate and evolve within a cognitive system — that is the real breakthrough.

If You Only Have Definitions, Tasks Are Just Documents

In the previous article, we discussed TOK (Task Ontology Kernel) — defining what a task "is." But definitions alone aren't enough.

Just like defining an elegant Class without a Runtime to execute it — it's just a document.

Tasks are the same. After being defined, we need to answer a more fundamental question:

How do tasks operate within a cognitive system?

This is exactly what TOCA (Task-Oriented Cognitive Architecture) is designed to solve.

Why Traditional Models Fall Short

The computational model we're used to looks like this:

Input → Process → Output

Simple and intuitive. But it has a fatal flaw: no evolution.

Every execution is independent. The experience from the previous run cannot automatically feed back into the next one. You have to manually adjust Prompts, modify code, and reconfigure tools.

In an AI-native environment, what we need is not a straight line, but a closed loop.

TOCA: The Five-Step Core Loop

TOCA breaks down task operation into five steps, forming a continuously evolving closed loop:

Capture (Capture Intent)
    ↓
Dispatch (Dispatch Task)
    ↓
Execute (Execute Task)
    ↓
Validate (Validate Results)
    ↓
Evolve (Evolve Strategy)
    ↓
Dispatch (Next round...)

Let's break them down one by one.

Step 1: Capture — Capturing Intent

Structuring a vague idea into a Task Object.

Human intentions are often ambiguous: "Analyze the performance for me," "This module needs refactoring."

Capture's job is to transform these vague intentions into structured Task Objects — including explicit Intent, Context, Strategy, and Evaluation.

This is the translation layer between humans and the system. In the POG ecosystem, this can be accomplished through conversation, a VS Code Plugin, or by directly writing YAML.

Step 2: Dispatch — Dispatching Tasks

Assigning tasks to the most suitable executor.

Not all tasks are suitable for LLMs. Some require human judgment; others need specific toolchains.

Dispatch's responsibility is to select the most appropriate execution unit based on the nature of the task:

LLM Agent: Suitable for analysis, writing, planning, reasoning
Toolchain: Suitable for compilation, deployment, testing
Human: Suitable for creative decisions, final review, ethical judgment

In TOK's YAML definition, this corresponds to the execution.agent setting.

Step 3: Execute — Executing Tasks

The Agent executes within Context boundaries, producing results and recording a complete trace.

This is the step where things actually get done. The key point is:

The Agent doesn't simply execute scripts. The Agent autonomously decides how to execute.

Task → Agent reads Task Object
     → Agent decides execution strategy
     → Agent uses tools (Shell, API, LLM reasoning)
     → Agent produces results
     → Agent records complete execution trace

The fundamental difference from traditional automation is: the Agent can dynamically select tools, adjust strategies, and even create new subtasks.

In POG Task, execution traces are recorded in record.md — not as Logs, but as a reasoning process that can be reviewed by humans.

Step 4: Validate — Validating Results

Determining whether the Intent has been achieved based on the Evaluation layer.

Producing results alone isn't enough. TOCA requires that every execution must pass validation:

Automated tests: Unit tests, integration tests
Semantic Alignment Check: Does the result truly align with the original Intent?
Human feedback: Final judgment by humans when necessary

Validation failure doesn't mean failure — it means evolution is needed.

Step 5: Evolve — Evolving Strategy

Feeding execution experience back into the Ontology to optimize the next Strategy.

This is TOCA's most powerful step, and the part completely missing from traditional models.

After execution, the system doesn't simply "start over." Instead, it writes this experience into the Strategy layer, making the next execution automatically better:

"Python script was too slow last time; switch to direct SQL queries next time"
"Three steps last time, but they can actually be merged into two"
"Validation criteria were too loose last time; need to add integration tests"

Tasks are not just executed — they evolve.

Why "Cognitive Architecture" Instead of "Workflow Engine"?

You might ask: how is this different from Airflow or Temporal?

The difference is fundamental:

	Workflow Engine	TOCA
Core Concept	DAG / Nodes	Task Object
Executor	Fixed scripts	Autonomous Agent
Evolution Capability	❌ None	✅ Automatic strategy evolution
State	Pipeline state	Cognitive state (persistent and evolvable)

A workflow engine is an Automation Pipeline.

TOCA is Cognition Infrastructure.

A workflow engine lets you run through pre-written steps once. TOCA lets tasks learn how to run better on their own.

A Complete Example

Suppose you have a task: "Analyze API performance weekly and generate a report."

Week 1 (Capture + Execute):

You define a Task Object, with the Strategy set to "Download logs → Python analysis → Generate markdown report"
The Agent executes and produces the report. Validation passes.

Week 2 (Evolve + Execute):

The Evolve step from last time discovered: Python analysis took 15 minutes, but could be done directly with SQL queries
Strategy auto-updates: "SQL query → Generate markdown report"
Execution time drops from 15 minutes to 30 seconds

Week 3 (Evolve + Execute):

Evolve discovers the report format can incorporate charts
Strategy adds a new tool: "SQL query → matplotlib charts → markdown report"

The task is continuously evolving. No manual human adjustment needed.

The True Significance of TOCA

TOCA isn't about "automating some steps."

It's about making thinking itself something that can be saved, reused, and continuously evolved between humans and AI.

In the past, cognition was brain-bound.
Now, cognition can be task-bound.

TOCA is a cognitive architecture with tasks as its core persistent unit, enabling humans and AI to collaboratively execute, evolve, and reuse structured cognitive processes.

Conclusion: Tasks Are Not Just Executed — They Evolve

Defining tasks (TOK) is only the first step. Making tasks continuously operate, learn, and grow stronger within a cognitive system (TOCA) — that is the real watershed moment from the tool era to the AI-native era.

In the next article, we'll look back at how this entire journey unfolded — from POG's Prompt governance, to POG Task's task execution, to TOK's ontological core.

👉 Next: From POG to TOK: A Natural Evolution Path

Full content: https://enjtorian.github.io/task-ontology-kernel

[TOK-01] What is Task Ontology Kernel (TOK)?

Ted Enjtorian — Wed, 04 Mar 2026 12:47:49 +0000

When "task" is no longer just a mental concept for humans, but becomes a native Primitive of the system.

Starting from an Observation

Have you noticed that when you repeatedly use LLMs, you naturally start doing something — organizing, saving, and reusing your Prompts?

At first, a Prompt is just a piece of text. It disappears once you're done.

But when you discover a Prompt that works particularly well, you start to:

Save it
Give it a name
Add a version number
Try to reuse it in different scenarios

At that moment, the Prompt is no longer just a Prompt.

It has become a Task.

Tasks Have Always Existed, But Were Never "Formalized"

Think about it: "Analyze API performance for me," "Build a login module," "Refactor this code" — these are all tasks. But before LLMs came along, they could only exist in human minds, or scattered across Todo Lists, Slack messages, and meeting notes.

They were unstructured mental concepts.

Nobody thought this was a problem, because in the past, only humans could "execute" tasks. Humans can accept vague instructions and automatically fill in missing context.

But LLMs changed everything.

LLMs Are the First "General-Purpose Task Executor" in Human History

Before LLMs, there were only two kinds of "executors": humans, or specialized software.

Now, LLMs can execute almost any cognitive task: analysis, writing, planning, transformation, design, debugging. No need to write specific code for each task.

This means that for the first time, tasks can be directly read and executed by machines.

But the prerequisite is — tasks must become structured.

This Is How TOK Was Born

Task Ontology Kernel solves exactly this problem. It defines:

What is a task? — The structure, identity, and properties of a task
How does a task exist? — State, lifecycle, and dependencies
How does a task evolve? — Versioning, feedback, and strategy iteration

TOK is not a tool, not a system, nor a framework. It is a theoretical foundation — just like Lambda Calculus is to programming languages, or the Relational Model is to databases.

TOK is to Task-native systems what the Relational Model is to relational databases.

What Does a Task Look Like?

In TOK, each task is composed of four layers:

Intent Layer

Describes "what to achieve," not "how to do it."

Context Layer

The environment, permissions, and historical records needed for execution.

Strategy Layer

Task decomposition logic and tool preferences. Can evolve with experience, not a hard-coded process.

Evaluation Layer

The verification protocol for task success — the Definition of Done.

Here's a concrete example:

{
  "id": "task-001",
  "intent": "Analyze API performance logs and generate a summary report",
  "context": {
    "domain": "backend",
    "resources": ["DB read access"]
  },
  "strategy": {
    "steps": ["Aggregate logs", "Calculate percentile metrics", "Generate summary"],
    "tools": ["Python script", "LLM"]
  },
  "evaluation": {
    "definitionOfDone": "Summary aligns with log metrics",
    "tests": ["unit test", "semantic alignment check"]
  }
}

This is no longer a vague text description. It is a structured object that can be directly parsed, executed, and validated by AI.

Why "Ontology"?

The word "Ontology" sounds academic, but its core meaning is very intuitive: defining what "things" exist in a system and how they relate to each other.

Every successful system has its core Primitive:

System	Primitive	Essence
Unix / Linux	Process	Process Ontology Kernel
Git	Commit	Version Ontology Kernel
Kubernetes	Pod	Container Ontology Kernel
TOK	Task	Task Ontology Kernel

Unix didn't "invent" the concept of files. But Unix was the first to make "file" a native Primitive of the system.

TOK doesn't invent "tasks" either. It is the first to formalize tasks as a system Primitive that can be natively executed by AI.

What Does This Mean?

This represents a fundamental paradigm shift in software engineering:

Code-native era: Human intent → Translated into code → Computer executes
Task-native era: Human intent → Structured as tasks → Agent executes

Code hasn't disappeared — it has shifted from being the "core asset" to a "derived tool." Just like when you use Git, the "commit" is the core unit, and files are just attachments to commits.

In Task-native systems, the task becomes the smallest native unit of execution, governance, and evolution, while code becomes a derived artifact generated or coordinated by tasks.

Conclusion: Not Reinventing Tasks, But Formalizing Them for the First Time

Great abstraction discoveries always make you feel "wasn't it always this way?" File, Object, Function, Container — none of them were new things; they were simply formalized for the first time.

TOK is the same.

Tasks have always existed. But after LLMs emerged, tasks finally have the chance to become executable system units — and TOK is the ontological structure defined for this very moment.

👉 Next: What is TOCA? The Core Loop of Task-Oriented Cognitive Architecture

Full content: https://enjtorian.github.io/task-ontology-kernel/

[POG-Task-04] # From Task Executor to POG Task: A Gravity Experiment on Context

Ted Enjtorian — Fri, 13 Feb 2026 22:42:47 +0000

Act I: The Shift in Readership

It all starts with a core question: "Who is reading the Task?"

For the past 15 years, tools like Jira, Trello, and Monday.com have dominated the world of project management. The design assumption of these tools was very clear: the reader of the task ticket is a human (PM, Engineer, QA). To please humans, these tools feature flashy interfaces, full of drag-and-drop interactions and rich visual feedback.

But now (2024-2026), we are facing a historic turning point: the reader of the task ticket has changed.

The new readers are no longer humans sitting in front of screens, but AI Agents (Copilot, Cursor, ChatGPT, Devin). These new readers have completely different characteristics:

Cannot understand GUI: They don't care where the buttons are.
Need structured text: They crave deterministic formats like JSON, YAML, and Markdown.
Extremely dependent on Context: This is the most critical point.

This shift explains why text-based management is making a strong comeback. This isn't for nostalgia, but for Interoperability. Text is the only universal interface in computer science. It eliminates the friction of the human-machine interface, allowing Agents to directly read requirements and execute them, without humans acting as a "human router" ferrying information between Jira and the IDE.

Act II: Context Gravity

Since the reader has become an AI Agent, we must solve a fatal problem: the Context Gap.

In traditional workflows, task definitions live in the cloud (Jira), while the execution environment is local (IDE/Git). Jira doesn't know what your code looks like, and the IDE doesn't know what your task is. This gap is unbridgeable for AI. Without Context, even the smartest model is blind.

To let the Agent understand the task, we must perform an action: Pull the Task Down.

This is the concept of Context Gravity. Following the principle of Data Gravity, the task (TASK.yaml) should live right next to the code (src/) it describes.

When the task and code live together at "zero distance" in the Git repository:

The Agent (like Copilot/Cursor) automatically scans the task definition.
You don't need to explain: "Hey, please look at Jira #1234".
The Agent directly sees the Objective and the relevant File Context.

This maximizes the efficiency of RAG (Retrieval-Augmented Generation). We no longer throw the entire Wiki at the AI, but precisely provide the context it needs. Tightly coupling Intent with Implementation is the key to filling the vacuum in the execution layer.

Act III: Prompt as Code & Task as Code

When we pull the Task down for the Agent and describe it with structured text, we have actually realized two powerful concepts: Prompt as Code and Task as Code.

This is like the Terraform Moment for the AI era.

Recall how Infrastructure as Code (IaC) changed operations: we no longer manually click through the AWS Console, but write HCL code to define architecture. This brought automation, reproducibility, and version control capabilities.

Now, we are treating AI tasks with the same logic:

Chat Era: We manually input prompts in the ChatGPT web interface, with no version control, no reproducibility, and inconsistent quality.
POG Era: We use YAML to define AI behavior, just like using HCL to define infrastructure.

POG (Prompt Orchestration Governance) is the concrete implementation of this concept:

Declarative: You tell POG what you want (Objective), not how to do it.
Modular: You can reference prompt fragments just like referencing modules.
Auditable: All changes are in Git; git blame can tell you who introduced the prompt that caused hallucinations.

This is not just swapping one tool for another; it is a shift in mindset. We are no longer people who "operate" chatbots; we are engineers who "define" tasks and context.

By pulling the Task down to the code level and standardizing it as Code, we finally prepare for the AI Agent to become a member of the team. This is not retro; this is the necessary path to Scale.

Practical Guide: https://dev.to/enjtorian/pog-task-03-deep-dive-into-pog-task-the-missing-layer-and-the-pog-task-moment-2oe1

Quick Start: https://enjtorian.github.io/pog-task/quickstart/

[POG-Task-03] Deep Dive into POG Task: The Missing Layer and the POG Task Moment

Ted Enjtorian — Tue, 10 Feb 2026 14:56:45 +0000

Intuition: Why Just "Chatting" with AI is Not Enough

You might have had this feeling. When building or using AI Agents, there's a strange, nameless sense of unease.

It's not because the AI isn't smart enough; GPT-4 and Claude 3.5 are already exceptional.
It's not because they can't code; they can generate complete modules in seconds.

This feeling goes deeper. It's a structural insecurity.

When you ask an Agent in a chat window to "refactor this module" or "deploy this fix," you are essentially performing mission-critical operations through an informal conversation.

The "Chat" Trap

If we look at the world through three groups of people, we can understand why this problem exists:

Task Manager Builders (Jira, Asana): They assume work is done by humans. "Tasks" are merely reminders for humans who already possess context and memory.
Agent Framework Builders (LangChain, AutoGPT): They focus on "can it run?". They care about reasoning loops and tool calls. Governance is an afterthought.
Governance & Audit Teams: They care about "who did what?" and "can we roll back?". But until recently, AI hadn't started doing real work, so they hadn't focused on the AI execution layer yet.

The Missing Layer

The problem is that we are missing a layer.

Chat logs are not work history. They are messy, lack structure, and are hard to replay.
Prompt logs are not decision records. They show the input, not the "contract" of work.

When an Agent modifies your codebase, deletes files, or changes infrastructure configurations, it's no longer just "chatting." It's Executing.

But where is the Execution Record?

Currently, it disappears the moment the chat window closes. If something goes wrong three months later, you can't "git blame" a conversation. You can't roll back a sequence of prompts.

Awakening

This is why POG Task exists. It's not just another to-do list. It's an acknowledgment of the fact that AI needs a native unit of work.

It needs to be more structured than chat messages.
It needs to be more rigorous than human to-do items.
It needs to be auditable, replayable, and persistent.

Next, we'll explore what this missing layer looks like by comparing it to one of the most successful "missing layers" in history: Git.

The Git Moment of AI Execution

History doesn't repeat itself, but it rhymes. In software engineering, we see a pattern: when a complexity crisis arises, a new "layer" emerges to solve it.

The Git Analogy

Before Git, we had version control systems (CVS, SVN). They worked, but assumed a centralized world with limited collaborators.
When Linux kernel development exploded, the old assumptions collapsed.
Git didn't just "make version control better." It redefined the fundamental unit of collaboration: the Commit.

Commits are immutable.
Commits have parents.
Commits are snapshots of the entire state.

Suddenly, "collaboration" wasn't a vague activity anymore; it became a graph composed of concrete, replayable units.

The Docker Analogy

Before Docker, we had virtual machines (VMs) and chroot.
Docker didn't invent isolation. It redefined the fundamental unit of deployment: the Container.

"It works on my machine" became obsolete because the environment itself was packaged.

The POG Task Moment

We are now at a similar moment for AI Agents.

We have intelligence (LLMs).
We have tools (Function Calling).
We have frameworks (LangChain).

But we lack the most fundamental unit of AI work.

POG Task proposes that the Task is that unit.
Just as Git turned "code changes" into a tangible object (commit), POG Task turns "AI behavior" into a tangible object (task file).

Tasks have a stable ID (UUID).
Tasks have a definition (input).
Tasks have a result (output/history).

It transforms vague "intent" into concrete "artifacts."

Manifesto: Why "Now" is the Moment for POG Task

For a long time, the concept of an "AI Task Layer" was redundant.
Before the emergence of LLMs, automation was deterministic. You wrote a script, and it executed. There was no "intent" to manage, only instructions.

But now, the world has changed.

Three Tipping Points

POG Task exists because we have simultaneously crossed three key tipping points:

Capability: AI models are finally stable enough to take on a "job." They can follow multi-step plans without hallucinating into a state of total loss of control.
Complexity: Agent systems have become too complex to run within a chat window. We need state management, replayability, and debugging tools.
Governance: As AI touches production code and infrastructure, "ChatOps" is no longer acceptable. We need an audit trail.

Neither Too Early Nor Too Late

If we had built this 2 years ago, it would have been too early. AI wasn't ready.
If we wait another 2 years, it will be too late. The ecosystem will have already fragmented into a thousand proprietary, incompatible task silos.

We are building POG Task now to define the standard unit of AI work before it's locked away in walled gardens.

Vision

We see a future where:

Human intent is captured clearly.
AI execution is constrained and safe.
Work history is preserved and learnable.

This is not just about productivity. It's about structure.
It's about giving AI the dignity of a clear role and giving humans the security of a clear process.

This is POG Task. The missing layer has finally been filled.

Check out the Implementation Guide: https://dev.to/enjtorian/pog-task-02-from-governance-to-execution-pog-task-design-and-mvp-4lh8

Quick Start: https://enjtorian.github.io/pog-task/quickstart/

[POG-Task-02] From Governance to Execution: POG Task Design and MVP

Ted Enjtorian — Mon, 09 Feb 2026 15:31:47 +0000

From Governance to Execution: POG Task Design and MVP

If governance cannot reach execution, it is merely theory.

Why POG Task Must Be in an "Executable Format"

In the previous article, we established a premise: Prompt Orchestration Governance (POG) cannot hold if it cannot constrain actual execution.

But governance cannot stop at principles or abstract models. It must be able to answer practical questions:

Which task is the AI currently executing?
Can the state and context of this task be understood by humans?

POG Task v1.1.0 exists precisely to answer these questions.

POG Task v1.1.0 is not a complete task system. It deliberately only satisfies three conditions:

AI can directly read and write it
Humans can directly review it
State can be presented by tools but is not controlled by them

This leads to the entire design logic of v1.1.0.

Physical Structure: File as Truth

Before discussing tools, we must first look at where the data lives. POG Task v0 implemented a strict file structure to ensure portability and reviewability.

Directory Structure

The system exists entirely within your codebase, typically under the pog-task root directory:

pog-task/
├─ README.md                                # Root document
├─ task.schema.json                         # YAML format validation definition
├─ pog-task-agent-instructions.md           # AI Agent "Protocol"
├─ pog-task-design.md                       # System Design
└─ list/                                    # Task list (layered by project/module)
    └── {project}/
        └── {module}/
            ├── {task-title}.yaml           # Structured State Stream (State)
            └── record/{uuid}/record.md     # Execution & Reasoning Log (History)

list/{project}/{module}/*.yaml: This is the structured intent of "what needs to be done."
record/{uuid}/record.md: This is the reasoning and execution log of "what happened."

Why POG Task Uses YAML as the Task Carrier

In v1.1.0, we chose YAML for its readability and precision.

It satisfies the following:

Structured Intent: Supports nested structures and complex checklists.
Human and AI Friendly: YAML is extremely easy to read and edit, reducing parsing hallucinations.
Strict Validation: Ensures every task complies with specifications through JSON Schema.
Git Native: Fits perfectly with Git, diff, and review workflows.

Minimal Task Structure

A POG Task only cares about "governable facts," for example:

type: task
id: "h7a8b9c0-d1e2..."
title: "Improve task governance clarity"
status: "in_progress"
created_at: "2026-02-01T10:32:00Z"
checklist: 
  - task: "Update documentation"
    done: false

This is not a simple workflow, but Structured Intent.

Why Task and Record Must Be Separated

POG Task clearly distinguishes between two types of data:

Task List (YAML): What intents currently exist?
Record (Markdown): How was this task "executed"?

Therefore, every Task corresponds to an independent execution record file (e.g., record/{uuid}/record.md).

Execution steps
Rationale for decisions
Mid-course corrections
Completion condition judgment

This ensures that governance no longer relies on "chat memory" but on re-readable factual records.

POG Task v1.1.0 does not have a dedicated Web UI. The first human interface chosen was VS Code for very pragmatic reasons:

Developers and Agents collaborate here frequently.
Native support for file system and directory semantics.
Plugins can "observe and assist" without "taking over the logic."

Plugin Overview

The POG Task Manager extension is designed as a passive observer that visualizes your task state without owning the data.

Get POG Task Manager Plugin

1. Explorer View

The plugin doesn't force you to read raw YAML; instead, it provides a structured Tree View in the sidebar:

Grouping: Tasks are automatically grouped by project and module.
Status Indicators: Icons clearly show if a task is todo, in_progress, or done.
Context: The intent is displayed as the primary label.

2. Task ↔ Record Navigation

This is the core "governance action."

Clicking a task: Immediately splits the editor.
- Left side: YAML file.
- Right side: Corresponding record.md file.
If the record doesn't exist, the plugin prompts to create it from a standard template, ensuring every execution has a complete reasoning context.

3. Execution Alignment

Copy Prompt: A one-click action to generate a "Handoff Prompt" for your AI agent. This prompt includes the task context and instructions to update the record, bridging the gap between the task definition and the AI's context window.

What the Plugin "Does Not" Do

To maintain a "governance-first" philosophy, the plugin has strict boundaries:

No Drag-and-Drop Status Changes: You cannot drag a task to "done." You must update the underlying file or record.
No Hidden Database: All data is just text files. If you remove the plugin, your tasks remain 100% readable.

The Role of LLM Agents in POG

In the current architecture, the LLM Agent is responsible for:

Reading task intent
Claiming and executing specified tasks
Writing reasoning processes and artifacts into the record
Updating task status and checklists

The Agent does not have the final say on the task state. It is only responsible for leaving enough clues for humans to understand.

Agent Protocol: `pog-task-agent-instructions.md`

To ensure reliable Agent behavior, POG has established a set of strict "Protocols" documented in pog-task-agent-instructions.md. This is not just a document, but an Operation Manual that every Agent must read before acting.

Key highlights of the protocol include:

Layered Path Rules:
- pog-task/list/{project}/{module}/{task-title}.yaml
Status Transition Protocol:
- Claiming: Agents must update the status to in_progress and fill in claimed_by.
- History: Every key action must be appended to the history.
"Intent-First" and "Record Perpetuity":
- Immediately initialize record.md after creating a task.
- Original Intent: The user's original request must be recorded in record.md to prevent execution drift.

This protocol transforms the AI execution "black box" into a predictable, observable process.

Conclusion: v1.1.0 as a Governance Defensive Line

POG Task v1.1.0 does not try to make AI faster. It exists to ensure:

Before AI starts "acting autonomously," we still have a full line of sight for governance.

YAML and the VS Code Plugin are not aesthetic choices; they are the embodiment of a governance stance.

10. Roadmap and Future Work

Phase	Features
v1.1	Core YAML structure, `record.md`, Agent flow, VS Code Plugin optimization
v1.2	Nested tasks, automatic Checklist analysis, enhanced history tracking
v2	Web UI + Dashboard, Jira/Git integration, Multi-agent orchestration
v3	Automated evaluation & reporting, KPI metrics, AI governance rules

Complete content at: https://enjtorian.github.io/pog-task/

[POG-Task-01] When AI Starts Acting, Prompt Governance Is Not Enough

Ted Enjtorian — Sun, 08 Feb 2026 16:40:21 +0000

When AI Starts Acting, Prompt Governance Is Not Enough

The moment AI executes, governance must move beyond conversation.

AI Is No Longer Just a Tool for "Answering Questions"

Initially, we used Large Language Models (LLMs) to explain code, generate documentation, or assist in brainstorming. But today's AI agents have crossed a critical threshold. They are now modifying code, refactoring modules, changing configurations, and even triggering deployment pipelines.

They are no longer just "Advisors"; they are Actors.

The Real Problem Isn't Errors, It's "Inexplicability"

What truly causes anxiety for teams is not AI errors, but the inability to answer simple questions when actions occur:

Why did it do this?
What assumption was this action based on?
If something goes wrong, can we replay the decision process?

Chat logs are not governance.
Prompt design is not a responsibility boundary.

Why Prompt Orchestration Governance (POG) Is Necessary

POG is not another form of prompt engineering. It addresses a fundamental gap in our current systems:

When AI performs an action that affects the system, can humans still understand, review, and replay this decision?

If the answer is no, then this is not automation; it is a risk amplifier.

The Multi-Agent Blind Spot

The problem is amplified in multi-agent systems. When you have a Planner Agent, an Executor Agent, and a Reviewer Agent, the "prompt" becomes an internal message flow hidden from view.

Governance often remains stuck at the single dialogue level, creating a structural misalignment where actions happen, but responsibility dissolves.

Why Governance Will Inevitably Fail at the "Prompt" Layer

We quickly realize that governing prompts only manages "thoughts," not "actions."

When AI starts doing actual work, a prompt tells it "what to do," but it completely fails to address:

Task boundaries
State transitions
Dependencies
Definition of Done

Traditionally, these responsibilities are borne by a "Task System." However, existing tools like Jira or Linear don't work here.

Why Traditional Task Systems Fail AI

Current task systems operate on specific assumptions: humans read the UI, humans update the status, and humans remember the context.

AI does not.

For AI, the UI is invisible, status must be machine-parsable, and history must be structured.

Conclusion: The Task Itself Must Be the Governance Unit

POG leads us to a single, critical conclusion:

The Task itself must become the unit of governance.

Not the chat. Not the log. Not the tool state.

To govern AI actors, we need executable, reviewable task descriptions that serve as a binding contract between human intent and machine execution. POG does not exist to limit AI, but to bring AI's actions back within system boundaries that humans can understand.

Most complete content: https://enjtorian.github.io/pog-task/

[POG-06] Prompt Library & SDLC Integration Strategy: Making High-Quality Prompts Built-in Accelerators for Development Process

Ted Enjtorian — Thu, 05 Feb 2026 16:31:53 +0000

How Do Skill Prompts in the Prompt Warehouse Create Value on the Battlefield?

In the previous article, we explored how to build a "vault" for high-quality, trusted prompts through Prompt Warehouse Management (PWM). But the problem is, if developers find the process of retrieving these Skill Prompts from the vault too cumbersome, they will likely choose to return to the "artisanal workshop" mode.

This is the core problem SDLC-aligned Prompt Library (SPL) needs to solve. Its goal is not "storage", but "integration" and "empowerment".

The core idea of SPL is: Proactively push "Skill Prompts" to where developers need them most, which is every stage of the Software Development Life Cycle (SDLC). It acts like a portable toolkit, handing you the handiest prompt specification based on your current stage.

Turning Every Stage of SDLC into a Skill Prompt Application Scenario

A typical SDLC includes Requirements, Design, Development, Testing, Deployment, and Maintenance stages. The charm of SPL lies in providing tailored Skill Prompt collections for each stage, allowing AI capabilities to integrate seamlessly.

Let's look at specific integration strategies and cases.

1. Requirements

Pain Points: Lengthy requirement documents, messy user interview notes, unclear requirements.
SPL Role: AI Assistant, helping PMs and analysts quickly refine and clarify requirements.

Skill Prompt Case	Input	Output
`generate-user-stories`	A transcript of a user interview.	Structured User Stories (As a [Role], I want [Goal], so that [Value]).
`identify-ambiguity`	A Product Requirement Document (PRD).	A list of clauses in the document that may be ambiguous, conflicting, or missing.
`create-acceptance-criteria`	A User Story.	A list of Acceptance Criteria for that User Story.

Value: Significantly shortens the requirements analysis cycle, improving requirement accuracy and consistency.

2. Design

Pain Points: Time-consuming translation from requirements to design, inconsistent document formats, lack of records for architectural decisions.
SPL Role: AI Design Partner, accelerating the design process and standardizing outputs.

Skill Prompt Case	Input	Output
`draft-api-spec`	A functional requirement description.	An API specification draft in OpenAPI format (paths, methods, parameters, responses).
`generate-diagram-script`	A natural language description of a system flow.	PlantsUML or Mermaid scripts that can be rendered into charts.
`write-adr`	Discussion records about a technical choice.	A structured Architecture Decision Record (ADR).

Value: Allows engineers to focus more on core design thinking rather than tedious documentation work.

3. Development

Pain Points: Repetitive boilerplate code, insufficient unit test coverage, non-standard code comments.
SPL Role: AI Pair Programmer, improving coding efficiency and quality.

Skill Prompt Case	Input	Output
`generate-boilerplate-code`	A function definition and comments.	The implementation framework for that function.
`create-unit-tests`	A piece of code or a function.	Unit test cases for that code (supporting Jest, PyTest, etc.).
`refactor-and-comment`	Working but messy code.	An optimized version with refactoring, clear comments, and Docstrings.

Value: Liberates developers from repetitive labor and builds in quality assurance steps.

4. Testing

Pain Points: Difficult test data construction, lack of diversity in test cases, hard to simulate real-world scenarios.
SPL Role: AI Test Data Generator, expanding the depth and breadth of testing.

Skill Prompt Case	Input	Output
`generate-mock-data`	Required data fields and format (e.g., `name`, `email`, `address`).	A large amount of realistic test data in format (JSON or CSV).
`create-edge-case-inputs`	A function or API specification.	A list of input values that may trigger edge conditions (e.g., null values, ultra-long strings, special characters).
`write-e2e-test-script`	Description of a user operation flow.	End-to-end (E2E) test script draft (supporting Cypress, Playwright, etc.).

Value: Significantly reduces time cost of writing tests, improving system robustness.

5. Deployment & Maintenance

Pain Points: Time-consuming release note writing, slow online issue troubleshooting, laborious user feedback analysis.
SPL Role: AI Site Reliability Engineer (SRE), improving operations efficiency.

Skill Prompt Case	Input	Output
`draft-release-notes`	A Git commit log.	A clear, user-friendly version release note.
`analyze-error-log`	An application error log (stack trace).	Analysis of error causes, explanations, and suggested solutions.
`summarize-user-feedback`	A pile of user reviews from App Store or customer service system.	Categorizes and summarizes feedback, extracting main complaints and suggestions.

Value: Accelerates issue response speed, allowing teams to learn faster from market feedback.

How to Practice SPL in Teams?

Start from Pain Points: Don't try to build prompts for all stages at once. Choose 1-2 areas where the team currently hurts the most.
Integrate with Tools: Integrate the SPL into tools developers use daily, such as VS Code extensions, CI/CD pipeline scripts, or internal team CLI tools. Make the cost of retrieving Skill Prompts near zero.
Establish a Feedback Loop: Skill Prompts in SPL are not static. Establish a mechanism so developers can easily suggest improvements to prompts or contribute new useful ones. This feedback becomes input for the Prompt Warehouse Management (PWM) process (Discovery phase), forming a positive cycle.

Conclusion

The core value of the SDLC-aligned Prompt Library (SPL) lies in its role as a "Translator" and "Enabler".

It "translates" those validated, high-quality Skill Prompts from the Prompt Warehouse into "tools" that developers can immediately understand and use in specific scenarios, and "empowers" every corner of software development with AI capabilities.

Through SPL, POG is no longer just a backend governance framework, but a close partner fighting alongside developers to improve daily work efficiency.

Next, we will elevate our perspective to explore a more macro design:
Orchestration Level and Architecture Design. When we possess massive Skill Prompt specifications, how do we effectively organize and orchestrate them into complex AI applications?

Most complete content: https://enjtorian.github.io/prompt-orchestration-governance-whitepaper/

[POG-05] Prompt Warehouse Management: Four Steps from Chaos to Order

Ted Enjtorian — Fri, 30 Jan 2026 16:32:39 +0000

A Good Prompt Warehouse Is Not About "Storage", But "Process"

We already know that Prompt Warehouse Management (PWM) is one of the two pillars of the POG framework, responsible for processing prompts from "raw materials" into "First-Class Specifications".

But how exactly does this "processing plant" operate internally?

Successful PWM relies on a clear, repeatable process ensuring every incoming prompt meets engineering standards. This process can be broken down into four core stages: Discovery, Normalization, Validation, and Versioning & Repository.

Let's break down this journey from "Interaction Prompt" to "Skill Prompt".

Step 1: Discovery - Panning for Gold in Sand

Goal: Identify and collect "Interaction Prompts" scattered across the organization that have potential reuse value.

In the early stages of implementation, this is a "treasure hunting" process. Your team needs to act like archaeologists, digging up prompts that have been created but not yet managed.

Excavation sites may include:

Collaboration Tools: Check design documents or brainstorming records in Notion, Confluence, Google Docs.
Communication Software: Review Slack or Teams channel history to find shared prompts that once impressed people.
Personal Notes: Encourage team members to contribute their privately hoarded "magic prompts".
Chat Applications: Collect effective prompts discovered in chat interfaces like ChatGPT and Claude.
LLM Agent Development Logs: Intermediate conversations generated during development with GitHub Copilot or VS Code.

The catch at this stage is "better to have too many than too few". Collect all seemingly useful Interaction Prompts to form a "candidate pool". These Discovered Prompts might be messy, but they are the foundation.

Step 2: Normalization - Tagging Every Piece of Gold

Goal: Transform unstructured "Discovered Prompts" into structured "Normalized Prompts" with rich metadata.

This is the key step in processing "raw materials" into "semi-finished products". Without normalization, every prompt is a black box that cannot be effectively managed or queried.

The Core of Normalization is Adding "Metadata":

A standardized prompt specification should include at least the following metadata:

Metadata Field	Description	Example
`id`	Unique identifier	`prompt-user-summary-v1`
`name`	Human-readable name	User Behavior Summary
`description`	Describes the use and purpose of this prompt	Summarizes user's raw activity logs into a short description of key points.
`version`	Version number, following Semantic Versioning (SemVer)	`1.2.0`
`author`	Creator or maintainer	`team-alpha`
`tags`	Tags for classification and search	`summary`, `user-profile`, `risk-control`
`model_parameters`	Applicable models and parameters	`{ "model": "gpt-4", "temperature": 0.5 }`
`schema`	Definition of input variables (inputs) and output format (output)	`inputs: { "user_logs": "string" }, output: "json"`

Through normalization, we turn a prompt from a sentence into a "Specification Manual" that machines can read and systems can understand.

Step 3: Validation - Testing the Purity of Gold

Goal: Ensure the quality, stability, security, and compliance of the prompt through a series of automated or semi-automated tests.

This is the link in PWM that best embodies "engineering" thinking. An unvalidated prompt is like untested code, liable to cause online issues at any moment.

Levels of Validation:

Functional Validation
- What? Check if the prompt generates expected output for given inputs.
- How? Design a "Golden Test Set" containing typical inputs and expected outputs for unit testing.
Robustness Validation
- What? Test the prompt's reaction to edge cases, abnormal inputs, or malicious inputs.
- How? Introduce Fuzz Testing, Adversarial Testing (e.g., Prompt Injection), and various unconventional input cases.
Performance Validation
- What? Evaluate performance metrics like response speed and Token consumption.
- How? Run the prompt in a standardized environment and record/monitor its resource usage.
Compliance & Ethical Validation
- What? Check if the prompt's output complies with laws, regulations, and ethical requirements.
- How? Design specific test cases to check for harmful, discriminatory, or biased content generation.

Only prompts that pass these validation gates become "Validated Prompts".

Step 4: Versioning & Repository - Putting Gold in the Vault

Goal: Store "Validated Prompts" in a centralized Repository as "Skill Prompts" and apply strict version control.

This is the final stop of the process and the centralized embodiment of prompt assetization results.

Core Elements:

Central Repository: The Single Source of Truth, enabling Discovery and Reuse.
Semantic Versioning: Manage prompt evolution like npm packages using Major.Minor.Patch (e.g., 2.1.5).
- Patch: Minor adjustments not affecting functionality (e.g., fixing typos).
- Minor: New features but backward compatible.
- Major: Breaking changes requiring application updates.
Immutability: Any published Skill Prompt version should not be modified. Any adjustment must publish a new version.
Dependency Management: Applications should explicitly depend on a specific Skill Prompt version.

Conclusion

The four steps of Prompt Warehouse Management—Discovery, Normalization, Validation, Versioning—together form a clear path from messy "Interaction Prompts" to production-ready "Skill Prompts".

It transforms prompt management from an "art" into a predictable, measurable "engineering discipline".

In the next article, we will explore the other pillar of POG:
How does the SDLC-aligned Prompt Library (SPL) integrate with the development process? See how these Skill Prompts maximize their value on the development frontline.

Most complete content: https://enjtorian.github.io/prompt-orchestration-governance-whitepaper/

[POG-04] POG Dual Architecture Deep Dive: Two Pillars Supporting Prompt Assetization and Scalable Application

Ted Enjtorian — Tue, 27 Jan 2026 15:54:06 +0000

From Chaos to Order, You Need More Than Just a Warehouse

We have established a consensus: Prompts should be managed as "First-class Software Assets". But a natural question follows: "How exactly do we do that?"

Merely building a "Prompt Warehouse" to store prompts is not enough. If this Prompt Warehouse is disconnected from the development process, it will quickly become a neglected "filing cabinet" rather than an "arsenal" that boosts efficiency.

This is the core insight behind the "Dual Architecture" proposed by Prompt Orchestration Governance (POG). The stable operation of POG relies on two closely coordinated, complementary pillars:

Prompt Warehouse Management (PWM): Responsible for Asset Lifecycle Management.
SDLC-aligned Prompt Library (SPL): Responsible for Asset Application and Integration in the Development Process.

Together, they form a complete closed loop from "assetization" to "scalable application".

Pillar 1: Prompt Warehouse Management (PWM)

The core responsibility of PWM is: Ensure that every prompt entering the "Trusted Asset Library" possesses high quality, high stability, and high security.

Think of it as a "Prompt Quality Control and Supply Center". It defines a standardized process to transform those scattered, uneven-quality "raw prompts" into structured, trustworthy "engineering assets".

The Asset Lifecycle we mentioned in the previous article—Discovery, Normalization, Validation, Versioning & Repository—defines the core activities of PWM.

Key Outputs of PWM

A Centralized Prompt Warehouse: The Single Source of Truth for all trusted prompts.
Structured Prompt Objects: Each prompt contains rich metadata (e.g., version, author, purpose, performance metrics, security level).
Automated Quality Gates: Automated tests integrated via CI/CD pipelines to ensure prompt changes do not degrade system quality.
Clear Governance Rules: Defines who can submit, review, and publish prompts, and what the change process is.

Without PWM, prompt management would be a mess of loose sand. It provides a stable and reliable "asset supply" for the entire POG system.

Pillar 2: SDLC-aligned Prompt Library (SPL)

If PWM is "Logistics and QC", then SPL is the "Frontline Operations Manual".

The core responsibility of SPL is: Effectively integrate high-quality prompt assets into every stage of the Software Development Life Cycle (SDLC) to truly empower development teams.

It no longer mixes all prompts together but organizes them according to "Development Phase" and "Task Purpose", forming targeted "Prompt Toolkits".

How Does SPL Align with SDLC?

SDLC Phase	SPL Prompt Examples	Value
Requirements	- Generate user stories from interview notes - Identify ambiguity in requirement documents	Accelerate requirement clarification, reduce communication costs
Design	- Draft API specs based on requirements - Generate PlantUML/Mermaid scripts for architecture diagrams	Improve design efficiency, standardize design docs
Development	- Convert natural language comments to boilerplate code - Generate unit test cases from code	Accelerate development, improve code quality
Testing	- Generate diverse test data (e.g., names, addresses) - Simulate various edge cases and abnormal inputs	Expand test coverage, improve test quality
Deployment	- Draft release notes based on changelogs - Generate comments and explanations for deployment scripts	Automate documentation, reduce deployment risks
Maintenance	- Analyze error logs and suggest possible causes - Summarize user feedback and categorize it	Shorten troubleshooting time, respond quickly to market

Through SPL, developers can quickly find "What prompt can I use to speed up my work right now?" at every stage. This transforms prompts from "a burden requiring extra management" into "a built-in accelerator for the development process".

Synergy of the Dual Architecture

PWM and SPL are like two sides of a gear; neither can exist without the other.

PWM provides "ammunition" for SPL: Without high-quality, standardized prompts provided by PWM, SPL would become a collection of unreliable scripts that developers dare not use lightly.
SPL finds an "outlet" for PWM's assets: Without SPL effectively delivering prompts to developers, PWM's Prompt Warehouse would become a stagnant pool, unable to generate actual value.

Their coordinated operation creates a positive cycle:

Developers use prompts via SPL in the SDLC and discover new, more effective prompts in practice.
These new prompts are submitted to the PWM process.
After Normalization and Validation, they become new high-quality assets entering the Prompt Warehouse.
These new assets are organized into SPL toolkits for more developers to use.
This cycle repeats, making the team's prompt asset library richer and development efficiency higher.

Conclusion

POG's dual architecture provides us with a clear blueprint, guiding us on how to systematically solve prompt management and application challenges from both strategic and tactical levels.

Prompt Warehouse Management is asset governance at the strategic level, concerning quality, stability, and security.
SDLC-aligned Prompt Library is process integration at the tactical level, concerning efficiency, empowerment, and application.

Only when both pillars are firmly established can AI system development truly break away from the chaos of the "artisanal workshop" and move towards a predictable, scalable, and governable "industrialized" era.

In the next two articles, we will dive deep into the internals of these two pillars, exploring:

What is the specific process of Prompt Warehouse Management?
How is SPL implemented and integrated into the SDLC?

Most complete content: https://enjtorian.github.io/prompt-orchestration-governance-whitepaper/

[POG-03] Prompts as First-class Software Assets: Stop Treating Your Gold Like Stones

Ted Enjtorian — Sat, 24 Jan 2026 12:30:53 +0000

The Path We Have Traveled in the History of Software Engineering

Throughout the history of software engineering, we have continuously learned how to turn "important things" into assets.

Code: Evolved from non-reusable scripts to source code version-controlled via Git.
Infrastructure: Evolved from manually configured servers to "Infrastructure as Code" (IaC) managed via Terraform/Ansible.
Test Cases: Evolved from ad-hoc test scripts to automated, repeatable test suites.
Reusability: Evolved from simple Utils/Libraries to "Quick Start Frameworks" like Spring Boot, allowing developers to stand on the shoulders of giants.

Every "assetization" revolution has brought huge leaps in scale, stability, and collaboration efficiency.

Now, it's Prompt's turn.

What is a "First-class Software Asset"?

When we say something is a "First-class Software Asset", it usually means it possesses the following qualities:

Has clear ownership and accountability
Included in version control systems
Has specifications and standards that can be described
Changes have traceable audit records
Is part of the automated process (CI/CD)
Discoverable and reusable

In short, it is treated seriously.

Conversely, if your prompts are still scattered across personal notes, Chatbot conversation logs, or exist as unstructured text in documents, then they remain 'second-class citizens,' which is exactly the source of the risk.

The Core Meaning of Assetizing Prompts

The core meaning of elevating prompts from "temporary instructions" to "software assets" lies in a shift of perspective.

Dimension	Old Perspective: Prompt as Instruction	New Perspective: Prompt as Asset
Value	One-time, disposable	Cumulative, evolutionary knowledge capital
Focus	Cares only about "output result"	Cares about the entire "lifecycle"
Owner	Unclear, usually the developer	Clear team or individual
Quality	Relies on personal experience and immediate testing	Guaranteed by standardized processes and validation
Risk	Implicit, hard to assess	Explicit, manageable, and traceable

This shift makes us stop asking just "Is this prompt useful?", and start asking:

Is it robust enough to handle various edge cases?
Is it clear enough to be understood and maintained by others?
Is it stable enough to perform consistently after model upgrades?
Is it compliant, meeting corporate brand and legal requirements?

The Lifecycle of a Prompt Asset

Like any software asset, a prompt should go through a complete lifecycle from birth to retirement. This is the core process that the Prompt Orchestration Governance (POG) framework focuses on.

Discovery
- Goal: Identify valuable, reusable prompts from existing code, documentation, and chat logs.
- Output: A list of unprocessed "candidate prompts".
Normalization
- Goal: Transform candidate prompts into a structured format following unified standards. This includes adding metadata such as: author, version, purpose, expected input/output, used models, etc.
- Output: A prompt object with uniform format and complete metadata.
Validation
- Goal: Ensure the quality, stability, and safety of the prompt through a series of automated or semi-automated tests. Tests may include: functional testing, regression testing, adversarial testing (e.g., prompt injection), bias, and compliance checks.
- Output: A prompt version that has passed quality gates and is marked as "trusted".
Versioning & Repository
- Goal: Store valid prompts in a centralized "Prompt Warehouse" and version control them like Git.
- Output: A prompt asset that is queryable, referenceable, and has clear version records. In POG terminology, such a fully processed prompt ready for production is also called a "Skill Prompt".

This process ensures that every prompt included in the "Asset Library" has the most basic engineering quality assurance and becomes part of the organizational knowledge.

The Huge Value of Assetization

Once a prompt is assetized, it is no longer a cost center, but a value center.

Knowledge Sedimentation and Compounding: Every prompt included in the warehouse represents the crystallization of a successful experience. Team wisdom accumulates rather than draining away as projects end.
Multiplication of Development Efficiency: Developers no longer need to start from scratch. They can search, discover, and directly reuse or fine-tune existing high-quality prompts in the Prompt Warehouse, significantly shortening development cycles.
Guarantee of System Stability: Through version control and automated validation, prompt changes become safe and controllable. Any modification causing issues can be quickly traced and rolled back.
Cornerstone of Cross-team Collaboration: When Product, Engineering, Legal, and Operations teams collaborate on the same "Trusted Prompt Warehouse" foundation, communication costs are significantly reduced, and system behavior consistency is guaranteed.

Conclusion

Treating prompts as first-class software assets is not adding unnecessary processes, but making a fundamental risk management and efficiency investment.

It requires us to treat these key instructions that define AI behavior with the same seriousness as core code. This is an upgrade in mindset and a necessary path for AI systems to move from "experiments" to "industrial-grade products."

In the next post, we will delve into the core engine of POG:
Deep Dive into POG Dual Architecture. See how Prompt Warehouse and SDLC Integration work together to support the entire governance system.

Most complete content: https://enjtorian.github.io/prompt-orchestration-governance-whitepaper/

Forem: Ted Enjtorian

[POG-Task-06] What is the "AI Native Task Governance Model"?

Why do we need an "AI Native" Governance Model?

Core Foundations: Treat Task as Code and Treat Prompt as Code

1. Treat Task as Code: Transforming Tasks into "Units of Intention"

2. Treat Prompt as Code: Transforming Prompts into Maintained Assets

3. Establishing Auditable and Traceable "Reasoning Traces"

Seamless Collaboration for Cumulative Experience

[POG-Task-05] Treat Tasks and Prompts as Code

What Was Valuable in the Past? What's Most Expensive Now?

Let's Look at Our Current "Ungoverned" Workflow

Enter the Improved Workflow: Introducing POG-Task

Preserve Your Personal Value, Starting Now!

[TOK-02] What is TOCA? The Core Loop of Task-Oriented Cognitive Architecture

If You Only Have Definitions, Tasks Are Just Documents

Why Traditional Models Fall Short

TOCA: The Five-Step Core Loop

Step 1: Capture — Capturing Intent

Step 2: Dispatch — Dispatching Tasks

Step 3: Execute — Executing Tasks

Step 4: Validate — Validating Results

Step 5: Evolve — Evolving Strategy

Why "Cognitive Architecture" Instead of "Workflow Engine"?

A Complete Example

The True Significance of TOCA

Conclusion: Tasks Are Not Just Executed — They Evolve

[TOK-01] What is Task Ontology Kernel (TOK)?

Starting from an Observation

Tasks Have Always Existed, But Were Never "Formalized"

LLMs Are the First "General-Purpose Task Executor" in Human History

This Is How TOK Was Born

What Does a Task Look Like?

Intent Layer

Context Layer

Strategy Layer

Evaluation Layer

Why "Ontology"?

What Does This Mean?

Conclusion: Not Reinventing Tasks, But Formalizing Them for the First Time

[POG-Task-04] # From Task Executor to POG Task: A Gravity Experiment on Context

Act I: The Shift in Readership

Act II: Context Gravity

Act III: Prompt as Code & Task as Code

[POG-Task-03] Deep Dive into POG Task: The Missing Layer and the POG Task Moment

Intuition: Why Just "Chatting" with AI is Not Enough

The "Chat" Trap

The Missing Layer

Awakening

The Git Moment of AI Execution

The Git Analogy

The Docker Analogy

The POG Task Moment

Manifesto: Why "Now" is the Moment for POG Task

Three Tipping Points

Neither Too Early Nor Too Late

Vision

[POG-Task-02] From Governance to Execution: POG Task Design and MVP

From Governance to Execution: POG Task Design and MVP

Why POG Task Must Be in an "Executable Format"

Physical Structure: File as Truth

Directory Structure

Why POG Task Uses YAML as the Task Carrier

Minimal Task Structure

Why Task and Record Must Be Separated

Plugin Overview

1. Explorer View

2. Task ↔ Record Navigation

3. Execution Alignment

What the Plugin "Does Not" Do

The Role of LLM Agents in POG

Agent Protocol: pog-task-agent-instructions.md

Conclusion: v1.1.0 as a Governance Defensive Line

10. Roadmap and Future Work

[POG-Task-01] When AI Starts Acting, Prompt Governance Is Not Enough

When AI Starts Acting, Prompt Governance Is Not Enough

AI Is No Longer Just a Tool for "Answering Questions"

The Real Problem Isn't Errors, It's "Inexplicability"

Why Prompt Orchestration Governance (POG) Is Necessary

The Multi-Agent Blind Spot

Why Governance Will Inevitably Fail at the "Prompt" Layer

Agent Protocol: `pog-task-agent-instructions.md`