@oisincoveney/pipeline 3.0.0 → 3.1.0

package/.agents/skills/canonicalize-tailwind/SKILL.md

@@ -1,86 +0,0 @@
----
-name: canonicalize-tailwind
-description: Sort, normalize, deduplicate, and resolve conflicting Tailwind utility classes.
----
-
-# Canonicalize Tailwind
-
-Use this when the user wants to clean up, canonicalize, or normalize Tailwind class lists.
-
-## Activation
-
-### Use For
-
-- cleaning up Tailwind classes
-- canonicalizing Tailwind utility lists
-- sorting, normalizing, or deduplicating Tailwind classes
-- resolving conflicting Tailwind utilities in class strings
-
-### Do Not Use For
-
-- new design or layout work
-- component extraction or code organization
-- visual changes rather than class-list cleanup
-
-## Load First
-
-- No companion modules are required.
-
-## Progress Updates
-
-Keep the user informed so longer runs do not look stuck.
-
-- One-line status update before each major phase.
-- Concrete and lightweight: what you are doing now, not verbose logs.
-
-## Workflow
-
-1. Identify Tailwind class strings in the requested files or components.
-2. Canonicalize class strings with `npx @tailwindcss/cli canonicalize`.
-3. Apply changed class strings back to the source.
-4. Run the project's formatter or relevant checks when available.
-
-## Commands
-
-- Use `npx @tailwindcss/cli canonicalize` to clean up Tailwind class lists — collapses shorthands (`mt-2 mr-2 mb-2 ml-2` → `m-2`), resolves overrides (`py-3 p-1 px-3` → `p-3`), canonicalizes arbitrary values to named utilities, and sorts classes; pass `--css path/to/input.css` if the project uses a custom CSS entry file
-
-  Single class string:
-
-  ```sh
-  npx @tailwindcss/cli canonicalize "mt-2 mr-2 mb-2 ml-2"
-  # m-2
-  ```
-
-  Multiple class strings as positional args (each returned on its own line):
-
-  ```sh
-  npx @tailwindcss/cli canonicalize "py-3 p-1 px-3" "mt-2 mr-2 mb-2 ml-2"
-  # p-3
-  # m-2
-  ```
-
-  Pipe class strings via stdin (one per line):
-
-  ```sh
-  echo "py-3 p-1 px-3\nmt-2 mr-2 mb-2 ml-2" | npx @tailwindcss/cli canonicalize
-  # p-3
-  # m-2
-  ```
-
-  Use `--format json` or `--format jsonl` for structured output with `input`/`output`/`changed` fields:
-
-  ```sh
-  npx @tailwindcss/cli canonicalize --format json "py-3 p-1 px-3"
-  # [{ "input": "py-3 p-1 px-3", "output": "p-3", "changed": true }]
-  ```
-
-  Use `--stream` to process stdin line-by-line without buffering:
-
-  ```sh
-  npx @tailwindcss/cli canonicalize --stream
-  ```
-
-## Verify
-
-- Confirm class strings still express the same visual intent after canonicalization.
-- Run relevant lint, typecheck, or formatting commands when available.

package/.agents/skills/componentize/SKILL.md

@@ -1,60 +0,0 @@
----
-name: componentize
-description: Extract and organize existing UI into reusable components with thoughtful APIs.
----
-
-# Componentize
-
-Use this when the user wants to componentize, extract, or organize UI code into reusable components.
-
-## Activation
-
-### Use For
-
-- componentizing an existing page, section, or prototype
-- extracting a page or section into components
-- extracting repeated UI into reusable components
-- reducing duplication in UI code
-- turning a draft implementation into production-ready code structure
-- splitting a large UI file into smaller, focused modules
-
-### Do Not Use For
-
-- brand-new design or layout work
-- visual polish without code structure changes
-- Tailwind class cleanup without component extraction
-- responsive behavior, dark mode, or image adaptation only
-
-## Load First
-
-- No companion modules are required.
-
-## Progress Updates
-
-Keep the user informed so longer runs do not look stuck.
-
-- One-line status update before each major phase.
-- Concrete and lightweight: what you are doing now, not verbose logs.
-
-## Workflow
-
-1. Inspect existing project component patterns before creating new components.
-2. Identify repeated patterns, logical sections, and self-contained UI blocks.
-3. Extract components with call-site spacing and configurable class merging.
-4. Reuse or extend existing project components where available.
-5. Re-scan extracted components for remaining duplication.
-
-## Rules
-
-- Break designs into small, focused components instead of rendering everything in a single large component — extract repeated patterns, logical sections, and self-contained UI blocks into their own components
-- Never bake margins into components — apply margins at the call site instead; every component must accept a `class` attribute and merge it with the classes on the component's top-level element
-- Use `clsx` or similar to merge classes together in client-side components
-- Always extract form controls into reusable components organized by HTML element — one `Input` component for all `<input>` types (text, email, password, etc.), one `Select` for `<select>`, one `Textarea` for `<textarea>`; never create type-specific components like `EmailInput` or `PasswordInput`; check the project for existing ones before creating new ones
-- When two or more elements share the same structure and styling but differ only in props like labels, placeholders, or types — extract them into a single reusable component parameterized by those differences
-- After extracting components, scan them for duplicated patterns and extract shared elements into reusable components — e.g. repeated section container/max-width/padding wrappers, repeated heading group structures (eyebrow + heading + subheading), repeated card shells, repeated button styles
-- Always use existing project components when they are available — reuse or extend them instead of creating new ones; buttons and form elements are especially common candidates
-
-## Verify
-
-- Run relevant formatting, lint, typecheck, or tests when available.
-- Confirm extracted components preserve the original UI and behavior.

package/.agents/skills/critique/SKILL.md

@@ -1,374 +0,0 @@
----
-name: critique
-description: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
----
-
-# Code Review and Quality
-
-## Overview
-
-Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers correctness, readability, architecture, security, performance, and the [[quality-gate]] smell check.
-
-**A review is the act of checking, not the act of approving.** "LGTM" with no findings and no evidence you walked the axes is not a review — it is a rubber stamp wearing one. The checkable signal (borrowed from [[doubt]]'s anti-theater rule): if the diff is non-trivial and you produced *zero* findings across all six axes, you almost certainly didn't review it — look again before you approve. You are also entitled to the upstream artifacts: the ticket's acceptance criteria, the test evidence ([[test]]), and the quality-gate evidence ([[quality-gate]]). A change that arrives without them isn't ready for review — send it back rather than reviewing a claim you can't check.
-
-**The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
-
-## When to Use
-
-- Before merging any PR or change
-- After completing a feature implementation
-- When another agent or model produced code you need to evaluate
-- When refactoring existing code
-- After any bug fix (review both the fix and the regression test)
-
-## The Five-Axis Review
-
-Every review evaluates code across these dimensions:
-
-### 1. Correctness
-
-Does the code do what it claims to do?
-
-- Does it match the spec or task requirements?
-- Are edge cases handled (null, empty, boundary values)?
-- Are error paths handled (not just the happy path)?
-- Does it pass all tests? Are the tests actually testing the right things?
-- Are there off-by-one errors, race conditions, or state inconsistencies?
-
-### 2. Readability & Simplicity
-
-Can another engineer (or agent) understand this code without the author explaining it?
-
-- Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context)
-- Is the control flow straightforward (avoid nested ternaries, deep callbacks)?
-- Is the code organized logically (related code grouped, clear module boundaries)?
-- Are there any "clever" tricks that should be simplified?
-- **Could this be done in fewer lines?** (1000 lines where 100 suffice is a failure)
-- **Are abstractions earning their complexity?** (Don't generalize until the third use case)
-- Would comments help clarify non-obvious intent? (But don't comment obvious code.)
-- Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
-
-### 3. Architecture
-
-Does the change fit the system's design?
-
-- Does it follow existing patterns or introduce a new one? If new, is it justified?
-- Does it maintain clean module boundaries?
-- Is there code duplication that should be shared?
-- Are dependencies flowing in the right direction (no circular dependencies)?
-- Is the abstraction level appropriate (not over-engineered, not too coupled)?
-
-### 4. Security
-
-For detailed security guidance, use [[secure]]. Does the change introduce vulnerabilities?
-
-- Is user input validated and sanitized?
-- Are secrets kept out of code, logs, and version control?
-- Is authentication/authorization checked where needed?
-- Are SQL queries parameterized (no string concatenation)?
-- Are outputs encoded to prevent XSS?
-- Are dependencies from trusted sources with no known vulnerabilities?
-- Is data from external sources (APIs, logs, user content, config files) treated as untrusted?
-- Are external data flows validated at system boundaries before use in logic or rendering?
-
-### 5. Performance
-
-For detailed profiling and optimization, use [[optimize]]. Does the change introduce performance problems?
-
-- Any N+1 query patterns?
-- Any unbounded loops or unconstrained data fetching?
-- Any synchronous operations that should be async?
-- Any unnecessary re-renders in UI components?
-- Any missing pagination on list endpoints?
-- Any large objects created in hot paths?
-
-### 6. Quality Gate
-
-For detailed smell guidance, use [[quality-gate]]. Does the change contain a design smell that should block merge?
-
-- Any workaround, bandaid, broad fallback, swallowed error, sleep/retry patch, or TODO/FIXME temporary code?
-- Any unsafe type assertion/cast, `as any`, `as unknown as T`, non-null assertion, raw `any`, unsafe `any` flow, lint/type suppression, or assertion that only silences tooling?
-- Any massive `if/else` ladder, repeated `switch`, nested branching, boolean parameter matrix, duplicated condition cluster, or mode flag explosion?
-- Any shallow wrapper, manager/helper dumping ground, leaked abstraction, message chain, hidden global, or shotgun-surgery pattern?
-- Any long method/file/class, long parameter list, primitive obsession, data clump, speculative abstraction, dead code, or over-mocked test?
-
-## Change Sizing
-
-Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes:
-
-```
-~100 lines changed   → Good. Reviewable in one sitting.
-~300 lines changed   → Acceptable if it's a single logical change.
-~1000 lines changed  → Too large. Split it.
-```
-
-**What counts as "one change":** A single self-contained modification that addresses one thing, includes related tests, and keeps the system functional after submission. One part of a feature — not the whole feature.
-
-**Splitting strategies when a change is too large:**
-
-| Strategy | How | When |
-|----------|-----|------|
-| **Stack** | Submit a small change, start the next one based on it | Sequential dependencies |
-| **By file group** | Separate changes for groups needing different reviewers | Cross-cutting concerns |
-| **Horizontal** | Create shared code/stubs first, then consumers | Layered architecture |
-| **Vertical** | Break into smaller full-stack slices of the feature | Feature work |
-
-**When large changes are acceptable:** Complete file deletions and automated refactoring where the reviewer only needs to verify intent, not every line.
-
-**Separate refactoring from feature work.** A change that refactors existing code and adds new behavior is two changes — submit them separately. Small cleanups (variable renaming) can be included at reviewer discretion.
-
-## Change Descriptions
-
-Every change needs a description that stands alone in version control history.
-
-**First line:** Short, imperative, standalone. "Delete the FizzBuzz RPC" not "Deleting the FizzBuzz RPC." Must be informative enough that someone searching history can understand the change without reading the diff.
-
-**Body:** What is changing and why. Include context, decisions, and reasoning not visible in the code itself. Link to bug numbers, benchmark results, or design docs where relevant. Acknowledge approach shortcomings when they exist.
-
-**Anti-patterns:** "Fix bug," "Fix build," "Add patch," "Moving code from A to B," "Phase 1," "Add convenience functions."
-
-## Review Process
-
-### Step 1: Understand the Context
-
-Before looking at code, understand the intent:
-
-```
-- What is this change trying to accomplish?
-- What spec or task does it implement?
-- What is the expected behavior change?
-```
-
-### Step 2: Review the Tests First
-
-Tests reveal intent and coverage:
-
-```
-- Do tests exist for the change?
-- Do they test behavior (not implementation details)?
-- Are edge cases covered?
-- Do tests have descriptive names?
-- Would the tests catch a regression if the code changed?
-```
-
-### Step 3: Review the Implementation
-
-Walk through the code with all review axes in mind:
-
-```
-For each file changed:
-1. Correctness: Does this code do what the test says it should?
-2. Readability: Can I understand this without help?
-3. Architecture: Does this fit the system?
-4. Security: Any vulnerabilities?
-5. Performance: Any bottlenecks?
-6. Quality gate: Any bandaid, unsafe cast/assertion, massive branch, or smell?
-```
-
-### Step 4: Categorize Findings
-
-Label every comment with its severity so the author knows what's required vs optional:
-
-| Prefix | Meaning | Author Action |
-|--------|---------|---------------|
-| *(no prefix)* | Required change | Must address before merge |
-| **Critical:** | Blocks merge | Security vulnerability, data loss, broken functionality |
-| **Nit:** | Minor, optional | Author may ignore — formatting, style preferences |
-| **Optional:** / **Consider:** | Suggestion | Worth considering but not required |
-| **FYI** | Informational only | No action needed — context for future reference |
-
-This prevents authors from treating all feedback as mandatory and wasting time on optional suggestions.
-
-### Step 5: Verify the Verification
-
-Check the author's verification story:
-
-```
-- What tests were run?
-- Did the build pass?
-- Was the change tested manually?
-- Are there screenshots for UI changes?
-- Is there a before/after comparison?
-```
-
-## Multi-Model Review Pattern
-
-Use different models for different review perspectives:
-
-```
-Model A writes the code
-    │
-    ▼
-Model B reviews for correctness and architecture
-    │
-    ▼
-Model A addresses the feedback
-    │
-    ▼
-Human makes the final call
-```
-
-This catches issues that a single model might miss — different models have different blind spots.
-
-**Example prompt for a review agent:**
-```
-Review this code change for correctness, security, and adherence to
-our project conventions. The spec says [X]. The change should [Y].
-Flag any issues as Critical, Important, or Suggestion.
-```
-
-## Dead Code Hygiene
-
-After any refactoring or implementation change, check for orphaned code:
-
-1. Identify code that is now unreachable or unused
-2. List it explicitly
-3. **Ask before deleting:** "Should I remove these now-unused elements: [list]?"
-
-Don't leave dead code lying around — it confuses future readers and agents. But don't silently delete things you're not sure about. When in doubt, ask.
-
-```
-DEAD CODE IDENTIFIED:
-- formatLegacyDate() in src/utils/date.ts — replaced by formatDate()
-- OldTaskCard component in src/components/ — replaced by TaskCard
-- LEGACY_API_URL constant in src/config.ts — no remaining references
-→ Safe to remove these?
-```
-
-## Specialized review lenses
-
-Use these lenses inside the same review, not as separate top-level skills:
-
-- **UI and accessibility:** check semantics, keyboard access, focus states, readable labels, responsive layout, loading/error states, and whether text or controls overlap at realistic viewport sizes.
-- **Strict maintainability:** look for giant files, spaghetti branching, shallow wrappers, unclear ownership, dead compatibility shims, and abstractions that do not earn their complexity.
-- **Quality gate:** load [[quality-gate]] and block workarounds, unsafe casts/assertions, type-system escapes, massive branching, duplicated condition clusters, shallow wrappers, dead code, and disabled checks.
-- **Requesting review:** package the diff with a short description, requirements/plan, base/head SHAs, verification run, and known risks. Do not hand the reviewer your whole session history.
-- **Receiving review:** verify each finding against the code before implementing it. Fix valid Critical and Important issues; push back with evidence when a comment is technically wrong.
-
-## Review Speed
-
-Slow reviews block entire teams. The cost of context-switching to review is less than the waiting cost imposed on others.
-
-- **Respond within one business day** — this is the maximum, not the target
-- **Ideal cadence:** Respond shortly after a review request arrives, unless deep in focused coding. A typical change should complete multiple review rounds in a single day
-- **Prioritize fast individual responses** over quick final approval. Quick feedback reduces frustration even if multiple rounds are needed
-- **Large changes:** Ask the author to split them rather than reviewing one massive changeset
-
-## Handling Disagreements
-
-When resolving review disputes, apply this hierarchy:
-
-1. **Technical facts and data** override opinions and preferences
-2. **Style guides** are the absolute authority on style matters
-3. **Software design** must be evaluated on engineering principles, not personal preference
-4. **Codebase consistency** is acceptable if it doesn't degrade overall health
-
-**Don't accept "I'll clean it up later."** Experience shows deferred cleanup rarely happens. Require cleanup before submission unless it's a genuine emergency. If surrounding issues can't be addressed in this change, require filing a bug with self-assignment.
-
-## Honesty in Review
-
-When reviewing code — whether written by you, another agent, or a human:
-
-- **Don't rubber-stamp.** "LGTM" without evidence of review helps no one.
-- **Don't soften real issues.** "This might be a minor concern" when it's a bug that will hit production is dishonest.
-- **Quantify problems when possible.** "This N+1 query will add ~50ms per item in the list" is better than "this could be slow."
-- **Push back on approaches with clear problems.** Sycophancy is a failure mode in reviews. If the implementation has issues, say so directly and propose alternatives.
-- **Accept override gracefully.** If the author has full context and disagrees, defer to their judgment. Comment on code, not people — reframe personal critiques to focus on the code itself.
-
-## Dependency Discipline
-
-Part of code review is dependency review:
-
-**Before adding any dependency:**
-1. Does the existing stack solve this? (Often it does.)
-2. How large is the dependency? (Check bundle impact.)
-3. Is it actively maintained? (Check last commit, open issues.)
-4. Does it have known vulnerabilities? (`npm audit`)
-5. What's the license? (Must be compatible with the project.)
-
-**Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability.
-
-## The Review Checklist
-
-```markdown
-## Review: [PR/Change title]
-
-### Context
-- [ ] I understand what this change does and why
-
-### Correctness
-- [ ] Change matches spec/task requirements
-- [ ] Edge cases handled
-- [ ] Error paths handled
-- [ ] Tests cover the change adequately
-
-### Readability
-- [ ] Names are clear and consistent
-- [ ] Logic is straightforward
-- [ ] No unnecessary complexity
-
-### Architecture
-- [ ] Follows existing patterns
-- [ ] No unnecessary coupling or dependencies
-- [ ] Appropriate abstraction level
-
-### Security
-- [ ] No secrets in code
-- [ ] Input validated at boundaries
-- [ ] No injection vulnerabilities
-- [ ] Auth checks in place
-- [ ] External data sources treated as untrusted
-
-### Performance
-- [ ] No N+1 patterns
-- [ ] No unbounded operations
-- [ ] Pagination on list endpoints
-
-### Verification
-- [ ] Tests pass
-- [ ] Build succeeds
-- [ ] Manual verification done (if applicable)
-
-### Verdict
-- [ ] **Approve** — Ready to merge
-- [ ] **Request changes** — Issues must be addressed
-```
-## See Also
-
-- For detailed security review guidance, use [[secure]].
-- For performance review checks, use [[optimize]].
-- For code smells and no-bandaid/no-cast/no-assertion review, use [[quality-gate]].
-- Before claiming the change is ready, use [[verify]].
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "It works, that's good enough" | Working code that's unreadable, insecure, or architecturally wrong creates debt that compounds. |
-| "I wrote it, so I know it's correct" | Authors are blind to their own assumptions. Every change benefits from another set of eyes. |
-| "We'll clean it up later" | Later never comes. The review is the quality gate — use it. Require cleanup before merge, not after. |
-| "AI-generated code is probably fine" | AI code needs more scrutiny, not less. It's confident and plausible, even when wrong. |
-| "The tests pass, so it's good" | Tests are necessary but not sufficient. They don't catch architecture problems, security issues, or readability concerns. |
-
-## Red Flags
-
-- PRs merged without any review
-- Review that only checks if tests pass (ignoring other axes)
-- "LGTM" without evidence of actual review
-- Security-sensitive changes without security-focused review
-- Large PRs that are "too big to review properly" (split them)
-- No regression tests with bug fix PRs
-- Review comments without severity labels — makes it unclear what's required vs optional
-- Accepting "I'll fix it later" — it never happens
-- Accepting casts/assertions/workarounds/giant branches because tests happen to pass
-
-## Verification
-
-After review is complete:
-
-- [ ] All Critical issues are resolved
-- [ ] All Important issues are resolved or explicitly deferred with justification
-- [ ] [[quality-gate]] was applied and no blocking smells remain
-- [ ] Tests pass
-- [ ] Build succeeds
-- [ ] The verification story is documented (what changed, how it was verified)

package/.agents/skills/dark-mode-image/SKILL.md

@@ -1,64 +0,0 @@
----
-name: dark-mode-image
-description: Create dark-mode variants of raster images for dark UI contexts.
----
-
-# Dark Mode Image
-
-Use this when the user wants to adapt a standalone source image into a dark-mode-suitable version.
-
-## Activation
-
-### Use For
-
-- creating a dark-mode version of an image, illustration, screenshot, photo, product mockup, decorative background, or texture
-- adapting an existing raster image so it presents correctly on a dark background
-- generating a dark-mode image variant for use in a dark-mode UI
-
-### Do Not Use For
-
-- adding dark mode to a page, section, component, or site
-- SVG-only assets
-- general image styling in a UI without dark-mode conversion
-
-When the `add-dark-mode` skill identifies raster images that need dark-mode variants, use this skill for that image-generation work. This skill is the required handoff point between dark-mode UI work and raster image generation.
-
-## Load First
-
-- Before image generation or editing, load and follow the `imagegen` skill.
-
-## Progress Updates
-
-Keep the user informed so longer runs do not look stuck.
-
-- One-line status update before each major phase.
-- Concrete and lightweight: what you are doing now, not verbose logs.
-
-## Workflow
-
-1. Load `imagegen`.
-2. Inspect the source image and the dark-mode UI context.
-3. Generate or edit a dark-mode version with the same dimensions as the original.
-4. Save the dark-mode image with a `-dark` suffix alongside the original.
-5. Return the saved project path for the caller to wire into the UI.
-
-## Rules
-
-- Before doing any image generation or editing, you MUST load and follow the `imagegen` skill
-- The `imagegen` skill invocation is not optional: do not skip it, do not replace it with an ad hoc image-generation workflow, and do not call image tooling directly without first applying `imagegen`
-- Let `imagegen` choose and run the correct image workflow; for normal dark-mode image variants, that will usually mean its default built-in `image_gen` tool mode
-- If the source image is a local file, follow `imagegen`'s local-image guidance before editing so the image is visible in the conversation context
-- Follow `imagegen`'s save-path policy: move or copy project-bound generated outputs into the workspace, and never leave a project-referenced dark-mode asset only under `$CODEX_HOME/*`
-- When generating a dark-mode image, choose a background color that feels like an appropriate inversion of the original background color: black or dark gray for white, dark gray for off-white, or the specific dark color provided by the user; if the original image's background matched the site background, match the dark-mode site background instead
-- Preserve the same contrast characteristics as the original image; light sections should become darker while relative separation and readability stay intact
-- Preserve blurs and softness; never sharpen anything that was blurry in the original image
-- Preserve the foreground color palette hues, adjusting saturation and lightness only as needed so the image presents correctly on a dark background
-- Preserve the original vibe as much as possible: bright and intense images should stay bright and intense, while subtle and muted images should stay subtle and muted
-- Pay attention to areas that fade out and preserve those fades in the dark-mode version
-- The generated dark-mode image must be exactly the same dimensions as the original image
-- Save dark-mode images with a `-dark` suffix, for example `bg.jpg` and `bg-dark.jpg`
-
-## Verify
-
-- Confirm the generated image dimensions match the original exactly.
-- Confirm the dark-mode image preserves the original composition, softness, fades, and foreground palette.

package/.agents/skills/design/SKILL.md

@@ -1,58 +0,0 @@
----
-name: design
-description: Design and build new UI with the complete ui.sh design guideline system.
----
-
-# Design
-
-Use this when the user wants to create new UI that follows the full ui.sh design guideline system.
-
-## Activation
-
-### Use For
-
-- designing new UI, layouts, sections, components, or pages from scratch
-- implementing visually polished Tailwind CSS UI
-- adding a new section or page to an existing UI
-- applying reusable design, markup, and Tailwind authoring rules while building UI
-
-### Do Not Use For
-
-- UI picker scaffolding only
-- semantic unstyled markup from screenshots, Figma exports, mockups, wireframes, or UI images
-- component extraction or code organization only
-- Tailwind class cleanup only
-- adding dark mode to an existing UI only
-- making an existing desktop-oriented UI responsive only
-
-## Load First
-
-- Read [UI Design Guidelines](./design-guidelines.md) before writing UI code.
-- Scan the rule-file index and load every guideline file that could apply.
-- Load reference modules only when the request needs that reference material.
-
-## Progress Updates
-
-Keep the user informed so longer runs do not look stuck.
-
-- One-line status update before each major phase.
-- Concrete and lightweight: what you are doing now, not verbose logs.
-
-## Workflow
-
-1. Inspect the user's request, target files, existing design conventions, and available components.
-2. Load [UI Design Guidelines](./design-guidelines.md) plus every applicable rule file.
-3. Implement the UI using the project's existing framework, component patterns, assets, and Tailwind conventions.
-4. Check the result across responsive breakpoints and interaction states.
-
-## Rules
-
-- Treat the guideline files in this skill as the source of truth for new UI design work.
-- Err on the side of loading too many applicable guideline files rather than too few.
-- Preserve user constraints unless a guideline explicitly requires asking about a design conflict.
-
-## Verify
-
-- Check desktop and mobile layouts.
-- Confirm every applicable guideline file was loaded and followed.
-- Run relevant formatting, lint, typecheck, or tests when available.