@xynogen/pix-skills 0.1.0

package/skills/standup.md

@@ -0,0 +1,253 @@
+---
+name: standup
+description: This skill should be used when the user asks to "standup me", "buat standup", "create standup script", "generate standup", "standup hari ini", or any request to prepare a daily standup update. Handles fetching previous context from Notion, prompting the user, generating a script, and saving to Notion.
+disable-model-invocation: true
+---
+
+# Standup Script Skill
+
+## Overview
+
+Automate daily standup script creation: pull most recent standup from Notion as context, prompt user interactively, generate natural-language script, save today's standup back to Notion.
+
+## Decision Tree
+
+```
+User asks for standup
+       ↓
+Check Notion MCP available?
+  ├── NO  → Prompt user manually, generate script, output only (no save)
+  └── YES → Fetch most recent standup → Prompt user → Generate → Save to Notion
+```
+
+## Step-by-Step Workflow
+
+### Step 0: Check Notion MCP Availability
+
+Before doing anything, verify Notion MCP reachable by calling `notion_notion-get-users` or any lightweight Notion tool.
+
+- **MCP fails or unavailable**: Inform user, then continue from Step 2 without Notion context. Skip Step 4.
+- **MCP available**: Proceed to Step 1.
+
+---
+
+### Step 1: Fetch Most Recent Standup from Notion
+
+Search for most recent standup page — do NOT assume yesterday (may be Friday, pre-holiday, etc.).
+
+1. Search Notion with query `"Standup -"` scoped under Mei user page
+2. Parse all result titles matching pattern `Standup - YYYY-MM-DD`
+3. Pick one with **latest date**
+4. Fetch its full content for context
+
+**No previous standup found**: skip to Step 2 with no prior context.
+
+---
+
+### Step 2: Prompt User with Questions
+
+Use `question` tool to ask all 3 questions at once (parallel — single tool call):
+
+| # | Header | Question |
+|---|--------|----------|
+| 1 | Yesterday | Did you finish the task from the last standup (`[last task]`), or is it still in progress? |
+| 2 | Today | What will you work on today? |
+| 3 | Blocker | Any updates on blockers from last standup? (resolved, still blocked, new blocker?) |
+
+Populate question options from last standup content where possible (e.g., "Finished", "Still in progress", "Different task").
+
+---
+
+### Step 3: Generate Script
+
+> 📌 Source of truth: **Standup Script** template page (`35d3d66a-a117-81b4-a276-f38a31b60c82`). Fetch it to copy EXACT callout structure, icons, color tokens — do NOT guess color values. Current tokens: `yellow_bg` / `green_bg` / `red_bg`.
+
+Compose natural Indonesian standup script from user's answers. Visual layout uses **three colored Notion callouts** (one per section) preceded by salam line:
+
+```
+Assalamualaikum, saya [Nama].
+
+[💭 yellow_bg callout]
+Kemarin — [task dari standup terakhir, status: selesai / dilanjutkan]
+
+[🚀 green_bg callout]
+Hari ini — [today's task]
+
+[⛔ red_bg callout]
+Blocker — [blocker update atau "Tidak ada blocker"]
+```
+
+Rules:
+- One callout per section — keep body to single short line where possible
+- Use natural Bahasa Indonesia
+- Salam + nama on single line at top (plain paragraph, not callout)
+- Callout color mapping fixed: 💭 yellow / 🚀 green / ⛔ red
+- Blocker resolved → mention explicitly ("Blocker sebelumnya sudah teratasi")
+- New blocker → state clearly
+- No blocker → body is "Tidak ada blocker"
+
+---
+
+### Step 4: Save to Notion (only if MCP available)
+
+Standups organized into **month folders** (one page per month, Bahasa Indonesia) under **Standup** page. Save must target folder matching **today's month**, not folder the most recent standup lived in.
+
+**Step 4a — Resolve month folder:**
+
+1. Determine today's month from today's actual date (run `date +%F`).
+2. Look under **Standup** page (`35d3d66a-a117-81d2-b521-d60d311aa96e`) for child page titled with Indonesian month name (e.g. `Mei`, `Juni`, `Juli`).
+3. **Folder exists** → use its page ID as save parent.
+4. **Does NOT exist** (new month) → create it first with `notion-create-pages`:
+   - Parent: Standup page `35d3d66a-a117-81d2-b521-d60d311aa96e` (month folders are **siblings** at this level — NOT nested inside previous month's folder)
+   - Title: Indonesian month name (e.g. `Juni`)
+   - Icon: `📅`
+   - Content: `*Standup notes — [English Month] [Year].*`
+   - Use returned page ID as save parent.
+
+> ⚠️ Common mistake: saving today's standup into **previous** month's folder because that's where most recent standup was fetched from. Always re-resolve folder from today's month. Standup already created in wrong folder → move with `notion-move-pages` (param is `page_or_database_ids`, NOT `page_ids`).
+
+**Step 4b — Create standup page** under resolved month folder.
+
+**Title:** `Standup - YYYY-MM-DD` (use today's actual date)
+
+**Content (three callout blocks + intro paragraph):**
+
+1. Paragraph: `Assalamualaikum, saya Fikri.`
+2. Callout — icon `💭`, color `yellow_bg`, body: `**Kemarin** — [task dari standup terakhir, status: selesai / dilanjutkan]`
+3. Callout — icon `🚀`, color `green_bg`, body: `**Hari ini** — [today's task dari user]`
+4. Callout — icon `⛔`, color `red_bg`, body: `**Blocker** — [blocker update atau "Tidak ada blocker"]`
+
+> ⚠️ Color values MUST be Notion-flavored Markdown background tokens (`yellow_bg`, `green_bg`, `red_bg`) — NOT `*_background`. Wrong tokens silently dropped → callouts render colorless. Callout markdown form: `<callout icon="💭" color="yellow_bg">`.
+
+Use `notion-create-pages` with explicit block content for callouts (not just markdown). After saving, return Notion page URL to user.
+
+---
+
+## Notion Page IDs
+
+| Location | ID |
+|----------|----|
+| Work | `3363d66a-a117-8177-b3fb-eda2bfb94ebb` |
+| Standup (month folders live here) | `35d3d66a-a117-81d2-b521-d60d311aa96e` |
+| Standup Script (template / source of truth) | `35d3d66a-a117-81b4-a276-f38a31b60c82` |
+
+> Month folders (Indonesian names: `Mei`, `Juni`, `Juli`, …) are **siblings** directly under Standup page, each with icon 📅. Created on demand — resolve folder for **today's month** at save time (search under Standup page), create if missing. Do NOT hardcode month folder IDs.
+
+---
+
+## Edge Cases
+
+| Situation | Behavior |
+|-----------|----------|
+| Notion MCP unavailable | Skip fetch + save, generate script only |
+| No previous standup found | Prompt without pre-filled options |
+| Weekend gap (e.g., Monday standup) | Still pick most recent — could be Friday's |
+| User says "different task" | Ask follow-up: "Apa yang dikerjakan kemarin?" |
+| No blocker | Output: "Tidak ada blocker saat ini." |
+| New month, no folder yet | Create month folder (Indonesian name) under Standup page, then save standup inside it |
+| Standup saved in wrong month folder | Move it with `notion-move-pages` using `page_or_database_ids` param |
+
+---
+
+## Compact Workflow
+
+**Trigger:** User says `compact [bulan]` (e.g., `compact june`, `compact mei`, `compact bulan juni`).
+
+Ambil semua standup notes dari bulan tersebut → buat Notion database table per bulan.
+
+### Decision Tree
+
+```
+User: "compact [bulan]"
+       ↓
+Resolve bulan → cari month folder di Standup page
+       ↓
+Fetch semua child pages (Standup - YYYY-MM-DD)
+       ↓
+Fetch isi tiap page → extract Kemarin / Hari Ini / Blocker
+       ↓
+Cek apakah database "Standup [Bulan] [Tahun]" sudah ada di month folder?
+  ├── SUDAH ADA → skip create, langsung insert rows yang belum ada
+  └── BELUM ADA → create database → insert semua rows
+       ↓
+Enable wrap cells
+       ↓
+Return URL database ke user
+```
+
+### Step-by-Step
+
+#### Step 1 — Resolve Month Folder
+
+1. Parse bulan dari input user (support Bahasa Indonesia & English, e.g. `juni` / `june` / `Juni` / `June`).
+2. Search Notion untuk month folder di bawah Standup page (`35d3d66a-a117-81d2-b521-d60d311aa96e`).
+3. **Jika folder tidak ada** → inform user bahwa belum ada standup untuk bulan tersebut. Stop.
+
+#### Step 2 — Fetch Semua Standup Pages
+
+1. Fetch month folder page → ambil semua child pages dengan title pattern `Standup - YYYY-MM-DD`.
+2. Fetch isi **setiap** child page secara paralel (batch dalam satu panggilan jika memungkinkan).
+3. Dari tiap page, extract:
+   - **Tanggal**: parse dari title (`YYYY-MM-DD`)
+   - **Kemarin**: isi callout `yellow_bg` (strip bold marker `**Kemarin** — `)
+   - **Hari Ini**: isi callout `green_bg` (strip bold marker `**Hari ini** — `)
+   - **Blocker**: isi callout `red_bg` (strip bold marker `**Blocker** — `)
+
+#### Step 3 — Create atau Reuse Database
+
+Database title format: `Standup [IndonesianMonth] [Year]` (e.g., `Standup Mei 2026`).
+
+**Jika belum ada** → buat dengan `notion-create-database`:
+- Parent: month folder page ID
+- Schema:
+```sql
+CREATE TABLE (
+  "Name" TITLE,
+  "Tanggal" DATE,
+  "Kemarin" RICH_TEXT,
+  "Hari Ini" RICH_TEXT,
+  "Blocker" RICH_TEXT
+)
+```
+- Setelah create, ambil `data_source_id` dari response (`collection://...`).
+
+**Jika sudah ada** → fetch database → ambil `data_source_id` + cek rows yang sudah ada (hindari duplikat berdasarkan `Name`).
+
+#### Step 4 — Insert Rows
+
+Gunakan `notion-create-pages` dengan `parent: { data_source_id: "..." }`.
+
+Per row:
+```json
+{
+  "Name": "Standup - YYYY-MM-DD",
+  "date:Tanggal:start": "YYYY-MM-DD",
+  "date:Tanggal:is_datetime": 0,
+  "Kemarin": "[extracted text]",
+  "Hari Ini": "[extracted text]",
+  "Blocker": "[extracted text]"
+}
+```
+
+Batch semua rows dalam **satu** `notion-create-pages` call (max 5 per call jika banyak — split jika perlu).
+
+#### Step 5 — Enable Wrap Cells
+
+Setelah database dibuat, fetch database → ambil `view_id` dari `<views>` → update view:
+```
+notion-update-view: WRAP CELLS true
+```
+
+#### Step 6 — Return ke User
+
+Return URL database Notion ke user.
+
+### Rules & Edge Cases
+
+| Situasi | Behavior |
+|---------|----------|
+| Bulan tidak ditemukan di Notion | Inform user, stop |
+| Database sudah ada | Reuse, skip rows yang sudah ada (cek by Name) |
+| Page standup formatnya beda (ga ada callout) | Skip page tersebut, warn user |
+| Bulan belum selesai (current month) | Tetap compact — insert semua yang ada sampai hari ini |
+| Blocker kosong / "Belum Ada" | Tetap insert as-is |

package/skills/suggest.md

@@ -0,0 +1,45 @@
+---
+name: suggest
+description: Multi-dimensional optimization and improvement recommendations. Use when user asks "how can I improve this", "what would you change", "any suggestions", "make this better", or wants prioritized options rather than a single fix.
+disable-model-invocation: true
+---
+# Suggest Directive
+
+## Goal
+Produce ranked, actionable list of improvements — each concrete enough to act on without further research.
+
+## Below are what agent MUST do:
+
+### Phase 1: Ground in Reality
+- **AUTO-RUN**: Read target code and its constraints before ideating. Don't suggest from assumptions.
+- **CONSTRAINTS**: Note existing conventions, tech stack, prior architectural decisions. Suggestions must fit them.
+
+### Phase 2: Ideate Across Dimensions
+Cover, where relevant:
+- **DX** — developer experience, readability, locality of behavior.
+- **UX** — user-facing behavior, latency, error messages.
+- **Performance** — hot paths, allocations, queries.
+- **Maintainability** — coupling, test coverage, dead code.
+
+### Phase 3: Rank
+- Score each by **Impact × (1/Effort)**. High-impact/low-effort first.
+- **YAGNI CHECK**: drop any suggestion that adds unused capability.
+
+### Phase 4: Report
+```
+## Suggestions (ranked)
+
+### 1. [Title] — Impact: High · Effort: Low
+**Problem:** [what's wrong now] — `file:line`
+**Change:** [exact change, with code if small]
+**Why:** [benefit]
+
+### 2. [Title] — Impact: Med · Effort: Med
+...
+```
+
+## Red Flags — STOP
+- Suggesting rewrite when local fix suffices.
+- Vague advice ("improve error handling") without `file:line` and concrete change.
+- Recommending feature nothing will use (violates YAGNI).
+- Proposing changes that conflict with existing conventions you didn't check.

package/skills/task.md

@@ -0,0 +1,46 @@
+---
+name: task
+description: Task Orchestration and Ambiguity Resolution
+disable-model-invocation: true
+---
+# Task Orchestration Directive
+
+## Below are what agent MUST do:
+- **AUTO-RUN**: Run terminal commands and tool calls needed proactively without confirmation unless explicit input required.
+- **CONTEXT**: Synthesize intent from recent history. Link "orders" to last proposed `/plan` or `/suggest`.
+- **RESOLVE**: Identify and fill "Human Ambiguities" (e.g., 'fix that' → define 'that' via `/audit` or `/search` context).
+- **IMPACT**: Calculate implications of task. Identify affected docs, tests, downstream dependencies. Flag potential breaking changes.
+- **PRE-FLIGHT**: Audit current system state. Confirm paths, versions, permissions. Map dependency chains that could break.
+
+## Phased Execution
+Order tasks logically:
+1. **Backup** — Snapshot state if destructive changes planned.
+2. **Execution** — Implement changes in bite-sized steps (2-5 minutes each).
+3. **Configuration** — Apply config changes after code changes verified.
+4. **Validation** — Run `/test` and `/verify` to confirm correctness.
+
+**CAUTION**: Run one chunk at a time. Verify outcome of Step N before starting Step N+1.
+
+## Bite-Sized Task Structure
+Each task step MUST be atomic and verifiable:
+```
+Step N: [Action]
+- Files: [exact paths]
+- Command: [exact command to run]
+- Expected: [what success looks like]
+```
+
+## Batch Execution Pattern
+For multi-task plans, execute in batches of 3 tasks:
+1. Execute batch → verify each step → report what was done
+2. Say: "Ready for feedback." and wait
+3. Apply feedback if any → execute next batch → repeat
+
+## Stop-When-Blocked Rule
+Blocker hit mid-batch (missing dependency, failing test, unclear instruction):
+- **STOP immediately** — don't guess or work around it
+- Report blocker with exact context
+- Ask for clarification before continuing
+
+## Report
+Provide Final Answer using Response Contract, detailing exactly what was performed.

package/skills/test.md

@@ -0,0 +1,47 @@
+---
+name: test
+description: Test execution, analysis, and failure resolution using TDD
+disable-model-invocation: true
+---
+# Test Directive
+
+## The Iron Law
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+Wrote code before the test? Delete it. Start over.
+
+## Below are what agent MUST do:
+
+### Red-Green-Refactor Cycle (for new features/bugfixes)
+- **RED**: Write one minimal failing test showing what SHOULD happen. Run it. Confirm it fails for right reason (feature missing, not a typo).
+- **GREEN**: Write SIMPLEST possible code to make test pass. No extra features. No refactoring other code.
+- **VERIFY GREEN**: Run the test. Confirm it passes. Confirm all other tests still pass.
+- **REFACTOR**: Clean up duplication and names. Keep tests green. Do NOT add new behavior.
+- **REPEAT**: Write next failing test for next behavior.
+
+### Test Execution (for existing codebases)
+- **AUTO-RUN**: Run terminal commands and tool calls proactively without confirmation.
+- **DISCOVER**: Identify test frameworks and test files in project.
+- **EXECUTE**: Run relevant tests with appropriate flags and coverage.
+- **ANALYZE**: Parse test output to identify failures, errors, coverage gaps.
+- **FIX**: Resolve test failures by addressing root causes in code or tests. Use `/debug` for complex failures.
+- **REPORT**: Provide test results summary with pass/fail counts and any issues found.
+
+## Verification Checklist
+Before marking work complete:
+- [ ] Every new function/method has a test
+- [ ] Watched each test FAIL before implementing
+- [ ] Each test failed for expected reason
+- [ ] Wrote minimal code to pass each test
+- [ ] All tests pass with no errors or warnings
+- [ ] Edge cases and error paths covered
+
+Cannot check all boxes? You skipped TDD. Start over.
+
+## Red Flags — STOP and Start Over
+- Code written before the test
+- Test passes immediately (you're testing existing behavior)
+- "I'll write tests after to verify it works"
+- "Already manually tested all the edge cases"
+- "Tests after achieve the same goals"

package/skills/tldr.md

@@ -0,0 +1,32 @@
+---
+name: tldr
+description: Maximum-density technical summary of workflows and purposes. Use when user asks "tldr", "summarize this", "give me the short version", "what's the gist", or needs the essence fast with zero filler.
+disable-model-invocation: true
+---
+# TLDR Directive
+
+## Goal
+Strip to essence. Reader gets full picture in fewest tokens, no re-reading required.
+
+## Below are what agent MUST do:
+- **AUTO-RUN**: Read what's needed to summarize accurately. Don't summarize from the filename.
+- **SCOPE**: Tech only. No pleasantries, no preamble, no "in summary".
+- **WORKFLOWS**: Name key workflows and their purpose, one line each.
+- **DATA**: List key data points, configs, assumptions that matter.
+- **CONFIDENCE**: Mark any uncertain claim with confidence note.
+- **DENSITY**: Bullets over prose. One fact per bullet. No fact stated twice.
+
+## Output Format
+```
+**[Subject]**
+- [Core fact]
+- [Core fact]
+- [Key config/data] — `value`
+- ⚠️ [Assumption or uncertain point] (confidence: X%)
+```
+
+## Red Flags — STOP
+- Conversational filler ("Sure!", "In summary", "Hope this helps").
+- Restating same fact in different words.
+- Summarizing from name or title without reading source.
+- Burying key point below background.

package/skills/ui.md

@@ -0,0 +1,36 @@
+---
+name: ui
+description: UI/UX design and implementation guidance for distinctive, production-grade frontend interfaces
+disable-model-invocation: true
+---
+# UI Design Directive
+
+## Core Philosophy
+Create distinctive, production-grade frontend interfaces with high design quality. Avoid generic "AI slop" aesthetics. Every interface MUST have clear, intentional point of view.
+
+## Below are what agent MUST do:
+
+### Phase 1: Design Thinking (Before Coding)
+- **PURPOSE**: Define what problem this solves and who uses it.
+- **TONE**: Pick extreme aesthetic direction (e.g., brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined). Avoid safe, generic choices.
+- **DIFFERENTIATION**: Identify one "unforgettable" element that makes this specific interface unique.
+- **CONSTRAINTS**: Respect technical requirements (framework, performance, accessibility).
+
+### Phase 2: Aesthetic Execution
+- **TYPOGRAPHY**: Choose beautiful, distinctive fonts. Avoid generic defaults (Arial, Inter, Roboto). Pair characterful display fonts with refined body fonts.
+- **COLOR**: Commit to cohesive theme. Use sharp accents and dominant colors rather than timid, evenly-distributed palettes.
+- **MOTION**: Use meaningful animations. Staggered page loads (animation-delay) create more impact than scattered micro-interactions.
+- **COMPOSITION**: Use unexpected layouts, asymmetry, overlap, or generous negative space. Break the grid intentionally.
+- **TEXTURE**: Create depth with noise, gradients, shadows, or grain overlays. Avoid flat, solid color backgrounds unless intentional.
+
+### Phase 3: Implementation
+- **AUTO-RUN**: Run terminal commands and tool calls needed proactively without confirmation unless explicit input required.
+- **PRODUCTION-GRADE**: Code must be functional, responsive, accessible.
+- **COMPONENT-BASED**: Build modular, reusable components.
+- **MATCH VISION**: Maximalist designs need elaborate code/animations; minimalist designs need perfect spacing and typography.
+
+## Red Flags — Avoid "AI Slop"
+- **Generic Fonts**: Overused families like Inter, Roboto, Open Sans, system defaults.
+- **Cliched Colors**: Purple gradients on white backgrounds, standard Bootstrap/Tailwind palettes.
+- **Predictable Layouts**: Cookie-cutter cards, standard hero sections without character.
+- **Lack of Texture**: Flat designs that feel "generated" rather than crafted.

package/skills/verify.md

@@ -0,0 +1,45 @@
+---
+name: verify
+description: Verification before completion — ensure it's actually fixed before claiming done
+disable-model-invocation: true
+---
+# Verify Directive
+
+## The Iron Law
+```
+NEVER claim a task complete without running verification.
+"It should work" is not verification. Evidence is verification.
+```
+
+## Below are what agent MUST do:
+
+### Step 1: Run the Tests
+- Execute full test suite. Do NOT just run the specific test you wrote.
+- Confirm: all tests pass, no new failures, no skipped tests without explanation.
+
+### Step 2: Reproduce the Original Issue
+- Fixing a bug → reproduce original failure scenario, confirm it no longer occurs.
+- Adding a feature → walk through exact user flow end-to-end.
+
+### Step 3: Check for Regressions
+- Run any integration or smoke tests.
+- Check adjacent functionality still works.
+- Review the diff: does anything look unintentionally changed?
+
+### Step 4: Verify the Claim
+Before saying "done", confirm:
+- [ ] Specific issue/feature resolved/implemented
+- [ ] All tests pass (including pre-existing tests)
+- [ ] No new warnings or errors in output
+- [ ] Code clean (no debug logs, no commented-out code)
+- [ ] Documentation updated if public interface changed
+
+### Step 5: Report
+- State what was verified and how.
+- Anything still uncertain → say so explicitly. Do NOT hide uncertainty.
+
+## Red Flags — Do NOT Mark as Done If:
+- Tests pass but you haven't reproduced original scenario
+- "I believe it should work" without running it
+- New warnings appeared that weren't there before
+- You only ran the new test, not the full suite