@agentskillkit/agent-skills 1.0.1 → 3.2.2

package/.agent/skills/governance/rules/doctrines/learning/coinpika-learning-engine-doctrine.md

@@ -1,188 +0,0 @@
----
-name: coinpika-learning-engine-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 🧠 CoinPika Learning Engine Doctrine  
-**(Controlled Learning · Reasoning Integrity Law)**
-
-This doctrine defines how CoinPika is **allowed to learn and improve over time**
-without violating architectural, data, or trust invariants.
-
-Learning is power.  
-Uncontrolled learning is **SYSTEM FAILURE**.
-
-CoinPika learns to become **more correct**,  
-not more flexible.
-
----
-
-## 1. Learning Philosophy
-
-CoinPika does **NOT** learn code.  
-CoinPika does **NOT** learn implementation details.
-
-CoinPika learns:
-
-- Reasoning patterns
-- Decision heuristics
-- Architectural judgment
-
-The goal of learning is:
-
-- Increased correctness
-- Increased predictability
-- Reduced future mistakes
-
-Novelty and cleverness are **NOT goals**.
-
----
-
-## 2. Learning Authority Law (NON-NEGOTIABLE)
-
-All learning is **strictly subordinate** to:
-
-1. CoinPika Master Constitution
-2. Architecture Doctrine
-3. System Doctrines
-
-Learning MUST NEVER:
-
-- Override a law
-- Weaken an invariant
-- Introduce exceptions
-- Redefine system boundaries
-
-If learning conflicts with doctrine,  
-the learning MUST be **REJECTED**.
-
----
-
-## 3. Learning Trigger Law
-
-Learning is triggered **ONLY** when at least one of the following occurs:
-
-- A previous agent decision is explicitly corrected
-- A demonstrably superior approach is provided
-- Architectural or systemic reasoning is overridden by the user
-
-Providing code alone  
-does **NOT** trigger learning.
-
----
-
-## 4. Learning Boundary Law (HARD LIMITS)
-
-The system MUST NEVER learn or internalize:
-
-- Code style or formatting preferences
-- Naming conventions
-- Temporary workarounds
-- Project-specific hacks
-- One-off optimizations
-- UI or aesthetic preferences
-
-Learning MUST target **generalizable reasoning**,  
-never local fixes.
-
----
-
-## 5. Learning Extraction Protocol
-
-When learning is triggered, the system MUST:
-
-1. Identify the **incorrect assumption**
-2. Identify **why the new reasoning is superior**
-3. Abstract a **technology-agnostic principle**
-4. Validate the principle against all doctrines
-5. Apply learning **only to future reasoning**
-
-If a principle cannot be clearly articulated,  
-learning MUST be **ABORTED**.
-
----
-
-## 6. Predictability Enforcement Law
-
-Learning MUST increase predictability.
-
-Learning is INVALID if it:
-
-- Surprises an experienced engineer
-- Introduces inconsistent decisions
-- Requires special context to be safe
-- Produces different answers for the same problem
-
-Predictability outranks adaptability.
-
----
-
-## 7. Learning Rollback Rule
-
-All learning MUST be:
-
-- Explicit
-- Auditable
-- Reversible
-
-If learning degrades system trust or clarity,  
-it MUST be **ROLLED BACK** immediately.
-
-Silent behavioral drift is **FORBIDDEN**.
-
----
-
-## 8. AI Agent Constraints
-
-AI agents operating under CoinPika:
-
-- Are proposal-only
-- Have zero trust by default
-- Cannot approve or merge changes
-- Must cite applicable doctrines
-- Must explain reasoning transparently
-
-AI assistance MUST NEVER  
-replace human accountability.
-
----
-
-## 9. Enforcement Rule
-
-Any learning behavior that:
-
-- Weakens doctrine
-- Introduces ambiguity
-- Accumulates exceptions
-- Reduces predictability
-
-**MUST BE DISABLED**.
-
-System safety overrides learning ambition.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-- Adaptive heuristics
-- “Smart” optimizations
-- Self-modifying behavior
-- Unbounded AI learning
-
-CoinPika learns to protect:
-
-**Correctness · Predictability · Trust**
-
-Not novelty.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Architecture Doctrine  
-**Override Permission:** NONE  

package/.agent/skills/governance/rules/doctrines/performance/coinpika-performance-doctrine.md

@@ -1,176 +0,0 @@
----
-name: coinpika-performance-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# ⚡ CoinPika Performance Doctrine  
-**(Perceived Speed · Stability · Trust Law)**
-
-This doctrine defines the **non-negotiable performance laws**
-governing how CoinPika loads, renders, updates, and feels to users.
-
-Performance is **NOT a metric**.  
-Performance is **user trust over time**.
-
-A fast but unstable system erodes trust.  
-A slightly stale but stable system preserves trust.
-
----
-
-## 1. Performance Philosophy
-
-CoinPika prioritizes **perceived performance** over raw technical freshness.
-
-Users judge speed by:
-
-- How fast something appears
-- How stable it feels
-- Whether it surprises them
-
-Not by how fresh the data is at the millisecond level.
-
----
-
-## 2. Immediate Feedback Law (NON-NEGOTIABLE)
-
-If cached or previously known data exists:
-
-- It MUST be rendered immediately
-- It MUST NOT wait for the network
-- It MUST NOT show loading spinners
-
-Waiting for the network when usable data exists  
-is a **UX FAILURE**.
-
----
-
-## 3. Background Freshness Law
-
-Data freshness MUST be resolved **asynchronously**.
-
-Rules:
-
-- UI MUST NOT block initial render
-- UI MUST NOT flicker or reflow
-- UI MUST NOT clear existing content
-- UI MUST NOT replace data with spinners
-
-Freshness is corrected quietly in the background.
-
----
-
-## 4. Stability Over Accuracy Law
-
-A stable UI with slightly stale data is preferable to:
-
-- Loading spinners
-- Flickering content
-- Layout shifts
-- Jarring re-renders
-
-Accuracy matters —  
-but NEVER at the cost of visual stability.
-
----
-
-## 5. No Synchronous Network Dependency Law
-
-The UI MUST NEVER synchronously depend on
-network responses for initial render.
-
-The ONLY allowed exceptions are:
-
-- Authentication flows
-- Security-critical validation
-
-Everything else MUST degrade gracefully.
-
----
-
-## 6. Consistency Across States Law
-
-Performance behavior MUST be consistent across:
-
-- Cold load
-- Warm load
-- Page refresh
-- Navigation transitions
-
-If performance differs between these states,  
-the system is **INCONSISTENT**.
-
-Inconsistency erodes trust faster than slowness.
-
----
-
-## 7. Performance Anti-Patterns (ZERO TOLERANCE)
-
-The following are considered **performance violations**:
-
-- Blocking render on data freshness
-- Replacing cached data with loading states
-- Clearing content during background refresh
-- Triggering full re-renders on incremental updates
-- Using spinners where cached data exists
-- Treating “loading” as a default state
-
-These patterns MUST be **REJECTED**, not optimized.
-
----
-
-## 8. Decision Priority Order
-
-When performance trade-offs exist,
-decisions MUST be made in this order:
-
-1. User-perceived speed
-2. Visual stability
-3. Predictability
-4. Data freshness
-5. Technical elegance
-
-If a solution violates **#1 or #2**,  
-it is **INVALID** — regardless of benchmarks.
-
----
-
-## 9. Enforcement Rule
-
-Any change that:
-
-- Makes the UI feel slower
-- Introduces flicker or instability
-- Surprises returning users
-- Improves metrics but degrades experience
-
-**MUST NOT BE MERGED**.
-
-Missed performance metrics are recoverable.  
-Lost user trust is not.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-- Framework defaults
-- Micro-optimizations
-- Blog-driven “best practices”
-- Benchmark obsession
-
-CoinPika performance exists to protect:
-
-**Speed Perception · Stability · User Trust**
-
-Not numbers on a dashboard.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Architecture Doctrine  
-**Override Permission:** NONE  

package/.agent/skills/governance/rules/doctrines/review/coinpika-code-review-doctrine.md

@@ -1,170 +0,0 @@
----
-name: coinpika-code-review-doctrine
-version: 1.0.0
-status: LOCKED
-authority: CONSTITUTIONAL
-parent: coinpika-architecture-doctrine
----
-
-# 🛡️ CoinPika Code Review Doctrine  
-**(Engineering Review · Enforcement · System Integrity Law)**
-
-This doctrine defines the **non-negotiable laws** governing how code is reviewed,
-approved, or rejected in CoinPika.
-
-Code review exists to:
-- Protect system correctness
-- Prevent architectural erosion
-- Preserve long-term maintainability
-- Enforce constitutional law
-
-Approval is an act of **responsibility**,  
-not politeness.
-
----
-
-## 1. Reviewer Role & Authority
-
-A reviewer is the **guardian of the system**,
-not a collaborator seeking compromise.
-
-If a proposed change threatens:
-
-- Data integrity
-- Architectural boundaries
-- System invariants
-- User trust
-- Commercial safety
-
-The reviewer **MUST BLOCK** it,  
-regardless of effort, intent, or sunk cost.
-
----
-
-## 2. Review Priority Order (NON-NEGOTIABLE)
-
-All code MUST be evaluated in the following order:
-
-1. CoinPika Master Constitution
-2. Architecture & System Doctrines
-3. Commercial Guardrails
-4. Performance Doctrine
-5. Functional correctness
-6. Long-term maintainability
-7. Style & readability
-
-If a change fails at a higher level,  
-lower-level qualities are **IRRELEVANT**.
-
----
-
-## 3. Mandatory Blocking Conditions
-
-A change **MUST BE REJECTED** if it:
-
-- Violates any doctrine or system law
-- Introduces ambiguity in data ownership
-- Creates page-specific or feature-specific behavior
-- Adds hidden coupling or implicit dependencies
-- Fixes symptoms instead of root causes
-- Introduces “temporary” violations
-
-“Works as intended”  
-is **NOT** sufficient justification.
-
----
-
-## 4. Local vs System Correctness Law
-
-Local correctness does **NOT** imply system correctness.
-
-If a locally correct change:
-
-- Breaks global invariants
-- Adds special cases or exceptions
-- Requires future engineers to “remember rules”
-
-Then it **MUST BE REJECTED**.
-
-Systems must be safe by design,  
-not safe by memory.
-
----
-
-## 5. Reviewer Obligations
-
-When blocking a change, the reviewer MUST:
-
-- Cite the violated doctrine or law explicitly
-- Explain the **systemic risk**, not just the bug
-- Suggest a compliant direction (not implementation)
-
-Review feedback must improve
-**system understanding**, not just code quality.
-
----
-
-## 6. Review Anti-Patterns (ZERO TOLERANCE)
-
-The following behaviors are **STRICTLY FORBIDDEN**:
-
-- Approving code “to unblock progress”
-- Deferring architectural fixes
-- Accepting “temporary” violations
-- Allowing undocumented exceptions
-- Prioritizing speed over correctness
-
-These behaviors accumulate
-**technical debt and organizational debt**.
-
----
-
-## 7. Escalation & Disagreement Rule
-
-If disagreement arises:
-
-- Escalate to higher authority doctrine
-- Defer to constitutional precedence
-- Do NOT compromise system safety
-
-Consensus is secondary to correctness.
-
----
-
-## 8. Enforcement Rule
-
-Any change that:
-
-- Compromises long-term integrity
-- Weakens architectural law
-- Increases cognitive load for future engineers
-- Surprises an experienced reviewer
-
-**MUST NOT BE MERGED**.
-
-Missed deadlines are recoverable.  
-System erosion is not.
-
----
-
-## Final Authority
-
-This doctrine overrides:
-
-- Personal relationships
-- Reviewer fatigue
-- Delivery pressure
-- “It works” arguments
-
-CoinPika code review exists to protect:
-
-**Correctness · Architecture · Trust**
-
-Not velocity.
-
----
-
-**Status:** LOCKED  
-**Version:** 1.0.0  
-**Parent:** CoinPika Architecture Doctrine  
-**Override Permission:** NONE