agemon 0.1.0 → 6.0.0

package/assets/skills/team-lead/skill-obsidian-vault-sync/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: skill-obsidian-vault-sync
+description: Formats raw meeting notes, technical plans, and generated tasks into structured, bidirectional Obsidian markdown notes with WikiLinks, YAML frontmatter, Dataview tags, and consistent folder organizational rules.
+triggers: ["@obsidian-sync", "format for obsidian", "create vault note", "obsidian note generator", "vault sync"]
+---
+
+# Instruction Rules
+1. **Strict YAML Frontmatter:** Every generated note MUST begin with valid YAML frontmatter containing metadata fields (`title`, `date`, `tags`, `type`, `status`).
+2. **Enforce Bidirectional Linking:** Automatically scan note content and wrap key domain concepts, people, systems, and projects in double brackets (e.g., `[[Projects/AITISI]]`, `[[People/Korak]]`, `[[Tech/Supabase]]`).
+3. **Dataview Task Formatting:** Format inline action items using standard Dataview syntax (`- [ ] task description #task @assignee due:YYYY-MM-DD`).
+4. **Output Format:** Pure, production-ready Obsidian Markdown code block ready for direct vault placement or API ingestion.
+
+# Formatting Framework
+- **Step 1: Note Categorization:** Identify note archetype (`meeting`, `architecture`, `task`, `project`, `journal`).
+- **Step 2: Metadata & Frontmatter Generation:** Construct ISO timestamps, tags, and relational properties.
+- **Step 3: Content Structuring & WikiLink Injection:** Format body text using standard headings (`##`) and apply `[[WikiLinks]]` to entities.
+- **Step 4: Target Vault Location Declaration:** Specify exact destination path inside the vault folder structure.
+
+---
+
+# Output Schema
+
+**Target Vault Path:** `Meetings/2026/2026-09-25-Architecture-Sync.md`
+
+```markdown
+---
+title: "Architecture Sync - Redis Caching & DB Migration"
+date: 2026-09-25
+type: meeting
+tags:
+  - meeting/technical
+  - project/infrastructure
+  - status/action-required
+status: open
+related:
+  - "[[Projects/AITISI]]"
+  - "[[People/Korak]]"
+---
+
+# Architecture Sync - Redis Caching & DB Migration
+
+## 📌 Context & Links
+- **Project Hub:** [[Projects/AITISI]]
+- **Lead Architect:** [[People/Korak]]
+- **Primary Tech Stack:** [[Tech/Nuxt]], [[Tech/Supabase]], [[Tech/Redis]], [[Tech/PostgreSQL]]
+
+---
+
+## 📝 Key Notes & Architectural Decisions
+Discussed API latency bottlenecks observed during peak load. To prevent database connection pool exhaustion in [[Tech/PostgreSQL]], we agreed to implement a caching layer using [[Tech/Redis]].
+
+### Summary Points
+- Database query times currently average ~180ms under high concurrency.
+- Adding a [[Tech/Redis]] caching layer is expected to reduce read latency below 20ms for static routes.
+- [[People/Korak]] will lead the implementation in `server/api/` and update system diagrams.
+
+---
+
+## ✅ Action Items & Tasks
+
+- [ ] Implement Redis connection pool in API server #task @Korak due:2026-10-02 priority:high
+- [ ] Benchmark query throughput on staging environment #task @Korak due:2026-10-05 priority:medium
+- [ ] Update infrastructure configuration in [[DevOps/Coolify-Setup]] #task @unassigned due:2026-10-08 priority:low
+
+---
+
+## 🔗 Related Notes
+- [[Architecture/ADR-004-Redis-Caching]]
+- [[MeetingNotes/2026-09-18-Sprint-Planning]]

package/assets/skills/team-lead/skill-prd-decomposer/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: skill-prd-decomposer
+description: Decomposes PRDs, feature requests, or technical specs into engineering-ready Epics and User Stories with testable Given/When/Then acceptance criteria.
+triggers: ["@prd-decomposer", "decompose prd", "create epics", "generate user stories", "breakdown backlog"]
+---
+
+# Instruction Rules
+1. **Enforce Atomic Stories:** Every generated user story must be small enough to implement in a single focused engineering session (1–3 days max).
+2. **Strict Acceptance Criteria:** Never use vague criteria like "works properly". Use explicit, testable statements or Given/When/Then formats.
+3. **Include Verification & Edge Cases:** Every story must specify UI, API, or DB verification steps alongside boundary conditions.
+4. **Output Format:** Clean Markdown using standard user story notation and tabular tracking matrices.
+
+# Decomposition Framework
+- **Step 1: Core Domain Identification:** Group raw requirements into logical functional Epics.
+- **Step 2: Story Mapping:** Break Epics into vertical user-facing or technical backend slices.
+- **Step 3: Criteria & Contract Definition:** Write clear acceptance criteria and technical dependencies for each story.
+- **Step 4: Backlog Matrix:** Tabulate story points, risk factors, and implementation order.
+
+---
+
+# Output Schema
+
+## 1. Feature Breakdown & Epic Mapping
+- **Input PRD / Concept:** [Name or link to source PRD]
+- **Target Release:** [e.g., Sprint 14 / v1.2.0]
+
+---
+
+## 2. Epic & Story Details
+
+### EPIC-01: [Epic Title]
+**Goal:** [Short statement on what business capability this Epic enables]
+
+#### US-101: [Story Title]
+- **As a** [user/role]
+- **I want to** [action/capability]
+- **So that** [business benefit/value]
+
+**Technical Notes & Scope:**
+- Target Files/Modules: `server/api/users.ts`, `components/UserProfile.vue`
+- Out of Scope: [What explicitly NOT to build in this story]
+
+**Acceptance Criteria:**
+- [ ] **AC-1 (Given/When/Then):** Given an authenticated user, when they click "Save", then validate inputs and save to database.
+- [ ] **AC-2 (Validation):** Return a `400 Bad Request` with an error payload if the email string is invalid.
+- [ ] **AC-3 (Verification):** Database record updated and cache invalidated.
+
+---
+
+#### US-102: [Story Title]
+- **As a** [user/role]
+- **I want to** [action/capability]
+- **So that** [business benefit/value]
+
+**Acceptance Criteria:**
+- [ ] **AC-1:** [Verifiable criterion]
+- [ ] **AC-2:** [Verifiable criterion]
+
+---
+
+## 3. Backlog Execution Matrix
+
+| Story ID | Summary | Effort (Points) | Dependencies | Risk Level |
+| :--- | :--- | :--- | :--- | :--- |
+| **US-101** | [Short summary] | 2 | None | Low |
+| **US-102** | [Short summary] | 3 | US-101 | Medium |
+
+## 4. Definition of Done Checklist
+- [ ] All acceptance criteria pass across listed user stories.
+- [ ] Code passes type-checks, linting, and existing test suites.
+- [ ] PR includes updated documentation or API specs if contracts changed.

package/assets/skills/team-lead/skill-sec-check/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: skill-sec-check
+description: Automated DevSecOps and security pre-flight evaluation skill. Scans architectural proposals, code diffs, and dependencies for OWASP Top 10 risks, secret leaks, RBAC flaws, and compliance gaps.
+triggers: ["@sec-check", "security review", "devsecops check", "owasp scan", "security audit"]
+---
+
+# Instruction Rules
+1. **Report High-Confidence Vulnerabilities Only:** Avoid theoretical noise. Trace inputs to confirm if data is truly attacker-controlled before flagging.
+2. **Never Ignore Environment/Secret Boundaries:** Flag any hardcoded keys, missing `.env.example` masks, or exposed client-side tokens.
+3. **Evaluate Zero-Trust & Least Privilege:** Question overly permissive database users, unauthenticated API endpoints, and unrestricted CORS headers.
+4. **Output Format:** Clean Markdown with actionable code-level mitigations and vulnerability severity badges.
+
+# Security Assessment Workflow
+- **Phase 1: Input Data Flow & Auth Check:** Trace user inputs, session handling, authentication, and authorization logic (RBAC/ABAC).
+- **Phase 2: OWASP & Injection Analysis:** Audit code/design against SQLi, XSS, SSRF, IDOR, and Command Injection risks.
+- **Phase 3: Secrets & Supply Chain Verification:** Check for exposed credentials, risky dependencies, and unsafe third-party packages.
+- **Phase 4: Remediation Plan:** Provide exact code fixes and security headers/configurations.
+
+---
+
+# Output Schema
+
+## 1. Executive Security Summary
+- **Overall Risk Score:** [ CRITICAL | HIGH | MEDIUM | LOW | PASS ]
+- **Target Context:** [e.g., Nuxt 3 Frontend + Supabase Backend + REST API]
+- **Primary Concerns Found:** [1-2 sentence high-level summary]
+
+## 2. Security Findings Matrix
+
+| Finding ID | Vulnerability Category | Severity | File / Endpoint | Status |
+| :--- | :--- | :--- | :--- | :--- |
+| **SEC-01** | Unauthenticated Mutation (IDOR) | HIGH | `/api/user/update` | NEEDS FIX |
+| **SEC-02** | Hardcoded JWT Secret Fallback | CRITICAL | `config/auth.ts` | NEEDS FIX |
+| **SEC-03** | Missing CORS Domain Restriction | MEDIUM | `server.ts` | WARNING |
+
+## 3. Deep-Dive Vulnerability Breakdown
+
+### [SEC-01] IDOR / Broken Access Control
+- **Location:** `server/api/projects/[id].ts`
+- **Threat Vector:** User can update project records without verifying ownership against the authenticated session token.
+- **Vulnerable Pattern:**
+  ```typescript
+  // BAD: Trusts route param directly
+  const { id } = event.context.params;
+  await db.update(projects).set(body).where(eq(projects.id, id));
+  ```
+- **Remediation Code:**
+  ```typescript
+  // GOOD: Enforces ownership boundary and allowlists writable fields
+  const session = await requireUserSession(event);
+  const { name, description } = body;
+  await db.update(projects)
+    .set({ name, description })
+    .where(and(
+      eq(projects.id, id),
+      eq(projects.ownerId, session.user.id)
+    ));
+  ```
+
+## 4. Compliance & Hardening Checklist
+- [ ] **Secrets Management:** All API keys loaded via `process.env` with zero fallbacks to defaults.
+- [ ] **Input Sanitization:** Parameterized SQL queries used exclusively (No raw string interpolation).
+- [ ] **Transport Security:** Strict-Transport-Security (HSTS) & CSP headers declared.
+- [ ] **Data Minimization:** APIs filter out sensitive fields (`password_hash`, `stripe_id`) before sending responses.
+
+## 5. Security Verdict & Next Steps
+- **Gatekeeper Status:** [ APPROVED | REJECTED UNTIL MITIGATED ]
+- **Required Action Items Before Deploy:**
+  1. Fix SEC-02 immediately by rotating exposed keys.
+  2. Implement session ownership check for SEC-01.

package/assets/skills/team-lead/skill-task-extractor/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: skill-task-extractor
+description: Scans transcripts, meeting notes, or raw discussion threads to extract commitments, convert vague statements into precise tasks, assign owners, infer explicit ISO deadlines, and generate structured task payloads.
+triggers: ["@extract-tasks", "extract todos", "generate action items", "transcript to tasks", "task extractor"]
+---
+
+# Instruction Rules
+1. **Normalize Vague Statements:** Transform vague discussion points (e.g., *"We should fix the database errors next week"*) into clear, actionable task titles (e.g., *"Implement connection pool timeout handling for PostgreSQL"*).
+2. **Explicit Date Conversion:** Convert all relative date references (e.g., *"by end of week"*, *"next Tuesday"*) into strict ISO format (`YYYY-MM-DD`), anchored to the transcript's own date/timestamp if it has one. If no reference date is available, ask the user for one before converting rather than guessing.
+3. **Owner Attribution:** Match mentioned names or roles to explicit task owners. If unassigned, mark clearly as `UNASSIGNED`.
+4. **Output Format:** Dual-format output containing a human-readable Obsidian Task list and a machine-readable JSON payload ready for PM tool APIs (Jira/Linear/Todoist/GitHub Issues).
+
+# Extraction Framework
+- **Step 1: Text Scanning & Intent Detection:** Scan inputs for action verbs, commitments, promises, and assignments.
+- **Step 2: Task Clarification:** Expand context to make every task self-contained without needing to re-read the original transcript.
+- **Step 3: Priority & Effort Inference:** Assign priority (`High`, `Medium`, `Low`) based on discussion urgency and risk.
+- **Step 4: Payload Formatting:** Generate both Markdown tasks and JSON API structures.
+
+---
+
+# Output Schema
+
+# Extracted Action Items
+
+## 1. Task Summary Matrix
+
+| Task ID | Action Title | Assignee | Priority | Due Date | Target Module |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| **TASK-01** | Configure Redis connection pooling for API routes | [[Korak]] | High | 2026-10-02 | `server/api/` |
+| **TASK-02** | Update Figma mockups for mobile onboarding flow | [[Sarah]] | Medium | 2026-09-30 | UI / UX |
+| **TASK-03** | Verify staging environment SSL certificate auto-renewal | UNASSIGNED | Low | 2026-10-05 | DevOps |
+
+---
+
+## 2. Obsidian Task List (Markdown Format)
+
+- [ ] **TASK-01:** Configure Redis connection pooling for API routes #task @Korak due:2026-10-02 priority:high
+- [ ] **TASK-02:** Update Figma mockups for mobile onboarding flow #task @Sarah due:2026-09-30 priority:medium
+- [ ] **TASK-03:** Verify staging environment SSL certificate auto-renewal #task @unassigned due:2026-10-05 priority:low
+
+---
+
+## 3. Machine-Readable API Payload (JSON)
+
+```json
+{
+  "source": "Meeting Transcript",
+  "generated_at": "2026-09-25",
+  "tasks": [
+    {
+      "id": "TASK-01",
+      "title": "Configure Redis connection pooling for API routes",
+      "description": "Implement connection pool parameters and handle timeout errors to prevent API latency spikes.",
+      "assignee": "Korak",
+      "priority": "High",
+      "due_date": "2026-10-02",
+      "tags": ["backend", "performance", "redis"]
+    },
+    {
+      "id": "TASK-02",
+      "title": "Update Figma mockups for mobile onboarding flow",
+      "description": "Simplify signup screens down to 2 steps as agreed during the roadmap sync.",
+      "assignee": "Sarah",
+      "priority": "Medium",
+      "due_date": "2026-09-30",
+      "tags": ["design", "ux", "mobile"]
+    },
+    {
+      "id": "TASK-03",
+      "title": "Verify staging environment SSL certificate auto-renewal",
+      "description": "Confirm the staging cert renews automatically before it next expires.",
+      "assignee": "UNASSIGNED",
+      "priority": "Low",
+      "due_date": "2026-10-05",
+      "tags": ["devops", "infra"]
+    }
+  ]
+}
+```

package/assets/skills/team-lead/skill-tech-spike/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: skill-tech-spike
+description: Scopes out unknown technical territories, verifies third-party integrations, evaluates library trade-offs, and designs proof-of-concept execution paths before sprint commitment.
+triggers: ["@spike", "tech spike", "proof of concept", "feasibility check", "investigate library"]
+---
+
+# Instruction Rules
+1. **Focus on risk mitigation and speed over production code.** A spike must answer a single technical question or prove/disprove a hypothesis.
+2. **Explicitly state timeboxes and scope boundaries.** Do not expand the scope beyond the target hypothesis.
+3. **Identify all third-party limits:** Rate limits, licensing restrictions, authentication overhead, and hardware/memory footprints.
+4. **Output format:** Use clean Markdown with structured tables and runnable evaluation code snippets.
+
+# Spike Execution Framework
+- **Phase 1: Hypothesis & Objectives:** What specific technical uncertainty are we solving?
+- **Phase 2: Feasibility & Boundary Evaluation:** Benchmark dependencies, APIs, and potential execution bottlenecks.
+- **Phase 3: Minimal Proof of Concept (PoC):** Provide an isolated code snippet or test suite to prove viability.
+- **Phase 4: Recommendation & Sprint Hand-off:** Go/No-Go verdict with effort estimates.
+
+---
+
+# Output Schema
+
+## 1. Spike Definition & Scope
+- **Hypothesis:** [e.g., "Supabase Realtime can handle 1,000 concurrent updates/sec without database lockups"]
+- **Timebox Limit:** [e.g., 4 Hours]
+- **Core Question:** [The single question that determines success/failure]
+
+## 2. Technical Evaluation Matrix
+
+| Criterion | Target Requirement | Evaluated Metric | Pass / Fail |
+| :--- | :--- | :--- | :--- |
+| **Performance / Latency** | < 200ms roundtrip | ~85ms | PASS |
+| **API Rate Limits** | > 5,000 req/min | 10,000 req/min | PASS |
+| **License / Security** | MIT / Apache 2.0 | AGPLv3 (Risk) | WARNING |
+| **Bundle / Overhead** | < 50KB gzip | 120KB gzip | FAIL |
+
+## 3. Minimal Viable Proof-of-Concept (PoC)
+
+Provide isolated, executable code to validate the integration:
+
+```typescript
+// Minimal execution test
+import { createClient } from '@supabase/supabase-js';
+
+async function testSpike() {
+  const client = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_KEY!);
+
+  console.time('Spike-Latency');
+  const { data, error } = await client.from('target_table').select('*').limit(1);
+  console.timeEnd('Spike-Latency');
+
+  if (error) throw error;
+  console.assert(data !== null, 'Expected a result from target_table');
+}
+
+testSpike();
+```

package/assets/skills/team-lead/skill-techlead-reviewer/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: skill-techlead-reviewer
+description: Acts as a Senior Tech Lead conducting pull request reviews. Evaluates architectural fit, code quality anti-patterns, N+1 performance bottlenecks, maintainability, and test coverage using prioritized finding levels.
+triggers: ["@code-review", "review pr", "review code", "tech lead review", "pull request review"]
+---
+
+# Instruction Rules
+1. **Focus on Architectural Leverage:** Prioritize correctness, security, and architectural fit over cosmetic formatting (leave formatting to automated linters/Prettier).
+2. **Prioritize Comments with Labels:** Every comment MUST include a priority badge (`🔴 [blocking]`, `🟡 [important]`, `🟢 [nit]`, `💡 [suggestion]`).
+3. **Be Specific and Actionable:** Explain *why* something is an issue and provide exact, ready-to-use refactored code blocks.
+4. **Output Format:** Strict Markdown with a structured summary, change categorization, and an actionable pull request review table.
+
+# Review Execution Phases
+- **Phase 1: High-Level Context Check:** Read diff metadata, file organization, and architectural alignment.
+- **Phase 2: Correctness & Performance Scan:** Check for async race conditions, unhandled null/undefined states, memory leaks, and $N+1$ database queries.
+- **Phase 3: Maintainability & Anti-Pattern Detection:** Check for tight coupling, duplication, "God components" (>300 lines), or magic strings/numbers.
+- **Phase 4: Structured Feedback Generation:** Output clean summary notes and an explicit approval decision.
+
+---
+
+# Output Schema
+
+## 1. Review Summary & Decision
+
+- **PR Target / Scope:** [e.g., `feature/payment-gateway-integration`]
+- **Verdict:** [ ✅ APPROVED | 🔄 REQUEST CHANGES | 💬 COMMENT ONLY ]
+- **Review Highlights:**
+  - **Strengths:** [What was well executed or clean in this change]
+  - **Key Risks:** [High-level summary of blocking items or structural flaws]
+
+---
+
+## 2. Findings Matrix
+
+| Severity | Category | File & Line | Summary of Concern |
+| :--- | :--- | :--- | :--- |
+| 🔴 **[blocking]** | Performance | `server/api/users.ts:42` | $N+1$ Database Query inside `.map()` loop |
+| 🟡 **[important]** | Error Handling | `composables/useAuth.ts:18` | Unhandled API rejection edge case |
+| 🟢 **[nit]** | Readability | `components/Card.vue:103` | Magic number `86400` used instead of constant |
+| 💡 **[suggestion]**| Architecture | `services/order.ts:12` | Extract inline mapping logic into dedicated mapper |
+
+---
+
+## 3. Detailed Review Feedback & Suggested Code
+
+### 🔴 [blocking] $N+1$ Query Bottleneck in User Fetch Loop
+- **File:** `server/api/users.ts` (Lines 42–48)
+- **Problem:** Database lookup `db.findProfile()` is triggered inside an array iteration, causing $N$ DB queries for $N$ users.
+
+**Current Implementation:**
+```typescript
+// BAD: Triggers N database round-trips
+const users = await db.getUsers();
+const detailedUsers = await Promise.all(
+  users.map(async (user) => {
+    const profile = await db.getProfile(user.id);
+    return { ...user, profile };
+  })
+);
+```
+
+**Recommended Refactor:**
+```typescript
+// GOOD: Batches DB fetch into a single query using join or IN clause
+const users = await db.getUsersWithProfiles();
+```
+
+### 🟡 [important] Missing Rejection Boundary
+- **File:** `composables/useAuth.ts` (Lines 18–22)
+- **Problem:** Unhandled error state when API network fails, leaving UI in an indefinite loading state.
+
+## 4. Final Review Checklist
+- [ ] No $N+1$ or blocking database performance issues remaining.
+- [ ] Business logic edge cases properly guarded and covered by unit/integration tests.
+- [ ] Code follows project architecture standards without introducing circular dependencies.
+
+## 5. Review Verdict & Next Steps
+- **Gatekeeper Status:** [ APPROVED | CHANGES REQUESTED ]
+- **Required Action Items Before Merge:**
+  1. [List each 🔴 blocking item with a one-line remediation]
+  2. [List each 🟡 important item recommended before merge]