@geraldmaron/construct 1.0.5 → 1.0.6

package/skills/docs/init-docs.md

@@ -1,20 +1,20 @@
 <!--
-skills/docs/init-docs.md — Skill: init-docs — Initialize Project Documentation Structure — `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
+skills/docs/init-docs.md (Skill: init-docs) Initialize Project Documentation Structure: `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 
 ## Trigger keywords `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 -->
-# Skill: init-docs — Initialize Project Documentation Structure
+# Skill: init-docs: Initialize Project Documentation Structure
 
 ## Trigger keywords
 `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 
 ## What this skill does
 
-When invoked, gather the user's intent and create a tailored documentation directory structure. The structure serves as both human reference and **required operational project state** — all LLMs working in this project, including Construct, should read these docs to understand purpose, decisions, constraints, and active reality before acting.
+When invoked, gather the user's intent and create a tailored documentation directory structure. The structure serves as both human reference and **required operational project state**: all LLMs working in this project, including Construct, should read these docs to understand purpose, decisions, constraints, and active reality before acting.
 
 ---
 
-## Step 1 — Gather intent (ask these questions)
+## Step 1: Gather intent (ask these questions)
 
 Ask the user **all at once** (single message, not one at a time):
 
@@ -26,9 +26,9 @@ Ask the user **all at once** (single message, not one at a time):
 
 ---
 
-## Step 2 — Generate the structure
+## Step 2: Generate the structure
 
-Based on answers, create the `docs/` directory and appropriate subdirectories. Use this as a base — add or remove sections based on the user's answers.
+Based on answers, create the `docs/` directory and appropriate subdirectories. Use this as a base: add or remove sections based on the user's answers.
 
 ### Core structure (always include)
 
@@ -45,12 +45,12 @@ docs/
 
 ## Interactive UX (TTY)
 
-When run interactively, `construct init-docs` renders a keyboard-driven **full-screen checkbox picker** — all available lanes listed with the default set pre-checked and context-suggested lanes highlighted in the UI. No typing required.
+When run interactively, `construct init-docs` renders a keyboard-driven **full-screen checkbox picker**: all available lanes listed with the default set pre-checked and context-suggested lanes highlighted in the UI. No typing required.
 
-- **↑ / ↓** — move cursor (details shown in a dedicated panel)
-- **Space** — toggle lane on/off
-- **a** — toggle all on/off
-- **Enter** — confirm and scaffold
+- **↑ / ↓**: move cursor (details shown in a dedicated panel)
+- **Space**: toggle lane on/off
+- **a**: toggle all on/off
+- **Enter**: confirm and scaffold
 - Follow-up choices use the same menu pattern instead of free-text answers
 
 If the user selects the `intake` lane, `construct init-docs` should also create `.cx/inbox/`. Both `.cx/inbox/` and `docs/intake/` act as drop zones for ingestable files, while `docs/intake/` also serves as the durable paper trail lane.
@@ -90,7 +90,7 @@ When run non-interactively (`--yes` or piped stdin), the lean default set is use
 
 ---
 
-## Step 3 — Make the core docs explicit project state
+## Step 3: Make the core docs explicit project state
 
 The required core documents are the operational state surface for the repo. All LLMs working here should read and maintain them:
 
@@ -104,9 +104,9 @@ Fill these in based on the user's answers and the actual repo shape. Treat them
 
 ---
 
-## Step 4 — Create skeleton files
+## Step 4: Create skeleton files
 
-Each created file should have a minimal, useful skeleton — not just a title. Skeletons should include:
+Each created file should have a minimal, useful skeleton: not just a title. Skeletons should include:
 - A one-line description of what goes in this file
 - Section headings relevant to the doc type
 - A note at the top that the file is required project state and all LLMs should keep it current.
@@ -156,7 +156,7 @@ Link to `docs/adr/` or the canonical project decision log used in this repo.
 
 ---
 
-## Step 5 — Tell the repo how upkeep works
+## Step 5: Tell the repo how upkeep works
 
 After creating the files, instruct the user:
 

package/skills/docs/init-project.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/init-project.md — Project Initialization — Use when: starting work on a new project or joining an existing one without doc
+skills/docs/init-project.md (Project Initialization) Use when: starting work on a new project or joining an existing one without doc
 
 Use when: starting work on a new project or joining an existing one without doc structure. ## Command
 -->

package/skills/docs/prd-workflow.md

@@ -1,9 +1,9 @@
 <!--
-skills/docs/prd-workflow.md — Workflow for producing a PRD and connecting it to workflow task packets.
+skills/docs/prd-workflow.md: Workflow for producing a PRD and connecting it to workflow task packets.
 
 Guides cx-product-manager through requirements gathering, user research, and writing a PRD
 to docs/prd/. Once approved, the PRD feeds /plan feature to create bead packets in
-.cx/workflow.json — closing the loop from discovery to execution.
+.cx/workflow.json: closing the loop from discovery to execution.
 -->
 # PRD Workflow
 
@@ -17,7 +17,7 @@ Choose the document type before drafting:
 | `prd-platform` | Internal platform, APIs, SDKs, developer tooling, operational infrastructure, shared services |
 | `prd-business` | Strategic bets, market positioning, business model changes, make-vs-buy, pricing strategy |
 | `meta-prd` | Requirements about the product operating system itself: agent workflows, evidence pipelines, templates, evaluation loops, governance |
-| `rfc` | Technical or architectural proposals that need structured review before implementation — no contract changes |
+| `rfc` | Technical or architectural proposals that need structured review before implementation: no contract changes |
 | `rfc-platform` | Proposals that change an external contract: API, SDK, schema, event payload, permission model, protocol |
 
 Style constraint: do not produce a wall of bullets. Use paragraphs for reasoning and narrative, tables for comparison, and bullets only where scanability helps. Keep em dashes rare.

package/skills/docs/prfaq-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/prfaq-workflow.md — Working-backwards PRFAQ generation from PRDs or evidence.
+skills/docs/prfaq-workflow.md: Working-backwards PRFAQ generation from PRDs or evidence.
 -->
 # PRFAQ Workflow
 

package/skills/docs/product-intelligence-review.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-intelligence-review.md — Evaluate Product Intelligence artifacts before they become docs of record.
+skills/docs/product-intelligence-review.md: Evaluate Product Intelligence artifacts before they become docs of record.
 -->
 # Product Intelligence Review
 

package/skills/docs/product-intelligence-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-intelligence-workflow.md — Native Construct workflow for product evidence, synthesis, and product docs.
+skills/docs/product-intelligence-workflow.md: Native Construct workflow for product evidence, synthesis, and product docs.
 
 Use this to move from raw product evidence to PRDs, Meta PRDs, PRFAQs, signal briefs,
 customer profiles, and backlog proposals without creating a separate sidecar system.

package/skills/docs/product-signal-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-signal-workflow.md — Synthesize product signals from evidence into the right artifact.
+skills/docs/product-signal-workflow.md: Synthesize product signals from evidence into the right artifact.
 Confidence rubric, contradiction resolution, artifact decision tree, and storage are all defined here.
 Follow rules/common/research.md for source-handling policy.
 -->
@@ -18,10 +18,10 @@ Use when: the user asks what customers are asking for, what themes are emerging,
 ## Contradiction Resolution
 
 When two signals conflict:
-1. Name both signals explicitly — do not average them away.
+1. Name both signals explicitly: do not average them away.
 2. Weight by customer tier (enterprise > growth > SMB) and recency (weight decays after 90 days).
 3. Record the contradiction in the signal brief as an open question.
-4. Never let a minority signal disappear — it may be the leading indicator.
+4. Never let a minority signal disappear: it may be the leading indicator.
 
 ## Artifact Decision Tree
 
@@ -43,11 +43,11 @@ After grouping evidence, check `.cx/knowledge/decisions/strategy/` for any decla
 
 ## Steps
 
-1. **Gather** — collect evidence briefs, customer profiles, field notes, tickets, and research from `.cx/knowledge/` and linked sources.
-2. **Group** — cluster by theme, ask, pain point, affected persona, product area, and counter-signal.
-3. **Assign confidence** — apply the rubric above; separate observation from inference.
-4. **Check strategy** — check `.cx/knowledge/decisions/strategy/`; flag alignment or conflict with Bets and Non-bets if documents exist.
-5. **Select artifact** — apply the decision tree; write the artifact; store to the path below.
+1. **Gather**: collect evidence briefs, customer profiles, field notes, tickets, and research from `.cx/knowledge/` and linked sources.
+2. **Group**: cluster by theme, ask, pain point, affected persona, product area, and counter-signal.
+3. **Assign confidence**: apply the rubric above; separate observation from inference.
+4. **Check strategy**: check `.cx/knowledge/decisions/strategy/`; flag alignment or conflict with Bets and Non-bets if documents exist.
+5. **Select artifact**: apply the decision tree; write the artifact; store to the path below.
 
 ## Storage
 
@@ -58,4 +58,4 @@ After grouping evidence, check `.cx/knowledge/decisions/strategy/` for any decla
 | PRD | `docs/prd/` |
 | PRFAQ | `docs/prfaq/` |
 | Meta PRD | `docs/meta-prd/` |
-| Backlog proposal | pending approval gate — do not file until explicit user approval |
+| Backlog proposal | pending approval gate: do not file until explicit user approval |

package/skills/docs/research-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/research-workflow.md — Research Workflow — Use when: the user asks to research a topic, investigate a question, or gather e
+skills/docs/research-workflow.md (Research Workflow) Use when: the user asks to research a topic, investigate a question, or gather e
 
 Use when: the user asks to research a topic, investigate a question, or gather evidence for a decision. ## Steps
 -->
@@ -11,9 +11,9 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 
 ## Steps
 
-1. **Clarify the question** — one specific, falsifiable question the research must answer.
-2. **Apply recency discipline** — always search from the most recent year backward. For fast-moving domains (AI tools, security, market data), treat anything older than 12 months as presumptively stale unless a newer source confirms it is still accurate.
-3. **Check internal evidence first** — search `.cx/research/`, `.cx/knowledge/`, `docs/prd/`, `docs/meta-prd/`, ADRs, runbooks, and ingested artifacts before going external.
+1. **Clarify the question**: one specific, falsifiable question the research must answer.
+2. **Apply recency discipline**: always search from the most recent year backward. For fast-moving domains (AI tools, security, market data), treat anything older than 12 months as presumptively stale unless a newer source confirms it is still accurate.
+3. **Check internal evidence first**: search `.cx/research/`, `.cx/knowledge/`, `docs/prd/`, `docs/meta-prd/`, ADRs, runbooks, and ingested artifacts before going external.
 4. **Choose the research path and starting point** by domain:
 
    | Domain | Authoritative starting points |
@@ -28,10 +28,10 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 5. **Use a source hierarchy**:
    - Primary: official docs, exact-version API references, standards, source code, peer-reviewed papers
    - Secondary: changelogs, migration guides, maintainer issue comments, release notes
-   - Tertiary: blogs/forums/Q&A only to locate primaries — never cite tertiary alone for a load-bearing claim
-6. **Verify every URL** — fetch each URL cited and confirm it resolves and matches the cited claim. Mark unconfirmed URLs as `[unverified]`.
-7. **Structure findings** using the template from `get_template("research-brief")` — resolves `.cx/templates/docs/research-brief.md` (override) then `templates/docs/research-brief.md` (shipped)
-8. **Write to `.cx/research/{topic-slug}.md`** — cx-docs-keeper owns this
+   - Tertiary: blogs/forums/Q&A only to locate primaries: never cite tertiary alone for a load-bearing claim
+6. **Verify every URL**: fetch each URL cited and confirm it resolves and matches the cited claim. Mark unconfirmed URLs as `[unverified]`.
+7. **Structure findings** using the template from `get_template("research-brief")`: resolves `.cx/templates/docs/research-brief.md` (override) then `templates/docs/research-brief.md` (shipped)
+8. **Write to `.cx/research/{topic-slug}.md`**: cx-docs-keeper owns this
 9. **Reference the research doc** in the requesting agent's output (link by path)
 
 ## Verification bar
@@ -39,13 +39,13 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 - Every load-bearing claim must cite a verified source path, URL, or document reference.
 - Record publication date, version, or access date for each source. If no date is available, state `[undated]` and treat confidence as `low`.
 - Fetch and confirm every URL before including it in a committed document.
-- Separate observation from inference — label each finding's confidence as `high`, `medium`, or `low`.
+- Separate observation from inference: label each finding's confidence as `high`, `medium`, or `low`.
 - Name contradictions and unresolved gaps.
 - Prefer two independent sources per load-bearing claim unless one authoritative primary source is sufficient.
 - State the strongest counter-evidence when one exists.
 
 ## File naming
-- Topic slug: lowercase, hyphens, no spaces — e.g., `firebase-auth-v9-migration.md`
+- Topic slug: lowercase, hyphens, no spaces: e.g., `firebase-auth-v9-migration.md`
 - Date prefix for time-sensitive research: `2026-04-release-comparison.md`
 
 ## When research feeds a decision

package/skills/docs/runbook-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/runbook-workflow.md — Runbook Workflow — Use when: creating operational procedures for services, alerts, or recurring ope
+skills/docs/runbook-workflow.md (Runbook Workflow) Use when: creating operational procedures for services, alerts, or recurring ope
 
 Use when: creating operational procedures for services, alerts, or recurring operations. ## Steps
 -->
@@ -10,7 +10,7 @@ Use when: creating operational procedures for services, alerts, or recurring ope
 ## Steps
 
 1. **cx-sre** or **cx-release-manager** identifies the need
-2. **Write to `docs/runbooks/{service}-{operation}.md`** using the template from `get_template("runbook")` — resolves `.cx/templates/docs/runbook.md` (override) then `templates/docs/runbook.md` (shipped)
+2. **Write to `docs/runbooks/{service}-{operation}.md`** using the template from `get_template("runbook")`: resolves `.cx/templates/docs/runbook.md` (override) then `templates/docs/runbook.md` (shipped)
 3. **Link from the relevant alert** or monitoring dashboard
 4. **cx-docs-keeper** adds to `.cx/context.md` if it's a critical path runbook
 

package/skills/docs/strategy-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/strategy-workflow.md — Read, update, and reason about the product strategy.
+skills/docs/strategy-workflow.md: Read, update, and reason about the product strategy.
 Canonical store: ~/.cx/strategy.md (user-global) or .cx/strategy.md (project-local, committed).
 Template: templates/docs/strategy.md.
 -->
@@ -32,5 +32,5 @@ Given a product signal or PRD, check:
 
 | Scope | Path | Committed? |
 |---|---|---|
-| User-global | `~/.cx/strategy.md` | No — local only |
-| Project-local | `.cx/strategy.md` | Yes — source of truth for this repo |
+| User-global | `~/.cx/strategy.md` | No: local only |
+| Project-local | `.cx/strategy.md` | Yes: source of truth for this repo |

package/skills/exploration/repo-map.md

@@ -1,9 +1,9 @@
 <!--
-skills/exploration/repo-map.md — Repo Exploration — Codebase Mapping Playbook — Use this skill when entering an unfamiliar codebase, doing deep investigation wo
+skills/exploration/repo-map.md (Repo Exploration) Codebase Mapping Playbook: Use this skill when entering an unfamiliar codebase, doing deep investigation wo
 
 Use this skill when entering an unfamiliar codebase, doing deep investigation work, or producing a `.cx/codebase-map.md` artifact for future sessions. Agents: `
 -->
-# Repo Exploration — Codebase Mapping Playbook
+# Repo Exploration: Codebase Mapping Playbook
 
 Use this skill when entering an unfamiliar codebase, doing deep investigation work, or producing a `.cx/codebase-map.md` artifact for future sessions.
 
@@ -51,14 +51,14 @@ find . -maxdepth 2 -type d \
 ```
 
 Classify each top-level directory as one of:
-- **entry** — main executables, CLIs, servers (cmd/, bin/, app/, main.*)
-- **lib** — shared library code (lib/, pkg/, src/, internal/)
-- **ui** — frontend/views (web/, frontend/, views/, components/)
-- **config** — configuration, env templates (.env.example, config/, etc/)
-- **infra** — deployment, CI/CD, Docker (deploy/, k8s/, .github/, terraform/)
-- **test** — test-only code (test/, tests/, __tests__/, spec/)
-- **docs** — documentation (docs/, .cx/)
-- **generated** — auto-generated, do not read (dist/, build/, .next/, vendor/)
+- **entry**: main executables, CLIs, servers (cmd/, bin/, app/, main.*)
+- **lib**: shared library code (lib/, pkg/, src/, internal/)
+- **ui**: frontend/views (web/, frontend/, views/, components/)
+- **config**: configuration, env templates (.env.example, config/, etc/)
+- **infra**: deployment, CI/CD, Docker (deploy/, k8s/, .github/, terraform/)
+- **test**: test-only code (test/, tests/, __tests__/, spec/)
+- **docs**: documentation (docs/, .cx/)
+- **generated**: auto-generated, do not read (dist/, build/, .next/, vendor/)
 
 ### 2b. Entry points
 
@@ -254,7 +254,7 @@ If you're about to {do Y}, start with: {file or path}
 
 ---
 
-## Quick Reference — Useful One-Liners
+## Quick Reference: Useful One-Liners
 
 ```bash
 # File count by extension

package/skills/frameworks/django.md

@@ -1,5 +1,5 @@
 <!--
-skills/frameworks/django.md — Django — ```
+skills/frameworks/django.md (Django) ```
 
 ## Project Structure ```
 -->
@@ -37,10 +37,10 @@ Keep apps small and feature-bounded. Do not put everything in one app.
 
 ### Field choices
 
-- `CharField` / `TextField` — strings; always set `blank=False` unless optional
-- `UUIDField(default=uuid.uuid4, primary_key=True)` — preferred over auto-increment for external-facing IDs
-- `JSONField` — use sparingly; prefer normalized columns for queryable data
-- `select_related` for FK, `prefetch_related` for M2M — avoid N+1 queries
+- `CharField` / `TextField`: strings; always set `blank=False` unless optional
+- `UUIDField(default=uuid.uuid4, primary_key=True)`: preferred over auto-increment for external-facing IDs
+- `JSONField`: use sparingly; prefer normalized columns for queryable data
+- `select_related` for FK, `prefetch_related` for M2M: avoid N+1 queries
 
 ### Migrations
 
@@ -115,13 +115,13 @@ class ItemSerializer(serializers.ModelSerializer):
 
 ## Security
 
-- `SECRET_KEY` from env — never commit
+- `SECRET_KEY` from env: never commit
 - `ALLOWED_HOSTS` locked down in production
 - `DEBUG = False` in production (template errors expose internals)
 - CSRF: enabled by default for form views; DRF uses `SessionAuthentication` + CSRF for browser clients
 - `django-environ` or `python-decouple` for settings from environment variables
 - Content security policy: `django-csp` middleware
-- SQL: always use ORM or parameterized `raw()` — never string-format user input into queries
+- SQL: always use ORM or parameterized `raw()`: never string-format user input into queries
 
 ## Testing
 
@@ -137,8 +137,8 @@ class ItemAPITest(APITestCase):
     self.assertEqual(Item.objects.count(), 1)
 ```
 
-- Use `APITestCase` (DRF) for API tests — wraps each test in a transaction that rolls back
-- `factory_boy` for fixtures — more maintainable than raw `create()`
+- Use `APITestCase` (DRF) for API tests: wraps each test in a transaction that rolls back
+- `factory_boy` for fixtures: more maintainable than raw `create()`
 - `pytest-django` with `@pytest.mark.django_db` for pytest-style tests
 - `django-silk` or `django-debug-toolbar` for query profiling in development
 
@@ -146,14 +146,14 @@ class ItemAPITest(APITestCase):
 
 - Database: add `db_index=True` for filtered columns; `select_related`/`prefetch_related` to eliminate N+1
 - Caching: `django.core.cache` with Redis backend (`django-redis`)
-- Async views: `async def` views supported in Django 4.1+ — use for I/O-bound operations with `asyncio`
+- Async views: `async def` views supported in Django 4.1+: use for I/O-bound operations with `asyncio`
 - Task queues: `Celery` + Redis/RabbitMQ for background jobs; `django-celery-beat` for scheduling
 - `gunicorn` + `uvicorn` workers for async support in production
 
 ## Common Pitfalls
 
-- `objects.all()` in views without pagination — always use `Paginator` or DRF `pagination_class`
-- Accessing related objects in a loop without `select_related` — profile with `django-debug-toolbar`
-- `settings.DEBUG` checks in production-like environments — use environment-specific settings modules
-- File uploads to local storage in production — use `django-storages` with S3/GCS
-- Signals for business logic — prefer explicit service functions; signals are invisible and hard to test
+- `objects.all()` in views without pagination: always use `Paginator` or DRF `pagination_class`
+- Accessing related objects in a loop without `select_related`: profile with `django-debug-toolbar`
+- `settings.DEBUG` checks in production-like environments: use environment-specific settings modules
+- File uploads to local storage in production: use `django-storages` with S3/GCS
+- Signals for business logic: prefer explicit service functions; signals are invisible and hard to test

package/skills/frameworks/nextjs.md

@@ -1,5 +1,5 @@
 <!--
-skills/frameworks/nextjs.md — Next.js (App Router) — ```
+skills/frameworks/nextjs.md (Next.js (App Router)) ```
 
 ## App Router Mental Model ```
 -->
@@ -46,9 +46,9 @@ Caching behaviors:
 
 | Option | Behavior |
 |---|---|
-| `cache: 'force-cache'` | Static — cache forever (default) |
-| `next: { revalidate: N }` | ISR — revalidate after N seconds |
-| `cache: 'no-store'` | Dynamic — always fresh |
+| `cache: 'force-cache'` | Static: cache forever (default) |
+| `next: { revalidate: N }` | ISR: revalidate after N seconds |
+| `cache: 'no-store'` | Dynamic: always fresh |
 | `next: { tags: ['items'] }` | Tag for on-demand revalidation |
 
 ### On-demand revalidation
@@ -91,15 +91,15 @@ export async function createItem(formData: FormData) {
 </form>
 ```
 
-Validate Server Action inputs — they are network endpoints.
+Validate Server Action inputs: they are network endpoints.
 
 ## Rendering Strategies
 
 | Strategy | When |
 |---|---|
-| Static (SSG) | Marketing pages, docs — no user-specific data |
-| ISR | Listings, product pages — stale-ok, periodic refresh |
-| Dynamic (SSR) | Dashboards, auth-gated pages — always fresh |
+| Static (SSG) | Marketing pages, docs: no user-specific data |
+| ISR | Listings, product pages: stale-ok, periodic refresh |
+| Dynamic (SSR) | Dashboards, auth-gated pages: always fresh |
 | Client | Highly interactive UIs, real-time, after-hydration only |
 
 Prefer static/ISR by default; reach for dynamic only when the data must be per-request.
@@ -129,20 +129,20 @@ export function middleware(req: NextRequest) {
 export const config = { matcher: ['/dashboard/:path*'] };
 ```
 
-Middleware runs on the Edge Runtime — no Node.js APIs. Keep it fast; no DB calls.
+Middleware runs on the Edge Runtime: no Node.js APIs. Keep it fast; no DB calls.
 
 ## Performance
 
 - Enable Partial Prerendering (PPR) in Next.js 15 for shell + streaming content
-- Use `next/image` for all images — automatic WebP, lazy loading, CLS prevention
-- Use `next/font` for self-hosted fonts — eliminates FOUT and external requests
+- Use `next/image` for all images: automatic WebP, lazy loading, CLS prevention
+- Use `next/font` for self-hosted fonts: eliminates FOUT and external requests
 - Bundle analysis: `ANALYZE=true next build`
 - Streaming: wrap slow data-dependent sections in `<Suspense>`
 
 ## Common Pitfalls
 
-- Importing client-only code (browser APIs, hooks) in Server Components — add `'use client'`
-- Large `layout.tsx` re-renders — use `memo` on stable child subtrees
-- Fetching the same data in multiple components — hoist to the nearest shared ancestor Server Component (fetch is deduplicated within a request)
-- Dynamic routes missing `generateStaticParams` for static builds — causes runtime 404
-- Server Actions called without input validation — treat as untrusted user input
+- Importing client-only code (browser APIs, hooks) in Server Components: add `'use client'`
+- Large `layout.tsx` re-renders: use `memo` on stable child subtrees
+- Fetching the same data in multiple components: hoist to the nearest shared ancestor Server Component (fetch is deduplicated within a request)
+- Dynamic routes missing `generateStaticParams` for static builds: causes runtime 404
+- Server Actions called without input validation: treat as untrusted user input

package/skills/frameworks/react.md

@@ -1,5 +1,5 @@
 <!--
-skills/frameworks/react.md — React — By default, components are **Server Components** — they run on the server, have
+skills/frameworks/react.md (React) By default, components are **Server Components**: they run on the server, have
 
 ## Component Design ### Server vs Client Components (React 19 / Next.js App Router)
 -->
@@ -9,7 +9,7 @@ skills/frameworks/react.md — React — By default, components are **Server Com
 
 ### Server vs Client Components (React 19 / Next.js App Router)
 
-By default, components are **Server Components** — they run on the server, have no state, and can fetch data directly. Add `'use client'` only when you need interactivity, browser APIs, or hooks.
+By default, components are **Server Components**: they run on the server, have no state, and can fetch data directly. Add `'use client'` only when you need interactivity, browser APIs, or hooks.
 
 ```tsx
 // Server Component — no directive needed
@@ -53,7 +53,7 @@ See decision matrix:
 | URL state | `useSearchParams` / router |
 | Component-local state | `useState` / `useReducer` |
 
-Do not put server data in a client store — TanStack Query is the cache. Derive don't duplicate.
+Do not put server data in a client store: TanStack Query is the cache. Derive don't duplicate.
 
 ## Performance
 
@@ -95,8 +95,8 @@ export function useItems() {
 
 ### Controlled vs uncontrolled
 
-- Controlled: React owns value via `state` — use for forms with validation, derived fields
-- Uncontrolled: DOM owns value via `ref` — use for file inputs and simple browser-owned fields
+- Controlled: React owns value via `state`: use for forms with validation, derived fields
+- Uncontrolled: DOM owns value via `ref`: use for file inputs and simple browser-owned fields
 
 ## Testing
 
@@ -113,20 +113,20 @@ test('submits search query', async () => {
 });
 ```
 
-- Use `@testing-library/react` — test behavior, not implementation
-- `userEvent` over `fireEvent` — simulates real user interactions
+- Use `@testing-library/react`: test behavior, not implementation
+- `userEvent` over `fireEvent`: simulates real user interactions
 - Mock at the network boundary (`msw`) not the component boundary
 
 ## Tooling
 
 - **Vite** for non-Next apps; fast HMR, native ESM
 - **Biome** for lint + format in a single fast tool (replaces ESLint + Prettier)
-- **TypeScript strict mode** — enables `noUncheckedIndexedAccess`, `strictNullChecks`, etc.
+- **TypeScript strict mode**: enables `noUncheckedIndexedAccess`, `strictNullChecks`, etc.
 - React DevTools Profiler for recomposition analysis
 
 ## Common Pitfalls
 
-- Stale closures in `useEffect` — include all reactive values in the dependency array or use `useEffectEvent` (React 19)
-- `useEffect` for data fetching — use TanStack Query instead
-- Direct DOM mutation inside render — causes tearing with concurrent mode
-- Key prop as array index — breaks reconciliation on reorder/insert
+- Stale closures in `useEffect`: include all reactive values in the dependency array or use `useEffectEvent` (React 19)
+- `useEffect` for data fetching: use TanStack Query instead
+- Direct DOM mutation inside render: causes tearing with concurrent mode
+- Key prop as array index: breaks reconciliation on reorder/insert

package/skills/frameworks/spring-boot.md

@@ -1,5 +1,5 @@
 <!--
-skills/frameworks/spring-boot.md — Spring Boot — ```
+skills/frameworks/spring-boot.md (Spring Boot) ```
 
 ## Project Structure ```
 -->
@@ -80,9 +80,9 @@ interface ItemRepository : JpaRepository<Item, UUID> {
 }
 ```
 
-- Default `FetchType.LAZY` for associations — never `EAGER`
+- Default `FetchType.LAZY` for associations: never `EAGER`
 - Use `JOIN FETCH` in queries when you need the association
-- Enable `spring.jpa.open-in-view=false` — prevents lazy-loading in the web layer
+- Enable `spring.jpa.open-in-view=false`: prevents lazy-loading in the web layer
 - Use Flyway or Liquibase for schema migrations; never `ddl-auto=update` in production
 
 ## Transactions
@@ -101,8 +101,8 @@ class ItemService(private val repo: ItemRepository) {
 ```
 
 - `@Transactional` on service layer, not repository or controller
-- `readOnly = true` as class-level default; override on writes — signals no dirty-check needed
-- Do not call `@Transactional` methods via `this` — Spring proxy won't intercept it
+- `readOnly = true` as class-level default; override on writes: signals no dirty-check needed
+- Do not call `@Transactional` methods via `this`: Spring proxy won't intercept it
 
 ## Security (Spring Security 6)
 
@@ -145,12 +145,12 @@ class ItemControllerIT(@Autowired val restTemplate: TestRestTemplate) {
 
 - `@WebMvcTest` for controller-only tests (fast, no DB)
 - `@DataJpaTest` for repository tests against a real embedded or Testcontainers DB
-- `@SpringBootTest` for integration tests — use Testcontainers for realistic DB
+- `@SpringBootTest` for integration tests: use Testcontainers for realistic DB
 - `MockMvc` + `@AutoConfigureMockMvc` for HTTP-layer testing without a real port
 
 ## Performance
 
-- Connection pool: `HikariCP` (default) — tune `maximumPoolSize` based on load testing
+- Connection pool: `HikariCP` (default): tune `maximumPoolSize` based on load testing
 - N+1 queries: use `JOIN FETCH` or `@EntityGraph`; verify with `spring.jpa.show-sql=true` in dev
 - Caching: `@Cacheable` + Spring Cache with Redis (`spring-boot-starter-data-redis`)
 - Async: `@EnableAsync` + `@Async` on service methods for fire-and-forget; use `CompletableFuture<T>` return type
@@ -158,8 +158,8 @@ class ItemControllerIT(@Autowired val restTemplate: TestRestTemplate) {
 
 ## Common Pitfalls
 
-- `LazyInitializationException` after transaction closes — resolve with `JOIN FETCH` or DTO projection
-- `@Transactional` on private methods — Spring AOP proxy can't intercept; move to public
-- Bean cycle injection — restructure or use `@Lazy`
-- Returning JPA entities directly from controllers — exposes internal model; always map to DTOs
-- `findAll()` without pagination on large tables — always use `Pageable`
+- `LazyInitializationException` after transaction closes: resolve with `JOIN FETCH` or DTO projection
+- `@Transactional` on private methods: Spring AOP proxy can't intercept; move to public
+- Bean cycle injection: restructure or use `@Lazy`
+- Returning JPA entities directly from controllers: exposes internal model; always map to DTOs
+- `findAll()` without pagination on large tables: always use `Pageable`

package/skills/frontend-design/accessibility.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/accessibility.md — Accessibility (WCAG 2.2 / Inclusive Design) — Target **WCAG 2.1 AA** as the minimum for any public-facing product. WCAG 2.2 AA
+skills/frontend-design/accessibility.md (Accessibility (WCAG 2.2 / Inclusive Design)) Target **WCAG 2.1 AA** as the minimum for any public-facing product. WCAG 2.2 AA
 
 ## Compliance Baseline Target **WCAG 2.1 AA** as the minimum for any public-facing product. WCAG 2.2 AA is the current standard (published October 2023) and req
 -->
@@ -25,7 +25,7 @@ ARIA augments semantics it can't add natively; it cannot fix broken semantics.
 
 ## ARIA Rules
 
-1. If a native HTML element provides the required semantics, use it — do not add ARIA to a `<div>` when `<button>` exists.
+1. If a native HTML element provides the required semantics, use it: do not add ARIA to a `<div>` when `<button>` exists.
 2. Do not change native semantics: `<h2 role="button">` is invalid.
 3. All interactive ARIA widgets must be keyboard-operable.
 4. Do not hide focusable elements with `aria-hidden="true"`.
@@ -84,11 +84,11 @@ function trapFocus(modal: HTMLElement) {
 |---|---|---|
 | Normal text (< 18pt / 14pt bold) | 4.5:1 | 7:1 |
 | Large text (≥ 18pt / 14pt bold) | 3:1 | 4.5:1 |
-| UI components / graphical objects | 3:1 | — |
+| UI components / graphical objects | 3:1 |: |
 
 Tools: Figma Contrast plugin, axe DevTools, APCA calculator for sophisticated use cases.
 
-Do not convey information by color alone — add shape, pattern, or text.
+Do not convey information by color alone: add shape, pattern, or text.
 
 ## Motion
 
@@ -136,11 +136,11 @@ if (!prefersReduced) gsap.to(el, { y: -20, duration: 0.3 });
 
 ## Testing Checklist
 
-- [ ] Run `axe` or `Lighthouse Accessibility` — fix all violations
+- [ ] Run `axe` or `Lighthouse Accessibility`: fix all violations
 - [ ] Navigate entire flow with keyboard only
 - [ ] Test with VoiceOver (macOS/iOS) or NVDA/JAWS (Windows)
 - [ ] Verify color contrast meets 4.5:1 for body text
-- [ ] Test with browser zoom at 200% — no horizontal scroll, no content loss
+- [ ] Test with browser zoom at 200%: no horizontal scroll, no content loss
 - [ ] Test with `prefers-reduced-motion: reduce` enabled
 - [ ] All form errors are announced by screen reader
 

package/skills/frontend-design/component-patterns.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/component-patterns.md — Component Patterns — Use this skill when designing component architecture, building design systems, o
+skills/frontend-design/component-patterns.md (Component Patterns) Use this skill when designing component architecture, building design systems, o
 
 Use this skill when designing component architecture, building design systems, or structuring reusable UI. ## Component Hierarchy
 -->

package/skills/frontend-design/engineering.md

@@ -1,5 +1,5 @@
 <!--
-skills/frontend-design/engineering.md — Frontend Engineering — Use this skill when working on build tooling, bundling, rendering strategies, or
+skills/frontend-design/engineering.md (Frontend Engineering) Use this skill when working on build tooling, bundling, rendering strategies, or
 
 Use this skill when working on build tooling, bundling, rendering strategies, or frontend infrastructure. ## Build Tools
 -->