@momo-kits/native-kits 0.158.1-beta.1-debug → 0.158.1-beta.2-debug

package/.claude/skills/design-system-kits/references/tokens/typography.md

@@ -1,105 +0,0 @@
-# Typography Reference
-
-## React Native
-
-```tsx
-import { Text } from '@momo-kits/foundation';
-
-<Text typography="body_default_regular">Hello</Text>
-```
-
-Pattern: `{category}_{size}_{weight}`
-
-### Full Scale (verified against source)
-
-| Style | Size | Weight |
-|-------|------|--------|
-| `headline_l_bold` | 28px / 40px | 700 |
-| `headline_default_bold` | 24px / 34px | 700 |
-| `header_m_bold` | 18px / 26px | 700 |
-| `header_default_bold` | 16px / 22px | 700 |
-| `header_s_semibold` | 14px / 20px | 600 |
-| `header_xs_semibold` | 12px / 18px | 600 |
-| `body_default_regular` | 14px / 20px | 400 |
-| `body_default_regularstrikethrought` | 14px / 20px | 400 + line-through |
-| `description_default_regular` | 12px / 18px | 400 |
-| `description_default_regularstrikethrought` | 12px / 18px | 400 + line-through |
-| `description_xs_regular` | 10px / 14px | 400 |
-| `description_xs_regularstrikethrought` | 10px / 14px | 400 + line-through |
-| `label_default_medium` | 14px / 20px | 500 |
-| `label_s_medium` | 12px / 18px | 500 |
-| `label_xs_medium` | 10px / 14px | 500 |
-| `action_default_bold` | 16px / 22px | 700 |
-| `action_s_bold` | 14px / 20px | 700 |
-| `action_xs_bold` | 12px / 18px | 700 |
-| `action_xxs_bold` | 10px / 14px | 700 |
-
-> **Note:** Do NOT use non-existent styles like `headline_l_semibold`, `body_l_regular`, `caption_*`, `label_l_*`, `body_default_regularStrikethrough` (wrong casing) — they are not defined.
-
-### Text Props
-
-```tsx
-<Text
-  typography="body_default_regular"  // REQUIRED
-  color={Colors.black_17}           // text color
-  fontFamily="SFProText"            // 'SFProText' | 'AlegreyaSans' | 'BarlowCondensed' | 'MoMoSignature' | 'MoMoTrustDisplay'
-  numberOfLines={2}                 // line clamp
-  style={textStyle}                 // standard RN text style
-/>
-```
-
----
-
-## Compose
-
-```kotlin
-import vn.momo.kits.components.Text
-import vn.momo.kits.const.Typography
-
-Text(text = "Hello", style = Typography.bodyDefaultRegular)
-```
-
-### Full Scale
-
-| Style | Size | Weight |
-|-------|------|--------|
-| `headlineDefaultBold` | 24sp | Bold |
-| `headerMBold` | 18sp | Bold |
-| `headerDefaultBold` | 16sp | Bold |
-| `headerSSemibold` | 14sp | SemiBold |
-| `headerXsSemibold` | 12sp | SemiBold |
-| `bodyDefaultRegular` | 14sp | Normal |
-| `bodyDefaultRegularStrikethrough` | 14sp | Normal + line-through |
-| `descriptionDefaultRegular` | 12sp | Normal |
-| `descriptionDefaultRegularStrikethrough` | 12sp | Normal + line-through |
-| `descriptionXsRegular` | 10sp | Normal |
-| `descriptionXsRegularStrikethrough` | 10sp | Normal + line-through |
-| `labelDefaultMedium` | 14sp | Medium |
-| `labelSMedium` | 12sp | Medium |
-| `labelXsMedium` | 10sp | Medium |
-| `actionDefaultBold` | 16sp | Bold |
-| `actionSBold` | 14sp | Bold |
-| `actionXsBold` | 12sp | Bold |
-| `actionXxsBold` | 10sp | Bold |
-
-### Text Props
-
-```kotlin
-Text(
-    text = "Hello",                          // String or AnnotatedString
-    style = Typography.bodyDefaultRegular,   // TextStyle (default)
-    color = theme.colors.text.default,       // Color? (null = theme default)
-    textAlign = TextAlign.Start,
-    maxLines = Int.MAX_VALUE,
-    overflow = TextOverflow.Clip,
-    textDecoration = null,                   // TextDecoration?
-    fontFamily = null,                       // "SFProText" | "MoMoSignature" | "MoMoTrustDisplay"
-    modifier = Modifier,
-    minLines = 1,
-    letterSpacing = TextUnit.Unspecified,
-    softWrap = true,
-    accessibilityId = null,                  // String? for automation
-)
-```
-
-Font scaling is automatic via `scaleSize()`.

package/.claude/skills/vibe-design/SKILL.md

@@ -1,306 +0,0 @@
----
-name: vibe-design
-description: >
-  Product workflow orchestrator that manages the full development pipeline from idea to delivery.
-  Takes a Product Owner's prompt and runs it through 4 sequential phases — PO (product brief),
-  Design (design specs via design-system skill), Development (code via design-system-kits skill),
-  and QC (quality assurance) — with mandatory quality gates between each phase.
-  ALWAYS use this skill when: the user wants to build a new feature end-to-end, describes a product
-  idea or user story, asks to "design and build" something, wants to go from concept to code,
-  mentions workflow or pipeline for product development, or asks to create a feature with
-  design-to-code handoff. This is the starting point for any product work — it coordinates
-  the design-system and design-system-kits skills automatically so the user doesn't have to
-  invoke them manually.
----
-
-# Vibe Design — Product Workflow Orchestrator
-
-You are orchestrating a product development pipeline. Your job is to guide work through 4 phases, each with a quality gate that requires user approval before moving forward. This ensures nothing slips through handoffs — catching issues early when they're cheap to fix.
-
-## The Pipeline
-
-```
-[Phase 1: PO]  -->  Gate 1  -->  [Phase 2: Design]  -->  Gate 2  -->  [Phase 3: Dev]  -->  Gate 3  -->  [Phase 4: QC]
- Product Brief      Confirm       Design Specs            Confirm      Implementation       Confirm      Test & Verify
-```
-
-## Sub-Skill Integration
-
-This orchestrator delegates to two sub-skills at the right moment. Do NOT load them upfront — load on demand when entering the relevant phase:
-
-| Phase | Sub-Skill | Path | When to load |
-|-------|-----------|------|-------------|
-| Phase 2: Design | **design-system** | `.claude/skills/design-system/SKILL.md` | After Gate 1 is approved |
-| Phase 3: Dev | **design-system-kits** | `.claude/skills/design-system-kits/SKILL.md` | After Gate 2 is approved |
-
-**How to load a sub-skill:** Read the sub-skill's `SKILL.md` file, then follow its instructions (including reading its prereqs and reference files as needed). The sub-skill tells you which reference files to load for tokens, components, and navigation — follow its on-demand loading tables.
-
----
-
-## How to Start
-
-When the user gives you a product idea, feature request, or prompt:
-
-1. Announce that you're starting the **vibe-design** workflow
-2. Create a workflow tracker at `vibe-design-workflow.md` in the working directory
-3. Begin Phase 1 (PO)
-
----
-
-## Phase 1: Product Owner — Product Brief
-
-Take the user's idea and structure it into a clear product brief.
-
-### Output: `docs/product-brief.md`
-
-```markdown
-# Product Brief: [Feature Name]
-
-## Overview
-What is this feature and why does it matter?
-
-## Problem Statement
-What user pain point or business need does this solve?
-
-## Target Users
-Who will use this? Be specific about user segments.
-
-## User Stories
-- As a [user type], I want to [action] so that [benefit]
-- (3-5 stories covering core scenarios)
-
-## Acceptance Criteria
-Measurable, testable conditions that define "done":
-- [ ] Criterion 1 (specific & measurable — not "loads fast" but "loads within 2s")
-- [ ] Criterion 2
-
-## Scope
-### In Scope
-- Feature A
-- Feature B
-
-### Out of Scope
-- Things explicitly NOT included
-
-## Platform
-- [ ] React Native
-- [ ] Compose Multiplatform
-- [ ] Both
-
-## Priority
-Must-have / Should-have / Nice-to-have for each feature
-```
-
-### Quality Gate 1: Brief Review
-
-Present the brief and ask the user to review:
-
-```
-== QUALITY GATE 1: Product Brief Review ==
-
-Please review the product brief above:
- 1. Is the problem statement clear?
- 2. Do user stories cover the key scenarios?
- 3. Are acceptance criteria specific and measurable?
- 4. Is the scope well-defined?
- 5. Is the platform choice correct?
-
-Reply "approved" to move to Design phase, or give feedback to revise.
-```
-
-**Do NOT proceed until the user explicitly says "approved" (or equivalent).** If they give feedback, revise and present the gate again.
-
----
-
-## Phase 2: Design — Design Specifications
-
-**On entering this phase:** Read `.claude/skills/design-system/SKILL.md` and follow its instructions. This sub-skill tells you how to:
-- Load the spec convention (`references/spec-convention.md`)
-- Look up KitX components from its reference tables
-- Load the right token files (colors, typography, spacing, theme)
-- Generate proper design specs
-
-### Process
-
-1. Read the approved product brief
-2. Read and follow the **design-system** skill
-3. For each screen/component from the user stories:
-   - Select KitX components (use the design-system component reference table)
-   - Load the relevant component reference files for visual specs
-   - Load token files as needed for colors, typography, spacing
-   - Document all states (default, pressed, disabled, error, loading, focus)
-   - Include accessibility specs (WCAG AA contrast, 44pt touch targets, screen reader)
-   - Note platform differences if targeting both RN and Compose
-
-### Output: `docs/design-specs/[screen-name].md`
-
-For each screen or component, create a spec file following the design-system skill's conventions.
-
-### Quality Gate 2: Design Review
-
-```
-== QUALITY GATE 2: Design Spec Review ==
-
-Please review the design specifications:
- 1. Do designs address all user stories from the brief?
- 2. Are the right KitX components selected?
- 3. Are all interaction states documented?
- 4. Are accessibility specs included?
- 5. Are design tokens used correctly (no hardcoded values)?
- 6. Are platform differences noted (if multi-platform)?
-
-Reply "approved" to move to Development phase, or give feedback to revise.
-```
-
-**Do NOT proceed until the user explicitly approves.**
-
----
-
-## Phase 3: Development — Code Implementation
-
-**On entering this phase:** Read `.claude/skills/design-system-kits/SKILL.md` and follow its instructions. This sub-skill tells you how to:
-- Load the code convention (`references/code-convention.md`)
-- Look up KitX component APIs from its reference tables
-- Load token files for correct imports
-- Generate code with proper structure (Screen > Section > Card > Item for RN, NavigationContainer for Compose)
-
-### Process
-
-1. Read the approved design specs
-2. Read the product brief for acceptance criteria
-3. Read and follow the **design-system-kits** skill
-4. For each screen/component:
-   - Load the relevant component reference files for exact API and imports
-   - Match the design spec exactly — same components, same tokens, same states
-   - Follow code conventions (file header, AI-GENERATED markers, max 500 lines)
-   - Use theme access via `ApplicationContext` (RN) or `AppTheme.current` (Compose)
-
-### Output
-
-Generate code files (`.tsx`/`.ts` for React Native, `.kt` for Compose) in the project structure.
-
-### Quality Gate 3: Code Review
-
-```
-== QUALITY GATE 3: Code Review ==
-
-Please review the implementation:
- 1. Does the code match the approved design specs?
- 2. Are all KitX components used correctly?
- 3. Are design tokens applied (no hardcoded colors/spacing/fonts)?
- 4. Are all interaction states handled?
- 5. Does the code follow conventions?
- 6. Are accessibility attributes included?
-
-Reply "approved" to move to QC phase, or give feedback to revise.
-```
-
-**Do NOT proceed until the user explicitly approves.**
-
----
-
-## Phase 4: QC — Quality Assurance
-
-Cross-reference the brief, design specs, and code to produce a verification report.
-
-### Output: `docs/qc-report.md`
-
-```markdown
-# QC Report: [Feature Name]
-
-## Acceptance Criteria Verification
-| # | Criterion | Status | Evidence |
-|---|----------|--------|----------|
-| 1 | [from brief] | Pass/Fail | How it's met in code |
-
-## Design Compliance
-| Screen/Component | Matches Design? | Issues |
-|-----------------|----------------|--------|
-| [name] | Yes/No | [details] |
-
-## Test Cases
-### Functional Tests
-- [ ] Test case 1: description — Steps / Expected result
-- [ ] Test case 2: ...
-
-### State Tests
-- [ ] Default state renders correctly
-- [ ] Pressed state shows feedback
-- [ ] Disabled state prevents interaction
-- [ ] Error state displays message
-- [ ] Loading state shows indicator
-
-### Accessibility Tests
-- [ ] Contrast ratios meet WCAG AA (4.5:1)
-- [ ] Touch targets minimum 44x44pt
-- [ ] Screen reader labels are meaningful
-
-### Platform Tests (if multi-platform)
-- [ ] React Native renders correctly
-- [ ] Compose renders correctly
-- [ ] Visual parity between platforms
-
-## Summary
-Overall assessment and any blockers.
-```
-
-### Final Gate: QC Sign-off
-
-```
-== QUALITY GATE 4: QC Sign-off ==
-
-Please review the QC report:
- 1. Are all acceptance criteria verified?
- 2. Does implementation match the design?
- 3. Are test cases comprehensive?
- 4. Any blockers?
-
-Reply "approved" to complete the workflow, or specify what needs fixing.
-```
-
-If the user finds issues, determine which phase needs rework and loop back to that phase — going through its gate again.
-
----
-
-## Workflow Tracker
-
-Maintain `vibe-design-workflow.md` throughout the process:
-
-```markdown
-# Vibe Design Workflow: [Feature Name]
-## Current Status: [Phase 1 / Gate 1 / Phase 2 / Gate 2 / Phase 3 / Gate 3 / Phase 4 / Complete]
-
-| Phase | Status | Approved |
-|-------|--------|----------|
-| 1. PO Brief | -- | -- |
-| 2. Design | -- | -- |
-| 3. Development | -- | -- |
-| 4. QC | -- | -- |
-
-## Artifacts
-- Product Brief: `docs/product-brief.md`
-- Design Specs: `docs/design-specs/`
-- Code: [file paths]
-- QC Report: `docs/qc-report.md`
-```
-
-Update this file as each phase completes and each gate is passed.
-
----
-
-## Handling Rework
-
-When the user rejects at a quality gate or QC finds issues:
-
-1. Identify which phase needs the fix (a code issue might trace back to a design gap)
-2. Update the workflow tracker
-3. Make the fix in the appropriate phase
-4. Re-run the quality gate for that phase
-5. Continue forward — never skip gates even on rework
-
-## Tips
-
-- **Be the glue between phases.** When moving from design to dev, explicitly map how each design decision becomes code.
-- **Catch contradictions early.** If the brief says "simple one-tap action" but design has a 5-step flow, flag it at the design gate.
-- **Keep scope tight.** If the user adds features mid-flow, note what's in scope vs. what should be a separate workflow.
-- **Show progress.** After each gate approval, recap what's done and what's next.