665 lines
14 KiB
Markdown
665 lines
14 KiB
Markdown
# CCPE System Definition
|
|
|
|
## 1. Purpose
|
|
|
|
CCPE System is a context protocol engineering framework for constructing, auditing, refactoring, registering, and maintaining AI Prompt Cards, Agent Specs, Committee Specs, CCPE Skill Specs, Runtime protocols, Cognitive Model Cards, Model Indexes, and external capability registrations.
|
|
|
|
It is also a supplier layer for the user's concrete work repositories. Project repositories should raise real requirements; CCPE supplies the appropriate AI artifact architecture and governance contracts.
|
|
|
|
It exists to solve a structural problem:
|
|
|
|
> Advanced AI work is no longer only a matter of writing better prompts.
|
|
|
|
Modern AI work often involves:
|
|
|
|
* Expert roles
|
|
* Reusable cognitive methods
|
|
* Tool use
|
|
* Human decision gates
|
|
* Multi-agent collaboration
|
|
* Long-running workflows
|
|
* Knowledge extraction
|
|
* Model maintenance
|
|
* Evaluation and version control
|
|
|
|
CCPE System provides a shared protocol for defining and managing these components.
|
|
|
|
CCPE can design both local development agents for the user's own work and production/business agents intended for deployed intelligent systems. For deployed systems, CCPE owns the specification, authority, evaluation, and governance contract. The target application project owns implementation, framework adapters, server runtime, persistence, monitoring, and deployment.
|
|
|
|
## 2. Core Definition
|
|
|
|
**CCPE is a context protocol engineering framework for building, reviewing, and maintaining AI Prompts, Agents, Skills, and Agentic Workflows.**
|
|
|
|
It systematically defines:
|
|
|
|
```text
|
|
Objective
|
|
Role
|
|
Context
|
|
Capability
|
|
Tool
|
|
Authority
|
|
Workflow
|
|
Constraint
|
|
State
|
|
Output
|
|
Evaluation
|
|
Runtime Environment
|
|
```
|
|
|
|
Its purpose is to transform AI systems from one-off responders into reusable, testable, composable, collaborative, and maintainable task-execution systems.
|
|
|
|
## 3. Historical Transition
|
|
|
|
The earlier CCPE 2.0 framework was primarily a product of the Prompt Engineering era.
|
|
|
|
It was effective for designing:
|
|
|
|
* Expert prompts
|
|
* Custom GPT / Gemini assistants
|
|
* Critique agents
|
|
* Advisory agents
|
|
* Structured reasoning assistants
|
|
* Human-facing cognitive tools
|
|
|
|
However, the agentic landscape has changed.
|
|
|
|
AI systems increasingly need to support:
|
|
|
|
* Tool invocation
|
|
* File operations
|
|
* External APIs
|
|
* Subagents
|
|
* Skills
|
|
* Workflow orchestration
|
|
* State management
|
|
* Human approval gates
|
|
* Runtime recovery
|
|
* Evaluation loops
|
|
* Knowledge asset management
|
|
|
|
Therefore, CCPE must evolve from:
|
|
|
|
```text
|
|
Prompt Engineering Framework
|
|
```
|
|
|
|
to:
|
|
|
|
```text
|
|
Prompt / Agent / Skill / Workflow Context Protocol Engineering Framework
|
|
```
|
|
|
|
## 4. What CCPE System Is Not
|
|
|
|
CCPE System is not merely:
|
|
|
|
```text
|
|
A prompt template
|
|
A persona framework
|
|
A role-playing instruction
|
|
A tool wrapper
|
|
A generic agent framework
|
|
A pure automation framework
|
|
A knowledge-base folder
|
|
A project execution repository
|
|
An automation Skill source repository
|
|
A deployed application runtime
|
|
A LangGraph, CrewAI, or other framework implementation
|
|
A chain-of-thought template
|
|
```
|
|
|
|
It is also not designed to force every AI artifact into a heavy engineering structure.
|
|
|
|
It is not the canonical source for `skills-vault` automation skills, MCP implementations, CLI tools, API services, or project-specific run histories. CCPE may register these capabilities as dependencies when CCPE artifacts rely on them.
|
|
|
|
The system should avoid both extremes:
|
|
|
|
```text
|
|
Under-engineering:
|
|
Treating every AI artifact as just a prompt.
|
|
|
|
Over-engineering:
|
|
Turning every lightweight expert prompt into a complex runtime system.
|
|
```
|
|
|
|
## 5. Primary Design Principle
|
|
|
|
The primary design principle of CCPE is:
|
|
|
|
> Probe scenario, then classify before designing.
|
|
|
|
Before creating or modifying an AI artifact, determine how it is or will be used, then determine what it actually is.
|
|
|
|
Scenario probe should identify:
|
|
|
|
```text
|
|
Target platform
|
|
Single-agent or multi-agent use
|
|
Manual orchestration or automation
|
|
Web-style direct chat or Codex-callable behavior
|
|
Depth-oriented expert thinking or workflow execution
|
|
Current usage for existing agents
|
|
Planned usage for new agents
|
|
```
|
|
|
|
Possible forms:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
CCPE-Committee
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Model Card
|
|
Model Index
|
|
Integration Registration
|
|
Project Runbook
|
|
automation Skill source
|
|
external tool / MCP / CLI / API
|
|
Hybrid Artifact
|
|
Out of Scope
|
|
```
|
|
|
|
This classification determines the necessary structure.
|
|
|
|
Scenario determines which layers are actually needed.
|
|
|
|
A portable expert assistant should not be forced into a Runtime Spec.
|
|
|
|
A multi-agent workflow should not be reduced to a single prompt.
|
|
|
|
A reusable cognitive model should not be trapped inside one agent.
|
|
|
|
A repeated method should not be duplicated across many prompts when it can become a Skill.
|
|
|
|
## 6. The Four Primary CCPE Forms
|
|
|
|
### 6.1 CCPE-Lite
|
|
|
|
CCPE-Lite is a lightweight Prompt Card.
|
|
|
|
It is designed for chat-based AI environments such as:
|
|
|
|
```text
|
|
Custom GPT
|
|
Gemini Gem
|
|
Claude Project Instruction
|
|
Simple assistant prompt
|
|
Single-role expert assistant
|
|
```
|
|
|
|
Use CCPE-Lite when the artifact is primarily:
|
|
|
|
* A single expert persona
|
|
* A critique assistant
|
|
* A thinking partner
|
|
* A reviewer
|
|
* A questioner
|
|
* A writing assistant
|
|
* A human-facing cognitive tool
|
|
|
|
CCPE-Lite should be:
|
|
|
|
```text
|
|
Portable
|
|
Concise
|
|
Stable
|
|
Easy to paste
|
|
Easy to modify
|
|
Low overhead
|
|
```
|
|
|
|
It should not include unnecessary runtime, tool, or state machinery unless the use case requires it.
|
|
|
|
For Web / GPT / Gemini / Claude style expert use, CCPE-Lite is a complete production form, not a shortened Agent Spec.
|
|
|
|
When migrating mature CCPE 2.0 expert prompts, preserve the four-layer working prompt kernel:
|
|
|
|
```text
|
|
Core Layer
|
|
Execution Layer
|
|
Constraint Layer
|
|
Operation Layer
|
|
```
|
|
|
|
Add Skill only when a method must be invoked by Codex or reused across agents. Add Agent Spec or Runtime only when collaboration, handoff, state, routing, tools, or automation require them.
|
|
|
|
### 6.2 CCPE-Agent
|
|
|
|
CCPE-Agent is a durable Agent Spec.
|
|
|
|
It is designed for a reusable working role that may participate in a broader workflow.
|
|
|
|
Use CCPE-Agent when the artifact:
|
|
|
|
* Has a long-term responsibility
|
|
* Needs maintenance over time
|
|
* Participates in a committee or workflow
|
|
* Has explicit input and output contracts
|
|
* Calls Skills
|
|
* Uses tools
|
|
* Requires collaboration rules
|
|
* Requires authority boundaries
|
|
* Requires evaluation criteria
|
|
|
|
CCPE-Agent should define:
|
|
|
|
```text
|
|
Objective
|
|
Role
|
|
Context
|
|
Capability
|
|
Authority
|
|
Workflow
|
|
Constraint
|
|
State
|
|
Output
|
|
Evaluation
|
|
Collaboration
|
|
```
|
|
|
|
A single agent can still require CCPE-Agent if it is a durable work unit.
|
|
|
|
A multi-agent member may only need CCPE-Lite if it is simple and manually operated.
|
|
|
|
The distinction is not “single vs multiple agents.”
|
|
|
|
The distinction is:
|
|
|
|
> Is this artifact a reusable work unit with durable responsibilities?
|
|
|
|
### 6.3 CCPE-Skill
|
|
|
|
CCPE-Skill is a reusable capability module.
|
|
|
|
A Skill may be:
|
|
|
|
```text
|
|
Tool-oriented
|
|
Method-oriented
|
|
Workflow-oriented
|
|
Evaluation-oriented
|
|
Transformation-oriented
|
|
Knowledge-management-oriented
|
|
```
|
|
|
|
A Skill is not merely a tool wrapper.
|
|
|
|
It may contain:
|
|
|
|
* A method
|
|
* A cognitive procedure
|
|
* A checklist
|
|
* A tool-use protocol
|
|
* A transformation procedure
|
|
* An evaluation rubric
|
|
* A report format
|
|
* A failure-handling rule
|
|
|
|
Use CCPE-Skill when the same capability should be callable by multiple agents or workflows.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Cognitive Imaging Skill
|
|
Assumption Stress-Test Skill
|
|
Argument Chain Inspection Skill
|
|
Voice-to-Text Preprocessing Skill
|
|
Knowledge Archival Skill
|
|
Model Extraction Skill
|
|
Review Report Synthesis Skill
|
|
```
|
|
|
|
### 6.4 CCPE-Runtime
|
|
|
|
CCPE-Runtime is a workflow and execution protocol.
|
|
|
|
Runtime is needed when work involves:
|
|
|
|
* Multiple stages
|
|
* Multiple agents
|
|
* Tool execution
|
|
* File operations
|
|
* Human decision gates
|
|
* State tracking
|
|
* Handoff
|
|
* Recovery
|
|
* Long-running process
|
|
* Evaluation and archival
|
|
|
|
Runtime does not mean full automation.
|
|
|
|
There are three runtime types:
|
|
|
|
```text
|
|
Interactive Runtime
|
|
Automation Runtime
|
|
Hybrid Runtime
|
|
```
|
|
|
|
Interactive Runtime is human-led and suited for deep cognition.
|
|
|
|
Automation Runtime is process-led and suited for stable, low-risk, verifiable tasks.
|
|
|
|
Hybrid Runtime combines human-led depth with automated support around the edges.
|
|
|
|
## 7. Cognitive Model Assets
|
|
|
|
CCPE System explicitly separates Agents from Models.
|
|
|
|
An Agent is a working role.
|
|
A Model is a reusable cognitive structure.
|
|
A Skill may execute a Model.
|
|
A Runtime may orchestrate Agents and Skills that use Models.
|
|
|
|
This separation is essential for maintaining the user's intellectual infrastructure.
|
|
|
|
### 7.1 Model Card
|
|
|
|
A Model Card defines one cognitive model.
|
|
|
|
It should include:
|
|
|
|
```text
|
|
Model Name
|
|
Aliases
|
|
Source Material
|
|
Model Type
|
|
Core Problem
|
|
Scope
|
|
Core Assumptions
|
|
Mechanism
|
|
Procedure
|
|
Inputs
|
|
Outputs
|
|
Failure Modes
|
|
Falsification Boundary
|
|
Related Models
|
|
Related Agents
|
|
Related Skills
|
|
Runtime Usage
|
|
Version Status
|
|
```
|
|
|
|
Model Cards are used when a cognitive model should be preserved independently of any one agent.
|
|
|
|
### 7.2 Model Index
|
|
|
|
A Model Index organizes many Model Cards.
|
|
|
|
It tracks:
|
|
|
|
```text
|
|
Model taxonomy
|
|
Hierarchy
|
|
Dependency relationships
|
|
Overlap relationships
|
|
Conflict relationships
|
|
Usage scenarios
|
|
Related agents
|
|
Related skills
|
|
Related runtimes
|
|
Source articles
|
|
Version status
|
|
Extraction history
|
|
```
|
|
|
|
A Model Index becomes necessary when the knowledge system contains many models, especially when they come from long-form writing or implicit conceptual structures.
|
|
|
|
## 8. Hybrid Artifacts
|
|
|
|
Many real AI artifacts are hybrid.
|
|
|
|
For example:
|
|
|
|
```text
|
|
Cognitive Imaging Specialist
|
|
= Agent role
|
|
+ Cognitive Imaging Model
|
|
+ Five-step analysis Skill
|
|
+ Report template
|
|
+ Optional retrieval policy
|
|
+ Possible Runtime node in review committee
|
|
```
|
|
|
|
CCPE System must identify these components rather than forcing the artifact into one category.
|
|
|
|
Hybrid artifacts may be split into multiple files when beneficial:
|
|
|
|
```text
|
|
Model Card
|
|
Skill Spec
|
|
Agent Spec
|
|
Prompt Card
|
|
Runtime Spec
|
|
```
|
|
|
|
However, splitting is not mandatory.
|
|
|
|
Use the lightest structure that preserves:
|
|
|
|
```text
|
|
Clarity
|
|
Reusability
|
|
Maintainability
|
|
Portability
|
|
Model fidelity
|
|
Execution quality
|
|
```
|
|
|
|
## 9. Depth vs Automation
|
|
|
|
CCPE System must distinguish between depth-oriented systems and automation-oriented systems.
|
|
|
|
### 9.1 Depth-Oriented Systems
|
|
|
|
Depth-oriented systems are used for:
|
|
|
|
* Deep thinking
|
|
* Theoretical writing
|
|
* Conceptual modeling
|
|
* Cognitive critique
|
|
* Strategic reflection
|
|
* Essay planning
|
|
* High-uncertainty reasoning
|
|
* Work requiring human judgment
|
|
|
|
They should not be forced into full automation.
|
|
|
|
They need:
|
|
|
|
```text
|
|
Human decision gates
|
|
Reflection loops
|
|
Interactive review
|
|
Uncertainty handling
|
|
Model fidelity
|
|
```
|
|
|
|
### 9.2 Automation-Oriented Systems
|
|
|
|
Automation-oriented systems are used for:
|
|
|
|
* File manipulation
|
|
* Formatting
|
|
* Batch processing
|
|
* Data extraction
|
|
* Low-risk code changes
|
|
* Report generation
|
|
* Tool execution
|
|
* Stable and repeatable workflows
|
|
|
|
They need:
|
|
|
|
```text
|
|
Authority rules
|
|
Tool scope
|
|
Validation
|
|
Failure handling
|
|
Rollback or recovery
|
|
State tracking
|
|
```
|
|
|
|
### 9.3 Hybrid Systems
|
|
|
|
Hybrid systems combine both.
|
|
|
|
Example:
|
|
|
|
```text
|
|
A modeling committee:
|
|
- Deep cognition is human-led.
|
|
- Agent review is assisted.
|
|
- Report collection may be automated.
|
|
- Deduplication may be automated.
|
|
- Final judgment remains human.
|
|
```
|
|
|
|
## 10. Human-in-the-Loop Principle
|
|
|
|
Human-in-the-loop is a first-class design element.
|
|
|
|
It is not a weakness.
|
|
|
|
It is required when work involves:
|
|
|
|
* High uncertainty
|
|
* High stakes
|
|
* Original thinking
|
|
* Conceptual modeling
|
|
* Theoretical synthesis
|
|
* Creative direction
|
|
* Strategic judgment
|
|
* Model authorship
|
|
* Irreversible decisions
|
|
* Major file changes or automation
|
|
|
|
CCPE System must explicitly mark where human judgment is required.
|
|
|
|
## 10.1 Language Policy
|
|
|
|
CCPE System supports a bilingual operating model:
|
|
|
|
```text
|
|
Protocol language: English allowed for portability.
|
|
Model canonical language: Simplified Chinese preferred for user-authored models.
|
|
English aliases: allowed as secondary labels.
|
|
Final Agent output: Simplified Chinese by default unless otherwise requested.
|
|
Direct user communication: Simplified Chinese by default unless otherwise requested.
|
|
File names: English kebab-case allowed and preferred for portability.
|
|
```
|
|
|
|
This policy preserves the user's original cognitive terminology while keeping the system portable across AI platforms.
|
|
|
|
## 11. Relationship Between Protocol, Skill, and Workbench
|
|
|
|
CCPE System has three operational layers.
|
|
|
|
### 11.1 Protocol
|
|
|
|
The protocol defines:
|
|
|
|
```text
|
|
Definitions
|
|
Classification rules
|
|
Layer structure
|
|
Quality rubric
|
|
Migration rules
|
|
Model rules
|
|
Runtime rules
|
|
```
|
|
|
|
It answers:
|
|
|
|
> What should this artifact be?
|
|
|
|
### 11.2 Forge Skill
|
|
|
|
The Forge Skill performs:
|
|
|
|
```text
|
|
Creation
|
|
Auditing
|
|
Refactoring
|
|
Model Mining
|
|
Indexing
|
|
Template-based generation
|
|
```
|
|
|
|
It answers:
|
|
|
|
> How should this artifact be created, inspected, or upgraded?
|
|
|
|
### 11.3 Workbench
|
|
|
|
The workbench stores:
|
|
|
|
```text
|
|
Raw inputs
|
|
Intermediate analysis
|
|
Upgraded drafts
|
|
Final artifacts
|
|
Archives
|
|
Model cards
|
|
Model indexes
|
|
Runtime specs
|
|
```
|
|
|
|
It answers:
|
|
|
|
> Where should this artifact live?
|
|
|
|
## 12. Immediate Build Target
|
|
|
|
The first operational target of CCPE System is:
|
|
|
|
```text
|
|
CCPE Forge Skill
|
|
= Creator + Auditor + Refactor + Model Mining
|
|
```
|
|
|
|
This Skill will be used to:
|
|
|
|
1. Inspect and repair CCPE itself.
|
|
2. Upgrade the previous CCPE intelligent agent.
|
|
3. Upgrade existing user-created agents.
|
|
4. Extract models from long-form writing.
|
|
5. Generate Model Cards.
|
|
6. Maintain Model Index.
|
|
7. Create future Agents, Skills, and Runtimes.
|
|
|
|
## 13. Success Criteria
|
|
|
|
CCPE System is successful if it can help the user:
|
|
|
|
```text
|
|
Create new agents without over-engineering.
|
|
Upgrade old agents without losing their intellectual flavor.
|
|
Extract reusable models from long-form writing.
|
|
Convert models into Skills where appropriate.
|
|
Build multi-agent workflows with clear human decision gates.
|
|
Distinguish deep cognition from automation.
|
|
Maintain a coherent model library.
|
|
Use Codex as a practical construction environment.
|
|
```
|
|
|
|
## 14. Core Warning
|
|
|
|
Do not confuse structure with intelligence.
|
|
|
|
The purpose of CCPE System is not to add more fields.
|
|
|
|
The purpose is to preserve and operationalize cognitive structure.
|
|
|
|
A good CCPE artifact should be:
|
|
|
|
```text
|
|
Clear enough to execute
|
|
Rich enough to preserve model depth
|
|
Modular enough to reuse
|
|
Light enough to maintain
|
|
Safe enough to run
|
|
Specific enough to evaluate
|
|
```
|