@pikaa-ai/pikaa 0.3.1 → 0.3.4

package/skills/markdown-mermaid-writing/references/diagrams/er.md

@@ -1,222 +0,0 @@
-<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
-
-# Entity Relationship (ER) Diagram
-
-> **Back to [Style Guide](../mermaid_style_guide.md)** — Read the style guide first for emoji, color, and accessibility rules.
-
-**Syntax keyword:** `erDiagram`
-**Best for:** Database schemas, data models, entity relationships, API data structures
-**When NOT to use:** Class hierarchies with methods (use [Class](class.md)), process flows (use [Flowchart](flowchart.md))
-
----
-
-## Exemplar Diagram
-
-```mermaid
-erDiagram
-    accTitle: Project Management Data Model
-    accDescr: Entity relationships for a project management system showing teams, projects, tasks, members, and comments with cardinality
-
-    TEAM ||--o{ PROJECT : "owns"
-    PROJECT ||--o{ TASK : "contains"
-    TASK ||--o{ COMMENT : "has"
-    TEAM ||--o{ MEMBER : "includes"
-    MEMBER ||--o{ TASK : "assigned to"
-    MEMBER ||--o{ COMMENT : "writes"
-
-    TEAM {
-        uuid id PK "🔑 Primary key"
-        string name "👥 Team name"
-        string department "🏢 Department"
-    }
-
-    PROJECT {
-        uuid id PK "🔑 Primary key"
-        uuid team_id FK "🔗 Team reference"
-        string title "📋 Project title"
-        string status "📊 Current status"
-        date deadline "⏰ Due date"
-    }
-
-    TASK {
-        uuid id PK "🔑 Primary key"
-        uuid project_id FK "🔗 Project reference"
-        uuid assignee_id FK "👤 Assigned member"
-        string title "📝 Task title"
-        string priority "⚠️ Priority level"
-        string status "📊 Current status"
-    }
-
-    MEMBER {
-        uuid id PK "🔑 Primary key"
-        uuid team_id FK "🔗 Team reference"
-        string name "👤 Full name"
-        string email "📧 Email address"
-        string role "🏷️ Job role"
-    }
-
-    COMMENT {
-        uuid id PK "🔑 Primary key"
-        uuid task_id FK "🔗 Task reference"
-        uuid author_id FK "👤 Author reference"
-        text body "📝 Comment text"
-        timestamp created_at "⏰ Created time"
-    }
-```
-
----
-
-## Tips
-
-- Include data types, `PK`/`FK` annotations, and **comment strings** with emoji for context
-- Use clear verb-phrase relationship labels: `"owns"`, `"contains"`, `"assigned to"`
-- Cardinality notation:
-  - `||--o{` one-to-many
-  - `||--||` one-to-one
-  - `}o--o{` many-to-many
-  - `o` = zero or more, `|` = exactly one
-- Limit to **5–7 entities** per diagram — split large schemas by domain
-- Entity names: `UPPER_CASE` (SQL convention)
-
----
-
-## Template
-
-```mermaid
-erDiagram
-    accTitle: Your Title Here
-    accDescr: Describe the data model and key relationships between entities
-
-    ENTITY_A ||--o{ ENTITY_B : "has many"
-    ENTITY_B ||--|| ENTITY_C : "belongs to"
-
-    ENTITY_A {
-        uuid id PK "🔑 Primary key"
-        string name "📝 Display name"
-    }
-
-    ENTITY_B {
-        uuid id PK "🔑 Primary key"
-        uuid entity_a_id FK "🔗 Reference"
-        string value "📊 Value field"
-    }
-```
-
----
-
-## Complex Example
-
-A multi-tenant SaaS platform schema with 10 entities spanning three domains — identity & access, billing & subscriptions, and audit & security. Relationships show the full cardinality picture from tenant isolation through user permissions to invoice generation.
-
-```mermaid
-erDiagram
-    accTitle: SaaS Multi-Tenant Platform Schema
-    accDescr: Ten-entity data model for a multi-tenant SaaS platform covering identity management, role-based access, subscription billing, and audit logging with full cardinality relationships
-
-    TENANT ||--o{ ORGANIZATION : "contains"
-    ORGANIZATION ||--o{ USER : "employs"
-    ORGANIZATION ||--|| SUBSCRIPTION : "holds"
-    USER }o--o{ ROLE : "assigned"
-    ROLE ||--o{ PERMISSION : "grants"
-    SUBSCRIPTION ||--|| PLAN : "subscribes to"
-    SUBSCRIPTION ||--o{ INVOICE : "generates"
-    USER ||--o{ AUDIT_LOG : "produces"
-    TENANT ||--o{ AUDIT_LOG : "scoped to"
-    USER ||--o{ API_KEY : "owns"
-
-    TENANT {
-        uuid id PK "🔑 Primary key"
-        string name "🏢 Tenant name"
-        string subdomain "🌐 Unique subdomain"
-        string tier "🏷️ Service tier"
-        boolean active "✅ Active status"
-        timestamp created_at "⏰ Created time"
-    }
-
-    ORGANIZATION {
-        uuid id PK "🔑 Primary key"
-        uuid tenant_id FK "🔗 Tenant reference"
-        string name "👥 Org name"
-        string billing_email "📧 Billing contact"
-        int seat_count "📊 Licensed seats"
-    }
-
-    USER {
-        uuid id PK "🔑 Primary key"
-        uuid org_id FK "🔗 Organization reference"
-        string email "📧 Login email"
-        string display_name "👤 Display name"
-        string status "📊 Account status"
-        timestamp last_login "⏰ Last active"
-    }
-
-    ROLE {
-        uuid id PK "🔑 Primary key"
-        uuid tenant_id FK "🔗 Tenant scope"
-        string name "🏷️ Role name"
-        string description "📝 Role purpose"
-        boolean system_role "🔒 Built-in flag"
-    }
-
-    PERMISSION {
-        uuid id PK "🔑 Primary key"
-        uuid role_id FK "🔗 Role reference"
-        string resource "🎯 Target resource"
-        string action "⚙️ Allowed action"
-        string scope "🔒 Permission scope"
-    }
-
-    PLAN {
-        uuid id PK "🔑 Primary key"
-        string name "🏷️ Plan name"
-        int price_cents "💰 Monthly price"
-        int seat_limit "👥 Max seats"
-        jsonb features "📋 Feature flags"
-        boolean active "✅ Available flag"
-    }
-
-    SUBSCRIPTION {
-        uuid id PK "🔑 Primary key"
-        uuid org_id FK "🔗 Organization reference"
-        uuid plan_id FK "🔗 Plan reference"
-        string status "📊 Sub status"
-        date current_period_start "📅 Period start"
-        date current_period_end "📅 Period end"
-    }
-
-    INVOICE {
-        uuid id PK "🔑 Primary key"
-        uuid subscription_id FK "🔗 Subscription reference"
-        int amount_cents "💰 Total amount"
-        string currency "💱 Currency code"
-        string status "📊 Payment status"
-        timestamp issued_at "⏰ Issue date"
-    }
-
-    AUDIT_LOG {
-        uuid id PK "🔑 Primary key"
-        uuid tenant_id FK "🔗 Tenant scope"
-        uuid user_id FK "👤 Acting user"
-        string action "⚙️ Action performed"
-        string resource_type "🎯 Target type"
-        uuid resource_id "🔗 Target ID"
-        jsonb metadata "📋 Event details"
-        timestamp created_at "⏰ Event time"
-    }
-
-    API_KEY {
-        uuid id PK "🔑 Primary key"
-        uuid user_id FK "👤 Owner"
-        string prefix "🏷️ Key prefix"
-        string hash "🔐 Hashed secret"
-        string name "📝 Key name"
-        timestamp expires_at "⏰ Expiration"
-        boolean revoked "❌ Revoked flag"
-    }
-```
-
-### Why this works
-
-- **10 entities organized by domain** — identity (Tenant, Organization, User, Role, Permission), billing (Plan, Subscription, Invoice), and security (Audit Log, API Key). The relationship lines naturally cluster related entities together.
-- **Full cardinality tells the business rules** — `||--||` (one-to-one) for Organization-Subscription means one subscription per org. `}o--o{` (many-to-many) for User-Role means flexible RBAC. Each relationship symbol encodes a constraint.
-- **Every field has type, annotation, and purpose** — PK/FK for schema generation, emoji comments for human scanning. A developer can read this diagram and write the migration script directly.

package/skills/markdown-mermaid-writing/references/diagrams/flowchart.md

@@ -1,177 +0,0 @@
-<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
-
-# Flowchart
-
-> **Back to [Style Guide](../mermaid_style_guide.md)** — Read the style guide first for emoji, color, and accessibility rules.
-
-**Syntax keyword:** `flowchart`
-**Best for:** Sequential processes, workflows, decision logic, troubleshooting trees
-**When NOT to use:** Complex timing between actors (use [Sequence](sequence.md)), state machines (use [State](state.md))
-
----
-
-## Exemplar Diagram
-
-```mermaid
-flowchart TB
-    accTitle: Feature Development Lifecycle
-    accDescr: End-to-end feature flow from idea through design, build, test, review, and release with a revision loop on failed reviews
-
-    idea([💡 Feature idea]) --> spec[📋 Write spec]
-    spec --> design[🎨 Design solution]
-    design --> build[🔧 Implement]
-    build --> test[🧪 Run tests]
-    test --> review{🔍 Review passed?}
-    review -->|Yes| release[🚀 Release to prod]
-    review -->|No| revise[✏️ Revise code]
-    revise --> test
-    release --> monitor([📊 Monitor metrics])
-
-    classDef start fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
-    classDef process fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
-    classDef decision fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
-    classDef success fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
-
-    class idea,monitor start
-    class spec,design,build,test,revise process
-    class review decision
-    class release success
-```
-
----
-
-## Tips
-
-- Use `TB` (top-to-bottom) for processes, `LR` (left-to-right) for pipelines
-- Rounded rectangles `([text])` for start/end, diamonds `{text}` for decisions
-- Max 10 nodes — split larger flows into "Phase 1" / "Phase 2" diagrams
-- Max 3 decision points per diagram
-- Edge labels should be 1–4 words: `-->|Yes|`, `-->|All green|`
-- Use `classDef` for **semantic** coloring — decisions in amber, success in green, actions in blue
-
-## Subgraph Pattern
-
-When you need grouped stages:
-
-```mermaid
-flowchart TB
-    accTitle: CI/CD Pipeline Stages
-    accDescr: Three-stage pipeline grouping code quality checks, testing, and deployment into distinct phases
-
-    trigger([⚡ Push to main])
-
-    subgraph quality ["🔍 Code Quality"]
-        lint[📝 Lint code] --> format[⚙️ Check formatting]
-    end
-
-    subgraph testing ["🧪 Testing"]
-        unit[🧪 Unit tests] --> integration[🔗 Integration tests]
-    end
-
-    subgraph deploy ["🚀 Deployment"]
-        build[📦 Build artifacts] --> ship[☁️ Deploy to staging]
-    end
-
-    trigger --> quality
-    quality --> testing
-    testing --> deploy
-    deploy --> done([✅ Pipeline complete])
-
-    classDef trigger_style fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
-    classDef success fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
-
-    class trigger trigger_style
-    class done success
-```
-
----
-
-## Template
-
-```mermaid
-flowchart TB
-    accTitle: Your Title Here (3-8 words)
-    accDescr: One or two sentences explaining what this diagram shows and what insight the reader gains
-
-    start([🏁 Starting point]) --> step1[⚙️ First action]
-    step1 --> decision{🔍 Check condition?}
-    decision -->|Yes| step2[✅ Positive path]
-    decision -->|No| step3[🔧 Alternative path]
-    step2 --> done([🏁 Complete])
-    step3 --> done
-```
-
----
-
-## Complex Example
-
-A 20+ node e-commerce order pipeline organized into 5 subgraphs, each representing a processing phase. Subgraphs connect through internal nodes, decision points route orders to exception handling, and color classes distinguish phases at a glance.
-
-```mermaid
-flowchart TB
-    accTitle: E-Commerce Order Processing Pipeline
-    accDescr: Full order lifecycle from intake through fulfillment, shipping, and notification with exception handling paths for payment failures, stockouts, and delivery issues
-
-    order_in([📥 New order]) --> validate_pay{💰 Payment valid?}
-
-    subgraph intake ["📥 Order Intake"]
-        validate_pay -->|Yes| check_fraud{🔐 Fraud check}
-        validate_pay -->|No| pay_fail[❌ Payment **declined**]
-        check_fraud -->|Clear| check_stock{📦 In stock?}
-        check_fraud -->|Flagged| manual_review[🔍 Manual **review**]
-        manual_review --> check_stock
-    end
-
-    subgraph fulfill ["📦 Fulfillment"]
-        pick[📋 **Pick** items] --> pack[📦 Pack order]
-        pack --> label[🏷️ Generate **shipping** label]
-    end
-
-    subgraph ship ["🚚 Shipping"]
-        handoff[🚚 Carrier **handoff**] --> transit[📍 In transit]
-        transit --> deliver{✅ Delivered?}
-    end
-
-    subgraph notify ["📤 Notifications"]
-        confirm_email[📧 Order **confirmed**]
-        ship_update[📧 Shipping **update**]
-        deliver_email[📧 Delivery **confirmed**]
-    end
-
-    subgraph exception ["⚠️ Exception Handling"]
-        pay_fail --> retry_pay[🔄 Retry payment]
-        retry_pay --> validate_pay
-        out_of_stock[📦 **Backorder** created]
-        deliver_fail[🔄 **Reattempt** delivery]
-    end
-
-    check_stock -->|Yes| pick
-    check_stock -->|No| out_of_stock
-    label --> handoff
-    deliver -->|Yes| deliver_email
-    deliver -->|No| deliver_fail
-    deliver_fail --> transit
-
-    check_stock -->|Yes| confirm_email
-    handoff --> ship_update
-    deliver_email --> complete([✅ Order **complete**])
-
-    classDef intake_style fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
-    classDef fulfill_style fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
-    classDef ship_style fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
-    classDef warn_style fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
-    classDef danger_style fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d
-
-    class validate_pay,check_fraud,check_stock,manual_review intake_style
-    class pick,pack,label fulfill_style
-    class handoff,transit,deliver ship_style
-    class confirm_email,ship_update,deliver_email warn_style
-    class pay_fail,retry_pay,out_of_stock,deliver_fail danger_style
-```
-
-### Why this works
-
-- **5 subgraphs map to real business phases** — intake, fulfillment, shipping, notification, and exceptions are how operations teams actually think about orders
-- **Exception handling is its own subgraph** — not scattered across phases. Agents and readers can see all failure paths in one place
-- **Color classes reinforce structure** — blue for intake, purple for fulfillment, green for shipping, amber for notifications, red for exceptions. Even without reading labels, the color pattern tells you which phase you're looking at
-- **Decisions route between subgraphs** — the diamonds (`{Payment valid?}`, `{In stock?}`, `{Delivered?}`) are the points where flow branches, and each branch leads to a clearly-labeled destination

package/skills/markdown-mermaid-writing/references/diagrams/gantt.md

@@ -1,138 +0,0 @@
-<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
-
-# Gantt Chart
-
-> **Back to [Style Guide](../mermaid_style_guide.md)** — Read the style guide first for emoji, color, and accessibility rules.
-
-**Syntax keyword:** `gantt`
-**Best for:** Project timelines, roadmaps, phase planning, milestone tracking, task dependencies
-**When NOT to use:** Simple chronological events (use [Timeline](timeline.md)), process logic (use [Flowchart](flowchart.md))
-
----
-
-## Exemplar Diagram
-
-```mermaid
-gantt
-    accTitle: Q1 Product Launch Roadmap
-    accDescr: Eight-week project timeline across discovery, design, build, and launch phases with milestones for design review and go/no-go decision
-
-    title 🚀 Q1 Product Launch Roadmap
-    dateFormat YYYY-MM-DD
-    axisFormat %b %d
-
-    section 📋 Discovery
-        User research          :done, research, 2026-01-05, 7d
-        Competitive analysis   :done, compete, 2026-01-05, 5d
-        Requirements doc       :done, reqs, after compete, 3d
-
-    section 🎨 Design
-        Wireframes             :done, wire, after reqs, 5d
-        Visual design          :active, visual, after wire, 7d
-        🏁 Design review       :milestone, review, after visual, 0d
-
-    section 🔧 Build
-        Core features          :crit, core, after visual, 10d
-        API integration        :api, after visual, 8d
-        Testing                :test, after core, 5d
-
-    section 🚀 Launch
-        Staging deploy         :staging, after test, 3d
-        🏁 Go / no-go          :milestone, decision, after staging, 0d
-        Production release     :crit, release, after staging, 2d
-```
-
----
-
-## Tips
-
-- Use `section` with emoji prefix to group by phase or team
-- Mark milestones with `:milestone` and `0d` duration — prefix with 🏁
-- Status tags: `:done`, `:active`, `:crit` (critical path, highlighted)
-- Use `after taskId` for dependencies
-- Keep total timeline **under 3 months** for readability
-- Use `axisFormat` to control date display (`%b %d` = "Jan 05", `%m/%d` = "01/05")
-
----
-
-## Template
-
-```mermaid
-gantt
-    accTitle: Your Title Here
-    accDescr: Describe the timeline scope and key milestones
-
-    title 📋 Your Roadmap Title
-    dateFormat YYYY-MM-DD
-    axisFormat %b %d
-
-    section 📋 Phase 1
-        Task one       :done, t1, 2026-01-01, 5d
-        Task two       :active, t2, after t1, 3d
-
-    section 🔧 Phase 2
-        Task three     :crit, t3, after t2, 7d
-        🏁 Milestone   :milestone, m1, after t3, 0d
-```
-
----
-
-## Complex Example
-
-A cross-team platform migration spanning 4 months with 6 sections, 24 tasks, and 3 milestones. Shows dependencies across teams (backend migration blocks frontend migration), critical path items, and the full lifecycle from planning through launch monitoring.
-
-```mermaid
-gantt
-    accTitle: Multi-Team Platform Migration Roadmap
-    accDescr: Four-month migration project across planning, backend, frontend, data, QA, and launch teams with cross-team dependencies, critical path items, and three milestone gates
-
-    title 🚀 Platform Migration — Q1/Q2 2026
-    dateFormat YYYY-MM-DD
-    axisFormat %b %d
-
-    section 📋 Planning
-        Kickoff meeting               :done, plan1, 2026-01-05, 2d
-        Architecture review            :done, plan2, after plan1, 5d
-        Migration plan document        :done, plan3, after plan2, 5d
-        Risk assessment                :done, plan4, after plan2, 3d
-        🏁 Planning complete           :milestone, m_plan, after plan3, 0d
-
-    section 🔧 Backend Team
-        API redesign                   :crit, be1, after m_plan, 12d
-        Data migration scripts         :be2, after m_plan, 10d
-        New service deployment         :crit, be3, after be1, 8d
-        Backward compatibility layer   :be4, after be1, 6d
-
-    section 🎨 Frontend Team
-        Component library update       :fe1, after m_plan, 10d
-        Page migration                 :crit, fe2, after be3, 12d
-        A/B testing setup              :fe3, after fe2, 5d
-        Feature parity validation      :fe4, after fe2, 4d
-
-    section 🗄️ Data Team
-        Schema migration               :crit, de1, after be2, 8d
-        ETL pipeline update            :de2, after de1, 7d
-        Data validation suite          :de3, after de2, 5d
-        Rollback scripts               :de4, after de1, 4d
-
-    section 🧪 QA Team
-        Test plan creation             :qa1, after m_plan, 7d
-        Regression suite               :qa2, after be3, 10d
-        Performance testing            :crit, qa3, after qa2, 7d
-        UAT coordination               :qa4, after qa3, 5d
-        🏁 QA sign-off                 :milestone, m_qa, after qa4, 0d
-
-    section 🚀 Launch
-        Staging deploy                 :crit, l1, after m_qa, 3d
-        🏁 Go / no-go decision         :milestone, m_go, after l1, 0d
-        Production cutover             :crit, l2, after m_go, 2d
-        Post-launch monitoring         :l3, after l2, 10d
-        Legacy system decommission     :l4, after l3, 5d
-```
-
-### Why this works
-
-- **6 sections map to real teams** — each team sees their workstream at a glance. Cross-team dependencies (frontend waits for backend API, QA waits for backend deploy) are explicit via `after taskId`.
-- **`:crit` marks the critical path** — the chain of tasks that determines the total project duration. If any critical task slips, the launch date moves. Mermaid highlights these in red.
-- **3 milestones are decision gates** — Planning Complete, QA Sign-off, and Go/No-Go. These are the points where stakeholders make decisions, not just status updates.
-- **24 tasks across 4 months** is readable because sections group by team. Without sections, this would be an unreadable wall of bars.

package/skills/markdown-mermaid-writing/references/diagrams/git_graph.md

@@ -1,74 +0,0 @@
-<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
-
-# Git Graph
-
-> **Back to [Style Guide](../mermaid_style_guide.md)** — Read the style guide first for emoji, color, and accessibility rules.
-
-**Syntax keyword:** `gitGraph`
-**Best for:** Branching strategies, merge workflows, release processes, git-flow visualization
-**When NOT to use:** General processes (use [Flowchart](flowchart.md)), project timelines (use [Gantt](gantt.md))
-
----
-
-## Exemplar Diagram
-
-```mermaid
-gitGraph
-    accTitle: Trunk-Based Development Workflow
-    accDescr: Git history showing short-lived feature branches merging into main with release tags demonstrating trunk-based development
-
-    commit id: "init"
-    commit id: "setup CI"
-
-    branch feature/auth
-    checkout feature/auth
-    commit id: "add login"
-    commit id: "add tests"
-
-    checkout main
-    merge feature/auth id: "merge auth" tag: "v1.0"
-
-    commit id: "update deps"
-
-    branch feature/dashboard
-    checkout feature/dashboard
-    commit id: "add charts"
-    commit id: "add filters"
-
-    checkout main
-    merge feature/dashboard id: "merge dash"
-
-    commit id: "perf fixes" tag: "v1.1"
-```
-
----
-
-## Tips
-
-- Use descriptive `id:` labels on commits
-- Add `tag:` for release versions
-- Branch names should match your actual convention (`feature/`, `fix/`, `release/`)
-- Show the **ideal** workflow — this is prescriptive, not descriptive
-- Use `type: HIGHLIGHT` on important merge commits
-- Keep to **10–15 commits** maximum for readability
-
----
-
-## Template
-
-```mermaid
-gitGraph
-    accTitle: Your Title Here
-    accDescr: Describe the branching strategy and merge pattern
-
-    commit id: "initial"
-    commit id: "second commit"
-
-    branch feature/your-feature
-    checkout feature/your-feature
-    commit id: "feature work"
-    commit id: "add tests"
-
-    checkout main
-    merge feature/your-feature id: "merge feature" tag: "v1.0"
-```