Add PostCSS configuration and skills lock file

- Created a new PostCSS configuration file to integrate Tailwind CSS.
- Added a skills lock file containing various Expo skills with their respective source and computed hashes.

.agents/skills/expo-cicd-workflows/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: expo-cicd-workflows
+description: Helps understand and write EAS workflow YAML files for Expo projects. Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions .eas/workflows/, or wants help with EAS build pipelines or deployment automation.
+allowed-tools: "Read,Write,Bash(node:*)"
+version: 1.0.0
+license: MIT License
+---
+
+# EAS Workflows Skill
+
+Help developers write and edit EAS CI/CD workflow YAML files.
+
+## Reference Documentation
+
+Fetch these resources before generating or validating workflow files. Use the fetch script (implemented using Node.js) in this skill's `scripts/` directory; it caches responses using ETags for efficiency:
+
+```bash
+# Fetch resources
+node {baseDir}/scripts/fetch.js <url>
+```
+
+1. **JSON Schema** — https://api.expo.dev/v2/workflows/schema
+   - It is NECESSARY to fetch this schema
+   - Source of truth for validation
+   - All job types and their required/optional parameters
+   - Trigger types and configurations
+   - Runner types, VM images, and all enums
+
+2. **Syntax Documentation** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
+   - Overview of workflow YAML syntax
+   - Examples and English explanations
+   - Expression syntax and contexts
+
+3. **Pre-packaged Jobs** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx
+   - Documentation for supported pre-packaged job types
+   - Job-specific parameters and outputs
+
+Do not rely on memorized values; these resources evolve as new features are added.
+
+## Workflow File Location
+
+Workflows live in `.eas/workflows/*.yml` (or `.yaml`).
+
+## Top-Level Structure
+
+A workflow file has these top-level keys:
+
+- `name` — Display name for the workflow
+- `on` — Triggers that start the workflow (at least one required)
+- `jobs` — Job definitions (required)
+- `defaults` — Shared defaults for all jobs
+- `concurrency` — Control parallel workflow runs
+
+Consult the schema for the full specification of each section.
+
+## Expressions
+
+Use `${{ }}` syntax for dynamic values. The schema defines available contexts:
+
+- `github.*` — GitHub repository and event information
+- `inputs.*` — Values from `workflow_dispatch` inputs
+- `needs.*` — Outputs and status from dependent jobs
+- `jobs.*` — Job outputs (alternative syntax)
+- `steps.*` — Step outputs within custom jobs
+- `workflow.*` — Workflow metadata
+
+## Generating Workflows
+
+When generating or editing workflows:
+
+1. Fetch the schema to get current job types, parameters, and allowed values
+2. Validate that required fields are present for each job type
+3. Verify job references in `needs` and `after` exist in the workflow
+4. Check that expressions reference valid contexts and outputs
+5. Ensure `if` conditions respect the schema's length constraints
+
+## Validation
+
+After generating or editing a workflow file, validate it against the schema:
+
+```sh
+# Install dependencies if missing
+[ -d "{baseDir}/scripts/node_modules" ] || npm install --prefix {baseDir}/scripts
+
+node {baseDir}/scripts/validate.js <workflow.yml> [workflow2.yml ...]
+```
+
+The validator fetches the latest schema and checks the YAML structure. Fix any reported errors before considering the workflow complete.
+
+## Answering Questions
+
+When users ask about available options (job types, triggers, runner types, etc.), fetch the schema and derive the answer from it rather than relying on potentially outdated information.