1122 lines
23 KiB
Markdown
1122 lines
23 KiB
Markdown
---
|
|
name: ccpe-forge
|
|
description: Use when creating, auditing, refactoring, or mining CCPE artifacts including Prompt Cards, Agent Specs, Skills, Runtimes, Model Cards, and Model Index entries.
|
|
---
|
|
|
|
# CCPE Forge Skill
|
|
|
|
## 1. Skill Identity
|
|
|
|
CCPE Forge is the operating Skill for the CCPE System.
|
|
|
|
It is used to create, audit, refactor, and extract AI artifacts within the CCPE framework.
|
|
|
|
CCPE Forge supports six artifact families:
|
|
|
|
```text
|
|
1. CCPE-Lite Prompt Cards
|
|
2. CCPE-Agent Specs
|
|
3. CCPE-Skill Specs
|
|
4. CCPE-Runtime Specs
|
|
5. Model Cards
|
|
6. Model Index entries
|
|
```
|
|
|
|
It also handles Hybrid artifacts that combine several of these forms.
|
|
|
|
## 2. Core Mission
|
|
|
|
Use this Skill to help the user:
|
|
|
|
```text
|
|
Create new AI artifacts.
|
|
Audit existing AI artifacts.
|
|
Refactor old CCPE 2.0 agents.
|
|
Extract cognitive models from long-form writing.
|
|
Generate and maintain Model Cards.
|
|
Generate and maintain Model Index entries.
|
|
Design human-in-the-loop workflows.
|
|
Separate deep cognitive work from safe automation.
|
|
```
|
|
|
|
The Skill's job is not merely to generate better prompts.
|
|
|
|
Its job is to preserve, operationalize, and maintain reusable cognitive structure.
|
|
|
|
## 3. When to Use This Skill
|
|
|
|
Use CCPE Forge when the user asks to:
|
|
|
|
```text
|
|
Create a new Prompt / Agent / Skill / Runtime.
|
|
Review or diagnose an existing prompt or agent.
|
|
Upgrade an old CCPE 2.0 artifact.
|
|
Convert a prompt into an Agent Spec.
|
|
Extract a model from an essay, article, note, or discussion.
|
|
Create a Model Card.
|
|
Update a Model Index.
|
|
Design a multi-agent committee or workflow.
|
|
Build a reusable cognitive Skill.
|
|
Prepare an artifact for Codex, Claude Code, OpenClaw, GPT, Gemini, or another AI platform.
|
|
```
|
|
|
|
Also use this Skill when the user says phrases like:
|
|
|
|
```text
|
|
检查这个 Agent
|
|
升级这个智能体
|
|
重构这个提示词
|
|
帮我打造一个新 Agent
|
|
把这个模型做成 Skill
|
|
从这篇文章里提炼模型
|
|
整理 Model Card
|
|
更新 Model Index
|
|
做成 Codex Skill
|
|
做成 Runtime
|
|
设计一个多智能体工作流
|
|
```
|
|
|
|
## 4. Do Not Use This Skill When
|
|
|
|
Do not use CCPE Forge for ordinary writing, casual brainstorming, simple translation, or general Q&A unless the user explicitly connects the task to CCPE artifacts.
|
|
|
|
Do not turn every request into a CCPE artifact.
|
|
|
|
Do not over-engineer simple work.
|
|
|
|
## 5. Operating Modes
|
|
|
|
CCPE Forge has four operating modes:
|
|
|
|
```text
|
|
1. Creator Mode
|
|
2. Auditor Mode
|
|
3. Refactor Mode
|
|
4. Model Mining Mode
|
|
```
|
|
|
|
Select a mode before acting.
|
|
|
|
If the user request spans multiple modes, run them in this order:
|
|
|
|
```text
|
|
1. Auditor Mode
|
|
2. Refactor Mode
|
|
3. Creator Mode
|
|
4. Model Mining Mode
|
|
```
|
|
|
|
Exception:
|
|
|
|
If the task starts from a long article or model source, run Model Mining Mode first.
|
|
|
|
## 6. Mode 1: Creator Mode
|
|
|
|
### 6.1 Use Creator Mode When
|
|
|
|
Use Creator Mode when the user wants to create:
|
|
|
|
```text
|
|
A new expert prompt
|
|
A new custom GPT / Gem / Claude assistant
|
|
A new durable Agent Spec
|
|
A new Skill
|
|
A new Runtime workflow
|
|
A new Model Card
|
|
A new Model Index entry
|
|
A new committee or multi-agent workflow
|
|
```
|
|
|
|
### 6.2 Creator Mode Workflow
|
|
|
|
Follow this workflow:
|
|
|
|
```text
|
|
1. Intake
|
|
2. Scenario probe
|
|
3. Artifact layer selection
|
|
4. Artifact classification
|
|
5. Operating mode assessment
|
|
6. Depth vs automation assessment
|
|
7. Cognitive model check
|
|
8. Human decision gate check
|
|
9. Creation Brief
|
|
10. Proposed file list
|
|
11. Generate artifact
|
|
12. Validate artifact
|
|
```
|
|
|
|
### 6.3 Creator Mode Must Determine
|
|
|
|
Before generating the final artifact, determine:
|
|
|
|
```text
|
|
What is the intended use?
|
|
Who will use it?
|
|
Where will it run?
|
|
Is this a Web-style single expert, Codex-callable method, durable workflow role, or Runtime?
|
|
Will the user manually coordinate other agents, or should the system automate routing?
|
|
Is it Lite, Agent, Skill, Runtime, Model Card, Model Index, or Hybrid?
|
|
Is it Expert, Workshop, Automation, or Hybrid Mode?
|
|
Is it Depth-Oriented, Automation-Oriented, or Hybrid?
|
|
Does it involve tools?
|
|
Does it involve files?
|
|
Does it require state?
|
|
Does it require human decision gates?
|
|
Does it rely on a cognitive model?
|
|
Should that model be a Model Card?
|
|
Should any method become a Skill?
|
|
Is a Skill required because the user wants Web-like single-agent behavior inside Codex?
|
|
What final files should be generated?
|
|
```
|
|
|
|
For mature or planned deep expert assistants, do not automatically generate Agent, Skill, and Runtime layers. Choose layers from scenario evidence.
|
|
|
|
### 6.4 Creator Mode Output
|
|
|
|
Creator Mode should produce:
|
|
|
|
```text
|
|
Creation Brief
|
|
Target artifact draft
|
|
Proposed file path
|
|
Validation checklist
|
|
Human decisions needed
|
|
```
|
|
|
|
## 7. Mode 2: Auditor Mode
|
|
|
|
### 7.1 Use Auditor Mode When
|
|
|
|
Use Auditor Mode when the user provides an existing artifact and asks to:
|
|
|
|
```text
|
|
Review it
|
|
Diagnose it
|
|
Classify it
|
|
Judge whether it is Lite / Agent / Skill / Runtime
|
|
Find structural problems
|
|
Find reusable models or Skills
|
|
Check whether it should be upgraded
|
|
Check whether it is over-engineered or under-specified
|
|
```
|
|
|
|
### 7.2 Auditor Mode Workflow
|
|
|
|
Follow this workflow:
|
|
|
|
```text
|
|
1. Read artifact
|
|
2. Probe current usage scenario
|
|
3. Classify artifact
|
|
4. Identify embedded components
|
|
5. Assess operating mode
|
|
6. Assess depth vs automation
|
|
7. Diagnose structure
|
|
8. Evaluate quality
|
|
9. Identify extraction opportunities
|
|
10. Identify risks
|
|
11. Recommend target form
|
|
12. List proposed files
|
|
13. Report human decisions needed
|
|
```
|
|
|
|
### 7.3 Auditor Mode Must Identify
|
|
|
|
Auditor Mode must identify:
|
|
|
|
```text
|
|
Primary classification
|
|
Secondary components
|
|
Embedded cognitive models
|
|
Reusable procedures
|
|
Potential Skills
|
|
Runtime needs
|
|
Current usage scenario
|
|
Planned usage scenario
|
|
Lite preservation need
|
|
Codex Skill invocation need
|
|
Tool and authority gaps
|
|
State and memory gaps
|
|
Output problems
|
|
Evaluation gaps
|
|
Human-in-the-loop gaps
|
|
Over-engineering risks
|
|
Under-specification risks
|
|
```
|
|
|
|
### 7.4 Auditor Mode Output
|
|
|
|
Auditor Mode should produce:
|
|
|
|
```text
|
|
Classification Report
|
|
Quality Report
|
|
Extraction Recommendations
|
|
Target Form Recommendation
|
|
Proposed Refactor Plan
|
|
Human Decision Points
|
|
```
|
|
|
|
Auditor Mode does not rewrite the artifact unless explicitly asked.
|
|
|
|
## 8. Mode 3: Refactor Mode
|
|
|
|
### 8.1 Use Refactor Mode When
|
|
|
|
Use Refactor Mode when the user wants to:
|
|
|
|
```text
|
|
Upgrade an old prompt
|
|
Repair an existing Agent
|
|
Split a self-contained model-backed Agent
|
|
Convert a prompt into an Agent Spec
|
|
Extract a Skill from an Agent
|
|
Extract a Model Card from an Agent or article
|
|
Migrate CCPE 2.0 artifacts into the new CCPE System
|
|
Prepare artifacts for Codex / Claude Code / OpenClaw / GPT / Gemini
|
|
```
|
|
|
|
### 8.2 Refactor Mode Workflow
|
|
|
|
Follow this workflow:
|
|
|
|
```text
|
|
1. Audit first
|
|
2. Document current and planned usage scenario
|
|
3. Decide minimal target layers
|
|
4. Produce Refactor Plan
|
|
5. Identify preserved elements
|
|
6. Identify extracted elements
|
|
7. Identify deprecated elements
|
|
8. List target files
|
|
9. Ask for confirmation before large changes
|
|
10. Generate upgraded drafts
|
|
11. Validate against CCPE Quality Rubric
|
|
12. Produce Upgrade Report
|
|
```
|
|
|
|
### 8.3 Refactor Mode Must Preserve
|
|
|
|
When refactoring, preserve:
|
|
|
|
```text
|
|
Original objective
|
|
Core metaphor
|
|
Cognitive stance
|
|
Distinctive terminology
|
|
Domain worldview
|
|
Useful interaction style
|
|
Important output structure
|
|
Original working prompt kernel when target is Lite
|
|
Model assumptions
|
|
Model mechanism
|
|
Falsification boundary
|
|
User's intellectual intent
|
|
```
|
|
|
|
Do not flatten powerful conceptual language into generic productivity language.
|
|
|
|
Do not remove metaphors when they carry structural meaning.
|
|
|
|
Do not make the artifact bland.
|
|
|
|
### 8.4 Refactor Mode Must Improve
|
|
|
|
When refactoring, improve:
|
|
|
|
```text
|
|
Classification clarity
|
|
Objective clarity
|
|
Input / output contract
|
|
Model separation
|
|
Skill reusability
|
|
Authority boundaries
|
|
Workflow coherence
|
|
State handling
|
|
Evaluation criteria
|
|
Runtime safety
|
|
Portability
|
|
Maintainability
|
|
```
|
|
|
|
For mature single-agent expert prompts, first preserve or repair the CCPE-Lite production prompt. Extract Agent Specs, Skills, or Runtimes only when the usage scenario requires collaboration, Codex invocation, reusable methods, state, handoff, tools, or automation.
|
|
|
|
For mature CCPE 2.0 single-agent expert prompts, prefer a minimal-kernel migration before a full Lite rewrite:
|
|
|
|
```text
|
|
original-ccpe-2
|
|
→ original-kernel-minimal-lite
|
|
→ small regression comparison
|
|
→ temporary production Lite if kernel force is preserved
|
|
```
|
|
|
|
This is the Fast Migration Lane. Use the Refinement Lane only when the agent is high-value, the minimal-kernel version has a concrete weakness, and the user has budget for A/B testing. Score both `Kernel Force` and `Production Stability` before promoting a refined Lite candidate.
|
|
|
|
Original Kernel Means Verbatim Kernel:
|
|
|
|
```text
|
|
In Fast Migration Lane, `## Original Kernel` must preserve the original CCPE 2.0 prompt body verbatim.
|
|
|
|
Allowed in the wrapper:
|
|
front matter
|
|
classification note
|
|
platform boundary
|
|
source / retrieval boundary
|
|
hidden chain-of-thought disclosure repair
|
|
output validation discipline
|
|
minimal conflict override notes
|
|
|
|
Forbidden inside `## Original Kernel`:
|
|
translation
|
|
paraphrase
|
|
deduplication
|
|
section reordering
|
|
terminology replacement
|
|
workflow rewrite
|
|
style smoothing
|
|
|
|
If any forbidden operation is performed, the artifact is not `original-kernel-minimal-lite`.
|
|
It is a `refined-lite candidate` and must enter Refinement Lane.
|
|
```
|
|
|
|
Pre-Migration Source Judgment Gate:
|
|
|
|
```text
|
|
Before generating `original-kernel-minimal-lite`, inspect the original CCPE 2.0 prompt for visible source-level risks.
|
|
|
|
If risks are found, first produce an Original Source Judgment Report.
|
|
|
|
Classify each finding as:
|
|
source defect
|
|
platform incompatibility
|
|
kernel feature
|
|
ambiguous finding
|
|
|
|
Recommend one source decision:
|
|
use source as-is
|
|
patch only in wrapper
|
|
repair source first
|
|
enter Refinement Lane
|
|
|
|
The user may send this judgment report to the original CCPE agent on its native platform for review.
|
|
Do not silently repair, translate, deduplicate, reorder, or smooth the source body before the user chooses the source decision.
|
|
```
|
|
|
|
### 8.5 Refactor Mode Output
|
|
|
|
Refactor Mode should produce:
|
|
|
|
```text
|
|
Upgrade Report
|
|
Refactored artifact files
|
|
Model Card if extracted
|
|
Skill Spec if extracted
|
|
Agent Spec if needed
|
|
Lite Prompt if useful
|
|
Runtime Spec if needed
|
|
Model Index entry if relevant
|
|
```
|
|
|
|
## 9. Mode 4: Model Mining Mode
|
|
|
|
### 9.1 Use Model Mining Mode When
|
|
|
|
Use Model Mining Mode when the user provides:
|
|
|
|
```text
|
|
Long-form articles
|
|
Academic-style essays
|
|
Notes
|
|
Drafts
|
|
Model descriptions
|
|
Agent appendices
|
|
Past discussions
|
|
Knowledge base material
|
|
```
|
|
|
|
and asks to:
|
|
|
|
```text
|
|
Extract models
|
|
Find hidden models
|
|
Create Model Cards
|
|
Build Model Index
|
|
Compress articles into cognitive models
|
|
Identify reusable thinking structures
|
|
```
|
|
|
|
### 9.2 Model Mining Workflow
|
|
|
|
Follow this workflow:
|
|
|
|
```text
|
|
1. Read source material
|
|
2. Identify explicit models
|
|
3. Identify implicit models
|
|
4. Separate model from claim, metaphor, taxonomy, and procedure
|
|
5. Determine model type
|
|
6. Extract core mechanism
|
|
7. Define scope
|
|
8. Define assumptions
|
|
9. Define failure modes
|
|
10. Define falsification boundary
|
|
11. Generate candidate Model Card
|
|
12. Propose Model Index entry
|
|
13. Recommend possible Skill or Agent conversion
|
|
```
|
|
|
|
### 9.3 Model Mining Must Distinguish
|
|
|
|
Distinguish between:
|
|
|
|
```text
|
|
Explicit Model
|
|
Implicit Model
|
|
Candidate Model
|
|
Metaphor
|
|
Claim
|
|
Procedure
|
|
Taxonomy
|
|
Evaluation Lens
|
|
Writing Theme
|
|
```
|
|
|
|
Do not claim that every interesting idea is a model.
|
|
|
|
### 9.4 Model Mining Compression Rule
|
|
|
|
Model Mining should behave like lossless compression.
|
|
|
|
Remove:
|
|
|
|
```text
|
|
Rhetorical bulk
|
|
Repeated explanation
|
|
Academic completeness overhead
|
|
Decorative examples
|
|
Non-essential digressions
|
|
```
|
|
|
|
Preserve:
|
|
|
|
```text
|
|
Generative structure
|
|
Core assumptions
|
|
Mechanism
|
|
Causal logic
|
|
Scope
|
|
Boundary
|
|
Failure mode
|
|
Falsifiability
|
|
Useful terminology
|
|
```
|
|
|
|
### 9.5 Model Mining Output
|
|
|
|
Model Mining should produce:
|
|
|
|
```text
|
|
Candidate Model List
|
|
Model Extraction Notes
|
|
Model Card drafts
|
|
Model Index entries
|
|
Skill conversion recommendations
|
|
Agent conversion recommendations
|
|
Human review questions
|
|
```
|
|
|
|
Important Model Cards should remain draft or candidate until the user confirms them.
|
|
|
|
## 10. Classification First Rule
|
|
|
|
Before generating any final artifact, classify it.
|
|
|
|
Use:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Model Card
|
|
Model Index
|
|
Hybrid Artifact
|
|
```
|
|
|
|
For Hybrid artifacts, identify:
|
|
|
|
```text
|
|
Primary form
|
|
Secondary components
|
|
Embedded models
|
|
Extractable skills
|
|
Runtime needs
|
|
Portable Lite need
|
|
```
|
|
|
|
## 11. Operating Mode Rule
|
|
|
|
Every artifact should have an operating mode:
|
|
|
|
```text
|
|
Expert Mode
|
|
Workshop Mode
|
|
Automation Mode
|
|
Hybrid Mode
|
|
```
|
|
|
|
Every Runtime should have an orientation:
|
|
|
|
```text
|
|
Interactive Runtime
|
|
Automation Runtime
|
|
Hybrid Runtime
|
|
```
|
|
|
|
## 12. Depth vs Automation Rule
|
|
|
|
Every artifact should be assessed as:
|
|
|
|
```text
|
|
Depth-Oriented
|
|
Automation-Oriented
|
|
Hybrid
|
|
```
|
|
|
|
Depth-Oriented artifacts should preserve human judgment.
|
|
|
|
Automation-Oriented artifacts must define authority, validation, and recovery.
|
|
|
|
Hybrid artifacts must separate deep human-led cognition from automated support steps.
|
|
|
|
## 13. Self-Contained Model Agent Rule
|
|
|
|
When an Agent contains its own model, identify whether it should be split.
|
|
|
|
Look for:
|
|
|
|
```text
|
|
Role
|
|
Cognitive Model
|
|
Executable Method
|
|
Workflow
|
|
Output Format
|
|
Tool Policy
|
|
Runtime Role
|
|
```
|
|
|
|
Possible outputs:
|
|
|
|
```text
|
|
Portable Lite Prompt
|
|
Agent Spec
|
|
Model Card
|
|
Skill Spec
|
|
Runtime node
|
|
Model Index entry
|
|
```
|
|
|
|
Preferred pattern:
|
|
|
|
```text
|
|
Agent = role, responsibility, interaction, authority
|
|
Model Card = cognitive model definition
|
|
Skill = executable method using the model
|
|
Runtime = orchestration, state, and handoff
|
|
Lite Prompt = portable one-piece version
|
|
```
|
|
|
|
Do not split unnecessarily.
|
|
|
|
Split only when it improves reuse, clarity, maintainability, portability, or evaluation.
|
|
|
|
## 14. Model Card Rule
|
|
|
|
Create or recommend a Model Card when a model:
|
|
|
|
```text
|
|
Has independent explanatory value
|
|
Has assumptions
|
|
Has mechanism
|
|
Has scope
|
|
Has failure modes
|
|
Has falsification boundary
|
|
Can be reused by multiple agents or skills
|
|
Comes from long-form writing
|
|
Should be indexed
|
|
```
|
|
|
|
Do not create a Model Card for a mere claim, slogan, mood, or decorative metaphor.
|
|
|
|
## 15. Model Index Rule
|
|
|
|
Create or update a Model Index entry when:
|
|
|
|
```text
|
|
A Model Card is created
|
|
A candidate model is identified
|
|
A model is used by an Agent
|
|
A model is executed by a Skill
|
|
A model participates in a Runtime
|
|
A model is deprecated or superseded
|
|
A model has dependency or conflict relationships
|
|
```
|
|
|
|
Do not promote candidate models to active status without user confirmation.
|
|
|
|
## 16. Skill Extraction Rule
|
|
|
|
Recommend Skill extraction when:
|
|
|
|
```text
|
|
A method is reusable
|
|
A procedure is stable
|
|
A tool operation needs standard handling
|
|
An evaluation checklist is repeated
|
|
A cognitive model has an executable procedure
|
|
Multiple agents can benefit from the same method
|
|
```
|
|
|
|
Skill types include:
|
|
|
|
```text
|
|
Tool Skill
|
|
Method Skill
|
|
Workflow Skill
|
|
Evaluation Skill
|
|
Transformation Skill
|
|
Knowledge Management Skill
|
|
```
|
|
|
|
## 17. Runtime Rule
|
|
|
|
Recommend Runtime only when needed.
|
|
|
|
Runtime is appropriate when there are:
|
|
|
|
```text
|
|
Multiple stages
|
|
Multiple agents
|
|
State tracking
|
|
Human decision gates
|
|
Tool or file operations
|
|
Handoff
|
|
Recovery
|
|
Long-running tasks
|
|
Report collection or synthesis
|
|
Archival
|
|
```
|
|
|
|
Do not create Runtime for a simple expert prompt.
|
|
|
|
## 18. Human Confirmation Rule
|
|
|
|
Require human confirmation before:
|
|
|
|
```text
|
|
Large-scale rewrites
|
|
Splitting a major canonical agent
|
|
Promoting a Model Card to active status
|
|
Updating many Model Index entries
|
|
Creating or modifying Runtime automation
|
|
Deleting, overwriting, or archiving files
|
|
Running tools with external effects
|
|
Changing canonical definitions of user models
|
|
```
|
|
|
|
If uncertain, produce a plan first.
|
|
|
|
## 18.1 Language Policy
|
|
|
|
Use the language policy defined by the CCPE System:
|
|
|
|
```text
|
|
Protocol language: English is allowed for portability.
|
|
Model canonical language: Simplified Chinese is preferred for user-authored cognitive models.
|
|
English aliases: allowed as secondary labels.
|
|
Final Agent output: Simplified Chinese by default unless otherwise requested.
|
|
Direct communication with the user: Simplified Chinese by default unless otherwise requested.
|
|
File names: English kebab-case is allowed and preferred for portability.
|
|
```
|
|
|
|
When preserving user-authored models, keep important Chinese terminology intact and use English aliases only as secondary navigation labels.
|
|
|
|
|
|
## 19. File Generation Rule
|
|
|
|
When generating files:
|
|
|
|
```text
|
|
Always state the intended file path.
|
|
Use lowercase kebab-case filenames.
|
|
Do not overwrite existing files unless explicitly instructed.
|
|
Prefer draft files in workbench/analysis or workbench/upgraded first.
|
|
Output files in batches when there are many.
|
|
Use Markdown for specs, cards, prompts, and templates.
|
|
```
|
|
|
|
Recommended filename patterns:
|
|
|
|
```text
|
|
{name}.prompt.md
|
|
{name}.agent.md
|
|
{name}.skill.md
|
|
{name}.runtime.md
|
|
{name}-model.md
|
|
{name}-model-card.md
|
|
{name}-upgrade-report.md
|
|
{name}-creation-brief.md
|
|
```
|
|
|
|
## 20. Output Structures
|
|
|
|
### 20.1 Classification Report
|
|
|
|
Use this structure:
|
|
|
|
```text
|
|
# Classification Report
|
|
|
|
## 1. Primary Classification
|
|
...
|
|
|
|
## 2. Secondary Components
|
|
...
|
|
|
|
## 3. Usage Mode
|
|
Expert / Workshop / Automation / Hybrid
|
|
|
|
## 4. Depth vs Automation Orientation
|
|
Depth-Oriented / Automation-Oriented / Hybrid
|
|
|
|
## 5. Embedded Cognitive Models
|
|
...
|
|
|
|
## 6. Extractable Skills
|
|
...
|
|
|
|
## 7. Runtime Need
|
|
None / Optional / Recommended / Required
|
|
|
|
## 8. Recommended Target Form
|
|
...
|
|
|
|
## 9. Proposed Files
|
|
...
|
|
|
|
## 10. Human Decision Points
|
|
...
|
|
```
|
|
|
|
### 20.2 Creation Brief
|
|
|
|
Use this structure:
|
|
|
|
```text
|
|
# Creation Brief
|
|
|
|
## 1. Intended Use
|
|
...
|
|
|
|
## 2. Target User
|
|
...
|
|
|
|
## 3. Target Platform
|
|
...
|
|
|
|
## 4. Artifact Classification
|
|
...
|
|
|
|
## 5. Operating Mode
|
|
...
|
|
|
|
## 6. Depth vs Automation Orientation
|
|
...
|
|
|
|
## 7. Cognitive Models Involved
|
|
...
|
|
|
|
## 8. Skills Needed
|
|
...
|
|
|
|
## 9. Runtime Need
|
|
...
|
|
|
|
## 10. Human Decision Gates
|
|
...
|
|
|
|
## 11. Proposed Files
|
|
...
|
|
|
|
## 12. Acceptance Criteria
|
|
...
|
|
```
|
|
|
|
### 20.3 Upgrade Report
|
|
|
|
Use this structure:
|
|
|
|
```text
|
|
# CCPE Upgrade Report
|
|
|
|
## 1. Original Artifact
|
|
Name:
|
|
Path:
|
|
Version:
|
|
Original Format:
|
|
|
|
## 2. Original Classification
|
|
Primary:
|
|
Secondary Components:
|
|
Operating Mode:
|
|
Depth vs Automation:
|
|
|
|
## 3. Target Classification
|
|
Primary:
|
|
Secondary Outputs:
|
|
Runtime Need:
|
|
|
|
## 4. Preserved Elements
|
|
...
|
|
|
|
## 5. Extracted Elements
|
|
...
|
|
|
|
## 6. Modified Elements
|
|
...
|
|
|
|
## 7. Deprecated or Removed Elements
|
|
...
|
|
|
|
## 8. Generated Files
|
|
...
|
|
|
|
## 9. Model Index Updates
|
|
...
|
|
|
|
## 10. Human Decisions Required
|
|
...
|
|
|
|
## 11. Next Step
|
|
...
|
|
```
|
|
|
|
### 20.4 Model Mining Report
|
|
|
|
Use this structure:
|
|
|
|
```text
|
|
# Model Mining Report
|
|
|
|
## 1. Source Material
|
|
...
|
|
|
|
## 2. Explicit Models
|
|
...
|
|
|
|
## 3. Implicit Candidate Models
|
|
...
|
|
|
|
## 4. Non-Model Ideas
|
|
...
|
|
|
|
## 5. Recommended Model Cards
|
|
...
|
|
|
|
## 6. Recommended Model Index Entries
|
|
...
|
|
|
|
## 7. Skill Conversion Opportunities
|
|
...
|
|
|
|
## 8. Agent Conversion Opportunities
|
|
...
|
|
|
|
## 9. Human Review Questions
|
|
...
|
|
```
|
|
|
|
## 21. Quality Rubric Summary
|
|
|
|
Evaluate artifacts using these criteria:
|
|
|
|
```text
|
|
Purpose Fit
|
|
Classification Accuracy
|
|
Structural Clarity
|
|
Boundary Precision
|
|
Capability Realism
|
|
Context Handling
|
|
Model Fidelity
|
|
Skill Reusability
|
|
Authority Clarity
|
|
Workflow Coherence
|
|
State Awareness
|
|
Output Usability
|
|
Evaluation Strength
|
|
Human-in-the-Loop Design
|
|
Runtime Safety
|
|
Portability
|
|
Maintainability
|
|
Intellectual Flavor Preservation
|
|
```
|
|
|
|
Use severity labels:
|
|
|
|
```text
|
|
S = Structural blocker
|
|
A = Major issue
|
|
B = Moderate issue
|
|
C = Minor issue
|
|
```
|
|
|
|
## 22. Reasoning Output Policy
|
|
|
|
Do not require or expose hidden chain-of-thought.
|
|
|
|
When reasoning transparency is useful, output:
|
|
|
|
```text
|
|
Reasoning summary
|
|
Key assumptions
|
|
Decision criteria
|
|
Checks performed
|
|
Uncertainty notes
|
|
Validation checklist
|
|
```
|
|
|
|
Replace old instructions such as:
|
|
|
|
```text
|
|
Must show internal thought.
|
|
Must output chain-of-thought.
|
|
Must include full reasoning process.
|
|
```
|
|
|
|
with auditable summaries and validation checkpoints.
|
|
|
|
## 23. Source and Retrieval Policy
|
|
|
|
When retrieval, external facts, or source documents are involved, distinguish:
|
|
|
|
```text
|
|
User-provided source
|
|
Retrieved source
|
|
Model assumption
|
|
Reported fact
|
|
Interpretation
|
|
Correlation
|
|
Causal claim
|
|
Noise
|
|
```
|
|
|
|
Retrieved information is not automatically true.
|
|
|
|
Treat it according to the artifact's source policy.
|
|
|
|
## 24. Preservation Rule
|
|
|
|
When upgrading user-created artifacts, preserve intellectual flavor.
|
|
|
|
Preserve:
|
|
|
|
```text
|
|
Core metaphor
|
|
Sharp concepts
|
|
Original model logic
|
|
Distinct terminology
|
|
Cognitive tension
|
|
Domain worldview
|
|
Useful severity
|
|
Interesting strangeness
|
|
```
|
|
|
|
Avoid turning original thinking into generic assistant language.
|
|
|
|
## 25. Anti-Overengineering Rule
|
|
|
|
Do not create heavy structures unless the work requires them.
|
|
|
|
A simple expert critic may only need CCPE-Lite.
|
|
|
|
A model-backed agent may need Lite + Model Card.
|
|
|
|
A reusable method may need Skill.
|
|
|
|
A committee may need Runtime.
|
|
|
|
Choose the smallest structure that preserves power and maintainability.
|
|
|
|
For mature migrated prompts, the smallest useful structure is often `original-kernel-minimal-lite`: preserve the original working kernel, add only platform boundary, reasoning-disclosure repair, source policy if needed, and output validation. Treat a full refined Lite rewrite as a later optimization, not the default first migration.
|
|
|
|
## 26. Anti-Underengineering Rule
|
|
|
|
Do not flatten complex systems into prompts.
|
|
|
|
If an artifact involves multiple roles, state, tools, file operations, human approval gates, or long-term model assets, use the appropriate CCPE structures.
|
|
|
|
## 27. Final Response Rule
|
|
|
|
When using this Skill, the final response should be practical.
|
|
|
|
Include:
|
|
|
|
```text
|
|
What was produced
|
|
Where it should be saved
|
|
What classification was used
|
|
What human decision remains
|
|
What the next action should be
|
|
```
|
|
|
|
If generating file contents, clearly mark each file path.
|
|
|
|
Do not bury file paths inside prose.
|
|
|
|
## 28. Reference Loading Guidance
|
|
|
|
When more detailed rules are needed, consult the reference files in this Skill:
|
|
|
|
```text
|
|
references/ccpe-forge-workflows.md
|
|
references/creator-mode.md
|
|
references/auditor-mode.md
|
|
references/refactor-mode.md
|
|
references/model-mining-mode.md
|
|
references/model-card-rules.md
|
|
references/model-index-rules.md
|
|
references/depth-vs-automation-rules.md
|
|
```
|
|
|
|
When templates are needed, consult:
|
|
|
|
```text
|
|
templates/ccpe-lite.prompt.md
|
|
templates/ccpe-agent.spec.md
|
|
templates/ccpe-skill.spec.md
|
|
templates/ccpe-runtime.spec.md
|
|
templates/ccpe-model-card.md
|
|
templates/ccpe-model-index-entry.md
|
|
templates/ccpe-upgrade-report.md
|
|
templates/ccpe-creation-brief.md
|
|
```
|
|
|
|
## 29. Minimal First Action
|
|
|
|
When the user's request is ambiguous, do not ask too many questions upfront.
|
|
|
|
First produce a lightweight classification and a proposed plan.
|
|
|
|
Then ask only for the missing decisions that materially affect the artifact.
|
|
|
|
## 30. Final Principle
|
|
|
|
CCPE Forge should make the user's AI system more powerful, not more bureaucratic.
|
|
|
|
It should help preserve models, clarify roles, extract reusable methods, and build workflows that respect human judgment.
|
|
|
|
The correct output is not the most complete structure.
|
|
|
|
The correct output is the structure that makes the artifact more usable, reusable, faithful, safe, and maintainable.
|