create-principles-disciple 1.104.0 → 1.104.2

package/plugin/dist/templates/langs/en/skills/pd-mentor/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: pd-mentor
+description: Interactive command guidance and scenario-based recommendations to help users understand Principles Disciple features. TRIGGER CONDITIONS: (1) User asks "how to use", "what can you do", "what should I do" (2) User says "help me out", "introduce features" (3) New project needs setup guidance (4) User unsure what actions are available.
+disable-model-invocation: true
+---
+
+# /pd-mentor: Spicy Mentor
+
+I'm your intelligent mentor, helping you understand and use all features of Principles Disciple.
+
+**Remember: Pain is the fuel of evolution, and I'm the one who lights the fire.**
+
+---
+
+## Execution Principles
+
+1. **Scenario-based Guidance**: Recommend the most appropriate commands based on user's current task
+2. **Interactive Q&A**: Use AskUserQuestion to understand user intent
+3. **Flowchart Display**: Visualize SOP processes
+4. **Options First**: Provide preset options to reduce typing burden
+
+---
+
+## Command Index
+
+| Command | Purpose | Use Case |
+|---------|---------|----------|
+| `/pd-init` | Initialize strategy | New project startup |
+| `/pd-bootstrap` | Environment tool scan and upgrade | Tool upgrade |
+| `/pd-research` | Initiate tool upgrade research | Deep research |
+| `/pd-thinking` | Manage mental models and candidates | Metacognition |
+| `/pd-evolution-status` | View trust score and security stage | Permission check |
+| `/pd-status` | View system status (GFI and Pain Dictionary) | Health check |
+| `/pd-help` | Get interactive command guidance | This skill |
+
+---
+
+## Scenario Matching
+
+### Scenario 1: New Project Initialization
+
+**Trigger**: User says "I just created a new project" or similar
+
+**Recommended Flow**:
+1. `/pd-init` - Establish strategic vision
+2. `/pd-bootstrap` - Scan environment tools, get capability list
+3. `/pd-thinking` - Establish project's mental model baseline
+
+**Script**: "A new project is like a blank canvas. Let me help you lay the foundation: strategy first, then equipment, finally mental framework."
+
+---
+
+### Scenario 2: Bug Fix Needed
+
+**Trigger**: User says "there's a bug", "got an error", "something's wrong"
+
+**Recommended Flow**:
+1. `/pd-status` - Check system status (GFI and Pain Dictionary)
+2. `/pd-evolution-status` - View EP tier and evolution status
+
+**Script**: "Problems are the fuel of evolution. Let me help you diagnose and fix systematically."
+
+---
+
+### Scenario 3: Daily Maintenance & Review
+
+**Trigger**: User says "what did I do today", "check progress", "give me a report"
+
+**Recommended Flow**:
+1. `/pd-evolution-status` - View current trust score
+2. `/pd-status` - Check GFI and Pain Dictionary status
+
+**Script**: "Let me help you review the current system status."
+
+---
+
+### Scenario 4: Permission or Security Related
+
+**Trigger**: User says "not enough permissions", "blocked", "security level"
+
+**Recommended Flow**:
+1. `/pd-evolution-status` - View trust score and security stage
+2. Explain current stage's capability boundaries
+
+**Script**: "Trust is earned, not given. Let me help you understand your current security level."
+
+---
+
+### Scenario 6: Tool Upgrade Needs
+
+**Trigger**: User says "want to upgrade tools", "research new version", "tech stack update"
+
+**Recommended Flow**:
+1. `/pd-bootstrap` - Scan current environment
+2. `/pd-research` - Initiate research for specific tools
+
+**Script**: "Tool upgrades are the guarantee of combat capability. Let me help you scan and plan."
+
+---
+
+## SOP Flowchart
+
+```
+┌─────────────────────────────────────────────────────────┐
+│              Evolution Loop SOP                         │
+├─────────────────────────────────────────────────────────┤
+│                                                         │
+│  Step 1: TRIAGE                                         │
+│     └─→ Collect evidence, reproduction steps, risk      │
+│                                                         │
+│  Step 2: DIAGNOSIS                                      │
+│     └─→ Root cause analysis, impact assessment          │
+│                                                         │
+│  Step 3: AUDIT                                          │
+│     └─→ Security check, logic verification             │
+│                                                         │
+│  Step 4: PLAN                                           │
+│     └─→ Target files, execution steps, rollback plan   │
+│                                                         │
+│  Step 5: EXECUTE                                        │
+│     └─→ Modify code according to plan                   │
+│                                                         │
+│  Step 6: VERIFY                                         │
+│     └─→ Run tests, check metrics                        │
+│                                                         │
+│  Step 7: REVIEW                                         │
+│     └─→ Code review, quality assessment                 │
+│                                                         │
+│  Step 8: LOG                                            │
+│     └─→ Record lessons learned, update principles       │
+│                                                         │
+└─────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Execution Flow
+
+### Step 1: Intent Recognition
+
+Use `AskUserQuestion` to ask user about current task scenario:
+
+**Options**:
+- 🆕 New project initialization
+- 🐛 Bug fix
+- 📊 Daily review
+- 🧹 Workspace cleanup
+- 🔐 Permission/Security
+- 🔧 Tool upgrade
+- ❓ Other
+
+### Step 2: Scenario Matching
+
+Based on user's selected scenario, recommend corresponding command flow.
+
+### Step 3: Confirm Execution
+
+Ask user if they want to execute a command:
+- "Execute `/pd-xxx` command now?"
+- "Need me to explain this command in detail?"
+
+---
+
+## Advanced Usage
+
+### Combined Skills
+
+For complex scenarios, combine multiple skills:
+
+| Scenario | Combined Flow |
+|----------|---------------|
+| Major refactor | `/pd-evolution-status` → `deductive-audit` → execute |
+| System optimization | `/pd-status` → `root-cause` → optimize |
+| Project review | `/pd-evolution-status` → `/pd-status` → `reflection-log` |
+
+### Internal Skill Calls
+
+These skills are usually called automatically by the system, but advanced users can also trigger them manually:
+
+- `triage` - Issue triage
+- `root-cause` - Root cause analysis
+- `deductive-audit` - Deductive audit
+- `reflection` - Metacognitive reflection
+- `reflection-log` - Reflection logging
+
+---
+
+## FAQ
+
+**Q: What is GFI (Friction Index)?**
+A: GFI (Global Friction Index) measures the system's "pain level", range 0-100. Higher values indicate more friction, requiring attention.
+
+**Q: How is EP (Evolution Points) calculated?**
+A: EP is earned through successful task completion and problem resolution. Failures may deduct EP but have protection mechanisms. Reaching EP thresholds automatically upgrades your tier, unlocking more permissions (larger code modification limits).
+
+**Q: What is Pain Signal?**
+A: Pain Signal is a problem signal detected by the system. Runtime V2 routes it through `PainSignalBridge`; manual triggers use `pd pain record`. `.state/.pain_flag` is legacy compatibility only.
+
+**Q: How to view installed tool capabilities?**
+A: Check `.state/SYSTEM_CAPABILITIES.json` or run `/pd-bootstrap` to rescan.
+
+**Q: What's the difference between `/pd-thinking` and `/pd-research`?**
+A: `/pd-thinking` manages mental models and candidate solutions for metacognition and decision support; `/pd-research` initiates tool upgrade research for technical investigation.
+
+---
+
+## Closing
+
+**Remember our creed**:
+
+> "Pain is the fuel of evolution, reflection is the ladder of progress."
+
+For any questions, feel free to call `/pd-help` or ask me directly. I'm your Spicy Mentor, evolving with you.

package/plugin/dist/templates/langs/en/skills/pd-pain-signal/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: pd-pain-signal
+description: Manually trigger a Principles Disciple Runtime V2 pain diagnosis. Use this when the user reports the agent is stuck, looping, unresponsive, or asks to record/trigger a pain signal. Mandatory path: use `pd pain record`; never write `.state/.pain_flag` and never use legacy write_pain_flag tooling.
+disable-model-invocation: false
+---
+
+# Pain Signal (Runtime V2)
+
+Manual pain diagnosis must enter Runtime V2 through the CLI:
+
+```bash
+pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --json
+```
+
+## Forbidden
+
+- Do not write `.state/.pain_flag` directly.
+- Do not use `write_file`, shell redirection, `Set-Content`, `Out-File`, `node -e`, or any other file-writing method to create `.state/.pain_flag`.
+- Do not use `write_pain_flag`. That was a legacy path.
+
+## Verify
+
+Use:
+```bash
+pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
+pd candidate list --workspace "<workspace>" --json
+pd runtime flow show --workspace "<workspace>" --json
+```
+
+Success requires non-empty `candidateIds` and `ledgerEntryIds`.

package/plugin/dist/templates/langs/en/skills/pd-planner/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: pd-planner
+description: Movie-script-style planning to break complex tasks into executable steps. TRIGGER CONDITIONS: (1) Need to create an implementation plan (2) Complex task requires multi-act breakdown (3) User says "help me plan", "draft a proposal" (4) Need to clarify steps and dependencies before execution.
+disable-model-invocation: true
+---
+
+# Planner
+
+You are a professional planning expert. Your task is to break down complex tasks into executable steps.
+
+## Planning Method
+
+Use a movie-script-style planning framework:
+
+### Act 1: Understanding
+- **Scene Setting**: Clarify objectives, constraints, resources
+- **Character Analysis**: Identify all participants and their capabilities
+- **Conflict Identification**: Clarify core conflicts to resolve
+
+### Act 2: Decomposition
+- **Act Breakdown**: Break task into 3-7 key steps
+- **Sub-tasks within Acts**: Each act contains 3-5 sub-tasks
+- **Verification Points**: Verify output at the end of each act
+
+### Act 3: Prioritization
+- **Dependencies**: Identify task dependencies
+- **Risk Ordering**: Front-load high-risk tasks
+- **Resource Allocation**: Ensure critical resources are available
+
+## Output Format
+
+### Plan Document
+
+**Task Objective**: [Clear objective statement]
+
+**Constraints**:
+- Time constraints: [Time limits]
+- Resource constraints: [Available resources]
+- Risk constraints: [Risks to avoid]
+
+**Act 1: Understanding**
+- Scene: [Current situation]
+- Characters: [Stakeholders]
+- Conflict: [Core problem]
+
+**Act 2: Decomposition**
+
+**Act 1**: [Title]
+- Step 1.1: [Specific action]
+- Step 1.2: [Specific action]
+- Step 1.3: [Specific action]
+- Verification: [Success criteria]
+
+**Acts 2-3**: [Similar structure]
+
+**Act 3: Prioritization**
+- Sequence: [Recommended execution order]
+- Parallel opportunities: [Tasks that can run in parallel]
+- Checkpoints: [Key verification points]
+
+**Risk Assessment**: [Potential issues and mitigations]
+
+---
+
+Please follow this framework to create a plan and output a structured execution script.

package/plugin/dist/templates/langs/en/skills/pd-runtime-v2/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: pd-runtime-v2
+description: Use this skill when manually triggering, verifying, or debugging Principles Disciple Runtime V2 pain diagnosis. It enforces the Runtime V2 entrypoints: high-value gated automatic pain events and `pd pain record` for manual diagnosis. It forbids writing `.state/.pain_flag` directly.
+disable-model-invocation: false
+---
+
+# PD Runtime V2 Pain Diagnosis
+
+Use Runtime V2 for all pain diagnosis work. Do not use legacy pain flag files as an entrypoint.
+
+## Entry Points
+
+Automatic:
+- Tool failures first accumulate GFI/friction.
+- Only high-value episodes enter Runtime V2: high GFI, repeated same failure, severe semantic pain, LLM paralysis, or explicit manual pain.
+- Approved `pain_detected` events enter `PainSignalBridge`.
+- The bridge runs `SplitDiagnosticianRunner`, commits candidates, and intakes them into the ledger.
+
+Manual:
+```bash
+pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --json
+```
+
+Forbidden:
+- Do not write `.state/.pain_flag`.
+- Do not use `write_file`, shell redirection, `Set-Content`, `Out-File`, `node -e`, or any other file-writing method to create `.state/.pain_flag`.
+- Do not use a `write_pain_flag` tool. Runtime V2 does not use that tool.
+
+## Status Commands
+
+Runtime health:
+```bash
+pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
+```
+
+Flow policy:
+```bash
+pd runtime flow show --workspace "<workspace>" --json
+```
+
+Trace pain-to-ledger chain (PRI-455 promoted):
+```bash
+pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
+```
+
+Activation status (PRI-455 promoted):
+```bash
+pd activation list --workspace "<workspace>" --json
+```
+
+Candidates:
+```bash
+pd candidate list --workspace "<workspace>" --json
+pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
+```
+
+## Success Criteria
+
+A diagnosis is successful only when:
+- `status` is `succeeded`
+- `candidateIds` is non-empty
+- `ledgerEntryIds` is non-empty
+
+Task creation alone is not success. A run without candidates or ledger entries is failed/retried/incomplete.
+
+## If Manual Diagnosis Is Needed
+
+1. Use `pd pain record`.
+2. Inspect JSON output.
+3. If `candidateIds` or `ledgerEntryIds` is empty, treat it as not completed.
+4. Use `pd candidate list/show` and `pd runtime flow show` for follow-up.

package/plugin/dist/templates/langs/en/skills/profile/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: profile
+description: Manually correct or update the user's expertise profile. Use to tell the system "I am an expert in X" or "I am a novice in Y".
+disable-model-invocation: true
+---
+
+# Profile Corrector
+
+You are now the "Manual Intervention Profile" component.
+
+**Task**:
+1. Parse user input `$ARGUMENTS` (format like "Frontend: Expert").
+2. Generate an **incremental evaluation** file `.state/.user_verdict.json`, forcing that domain's weight to extremely high (or low, depending on user description).
+3. Inform user: Changes will take effect after task completion (Stop).
+
+**JSON Template**:
+```json
+{
+  "updates": [
+    {"domain": "<EXTRACTED_DOMAIN>", "delta": 10, "reason": "User self-declared expertise"}
+  ]
+}
+```
+*(Note: If Novice, set delta to -10)*

package/plugin/dist/templates/langs/en/skills/reflection/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: reflection
+description: Perform a deep metacognitive reflection on the current task status, user sentiment, and systemic issues. Use this before context compaction or when stuck.
+disable-model-invocation: false
+---
+
+# Metacognitive Reflection
+
+**Trigger Scenario**: Context about to be compacted (Memory Loss Imminent) or Task long-term stalled.
+**Goal**: Before forgetting the detailed process, extract "painful lessons" and solidify them as principles.
+
+Please execute the following reflection steps:
+
+## 1. Status Scan
+- **Goal**: What was our original objective? (Check early conversation context)
+- **Status**: How much is completed now? Where are we stuck?
+- **Cost**: We've consumed significant tokens. Is the output matching the cost?
+
+## 2. Pain Detection
+Please honestly answer the following questions (Yes/No):
+- [ ] **Task Stalled**: No实质性 code progress for 3+ consecutive rounds?
+- [ ] **Repeated Errors**: Bug fixed then reappeared, or same error reported twice?
+- [ ] **User Frustration**: User used negative words like "wrong", "no", "stop", or tone became impatient?
+- [ ] **Blind Action**: Modified code directly without PLAN or AUDIT?
+- [ ] **Architecture Degradation**: Is code more chaotic than when we started?
+
+## 3. Root Cause Analysis (If Pain Detected)
+If any of above is Yes, must perform deep attribution:
+- **Direct Cause**: What did we do (or not do) that led to current situation?
+- **Root Cause**: Where did our mental model go wrong? (Too eager? Ignored existing files? Disregarded tests?)
+
+## 4. Evolution Logging
+If pain detected, must execute:
+1. **Record**: Write analysis results to `memory/ISSUE_LOG.md`.
+2. **Extract**: If this is the second occurrence, extract a **Prohibitive Principle (Must NOT)**.
+3. **Reinforce**: Suggest a specific Hook or Test to prevent future recurrence.
+
+## 5. Recovery Plan
+- Since we're about to compact context, how should we continue with the "cleanest" state?
+- Update `memory/.scratchpad.md`, mark current progress, ensure seamless continuation after compaction.

package/plugin/dist/templates/langs/en/skills/reflection-log/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: reflection-log
+description: Final task reflection and evolution logging. Use to capture pain signals, update profiles, and propose new principles.
+disable-model-invocation: true
+---
+
+# Reflection & Evolution
+
+**Goal**: Transform single-task experience into system's permanent memory.
+
+Please execute the following closing operations:
+
+## 1. Pain Summary
+- Briefly describe the most painful, time-consuming, or failure-causing points in this task.
+
+## 2. Issue Logging
+- **Action**: Append detailed Pain Signal and diagnosis results to `memory/ISSUE_LOG.md`.
+
+## 3. Evolution Candidates
+- **Principle**: Propose a new principle (P-XX).
+- **Guardrail**: Suggest a specific Hook, Rule, or Test.
+  - **Path Interception**: Suggest adding sensitive directories to `risk_paths` in `.principles/PROFILE.json`.
+  - **Behavior Interception**: Suggest adding regex to `custom_guards` in `.principles/PROFILE.json` to intercept dangerous calls of specific tools (e.g., `Edit.*SYSTEM`).
+
+## 4. Positive Reinforcement
+- **Check Excellence Signals**: 
+  1. User's explicit praise (Quote user).
+  2. Objective performance/quality metric improvements (Cite data).
+  3. Reviewer's high evaluation (Excellent/Elegant).
+- **Extract Pattern**: If above signals exist, record `achievement` field in `.state/.user_verdict.json` describing the successful behavioral pattern.
+
+## 5. Attribution
+- **Agent Scorecard**: Evaluate sub-agent performance used in this task, write to `.state/.verdict.json`. Format follows `@.principles/schemas/agent_verdict_schema.json`.
+- **User Profile**: Evaluate user instruction quality and preferences, write to `.state/.user_verdict.json`. Format follows `@.principles/schemas/user_verdict_schema.json`.
+
+## 6. Cleanup
+- Clean up all intermediate marker files (e.g., `.pain_flag`, `.verdict.json`, etc.).

package/plugin/dist/templates/langs/en/skills/report/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: report
+description: Manually request a formal status report from the Reporter agent.
+disable-model-invocation: true
+---
+
+# /report: Get Work Report
+
+User (the boss) requests an immediate work report.
+
+## Execution Action
+1. Immediately delegate ``pd_spawn_agent(reporter)``.
+2. Task description: "The boss wants to know the current situation. Please analyze current conversation context and recent `memory/ISSUE_LOG.md` to write an elegant report for the boss. Remember to check their profile first!"

package/plugin/dist/templates/langs/en/skills/root-cause/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: root-cause
+description: Deep dive analysis into why a problem occurred. Uses the 5 Whys method and classifies the cause.
+disable-model-invocation: true
+---
+
+# Root Cause Analysis
+
+**Goal**: See through phenomena to essence, prevent repeated mistakes.
+
+Please execute diagnosis in the following format:
+
+## 1. Proximal Cause
+- **Verb-driven**: Describe what specific operation or lack thereof caused the immediate failure.
+
+## 2. 5 Whys (Deep Inquiry)
+1. Why did the proximal cause occur?
+2. ...
+3. ...
+4. ...
+5. Trace back to systemic or cognitive root.
+
+## 3. Root Cause
+- **Adjective/Design-driven**: Describe system architecture, process defects, or wrong assumptions.
+- **Guardrail Failure Analysis**: Why didn't existing gates (Hooks) or rules (Rules) intercept this error? Is it missing rules, loose matching, or logic loopholes?
+
+## 4. Category
+- [ ] **People**: Capability blind spots, habit issues.
+- [ ] **Design**: Process/tool defects, insufficient gates, architecture loopholes.
+- [ ] **Assumption**: Wrong assumptions about environment, versions, or dependencies.
+
+## 5. Principle Candidate
+- If we fix this issue, what principle should be added to prevent it from happening again?

package/plugin/dist/templates/langs/en/skills/triage/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: triage
+description: Initial problem definition and risk assessment. Use to collect environment info, reproduction steps, and logs.
+disable-model-invocation: true
+---
+
+# Triage (Problem Triage)
+
+**Goal**: Collect sufficient evidence to define the problem and assess change risk.
+
+Please output in the following structure:
+
+## 1. Goal
+- One sentence describing the final success criteria for this task.
+
+## 2. Problem
+- What is happening now? What is the expected behavior?
+- **Evidence**: List relevant log snippets, error codes, or observed anomalies.
+
+## 3. Reproduction
+- Provide clear reproduction commands or operation sequence.
+- Note key variables in current environment.
+
+## 4. Scope
+- Preview of involved files or modules.
+- **Risk Level**: Low / Medium / High (based on `.principles/PROFILE.json` definition).
+
+## 5. Next Step
+- Recommend which sub-agent to delegate (usually Explorer) for further evidence collection.

package/plugin/dist/templates/langs/en/skills/watch-evolution/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: watch-evolution
+description: Start the background evolution daemon to process queued tasks from EVOLUTION_QUEUE.json.
+---
+
+# /watch-evolution: Background Evolution Guardian
+
+**Goal**: Start a continuously running process to automatically analyze and fix backlog code issues.
+
+## 1. Environment Preparation
+- Ensure `evolution_mode: "async"` is configured in `.principles/PROFILE.json`.
+- Ensure `.state/evolution_queue.json` exists.
+
+## 2. Startup Command
+Run the following command to start the daemon:
+
+```bash
+python scripts/evolution_daemon.py
+```
+
+## 3. Workflow
+1. **Auto Scan**: Scan `.state/evolution_queue.json` every 30 seconds.
+2. **Scheduling Strategy**:
+   - Process tasks by `priority` from high to low (high priority first).
+   - Tasks with `status: retrying` are only re-executed after `next_retry_at` expires.
+   - Failed tasks enter exponential backoff retry, marked as `failed` after max attempts.
+3. **Diagnosis**: Load `root-cause` skill, locate error root cause in Headless mode.
+4. **Fix**: Load fix skill, automatically modify code and run tests.
+5. **Log**: Call `reflection-log` to store experience in `PRINCIPLES.md` and `ISSUE_LOG.md`.
+6. **Dashboard**: Real-time update of `memory/EVOLUTION_PRD.md` showing progress.
+
+## 4. Exit
+- Press `Ctrl+C` to stop background task. Task state will be preserved in JSON, can continue on next startup.