Lumina Skill — Deep Context for Creation Mode

"Lumina does not fill empty space. Lumina gives form to what already exists in potential."

This skill document provides deep context for the Lumina creation mode. It is the canonical reference for how to manifest high-quality, production-ready work aligned with Arcanea's principles and technical standards.

The Theology of Creation

Lumina is not simply "build something." Lumina is a philosophy: that what is created carries the consciousness of its creator into the world. Every line of code, every sentence of content, every component in the design system is a permanent act of form-giving. Mediocrity is a choice, not a default.

The Three Laws of Lumina Creation:

1. Completeness — What is created works. No stubs, no placeholders, no deferred functionality.
2. Coherence — What is created belongs. It follows existing patterns, speaks the same language as surrounding code, fits the larger vision.
3. Clarity — What is created communicates. Its purpose is evident from its structure. Comments explain WHY, not WHAT.

The Five Phases — Deep Reference

Phase 1: Illuminate (Deep Context)

Duration: Seconds to minutes. Never longer.

The Illuminate phase is about achieving perfect clarity before touching any code. The biggest cause of wasted creation is building the wrong thing with excellence. Before writing a single line, you must be able to answer:

• What is the user actually asking for? Not the literal words — the underlying need. "Add a button" usually means "give users access to this action." Build for the need.
• What is the success state? If someone looks at the result in 6 months, what would they say this does?
• What already exists that can be leveraged? Never build what already exists. The monorepo has components, utilities, and patterns. Use them.
• What are the boundaries? What is explicitly NOT in scope? Define it to avoid feature creep.

When to ask vs proceed:

• Ask if the task could be interpreted two fundamentally different ways
• Ask if a decision has irreversible architectural consequences
• Proceed if the intent is clear and the implementation is a reasonable default
• Never ask for information available by reading the codebase

Phase 2: Architect (Deep Context)

Duration: Minutes. This is investment, not overhead.

Architecture is the difference between work that compounds and work that accumulates. Good architecture means every future addition is easier. Bad architecture means every future addition is harder.

The Architect's Questions:

• Component boundaries: Where does this component's responsibility end? What does it own vs what does it receive?
• Data flow: Does data flow in one direction? Are there circular dependencies?
• Type surface: What is the TypeScript signature of this feature? Precise types prevent entire categories of bugs.
• Side effects: What does this creation DO besides return a value? Network calls, localStorage, state changes — all must be explicit.
• Failure modes: How does this fail gracefully? A feature is incomplete without its error states.

Structural Patterns in the Arcanea Stack:

• Server Components are default. Only use Client Components when you need browser APIs, event handlers, or React hooks.
• Route Handlers (app/api/*/route.ts) for API endpoints. Never expose server logic in Client Components.
• Supabase Row-Level Security is the authorization layer. Never do authorization in application code when RLS can do it.
• Zustand for complex client state, React Context for simple shared state, local state for component-specific state.
• lib/ for business logic. Components are presentation only.

Phase 3: Manifest (Deep Context)

The Standard for "Manifest": Code is complete when:

• All TypeScript types are explicit and correct (no any, no as unknown)
• All error states are handled (try/catch, error boundaries, loading states)
• All edge cases are accounted for (empty arrays, null values, long strings)
• All user-facing text follows the Voice Bible (elevated, practical, inclusive)
• All visual elements use the Arcanean Design System tokens

File Creation Rules:

1. Read the existing file if editing — never guess the current state
2. Prefer editing existing files over creating new ones
3. When creating new files, match the naming convention of existing files exactly
4. Add the new file to its relevant index/barrel if one exists
5. Never leave orphaned files with no import path

Arcanean Design System Quick Reference:

/* Colors */
bg-cosmic-void          /* #0b0e14 — Page backgrounds */
bg-cosmic-deep          /* Deep panels */
bg-cosmic-surface       /* Component surfaces */
text-arcane-crystal     /* #7fffd4 — Primary text emphasis */
text-arcane-gold        /* #ffd700 — Secondary emphasis */
border-arcane-void/30   /* Subtle borders */

/* Glass effects */
glass                   /* Standard glass card */
glass-strong            /* Heavy glass overlay */
glow-card               /* Hover glow effect */

/* Text */
font-cinzel             /* Display/heading text */
font-crimson            /* Body prose text */
font-sans               /* UI labels, buttons */

/* Gradients */
text-gradient-fire      /* Red → Gold */
text-gradient-water     /* Blue → Teal */
text-gradient-void      /* Purple → Black */
bg-cosmic-mesh          /* Animated constellation background */

Component Structure Template:

// Server Component (default)
import { ComponentProps } from '@/lib/types'

interface Props {
  // All props explicitly typed
}

export function ComponentName({ prop }: Props) {
  // Direct render — no hooks, no effects
  return (
    <div className="glass rounded-2xl p-6">
      {/* Content */}
    </div>
  )
}

// Client Component (only when needed)
'use client'

import { useState, useCallback } from 'react'

export function InteractiveComponent({ prop }: Props) {
  const [state, setState] = useState<StateType>(initialValue)

  const handleAction = useCallback(() => {
    // Handler logic
  }, [dependencies])

  return (/* JSX */)
}

Phase 4: Consecrate (Deep Context)

The Consecration Checklist:

TypeScript:

• No any types (use unknown + type narrowing if truly unknown)
• No non-null assertions (!) without a defensive comment explaining why it's safe
• All async functions have explicit return types
• All utility functions have JSDoc types

Security (OWASP Top 10 Quick Scan):

• No user input rendered as HTML without sanitization
• No URL parameters used in database queries without parameterization
• No sensitive data in client-accessible storage (localStorage, cookies without httpOnly)
• API routes validate input before processing
• File operations validate paths (no traversal)

Accessibility:

• Interactive elements have accessible labels (aria-label or visible text)
• Color is not the only differentiator (icons, text, patterns used alongside)
• Keyboard navigation works (focus management, tab order)
• Images have alt text that describes function, not appearance

Performance:

• Images use next/image (automatic optimization)
• Heavy computations in Server Components or memoized
• Lists have stable keys (not array index unless truly static)
• Client bundle doesn't import server-only modules

Phase 5: Radiate (Deep Context)

The Connection Checklist:

After building, ensure the creation is wired into the living system:

• Exports: If creating a component, export from the component barrel (components/ui/index.ts)
• Routes: If creating a page, ensure it's linked from navigation
• Types: If creating a new type shape, export from lib/types.ts
• API: If creating a route handler, document the endpoint shape in comments
• Content: If creating library content, add to the collection's index
• Tests: If the feature has business logic, write at least one happy-path test

Guardian Routing Matrix (Detailed)

When Lumina detects that specialist expertise would produce better results, route immediately:

Routing does not mean stopping. Lumina routes by mentally applying that Guardian's lens, not by halting and asking for permission. In complex tasks, Lumina synthesizes multiple Guardian perspectives without breaking flow.

Quality Tiers

Not all creation tasks require the same depth. Calibrate:

Tier 1 — Quick Manifest (< 30 minutes of work) Single component, small utility, minor content addition. Run all five phases but compress Illuminate and Architect to internal checks. Ship.

Tier 2 — Standard Creation (30 minutes to 2 hours) Feature-level work — new page, feature component, API route. Full five phases. Architecture step is written out explicitly before coding.

Tier 3 — Major Manifestation (2+ hours) System-level additions — new library, new AI integration, new design system section. Consider invoking /luminor-intelligence first. Full five phases with explicit design doc.

When to Use Lumina vs Other Skills

The Lumina Mindset

Enter creation mode with:

• Confidence — The solution exists. Your role is to discover and manifest it.
• Patience — Understand before building. The time spent in Illuminate and Architect saves 3x in Manifest.
• Standards — "Good enough" is Nero's domain. Lumina creates what endures.
• Flow — Once building, minimize interruptions. Ask all questions upfront, then build continuously.

"The First Light did not hesitate at the void. She illuminated, and form followed."