ccpe-system/README.md

CCPE System

1. What This Project Is

CCPE System is a context protocol engineering workspace for designing, auditing, refactoring, and maintaining AI Prompts, Agents, Skills, Workflows, Runtime protocols, and Cognitive Model assets.

CCPE originally emerged from advanced Prompt Engineering. The new CCPE System extends that foundation into Agentic Engineering.

Its purpose is to help transform AI from a one-off responder into a reusable, testable, composable, collaborative, and maintainable task-execution system.

CCPE System is also a supplier workspace for the user's local work projects. Project workbenches such as writing-workbench, knowledge-vault, video-workbench, and future work-projects should raise concrete requirements first; CCPE then supplies the appropriate Prompt Cards, Agent Specs, Runtime protocols, Model Cards, evaluation rules, invocation contracts, or integration registrations.

CCPE is not the runtime framework for deployed production systems. For production or business agents that will run inside LangGraph, CrewAI, a server application, or another agentic framework, CCPE may design and govern the agent specification, but implementation, deployment, service state, framework adapters, and production operations belong to the concrete development project.

For engineered cognitive model governance systems such as the-mindscape-of-bro-tsong, CCPE supplies architecture, Agent/Runtime contracts, evaluation rules, and integration requests. The product repository owns its governed model cards, model indexes, review runs, process records, and lifecycle decisions. CCPE's model-cards/ and model-index/ remain CCPE protocol, template, reference, and historical artifact surfaces unless a concrete CCPE artifact says otherwise.

2. Core Definition

CCPE is a context protocol engineering framework for constructing, auditing, and maintaining AI Prompt, Agent, Skill, and Agentic Workflow systems.

It systematically defines:

• Objective
• Role
• Context
• Capability
• Tool
• Authority
• Workflow
• Constraint
• State
• Output
• Evaluation
• Runtime environment

The goal is not to make every AI system fully automated. The goal is to make AI systems structurally clear, reusable, inspectable, and aligned with the depth and risk level of the work.

3. Primary Design Philosophy

CCPE System is built around one principle:

Do not treat every AI artifact as a prompt.

Some artifacts are prompts. Some are agents. Some are reusable skills. Some are workflows. Some are runtime protocols. Some are cognitive models. Some are model indexes. Some are hybrid systems.

The first job of CCPE is classification. The second job is structural diagnosis. The third job is creation or refactoring.

3.1 Repository Boundary

CCPE owns architecture, classification, and reusable cognitive assets. It does not own every execution artifact that those assets may produce.

CCPE System
= architecture forge
+ cognitive model registry
+ prompt / agent / skill / runtime specification workspace
+ external capability registration center

Project workbenches / vaults
= concrete project execution spaces
+ runbooks
+ project-specific process records
+ article materials
+ drafts
+ returned participant outputs
+ user decision records
+ product-owned model governance records

skills-vault
= automation skill source repository
+ installable tool skills
+ scripts
+ tests
+ fixtures
+ installation notes

Business rule:

CCPE designs who does what, why, under what authority, and with what evaluation.
Project repositories execute concrete work.
skills-vault implements repeatable automation actions.
Production application repositories implement deployable agentic systems.

When CCPE needs a deterministic helper from skills-vault, record the request under requirements/skills-vault/. Do not implement the automation source in this repository.

CCPE may design both development agents for the user's own work and production/business agents for deployed systems. Production/business agents should be exported or adapted into the target application project; CCPE should not become the server runtime or application framework.

4. Core Artifact Types

4.1 CCPE-Lite

CCPE-Lite is a lightweight Prompt Card for expert-style AI assistants.

Use it when the artifact is mainly:

• A single expert role
• A custom GPT / Gemini / Claude instruction
• A stable persona with a task method
• A human-facing reasoning or review assistant
• Not heavily dependent on external tools, state, or runtime orchestration

Typical examples:

• Red-team critic
• Socratic questioner
• Article reviewer
• Cognitive sparring partner
• Strategic thinking assistant

CCPE-Lite should remain portable, concise, and directly usable in chat-based AI products.

4.2 CCPE-Agent

CCPE-Agent is a durable Agent Spec for a reusable working role.

Use it when the artifact:

• Has a stable responsibility
• Needs to be maintained over time
• May participate in a multi-agent workflow
• Has explicit input and output contracts
• May call skills or tools
• Needs handoff rules, authority boundaries, and evaluation criteria

Typical examples:

• Committee member agent
• Project director agent
• Knowledge archivist agent
• Red-team analyst agent used as a workflow node
• Specialist agent in OpenClaw, Claude Code, Codex, or similar systems

CCPE-Agent is not limited to multi-agent systems. A single agent may also need an Agent Spec when it becomes a long-term, composable, or evaluable work unit.

4.3 CCPE-Committee

CCPE-Committee is a fixed multi-agent judgment or review structure.

Use it when:

• Several roles must preserve independent judgment
• Role tension matters
• Reports must be produced by real invocation
• Synthesis must not erase disagreement
• A human decision gate controls downstream action

Committee is not a casual collection of agents. It requires member definitions, invocation rules, report contracts, synthesis rules, and no-simulation discipline.

4.4 CCPE-Skill

CCPE-Skill is a reusable capability module.

A Skill may be:

• 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, procedure, checklist, reasoning protocol, tool usage rule, output template, and validation criteria.

Typical examples:

• Cognitive Imaging Skill
• Assumption stress-test Skill
• Argument-chain inspection Skill
• Voice-to-text preprocessing Skill
• Knowledge archival Skill
• Model extraction Skill
• Report synthesis Skill

A Skill should be reusable across multiple agents.

CCPE-Skill is distinct from automation Skill source. Deterministic script-backed automation belongs in skills-vault; CCPE registers it only when a CCPE Agent or Runtime formally depends on it.

4.5 CCPE-Runtime

CCPE-Runtime is a protocol for running multi-step, multi-role, tool-using, or long-running work.

Runtime does not always mean automation.

There are three major runtime orientations:

1. Interactive Runtime

   • Human-led
   • Deep thinking
   • High uncertainty
   • Human decision gates
   • Suitable for modeling, writing, research, and conceptual work

2. Automation Runtime

   • Process-led
   • Low uncertainty
   • Clear success criteria
   • Tool execution and file operations
   • Suitable for repetitive, verifiable, low-risk work

3. Hybrid Runtime

   • Deep work at the core
   • Automation around the edges
   • Human makes key decisions
   • Agents handle collection, formatting, routing, deduplication, and archival

Typical examples:

• Modeling committee workflow
• Article review committee
• Coding project planning and implementation workflow
• Knowledge extraction pipeline
• Multi-agent synthesis workflow

4.6 Integration Registration

Integration Registration records an external capability that CCPE depends on but does not own.

Use it for:

• skills-vault automation skills
• MCP servers
• CLI tools
• API services
• Installed local capabilities
• Agentic development frameworks

Registration records authority, allowed operations, safety, validation, failure behavior, and consumers. It does not copy implementation source.

5. Cognitive Model Assets

CCPE System distinguishes between Agents and Models.

An Agent is a role or work unit. A Model is a reusable cognitive structure. A Skill may execute a Model. A Runtime may orchestrate Agents and Skills that use Models.

5.1 Model Card

A Model Card is the canonical description of a single cognitive model.

It should capture:

• Model name
• Source material
• Core problem
• Scope
• Assumptions
• Mechanism
• Procedure
• Failure modes
• Falsification boundary
• Related agents
• Related skills
• Version status

Examples:

• Cognitive Imaging Model
• Giant Cognition Model
• Cognitive Prism Model
• Argument Compression Model
• Concept Boundary Model

A Model Card should preserve the structure of the model without forcing it into an agent persona.

5.2 Model Index

A Model Index organizes many Model Cards.

It should capture:

• Model taxonomy
• Model hierarchy
• Dependency relationships
• Overlap and conflict relationships
• Usage scenarios
• Related agents
• Related skills
• Version status
• Extraction source

The Model Index is necessary when a knowledge system contains dozens or hundreds of models.

6. CCPE Forge Skill

This project includes a Codex Skill called ccpe-forge.

The Forge Skill supports four modes:

6.1 Creator Mode

Use Creator Mode to create new artifacts:

• Prompt Cards
• Agent Specs
• Skills
• Runtime Specs
• Model Cards
• Model Index entries

Creator Mode must first clarify or infer the intended artifact type, usage mode, automation level, human decision points, and target platform.

6.2 Auditor Mode

Use Auditor Mode to inspect existing artifacts.

It should diagnose:

• Whether the artifact is Lite, Agent, Skill, Runtime, Model Card, or Hybrid
• Whether it has embedded cognitive models
• Whether it should be split into Agent, Skill, Model Card, or Runtime
• Whether it has unclear goals, boundaries, authority, state, output, or evaluation rules
• Whether it is over-engineered or under-specified

6.3 Refactor Mode

Use Refactor Mode to upgrade or restructure existing artifacts.

It should produce:

• Refactor plan
• Upgrade report
• Revised Prompt Card
• Agent Spec
• Skill Spec
• Runtime Spec
• Model Card
• Model Index entry

Refactor Mode must preserve the original intellectual flavor and core model unless explicitly instructed otherwise.

6.4 Model Mining Mode

Use Model Mining Mode to extract cognitive models from long-form writing, essays, notes, research drafts, or discussions.

It should identify:

• Explicit models
• Implicit models
• Foundational assumptions
• Mechanisms
• Procedures
• Scope
• Failure modes
• Falsification boundaries
• Possible Skill or Agent conversions

Model Mining should behave like lossless compression. It should remove rhetorical bulk, academic completeness overhead, and supporting digressions, while preserving the generative structure of the model.

7. Recommended Project Directory

ccpe-system/
├── AGENTS.md
├── README.md
│
├── ccpe-protocol/
│   ├── ccpe-system-definition.md
│   ├── ccpe-boundaries.md
│   ├── ccpe-classification-rules.md
│   ├── ccpe-artifact-taxonomy.md
│   ├── ccpe-operating-modes.md
│   ├── ccpe-layer-spec.md
│   ├── ccpe-quality-rubric.md
│   ├── ccpe-migration-policy.md
│   └── ccpe-governance-adapter.md
│
├── .codex/
│   └── skills/
│       └── ccpe-forge/
│           ├── SKILL.md
│           ├── references/
│           └── templates/
│
├── workbench/
│   ├── raw/
│   ├── analysis/
│   ├── upgraded/
│   └── archive/
│
├── agents/
│   ├── lite/
│   ├── agent-specs/
│   └── committees/
│
├── skills/
│   ├── cognitive/
│   ├── tool/
│   ├── workflow/
│   └── evaluation/
│
├── runtimes/
│   ├── interactive/
│   ├── automation/
│   └── hybrid/
│
├── model-cards/
│   ├── foundational/
│   ├── intermediate/
│   ├── applied/
│   ├── workflow-models/
│   └── implicit-extracted/
│
├── model-index/
│   ├── model-index.md
│   ├── model-taxonomy.md
│   ├── model-dependency-map.md
│   ├── model-usage-map.md
│   └── extraction-log.md
│
├── requirements/
│   └── skills-vault/           # Outbound supplier requests for deterministic automation helpers.
│
└── integrations/               # Create only when concrete registration files are needed.
    ├── skills-vault/
    ├── mcp/
    ├── cli-tools/
    └── api-services/

8. Recommended Workflow

8.1 Creating a New Agent

1. Place the creation request in workbench/raw/, reference the relevant source in knowledge-vault/prompts/, or describe it directly to Codex.

2. Ask Codex to use ccpe-forge in Creator Mode.

3. Generate a Creation Brief.

4. Confirm target form:

   • Lite
   • Agent
   • Committee
   • Skill
   • Runtime
   • Model Card
   • Integration Registration
   • Project Runbook or automation Skill source that should be routed outside CCPE
   • Hybrid

5. Generate the target file.

6. Place the final artifact in the correct directory.

8.1.1 Requesting Deterministic Automation

If a CCPE Agent or Runtime needs a script-backed automation helper:

1. Classify the helper as automation Skill source.
2. Write a supplier request under requirements/skills-vault/.
3. Wait for implementation in skills-vault.
4. After implementation and installation, create an Integration Registration only if a CCPE artifact formally depends on it.

8.2 Upgrading an Existing Agent

1. Identify the old agent source. Current prompt assets usually live in C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\; use workbench/raw/ only for temporary or unclassified inputs.

2. Ask Codex to use ccpe-forge in Auditor Mode.

3. Review the Upgrade Report.

4. If accepted, run Refactor Mode.

5. Store:

   • Diagnosis in workbench/analysis/
   • Upgraded artifact in workbench/upgraded/
   • Final reusable artifact in agents/, skills/, runtimes/, or model-cards/

8.3 Extracting Models from Articles

1. Put the article in workbench/raw/, or reference its canonical source path if it already lives in knowledge-vault.
2. Ask Codex to use ccpe-forge in Model Mining Mode.
3. Extract candidate models.
4. Generate Model Cards.
5. Register them in Model Index.
6. Optionally convert strong models into Skills or Agents.

8.4 Building a Multi-Agent Workflow

1. Define the Runtime first.
2. Define each Agent Spec.
3. Define shared Skills.
4. Define Model Cards used by those Agents or Skills.
5. Define human decision gates.
6. Define output, evaluation, and archival rules.

9. Key Design Rules

9.1 Classify Before Creating

Never create or refactor before classifying the artifact type.

9.2 Do Not Over-Engineer

Not every expert prompt needs Agent, Skill, and Runtime layers.

Use the lightest structure that preserves function, clarity, and future maintainability.

9.2.1 Scenario Probe Before Layering

Before creating or upgrading an artifact, identify how it will actually be used:

Web / GPT / Gemini / Claude single-agent prompt
Codex-callable Skill
Durable workflow role
Manual multi-agent committee member
Automated or semi-automated Runtime node

Scenario determines the required layers.

For mature single-agent expert prompts, the default repair path is:

CCPE-Lite
+ Model Card if the embedded model is stable and important

Add Skill only when the method must be invoked by Codex or reused across agents. Add Agent Spec only when the role needs collaboration, handoff, authority, or evaluation contracts. Add Runtime only when stages, state, routing, synthesis, archival, tools, or automation are involved.

Lite is not a downgraded Agent Spec. In Web-style expert use, Lite is the production artifact.

9.3 Do Not Under-Specify High-Risk Systems

If the system involves tools, file operations, code changes, long-running tasks, multi-agent handoff, external APIs, or automation, it must include authority, state, evaluation, and runtime rules.

9.4 Separate Role from Model

A cognitive model should not be permanently trapped inside one agent if it can be reused.

Preferred separation:

Agent = role, responsibility, interaction, authority
Model Card = cognitive model definition
Skill = executable procedure using the model
Runtime = workflow orchestration

9.5 Preserve Intellectual Flavor

When refactoring an existing agent, preserve:

• Core metaphor
• Cognitive stance
• Domain worldview
• Distinctive reasoning style
• Original purpose
• User's intellectual intent

Structural cleanup must not flatten the agent into generic corporate sludge.

9.6 Human-in-the-Loop Is First-Class

Human involvement is not a failure of automation.

For deep thinking, model building, theoretical writing, conceptual design, and high-uncertainty evaluation, human judgment must remain central.

CCPE should explicitly mark human decision gates instead of hiding them.

10. Current Project Goal

The immediate goal of this workspace is to construct the CCPE System itself, based on Codex, as a reusable Skill-driven workbench.

The first build target is:

CCPE Forge Skill
= Creator + Auditor + Refactor + Model Mining

The Forge Skill will then be used to:

1. Inspect and repair CCPE itself.
2. Upgrade the previous CCPE intelligent agent.
3. Upgrade existing user-created agents.
4. Extract Model Cards from long-form writing.
5. Build a usable Model Index.
6. Support future creation of Agents, Skills, and Runtimes.

11. File Naming Conventions

Use lowercase kebab-case for filenames.

Recommended examples:

cognitive-imaging-model.md
cognitive-imaging.skill.md
cognitive-imaging-specialist.agent.md
modeling-committee.runtime.md
zhangliao-red-team.prompt.md

12. Versioning

Each durable artifact should include:

author:
version:
created:
updated:
status:
based_on:
related_models:
related_skills:
related_agents:

Recommended status values:

candidate
draft
active
rejected
merged
deprecated
archived

13. Language Policy

CCPE System uses a bilingual language strategy.

Protocol language may be English when portability across Codex, Claude Code, OpenClaw, GPT, Gemini, and other systems is useful.

For user-authored cognitive models, the canonical model language should normally be Simplified Chinese. English aliases are allowed as secondary labels for navigation, interoperability, and file references.

Final Agent output should use Simplified Chinese by default unless the user explicitly requests another language.

When CCPE System communicates directly with the user, it should also use Simplified Chinese by default unless otherwise requested.

File names may use English kebab-case for portability.

Bilingual naming is encouraged for important models.

Example:

认知显影术 / Cognitive Imaging
巨人认知 / Giant Cognition
认知棱镜 / Cognitive Prism

14. First Build Sequence

Recommended construction order:

Batch 0:
README.md
AGENTS.md

Batch 1:
ccpe-system-definition.md
ccpe-classification-rules.md
ccpe-operating-modes.md

Batch 2:
ccpe-layer-spec.md
ccpe-quality-rubric.md
ccpe-migration-policy.md

Batch 3:
.codex/skills/ccpe-forge/SKILL.md

Batch 4:
Forge workflow references

Batch 5:
Model Card and Model Index rules

Batch 6:
Core templates

Batch 7:
Model and upgrade templates

Batch 8:
Model Index initial files

Batch 9:
Directory README files