/partials/...` or the local app template folder.
+4. Render the full page by including the same partial that the HTMX response returns.
+5. Preserve non-HTMX fallback behavior for links and forms whenever practical.
+6. Add tests for both normal and HTMX requests when the view branches on `request.htmx`.
+
+## View Patterns
+
+Branch on `request.htmx` only after the same auth, permission, and data-loading path has run:
+
+```python
+from django.contrib.auth.decorators import login_required
+from django.shortcuts import redirect, render
+from django_htmx.http import trigger_client_event
+from django.views.decorators.http import require_http_methods
+
+
+@login_required
+@require_http_methods(["GET", "POST"])
+def profile_panel(request):
+ profile = request.user.profile
+ form = ProfileForm(request.POST or None, instance=profile)
+
+ if request.method == "POST" and form.is_valid():
+ form.save()
+ if not request.htmx:
+ return redirect("settings")
+ form = ProfileForm(instance=profile)
+ response = render(request, "core/partials/profile_panel.html", {"form": form})
+ return trigger_client_event(response, "profile:saved", after="swap")
+
+ template_name = (
+ "core/partials/profile_panel.html"
+ if request.htmx
+ else "pages/user-settings.html"
+ )
+ return render(request, template_name, {"form": form})
+```
+
+Use `@vary_on_headers("HX-Request")` on cacheable views that return different full-page and partial content for the same URL.
+
+For mutations that should redirect a normal browser but update the current page for HTMX, return separate responses:
+
+```python
+from django.contrib.auth.decorators import login_required
+from django.shortcuts import redirect, render
+from django_htmx.http import trigger_client_event
+from django.views.decorators.http import require_http_methods
+
+
+@login_required
+@require_http_methods(["GET", "POST"])
+def create_note(request):
+ form = NoteForm(request.POST or None)
+ if request.method == "POST" and form.is_valid():
+ note = form.save(commit=False)
+ note.user = request.user
+ note.save()
+ if request.htmx:
+ response = render(request, "core/partials/note.html", {"note": note})
+ return trigger_client_event(response, "note:created", {"id": note.pk})
+ return redirect("notes")
+
+ template_name = "core/partials/note_form.html" if request.htmx else "core/note_form.html"
+ return render(request, template_name, {"form": form})
+```
+
+Prefer `django_htmx.http` helpers over hand-writing HTMX headers:
+
+- `HttpResponseClientRedirect` for `HX-Redirect`.
+- `HttpResponseClientRefresh` for `HX-Refresh`.
+- `HttpResponseLocation` for `HX-Location`.
+- `HttpResponseStopPolling` or status `286` for stopping polling.
+- `push_url()`, `replace_url()`, `retarget()`, `reswap()`, `reselect()`, and `trigger_client_event()` for response header modifiers.
+
+## Template Patterns
+
+Keep forms valid without JavaScript, then add HTMX attributes:
+
+```django
+
+```
+
+Use stable targets:
+
+- Use `hx-target="#component-id"` with IDs that appear exactly once.
+- Use `hx-swap="outerHTML"` when replacing the target element itself.
+- Ensure partials returned to an `outerHTML` swap include the target root element with the same ID.
+- Use `hx-swap="innerHTML"` when replacing only the target contents.
+- Use `hx-select` or `reselect()` when the server returns a larger HTML response but only one fragment should be swapped.
+- Use `hx-indicator` for visible pending states and `hx-disabled-elt` for controls that must not be clicked twice.
+- Use `hx-confirm` for simple confirmation. Use an Alpine-controlled modal only when the confirmation has real UI complexity.
+
+Use out-of-band swaps for shared chrome, messages, counters, and badges that are outside the main target:
+
+```django
+
+ {% include "components/messages.html" with messages=messages %}
+
+```
+
+For lists, return the row or item fragment after create/update/delete instead of rebuilding a full page unless the queryset ordering, filters, totals, or pagination also change.
+
+## Forms And Validation
+
+- Keep Django forms as the validation source of truth.
+- Include `{% csrf_token %}` in forms even though the base HTMX header is configured. It preserves non-HTMX fallback and standard Django behavior.
+- For invalid HTMX form submissions, return a rendered bound form with normal status `200` unless the project has explicit `htmx:beforeSwap` or response-target handling for `4xx` and `422` responses.
+- For successful create/update, either return the updated component or return an empty `HttpResponse(status=204)` plus `HX-Trigger` when another element should refresh.
+- For destructive actions, require POST unless the project has a deliberate method override pattern for `DELETE`. Django does not parse form bodies for `PUT`, `PATCH`, or `DELETE` the way it does for POST.
+
+## Events And Alpine Coordination
+
+Use HTMX events to connect server results to local browser state:
+
+```python
+response = render(request, "core/partials/dialog_body.html", context)
+return trigger_client_event(response, "dialog:saved", after="swap")
+```
+
+```html
+
+```
+
+Keep the ownership line clear:
+
+- HTMX owns server trips, fresh HTML, history updates, and cross-component server facts.
+- Alpine owns local-only state, keyboard/menu behavior, temporary UI state, and transitions.
+- Do not mirror server truth into Alpine stores unless there is a clear reason and synchronization plan.
+- After swapping content that contains Alpine components, rely on the loaded Alpine build to initialize new markup. Avoid manually calling Alpine lifecycle APIs unless a bug proves it is necessary.
+
+## History, Navigation, And Boosting
+
+- Use `hx-push-url="true"` only when the new state deserves a real browser URL.
+- Ensure every pushed URL can render a full page on direct load and refresh.
+- Use `push_url()` or `replace_url()` when the server decides which URL should appear after a swap.
+- Keep `historyRestoreAsHxRequest = false` so htmx history-cache misses are sent as normal full-page requests rather than HX requests.
+- Use `hx-boost` sparingly. Confirm forms still send CSRF tokens and links still render useful full pages.
+
+## Security Rules
+
+- Let Django autoescape user content. Avoid `safe`, `mark_safe`, and raw user-provided HTML.
+- If trusted product requirements allow sanitized rich HTML, strip or whitelist attributes so injected `hx-`, `data-hx-`, `hx-on`, `hx-vals`, and script-bearing content cannot create requests or execute code.
+- Do not put secrets, private object IDs, or authorization decisions in HTMX attributes. Enforce permissions in the view.
+- Avoid `js:` prefixes in `hx-headers` and `hx-vals`. Prefer plain JSON attributes or server-rendered hidden inputs.
+- Keep HTMX requests same-origin unless there is a deliberate CORS and CSRF design.
+- Use `hx-history="false"` on sensitive pages or containers that should not be stored in the browser history cache.
+
+## Testing Checklist
+
+- Test the normal browser path and the HTMX path.
+- Send `HTTP_HX_REQUEST="true"` in Django tests for HTMX responses.
+- Assert the partial response contains the expected fragment and omits full-page chrome when appropriate.
+- Assert redirects, refreshes, retargeting, triggers, and status codes through response headers.
+- Assert invalid forms re-render errors into the intended target.
+- Add `@vary_on_headers("HX-Request")` coverage when cache headers are involved.
+
+Example:
+
+```python
+def test_profile_panel_htmx_renders_partial(client, user):
+ client.force_login(user)
+
+ response = client.get("/settings/profile/", HTTP_HX_REQUEST="true")
+ content = response.content.decode("utf-8").lower()
+
+ assert response.status_code == 200
+ assert b'id="profile-panel"' in response.content
+ assert " None:
+ from django.contrib.auth import get_user_model
+
+ user = get_user_model().objects.get(pk=user_id)
+ ...
+```
+
+```python
+from django.db import transaction
+from django_q.tasks import async_task
+
+transaction.on_commit(
+ lambda: async_task("apps.core.tasks.send_welcome_email", user.pk)
+)
+```
+
+Use `q_options` when Django Q2 options would collide with task kwargs:
+
+```python
+async_task(
+ "apps.core.tasks.rebuild_report",
+ report_id,
+ q_options={"timeout": 300, "group": "reports"},
+)
+```
+
+## Scheduling Work
+
+Prefer named, idempotent schedules created by a migration, admin action, or
+setup command. Avoid creating schedules unconditionally at import time or app
+startup.
+
+```python
+from django_q.models import Schedule
+
+Schedule.objects.get_or_create(
+ name="clear-expired-sessions",
+ defaults={
+ "func": "django.core.management.call_command",
+ "args": "'clearsessions'",
+ "schedule_type": Schedule.HOURLY,
+ },
+)
+```
+
+Use `Schedule.objects.get_or_create(name=..., defaults={...})` when seeding
+schedules so repeated setup does not duplicate jobs. Cron schedules require the
+optional `croniter` dependency; do not use `Schedule.CRON` unless the generated
+project includes it.
+
+Missed schedules catch up by default. Set `Q_CLUSTER["catch_up"] = False` when
+a job should run once after downtime instead of replaying every missed interval.
+
+## Broker Choices
+
+### Redis Broker
+
+This template should normally use Redis:
+
+```python
+Q_CLUSTER = {
+ "name": "...",
+ "timeout": 3600,
+ "workers": 4,
+ "redis": REDIS_URL,
+}
+```
+
+Redis is fast and matches local Docker, deployment workers, and the default
+cache configuration. The default Redis broker does not support delivery
+receipts. If a worker host dies catastrophically while executing a task, the
+in-flight package can be lost; if task code raises, Django Q2 records a
+failure. Use idempotent task design, explicit retries in task code where
+needed, and monitoring for failures.
+
+### ORM Broker
+
+Use the Django database broker only for low-throughput deployments, local
+simplicity, or environments where Redis is unavailable:
+
+```python
+Q_CLUSTER = {
+ "name": "...",
+ "timeout": 3600,
+ "retry": 4800,
+ "workers": 4,
+ "max_attempts": 2,
+ "orm": "default",
+}
+```
+
+When switching to ORM:
+
+- Remove the `"redis"` broker key; configure one broker per cluster unless you
+ intentionally use custom clusters.
+- Run migrations for `django_q`. If the broker uses a non-default database
+ alias, run migrations with `--database `.
+- Increase `"poll"` above the default `0.2` seconds, for example `"poll": 2.0`,
+ when you need lower database polling pressure and can tolerate higher queue
+ pickup latency.
+- The ORM broker enables the Queued Tasks admin table.
+- Review Redis-dependent cache, health check, Docker, and deployment settings
+ separately. Schedules are always database rows; the broker setting controls
+ queued task packages, not the schedule table.
+
+## Testing
+
+- Test task business logic by calling the function directly.
+- Test enqueueing with synchronous mode:
+ - per call: `async_task("apps.core.tasks.fn", arg, sync=True)`
+ - per test: override `Q_CLUSTER["sync"] = True`
+- For worker/broker integration, run
+ `uv run --no-sync python manage.py qcluster` in a separate process and wait
+ for `result(task_id, 200)` or a similar bounded wait; do not rely on
+ arbitrary sleeps.
+- Use `pytest.mark.django_db(transaction=True)` when a real worker process must
+ observe committed database rows.
+
+## Debugging Checklist
+
+- Is a `qcluster` process running with the same settings module, `SECRET_KEY`,
+ broker URL, and cluster name as the web process?
+- Can the worker import the dotted task path?
+- Did database migrations run, including `django_q` migrations?
+- Is Redis reachable from both web and worker containers, or is the ORM broker
+ polling the expected database?
+- Did a scheduled task duplicate because setup created another `Schedule` row
+ with no stable name?
+- Did downtime trigger schedule catch-up?
+- Is task failure visible in Django admin, logs, or the configured error
+ reporter?
+
+## References
+
+- Official docs: https://django-q2.readthedocs.io/en/master/
+- Upstream repo: https://github.com/django-q2/django-q2
diff --git a/plugins/LVTD-LLC/skills/skills/django-q2/assets/app-icon.png b/plugins/LVTD-LLC/skills/skills/django-q2/assets/app-icon.png
new file mode 100644
index 00000000..c019f518
Binary files /dev/null and b/plugins/LVTD-LLC/skills/skills/django-q2/assets/app-icon.png differ
diff --git a/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/SKILL.md b/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/SKILL.md
new file mode 100644
index 00000000..799f43c5
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/SKILL.md
@@ -0,0 +1,68 @@
+---
+name: django-targeted-mocking
+description: Mock Django test boundaries safely with override_settings, pytest settings, autospecced unittest.mock objects, output/input capture, requests-mock, VCR.py, outbound HTTP blocking, and time-freezing tools. Use when tests need to replace settings, HTTP calls, time, command output, stdin, or external services without broad fragile MagicMock patches.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Django Targeted Mocking
+ category: Django
+ tags: django,testing,mocking,http,pytest
+---
+
+# Django Targeted Mocking
+
+Mock only at boundaries that are slow, nondeterministic, external, or hard to trigger. Broad mocks can make tests faster while proving less, so prefer framework helpers and interface-checked replacements.
+
+## Boundary Workflow
+
+1. Decide whether mocking is necessary.
+ - Prefer real code for local domain logic.
+ - Mock external HTTP, time, settings, output/input, and expensive service edges.
+
+2. Patch where the code under test looks up the dependency.
+ - Patch the imported symbol used by the module under test, not the original library path unless that is what the module reads.
+
+3. Prefer specific tools.
+ - Settings: `override_settings`, `modify_settings`, or pytest-django's `settings` fixture.
+ - Output: `io.StringIO`, pytest `capsys`, or command test helpers.
+ - HTTP: `requests-mock` for hand-authored responses; VCR.py for recorded responses.
+ - Time: pass time as a parameter when possible; otherwise use `time-machine` or a similar time-specific tool.
+
+4. Make mocks interface-aware.
+ - Use `autospec=True`, `spec`, `spec_set`, `create_autospec`, or a small fake object.
+ - Avoid bare `Mock`/`MagicMock` when the interface matters.
+
+5. Block unexpected outbound HTTP.
+ - A normal test run should fail if a test reaches the network unintentionally.
+
+Read [mocking-patterns.md](references/mocking-patterns.md) for concrete patterns.
+
+## Decision Rules
+
+- Use Django settings helpers instead of direct assignment to `django.conf.settings`.
+- Prefer a hand-built fake or `types.SimpleNamespace` when only a few attributes are needed.
+- Use `requests-mock` for deterministic API responses you control.
+- Use VCR.py when real recorded responses are valuable and safe to store.
+- On CI, configure VCR record mode so missing cassettes fail instead of recording.
+- Mock time consistently across the runtime; do not patch several datetime functions by hand.
+- Do not mock the component whose behavior the test is meant to prove.
+
+## Common Mistakes
+
+- Patching settings directly and leaking state across tests.
+- Using catch-all `MagicMock` objects that accept typoed attributes and wrong call signatures.
+- Allowing tests to hit real external services.
+- Recording VCR cassettes in CI.
+- Mocking a view's internal helpers so thoroughly that the test no longer covers request behavior.
+- Patching the wrong import path and thinking the mock is active.
+
+## Verification
+
+Before finishing:
+
+- Each mock has a clear boundary reason.
+- Interface-sensitive mocks use specs or fakes.
+- Unexpected outbound HTTP is blocked in the normal suite.
+- Settings are restored automatically by Django or pytest helpers.
+- Tests still cover the behavior, not only mock calls.
diff --git a/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/references/mocking-patterns.md b/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/references/mocking-patterns.md
new file mode 100644
index 00000000..c0560bdc
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-targeted-mocking/references/mocking-patterns.md
@@ -0,0 +1,94 @@
+# Mocking Patterns
+
+## Settings
+
+Use Django helpers so `setting_changed` fires and state is restored.
+
+```python
+from django.test import override_settings
+
+@override_settings(PAGE_SIZE=10)
+def test_page_size(client):
+ ...
+```
+
+With pytest-django:
+
+```python
+def test_page_size(settings):
+ settings.PAGE_SIZE = 10
+ ...
+```
+
+## Output and Input
+
+For management command output, pass file-like objects when the API supports it.
+
+```python
+out = io.StringIO()
+call_command("my_command", stdout=out)
+assert "done" in out.getvalue()
+```
+
+In pytest, use `capsys` for stdout/stderr capture.
+
+## HTTP
+
+Use `requests-mock` for direct, explicit response setup.
+
+```python
+def test_api_client(requests_mock):
+ requests_mock.get("https://api.example.test/books", json={"items": []})
+ assert fetch_books() == []
+```
+
+Block real outbound requests by default with a session-scoped fixture when the project uses `requests`.
+
+```python
+@pytest.fixture(autouse=True, scope="session")
+def block_http():
+ with requests_mock.Mocker() as mocker:
+ mocker.real_http = False
+ yield mocker
+```
+
+Use VCR.py when real responses are useful. Scrub secrets from cassettes and set CI to non-recording mode.
+
+## Time
+
+Prefer explicit time parameters in application code:
+
+```python
+def is_expired(record, now):
+ return record.expires_at <= now
+```
+
+When that is not practical, use a time-specific package so all relevant time calls agree.
+
+```python
+import time_machine
+
+@time_machine.travel("2026-06-14 12:00:00Z")
+def test_deadline():
+ ...
+```
+
+## Interface-Checked Mocks
+
+Use specs when replacing an object with an expected API.
+
+```python
+with mock.patch("app.emailing.EmailClient", autospec=True) as client_cls:
+ ...
+```
+
+For small interfaces, a fake object can be clearer than a mock.
+
+```python
+class FakeEmailClient:
+ def __init__(self):
+ self.sent = []
+
+ def send(self, message):
+ self.sent.append(message)
+```
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-data/SKILL.md b/plugins/LVTD-LLC/skills/skills/django-test-data/SKILL.md
new file mode 100644
index 00000000..286fd342
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-data/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: django-test-data
+description: Design faster, clearer Django test data and test structure with factories, setUpTestData, SimpleTestCase/TestCase choices, fixture-file cleanup, query optimization, and unit-vs-integration boundaries. Use when Django tests create too much data, rely on slow fixtures, overuse TransactionTestCase, duplicate setup, or need refactoring for speed without losing coverage.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Django Test Data
+ category: Django
+ tags: django,testing,test-data,factories,pytest
+---
+
+# Django Test Data
+
+Most slow Django suites spend time building data they do not need or exercising full request/database paths for behavior that can be tested at a smaller boundary. Use this skill to reduce setup cost while keeping representative integration coverage.
+
+## Refactoring Workflow
+
+1. Map the behavior under test.
+ - Identify the smallest useful boundary: function, form, model method, middleware, command helper, view, or full request path.
+ - Keep a few integration tests for wiring; move detailed cases to unit tests where the boundary is clean.
+
+2. Choose the fastest test base class.
+ - `SimpleTestCase`: no database access.
+ - `TestCase`: ordinary database tests with rollback.
+ - `TransactionTestCase`: committed transaction behavior only.
+ - `LiveServerTestCase`: browser/live-server tests only.
+
+3. Remove broad fixture data.
+ - Avoid large fixture files and base classes that always create objects.
+ - Build only the data each test or class needs.
+
+4. Use factories deliberately.
+ - Start with small factory functions when the domain is simple.
+ - Use Factory Boy or Model Bakery when relationships and variants become repetitive.
+
+5. Share class-level data with `setUpTestData`.
+ - Use `setUpTestData()` for database objects reused by multiple methods in a `TestCase`.
+ - Avoid mutating shared in-memory objects across methods.
+
+6. Optimize database access in test setup and assertions.
+ - Use `select_related`, `prefetch_related`, or `bulk_create` where setup/query cost is the bottleneck.
+ - Assert query counts for hot paths when performance is part of the contract.
+
+Read [patterns.md](references/patterns.md) for examples and decision details.
+
+## Decision Rules
+
+- If a test does not need the database, use `SimpleTestCase`.
+- If only some tests need the database, split them into separate classes.
+- If a test requires committed transaction behavior, first check whether `captureOnCommitCallbacks()` or an inner `atomic()` is enough.
+- If many tests share expensive objects, use `setUpTestData` instead of `setUp`.
+- If fixture files are hard to understand or grow over time, replace them with factories.
+- If a test depends on hard-coded auto-increment IDs, fix the assertion rather than enabling `reset_sequences=True`.
+- Combine assertions when they describe one behavior produced by one expensive action.
+
+## Common Mistakes
+
+- Testing form validation only through rendered HTML instead of inspecting form errors directly.
+- Leaving management-command business logic inside `handle()`, forcing tests through `call_command()`.
+- Using `TransactionTestCase` as the default.
+- Putting data in a base `TestCase` that only a few subclasses need.
+- Treating factories as permission to create a large object graph for every test.
+- Mutating objects created by `setUpTestData` and leaking in-memory state to later tests.
+
+## Verification
+
+Before finishing a refactor:
+
+- The old behavior remains covered at the right level.
+- Database-using and non-database tests are split where useful.
+- Repeated setup moved to `setUpTestData` or factories only where it reduces cost.
+- Relevant tests pass individually and as part of their module/class.
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-data/references/patterns.md b/plugins/LVTD-LLC/skills/skills/django-test-data/references/patterns.md
new file mode 100644
index 00000000..29394641
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-data/references/patterns.md
@@ -0,0 +1,75 @@
+# Test Data Patterns
+
+## Test Base Class Selection
+
+| Need | Class |
+|------|-------|
+| Pure Python logic, form validation without DB, middleware unit, helper method | `SimpleTestCase` |
+| Models, ORM reads/writes, ordinary view tests | `TestCase` |
+| Committed transaction behavior, low-level transaction edge cases | `TransactionTestCase` |
+| Browser/live server behavior | `LiveServerTestCase` |
+
+Split test classes when only some methods need database access.
+
+## Arrange-Act-Assert
+
+Use Arrange-Act-Assert as a readability guide:
+
+- Arrange only the data needed for the behavior.
+- Act once when the behavior has one meaningful effect.
+- Assert all facts that describe that effect.
+
+Avoid splitting one expensive request into many tests just to enforce "one assertion per test". That can make the suite slower without improving clarity.
+
+## Factories
+
+Small factory functions are enough for simple projects:
+
+```python
+def make_book(**kwargs):
+ defaults = {"title": "Django Patterns"}
+ defaults.update(kwargs)
+ return Book.objects.create(**defaults)
+```
+
+Use Factory Boy or Model Bakery when:
+
+- Relationships are repetitive.
+- Many tests need valid default objects.
+- Variants would otherwise create long setup blocks.
+
+Keep factories lean. If every call creates users, permissions, orders, payments, and logs, the factory has become another fixture file.
+
+## setUpTestData
+
+Use `setUpTestData()` to create class-level database objects once for a `TestCase`:
+
+```python
+class BookTests(TestCase):
+ @classmethod
+ def setUpTestData(cls):
+ cls.book = Book.objects.create(title="Django Patterns")
+```
+
+Django rolls back database writes between methods, but Python object mutation can still surprise you. Refresh from the database or avoid mutating shared instances directly.
+
+## Transaction Edge Cases
+
+For `IntegrityError` inside `TestCase`, wrap the failing operation in an inner transaction:
+
+```python
+with transaction.atomic():
+ with self.assertRaises(IntegrityError):
+ create_duplicate()
+```
+
+For `transaction.on_commit()`, prefer `TestCase.captureOnCommitCallbacks()` before switching to `TransactionTestCase`.
+
+## Component Boundaries
+
+| Component | Faster Test Boundary |
+|-----------|----------------------|
+| Form | Instantiate form, inspect `errors`, `cleaned_data`, and validity |
+| Management command | Extract helper methods; keep one `call_command()` smoke/integration test |
+| Middleware | Use `RequestFactory` and simple `get_response` callable |
+| View | Keep request-path tests for wiring; move complex branching into testable functions |
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-parallelization/SKILL.md b/plugins/LVTD-LLC/skills/skills/django-test-parallelization/SKILL.md
new file mode 100644
index 00000000..14ad9844
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-parallelization/SKILL.md
@@ -0,0 +1,85 @@
+---
+name: django-test-parallelization
+description: Safely parallelize Django and pytest-django test suites with Django --parallel, pytest-xdist, test isolation checks, randomized order detection, shared-resource sharding, locks, and load balancing. Use when enabling parallel tests, diagnosing failures under parallel execution, handling flaky Django tests, or making caches, files, queues, and external resources safe across workers.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Django Test Parallelization
+ category: Django
+ tags: django,testing,parallelization,pytest,xdist
+---
+
+# Django Test Parallelization
+
+Parallel test execution is a multiplier after a suite is isolated. Treat failures under parallel execution as evidence of hidden shared state until proven otherwise.
+
+## Readiness Workflow
+
+1. Measure serial runtime first.
+ - If the suite is already dominated by startup or database creation, parallelism may not help enough on its own.
+
+2. Check isolation before enabling parallelism as the default.
+ - Run in reverse order.
+ - Run with randomized order when reverse order is not enough.
+ - Preserve random seeds so failures can be reproduced.
+
+3. Enable the runner deliberately.
+ - Django runner: install `tblib`, then run `python manage.py test --parallel`.
+ - pytest-django: install `pytest-xdist`, then run `pytest -n auto`.
+
+4. Classify failures.
+ - Order-dependent failures usually come from mutated globals, class attributes, settings, caches, monkeypatches, or database assumptions.
+ - Parallel-only failures usually come from shared resources such as files, cache keys, ports, queues, external services, or temporary directories.
+
+5. Make resources worker-safe.
+ - Prefer sharding per process or worker.
+ - Use locks only when the resource cannot be partitioned.
+ - Keep lock scope narrow.
+
+6. Balance work after it is correct.
+ - Split large test classes or modules only when measurement shows one group holds back the parallel run.
+
+## Commands
+
+```bash
+python -m pip install tblib
+python manage.py test --parallel
+python manage.py test --parallel 1
+python manage.py test --reverse
+
+python -m pip install pytest-xdist
+pytest -n auto
+pytest -n auto --dist loadscope
+```
+
+For shared-resource patterns, read [shared-resources.md](references/shared-resources.md).
+
+## Decision Rules
+
+- Add parallel testing early in new projects; older serial suites often have hidden isolation assumptions.
+- Use CI reverse-order testing as a low-friction guard against order dependencies.
+- Use random order when reverse order misses a suspected dependency, and capture the seed.
+- Prefer `pytest -n auto --dist loadscope` for Django `TestCase`-heavy suites because class/module setup can be expensive.
+- Shard resources before reaching for locks.
+- Put process-specific behavior in test settings only, not production settings.
+- Split large test groups only after profiling shows an imbalance.
+
+## Common Mistakes
+
+- Assuming database transaction isolation protects caches, files, task queues, or external systems.
+- Mutating class attributes, globals, app settings, or cache entries without restoring them.
+- Enabling random order without preserving the seed.
+- Using a single lockfile for too much work and accidentally serializing the suite.
+- Letting pytest-xdist split related tests so finely that setup cost is duplicated.
+- Making parallelism the default before the suite passes reliably under order-isolation checks.
+
+## Verification
+
+Before calling parallelization complete:
+
+- Serial run passes.
+- Reverse or random-order run passes, or known failures are fixed.
+- Parallel run passes at least twice.
+- Any shared-resource sharding lives in test configuration.
+- CI has a serial fallback command for debugging.
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-parallelization/references/shared-resources.md b/plugins/LVTD-LLC/skills/skills/django-test-parallelization/references/shared-resources.md
new file mode 100644
index 00000000..2ac14343
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-parallelization/references/shared-resources.md
@@ -0,0 +1,60 @@
+# Shared Resources
+
+Parallel workers share more than the database. Audit every resource that can persist across processes.
+
+## Resource Audit
+
+| Resource | Risk | Preferred Fix |
+|----------|------|---------------|
+| Django cache | Key collisions and stale values | Test-only key function or per-worker cache location |
+| Files/media storage | Path collisions and cleanup races | Per-worker temp root |
+| External HTTP service | Rate limits or cross-test state | Mock HTTP or isolate account/project |
+| Task queue | Workers consuming each other's jobs | In-memory/eager mode or per-worker queue |
+| Ports/sockets | Bind collisions | Allocate dynamic ports |
+| Global settings/class attrs | State leaks between tests | Patch in the narrowest scope and restore |
+| Lock-protected external resource | Hidden serialization | Lock only the critical section |
+
+## Sharding Pattern
+
+Prefer deriving a worker-specific suffix from process or pytest-xdist worker identity.
+
+```python
+import os
+
+def parallel_worker_suffix() -> str:
+ return os.environ.get("PYTEST_XDIST_WORKER") or str(os.getpid())
+```
+
+Use the suffix in temp directories, cache locations, queue names, and resource names. Keep this in test settings or test helpers so production behavior is untouched.
+
+## Cache Key Function
+
+For Django cache backends that support `KEY_FUNCTION`, include a worker suffix in test settings.
+
+```python
+import os
+
+def parallel_cache_key(key, key_prefix, version):
+ worker = os.environ.get("PYTEST_XDIST_WORKER") or str(os.getpid())
+ return f"{worker}:{key_prefix}:{version}:{key}"
+```
+
+Do not use worker-specific cache keys in production; normal application processes need shared cache semantics.
+
+## Locking Pattern
+
+Use locks only when sharding is impossible.
+
+- Keep the locked block as small as possible.
+- Lock around the shared resource, not the whole test.
+- Use a project-standard lock helper when one exists.
+- Avoid one global lock for unrelated resources.
+
+## Debug Checklist
+
+- Does the failing test pass alone?
+- Does it fail only with `--parallel` or `pytest -n`?
+- Does it fail in a fixed order run?
+- Which resource does the test mutate outside the test database?
+- Can that resource be named per worker?
+- If not, what is the smallest lockable section?
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-performance/SKILL.md b/plugins/LVTD-LLC/skills/skills/django-test-performance/SKILL.md
new file mode 100644
index 00000000..f20c872d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-performance/SKILL.md
@@ -0,0 +1,94 @@
+---
+name: django-test-performance
+description: Improve slow Django test suites through measured profiling, safe test settings, database and migration tuning, parallel execution, test-data cleanup, and CI workflow changes. Use when Django or pytest-django tests are slow, CI test jobs take too long, database setup dominates runtime, or a user asks for a prioritized speedup plan rather than isolated test fixes.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Django Test Performance
+ category: Django
+ tags: django,testing,performance,pytest,ci
+---
+
+# Django Test Performance
+
+Use this as the orchestration skill for speeding up a Django test suite. Do not start by changing settings blindly; first measure the suite and then pick the smallest safe optimization with a repeatable verification command.
+
+## Core Workflow
+
+1. Establish a baseline.
+ - Run the same command developers or CI use.
+ - Capture wall-clock time, runner, settings module, database backend, worker count, and branch.
+ - If the cause is unclear, use `django-test-profiling` before changing behavior.
+
+2. Classify the dominant cost.
+ - Startup/import/discovery: reduce collection scope and expensive app initialization.
+ - Database creation/migrations: reuse DB locally, squash migration history, or improve database storage.
+ - Per-test setup: reduce fixture data, use factories, and use `setUpTestData`.
+ - External backends: replace file storage, cache, task queues, and instrumentation with test-safe backends.
+ - Long tail of tests: parallelize after isolation checks.
+
+3. Apply low-risk wins first.
+ - Fast password hasher.
+ - `DEBUG = False` in tests.
+ - Disable database serialization when serialized rollback is not needed.
+ - Disable debug toolbar, Sentry/Rollbar/APM initialization, and other instrumentation.
+ - In-memory or local test backends for storage, cache, and task queues.
+ - See [speed-wins.md](references/speed-wins.md).
+
+4. Improve data and structure.
+ - Use `django-test-data` for factory, fixture, `setUpTestData`, `TestCase`, and integration-vs-unit decisions.
+
+5. Improve migrations and database setup.
+ - Use `--keepdb` or `--reuse-db` for local repeat runs.
+ - Force rebuilds when migration history changes.
+ - Prefer squashing migrations over disabling migrations globally.
+ - Keep the test database backend close to production unless the project is database-agnostic.
+
+6. Parallelize only when safe.
+ - Use `django-test-parallelization` for order isolation, shared resources, and worker configuration.
+
+7. Re-measure with the original baseline command.
+ - Report before/after runtime and the changed risk surface.
+ - Keep or revert each optimization based on measured impact and behavioral fidelity.
+
+## Default Commands
+
+```bash
+time python manage.py test
+python manage.py test --timing
+python manage.py test --keepdb
+
+time pytest
+pytest --durations 20
+pytest --reuse-db
+pytest --create-db
+```
+
+## Decision Rules
+
+- If you cannot name the bottleneck, profile first.
+- If a setting changes production-like behavior, keep the override narrow and document why tests remain representative.
+- Avoid broad `TESTING = True` branches in application code; use explicit settings and test helpers.
+- Do not swap PostgreSQL/MySQL/MariaDB projects to SQLite just for speed unless production is SQLite or the project intentionally supports many backends.
+- Do not disable migrations as the normal path. If a legacy project insists, run real migrations in CI.
+- Keep local speed shortcuts from hiding CI coverage. CI should run slow tests and migration-realistic paths somewhere.
+
+## Handoff Map
+
+| Situation | Use |
+|-----------|-----|
+| Need timings, slow-test lists, flame graphs, or cProfile output | `django-test-profiling` |
+| Enabling `--parallel`, `pytest-xdist`, or debugging random failures | `django-test-parallelization` |
+| Fixture bloat, factories, `setUpTestData`, `TestCase` class choices | `django-test-data` |
+| Mocking settings, HTTP, time, output, or command input safely | `django-targeted-mocking` |
+| CI cache, split jobs, slow markers, runner scale | `django-ci-test-optimization` |
+
+## Verification
+
+Before finishing, provide:
+
+- Baseline and final runtime from the same command.
+- A ranked list of changes made or recommended.
+- Risks introduced by each test-only override.
+- Commands the project should keep for local and CI verification.
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-performance/references/speed-wins.md b/plugins/LVTD-LLC/skills/skills/django-test-performance/references/speed-wins.md
new file mode 100644
index 00000000..84efdf97
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-performance/references/speed-wins.md
@@ -0,0 +1,58 @@
+# Safe Speed Wins
+
+Apply these only after measuring. Keep the test suite faithful enough that passing tests still mean production behavior is covered.
+
+## Settings Checklist
+
+| Area | Typical Test Override | Check |
+|------|-----------------------|-------|
+| Password hashing | Fast hasher such as MD5 for tests | No test asserts production hash cost |
+| Debug mode | `DEBUG = False` | Debug-specific behavior has separate tests if needed |
+| DB serialization | `DATABASES["default"]["TEST"]["SERIALIZE"] = False` | Suite does not depend on serialized rollback |
+| File storage | In-memory or temp-dir storage | File behavior under test still uses a real file when needed |
+| Cache | LocMem, Dummy, fake Redis, or per-worker cache | Cache behavior tests use a representative backend |
+| Task queues | Eager, sync, or in-memory brokers | Worker integration has separate coverage |
+| Instrumentation | Disable debug toolbar, APM, Sentry/Rollbar setup | Error-reporting integration is tested elsewhere |
+| Static files | Avoid WhiteNoise startup scans during tests | Static-file behavior has targeted tests |
+
+## Local Database Reuse
+
+Use database reuse for repeated local runs:
+
+```bash
+python manage.py test --keepdb
+pytest --reuse-db
+pytest --create-db
+```
+
+Force a rebuild after:
+
+- Switching branches with migration changes.
+- Editing, deleting, renaming, or squashing migrations.
+- Renaming apps or models.
+- Upgrading Django or database drivers.
+- Seeing unexplained schema-related failures.
+
+## Migrations
+
+Prefer migration squashing over bypassing migrations. Long migration histories slow database creation and increase CI setup time, but disabled migrations can hide production schema behavior.
+
+If a project uses no-migration local shortcuts:
+
+- Keep them out of CI or add a CI job that runs migrations for real.
+- Avoid depending on no-migration behavior in tests.
+- Revisit the shortcut after migration squashing.
+
+## Slow Test Markers
+
+Local runs may skip marked slow tests, but CI should still run them.
+
+```bash
+python manage.py test --exclude-tag slow
+python manage.py test --tag slow
+
+pytest -m "not slow"
+pytest -m "slow"
+```
+
+Use strict marker registration in pytest so typoed marks do not silently change coverage.
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-profiling/SKILL.md b/plugins/LVTD-LLC/skills/skills/django-test-profiling/SKILL.md
new file mode 100644
index 00000000..c77a24a1
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-profiling/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: django-test-profiling
+description: Profile and measure slow Django test suites with Django's runner, pytest-django, shell timing, py-spy, cProfile, pytest durations, and profiler visualizations. Use when a Django project has slow tests, unclear test-runtime bottlenecks, CI timing problems, startup overhead, database setup overhead, or a request to find the slowest tests before optimizing.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Django Test Profiling
+ category: Django
+ tags: django,testing,profiling,pytest,performance
+---
+
+# Django Test Profiling
+
+Use this skill before changing a Django test suite for speed. Measurement decides which optimization is worth doing; otherwise it is easy to spend time on harmless settings while the real cost sits in startup, database setup, fixture construction, or a small set of slow tests.
+
+## Measurement Workflow
+
+1. Capture a full wall-clock baseline.
+ - Prefer shell timing because it includes Python startup, Django import time, test discovery, database setup, and teardown.
+ - Record the exact command, environment, and repeat count.
+
+2. Separate framework phases when possible.
+ - For Django's runner, use `--timing` to see database setup and teardown.
+ - For pytest, compare shell timing with `pytest --durations`.
+
+3. Find the slowest tests.
+ - For pytest-django, start with `pytest --durations 20`.
+ - For Django's runner, use an existing slow-test plugin or a small custom runner only when the project does not already have one.
+
+4. Profile only after you know where the time goes.
+ - Use `py-spy` first for a low-overhead whole-run view.
+ - Use `cProfile` when you need exhaustive Python call data.
+
+5. Convert the result into a ranked action list.
+ - Identify whether the expensive part is startup, database creation, repeated setup, test data, query count, I/O, cache/file/storage access, or a specific test body.
+ - Hand off to `django-test-performance`, `django-test-data`, or `django-test-parallelization` when the next step fits those skills.
+
+## Commands
+
+```bash
+time python manage.py test
+python manage.py test --timing
+pytest --durations 20
+```
+
+For profiling command variants and interpretation guidance, read [profiler-commands.md](references/profiler-commands.md).
+
+## Decision Rules
+
+- Treat shell timing as the authoritative user-visible duration.
+- Use Django `--timing` when database setup or teardown may dominate.
+- Optimize the slowest measured tests first, not the tests that look suspicious.
+- Put noisy duration reports in CI logs when they distract from normal local runs.
+- Use `py-spy --subprocesses` when the test runner uses child processes.
+- Sort cProfile by cumulative time first; inspect self-time only after you understand the caller chain.
+
+## Common Mistakes
+
+- Trusting a framework's final "ran in X seconds" line as the complete runtime.
+- Comparing Django runner timing and pytest timing as if they measure identical phases.
+- Profiling everything before finding slow tests.
+- Reading unsorted cProfile output and chasing import internals.
+- Expecting sampling profiles to catch every short hot path.
+- Optimizing a helper without checking how often it is reached by tests.
+
+## Verification
+
+Before reporting findings, include:
+
+- The exact baseline command and measured wall-clock time.
+- The slowest tests or slowest phases.
+- The profiler used, if any, and why it was appropriate.
+- The top 3 practical next actions, ordered by expected impact.
diff --git a/plugins/LVTD-LLC/skills/skills/django-test-profiling/references/profiler-commands.md b/plugins/LVTD-LLC/skills/skills/django-test-profiling/references/profiler-commands.md
new file mode 100644
index 00000000..ef25383a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/django-test-profiling/references/profiler-commands.md
@@ -0,0 +1,56 @@
+# Profiler Commands
+
+Use these commands as starting points and adapt them to the project's runner, package manager, and CI environment.
+
+## Baseline Timing
+
+| Goal | Command |
+|------|---------|
+| Full Django suite wall-clock time | `time python manage.py test` |
+| Django DB setup/teardown timing | `python manage.py test --timing` |
+| Full pytest suite wall-clock time | `time pytest` |
+| Slowest pytest phases | `pytest --durations 20` |
+| PowerShell timing | `Measure-Command { python manage.py test }` |
+
+Repeat short runs several times. For long suites, a single CI baseline may be enough to prioritize first-pass work, but note that it is a noisy measurement.
+
+## py-spy
+
+Use `py-spy` for a low-overhead overview of where a running suite spends time.
+
+```bash
+python -m pip install py-spy
+sudo py-spy record -o profile.svg --subprocesses -- python manage.py test
+sudo py-spy record --format speedscope -o profile.speedscope --subprocesses -- python manage.py test
+```
+
+Use `--subprocesses` for Django parallel tests or tools that fork worker processes. Add `--idle` only when sleeping or idle time is itself part of the diagnosis.
+
+## cProfile
+
+Use `cProfile` when sampling is too coarse or you need exhaustive Python call accounting.
+
+```bash
+python -m cProfile -s cumtime manage.py test
+python -m cProfile -m pytest
+python -m cProfile -o profile.prof manage.py test
+```
+
+Read cumulative time first to find expensive call trees. Then inspect total time to find functions that are expensive by themselves rather than through their callees.
+
+## Visualizing cProfile
+
+```bash
+python -m pip install pyprof2calltree
+pyprof2calltree -i profile.prof -k
+```
+
+Use kcachegrind/qcachegrind when you need caller/callee navigation. For pytest users, `pytest-profiling` can store cProfile output without manually wrapping the runner.
+
+## Interpretation Checklist
+
+- Is the cost in suite startup, test discovery, database setup, fixture creation, repeated query work, file/cache/network I/O, or actual assertions?
+- Does one test class/module dominate a parallel run?
+- Do slow pytest entries show setup, call, or teardown time?
+- Does the profile point to test code, application code, or framework/package initialization?
+- Can the next fix be validated by rerunning the same timing command?
diff --git a/plugins/LVTD-LLC/skills/skills/fastmcp-django/SKILL.md b/plugins/LVTD-LLC/skills/skills/fastmcp-django/SKILL.md
new file mode 100644
index 00000000..9d8da42f
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/fastmcp-django/SKILL.md
@@ -0,0 +1,441 @@
+---
+name: fastmcp-django
+description: Use when adding, changing, deploying, testing, or debugging FastMCP MCP servers in existing Django apps, including ASGI mounting, stdio or sidecar servers, Django ORM access from MCP tools, auth and permissions, Streamable HTTP deployment, and MCP client tests.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: FastMCP Django
+ category: Django
+ tags: fastmcp,django,mcp,asgi
+---
+
+# FastMCP with Django
+
+Use this when exposing Django application capabilities to agents through MCP.
+Keep Django as the source of truth for auth, permissions, validation, models,
+transactions, and business rules. Use FastMCP as the protocol layer around
+small, typed capabilities.
+
+## Tool Choice
+
+- Prefer the standalone `fastmcp` package (`from fastmcp import FastMCP`) for
+ new Python MCP work in Django. It is the actively maintained FastMCP project
+ and includes HTTP transport, clients, auth helpers, CLI tooling, testing
+ utilities, server composition, and OpenAPI/FastAPI conversion features.
+- Use the official MCP Python SDK (`from mcp.server.fastmcp import FastMCP`)
+ when the project has already standardized on it, when you need lower-level
+ protocol control, or when a host explicitly requires SDK behavior.
+- Consider `django-mcp-server` only when the project needs a Django-native
+ package that works inside WSGI or declaratively exposes models/DRF APIs. Audit
+ its security model and generated tool contracts before exposing private data.
+- If the app already has a deliberate public OpenAPI surface, generating or
+ proxying tools from that API can be useful for a first pass. For production
+ agents, prefer hand-curated tools with purpose-built names, input schemas,
+ permission checks, and bounded outputs.
+
+FastMCP docs track the project's `main` branch, so re-check the current docs
+when relying on recently added features or version badges.
+
+## Implementation Workflow
+
+1. Read the existing Django entrypoints first: `manage.py`, `settings.py`,
+ `asgi.py`, `wsgi.py`, URL routing, auth middleware, DRF/Ninja APIs, Celery or
+ Django Q tasks, and deployment files.
+2. Choose the transport boundary:
+ - Use stdio for a local desktop/editor MCP server that runs beside the app.
+ - Use a separate FastMCP HTTP sidecar when the Django deployment is WSGI-only
+ or when MCP should scale independently.
+ - Mount FastMCP into the Django ASGI process when the app already runs under
+ ASGI and sharing the same domain/process is intentional.
+3. Put MCP server registration in a small module such as `apps/core/mcp.py` or
+ `project/mcp.py`. Keep tool bodies thin and call existing services,
+ selectors, forms, serializers, policies, or domain functions.
+4. Make every exposed capability explicit. Avoid generic SQL, generic model
+ browsing, arbitrary imports, file path access, or "admin" tools unless the
+ project has a clear allowlist and authorization plan.
+5. Add tests through `fastmcp.Client` before wiring the transport. Most behavior
+ should be tested in-memory without a running web server.
+
+## Stdio Server Pattern
+
+For local agent clients, create a standalone script that initializes Django
+before importing models or tool modules.
+
+```python
+# mcp_server.py
+import os
+
+os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.settings")
+
+import django
+
+django.setup()
+
+from apps.core.mcp import mcp
+
+if __name__ == "__main__":
+ mcp.run()
+```
+
+This shape also works well with the FastMCP CLI because the file fully prepares
+Django when loaded by `fastmcp list`, `fastmcp call`, or an MCP inspector.
+
+## HTTP Sidecar Pattern
+
+Use a sidecar when Django is still deployed through WSGI, when MCP needs
+separate scaling, or when you want a clear operational boundary. The sidecar is
+a separate process that initializes Django, imports the same MCP server object,
+and serves Streamable HTTP.
+
+```python
+# mcp_http_server.py
+import os
+
+os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.settings")
+
+import django
+
+django.setup()
+
+from apps.core.mcp import mcp
+
+if __name__ == "__main__":
+ mcp.run(
+ transport="http",
+ host="127.0.0.1",
+ port=8765,
+ path="/mcp",
+ )
+```
+
+Run the Django web process and MCP process independently:
+
+```text
+web: gunicorn project.wsgi:application
+mcp: python mcp_http_server.py
+```
+
+Point the reverse proxy or internal client at the sidecar's `/mcp` endpoint.
+Keep the sidecar on a private interface unless it has production-grade TLS,
+auth, rate limits, logging, and monitoring. Give it the same settings module,
+database URL, cache/broker settings, secrets, and migrations as the web process.
+Do not try to mount FastMCP inside WSGI middleware; use ASGI mounting only when
+the combined process is actually served by an ASGI server.
+
+## ASGI Mount Pattern
+
+For a Django app already served by ASGI, make FastMCP a sibling ASGI app and
+route `/mcp` before the Django catch-all. Pass the FastMCP lifespan to the outer
+Starlette app; otherwise Streamable HTTP session management may not initialize.
+
+```python
+# project/asgi.py
+import os
+
+from django.core.asgi import get_asgi_application
+from starlette.applications import Starlette
+from starlette.routing import Mount
+
+os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.settings")
+
+django_app = get_asgi_application()
+
+from apps.core.mcp import mcp
+
+mcp_app = mcp.http_app(path="/")
+
+application = Starlette(
+ routes=[
+ Mount("/mcp", app=mcp_app),
+ Mount("/", app=django_app),
+ ],
+ lifespan=mcp_app.lifespan,
+)
+```
+
+If the project uses Channels, keep websocket routing in `ProtocolTypeRouter` and
+put the Starlette HTTP router in the `"http"` branch. If the project already has
+an app lifespan, compose it with the FastMCP lifespan instead of replacing it.
+
+Do not set both the mount prefix and `http_app(path=...)` to `/mcp` unless the
+intended endpoint is `/mcp/mcp`. When mounting at `/mcp`, use
+`mcp.http_app(path="/")`; when running FastMCP as the whole HTTP app, use a path
+such as `mcp.http_app(path="/mcp")` or `mcp.run(transport="http", path="/mcp")`.
+
+## Tool Design
+
+Create tools as narrow application actions, not generic database access.
+
+```python
+# apps/core/mcp.py
+from collections.abc import Callable
+from typing import Annotated
+
+from django.core.exceptions import PermissionDenied
+from django.db import close_old_connections, transaction
+from fastmcp import FastMCP
+from fastmcp.dependencies import Depends
+from pydantic import Field
+
+
+class ResourceNotFound(Exception):
+ """Safe not-found error for MCP clients."""
+
+
+def get_current_actor_id() -> int:
+ """Return the authenticated Django user ID from trusted MCP auth context."""
+ raise PermissionDenied("Authentication is required")
+
+
+def _order_summary(order_id: int, actor_id: int) -> dict:
+ from apps.orders.models import Order
+
+ try:
+ order = Order.objects.select_related("customer").get(pk=order_id)
+ except Order.DoesNotExist as exc:
+ raise ResourceNotFound("Order not found") from exc
+
+ if not order.can_be_viewed_by_id(actor_id):
+ raise PermissionDenied("Not allowed to view this order")
+
+ return {
+ "id": order.pk,
+ "status": order.status,
+ "customer": order.customer.name,
+ "total_cents": order.total_cents,
+ }
+
+
+def create_mcp(
+ actor_id_dependency: Callable[[], int] = get_current_actor_id,
+) -> FastMCP:
+ mcp = FastMCP("Project MCP", on_duplicate_tools="error")
+
+ @mcp.tool(timeout=10)
+ def get_order_summary(
+ order_id: Annotated[int, Field(gt=0, description="Internal order ID")],
+ actor_id: int = Depends(actor_id_dependency),
+ ) -> dict:
+ """Return a concise order summary the actor is allowed to view."""
+ close_old_connections()
+ try:
+ return _order_summary(order_id=order_id, actor_id=actor_id)
+ except ResourceNotFound:
+ return {"error": "not_found", "message": "Order not found"}
+ except PermissionDenied:
+ return {
+ "error": "forbidden",
+ "message": "Not allowed to view this order",
+ }
+ finally:
+ close_old_connections()
+
+ @mcp.tool(timeout=20)
+ def cancel_order(
+ order_id: Annotated[int, Field(gt=0)],
+ reason: Annotated[str, Field(min_length=3, max_length=500)],
+ actor_id: int = Depends(actor_id_dependency),
+ ) -> dict:
+ """Cancel an order if the actor is allowed to do so."""
+ close_old_connections()
+ try:
+ with transaction.atomic():
+ from apps.orders.services import cancel_order_for_actor
+
+ order = cancel_order_for_actor(
+ order_id=order_id,
+ actor_id=actor_id,
+ reason=reason,
+ )
+ transaction.on_commit(lambda: order.enqueue_cancellation_email())
+ return {"id": order.pk, "status": order.status}
+ except PermissionDenied:
+ return {
+ "error": "forbidden",
+ "message": "Not allowed to cancel this order",
+ }
+ except ValueError:
+ return {
+ "error": "invalid_state",
+ "message": "Order cannot be cancelled",
+ }
+ finally:
+ close_old_connections()
+
+ return mcp
+
+
+mcp = create_mcp()
+```
+
+Rules for tool contracts:
+
+- Use typed parameters, Pydantic `Field` constraints, docstrings, return type
+ annotations, and small JSON-serializable return values.
+- Use existing Django services and policy methods. Do not duplicate permission
+ logic inside MCP modules when a project already has one source of truth.
+- Keep writes idempotent where possible. Include explicit confirmation fields or
+ idempotency keys for costly/destructive tools.
+- Pass durable identifiers, not Django model instances, request objects, lazy
+ querysets, open files, or huge payloads.
+- Paginate and cap every list/search tool. Return stable IDs and summaries, not
+ entire model dumps.
+- Add `timeout=...` on slow or externally dependent tools and make long-running
+ work enqueue a background job instead of holding the MCP request open.
+- Never let the model provide privileged identity fields in production. Inject
+ the current user/account from validated auth context or a trusted dependency.
+
+## Django Async Rules
+
+- A synchronous `def` FastMCP tool is usually simplest for Django ORM work.
+ FastMCP dispatches sync tools without blocking the event loop, and the tool
+ can use normal ORM, transactions, forms, and serializers.
+- In an `async def` tool, do not call sync ORM or other async-unsafe Django code
+ directly. Use Django async ORM methods (`aget`, `acreate`, `asave`,
+ `async for`) when they cover the operation.
+- Transactions do not work in Django async mode. Put transactional work in one
+ synchronous helper and call it with `sync_to_async(..., thread_sensitive=True)`
+ from the async tool.
+- Do not set `DJANGO_ALLOW_ASYNC_UNSAFE` to make MCP tools work. Fix the calling
+ boundary instead.
+- Because MCP calls are not Django requests, there is no normal request
+ lifecycle to clean database connections. For long-lived MCP processes, call
+ `close_old_connections()` around ORM work or centralize connection cleanup in
+ a thin helper that preserves function signatures.
+
+## Auth And Permissions
+
+- Treat MCP auth separately from Django browser auth. Django session middleware,
+ login decorators, and CSRF middleware do not automatically protect a mounted
+ Starlette/FastMCP sub-application.
+- Prefer bearer/JWT/OAuth-style auth for remote HTTP MCP servers. FastMCP auth
+ only applies to HTTP-based transports; stdio inherits the local process
+ security model.
+- Map validated token claims to Django users, organizations, and scopes before
+ calling domain services. Enforce object-level permissions inside each tool.
+- Do not expose `user_id`, `organization_id`, `is_staff`, scope lists, or
+ permission flags as LLM-controlled parameters. Use FastMCP dependency
+ injection or request/auth context to hide trusted values from the tool schema.
+- Do not rely on CORS or CSRF as an auth mechanism. Add CORS only when a browser
+ MCP client or inspector needs it, and keep allowed origins and headers narrow.
+- Mask sensitive error details in production. Return explicit, safe errors for
+ denied permissions and validation failures; log full exceptions server-side.
+
+## Resources And Prompts
+
+- Use tools for permissioned data, mutations, searches, and any result that
+ depends on the current user.
+- Use resources for bounded, read-only, low-risk content such as public docs,
+ product metadata, or static schemas. Do not publish private model tables as
+ global resources unless every client may read them.
+- Use prompts for reusable agent workflows such as "triage this customer", but
+ keep prompts free of secrets and make them call tools rather than embedding
+ stale database facts.
+
+## Deployment
+
+- Streamable HTTP is the preferred remote transport. SSE is legacy; stdio is for
+ local tools.
+- If Django is still WSGI-only, either run FastMCP as a separate HTTP sidecar or
+ migrate the deployment to ASGI before mounting it into the same process.
+- Run remote MCP behind TLS and real authentication. Avoid exposing unauthenticated
+ internal tools on a public domain.
+- For nginx or another reverse proxy, disable response buffering for MCP/SSE
+ streams and raise read/send timeouts for long operations.
+- If OAuth discovery is used under a mount prefix, verify well-known discovery
+ URLs and avoid double-prefixing `base_url` and MCP paths.
+- Keep environment parity: the MCP process needs the same `DJANGO_SETTINGS_MODULE`,
+ database URL, cache/broker settings, secret management, logging, and migrations
+ as the Django process.
+
+## Testing
+
+Use in-memory FastMCP clients for most tests. Async tests require
+`pytest-asyncio` or an equivalent async pytest plugin. Either set
+`asyncio_mode = "auto"` in pytest configuration or mark async tests explicitly
+with `@pytest.mark.asyncio`.
+
+```toml
+[tool.pytest.ini_options]
+asyncio_mode = "auto"
+```
+
+```python
+import pytest
+from fastmcp import Client
+
+from apps.core.mcp import create_mcp
+
+
+@pytest.mark.asyncio
+@pytest.mark.django_db
+async def test_get_order_summary(order, user):
+ mcp = create_mcp(actor_id_dependency=lambda: user.pk)
+
+ async with Client(mcp) as mcp_client:
+ result = await mcp_client.call_tool(
+ "get_order_summary",
+ {"order_id": order.pk},
+ )
+
+ assert result.data["id"] == order.pk
+ assert result.data["status"] == order.status
+```
+
+Testing checklist:
+
+- Assert `list_tools()` output for names, descriptions, and schemas when tool
+ contracts matter.
+- Test allowed and denied users for every permissioned tool.
+- Test invalid inputs, missing objects, pagination caps, and destructive action
+ confirmation paths.
+- Test write tools against database state and `transaction.on_commit` side
+ effects.
+- When tools use auth-injected dependencies, test through the same auth path or
+ build the server through a factory that accepts a test auth resolver. Do not
+ expose `actor_id` as an LLM parameter just to make tests easier.
+- Add one HTTP transport smoke test only when ASGI mounting, auth headers, proxy
+ behavior, or URL paths changed.
+- Use `pytest.mark.django_db(transaction=True)` when a separate server process
+ or background worker must observe committed rows.
+
+Useful local checks:
+
+```bash
+DJANGO_SETTINGS_MODULE=project.settings fastmcp list mcp_server.py
+DJANGO_SETTINGS_MODULE=project.settings fastmcp inspect mcp_server.py --format json
+fastmcp call http://localhost:8000/mcp get_order_summary order_id=1 --auth "Bearer $TOKEN"
+```
+
+## Debugging Checklist
+
+- `AppRegistryNotReady`: initialize Django before importing models, or move model
+ imports inside tools/helpers.
+- `SynchronousOnlyOperation`: sync Django code is running in an async tool. Use a
+ sync tool, async ORM methods, or `sync_to_async(..., thread_sensitive=True)`.
+- HTTP 404 or `/mcp/mcp`: check the ASGI mount prefix versus `http_app(path=...)`.
+- Session manager or stream errors: make sure the outer ASGI app uses
+ `mcp_app.lifespan`.
+- Client connects but receives no streamed results: check proxy buffering and
+ timeout settings.
+- Tool list is huge or unsafe: replace generic model/API exposure with a small
+ allowlist of agent-focused capabilities.
+- Tool schema is wrong: remove `*args`/`**kwargs`, add type annotations, avoid
+ wrappers that hide the original function signature, and inspect with
+ `fastmcp inspect`.
+- Auth appears bypassed: remember that Django middleware may not run for mounted
+ FastMCP routes. Validate tokens and enforce permissions inside the MCP layer
+ and domain services.
+
+## References
+
+- FastMCP docs: https://gofastmcp.com/getting-started/welcome
+- FastMCP GitHub: https://github.com/PrefectHQ/fastmcp
+- FastMCP HTTP deployment: https://gofastmcp.com/deployment/http
+- FastMCP tests: https://gofastmcp.com/development/tests
+- FastMCP tools: https://gofastmcp.com/servers/tools
+- FastMCP authentication: https://gofastmcp.com/servers/auth/authentication
+- FastMCP dependency injection: https://gofastmcp.com/servers/dependency-injection
+- Django async support: https://docs.djangoproject.com/en/5.2/topics/async/
+- Django ASGI deployment: https://docs.djangoproject.com/en/5.2/howto/deployment/asgi/
diff --git a/plugins/LVTD-LLC/skills/skills/fastmcp-django/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/fastmcp-django/agents/openai.yaml
new file mode 100644
index 00000000..6ccf4acb
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/fastmcp-django/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "FastMCP Django"
+ short_description: "Add MCP functionality to Django apps with FastMCP."
+ default_prompt: "Add MCP functionality to this Django app using FastMCP."
diff --git a/plugins/LVTD-LLC/skills/skills/fastmcp-django/assets/app-icon.png b/plugins/LVTD-LLC/skills/skills/fastmcp-django/assets/app-icon.png
new file mode 100644
index 00000000..f1019804
Binary files /dev/null and b/plugins/LVTD-LLC/skills/skills/fastmcp-django/assets/app-icon.png differ
diff --git a/plugins/LVTD-LLC/skills/skills/make-product-viral/SKILL.md b/plugins/LVTD-LLC/skills/skills/make-product-viral/SKILL.md
new file mode 100644
index 00000000..068487ae
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/make-product-viral/SKILL.md
@@ -0,0 +1,222 @@
+---
+name: make-product-viral
+description: Make a product, landing page, pricing page, launch page, free tool, or social preview easier to understand, buy, remember, and share using Marc Lou-inspired viral product patterns.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Make Product Viral
+ category: Marketing
+ tags: marketing,launch,cro,pricing,copywriting,shareability
+---
+
+# Make Product Viral
+
+## Attribution
+
+This skill is inspired by Marc Lou's "32 Principles of a Viral Product" post on X:
+https://x.com/marclou/status/2065385672991752210
+
+Marc framed the source ideas as patterns from five years of building startups in
+public, not as universal rules. Keep that spirit: use the principles as strong
+defaults, then adapt them to the product, audience, price point, and channel.
+
+Do not copy Marc's original post wholesale into outputs. Attribute the framework
+when the user asks where the ideas came from or when the output presents this as
+a named audit method.
+
+## Core Lens
+
+A viral product is not just a product with social sharing. It has a simple
+promise, visible product proof, low cognitive load, a clear buying path, and a
+memorable reason to talk about it.
+
+Optimize in this order:
+
+1. Can people understand it in seconds?
+2. Can they see or try the product before reading a long explanation?
+3. Is the desired outcome concrete, emotional, and memorable?
+4. Is there one obvious next action?
+5. Is trust visible before the user is asked to pay?
+6. Is the page easy to share, including its final impression and social preview?
+
+## Fast Audit
+
+Use this sequence when reviewing a product, landing page, launch page, pricing
+page, free tool, app-store surface, or OG/social preview.
+
+### 1. One Thing
+
+The product should be describable in under 10 words. The page should sell one
+main outcome, not a bundle of unrelated capabilities.
+
+Check for:
+
+- A specific audience or use case.
+- One memorable promise.
+- A clear category, alternative, or comparison anchor.
+- No hero copy that tries to serve every possible buyer at once.
+
+If the page lacks a sharp one-line description, write that before making
+lower-level suggestions.
+
+### 2. Hero That Can Sell Alone
+
+Assume many visitors will not scroll. The first viewport should answer:
+
+- What is this?
+- Who is it for?
+- What result do I get?
+- Why should I believe it?
+- What happens if I click?
+
+Prefer concrete outcomes over adjectives. Replace vague claims like "faster" or
+"better" with numbers, time saved, money made, risk reduced, or pain removed
+when evidence exists. If evidence does not exist, recommend how to gather it.
+
+### 3. Show Product Before Explaining
+
+A demo, interactive example, annotated screenshot, calculator, scanner, or short
+founder walkthrough usually beats paragraphs of copy.
+
+For AI and software products, look for a way to let users experience the payoff
+on the page before they create an account. If a hard paywall is appropriate,
+still show enough product proof to create desire and trust.
+
+### 4. One Screen, One Idea
+
+Each major section should communicate one idea:
+
+- problem
+- product proof
+- outcome
+- social proof
+- pricing
+- comparison
+- objections
+- final shareable close
+
+If a section mixes several arguments, split it or cut it until the scan path is
+obvious.
+
+### 5. CTA Clarity
+
+Use one primary CTA. The CTA should say what happens next, not a generic action.
+
+Weak patterns:
+
+- Get Started
+- Learn More
+- Submit
+
+Stronger patterns:
+
+- Analyze My Website
+- Generate My Launch Page
+- See Pricing
+- Buy the Template
+- Run the Audit
+
+Only include a secondary CTA when it serves the same buying journey, such as
+watching a demo or viewing pricing.
+
+### 6. Pricing And Paywall
+
+For simple indie products, default to clear paid validation over free-user
+accumulation unless the business model truly depends on a free tier.
+
+Consider:
+
+- Is pricing visible from navigation or early page flow?
+- Are there three or fewer choices?
+- Is one plan the obvious best fit?
+- Could a one-time payment sell better than a subscription?
+- Does the product need a tight trial with payment required, especially for
+ app-store-style products?
+
+Do not apply this blindly. SaaS with recurring infrastructure, collaboration,
+ongoing service delivery, or high expansion value may need subscriptions.
+Freemium can work when free usage is a distribution channel, proof engine, or
+network-effect driver.
+
+### 7. Copy Only This Founder Could Write
+
+Generic copy is easy to ignore and easy to copy. Look for founder experience,
+specific customer language, sharp opinions, or proof from real use.
+
+Use customer words when available. If customer research is missing, ask for
+reviews, support tickets, DMs, interviews, beta feedback, or demo-call notes
+before inventing proof.
+
+### 8. Trust Before Traffic
+
+Do not send serious launch traffic to a page with no proof.
+
+Minimum proof can include:
+
+- specific beta-user quotes
+- founder demo video
+- named testimonials
+- before-and-after examples
+- public build-in-progress evidence
+- case-study numbers
+- credible comparison against alternatives
+
+If testimonials do not exist, recommend a beta-feedback sprint before a bigger
+launch.
+
+### 9. Social Preview As Thumbnail
+
+Treat the OG image like a YouTube thumbnail: it should earn the click without
+requiring the full page.
+
+Check for:
+
+- one clear message
+- strong contrast
+- readable text if text is used
+- recognizable product, result, or emotion
+- no dense screenshot walls
+- no tiny UI text that only makes sense after zooming
+
+Marc clarified in the thread that overly text-heavy thumbnails can fail because
+people will not stop to decode them. If the OG image has a lot of text, ask:
+"How would this look with roughly 180 characters or less?"
+
+### 10. Memorable Final Impression
+
+The footer or final section should not feel like a dead end. End with something
+people can remember or share:
+
+- a strong one-line promise
+- a pointed comparison
+- a founder note
+- a compact demo or result
+- a final CTA tied to the product's core action
+
+## Output Format
+
+When using this skill, respond with:
+
+1. **Viral diagnosis:** the main reason this is or is not likely to spread.
+2. **Highest-leverage fixes:** 3 to 7 changes, ordered by impact.
+3. **Hero rewrite:** headline, subhead, CTA, and proof or demo suggestion.
+4. **Shareability pass:** OG image, footer or final impression, and one-line
+ description.
+5. **Pricing or paywall note:** only if relevant.
+6. **Validation plan:** what to check before launch.
+
+Keep recommendations concrete. Prefer replacement copy, section order, product
+proof, pricing structure, and specific UI/content changes over abstract advice.
+
+## Caveats
+
+- Attribute the source when presenting the framework: inspired by Marc Lou's
+ viral product principles.
+- Treat the principles as strong defaults, not commandments.
+- Avoid fake testimonials, fake scarcity, manipulative claims, or unsupported
+ numbers.
+- Strong claims need evidence. If evidence is missing, recommend how to gather
+ it.
+- Do not let "viral" override usefulness. A product that spreads but disappoints
+ users creates the wrong kind of attention.
diff --git a/plugins/LVTD-LLC/skills/skills/make-product-viral/assets/app-icon.png b/plugins/LVTD-LLC/skills/skills/make-product-viral/assets/app-icon.png
new file mode 100644
index 00000000..0ca882b9
Binary files /dev/null and b/plugins/LVTD-LLC/skills/skills/make-product-viral/assets/app-icon.png differ
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/SKILL.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/SKILL.md
new file mode 100644
index 00000000..4e9094ec
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/SKILL.md
@@ -0,0 +1,56 @@
+---
+name: product-led-seo-strategy
+description: Create product-led SEO strategies that turn product value, user intent, page architecture, taxonomy, and scalable user experiences into organic growth. Use when a user asks for SEO strategy, organic growth planning, content/product SEO, programmatic SEO direction, search moat creation, or wants to avoid keyword-list SEO.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Product-Led SEO Strategy
+ category: Marketing
+ tags: seo,organic-growth,product-led-growth,content-strategy,marketing
+---
+
+# Product-Led SEO Strategy
+
+Use this skill to plan SEO from the product outward: who the user is, what they need, what product surface can satisfy that need, how the site architecture scales, and how the work compounds over time.
+
+This skill is derived from Eli Schwartz's *Product-Led SEO* and uses transformed guidance with durable book-topic references. Do not copy book prose into user outputs.
+
+## Quick Start
+
+1. Load `guidelines.md` to choose the smallest useful reference set.
+2. Use `workflows/create-seo-strategy.md` for a full strategy.
+3. Anchor recommendations in user demand, product usefulness, and business outcomes.
+4. Treat keyword data as supporting evidence, not the starting point.
+5. Deliver concrete product/page ideas, required teams, measurement plan, and risks.
+
+## Default Output
+
+When the user asks for a strategy, return:
+
+1. **Strategic thesis** - the user demand and product-led SEO angle.
+2. **Product surface** - pages, templates, taxonomy, tools, databases, or content experiences to build.
+3. **Moat** - why this is difficult to copy.
+4. **Execution plan** - phases, owners, dependencies, and launch sequence.
+5. **Measurement** - impressions, clicks, conversions, business proxy metrics, and learning loops.
+6. **Risks** - weak assumptions, technical constraints, content quality, and resource gaps.
+7. **Next actions** - the first 3-7 tasks.
+
+## Contents
+
+| Need | Start Here |
+|------|------------|
+| Understand the model | `references/core/knowledge.md` |
+| Apply strategy rules | `references/core/rules.md` |
+| See examples and rewrites | `references/core/examples.md` |
+| Build a full plan | `workflows/create-seo-strategy.md` |
+| Route by task | `guidelines.md` |
+
+## Core Posture
+
+- Start with real users and product value.
+- Prefer scalable product surfaces over isolated keyword pages.
+- Create search demand or capture long-tail demand where tools undercount volume.
+- Use content only when it helps the user do something useful.
+- Plan for compounding: slow early signals can become durable growth.
+- Keep strategy stable while tactics adapt to user behavior and search changes.
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/agents/openai.yaml
new file mode 100644
index 00000000..f358d298
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Product-Led SEO Strategy"
+ short_description: "Plan SEO around product and user value."
+ default_prompt: "Create a product-led SEO strategy for this product."
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/assets/app-icon.png b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/assets/app-icon.png
new file mode 100644
index 00000000..ede82b5d
Binary files /dev/null and b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/assets/app-icon.png differ
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/guidelines.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/guidelines.md
new file mode 100644
index 00000000..5025f969
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/guidelines.md
@@ -0,0 +1,45 @@
+# Product-Led SEO Strategy Guidelines
+
+Load the minimum files needed for the task.
+
+## By Task
+
+| What you're doing | Load these files |
+|-------------------|------------------|
+| Creating a full SEO strategy | `references/core/knowledge.md`, `references/core/rules.md`, `workflows/create-seo-strategy.md` |
+| Reviewing an existing SEO plan | `references/core/rules.md`, `references/core/examples.md` |
+| Turning a product into organic growth surfaces | `references/core/knowledge.md`, `references/core/examples.md` |
+| Replacing a keyword-list roadmap | `references/core/rules.md`, `workflows/create-seo-strategy.md` |
+| Explaining product-led SEO to stakeholders | `references/core/knowledge.md` |
+
+## By Problem
+
+| If you notice... | Load these files |
+|------------------|------------------|
+| The plan starts with keyword volume and blog posts | `references/core/rules.md` |
+| The user wants "programmatic SEO" but has no user-value thesis | `references/core/knowledge.md`, `workflows/create-seo-strategy.md` |
+| Content is being treated as output rather than a business tool | `references/core/rules.md`, `references/core/examples.md` |
+| The proposal has no moat or defensibility | `references/core/knowledge.md`, `references/core/examples.md` |
+| Metrics are only rankings or traffic | `references/core/rules.md` |
+
+## Decision Tree
+
+```text
+What is the user asking for?
+|
++-- Full strategy -> create-seo-strategy workflow
++-- Critique a plan -> rules + examples
++-- Explain the concept -> knowledge
++-- Fix keyword/content thinking -> rules
++-- Find opportunities -> prefer seo-opportunity-research skill
++-- Build roadmap/resources -> prefer seo-roadmap-prioritization skill
+```
+
+## File Index
+
+| File | Purpose |
+|------|---------|
+| `references/core/knowledge.md` | Concepts, terminology, and source anchors |
+| `references/core/rules.md` | Strategic rules and anti-patterns |
+| `references/core/examples.md` | Scenario examples and better framing |
+| `workflows/create-seo-strategy.md` | Repeatable strategy workflow |
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/examples.md
new file mode 100644
index 00000000..8b4858e2
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/examples.md
@@ -0,0 +1,46 @@
+# Product-Led SEO Strategy Examples
+
+Scenario examples for turning SEO from keyword execution into product strategy.
+
+## Weak vs Strong Framing
+
+### Keyword-First Blog Plan
+
+**Weak frame**: "Find 100 high-volume keywords and publish posts until traffic grows."
+
+**Problems**:
+- Competitors can use the same keyword list.
+- The plan may attract visitors who do not match the product.
+- It creates publishing work without a durable asset.
+
+**Product-led frame**: "Identify a repeatable user problem, build a page or tool that solves it, and scale that surface through templates, taxonomy, and internal links."
+
+## Product Surface Examples
+
+| Situation | Product-Led Surface | Why It Works |
+|-----------|--------------------|--------------|
+| SaaS with many integrations | Integration pair pages | Captures specific jobs users search for and can scale from product data |
+| Marketplace with inventory | Category and item pages | Search surface mirrors actual available supply |
+| Health or finance product | Useful calculators, explainers, or databases | Satisfies high-trust user needs better than generic posts |
+| Support-heavy product | Searchable help and troubleshooting pages | Reduces support cost while capturing problem-aware searches |
+| Local or multi-location business | Location/service pages with real local utility | Avoids thin city duplication by adding user-relevant detail |
+
+## Strategy Rewrite
+
+### Before
+
+"We should rank for the highest-volume keywords in our category."
+
+### After
+
+"We should build the search surface only our product can support: a structured library of user problems, product-specific answers, and next-step CTAs. We will judge progress by non-brand impressions, clicks, qualified actions, and learning that improves the product."
+
+## Moat Questions
+
+Use these to stress-test an idea:
+
+1. What can we build that a generic publisher cannot?
+2. What data, inventory, workflow, community, or expertise do we uniquely have?
+3. Does this surface get better as more users interact with it?
+4. Can it expand into adjacent page types once it works?
+5. Would users still value this page if search engines disappeared?
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/knowledge.md
new file mode 100644
index 00000000..05d5718a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/knowledge.md
@@ -0,0 +1,71 @@
+# Product-Led SEO Strategy Knowledge
+
+Core concepts for building SEO strategy around product value rather than keyword lists.
+
+## Source References
+
+| Topic | Durable Reference |
+|-------|-------------------|
+| Drops example and product-led framing | *Product-Led SEO*, product-led strategy framing |
+| Keyword-driven vs product-led approach | *Product-Led SEO*, strategy over keyword-first planning |
+| Product-led successes and scalable architecture | *Product-Led SEO*, scalable product and page architecture examples |
+| Content as a business tool | *Product-Led SEO*, content as a business and user-progress tool |
+| Blue Ocean SEO and right questions | *Product-Led SEO*, Blue Ocean SEO strategy |
+| Multidisciplinary implementation | *Product-Led SEO*, organizational implementation and cross-functional execution |
+
+## Key Concepts
+
+### Product-Led SEO
+
+**Definition**: An SEO strategy where the product, page architecture, data, taxonomy, or user experience creates the search asset.
+
+Product-led SEO asks what useful thing the business can build for search users. The answer may be a template system, directory, database, calculator, comparison surface, support library, marketplace inventory, or content experience.
+
+### Product Surface
+
+**Definition**: The repeatable experience a search user lands on.
+
+Examples include item detail pages, location pages, integration pages, condition pages, product comparison pages, glossary entries, and searchable indexes. The surface should satisfy user intent without feeling like thin keyword content.
+
+### SEO Moat
+
+**Definition**: A search acquisition advantage that is difficult to copy because it depends on product depth, data, architecture, brand, user behavior, or operational effort.
+
+A moat is weak when competitors can reproduce it with a keyword tool and freelance content. It is stronger when it requires engineering, proprietary data, community contribution, inventory, or hard-won user insight.
+
+### Compounding SEO
+
+**Definition**: Organic growth that improves as pages are discovered, queries expand, links accrue, and user signals reinforce visibility.
+
+Early metrics can be modest. The strategic question is whether the surface can compound without continuously buying or writing one-off assets.
+
+### Content As Tool
+
+**Definition**: Content is useful only when it helps the user progress toward a goal and supports a business outcome.
+
+Avoid creating content for word count, keyword inclusion, or arbitrary publishing volume. Use content as part of the product experience.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Non-brand search | Search demand not dependent on already knowing the brand |
+| Search product | A product surface intentionally built to satisfy search users |
+| Blue Ocean SEO | SEO based on unmet or under-measured user demand |
+| Red Ocean SEO | SEO based on obvious keywords that many competitors can target |
+| Taxonomy | The structured classification that determines pages, internal links, and scalable coverage |
+| Template quality | The repeatable UX and content quality of generated or programmatic pages |
+
+## Common Misconceptions
+
+- **Myth**: Keyword volume should define the roadmap.
+ **Reality**: Keyword data can miss demand that does not exist yet or is expressed in long-tail forms.
+
+- **Myth**: A content calendar is an SEO strategy.
+ **Reality**: Publishing is only useful when it serves a user need and business goal.
+
+- **Myth**: Backlinks are always the first lever.
+ **Reality**: Strong product surfaces can earn links as a byproduct of usefulness.
+
+- **Myth**: SEO is a marketing-only function.
+ **Reality**: Product-led SEO usually needs product, engineering, design, content, data, and executive support.
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/rules.md
new file mode 100644
index 00000000..fbbf608a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/references/core/rules.md
@@ -0,0 +1,61 @@
+# Product-Led SEO Strategy Rules
+
+Use these rules when designing or reviewing an SEO strategy.
+
+## Core Rules
+
+### 1. Start With Users, Not Keywords
+
+Identify who searches, what they are trying to accomplish, and what useful surface the product can provide.
+
+- Use keyword data after the user hypothesis exists.
+- Treat missing search volume as a research signal, not an automatic rejection.
+- Avoid head terms when they do not describe real buyer behavior.
+
+### 2. Build Something Worth Landing On
+
+The page should be a useful product experience, not an article dressed up for search.
+
+- Match the content depth to intent and funnel stage.
+- Make the template useful even when scaled.
+- Do not add words that confuse the user for the sake of SEO.
+
+### 3. Prefer Scalable Architecture Over One-Off Posts
+
+When a repeatable search pattern exists, design taxonomy, page templates, internal linking, and ownership before writing pages.
+
+- Ask whether the opportunity can scale across many useful pages.
+- Define the page type, data source, and internal linking model.
+- Plan for future adjacent surfaces if the first surface works.
+
+### 4. Create A Moat
+
+Favor ideas competitors cannot copy quickly.
+
+- Use proprietary data, product workflows, inventory, user-generated data, or operational expertise.
+- Avoid plans that are just "write more/better content for the same keywords."
+- State why the business is uniquely able to build the surface.
+
+### 5. Use Content As A Business Tool
+
+Every content asset should have a user job and a business job.
+
+- Tie the asset to a CTA, next step, conversion, retention, support reduction, or learning goal.
+- Cut content that exists only to hit a word count or keyword target.
+- Measure content after launch and improve or remove weak surfaces.
+
+### 6. Plan For Compounding
+
+Product-led SEO usually needs patience.
+
+- Define early indicators: impressions, crawl/indexation, query expansion, and engagement.
+- Explain why near-term traffic may be modest.
+- Keep investing only if the learning loop supports the thesis.
+
+## Red Flags
+
+- The strategy can be copied by anyone with a keyword tool.
+- The plan does not say what product or page surface will be built.
+- The business goal is "rank higher" rather than acquire, convert, assist, retain, or reduce cost.
+- Engineering, design, data, or product work is needed but absent from the plan.
+- The content is not useful without the search engine.
diff --git a/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/workflows/create-seo-strategy.md b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/workflows/create-seo-strategy.md
new file mode 100644
index 00000000..6f0b3923
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/product-led-seo-strategy/workflows/create-seo-strategy.md
@@ -0,0 +1,84 @@
+# Create SEO Strategy Workflow
+
+Use this workflow to create or revise a product-led SEO strategy.
+
+## When to Use
+
+- The user asks for organic growth or SEO strategy.
+- The current plan starts with keyword research or a content calendar.
+- The business has product, data, inventory, or expertise that could become a search surface.
+
+## Prerequisites
+
+- Product or website description.
+- Target users or customer segments.
+- Business goal: revenue, leads, signups, support reduction, marketplace supply/demand, or another outcome.
+- Current organic performance if available.
+
+**Reference**: `references/core/knowledge.md`, `references/core/rules.md`
+
+## Workflow Steps
+
+### Step 1: Define The User Demand
+
+**Goal**: Name the search user and the job they need done.
+
+- [ ] Identify 2-5 user segments.
+- [ ] Describe what each segment is trying to learn, compare, solve, buy, or complete.
+- [ ] Separate brand demand from non-brand demand.
+- [ ] Note where keyword tools may undercount demand.
+
+### Step 2: Choose The Product Surface
+
+**Goal**: Decide what useful thing the company should build.
+
+- [ ] List possible surfaces: tool, directory, database, template page, comparison, support library, glossary, calculator, or marketplace page.
+- [ ] For each surface, define the repeatable template and required data.
+- [ ] Reject surfaces that are just generic articles unless content is the product.
+- [ ] Pick the surface with the best combination of user value, scale, and defensibility.
+
+### Step 3: Design Architecture And Moat
+
+**Goal**: Make the surface crawlable, useful, and hard to copy.
+
+- [ ] Define taxonomy and URL patterns.
+- [ ] Define internal linking paths.
+- [ ] Identify data sources and content generation process.
+- [ ] State why the business can build this better than competitors.
+- [ ] Identify engineering, design, content, data, and product dependencies.
+
+### Step 4: Define Measurement
+
+**Goal**: Track learning and business impact.
+
+- [ ] Select early metrics: indexation, impressions, query breadth, and template coverage.
+- [ ] Select mid metrics: clicks, CTR, engagement, CTA clicks, assisted conversions.
+- [ ] Select business metrics: leads, signups, revenue, downloads, support deflection, or retention.
+- [ ] Explain the expected lag before compounding is visible.
+
+### Step 5: Build The Plan
+
+**Goal**: Turn strategy into a credible roadmap.
+
+- [ ] Define the MVP surface and first launch scope.
+- [ ] Define phase 2 expansion triggers.
+- [ ] List risks and assumptions.
+- [ ] Identify first experiments.
+- [ ] Produce a 30/60/90-day plan or quarterly plan depending on user need.
+
+## Common Mistakes
+
+| Mistake | Why It's Bad | Do Instead |
+|---------|--------------|------------|
+| Starting with top-volume keywords | Creates copyable Red Ocean work | Start with user demand and unique product capability |
+| Calling blog output a strategy | Output is not the same as value | Define the product surface and business outcome |
+| Ignoring engineering/design | Product-led SEO is cross-functional | Name dependencies up front |
+| Reporting rankings only | Rankings do not prove business impact | Report impressions, clicks, conversions, and business proxies |
+
+## Exit Criteria
+
+Task is complete when:
+
+- [ ] The strategy names the user, product surface, moat, metrics, and roadmap.
+- [ ] The plan explains why keyword data is supporting evidence, not the driver.
+- [ ] The first implementation step is concrete enough for an owner to start.
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/SKILL.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/SKILL.md
new file mode 100644
index 00000000..032dc2b8
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/SKILL.md
@@ -0,0 +1,96 @@
+---
+name: reader-experience-edit
+description: Audit and revise practical nonfiction drafts for reader experience, value pacing, front-loaded insight, value-per-page, boredom, and beta-readiness. Use when editing, restructuring, shortening, or reviewing a book, guide, manual, course-like manuscript, or long-form educational draft so readers receive useful value quickly and keep reading.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Reader Experience Edit
+ category: Writing
+ tags: writing,books,nonfiction,editing,reader-experience
+---
+
+# Reader Experience Edit
+
+## Core Lens
+
+Treat reader experience as value received over time spent. Practical nonfiction does not keep readers engaged through suspense; it keeps them engaged by regularly delivering the outcome promised by the book.
+
+Use this skill to diagnose and improve:
+
+- Slow starts.
+- Long stretches of theory before payoff.
+- Low value-per-page.
+- Sections whose value is unclear.
+- Drafts that need to be coherent enough for beta readers, not polished enough for publication.
+
+## Reference Routing
+
+| Need | Read |
+|------|------|
+| Core concepts and terminology | `references/core/knowledge.md` |
+| Revision rules and decision criteria | `references/core/rules.md` |
+| Before/after patterns | `references/core/examples.md` |
+| Fast audit checklist | `references/core/checklist.md` |
+| Step-by-step manuscript audit | `workflows/audit-manuscript.md` |
+
+## Workflow
+
+### 1. Anchor On The Promise
+
+Identify:
+
+- Target reader.
+- Book promise.
+- First meaningful piece of value.
+- What the reader should be able to do, decide, or understand after each major section.
+
+If the promise is unclear, use `book-toc-lab` before editing the manuscript.
+
+### 2. Create A Value Map
+
+Build a table:
+
+```text
+Section | Word count | Reader takeaway | Value type | Risk
+```
+
+Use it to find:
+
+- Slow start: too many words before first value.
+- Long slog: back-to-back sections without strong takeaways.
+- Fluff: high word count relative to reader value.
+
+### 3. Front-Load Value
+
+Look for ways to deliver the first useful result earlier:
+
+- Cut front matter.
+- Insert real value into theory sections.
+- Start with the main insight, tool, checklist, example, or result.
+- Move background after the reader has a reason to care.
+
+### 4. Increase Value-Per-Page
+
+Prefer deletion before addition.
+
+- Cut anything outside the target reader's scope.
+- Replace general motivation with concrete examples.
+- Compress explanations that do not change reader behavior.
+- Save deleted material in a separate cutting-room-floor note when useful.
+
+### 5. Prepare For Beta Readers
+
+Do not aim for perfect prose yet. Aim for a draft that is coherent enough for motivated readers to identify real problems.
+
+Return:
+
+1. Main reader-experience diagnosis.
+2. Value map or section-by-section risk table.
+3. Highest-leverage cuts, moves, and rewrites.
+4. Revised opening or TOC recommendations when relevant.
+5. Beta-readiness note: what must be fixed before readers see it.
+
+## Quality Bar
+
+Recommendations should be structural and specific. Prefer "move this section after X", "cut this setup", or "turn this theory into a worked example" over generic writing advice.
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/checklist.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/checklist.md
new file mode 100644
index 00000000..b950a93a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/checklist.md
@@ -0,0 +1,58 @@
+# Reader Experience Checklist
+
+Use this checklist when reviewing a practical nonfiction draft.
+
+## Before You Start
+
+- [ ] Target reader is defined.
+- [ ] Book promise is clear.
+- [ ] Draft or TOC has section headings.
+- [ ] Approximate word counts are available or can be estimated.
+
+## Value Pacing
+
+- [ ] First meaningful value appears early.
+- [ ] Each chapter has a clear reader takeaway.
+- [ ] Back-to-back theory sections are broken up with actual value.
+- [ ] Long sections justify their length with proportionate payoff.
+- [ ] The opening receives extra scrutiny.
+
+## Section Audit
+
+- [ ] Each section answers "what does the reader gain here?"
+- [ ] Examples are close to the target reader's situation.
+- [ ] Claims that may trigger skepticism are supported.
+- [ ] Repeated motivation is removed.
+- [ ] Tool-specific or time-sensitive tangents are moved out when possible.
+
+## Deletion Pass
+
+- [ ] Cut or compress weak front matter.
+- [ ] Cut sections outside the reader profile.
+- [ ] Cut sentences that create avoidable drama or confusion.
+- [ ] Move deleted material to a cutting-room-floor note if useful.
+- [ ] Check whether cuts improved the reader's path.
+
+## Beta-Readiness
+
+- [ ] The manuscript is coherent enough for a motivated reader.
+- [ ] The draft is not over-polished.
+- [ ] Structural concerns are addressed before sentence-level concerns.
+- [ ] The author knows what kind of feedback to request.
+
+## Red Flags
+
+- The first chapter mostly explains why the topic matters.
+- The author says "they need this background" but cannot name the next action it enables.
+- The most useful content appears late.
+- The draft gets longer every revision.
+- The author is polishing sentences before testing structure.
+
+## Quick Reference
+
+| Aspect | Ideal | Acceptable | Red Flag |
+|--------|-------|------------|----------|
+| Start | Immediate useful payoff | Quick setup then payoff | Long throat-clearing |
+| Theory | Supports near-term action | Brief orientation | Front-loaded lecture |
+| Length | Every section earns words | Some compression needed | Value buried |
+| Draft state | Beta-ready | Slightly rough | Over-polished or incoherent |
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/examples.md
new file mode 100644
index 00000000..477e19ce
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/examples.md
@@ -0,0 +1,93 @@
+# Reader Experience Examples
+
+Synthetic examples for revising useful nonfiction.
+
+## Slow Start
+
+### Before
+
+```text
+Chapter 1: Why Meetings Matter
+- History of meetings
+- Why remote work changed everything
+- Problems with collaboration
+- A personal story about bad meetings
+- The five-part meeting reset
+```
+
+**Problems**:
+- The reader waits too long for a useful tool.
+- Background comes before payoff.
+- The chapter title promises motivation, not action.
+
+### After
+
+```text
+Chapter 1: Diagnose Why Your Remote Meetings Waste Time
+- The three-question meeting diagnosis
+- Example: a status meeting that should be async
+- The five-part meeting reset
+- Why remote work makes old meeting habits worse
+```
+
+**Why it works**:
+- The reader gets a diagnostic immediately.
+- Theory supports a tool the reader already used.
+- The promise is practical and testable.
+
+## Value Enabler To Actual Value
+
+### Before
+
+```text
+To understand customer interviews, we first need to understand the history of market research and the difference between qualitative and quantitative methods.
+```
+
+**Problem**: Accurate, but it delays the reader's goal.
+
+### After
+
+```text
+Before your next customer call, replace "Would you buy this?" with "How are you solving this today?" The second question reveals real behavior instead of polite prediction. The research theory can wait until after the reader has seen the difference.
+```
+
+**Why it works**:
+- Gives a usable action first.
+- Explains the theory only as much as needed.
+
+## Cutting Decision
+
+### Keep
+
+- A checklist the reader can apply immediately.
+- A worked example that resolves confusion.
+- A caveat that prevents misuse.
+- A story that proves the reader's problem is real.
+
+### Cut Or Move
+
+- A second story proving the same point.
+- A tool tutorial likely to go out of date.
+- A personal aside that does not change reader behavior.
+- A long definition before the reader knows why it matters.
+
+## Beta-Ready Standard
+
+### Too Early
+
+- The outline is vague.
+- Sections do not yet connect.
+- The first useful payoff is missing.
+
+### Ready Enough
+
+- The promise is clear.
+- The reader can follow the chapter sequence.
+- The draft contains enough value for readers to react to.
+- The author expects structural feedback and is willing to revise.
+
+### Too Late
+
+- The author has copyedited everything.
+- The design is emotionally hard to change.
+- Feedback will mostly be typos, praise, and small wording suggestions.
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/knowledge.md
new file mode 100644
index 00000000..e45d7d6c
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/knowledge.md
@@ -0,0 +1,87 @@
+# Reader Experience Knowledge
+
+Core concepts for editing useful nonfiction so readers keep receiving value.
+
+## Overview
+
+Reader experience is the pacing and placement of value. A useful book should regularly give the reader something they can use, understand, decide, or feel progress from.
+
+## Key Concepts
+
+### Reader Experience
+
+**Definition**: The felt sequence of value, effort, confusion, and momentum while reading.
+
+Readers may not name reader experience directly, but they reveal it through skimming, comments, reviews, abandonment, and recommendations.
+
+### Value-Per-Page
+
+**Definition**: The density of useful reader payoff relative to reading time.
+
+A short section can have low value-per-page if it delays the payoff. A long section can work if every part earns attention.
+
+### Value Enabler
+
+**Definition**: Background, theory, context, definitions, setup, or tooling that enables future value but is not itself the value the reader came for.
+
+Value enablers are necessary in many books, but they become dangerous when they appear before readers have received enough real value to trust the journey.
+
+### Actual Value
+
+**Definition**: A piece of content that directly helps the reader solve the problem or reach the promised outcome.
+
+Examples include an insight, checklist, decision rule, script, example, diagnosis, template, or concrete next action.
+
+### Slow Start
+
+**Definition**: Too many words before the first meaningful reader payoff.
+
+Slow starts are risky because abandonment is most likely early, before the reader has banked enough value to forgive weaker sections.
+
+### Long Slog
+
+**Definition**: A run of sections where payoff is delayed, obvious, repetitive, or too abstract.
+
+Long slogs often appear when the author orders content by their expert model instead of the reader's goal.
+
+### Cutting Room Floor
+
+**Definition**: A separate place to preserve deleted sections, examples, and tangents.
+
+Keeping a cutting room floor lowers the emotional cost of deletion and creates raw material for future articles, bonuses, or marketing.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| A-ha moment | A point where the reader gets a useful, memorable insight. |
+| Front-loading | Moving meaningful value earlier in the draft. |
+| Fluff | Words that delay, dilute, or distract from the promised value. |
+| Beta-ready | Coherent enough for readers to expose big problems, not polished for publication. |
+
+## How It Relates To
+
+- **Book TOC Lab**: TOC design predicts value pacing before drafting.
+- **Beta Reader Feedback**: Beta comments and abandonment reveal where reader experience fails.
+- **Seed Marketing**: Strong reader experience creates the satisfaction needed for word of mouth.
+
+## Common Misconceptions
+
+- **Myth**: Readers need all the theory first.
+ **Reality**: Readers usually need a useful payoff first, then they will tolerate more theory.
+
+- **Myth**: A draft improves mainly by adding better material.
+ **Reality**: Many drafts improve fastest by cutting, moving, and compressing material that delays value.
+
+- **Myth**: The draft should be polished before beta readers see it.
+ **Reality**: Over-polishing hides big problems and makes readers reluctant to give structural feedback.
+
+## Quick Reference
+
+| Concept | One-Line Summary |
+|---------|------------------|
+| Reader experience | Value delivered over reading time. |
+| Value enabler | Setup needed for value, but not value itself. |
+| Value-per-page | Useful payoff density. |
+| Front-loading | Deliver meaningful value earlier. |
+| Beta-ready | Coherent enough to test, imperfect enough to improve. |
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/rules.md
new file mode 100644
index 00000000..a35c1d28
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/references/core/rules.md
@@ -0,0 +1,78 @@
+# Reader Experience Rules
+
+Use these rules when editing practical nonfiction for engagement and usefulness.
+
+## Core Rules
+
+### 1. Deliver Value Early
+
+Put a meaningful insight, action, example, or diagnostic near the beginning.
+
+- Cut or compress throat-clearing.
+- Move author bio, motivation, and broad context later unless they are essential.
+- Let the reader experience progress before asking for patience.
+
+### 2. Order By Reader Goals
+
+Arrange content by what the reader is trying to achieve, not by how the expert mentally organizes the field.
+
+- Teach only enough foundation for the next useful action.
+- Alternate value enablers with actual value.
+- Use examples before abstractions when confusion is likely.
+
+### 3. Track Value Against Word Count
+
+Add approximate word counts to the TOC or section list.
+
+- Flag sections with high word count and weak takeaway.
+- Flag back-to-back setup sections.
+- Flag chapters whose first major value appears late.
+
+### 4. Delete Before Adding
+
+When engagement drops, try cutting first.
+
+- Delete repeated motivation.
+- Delete tangents outside the reader profile.
+- Delete sentences that create disproportionate confusion or debate.
+- Move useful but nonessential material to a companion resource.
+
+### 5. Keep The Strongest Start
+
+Spend disproportionate revision energy on the opening.
+
+- A strong start can carry readers through a weaker later section.
+- A strong ending cannot rescue a disappointing beginning.
+- Prepare only enough draft to begin useful beta reading when the manuscript is modular.
+
+### 6. Stop At Beta-Ready
+
+Do not polish every sentence before beta reading.
+
+- Fix structure, clarity, and major reader experience problems.
+- Leave minor grammar and wording issues for later.
+- Show readers something imperfect enough that they will give useful feedback.
+
+## Guidelines
+
+- If a section does not create value, justify value, or enable near-term value, cut it.
+- Convert abstract sections into examples, checklists, questions, or actions.
+- Preserve deleted material outside the manuscript so the author can let it go.
+- Treat boredom as a design failure, not a reader failure.
+
+## Exceptions
+
+- **Literary nonfiction**: Atmosphere and voice may be part of value, but they still need to serve the reader promise.
+- **Reference works**: Readers may skip around, so value must be clear at the section level.
+- **Expert audiences**: More theory can appear earlier if the audience already wants it and knows why it matters.
+
+## Quick Reference
+
+| Rule | Summary |
+|------|---------|
+| Deliver value early | Give readers progress before patience is required. |
+| Reader goals | Sequence by learner need, not expert taxonomy. |
+| Track word count | Find slow starts, slogs, and fluff. |
+| Delete first | Improve value density before adding more. |
+| Strong start | Earlier sections deserve extra attention. |
+| Beta-ready | Coherent beats polished before reader testing. |
diff --git a/plugins/LVTD-LLC/skills/skills/reader-experience-edit/workflows/audit-manuscript.md b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/workflows/audit-manuscript.md
new file mode 100644
index 00000000..222cae5b
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/reader-experience-edit/workflows/audit-manuscript.md
@@ -0,0 +1,84 @@
+# Audit Manuscript Workflow
+
+Use this workflow to audit a nonfiction draft for reader experience.
+
+## When To Use
+
+- A manuscript feels boring, bloated, or hard to finish.
+- A practical guide needs stronger early value.
+- The author wants to prepare a draft for beta readers.
+
+## Prerequisites
+
+- Draft manuscript, detailed outline, or chapter list.
+- Target reader and book promise.
+
+**Reference**: `references/core/rules.md`
+
+---
+
+## Workflow Steps
+
+### Step 1: Anchor The Audit
+
+**Goal**: Know what value the draft is supposed to deliver.
+
+- [ ] Identify the target reader.
+- [ ] State the book promise.
+- [ ] Identify the first major reader payoff.
+- [ ] Note any known constraints, such as deadline or beta-reader date.
+
+---
+
+### Step 2: Build A Value Map
+
+**Goal**: See reader value over time.
+
+- [ ] Create a table of sections or chapters.
+- [ ] Add approximate word counts.
+- [ ] Add the main reader takeaway for each section.
+- [ ] Mark each section as actual value, value enabler, proof, example, or transition.
+
+---
+
+### Step 3: Identify Reader Experience Risks
+
+**Goal**: Find slow starts, slogs, and fluff.
+
+- [ ] Flag how many words pass before the first useful payoff.
+- [ ] Flag sections with weak takeaways and high word count.
+- [ ] Flag runs of setup without actual value.
+- [ ] Flag sections outside the target reader's scope.
+- [ ] Flag likely confusion or skepticism points.
+
+**Reference**: `references/core/checklist.md`
+
+---
+
+### Step 4: Recommend Structural Edits
+
+**Goal**: Improve value density and pacing.
+
+- [ ] Move useful material earlier.
+- [ ] Cut or compress front matter.
+- [ ] Turn theory into examples, checklists, questions, or actions.
+- [ ] Delete tangents or move them to companion material.
+- [ ] Suggest a revised opening sequence if needed.
+
+---
+
+### Step 5: Decide Beta-Readiness
+
+**Goal**: Stop polishing at the right level.
+
+- [ ] Confirm the draft is coherent enough for motivated readers.
+- [ ] List fixes required before beta readers see it.
+- [ ] List issues that should wait until after beta feedback.
+
+## Exit Criteria
+
+Task is complete when:
+
+- [ ] The main reader-experience problem is named.
+- [ ] The author has an ordered edit list.
+- [ ] The draft has a clear path toward beta reading or the next revision.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/SKILL.md
new file mode 100644
index 00000000..9a123c93
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/SKILL.md
@@ -0,0 +1,183 @@
+---
+name: rust-api-test-harness
+description: Use when adding, changing, testing, or debugging Rust HTTP APIs and services, especially when Codex needs black-box integration tests, random-port app startup, real database test isolation, external HTTP mocks, or CI-ready cargo verification for Actix, Axum, Warp, Rocket, or similar Rust web frameworks.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust API Test Harness
+ category: Rust
+ tags: rust,api-testing,integration-tests,backend
+---
+
+# Rust API Test Harness
+
+Use this skill to make Rust API work test-first, reproducible, and CI-ready.
+Prefer black-box tests that exercise the service through HTTP and verify
+observable behavior rather than reaching through framework internals.
+
+## Core Workflow
+
+1. Inspect the project first: `Cargo.toml`, workspace layout, existing `src/main.rs`,
+ `src/lib.rs`, router/startup modules, `tests/`, migrations, Docker Compose,
+ and CI workflows.
+2. Find the application boundary. Extract startup code into a reusable function
+ if needed so tests can bind a random local port and pass explicit state.
+3. Write or update an integration test before changing behavior. Put API tests
+ under `tests/` unless the project already has a clear convention.
+4. Create a `spawn_app` helper that starts the service once per test case,
+ captures the base URL, and owns any disposable test resources.
+5. Exercise the public HTTP contract with `reqwest`, not framework-specific
+ request objects, unless the project intentionally uses in-process tests.
+6. Isolate state. Use real dependencies when behavior depends on their semantics:
+ Postgres for SQL behavior, a mock HTTP server for external APIs, and unique
+ resource names per test.
+7. Keep test helpers as production-quality code. Give failures useful messages,
+ hide boilerplate behind small helper methods, and avoid sleeps when readiness
+ can be observed.
+8. Run the local verification script or equivalent cargo commands before
+ finishing.
+
+## Startup Shape
+
+Prefer a startup function that accepts infrastructure instead of creating it
+inside the handler module. Actix can listen on a synchronous
+`std::net::TcpListener`:
+
+```rust
+pub fn run(
+ listener: std::net::TcpListener,
+ app_state: AppState,
+) -> Result {
+ let state = actix_web::web::Data::new(app_state);
+ let server = actix_web::HttpServer::new(move || {
+ actix_web::App::new()
+ .app_data(state.clone())
+ .route("/health_check", actix_web::web::get().to(health_check))
+ })
+ .listen(listener)?
+ .run();
+
+ Ok(server)
+}
+```
+
+For Axum, prefer the same boundary but use Tokio's async listener type:
+
+```rust
+pub fn router(app_state: AppState) -> axum::Router {
+ axum::Router::new()
+ .route("/health_check", axum::routing::get(health_check))
+ .with_state(app_state)
+}
+
+pub async fn spawn_axum_app() -> TestApp {
+ let listener = tokio::net::TcpListener::bind("127.0.0.1:0")
+ .await
+ .expect("failed to bind random port");
+ let port = listener.local_addr().unwrap().port();
+ let server = axum::serve(listener, router(test_state().await));
+ let server_handle = tokio::spawn(async move { server.await });
+
+ TestApp {
+ address: format!("http://127.0.0.1:{port}"),
+ http_client: reqwest::Client::new(),
+ server_handle,
+ }
+}
+```
+
+## Test Harness Pattern
+
+Use a helper object instead of repeating setup in every test.
+
+```rust
+pub struct TestApp {
+ pub address: String,
+ pub http_client: reqwest::Client,
+ pub server_handle: tokio::task::JoinHandle>,
+}
+
+pub async fn spawn_app() -> TestApp {
+ let listener = std::net::TcpListener::bind("127.0.0.1:0")
+ .expect("failed to bind random port");
+ let port = listener.local_addr().unwrap().port();
+
+ let server = my_app::startup::run(listener, test_state().await)
+ .expect("failed to start test server");
+ let server_handle = tokio::spawn(server);
+
+ TestApp {
+ address: format!("http://127.0.0.1:{port}"),
+ http_client: reqwest::Client::new(),
+ server_handle,
+ }
+}
+```
+
+Add small helper methods when a multi-step user journey appears in more than
+one test. Keep the method names behavior-oriented, for example
+`post_subscription`, `login`, `create_newsletter`, or `confirm_subscription`.
+
+Do not discard the `JoinHandle` returned by `tokio::spawn`. Keep it in the test
+fixture so tests can detect an unexpectedly finished server task and abort it
+during teardown instead of hiding server-side panics behind later
+connection-refused errors.
+
+## Assertions
+
+- Assert status codes and response headers first.
+- Assert persisted side effects through public APIs when possible; query the
+ database directly only when the public API has no observation point yet.
+- Assert negative cases as first-class behavior: missing fields, malformed
+ payloads, duplicate submissions, unauthorized users, upstream failures, and
+ timeouts.
+- Avoid snapshotting noisy response bodies unless the API contract actually
+ includes those exact bytes.
+
+## State And Dependency Isolation
+
+Read `references/database-test-isolation.md` when tests touch a database.
+Read `references/external-http-mocks.md` when tests call third-party HTTP APIs.
+
+Default preferences:
+
+- Use real Postgres for Postgres-backed behavior instead of SQLite or in-memory
+ substitutes.
+- Use one logical database, schema, or unique namespace per test when tests can
+ write shared state.
+- Run migrations in setup before the app starts.
+- Use `wiremock` or an equivalent local mock server for external HTTP APIs.
+- Configure timeouts aggressively in tests so failures do not hang.
+
+## Verification
+
+Run the bundled preflight script from the Rust project root when the standard
+cargo workflow applies:
+
+```bash
+path/to/rust-api-test-harness/scripts/check-rust-service.sh
+```
+
+By default, the script runs:
+
+```bash
+cargo fmt --all --check
+cargo clippy --all-targets --all-features -- -D warnings
+cargo test --all-features
+```
+
+Set `RUST_API_TEST_HARNESS_SKIP_CLIPPY=1` to skip only the clippy step. The
+script still runs formatting and tests. Use this escape hatch when the project
+configures linting separately in CI or when `--all-targets --all-features` is
+known to be inappropriate for the local preflight.
+
+If the project does not use all features in CI, mirror the repository's existing
+CI commands instead and explain the deviation.
+
+## Reference Files
+
+- `references/database-test-isolation.md`: patterns for Postgres-backed tests,
+ migrations, per-test databases, and cleanup tradeoffs.
+- `references/external-http-mocks.md`: patterns for testing outbound HTTP
+ clients and API workflows with local mocks.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/agents/openai.yaml
new file mode 100644
index 00000000..da57d1e7
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust API Test Harness"
+ short_description: "Build reliable Rust API integration tests"
+ default_prompt: "Add black-box integration tests for this Rust API using the Rust API Test Harness skill."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/assets/app-icon.png b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/assets/app-icon.png
new file mode 100644
index 00000000..b3df200e
Binary files /dev/null and b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/assets/app-icon.png differ
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/database-test-isolation.md b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/database-test-isolation.md
new file mode 100644
index 00000000..84613223
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/database-test-isolation.md
@@ -0,0 +1,72 @@
+# Database Test Isolation
+
+Use this reference when Rust API tests write to a real database.
+
+## Goals
+
+- Tests can run repeatedly without depending on previous runs.
+- Tests can run in parallel without corrupting each other.
+- Test behavior matches production database semantics closely enough to catch
+ query, constraint, transaction, and migration bugs.
+
+## Preferred Pattern: Disposable Logical Database
+
+Use this when the application talks to Postgres through a pool and the test
+cannot wrap all queries in a single transaction.
+
+1. Load the normal test configuration.
+2. Replace the database name with a unique value, usually a UUID.
+3. Connect to the Postgres server without selecting that database.
+4. Create the logical database.
+5. Connect a pool to the new database.
+6. Run migrations.
+7. Start the application with that pool or with configuration pointing to that
+ database.
+
+This costs more than a transaction rollback, but it keeps API tests simple and
+works with connection pools, background tasks, and request handlers that acquire
+their own connections.
+
+## Transaction Rollback Pattern
+
+Use this mostly for repository/unit tests where the test controls the exact
+connection used by the code under test.
+
+1. Begin a transaction.
+2. Pass `&mut Transaction<'_, Postgres>` or a compatible executor into the code.
+3. Assert behavior.
+4. Roll back at the end of the test.
+
+Avoid this for black-box HTTP tests if the running app obtains connections from
+a `PgPool` that the test cannot intercept.
+
+## Migration Rules
+
+- Run migrations in test setup instead of assuming a developer already ran them.
+- Keep migrations committed and deterministic.
+- Prefer additive migrations for deployed services: add nullable columns first,
+ deploy code that writes them, backfill, then add stricter constraints.
+- When using `sqlx::migrate!`, keep the migrations path valid from the crate or
+ workspace where tests execute.
+
+## Cleanup
+
+Choose one policy and make it explicit:
+
+- Drop the logical database at test teardown when the suite creates many large
+ records or runs in shared CI infrastructure.
+- Leave disposable databases behind for local speed and post-failure inspection
+ when the test Postgres instance is easy to reset.
+
+If cleanup is best-effort, never let cleanup failures hide the original test
+failure.
+
+## Common Failure Modes
+
+- A fixed database name makes tests order-dependent.
+- A fixed HTTP port makes tests fail when another process is running.
+- Migrations are skipped locally and only fail in CI.
+- Tests use SQLite while production uses Postgres-specific constraints,
+ isolation, JSON, arrays, or enum behavior.
+- Test setup uses `.env` values from a developer machine instead of explicit
+ test configuration.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/external-http-mocks.md b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/external-http-mocks.md
new file mode 100644
index 00000000..48d37bf3
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/references/external-http-mocks.md
@@ -0,0 +1,63 @@
+# External HTTP Mocks
+
+Use this reference when a Rust API test needs to verify outbound HTTP calls to
+email providers, payment APIs, webhooks, search services, or other third-party
+systems.
+
+## Preferred Pattern
+
+1. Start a local mock server in the test setup.
+2. Point the application or client base URL at the mock server.
+3. Configure the exact expected request: method, path, headers, body, and number
+ of calls.
+4. Exercise the public API through HTTP.
+5. Assert both the API response and the mock expectations.
+
+`wiremock` is a good default for Rust projects because it integrates cleanly
+with async tests and can verify scoped request expectations.
+
+## Client Design
+
+Make external clients easy to test:
+
+- Accept a base URL through configuration.
+- Reuse one `reqwest::Client` instead of constructing a new client per request.
+- Put authorization headers, timeouts, and serialization in one small client
+ type.
+- Keep request construction close to the client, not scattered across handlers.
+- Return errors that preserve enough context for callers and operators.
+
+## Test Cases To Cover
+
+- Happy path with exact method, path, authorization, content type, and JSON/body.
+- Non-2xx upstream responses.
+- Timeouts or connection failures.
+- Invalid or missing configuration.
+- Duplicate submission behavior when external side effects are expensive.
+
+## Mocking Boundaries
+
+Mock systems outside the service boundary. Do not mock the Rust handler being
+tested or the domain function whose behavior is the point of the test.
+
+Good mock boundary:
+
+```text
+test -> local API server -> real handler/domain code -> mock external API
+```
+
+Weak mock boundary:
+
+```text
+test -> mocked handler -> no real API behavior exercised
+```
+
+## Practical Tips
+
+- Use short timeouts in tests to avoid long hangs.
+- Prefer named helper methods such as `mock_email_send_success` over inline mock
+ setup when the expectation appears in multiple tests.
+- Keep mock assertions strict enough to catch contract drift, but do not assert
+ incidental headers that libraries may change.
+- Use scoped mocks where available so expectations are verified before the test
+ moves on.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/scripts/check-rust-service.sh b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/scripts/check-rust-service.sh
new file mode 100755
index 00000000..999b5059
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-api-test-harness/scripts/check-rust-service.sh
@@ -0,0 +1,20 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v cargo >/dev/null 2>&1; then
+ echo "cargo was not found on PATH" >&2
+ exit 127
+fi
+
+if [ ! -f Cargo.toml ]; then
+ echo "run this script from a Rust crate or workspace root containing Cargo.toml" >&2
+ exit 2
+fi
+
+cargo fmt --all --check
+
+if [ "${RUST_API_TEST_HARNESS_SKIP_CLIPPY:-0}" != "1" ]; then
+ cargo clippy --all-targets --all-features -- -D warnings
+fi
+
+cargo test --all-features
diff --git a/plugins/LVTD-LLC/skills/skills/rust-deployable-service/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/SKILL.md
new file mode 100644
index 00000000..e498d30b
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/SKILL.md
@@ -0,0 +1,75 @@
+---
+name: rust-deployable-service
+description: Use when preparing, containerizing, configuring, testing, or reviewing Rust services for deployment, especially Docker multi-stage builds, runtime configuration, environment overrides, secrets, health checks, SQLx offline builds, release profiles, image-size reduction, or production startup validation.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust Deployable Service
+ category: Rust
+ tags: rust,deployment,docker,configuration,sqlx
+---
+
+# Rust Deployable Service
+
+Use this skill when a Rust service needs to move from local development to a
+repeatable container or cloud deployment. Keep runtime configuration explicit,
+builds reproducible, and health checks boring.
+
+## Core Workflow
+
+1. Inspect `Cargo.toml`, workspace layout, `Dockerfile`, `.dockerignore`,
+ config files, migrations, `.sqlx/`, CI, and deployment docs.
+2. Identify the binary entrypoint and runtime dependencies: database, Redis,
+ external APIs, TLS roots, static files, templates, migrations, and config.
+3. Separate build-time and runtime configuration. Never bake production secrets
+ into images.
+4. Use hierarchical config with environment overrides for deployment-specific
+ values.
+5. Use a multi-stage Docker build and copy only the runtime binary and needed
+ assets into the final image.
+6. Account for SQLx query checking. Use `SQLX_OFFLINE=true` with checked-in
+ `.sqlx/` metadata or provide a build-time database intentionally.
+7. Add health and readiness checks that match real dependencies.
+8. Run the bundled Docker preflight or the repository's equivalent CI command.
+
+## Configuration Rules
+
+Read `references/configuration.md` when adding config files, environment
+variables, or secret handling.
+
+- Keep local defaults convenient and production defaults conservative.
+- Validate config at startup before binding the server when possible.
+- Store secrets in environment variables or the deployment secret manager.
+- Avoid reading environment variables deep inside handlers or repositories.
+
+## Docker Rules
+
+Read `references/docker-rust.md` before changing Docker builds.
+
+- Use dependency caching deliberately; avoid invalidating the whole build on
+ every source edit when practical.
+- Use `--locked` for release builds if the repo commits `Cargo.lock`.
+- Include CA certificates when outbound HTTPS is required.
+- Copy migrations, templates, and static assets only if the binary needs them at
+ runtime.
+- Run as a non-root user when the deployment platform supports it.
+
+## Verification
+
+Run from the Rust project root when Docker is part of the delivery path:
+
+```bash
+path/to/rust-deployable-service/scripts/docker-preflight.sh
+```
+
+The script builds an image. It only runs a smoke command when
+`RUST_DEPLOY_SMOKE_COMMAND` is set, because services often need environment and
+infrastructure to start successfully.
+
+## Reference Files
+
+- `references/configuration.md`: typed config loading, overrides, validation,
+ and secrets.
+- `references/docker-rust.md`: multi-stage builds, SQLx offline builds, runtime
+ assets, and image checks.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-deployable-service/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/agents/openai.yaml
new file mode 100644
index 00000000..163d3985
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust Deployable Service"
+ short_description: "Prepare Rust services for container deployment"
+ default_prompt: "Prepare this Rust service for containerized deployment."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/configuration.md b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/configuration.md
new file mode 100644
index 00000000..b3de9066
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/configuration.md
@@ -0,0 +1,45 @@
+# Configuration
+
+Rust services should parse configuration once at startup and pass typed config
+through application state.
+
+## Layers
+
+Typical precedence:
+
+1. Defaults committed to the repo.
+2. Environment-specific file such as `configuration/production.yml`.
+3. Environment variables from the deployment platform.
+4. Secret manager values mounted as environment or files.
+
+Document the actual precedence in code or deployment docs.
+
+## Typed Config
+
+```rust
+#[derive(serde::Deserialize, Clone)]
+pub struct Settings {
+ pub application: ApplicationSettings,
+ pub database: DatabaseSettings,
+}
+
+#[derive(serde::Deserialize, Clone)]
+pub struct DatabaseSettings {
+ pub url: secrecy::SecretString,
+ pub max_connections: u32,
+}
+```
+
+Validate at startup:
+
+- Required secrets are present.
+- Ports and URLs parse.
+- Pool sizes and timeouts are within expected bounds.
+- Production does not use local-only defaults.
+
+## Secret Handling
+
+- Do not commit production secrets.
+- Do not print full config structs when they contain secrets.
+- Keep secret values in `SecretString` or project wrappers.
+- Expose secrets only at the driver boundary that needs raw text.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/docker-rust.md b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/docker-rust.md
new file mode 100644
index 00000000..de9ba725
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/references/docker-rust.md
@@ -0,0 +1,54 @@
+# Docker For Rust Services
+
+Use multi-stage builds so the final image contains the runtime binary and only
+the files it needs.
+
+## Multi-Stage Shape
+
+```dockerfile
+FROM rust:1-bookworm AS builder
+WORKDIR /app
+COPY Cargo.toml Cargo.lock ./
+COPY src ./src
+RUN cargo build --release --locked
+
+FROM debian:bookworm-slim AS runtime
+RUN apt-get update \
+ && apt-get install -y --no-install-recommends ca-certificates \
+ && rm -rf /var/lib/apt/lists/*
+WORKDIR /app
+COPY --from=builder /app/target/release/my-service /usr/local/bin/my-service
+CMD ["my-service"]
+```
+
+Adapt the base image, binary path, and copied assets to the project.
+
+## SQLx Builds
+
+For SQLx macros in Docker, prefer checked-in offline metadata:
+
+```dockerfile
+ENV SQLX_OFFLINE=true
+COPY .sqlx ./.sqlx
+RUN cargo build --release --locked
+```
+
+If the build intentionally connects to a database, make that explicit in CI and
+avoid hiding network/database requirements inside the Dockerfile.
+
+## Runtime Assets
+
+Copy only assets the binary reads at runtime:
+
+- `migrations/` if the app runs migrations at startup.
+- Templates or static files for server-rendered apps.
+- CA certificates for outbound HTTPS.
+- Time zone or locale data if required.
+
+## Checks
+
+- Does the image build from a clean checkout?
+- Does it start with missing required config and fail clearly?
+- Does the health endpoint respond when dependencies are available?
+- Is the binary compiled with the expected feature flags?
+- Does the final image avoid build tools and source code unless needed?
diff --git a/plugins/LVTD-LLC/skills/skills/rust-deployable-service/scripts/docker-preflight.sh b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/scripts/docker-preflight.sh
new file mode 100755
index 00000000..46711a3e
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-deployable-service/scripts/docker-preflight.sh
@@ -0,0 +1,26 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v docker >/dev/null 2>&1; then
+ echo "docker is required" >&2
+ exit 127
+fi
+
+DOCKERFILE="${RUST_DEPLOY_DOCKERFILE:-Dockerfile}"
+CONTEXT="${RUST_DEPLOY_CONTEXT:-.}"
+IMAGE="${RUST_DEPLOY_IMAGE:-rust-service-preflight:local}"
+
+if [ ! -f "$DOCKERFILE" ]; then
+ echo "Dockerfile not found: $DOCKERFILE" >&2
+ exit 2
+fi
+
+echo "==> docker build -f $DOCKERFILE -t $IMAGE $CONTEXT"
+docker build -f "$DOCKERFILE" -t "$IMAGE" "$CONTEXT"
+
+if [ -n "${RUST_DEPLOY_SMOKE_COMMAND:-}" ]; then
+ echo "==> docker run smoke command"
+ docker run --rm "$IMAGE" sh -c "$RUST_DEPLOY_SMOKE_COMMAND"
+else
+ echo "==> skipping smoke run; set RUST_DEPLOY_SMOKE_COMMAND to run one"
+fi
diff --git a/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/SKILL.md
new file mode 100644
index 00000000..3c3b6eb1
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/SKILL.md
@@ -0,0 +1,101 @@
+---
+name: rust-domain-boundaries
+description: Use when modeling, validating, refactoring, or reviewing Rust service domain boundaries, especially when replacing primitive String fields with newtypes, parse-don't-validate constructors, private invariants, TryFrom/FromStr parsers, request DTO boundaries, or property tests.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust Domain Boundaries
+ category: Rust
+ tags: rust,domain-modeling,newtypes,validation,property-testing
+---
+
+# Rust Domain Boundaries
+
+Use this skill to keep invalid states out of Rust service internals. Parse raw
+input once at the boundary, store validated values in narrow domain types, and
+make unchecked construction difficult.
+
+## Core Workflow
+
+1. Find raw input boundaries: HTTP payloads, path/query parameters, config
+ files, environment variables, database rows, queues, and CLI flags.
+2. Separate transport DTOs from domain types. Let `serde` deserialize incoming
+ shapes, then convert DTO fields into validated domain values.
+3. Replace primitive strings with small types for ruled values: email addresses,
+ usernames, passwords, subscriber names, slugs, tenant IDs, idempotency keys,
+ and money-like or duration-like values.
+4. Give domain types private fields and smart constructors. Avoid unchecked
+ `pub` fields or `impl From` for fallible conversions.
+5. Return typed validation errors that map to useful HTTP responses without
+ leaking internal details.
+6. Keep database and external API mapping explicit. Convert to raw strings at
+ the final persistence or serialization edge.
+7. Test invariants directly. Cover valid examples, malformed inputs, boundary
+ lengths, normalization rules, and round trips.
+
+## Type Design Rules
+
+- Prefer `TryFrom`, `TryFrom<&str>`, or `FromStr` for fallible parsing.
+- Keep stored values owned unless profiling proves borrowing is necessary.
+- Implement `AsRef` or a named accessor for read-only exposure.
+- Implement `Display` only when the formatted value is safe to show in logs,
+ errors, and UI.
+- Avoid deriving `Debug` for secret-bearing values unless the debug output is
+ redacted.
+- Make normalization visible in tests: trim, lowercase, Unicode handling, and
+ canonicalization.
+
+## Request Boundary Pattern
+
+Deserialize into a request shape, then construct a command:
+
+```rust
+#[derive(serde::Deserialize)]
+pub struct SubscribeRequest {
+ email: String,
+ name: String,
+}
+
+pub struct SubscribeCommand {
+ pub email: EmailAddress,
+ pub name: SubscriberName,
+}
+
+impl TryFrom for SubscribeCommand {
+ type Error = SubscribeValidationError;
+
+ fn try_from(value: SubscribeRequest) -> Result {
+ Ok(Self {
+ email: EmailAddress::parse(value.email)?,
+ name: SubscriberName::parse(value.name)?,
+ })
+ }
+}
+```
+
+Handlers should reject invalid input before business logic or database code. If
+validation needs database state, keep pure parsing separate from uniqueness or
+authorization checks.
+
+## Tests
+
+Read `references/property-testing.md` when invariants have many edge cases or
+when an AI agent is likely to miss invalid inputs with example-only tests.
+
+Minimum tests for a new domain type:
+
+- Accept a realistic valid value.
+- Reject empty input and whitespace-only input.
+- Reject too-long input when storage or product rules impose limits.
+- Reject format violations.
+- Preserve or normalize exactly as documented by tests.
+- Round-trip through `serde` or SQL mapping when that type crosses those
+ boundaries.
+
+## Reference Files
+
+- `references/newtype-patterns.md`: constructor, trait, serde, and persistence
+ patterns for Rust newtypes.
+- `references/property-testing.md`: property-testing strategy for parsers and
+ domain constructors.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/agents/openai.yaml
new file mode 100644
index 00000000..67072224
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust Domain Boundaries"
+ short_description: "Model Rust service invariants with types"
+ default_prompt: "Make this Rust service code safer with domain types and parser boundaries."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/newtype-patterns.md b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/newtype-patterns.md
new file mode 100644
index 00000000..83e528d6
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/newtype-patterns.md
@@ -0,0 +1,109 @@
+# Newtype Patterns
+
+Use a newtype when a primitive value has business meaning, validation rules, or
+security handling that would be easy to bypass if it stayed as `String`, `i64`,
+or `Uuid` everywhere.
+
+## Basic Shape
+
+```rust
+#[derive(Clone, PartialEq, Eq, Hash)]
+pub struct EmailAddress(String);
+
+impl EmailAddress {
+ pub fn parse(input: impl Into) -> Result {
+ let input = input.into();
+ let candidate = input.trim();
+
+ if candidate.is_empty() {
+ return Err(EmailAddressError::Empty);
+ }
+
+ if !candidate.contains('@') {
+ return Err(EmailAddressError::MissingAtSign);
+ }
+
+ Ok(Self(candidate.to_owned()))
+ }
+
+ pub fn as_str(&self) -> &str {
+ &self.0
+ }
+}
+
+impl AsRef for EmailAddress {
+ fn as_ref(&self) -> &str {
+ self.as_str()
+ }
+}
+```
+
+Keep the field private. If callers need construction for tests, provide a
+checked constructor or a test-only helper under `#[cfg(test)]`.
+
+## Conversion Guidance
+
+- Use `TryFrom` when callers already own a string.
+- Use `FromStr` when parsing is idiomatic for config, CLI, or path values.
+- Avoid `From` for validated types; it implies conversion cannot fail.
+- Avoid `Deref` unless the type is intentionally string-like and
+ all string operations are safe.
+- Use named constructors for intent when there are multiple validation modes,
+ for example `Password::parse_plaintext` vs `PasswordHash::parse_phc`.
+
+## Serde Boundary
+
+For request DTOs, prefer deserializing raw strings and converting explicitly in
+the handler or command constructor. This keeps HTTP error mapping under your
+control.
+
+For internal APIs or stored JSON, custom `Deserialize` can be useful:
+
+```rust
+impl<'de> serde::Deserialize<'de> for EmailAddress {
+ fn deserialize(deserializer: D) -> Result
+ where
+ D: serde::Deserializer<'de>,
+ {
+ let value = String::deserialize(deserializer)?;
+ Self::parse(value).map_err(serde::de::Error::custom)
+ }
+}
+```
+
+## SQL Mapping
+
+Convert domain values at the repository edge:
+
+```rust
+sqlx::query!(
+ "insert into subscriptions (email, name) values ($1, $2)",
+ command.email.as_str(),
+ command.name.as_str(),
+)
+.execute(pool)
+.await?;
+```
+
+For frequent mappings, consider implementing `sqlx::Type`, `Encode`, and
+`Decode`, but keep simple `.as_str()` mapping unless the repeated boilerplate is
+material.
+
+## Error Types
+
+Make validation errors specific enough for tests and HTTP mapping:
+
+```rust
+#[derive(Debug, thiserror::Error, PartialEq, Eq)]
+pub enum SubscriberNameError {
+ #[error("name cannot be empty")]
+ Empty,
+ #[error("name is too long")]
+ TooLong,
+ #[error("name contains forbidden characters")]
+ InvalidCharacters,
+}
+```
+
+Do not put raw secrets, tokens, or passwords in validation error variants or
+`Display` messages.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/property-testing.md b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/property-testing.md
new file mode 100644
index 00000000..9358124a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-domain-boundaries/references/property-testing.md
@@ -0,0 +1,66 @@
+# Property Testing Domain Types
+
+Use property tests when a parser or constructor has many possible inputs and a
+small example table is unlikely to cover edge cases. Good candidates include
+names, slugs, email-like identifiers, idempotency keys, path segments, and
+custom numeric ranges.
+
+## Test Strategy
+
+1. Keep example tests for important named cases. They document product rules.
+2. Add generated valid inputs to prove broad acceptance.
+3. Add generated invalid inputs to prove rejection boundaries.
+4. Assert the stable property, not implementation details.
+
+Useful properties:
+
+- Accepted values can be displayed or serialized without panicking.
+- Accepted values round-trip through the accessor.
+- Rejected values never reach the repository or command handler.
+- Normalization is idempotent: parsing an already-normalized output gives the
+ same value.
+- Length limits are enforced before database insertion.
+
+## Proptest Sketch
+
+```rust
+use proptest::prelude::*;
+
+proptest! {
+ #[test]
+ fn subscriber_names_reject_blank_input(raw in "\\s*") {
+ prop_assume!(!raw.is_empty());
+ prop_assert!(SubscriberName::parse(raw).is_err());
+ }
+
+ #[test]
+ fn subscriber_names_accept_non_empty_trimmed_text(raw in "[a-zA-Z][a-zA-Z ]{0,80}") {
+ let parsed = SubscriberName::parse(raw.clone())?;
+ prop_assert_eq!(parsed.as_str(), raw.trim());
+ }
+}
+```
+
+## Fake Data
+
+Use `fake` or a small custom generator for realistic valid values. Avoid random
+internet-looking data if the validation rules are stricter than the generator.
+
+```rust
+use fake::{Fake, faker::internet::en::SafeEmail};
+
+#[test]
+fn generated_safe_emails_are_accepted() {
+ for _ in 0..100 {
+ let email: String = SafeEmail().fake();
+ assert!(EmailAddress::parse(email).is_ok());
+ }
+}
+```
+
+## Keep Tests Deterministic
+
+- Seed randomness when the framework supports it.
+- Keep generated input size bounded so tests remain fast.
+- Store regression cases found by shrinking as named example tests.
+- Do not use property tests as a substitute for clear domain rules.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-error-observability/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-error-observability/SKILL.md
new file mode 100644
index 00000000..ff8dd806
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-error-observability/SKILL.md
@@ -0,0 +1,95 @@
+---
+name: rust-error-observability
+description: Use when adding, changing, debugging, or reviewing Rust service error handling and observability, especially when separating domain errors from HTTP responses, adding thiserror/anyhow, implementing ResponseError or IntoResponse, adding tracing spans, redacting secrets, or diagnosing async failures.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust Error Observability
+ category: Rust
+ tags: rust,error-handling,observability,tracing,backend
+---
+
+# Rust Error Observability
+
+Use this skill to make Rust service failures understandable to operators while
+keeping user-facing responses safe. Treat error handling and telemetry as one
+design surface.
+
+## Core Workflow
+
+1. Inventory error flows: handler return types, service/repository errors,
+ worker errors, middleware, logs, and tracing setup.
+2. Classify each error by purpose:
+ - Domain or validation outcome.
+ - Recoverable control flow.
+ - Operator diagnostic.
+ - User-facing HTTP response.
+3. Keep domain errors typed. Use `thiserror` for expected branches that callers
+ should match on.
+4. Add context at infrastructure boundaries. Use `anyhow` or opaque application
+ errors when callers should not match every dependency failure.
+5. Map errors to HTTP responses in one place per framework: `ResponseError`,
+ Axum `IntoResponse`, or a small adapter function.
+6. Add structured spans before more log lines. Include stable diagnostic fields,
+ not raw payloads or secrets.
+7. Ensure errors are logged once. Prefer logging at the outer boundary where
+ request context is available.
+8. Test both the public response and the diagnostic path when behavior changed.
+
+## Error Boundary Rules
+
+- Domain modules return domain errors, not HTTP status codes.
+- Repository modules attach query or operation context, but do not log every
+ error.
+- Handlers convert domain outcomes into response types and let unexpected
+ failures become a consistent 500.
+- Background workers log failed job IDs, attempt counts, and next action.
+- Avoid `unwrap`, `expect`, or stringly `map_err` in service paths unless the
+ invariant is local and the panic message is useful.
+
+Read `references/error-boundaries.md` when choosing between `thiserror`,
+`anyhow`, opaque errors, and framework response adapters.
+
+## Tracing Rules
+
+- Instrument request handlers, service methods, outbound clients, database
+ operations, and worker jobs at boundaries.
+- Use `#[tracing::instrument(skip(...))]` for request bodies, pools, clients,
+ passwords, tokens, and large values.
+- Attach fields like request ID, user ID, tenant ID, job ID, upstream name, and
+ idempotency key when safe.
+- Do not log secrets, cookies, password hashes, bearer tokens, or full PII.
+
+Read `references/tracing.md` for spans, subscriber setup, and test logging.
+Read `references/secrets-and-pii.md` before touching secret-bearing values.
+
+## HTTP Response Pattern
+
+Keep response errors stable and intentional:
+
+```rust
+pub enum SubscribeError {
+ Validation(SubscribeValidationError),
+ Unexpected(anyhow::Error),
+}
+
+impl actix_web::ResponseError for SubscribeError {
+ fn status_code(&self) -> actix_web::http::StatusCode {
+ match self {
+ Self::Validation(_) => actix_web::http::StatusCode::BAD_REQUEST,
+ Self::Unexpected(_) => actix_web::http::StatusCode::INTERNAL_SERVER_ERROR,
+ }
+ }
+}
+```
+
+The response body should be safe for users. The trace event should carry the
+diagnostic context operators need.
+
+## Reference Files
+
+- `references/error-boundaries.md`: choosing error types and response adapters.
+- `references/tracing.md`: spans, fields, subscriber setup, and test output.
+- `references/secrets-and-pii.md`: redaction rules for secrets and sensitive
+ user data.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-error-observability/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-error-observability/agents/openai.yaml
new file mode 100644
index 00000000..c9a09887
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-error-observability/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust Error Observability"
+ short_description: "Shape Rust errors and tracing for services"
+ default_prompt: "Improve this Rust service error handling and structured tracing."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/error-boundaries.md b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/error-boundaries.md
new file mode 100644
index 00000000..18f60fbc
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/error-boundaries.md
@@ -0,0 +1,81 @@
+# Error Boundaries
+
+Good Rust services use more than one error style. Pick the style from the
+caller contract, not from habit.
+
+## Typed Domain Errors
+
+Use typed enums when callers should branch:
+
+```rust
+#[derive(Debug, thiserror::Error)]
+pub enum LoginError {
+ #[error("invalid credentials")]
+ InvalidCredentials,
+ #[error("account is locked")]
+ AccountLocked,
+}
+```
+
+Typed errors work well for validation, authorization decisions, duplicate
+resources, idempotency conflicts, and expected workflow states.
+
+## Opaque Application Errors
+
+Use `anyhow::Error` or an opaque application error when callers should attach
+context and bubble up:
+
+```rust
+let row = sqlx::query!(...)
+ .fetch_optional(pool)
+ .await
+ .context("failed to fetch user credentials")?;
+```
+
+Add context at the boundary where the operation is meaningful. Avoid wrapping
+the same error with vague context at every layer.
+
+## HTTP Adapters
+
+Keep HTTP mapping close to the web layer. Domain crates should not depend on
+Actix, Axum, Warp, or Rocket.
+
+Actix:
+
+```rust
+impl actix_web::ResponseError for AppError {
+ fn status_code(&self) -> actix_web::http::StatusCode {
+ match self {
+ AppError::BadRequest(_) => StatusCode::BAD_REQUEST,
+ AppError::Unauthorized => StatusCode::UNAUTHORIZED,
+ AppError::Unexpected(_) => StatusCode::INTERNAL_SERVER_ERROR,
+ }
+ }
+}
+```
+
+Axum:
+
+```rust
+impl axum::response::IntoResponse for AppError {
+ fn into_response(self) -> axum::response::Response {
+ let status = match self {
+ AppError::BadRequest(_) => StatusCode::BAD_REQUEST,
+ AppError::Unauthorized => StatusCode::UNAUTHORIZED,
+ AppError::Unexpected(_) => StatusCode::INTERNAL_SERVER_ERROR,
+ };
+ status.into_response()
+ }
+}
+```
+
+## Logging Once
+
+Prefer this flow:
+
+1. Add context with `Context` or typed variants as errors move up.
+2. Convert to a response at the framework boundary.
+3. Emit one structured error event there, with request context.
+
+Avoid logging inside every helper and then returning the same error. Duplicate
+logs make incidents harder to read.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/secrets-and-pii.md b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/secrets-and-pii.md
new file mode 100644
index 00000000..b56bcab3
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/secrets-and-pii.md
@@ -0,0 +1,46 @@
+# Secrets And PII
+
+Treat observability as a data exposure surface. A trace field, panic message, or
+debug dump can leak the same information as an API response.
+
+## Never Log Raw
+
+- Passwords or password reset tokens.
+- Session IDs and signed cookie contents.
+- Bearer tokens, API keys, OAuth codes, and refresh tokens.
+- Full payment data.
+- Password hashes unless the project explicitly treats them as safe diagnostic
+ data; default to not logging them.
+
+## Use Secret Types
+
+Use `secrecy::SecretString` or a project-local wrapper when a value should not
+appear in `Debug` output:
+
+```rust
+use secrecy::{ExposeSecret, SecretString};
+
+pub struct Credentials {
+ pub username: String,
+ pub password: SecretString,
+}
+
+verify_password(credentials.password.expose_secret(), stored_hash).await?;
+```
+
+Expose secrets only at the call site that needs the raw value.
+
+## Redaction Pattern
+
+When logs need a stable correlation value, log a derived non-secret:
+
+- User ID instead of email when possible.
+- Domain name instead of full email.
+- Last four characters only when product policy permits it.
+- Hash of a token only when the hash cannot be used as a credential.
+
+## Error Messages
+
+User-facing errors should be specific enough to act on but not specific enough
+to enumerate users, credentials, or resources. Operator-facing errors can carry
+more context through spans and secure logs.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/tracing.md b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/tracing.md
new file mode 100644
index 00000000..536f90b1
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-error-observability/references/tracing.md
@@ -0,0 +1,72 @@
+# Tracing Patterns
+
+Use `tracing` spans to connect request, database, upstream, and worker events.
+Logs without spans often lose the request context that makes production
+debugging useful.
+
+## Handler Instrumentation
+
+```rust
+#[tracing::instrument(
+ name = "Create subscription",
+ skip(pool, email_client, payload),
+ fields(request_id = %request_id, subscriber_email = tracing::field::Empty)
+)]
+pub async fn subscribe(
+ payload: web::Json,
+ pool: web::Data,
+ email_client: web::Data,
+) -> Result {
+ let command = SubscribeCommand::try_from(payload.into_inner())?;
+ tracing::Span::current().record("subscriber_email", command.email.as_str());
+ // ...
+ Ok(HttpResponse::Ok().finish())
+}
+```
+
+Skip large objects and secret-bearing values. Record safe fields only after
+validation and redaction decisions are clear.
+
+## Subscriber Setup
+
+Look for existing initialization before adding another subscriber. A typical app
+has one setup function used by `main` and tests:
+
+```rust
+pub fn init_subscriber(env_filter: String) {
+ let env_filter = tracing_subscriber::EnvFilter::try_from_default_env()
+ .unwrap_or_else(|_| env_filter.into());
+
+ tracing_subscriber::fmt()
+ .with_env_filter(env_filter)
+ .with_target(true)
+ .init();
+}
+```
+
+In tests, initialize once with `try_init` or a `OnceLock` to avoid panics from
+multiple global subscriber installs.
+
+## Useful Fields
+
+- `request_id`
+- `user_id` or tenant ID when safe.
+- `job_id` and attempt number.
+- `upstream` service name.
+- `idempotency_key` when it is not secret.
+- Database operation name, not full SQL with user data.
+
+## Failure Events
+
+Use `tracing::error!` or `tracing::warn!` at the boundary that decides what
+happens next:
+
+```rust
+tracing::error!(
+ error = ?err,
+ "request failed with unexpected error"
+);
+```
+
+Use `?err` for debug diagnostics when the error is safe. Use `%err` when the
+display message is intentionally redacted.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/SKILL.md
new file mode 100644
index 00000000..3dba5677
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: rust-idempotent-workflows
+description: Use when designing, implementing, testing, or debugging Rust service workflows that must be safe under retries, duplicate requests, crashes, concurrent submissions, background workers, queues, email/payment/notification side effects, idempotency keys, transaction isolation, or save-and-replay API behavior.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust Idempotent Workflows
+ category: Rust
+ tags: rust,idempotency,retries,background-jobs,concurrency
+---
+
+# Rust Idempotent Workflows
+
+Use this skill to make Rust workflows reliable when clients retry, workers
+crash, requests race, and external side effects cannot be rolled back.
+
+## Core Workflow
+
+1. Write the failure story before writing code. List what happens if the process
+ crashes after each database write and after each external side effect.
+2. Identify the idempotency boundary: HTTP endpoint, command handler, queue job,
+ webhook, or external callback.
+3. Choose the idempotency strategy:
+ - Natural idempotency from a unique business key.
+ - Client-provided idempotency key with save-and-replay.
+ - Server-generated deduplication key.
+ - Outbox or queue table for side effects.
+4. Put state transitions and idempotency records in the same transaction when
+ they must agree.
+5. Make duplicate concurrent requests deterministic. Use unique constraints,
+ locks, serializable transactions, or explicit conflict handling.
+6. Treat external side effects as at-least-once unless the provider guarantees
+ more. Store enough state to retry or reconcile.
+7. Add tests for duplicate requests, retry after timeout, concurrent requests,
+ crash windows when practical, and worker retry behavior.
+
+## Idempotency Key Rules
+
+Read `references/idempotency.md` before adding idempotency keys or save-and-
+replay behavior.
+
+- Bind the key to the authenticated user or tenant.
+- Store a hash of the request payload when replaying responses.
+- Return the original response for exact replays.
+- Reject reuse of the same key with a different payload.
+- Expire records only after product and provider retry windows have passed.
+
+## Background Work Rules
+
+Read `references/background-workers.md` when adding queue tables, polling
+workers, retries, or external side effects.
+
+- Commit durable intent before sending external effects.
+- Use `pending`, `in_progress`, `succeeded`, and `failed` states deliberately.
+- Keep retry counts, next-attempt timestamps, and last error summaries.
+- Make workers safe to run in multiple processes.
+
+## Concurrency Rules
+
+Read `references/concurrency.md` when duplicate requests, locks, isolation
+levels, or unique constraints are part of the fix.
+
+Use the database as the source of truth for deduplication when multiple app
+instances can process the same workflow.
+
+## Reference Files
+
+- `references/idempotency.md`: idempotency keys, save-and-replay, and request
+ payload binding.
+- `references/background-workers.md`: queue tables, worker loops, retry
+ boundaries, and outbox behavior.
+- `references/concurrency.md`: lock choices, transaction isolation, and duplicate
+ request tests.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/agents/openai.yaml
new file mode 100644
index 00000000..95aaeef2
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust Idempotent Workflows"
+ short_description: "Make Rust workflows safe for retries"
+ default_prompt: "Make this Rust workflow idempotent and safe under retries."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/background-workers.md b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/background-workers.md
new file mode 100644
index 00000000..ea139db6
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/background-workers.md
@@ -0,0 +1,46 @@
+# Background Workers
+
+Background workers make reliability harder because work can be claimed, retried,
+or interrupted independently of the original request.
+
+## Queue Table Shape
+
+Typical durable fields:
+
+- `id`
+- `task_type`
+- `payload`
+- `status`
+- `attempt_count`
+- `next_attempt_at`
+- `locked_by`
+- `locked_at`
+- `last_error`
+- `created_at`
+- `updated_at`
+
+Use JSON payloads only when schema evolution and validation are understood.
+
+## Claiming Work
+
+Use database mechanisms that allow multiple workers:
+
+- `FOR UPDATE SKIP LOCKED` for polling workers.
+- A leased `locked_at` timestamp so abandoned work can be retried.
+- Unique constraints for deduplication.
+
+## Retry Policy
+
+- Classify errors as retryable or terminal.
+- Use bounded exponential backoff with jitter when practical.
+- Store enough error context for operators without leaking secrets.
+- Move permanently failed jobs to a visible state instead of dropping them.
+
+## Outbox Pattern
+
+When a request must update local state and send an external message, commit the
+local state and an outbox row in one transaction. A worker sends the external
+message and marks the outbox row complete.
+
+This avoids the crash window where the database commits but the process exits
+before sending the message, or the message sends but the database rolls back.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/concurrency.md b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/concurrency.md
new file mode 100644
index 00000000..b2d10aa9
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/concurrency.md
@@ -0,0 +1,35 @@
+# Concurrency
+
+Assume duplicate requests can arrive at the same time on different processes.
+Application-level checks are not enough when a database is the shared state.
+
+## Preferred Defenses
+
+- Unique constraints for one-per-key invariants.
+- Transactions for multi-row state changes.
+- `SELECT ... FOR UPDATE` when a workflow must inspect and mutate a row.
+- Optimistic version columns when the user can retry conflicts.
+- Advisory locks only when the lock key and failure behavior are simple.
+
+## Tests
+
+Write at least one test that submits the same operation concurrently:
+
+```rust
+let first = tokio::spawn(send_request(client.clone(), payload.clone()));
+let second = tokio::spawn(send_request(client.clone(), payload.clone()));
+
+let (first, second) = tokio::try_join!(first, second)?;
+```
+
+Assert durable effects, not just status codes:
+
+- One row was created.
+- One email or outbox item exists.
+- Both responses are acceptable under the API contract.
+
+## Isolation Notes
+
+Postgres `READ COMMITTED` is often enough when unique constraints enforce the
+invariant. Use stronger isolation or explicit locks when the invariant spans
+multiple rows and cannot be expressed as a constraint.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/idempotency.md b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/idempotency.md
new file mode 100644
index 00000000..286f2b82
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-idempotent-workflows/references/idempotency.md
@@ -0,0 +1,48 @@
+# Idempotency
+
+Idempotency means a client can safely retry the same operation and observe the
+same effect. It does not mean every endpoint should ignore duplicates.
+
+## Strategy Choices
+
+Natural idempotency:
+
+- `PUT /resource/{id}` where the payload fully replaces state.
+- Confirming an already-confirmed subscription.
+- Creating a unique resource keyed by a natural unique constraint.
+
+Idempotency key:
+
+- Payment-like operations.
+- Email or notification dispatch requests.
+- Endpoint creates a resource and returns generated data.
+
+Outbox:
+
+- A database change must trigger an external side effect.
+- The side effect cannot be rolled back with the database transaction.
+
+## Save And Replay
+
+Store:
+
+- User or tenant ID.
+- Idempotency key.
+- Request payload hash.
+- Response status and body when complete.
+- State: `pending`, `completed`, `failed`.
+- Expiration timestamp.
+
+On repeat:
+
+- Same key and same payload: return stored response or wait/retry according to
+ project policy if still pending.
+- Same key and different payload: return conflict.
+- Missing key on an endpoint that requires it: return bad request.
+
+## Tests
+
+- Same key and same payload returns the same result.
+- Same key and different payload is rejected.
+- Concurrent duplicate requests create one durable effect.
+- Retry after a simulated timeout does not send duplicate external effects.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-service-security/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-service-security/SKILL.md
new file mode 100644
index 00000000..2f9c8e90
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-service-security/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: rust-service-security
+description: Use when adding, changing, testing, or reviewing security-sensitive Rust web service behavior, especially login flows, password hashing, credential checks, session cookies, flash messages, admin route protection, auth middleware, user enumeration defenses, or moving CPU-heavy password work off async executors.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust Service Security
+ category: Rust
+ tags: rust,security,authentication,sessions,passwords
+---
+
+# Rust Service Security
+
+Use this skill when a Rust service handles identity, credentials, sessions,
+cookies, privileged routes, or sensitive user data. Prefer explicit threat
+checks and tests over optimistic handler code.
+
+## Core Workflow
+
+1. Identify the protected asset: account access, admin area, session state,
+ password change, reset token, private data, or privileged operation.
+2. Trace the whole flow: request parsing, credential lookup, verification,
+ session mutation, redirects/responses, logs, and tests.
+3. Keep secrets out of logs and debug output. Use secret wrappers for passwords,
+ tokens, signing keys, and session secrets.
+4. Run password hashing and verification with memory-hard algorithms and move
+ CPU-heavy work off async reactor threads.
+5. Prevent user enumeration. Failed login and password reset flows should not
+ reveal whether the account exists.
+6. Set cookie and session attributes deliberately: `HttpOnly`, `Secure`,
+ `SameSite`, path, lifetime, signing/encryption, and store backend.
+7. Protect routes at middleware or extractor boundaries, not by repeating
+ ad-hoc checks in every handler.
+8. Add tests for happy path, failed auth, missing session, forged cookie or
+ token, and logout/session rotation behavior.
+
+## Password Rules
+
+Read `references/password-auth.md` before implementing or changing password
+storage or verification.
+
+- Store PHC strings produced by Argon2id or the project's chosen password
+ hasher; never store plaintext or reversible encrypted passwords.
+- Generate salts with a secure RNG.
+- Use constant, generic responses for invalid credentials.
+- Use `tokio::task::spawn_blocking` or a dedicated blocking abstraction for
+ expensive password operations.
+- Keep password hash parameters configurable enough to upgrade over time.
+
+## Cookie And Session Rules
+
+Read `references/cookies-sessions.md` when setting, reading, deleting, signing,
+or persisting cookies and sessions.
+
+- Never store raw credentials in cookies.
+- Prefer opaque session IDs backed by a server-side store for privileged apps.
+- Rotate or renew session state after login and privilege changes.
+- Delete sessions server-side on logout when using a server-side store.
+- Test security attributes on `Set-Cookie` headers.
+
+## Route Protection
+
+Read `references/auth-middleware.md` when adding admin routes, extractors,
+guards, or framework middleware.
+
+Keep handlers typed:
+
+```rust
+pub async fn admin_dashboard(user: AuthenticatedUser) -> Result {
+ // Handler can assume authentication succeeded.
+ Ok(HttpResponse::Ok().finish())
+}
+```
+
+Avoid optional user lookups in handlers that require authentication; make the
+missing-user case impossible at the handler signature when the framework allows
+it.
+
+## Reference Files
+
+- `references/password-auth.md`: Argon2, PHC strings, user enumeration, and
+ blocking password work.
+- `references/cookies-sessions.md`: cookie flags, signed messages, server-side
+ sessions, and logout.
+- `references/auth-middleware.md`: route guards, extractors, and typed session
+ access.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-service-security/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-service-security/agents/openai.yaml
new file mode 100644
index 00000000..0e374185
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-service-security/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust Service Security"
+ short_description: "Review Rust web auth, cookies, and sessions"
+ default_prompt: "Review or implement secure auth behavior in this Rust service."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-service-security/references/auth-middleware.md b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/auth-middleware.md
new file mode 100644
index 00000000..e5970b7f
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/auth-middleware.md
@@ -0,0 +1,32 @@
+# Auth Middleware And Typed Access
+
+Route protection should be centralized and visible in tests.
+
+## Guard Boundary
+
+Use the framework's middleware, extractor, or guard mechanism to turn session
+state into a typed authenticated user:
+
+```rust
+pub struct AuthenticatedUser {
+ pub user_id: uuid::Uuid,
+}
+```
+
+Handlers that require auth should accept `AuthenticatedUser`, not
+`Option`.
+
+## Checks
+
+- Authentication: is there a valid session or token?
+- Authorization: is this authenticated identity allowed to perform this action?
+- Freshness: does this operation require recent password verification?
+- CSRF: do cookie-authenticated mutating requests have CSRF protection?
+
+## Tests
+
+- Unauthenticated requests are rejected or redirected.
+- Authenticated users can access allowed routes.
+- Authenticated but unauthorized users are rejected.
+- Session tampering or unknown session IDs fail closed.
+- Middleware preserves request data needed by downstream handlers.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-service-security/references/cookies-sessions.md b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/cookies-sessions.md
new file mode 100644
index 00000000..d08a85f4
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/cookies-sessions.md
@@ -0,0 +1,39 @@
+# Cookies And Sessions
+
+Cookies are a transport for session state, not a place to store credentials.
+
+## Cookie Attributes
+
+For session cookies:
+
+- `HttpOnly`: true by default.
+- `Secure`: true outside local development.
+- `SameSite`: `Lax` for most server-rendered apps; use `Strict` only when the
+ product flow tolerates it.
+- `Path`: keep as narrow as practical.
+- `Max-Age` or `Expires`: align with session policy.
+
+Test `Set-Cookie` headers when adding auth flows.
+
+## Session Storage
+
+Prefer opaque session IDs backed by Redis, Postgres, or the framework's
+server-side session store for privileged applications.
+
+Signed client-side cookies are acceptable only when:
+
+- The stored data is small and non-sensitive.
+- The signing/encryption key is managed as a secret.
+- Revocation requirements are understood.
+
+## Login And Logout
+
+- Renew or rotate session identifiers after login.
+- Clear flash messages and transient auth state deliberately.
+- Delete server-side session records on logout when applicable.
+- Return redirects that match the product flow and do not create open redirects.
+
+## Signed Messages
+
+Flash messages and one-time notices can use signed cookies if they are not
+secrets and expire quickly. Treat the signing key as a secret.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-service-security/references/password-auth.md b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/password-auth.md
new file mode 100644
index 00000000..ae6c3e2f
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-service-security/references/password-auth.md
@@ -0,0 +1,47 @@
+# Password Authentication
+
+Password code is security-critical and performance-sensitive. Keep it small,
+tested, and isolated from handlers.
+
+## Storage
+
+- Store a PHC string from a memory-hard password hasher such as Argon2id.
+- Do not store plaintext passwords, reversible encrypted passwords, or separate
+ salt columns unless the chosen hasher requires it.
+- Treat password hashes as sensitive operational data. Avoid logging them.
+
+## Verification Boundary
+
+```rust
+pub async fn verify_password(
+ candidate: secrecy::SecretString,
+ expected_hash: secrecy::SecretString,
+) -> Result {
+ tokio::task::spawn_blocking(move || {
+ verify_password_blocking(candidate, expected_hash)
+ })
+ .await?
+}
+```
+
+Use `spawn_blocking` or an equivalent blocking worker boundary because password
+hashing is CPU and memory intensive.
+
+## User Enumeration
+
+Login and reset flows should not reveal whether an account exists.
+
+Patterns:
+
+- Return the same response for missing user and wrong password.
+- Consider a fake password hash for missing users so timing does not trivially
+ reveal account existence.
+- Log safe diagnostic fields internally, not raw credentials.
+
+## Tests
+
+- Valid password succeeds.
+- Wrong password fails.
+- Missing user returns the same public response as wrong password.
+- Password hash verification does not run on the async reactor directly when
+ the project has an abstraction for blocking work.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/SKILL.md b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/SKILL.md
new file mode 100644
index 00000000..9a94cfa7
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: rust-sqlx-postgres-service
+description: Use when adding, changing, testing, or reviewing Postgres persistence in Rust services that use sqlx, especially when designing migrations, query! or query_as! calls, PgPool injection, transactions, compile-time checked SQL, SQLx offline mode, repository boundaries, or database-backed integration tests.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Rust SQLx Postgres Service
+ category: Rust
+ tags: rust,sqlx,postgres,migrations,persistence
+---
+
+# Rust SQLx Postgres Service
+
+Use this skill to make Rust/Postgres changes schema-first, compile-checked, and
+testable. Prefer explicit migrations, injected pools, narrow repository
+functions, and transaction boundaries that match the business operation.
+
+## Core Workflow
+
+1. Inspect `Cargo.toml`, `migrations/`, `.sqlx/`, `docker-compose.yml`, CI, and
+ existing database helper modules before changing code.
+2. Design the schema change first. Create or update a migration before writing
+ repository code that depends on it.
+3. Prefer `sqlx::query!` and `query_as!` for compile-time checked SQL. Use
+ dynamic SQL only when the query shape truly changes at runtime.
+4. Inject `PgPool`, `PgConnection`, or `Transaction` explicitly. Do not create a
+ pool inside handlers or repository functions.
+5. Keep repository functions small and named by behavior. Return domain types
+ or persistence DTOs instead of leaking raw rows through the app.
+6. Use a transaction for multi-step operations that must commit or roll back
+ together.
+7. Add or update integration tests that run migrations and exercise the public
+ behavior when the change affects API semantics.
+8. Run the bundled preflight script or the repository's equivalent SQLx/Cargo
+ CI commands.
+
+## Migration Rules
+
+Read `references/migration-safety.md` before changing existing tables or data.
+
+Default migration preferences:
+
+- Use additive changes first: new nullable columns, new tables, new indexes.
+- Backfill separately from schema creation when a table may be large.
+- Add `not null`, uniqueness, and foreign-key constraints only after existing
+ data satisfies them.
+- Name constraints and indexes deliberately when they will appear in errors or
+ operations.
+- Keep down migrations if the project uses them; otherwise document rollback
+ expectations in the migration review.
+
+## Query Rules
+
+Read `references/sqlx-patterns.md` for SQLx macro, transaction, and offline
+mode details.
+
+- Prefer bind parameters over string interpolation.
+- Use `fetch_optional` for lookup-by-key operations.
+- Use `execute` for inserts/updates where row data is not needed.
+- Use `RETURNING` when the caller needs generated IDs or timestamps.
+- Check affected row counts for updates and deletes that should target exactly
+ one row.
+- Map database uniqueness conflicts to domain errors near the repository edge.
+
+## Verification
+
+Run from the Rust project root when the standard SQLx workflow applies:
+
+```bash
+path/to/rust-sqlx-postgres-service/scripts/sqlx-preflight.sh
+```
+
+The script is conservative: it checks formatting and tests, inspects SQLx
+migration state when the CLI and `DATABASE_URL` are available, verifies SQLx
+offline metadata with `cargo sqlx prepare --check` when `.sqlx/` or
+`DATABASE_URL` is available, and only applies migrations when
+`RUST_SQLX_PREFLIGHT_RUN_MIGRATIONS=1` is set.
+
+If the repository has a different CI command, use that command and explain why.
+
+## Reference Files
+
+- `references/sqlx-patterns.md`: `query!`, `query_as!`, pools, transactions,
+ feature flags, and offline mode.
+- `references/migration-safety.md`: safe migration sequencing and rollout
+ checks.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/agents/openai.yaml
new file mode 100644
index 00000000..b3d721b0
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Rust SQLx Postgres Service"
+ short_description: "Build safe SQLx/Postgres service layers"
+ default_prompt: "Add or review SQLx/Postgres persistence for this Rust service."
diff --git a/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/migration-safety.md b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/migration-safety.md
new file mode 100644
index 00000000..b1ff19f8
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/migration-safety.md
@@ -0,0 +1,32 @@
+# Migration Safety
+
+Review migrations as production changes, not just local setup.
+
+## Safe Sequencing
+
+Prefer expand/backfill/contract:
+
+1. Expand: add a table, nullable column, index, or non-enforced path.
+2. Deploy code that writes both old and new shapes if needed.
+3. Backfill existing data in bounded batches.
+4. Add constraints after data is valid.
+5. Remove old columns or tables only after callers no longer depend on them.
+
+## Checks Before Merging
+
+- Does the migration run on an empty database?
+- Does it run on a database with realistic existing data?
+- Are large table rewrites avoided or explicitly planned?
+- Are new indexes needed before new query paths ship?
+- Are uniqueness constraints backed by product behavior and tests?
+- Does rollback policy match the team's migration style?
+
+## Constraint Errors
+
+Map expected constraint failures to domain errors:
+
+- Unique email or username: conflict or validation error.
+- Foreign key missing: bad request or internal bug depending on caller.
+- Check constraint violation: validation error if caused by user input.
+
+Do not expose raw database error strings to users.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/sqlx-patterns.md b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/sqlx-patterns.md
new file mode 100644
index 00000000..e25cf5f2
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/references/sqlx-patterns.md
@@ -0,0 +1,102 @@
+# SQLx Patterns
+
+Use SQLx's compile-time checked macros when the SQL shape is known at compile
+time. They catch column names, nullability, and type mismatches before runtime.
+
+## Pool Injection
+
+Create the pool at startup and pass it through application state:
+
+```rust
+pub struct AppState {
+ pub db_pool: sqlx::PgPool,
+}
+
+pub async fn create_pool(database_url: &str) -> Result {
+ sqlx::postgres::PgPoolOptions::new()
+ .max_connections(10)
+ .connect(database_url)
+ .await
+}
+```
+
+Repository functions should accept `&PgPool`, `&mut PgConnection`, or
+`&mut Transaction<'_, Postgres>` depending on the needed boundary.
+
+## Query Macros
+
+```rust
+let user = sqlx::query!(
+ r#"
+ select id, email, password_hash
+ from users
+ where email = $1
+ "#,
+ email.as_str(),
+)
+.fetch_optional(pool)
+.await?;
+```
+
+Use `query_as!` when mapping into a concrete struct:
+
+```rust
+#[derive(Debug)]
+pub struct SubscriberRow {
+ pub id: uuid::Uuid,
+ pub email: String,
+}
+
+let rows = sqlx::query_as!(
+ SubscriberRow,
+ "select id, email from subscriptions where status = $1",
+ "confirmed",
+)
+.fetch_all(pool)
+.await?;
+```
+
+## Transactions
+
+Use transactions for workflows that update multiple rows or combine persistence
+with idempotency state:
+
+```rust
+let mut tx = pool.begin().await?;
+
+insert_issue(&mut tx, issue).await?;
+mark_idempotency_key_used(&mut tx, key).await?;
+
+tx.commit().await?;
+```
+
+Pass `&mut tx` down rather than starting nested transactions in helpers.
+
+## Offline Mode
+
+SQLx macros need either `DATABASE_URL` at build time or a checked-in `.sqlx/`
+metadata directory. For Docker or CI builds without a database:
+
+```bash
+cargo sqlx prepare --workspace -- --all-targets --all-features
+SQLX_OFFLINE=true cargo build --release
+```
+
+Keep `.sqlx/` in sync when migrations or query shapes change.
+
+## Feature Flags
+
+Common dependencies:
+
+```toml
+sqlx = { version = "0.8", default-features = false, features = [
+ "runtime-tokio-rustls",
+ "postgres",
+ "uuid",
+ "chrono",
+ "migrate",
+] }
+```
+
+Match features to actual column types. Missing `uuid`, `chrono`, `time`, or
+`json` features often show up as macro compilation errors.
diff --git a/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/scripts/sqlx-preflight.sh b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/scripts/sqlx-preflight.sh
new file mode 100755
index 00000000..b04eea11
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/rust-sqlx-postgres-service/scripts/sqlx-preflight.sh
@@ -0,0 +1,43 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v cargo >/dev/null 2>&1; then
+ echo "cargo is required" >&2
+ exit 127
+fi
+
+if [ ! -f Cargo.toml ]; then
+ echo "run this script from a Rust project root containing Cargo.toml" >&2
+ exit 2
+fi
+
+echo "==> cargo fmt"
+cargo fmt --all --check
+
+if command -v sqlx >/dev/null 2>&1 && [ -d migrations ]; then
+ if [ -d .sqlx ] || [ -n "${DATABASE_URL:-}" ]; then
+ echo "==> cargo sqlx prepare --check"
+ cargo sqlx prepare --check --workspace
+ else
+ echo "==> skipping cargo sqlx prepare --check; .sqlx/ and DATABASE_URL are not available"
+ fi
+
+ if [ -n "${DATABASE_URL:-}" ]; then
+ echo "==> sqlx migrate info"
+ sqlx migrate info
+
+ if [ "${RUST_SQLX_PREFLIGHT_RUN_MIGRATIONS:-0}" = "1" ]; then
+ echo "==> sqlx migrate run"
+ sqlx migrate run
+ else
+ echo "==> skipping sqlx migrate run; set RUST_SQLX_PREFLIGHT_RUN_MIGRATIONS=1 to apply migrations"
+ fi
+ else
+ echo "==> skipping sqlx migrate info; DATABASE_URL is not set"
+ fi
+else
+ echo "==> skipping sqlx CLI checks; sqlx command or migrations/ directory not found"
+fi
+
+echo "==> cargo test"
+cargo test --all-features
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/SKILL.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/SKILL.md
new file mode 100644
index 00000000..853bbeff
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/SKILL.md
@@ -0,0 +1,79 @@
+---
+name: self-publishing-production
+description: Plan and check the final production tasks for self-publishing nonfiction books, including copyediting, final review readers, proofreading, layout, cover files, print-on-demand, ISBNs, and launch-readiness sequencing. Use when preparing a manuscript for publication after beta reading or when auditing a self-publishing checklist.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Self-Publishing Production
+ category: Writing
+ tags: writing,books,nonfiction,self-publishing,production,publishing
+---
+
+# Self-Publishing Production
+
+## Core Lens
+
+Production begins after the manuscript's big-picture structure, promise, and reader value are mostly working. These tasks are predictable and solvable, but doing them too early wastes effort because beta feedback may still reshape the book.
+
+Use this skill to plan or audit:
+
+- Copyediting.
+- Final review readers.
+- Proofreading.
+- Interior layout.
+- Cover file requirements.
+- Print-on-demand and retailer setup.
+- ISBN decisions.
+- Final PDF/page checks.
+
+## Reference Routing
+
+| Need | Read |
+|------|------|
+| Production concepts and sequencing | `references/core/knowledge.md` |
+| Production rules and current-info caveats | `references/core/rules.md` |
+| Example production plans and decisions | `references/core/examples.md` |
+| Final checklist | `references/core/checklist.md` |
+| Prepare production plan | `workflows/prepare-production.md` |
+
+## Workflow
+
+### 1. Confirm The Manuscript Is Ready For Production
+
+Check that:
+
+- Beta readers have validated desire, effectiveness, and engagement.
+- Remaining issues are mostly polish, accuracy, layout, or packaging.
+- The author is not using production work to avoid structural revision.
+
+### 2. Sequence The Work
+
+Recommended order:
+
+1. Final structural review or developmental review if still needed.
+2. Copyedit for clarity, concision, and sentence-level quality.
+3. Expert, sensitivity, legal, or influential review where relevant.
+4. Proofread.
+5. Interior layout for ebook, paperback, hardback, or PDF.
+6. Cover files for each format.
+7. Print-on-demand, retailer, ISBN, and metadata setup.
+8. Final PDF/page review.
+
+### 3. Verify Current Production Requirements
+
+Before giving precise setup instructions, verify current requirements from the relevant platform or vendor. KDP, IngramSpark, ISBN agencies, cover dimensions, trim rules, file formats, and royalty terms can change.
+
+### 4. Return A Practical Checklist
+
+Return:
+
+1. Production-readiness diagnosis.
+2. Ordered task plan.
+3. Tasks to hire vs do yourself.
+4. Platform-specific checks that need current verification.
+5. Final quality gates.
+
+## Quality Bar
+
+Keep production advice specific enough to execute but conservative about platform details. Never let formatting, cover, or upload work start before the manuscript is structurally ready unless the user explicitly accepts the rework risk.
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/checklist.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/checklist.md
new file mode 100644
index 00000000..361fe497
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/checklist.md
@@ -0,0 +1,63 @@
+# Self-Publishing Production Checklist
+
+Use this checklist after beta reading and before publication.
+
+## Production Readiness
+
+- [ ] Book promise and scope are stable.
+- [ ] Beta readers have validated reader value.
+- [ ] Major structure and reader-experience issues are resolved.
+- [ ] Remaining work is editorial, production, metadata, or launch support.
+
+## Editorial
+
+- [ ] Developmental review is complete or intentionally skipped.
+- [ ] Copyedit is scheduled or complete.
+- [ ] Expert review is scheduled where accuracy risk exists.
+- [ ] Sensitivity review is scheduled where relevant.
+- [ ] Legal review is scheduled where relevant.
+- [ ] Proofreading is scheduled after copyedit.
+
+## Layout
+
+- [ ] Ebook layout plan exists.
+- [ ] Paperback layout plan exists if printing.
+- [ ] PDF layout plan exists if selling or distributing PDF.
+- [ ] Images, tables, captions, footnotes, and links are checked.
+- [ ] Final PDF is visually reviewed.
+- [ ] Print proof is ordered when practical.
+
+## Cover And Assets
+
+- [ ] Ebook front cover.
+- [ ] Paperback full cover with correct trim and spine.
+- [ ] Hardback assets if relevant.
+- [ ] Audiobook square cover if relevant.
+- [ ] Social and retailer thumbnails if relevant.
+- [ ] Barcode/ISBN placement handled.
+
+## Platform And Metadata
+
+- [ ] Current retailer or distributor requirements are verified.
+- [ ] ISBN strategy is chosen.
+- [ ] Metadata, categories, keywords, and description are prepared.
+- [ ] Pricing and territories are decided.
+- [ ] Author profile and publisher/imprint details are prepared.
+
+## Red Flags
+
+- Copyediting starts while chapters may still be deleted.
+- Layout starts before manuscript text is stable.
+- Platform-specific advice is based on memory instead of current docs.
+- Cover dimensions are guessed.
+- Final PDF is not visually reviewed.
+
+## Quick Reference
+
+| Area | Done Means |
+|------|------------|
+| Manuscript | Structure stable and edited. |
+| Reviews | Accuracy, sensitivity, legal, and proofing addressed as needed. |
+| Layout | Every format exported and visually checked. |
+| Cover | Correct asset for each format. |
+| Metadata | Current platform fields prepared. |
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/examples.md
new file mode 100644
index 00000000..1b715e72
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/examples.md
@@ -0,0 +1,88 @@
+# Self-Publishing Production Examples
+
+Synthetic examples for production decisions.
+
+## Production Sequence
+
+### Good Sequence
+
+```text
+Beta reading complete
+-> expert review for accuracy
+-> copyedit
+-> proofread
+-> layout ebook and paperback
+-> create final cover files
+-> upload and order proof
+-> scan PDF/proof
+-> publish
+```
+
+**Why it works**:
+- Structural changes happen before polish.
+- Accuracy checks happen before final wording is locked.
+- Layout is reviewed visually before publication.
+
+### Risky Sequence
+
+```text
+First draft
+-> cover design
+-> paperback layout
+-> proofread
+-> beta reading
+```
+
+**Problems**:
+- Beta feedback may force structural changes after expensive production work.
+- Proofreading happens before content is stable.
+- Layout work may need to be redone.
+
+## Hire Or Do Yourself
+
+| Task | Usually Hire | Can DIY When |
+|------|--------------|--------------|
+| Copyediting | Quality matters and budget exists | Author has strong editing skill and low risk |
+| Proofreading | Almost always worth outside eyes | Private/internal release |
+| Layout | Complex layout, index, many images | Simple book and frequent updates expected |
+| Cover | Commercial public release | Author has design ability or strong template |
+| ISBN setup | Complex imprint/distribution | Simple platform-only release |
+
+## Final Review Reader Choice
+
+### Expert Reader
+
+Use when:
+- The book makes technical, legal, medical, financial, scientific, or specialized claims.
+- The author may have overgeneralized.
+
+### Sensitivity Reader
+
+Use when:
+- The manuscript discusses identities, cultures, trauma, marginalization, or lived experiences outside the author's expertise.
+
+### Legal Review
+
+Use when:
+- The book names real people or entities in risky anecdotes.
+- The book includes potentially defamatory claims.
+- The book uses copyrighted material, private information, or sensitive IP.
+
+### Influential Reader
+
+Use when:
+- The book is nearly strong enough for a testimonial.
+- The reader's endorsement may help the cover, product page, or launch.
+
+## Visual PDF Checks
+
+Look for:
+
+- Heading stranded at bottom of page.
+- First or last line of paragraph isolated.
+- Lists split awkwardly.
+- Image or caption separated.
+- Large accidental whitespace.
+- Page numbers missing or inconsistent.
+- Blank pages in the wrong place.
+- Font or glyph rendering problems.
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/knowledge.md
new file mode 100644
index 00000000..00526aa3
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/knowledge.md
@@ -0,0 +1,92 @@
+# Self-Publishing Production Knowledge
+
+Core concepts for turning a validated manuscript into publishable book files.
+
+## Overview
+
+Self-publishing production is the final sequence of professionalization tasks after the book is working for readers. It includes editorial polish, final reviews, formatting, cover assets, retail setup, and quality checks.
+
+## Key Concepts
+
+### Copyediting
+
+**Definition**: Editing for clarity, concision, phrasing, consistency, and sentence-level quality.
+
+Copyediting does not solve big-picture structure. It should happen after beta reading or developmental editing has addressed major issues.
+
+### Proofreading
+
+**Definition**: Final pass for typos, grammar, and small errors.
+
+Proofreading usually happens after copyediting and near the final layout stage, although integrating edits in the manuscript source can be faster for some workflows.
+
+### Final Review Readers
+
+**Definition**: Targeted reviewers who catch issues beta reading may miss.
+
+Examples include expert readers, sensitivity readers, legal reviewers, and influential readers who may provide testimonials or editorial reviews.
+
+### Interior Layout
+
+**Definition**: Formatting the manuscript into ebook, paperback, hardback, or PDF files.
+
+Layout quality includes readable typography, stable section breaks, image placement, page numbering, and no awkward widows, orphans, or broken lists.
+
+### Cover Files
+
+**Definition**: The format-specific cover assets needed for ebook, paperback, hardback, audiobook, and marketing images.
+
+Paperback and hardback covers usually need exact trim size and spine width based on page count and paper type.
+
+### Print-On-Demand Setup
+
+**Definition**: Configuring a service or retailer to print, distribute, and sell physical books.
+
+Requirements differ by platform and change over time, so current official documentation matters.
+
+### ISBN
+
+**Definition**: A book identifier used for specific formats and editions.
+
+Each format or major edition may need a separate ISBN. Free platform ISBNs can be convenient but may limit publisher imprint control.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Trim size | Physical page dimensions of a printed book. |
+| Spine width | Width of the book spine based on page count and paper. |
+| POD | Print on demand. |
+| Imprint | Publisher name under which the book is published. |
+| Proof copy | Physical or digital test copy reviewed before release. |
+
+## How It Relates To
+
+- **Beta Reader Feedback**: Production begins after beta feedback validates the core book.
+- **Book Sales Optimization**: Cover, metadata, descriptions, and formats affect sales.
+- **Reader Experience Edit**: Layout and page design can support or harm readability.
+
+## Common Misconceptions
+
+- **Myth**: A copyeditor fixes structural problems.
+ **Reality**: Copyediting improves prose after structure is already sound.
+
+- **Myth**: Layout is just decoration.
+ **Reality**: Bad layout can create broken reading experiences and visible quality issues.
+
+- **Myth**: One cover file works everywhere.
+ **Reality**: Each format may need its own dimensions and export requirements.
+
+- **Myth**: ISBNs are only admin trivia.
+ **Reality**: ISBN choices can affect imprint, distribution, and edition management.
+
+## Quick Reference
+
+| Concept | One-Line Summary |
+|---------|------------------|
+| Copyedit | Sentence-level improvement after structure is stable. |
+| Proofread | Final typo and grammar pass. |
+| Final review | Expert, legal, sensitivity, or testimonial checks. |
+| Layout | Turn manuscript into clean book files. |
+| Cover files | Format-specific cover assets. |
+| ISBN | Identifier decisions by format and edition. |
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/rules.md
new file mode 100644
index 00000000..83d476f2
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/references/core/rules.md
@@ -0,0 +1,82 @@
+# Self-Publishing Production Rules
+
+Use these rules when planning final production for a self-published nonfiction book.
+
+## Core Rules
+
+### 1. Do Structural Work Before Production
+
+Production should not begin while the book's promise, structure, or reader value is still unstable.
+
+- Finish beta reading or developmental review first.
+- Resolve major reader confusion and boredom before copyediting.
+- Avoid formatting pages that may be deleted or moved.
+
+### 2. Use The Right Editor For The Current Problem
+
+Different reviews solve different issues.
+
+- Developmental editor: big-picture structure and argument.
+- Copyeditor: sentence-level clarity and style.
+- Proofreader: typos, grammar, and final errors.
+- Expert reader: accuracy and overgeneralization.
+- Sensitivity reader: bias, harm, and marginalization.
+- Legal review: libel, rights, privacy, or IP risk.
+
+### 3. Verify Current Platform Requirements
+
+Before providing exact production instructions, check the relevant official guidance.
+
+- KDP, IngramSpark, Draft2Digital, retailers, and ISBN agencies change requirements.
+- Cover dimensions depend on current trim, paper, binding, and page count.
+- File requirements differ by format and platform.
+
+### 4. Plan Cover Assets By Format
+
+Each format may need a distinct file.
+
+- Ebook front cover.
+- Paperback front, back, and spine.
+- Hardback jacket or case cover when relevant.
+- Audiobook square cover.
+- Marketing images or thumbnails.
+
+### 5. Review Final PDFs Visually
+
+Do not rely only on text extraction or automated export success.
+
+- Scan every page or representative pages for layout errors.
+- Check section starts, list breaks, headings, images, captions, page numbers, and blank pages.
+- Order a proof copy for print when possible.
+
+### 6. Decide ISBN Strategy Early Enough
+
+ISBNs can affect setup and metadata.
+
+- Free platform ISBNs are convenient.
+- Owned ISBNs support a custom imprint and broader control.
+- Different formats and major editions may require different ISBNs.
+
+## Guidelines
+
+- Hire specialists when the task is high-leverage and tedious to do yourself.
+- Learn layout yourself only if frequent updates are likely or control matters.
+- Keep source manuscript and formatted exports clearly separated.
+- Keep a release checklist with owner, status, and current platform links.
+
+## Exceptions
+
+- **Lean early access**: Some authors can release rougher digital editions intentionally, but should label them clearly.
+- **Publisher-managed production**: The publisher may own copyediting, layout, covers, metadata, and upload.
+- **Internal or private books**: ISBNs, retailer metadata, and public cover requirements may not apply.
+
+## Quick Reference
+
+| Rule | Summary |
+|------|---------|
+| Structure first | Do not polish unstable content. |
+| Right editor | Match review type to problem type. |
+| Verify platforms | Current official requirements matter. |
+| Format covers | Each product needs correct assets. |
+| Visual PDF check | Export success is not quality assurance. |
+| ISBN strategy | Decide imprint and format IDs deliberately. |
diff --git a/plugins/LVTD-LLC/skills/skills/self-publishing-production/workflows/prepare-production.md b/plugins/LVTD-LLC/skills/skills/self-publishing-production/workflows/prepare-production.md
new file mode 100644
index 00000000..00f0ba9e
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/self-publishing-production/workflows/prepare-production.md
@@ -0,0 +1,82 @@
+# Prepare Production Workflow
+
+Use this workflow to move a validated manuscript into publication production.
+
+## When To Use
+
+- Beta reading is complete or nearly complete.
+- The author needs an ordered production checklist.
+- The book is moving toward self-publication.
+
+## Prerequisites
+
+- Stable manuscript or final beta revision.
+- Target formats, such as ebook, paperback, PDF, or audiobook.
+- Intended sales/distribution channels.
+
+**Reference**: `references/core/rules.md`
+
+---
+
+## Workflow Steps
+
+### Step 1: Confirm Readiness
+
+**Goal**: Avoid production rework.
+
+- [ ] Confirm no major structure changes are expected.
+- [ ] Confirm beta feedback has been addressed.
+- [ ] Confirm remaining issues are editorial or production issues.
+
+---
+
+### Step 2: Plan Editorial Passes
+
+**Goal**: Match review type to risk.
+
+- [ ] Decide whether developmental review is still needed.
+- [ ] Schedule copyediting.
+- [ ] Schedule expert, sensitivity, legal, or influential review as needed.
+- [ ] Schedule proofreading after text is stable.
+
+---
+
+### Step 3: Choose Formats And Platforms
+
+**Goal**: Define required outputs.
+
+- [ ] List formats: ebook, paperback, hardback, PDF, audiobook.
+- [ ] List platforms or distributors.
+- [ ] Verify current file, cover, metadata, and ISBN requirements.
+- [ ] Decide whether to sell direct, through retailers, or both.
+
+---
+
+### Step 4: Prepare Assets
+
+**Goal**: Create all files needed for upload and promotion.
+
+- [ ] Interior files for each format.
+- [ ] Cover files for each format.
+- [ ] ISBN/barcode assets where needed.
+- [ ] Product description, categories, keywords, author bio, and endorsements.
+
+---
+
+### Step 5: Run Final Quality Gates
+
+**Goal**: Catch visible errors before publication.
+
+- [ ] Visually review final PDFs.
+- [ ] Check ebook links and navigation.
+- [ ] Order and review print proof when practical.
+- [ ] Confirm pricing, territories, and metadata.
+- [ ] Archive final source and export files.
+
+## Exit Criteria
+
+Task is complete when:
+
+- [ ] Every required format has an owner and status.
+- [ ] Current platform requirements have been checked.
+- [ ] Final quality gates are complete or scheduled.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/SKILL.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/SKILL.md
new file mode 100644
index 00000000..14f39d99
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/SKILL.md
@@ -0,0 +1,46 @@
+---
+name: seo-opportunity-research
+description: Find product-led and blue-ocean SEO opportunities from customer demand, query behavior, competitive gaps, search result features, communities, and proprietary product strengths. Use when researching SEO opportunities, organic growth ideas, competitive SEO gaps, programmatic SEO concepts, or when keyword tools show little volume.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: SEO Opportunity Research
+ category: Marketing
+ tags: seo,research,organic-growth,competitive-research,blue-ocean
+---
+
+# SEO Opportunity Research
+
+Use this skill to find SEO opportunities that come from user needs and product advantages, not just keyword-tool exports. It is especially useful when the best opportunity is under-measured, emerging, long-tail, or hard for competitors to copy.
+
+This skill is derived from Eli Schwartz's *Product-Led SEO* and uses transformed guidance with durable book-topic references. Do not copy book prose into user outputs.
+
+## Quick Start
+
+1. Load `guidelines.md` to choose the right reference.
+2. Use `workflows/find-seo-opportunities.md` for a full research pass.
+3. Start with customers, communities, product strengths, and search behavior.
+4. Use competitors to learn intent and gaps, not to clone their roadmap.
+5. Return prioritized opportunities with evidence, product surface, moat, and next validation step.
+
+## Default Output
+
+When asked to research opportunities, return:
+
+1. **Opportunity themes** - grouped by user need or product surface.
+2. **Evidence** - customer, community, Search Console, SERP, competitor, or proxy evidence.
+3. **Product-led surface** - what should be built.
+4. **Moat** - why the opportunity is defensible.
+5. **Validation step** - how to test demand or feasibility.
+6. **Priority** - impact, confidence, effort, and time-to-signal.
+
+## Contents
+
+| Need | Start Here |
+|------|------------|
+| Understand blue-ocean SEO | `references/core/knowledge.md` |
+| Apply research rules | `references/core/rules.md` |
+| See opportunity examples | `references/core/examples.md` |
+| Run a research pass | `workflows/find-seo-opportunities.md` |
+| Route by task | `guidelines.md` |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/agents/openai.yaml
new file mode 100644
index 00000000..6915e993
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "SEO Opportunity Research"
+ short_description: "Find blue-ocean SEO opportunities and competitive gaps."
+ default_prompt: "Find SEO opportunities for this product without copying competitors."
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/guidelines.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/guidelines.md
new file mode 100644
index 00000000..fcd83c53
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/guidelines.md
@@ -0,0 +1,44 @@
+# SEO Opportunity Research Guidelines
+
+Load the minimum files needed for the task.
+
+## By Task
+
+| What you're doing | Load these files |
+|-------------------|------------------|
+| Finding new organic growth opportunities | `references/core/knowledge.md`, `workflows/find-seo-opportunities.md` |
+| Researching low-volume or no-volume ideas | `references/core/rules.md`, `references/core/examples.md` |
+| Reviewing competitor SEO | `references/core/rules.md` |
+| Mining SERP features and query refinements | `references/core/knowledge.md`, `workflows/find-seo-opportunities.md` |
+| Prioritizing opportunity ideas | `references/core/rules.md`, `references/core/examples.md` |
+
+## By Problem
+
+| If you notice... | Load these files |
+|------------------|------------------|
+| Keyword tools show no demand | `references/core/knowledge.md`, `references/core/rules.md` |
+| Competitor research is becoming copycat planning | `references/core/rules.md` |
+| The opportunity has no defensible product surface | `references/core/examples.md` |
+| The user asks for "programmatic SEO ideas" | `workflows/find-seo-opportunities.md` |
+| Research ignores customer language | `references/core/rules.md` |
+
+## Decision Tree
+
+```text
+What evidence is available?
+|
++-- Existing customers -> start with customer gaps and language
++-- Search Console -> mine non-brand queries and impressions
++-- Competitors -> inspect query intent, content gaps, links, and structure
++-- No data -> use communities, surveys, and proxy products
++-- Need roadmap -> hand off to seo-roadmap-prioritization
+```
+
+## File Index
+
+| File | Purpose |
+|------|---------|
+| `references/core/knowledge.md` | Blue-ocean, red-ocean, query, and competitor concepts |
+| `references/core/rules.md` | Research rules and anti-patterns |
+| `references/core/examples.md` | Opportunity examples and scoring |
+| `workflows/find-seo-opportunities.md` | Repeatable research process |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/examples.md
new file mode 100644
index 00000000..12091a03
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/examples.md
@@ -0,0 +1,45 @@
+# SEO Opportunity Research Examples
+
+Examples for turning raw research into product-led SEO opportunities.
+
+## Opportunity Patterns
+
+| Signal | Possible Surface | Evidence To Collect |
+|--------|------------------|---------------------|
+| Customers repeatedly ask "which option fits me?" | Selector, quiz, comparison tool | Sales notes, support tickets, query modifiers |
+| Users search for pairs of tools/products | Integration or compatibility pages | Autocomplete, competitor pages, product logs |
+| Search results are generic and shallow | Narrow expert guide or database | SERP review, community complaints |
+| Users need local or contextual detail | Location/service pages with real utility | Local SERPs, customer geography, service availability |
+| Internal data answers a common question | Data-backed index, benchmark, calculator | Product data, proprietary dataset, user interviews |
+
+## Competitor Gap Review
+
+When reviewing a search competitor, capture:
+
+| Dimension | Questions |
+|-----------|-----------|
+| Intent | Which user job does the page satisfy? |
+| Format | Is it article, product page, directory, tool, forum, or support page? |
+| Gaps | What question remains unanswered? |
+| UX | Is the page easy to use for the intent? |
+| Trust | What proof, data, authorship, or brand signals exist? |
+| Moat | Could we create a more useful or defensible surface? |
+
+## Opportunity Scoring Example
+
+| Idea | Impact | Confidence | Effort | Moat | Next Validation |
+|------|--------|------------|--------|------|-----------------|
+| Integration pair pages | High | Medium | Medium | Medium | Test 20 high-fit pairs |
+| Generic blog for head keyword | Medium | Low | Low | Low | Deprioritize unless product angle exists |
+| Proprietary benchmark page | High | Medium | High | High | Validate dataset quality and user demand |
+| Support issue library | Medium | High | Low | Medium | Publish top 25 known issues and measure support deflection |
+
+## Research Rewrite
+
+### Before
+
+"Competitor X gets traffic from these 50 pages. We should write similar articles."
+
+### After
+
+"Competitor X proves this intent exists, but their surface is shallow. We can build a structured tool that answers the user's decision question, uses our data, and creates internal links across related use cases."
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/knowledge.md
new file mode 100644
index 00000000..5e72987d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/knowledge.md
@@ -0,0 +1,67 @@
+# SEO Opportunity Research Knowledge
+
+Core concepts for finding organic search opportunities that are useful, defensible, and not obvious from keyword volume alone.
+
+## Source References
+
+| Topic | Durable Reference |
+|-------|-------------------|
+| Strategic SEO and Quora example | *Product-Led SEO*, strategic SEO and product-led opportunity examples |
+| Blue Ocean and Red Ocean SEO | *Product-Led SEO*, Blue Ocean and Red Ocean SEO concepts |
+| Future Blue Oceans and customer research | *Product-Led SEO*, customer research for emerging search demand |
+| Query refinements and search features | *Product-Led SEO*, query refinements, SERP features, and intent signals |
+| Competitive tracking | *Product-Led SEO*, competitor research and tracking |
+| Compounding and investment timing | *Product-Led SEO*, compounding SEO investment and time-to-signal |
+
+## Key Concepts
+
+### Blue-Ocean SEO
+
+**Definition**: SEO opportunity based on unmet or newly created demand where keyword data may be weak or nonexistent.
+
+Blue-ocean work begins with a hypothesis about users and their needs. It often depends on customer interviews, community research, product insight, and the ability to build a new useful surface.
+
+### Red-Ocean SEO
+
+**Definition**: SEO work in obvious, crowded keyword spaces where many competitors can target the same demand.
+
+Red-ocean work can still matter, but it is less defensible. Treat it as table stakes or comparison data, not the whole strategy.
+
+### Query Refinement Signals
+
+**Definition**: Search features that reveal how users and search engines reshape demand.
+
+Useful signals include autocomplete, related queries, "People also ask," query modifiers, local refinements, and SERP formats. These show intent paths more than exact volumes.
+
+### Competitor Set
+
+**Definition**: Any site satisfying the same search intent, not only companies selling a similar product.
+
+Competitors can include publishers, directories, marketplaces, support sites, government sites, and Wikipedia-like informational pages.
+
+### Opportunity Moat
+
+**Definition**: The reason the opportunity is hard to copy.
+
+Strong moats can come from data, inventory, scale, product workflow, community, brand trust, operational effort, or integration with the core product.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Proxy demand | Demand inferred from adjacent products, communities, competitor traffic, or user research |
+| Query set | A group of related searches around one user need |
+| Search surface | A repeatable product/page experience built for a query set |
+| Gap | A user need competitors answer poorly or not at all |
+| Time-to-signal | How quickly the team can see evidence of demand or SEO traction |
+
+## Common Misconceptions
+
+- **Myth**: No search volume means no opportunity.
+ **Reality**: New categories and long-tail patterns are often undercounted.
+
+- **Myth**: Competitor SEO research means copying their pages.
+ **Reality**: Competitors reveal intent, gaps, and structures to improve on.
+
+- **Myth**: The business competitor is always the search competitor.
+ **Reality**: Search competitors are whoever satisfies the same query.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/rules.md
new file mode 100644
index 00000000..0d6abf12
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/references/core/rules.md
@@ -0,0 +1,66 @@
+# SEO Opportunity Research Rules
+
+Use these rules to discover and evaluate SEO opportunities.
+
+## Core Rules
+
+### 1. Start With Missing User Value
+
+Look for things users want but cannot find, cannot compare, cannot trust, or cannot complete easily.
+
+- Talk to customers or inspect customer language.
+- Review communities, support tickets, sales calls, and search queries.
+- Ask what the product uniquely knows or can expose.
+
+### 2. Treat Low Volume As A Clue
+
+Do not reject an idea only because keyword tools show weak demand.
+
+- Check whether the category is new, niche, fragmented, or expressed in many long-tail variations.
+- Use proxies: adjacent sites, community volume, support demand, sales objections, or product usage.
+- Define a lightweight validation step before large investment.
+
+### 3. Use SERP Features To Understand Intent
+
+Search features show how users refine vague needs.
+
+- Collect autocomplete variations.
+- Review related searches and "People also ask."
+- Note local, device, image, video, shopping, snippet, or forum patterns.
+- Translate those patterns into user jobs.
+
+### 4. Learn From Competitors Without Copying
+
+Competitors should shorten learning, not define the plan.
+
+- Identify which search intents they satisfy.
+- Find gaps in depth, structure, freshness, UX, trust, or conversion path.
+- Inspect internal linking, page type, and link acquisition patterns.
+- Avoid tactics that are illegitimate, fragile, or purely content-volume based.
+
+### 5. Require A Product Surface
+
+Every promising opportunity should point to something the business can build.
+
+- Tool, directory, index, template, calculator, support library, comparison, data page, or product page.
+- If the answer is only "write content," explain why content alone is defensible.
+
+### 6. Score Impact, Confidence, Effort, And Moat
+
+Use a simple scoring model:
+
+| Criterion | Ask |
+|-----------|-----|
+| Impact | Could this drive meaningful business value? |
+| Confidence | What evidence supports demand and feasibility? |
+| Effort | What teams and time are required? |
+| Moat | How hard is this to copy? |
+| Time-to-signal | How soon can we learn if it works? |
+
+## Red Flags
+
+- The opportunity is just a competitor's top page with rewritten copy.
+- The idea depends on ranking for a head term with unclear user fit.
+- No product, data, or operational advantage is named.
+- There is no validation step before a large build.
+- The plan ignores why the user would choose this result.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/workflows/find-seo-opportunities.md b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/workflows/find-seo-opportunities.md
new file mode 100644
index 00000000..cd36ecb0
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-opportunity-research/workflows/find-seo-opportunities.md
@@ -0,0 +1,80 @@
+# Find SEO Opportunities Workflow
+
+Use this workflow to discover and prioritize product-led SEO opportunities.
+
+## When to Use
+
+- The user asks for SEO ideas, organic growth opportunities, or programmatic SEO concepts.
+- Keyword tools are weak or crowded.
+- Competitors have traction but the user needs a defensible angle.
+- The product has data, inventory, workflows, or expertise that could become search surfaces.
+
+## Prerequisites
+
+- Product/business description.
+- Known customer segments or pain points.
+- Existing site and competitors if available.
+- Search Console, analytics, support, sales, or product data if available.
+
+**Reference**: `references/core/knowledge.md`, `references/core/rules.md`
+
+## Workflow Steps
+
+### Step 1: Collect Demand Signals
+
+**Goal**: Build an evidence base beyond keyword volume.
+
+- [ ] List customer problems from interviews, support, sales, reviews, and communities.
+- [ ] Pull Search Console queries and impressions if available.
+- [ ] Inspect autocomplete, related queries, and "People also ask."
+- [ ] Note adjacent products or sites that reveal proxy demand.
+
+### Step 2: Define Query Sets
+
+**Goal**: Group demand by user job.
+
+- [ ] Cluster signals by intent, not exact keyword.
+- [ ] Identify whether each group is informational, comparative, transactional, support, or local.
+- [ ] Note where current SERPs fail the user.
+
+### Step 3: Study Search Competitors
+
+**Goal**: Learn what works and where gaps exist.
+
+- [ ] Identify competitors by SERP overlap, not just business category.
+- [ ] Review page type, content structure, trust signals, internal links, and CTAs.
+- [ ] Identify what they do well and what they leave unanswered.
+- [ ] Avoid copying their surface without a better user-value thesis.
+
+### Step 4: Generate Product-Led Surfaces
+
+**Goal**: Convert insights into buildable assets.
+
+- [ ] Propose tools, directories, databases, templates, support pages, comparisons, calculators, or product pages.
+- [ ] Name the data, content, or workflow required for each.
+- [ ] State why the business can build it credibly.
+- [ ] State what would make it difficult to copy.
+
+### Step 5: Score And Prioritize
+
+**Goal**: Choose what to validate first.
+
+- [ ] Score impact, confidence, effort, moat, and time-to-signal.
+- [ ] Pick 3-5 opportunities for near-term validation.
+- [ ] Define the smallest test for each opportunity.
+
+## Quick Checklist
+
+```text
+[ ] Demand signals collected
+[ ] Query sets clustered by intent
+[ ] Search competitors reviewed
+[ ] Product-led surfaces proposed
+[ ] Moat stated
+[ ] Validation tests defined
+[ ] Priorities scored
+```
+
+## Exit Criteria
+
+Task is complete when the user has a ranked opportunity list with evidence, surface, moat, validation step, and first owner/action.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/SKILL.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/SKILL.md
new file mode 100644
index 00000000..9ca787b9
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/SKILL.md
@@ -0,0 +1,47 @@
+---
+name: seo-persona-intent-mapping
+description: Map SEO personas, search intent, funnel stage, expected content format, CTA, device context, and localization needs into actionable organic search plans. Use when planning keyword research, SEO content briefs, funnel mapping, search intent analysis, persona-driven content, or when traffic is not converting.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: SEO Persona Intent Mapping
+ category: Marketing
+ tags: seo,personas,search-intent,content-strategy,conversion
+---
+
+# SEO Persona Intent Mapping
+
+Use this skill to turn vague keyword or audience ideas into a search-user map: who is searching, where they are in the buying journey, what content they expect, and what action should follow.
+
+This skill is derived from Eli Schwartz's *Product-Led SEO* and uses transformed guidance with durable book-topic references. Do not copy book prose into user outputs.
+
+## Quick Start
+
+1. Load `guidelines.md` to choose the smallest reference set.
+2. Use `workflows/map-persona-intent.md` for a full mapping pass.
+3. Build persona rows around search behavior, not demographics.
+4. Match each intent to content format, depth, CTA, device, and localization needs.
+5. Prioritize the work by customer value and business outcome.
+
+## Default Output
+
+When asked to map personas or intent, return:
+
+1. **Persona segments** - search-behavior-based groups.
+2. **Intent and funnel stage** - problem, research, comparison, purchase, support, or retention.
+3. **Expected content/product experience** - format and depth.
+4. **CTA** - next action appropriate to stage.
+5. **Device/localization considerations** - screen, language, country, and cultural cues.
+6. **Priority** - business value and evidence.
+7. **Open research questions** - what must be validated with users or data.
+
+## Contents
+
+| Need | Start Here |
+|------|------------|
+| Understand SEO-specific personas | `references/core/knowledge.md` |
+| Apply mapping rules | `references/core/rules.md` |
+| See mapping examples | `references/core/examples.md` |
+| Build a persona-intent table | `workflows/map-persona-intent.md` |
+| Route by task | `guidelines.md` |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/agents/openai.yaml
new file mode 100644
index 00000000..3c38fd8d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "SEO Persona Intent Mapping"
+ short_description: "Map personas, intent, funnel stage, and SEO content."
+ default_prompt: "Map our personas and search intent into an SEO content plan."
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/guidelines.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/guidelines.md
new file mode 100644
index 00000000..6aa39c6b
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/guidelines.md
@@ -0,0 +1,44 @@
+# SEO Persona Intent Mapping Guidelines
+
+Load the minimum files needed for the task.
+
+## By Task
+
+| What you're doing | Load these files |
+|-------------------|------------------|
+| Building SEO personas | `references/core/knowledge.md`, `workflows/map-persona-intent.md` |
+| Turning keywords into content briefs | `references/core/rules.md`, `references/core/examples.md` |
+| Diagnosing traffic that does not convert | `references/core/rules.md` |
+| Mapping funnel-stage CTAs | `references/core/knowledge.md`, `references/core/examples.md` |
+| Planning international or device-sensitive content | `references/core/rules.md` |
+
+## By Problem
+
+| If you notice... | Load these files |
+|------------------|------------------|
+| Personas are demographic but not search-behavior based | `references/core/knowledge.md` |
+| Keyword volume is driving content priority | `references/core/rules.md` |
+| Every page has the same CTA | `references/core/rules.md`, `references/core/examples.md` |
+| Long-form content is proposed for bottom-funnel needs | `references/core/examples.md` |
+| International content assumes translation without user evidence | `references/core/rules.md` |
+
+## Decision Tree
+
+```text
+Need a full map?
+|
++-- Yes -> map-persona-intent workflow
++-- No, just need rules -> references/core/rules.md
++-- Need examples -> references/core/examples.md
++-- Need broader strategy -> product-led-seo-strategy skill
++-- Need measurement -> seo-roadmap-prioritization or product-led-seo-strategy
+```
+
+## File Index
+
+| File | Purpose |
+|------|---------|
+| `references/core/knowledge.md` | Persona, funnel, intent, CTA, device, and locale concepts |
+| `references/core/rules.md` | Mapping rules and quality checks |
+| `references/core/examples.md` | Example persona-intent rows and rewrites |
+| `workflows/map-persona-intent.md` | Step-by-step mapping workflow |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/examples.md
new file mode 100644
index 00000000..6aa89c3d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/examples.md
@@ -0,0 +1,42 @@
+# SEO Persona Intent Mapping Examples
+
+Use these examples to structure persona-intent work.
+
+## Persona-Intent Table
+
+| Persona | Search Moment | Funnel Stage | Expected Experience | CTA | Metric |
+|---------|---------------|--------------|---------------------|-----|--------|
+| Problem-aware buyer | "How do I solve X?" | High | Educational guide, diagnostic tool, or explainer | Read next, subscribe, run tool | Engagement, email capture |
+| Evaluating buyer | "X vs Y" | Mid | Comparison page with criteria and tradeoffs | View demo, compare plans | Demo clicks, comparison completion |
+| Ready buyer | "X pricing" | Low | Pricing/product page with proof and clear next step | Start trial, contact sales | Conversion rate, qualified leads |
+| Existing customer | "How to fix X in product" | Support | Help article or troubleshooting flow | Resolve, contact support | Support deflection, solved rate |
+| International user | "[category] in [country]" | Variable | Localized details, currency, availability, culture cues | Country-specific next step | Local conversion proxy |
+
+## Weak vs Strong Brief
+
+### Weak
+
+"Write a 2,000-word article for a high-volume keyword."
+
+### Strong
+
+"For problem-aware buyers who are not ready to buy, create an educational page that explains the problem, shows decision criteria, links to adjacent topics, and invites the user into a low-pressure next step."
+
+## CTA Matching
+
+| Intent | Weak CTA | Better CTA |
+|--------|----------|------------|
+| Learning | Buy now | See examples, save checklist, read next |
+| Comparing | Subscribe | Compare plans, view product fit, book consult |
+| Buying | Learn more | Start trial, request quote, check availability |
+| Troubleshooting | Contact sales | Try fix, view docs, contact support |
+
+## Content Format Selection
+
+| User Need | Better Format |
+|-----------|---------------|
+| Needs a definition | Short answer plus related links |
+| Needs decision help | Comparison, matrix, buyer guide |
+| Needs a calculation | Calculator or worksheet |
+| Needs local availability | Location page with real service details |
+| Needs product confidence | Demo, proof, use cases, reviews |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/knowledge.md
new file mode 100644
index 00000000..3b92a84c
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/knowledge.md
@@ -0,0 +1,69 @@
+# SEO Persona Intent Mapping Knowledge
+
+Core concepts for mapping search behavior to SEO content and product experiences.
+
+## Source References
+
+| Topic | Durable Reference |
+|-------|-------------------|
+| SEO as business metric and funnel assist | *Product-Led SEO*, organic search as a business and funnel contributor |
+| SEO in the conversion funnel and long tail | *Product-Led SEO*, conversion funnel and long-tail search behavior |
+| Reporting and three levels of performance | *Product-Led SEO*, reporting and performance interpretation |
+| Buyer personas for keyword research | *Product-Led SEO*, SEO-specific buyer personas |
+| Six SEO persona steps | *Product-Led SEO*, persona workflow for search planning |
+
+## Key Concepts
+
+### SEO-Specific Persona
+
+**Definition**: A search-behavior persona that describes how a potential user searches, what they need, and what content will help them progress.
+
+Age, gender, job title, and generic brand personas are secondary unless they change search behavior. The useful persona fields are problem, intent, funnel stage, device, expected format, CTA, and cultural/language context.
+
+### Funnel Stage
+
+**Definition**: The user's distance from a conversion event.
+
+High-funnel users often need education and exploration. Mid-funnel users compare options. Low-funnel users need proof, pricing, product detail, availability, or contact paths.
+
+### Content Fit
+
+**Definition**: The match between user intent and the content or product experience served.
+
+Long-form content is useful only when the user expects depth. A bottom-funnel price or feature query may need a concise table, product page, quote flow, or CTA instead.
+
+### CTA Fit
+
+**Definition**: The next action appropriate to the user's stage.
+
+High-funnel CTAs might invite reading more, subscribing, downloading, or exploring a tool. Low-funnel CTAs might invite a demo, purchase, quote, trial, or contact.
+
+### Device And Locale Context
+
+**Definition**: The device, language, country, and cultural conditions that change what content format is useful.
+
+Do not assume mobile-first means short content for every case. Do not assume international users always need fully translated pages.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Search intent | What the user is trying to accomplish with the query |
+| Funnel stage | Awareness, exploration, comparison, decision, support, or retention |
+| Content depth | How much detail the user needs at this stage |
+| Follow-on action | The next useful engagement after landing |
+| Persona bucket | A practical group of users with similar search behavior |
+
+## Common Misconceptions
+
+- **Myth**: High search volume means priority.
+ **Reality**: Priority should follow customer need and business value.
+
+- **Myth**: Existing company personas are enough for SEO.
+ **Reality**: SEO needs search-behavior details that many personas omit.
+
+- **Myth**: More content depth is always better.
+ **Reality**: The right depth depends on funnel stage and user expectation.
+
+- **Myth**: Organic search should be judged only by last-click conversion.
+ **Reality**: Organic often assists earlier in the journey.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/rules.md
new file mode 100644
index 00000000..fe0d1af4
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/references/core/rules.md
@@ -0,0 +1,61 @@
+# SEO Persona Intent Mapping Rules
+
+Use these rules when mapping search users to SEO content, product pages, and CTAs.
+
+## Core Rules
+
+### 1. Build Personas Around Search Behavior
+
+Use only persona attributes that influence how someone searches or what they expect from the page.
+
+- Capture the user's problem, trigger, vocabulary, and likely query shape.
+- Skip demographic detail unless it changes intent or language.
+- Include current customers, potential customers, influencers, and support users.
+
+### 2. Map Intent Before Keywords
+
+Define the job behind the search before choosing phrases.
+
+- Ask what the user needs at this moment.
+- Distinguish learning, comparison, buying, troubleshooting, and brand navigation.
+- Use keywords to label demand, not to invent strategy.
+
+### 3. Match Content Depth To Funnel Stage
+
+Do not give every persona the same format.
+
+- High-funnel research can justify depth, examples, and education.
+- Mid-funnel comparison needs proof, differentiation, and decision support.
+- Low-funnel intent needs concise product, pricing, availability, quote, or contact paths.
+
+### 4. Match CTA To User Readiness
+
+The CTA should be a helpful next step, not the company's preferred conversion on every page.
+
+- High-funnel: read next, subscribe, save, compare, explore, download.
+- Mid-funnel: demo, calculator, comparison, webinar, sample, case study.
+- Low-funnel: buy, start trial, request quote, contact sales, book service.
+
+### 5. Account For Device And Locale
+
+Format and language decisions should follow user context.
+
+- Consider whether the task is likely desktop, mobile, or voice.
+- Consider country, currency, units, legal constraints, and language expectation.
+- Validate whether translation is needed before creating language-specific work.
+
+### 6. Prioritize By Business Outcome
+
+Traffic that cannot convert or assist is not a priority.
+
+- Link each persona row to a business goal.
+- Use engagement, CTA clicks, lead quality, revenue, or support reduction as value signals.
+- Treat rankings as secondary.
+
+## Red Flags
+
+- Persona rows differ only by demographic labels.
+- The same article format is recommended for every stage.
+- CTAs ignore funnel stage.
+- The map prioritizes volume without conversion logic.
+- Localization is recommended without user evidence.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/workflows/map-persona-intent.md b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/workflows/map-persona-intent.md
new file mode 100644
index 00000000..00e4c8e8
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-persona-intent-mapping/workflows/map-persona-intent.md
@@ -0,0 +1,77 @@
+# Map Persona Intent Workflow
+
+Use this workflow to create an SEO persona, intent, content, and CTA map.
+
+## When to Use
+
+- Planning SEO content or product pages.
+- Diagnosing traffic that does not convert.
+- Turning audience knowledge into keyword research.
+- Building content briefs from real user needs.
+
+## Prerequisites
+
+- Product or website description.
+- Known customer segments or raw customer notes.
+- Business goals and conversion events.
+- Existing query, analytics, or Search Console data if available.
+
+**Reference**: `references/core/knowledge.md`, `references/core/rules.md`
+
+## Workflow Steps
+
+### Step 1: Identify Search Users
+
+**Goal**: Define practical search-behavior segments.
+
+- [ ] List all potential users, buyers, influencers, and support users.
+- [ ] For each, state the problem or trigger that causes a search.
+- [ ] Remove persona details that do not affect search behavior.
+
+### Step 2: Map Intent And Funnel Stage
+
+**Goal**: Understand what each user needs now.
+
+- [ ] Classify each moment as awareness, research, comparison, decision, support, or retention.
+- [ ] Write likely query shapes in plain language.
+- [ ] Separate brand, non-brand, and support demand.
+
+### Step 3: Choose Content Or Product Experience
+
+**Goal**: Match the landing experience to intent.
+
+- [ ] Choose format: page, tool, directory, comparison, product page, support article, calculator, or guide.
+- [ ] Set depth: short answer, structured page, long-form, interactive, or transactional.
+- [ ] Note device and locale constraints.
+
+### Step 4: Match CTA And Metric
+
+**Goal**: Make the next step useful and measurable.
+
+- [ ] Choose a CTA that matches funnel readiness.
+- [ ] Select a success metric tied to business value.
+- [ ] Add a proxy metric if direct revenue attribution is not available.
+
+### Step 5: Prioritize
+
+**Goal**: Decide what to build first.
+
+- [ ] Score each row by user value, business value, confidence, and effort.
+- [ ] Prioritize rows where user intent and business outcome are both strong.
+- [ ] Flag rows that need customer research before build.
+
+## Quick Checklist
+
+```text
+[ ] Search users identified
+[ ] Intent and funnel stage mapped
+[ ] Content/product format selected
+[ ] CTA matched to readiness
+[ ] Device and locale noted
+[ ] Business metric assigned
+[ ] Priorities ranked
+```
+
+## Exit Criteria
+
+Task is complete when each priority row has a persona, intent, funnel stage, experience, CTA, metric, and research gap.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/SKILL.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/SKILL.md
new file mode 100644
index 00000000..95d5c07a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/SKILL.md
@@ -0,0 +1,46 @@
+---
+name: seo-roadmap-prioritization
+description: Prioritize SEO initiatives as product roadmap work with impact, effort, confidence, resourcing, executive pitch, cross-functional ownership, quarterly planning, and business KPI alignment. Use when building SEO roadmaps, scoring SEO work, requesting engineering/design/content resources, annual planning, executive buy-in, or turning SEO recommendations into product-ready asks.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: SEO Roadmap Prioritization
+ category: Marketing
+ tags: seo,roadmap,prioritization,product-management,planning
+---
+
+# SEO Roadmap Prioritization
+
+Use this skill to turn SEO ideas into product-style roadmap items that can compete for resources, survive planning, and ship through cross-functional teams.
+
+This skill is derived from Eli Schwartz's *Product-Led SEO* and uses transformed guidance with durable book-topic references. Do not copy book prose into user outputs.
+
+## Quick Start
+
+1. Load `guidelines.md` to choose the relevant reference.
+2. Use `workflows/prioritize-seo-roadmap.md` for roadmap work.
+3. Translate SEO asks into business language, not SEO jargon.
+4. Score initiatives by impact, effort, confidence, and strategic fit.
+5. Include owners, dependencies, resource asks, and measurement.
+
+## Default Output
+
+When asked for a roadmap or prioritization, return:
+
+1. **Roadmap table** - initiative, why, fix/build, impact, effort, confidence, owner, dependencies, timing.
+2. **Recommended sequence** - now, next, later.
+3. **Resource asks** - engineering, product, design, content, data, executive support.
+4. **Executive pitch** - business KPI framing and expected payoff.
+5. **Risks and tradeoffs** - what may be displaced or delayed.
+6. **Measurement plan** - leading indicators and business outcomes.
+
+## Contents
+
+| Need | Start Here |
+|------|------------|
+| Understand SEO as product roadmap work | `references/core/knowledge.md` |
+| Apply prioritization rules | `references/core/rules.md` |
+| See scoring examples | `references/core/examples.md` |
+| Build a roadmap | `workflows/prioritize-seo-roadmap.md` |
+| Route by task | `guidelines.md` |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/agents/openai.yaml
new file mode 100644
index 00000000..f0b366cb
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "SEO Roadmap Prioritization"
+ short_description: "Prioritize SEO roadmaps, resources, and executive planning."
+ default_prompt: "Prioritize these SEO initiatives into a roadmap."
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/guidelines.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/guidelines.md
new file mode 100644
index 00000000..5a3da6ec
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/guidelines.md
@@ -0,0 +1,44 @@
+# SEO Roadmap Prioritization Guidelines
+
+Load the minimum files needed for the task.
+
+## By Task
+
+| What you're doing | Load these files |
+|-------------------|------------------|
+| Prioritizing SEO initiatives | `references/core/rules.md`, `workflows/prioritize-seo-roadmap.md` |
+| Building a quarterly or annual SEO plan | `references/core/knowledge.md`, `workflows/prioritize-seo-roadmap.md` |
+| Preparing an executive pitch | `references/core/rules.md`, `references/core/examples.md` |
+| Turning audit findings into tickets | `references/core/examples.md` |
+| Requesting engineering/product resources | `references/core/knowledge.md`, `references/core/rules.md` |
+
+## By Problem
+
+| If you notice... | Load these files |
+|------------------|------------------|
+| SEO asks are vague or ignored | `references/core/rules.md`, `references/core/examples.md` |
+| The roadmap uses rankings instead of business value | `references/core/rules.md` |
+| The plan has no owners or dependencies | `workflows/prioritize-seo-roadmap.md` |
+| Annual planning needs a stronger pitch | `references/core/knowledge.md`, `references/core/examples.md` |
+| SEO is treated as a checklist rather than a product function | `references/core/knowledge.md` |
+
+## Decision Tree
+
+```text
+What does the user need?
+|
++-- Score existing items -> rules + workflow
++-- Create roadmap from scratch -> knowledge + workflow
++-- Pitch executives -> examples + rules
++-- Technical issue triage -> technical-seo-triage skill
++-- Strategic thesis -> product-led-seo-strategy skill
+```
+
+## File Index
+
+| File | Purpose |
+|------|---------|
+| `references/core/knowledge.md` | SEO at scale, product function, planning, teams, executive buy-in |
+| `references/core/rules.md` | Prioritization and pitch rules |
+| `references/core/examples.md` | Roadmap tables and pitch rewrites |
+| `workflows/prioritize-seo-roadmap.md` | Step-by-step prioritization workflow |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/examples.md
new file mode 100644
index 00000000..65853252
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/examples.md
@@ -0,0 +1,43 @@
+# SEO Roadmap Prioritization Examples
+
+Examples for turning SEO work into product-ready roadmap items.
+
+## Roadmap Table Template
+
+| Initiative | Why It Matters | Build/Fix | Impact | Effort | Confidence | Owner | Dependencies | Metric |
+|------------|----------------|-----------|--------|--------|------------|-------|--------------|--------|
+| Improve internal links for orphan pages | Valuable pages are not discovered or authority is weak | Add related/recent/discovery modules | 8 | 5 | 7 | Product/Eng | Crawl data, template work | Indexed pages, non-brand impressions |
+| Launch integration page templates | Users search for product pairs | Build scalable integration pages | 9 | 4 | 6 | SEO PM | Product data, content, engineering | Impressions, demo clicks |
+| Fix canonical mismatch | Google selects unintended URLs | Correct canonicals and internal links | 7 | 8 | 8 | Eng | GSC export, crawl | Canonical acceptance, clicks |
+
+Score effort so higher means easier if using the book-inspired additive model. If the team prefers RICE or ICE, adapt the scale but keep impact, effort, and confidence explicit.
+
+## Weak vs Strong Ask
+
+### Weak
+
+"Engineering needs to fix title tags, canonicals, and internal links for SEO."
+
+### Strong
+
+"Build a template update that improves discovery and CTR for 2,000 product pages. The expected business result is more non-brand impressions, more qualified clicks, and more trial starts from pages already close to indexation."
+
+## Executive Pitch Frame
+
+Use this structure:
+
+1. **Business outcome**: What KPI improves?
+2. **Opportunity**: What search/product demand is unmet?
+3. **Build**: What capability, page type, or technical change is needed?
+4. **Evidence**: What data supports the ask?
+5. **Resources**: Which teams and how much time?
+6. **Timeline**: When should leading indicators appear?
+7. **Risk**: What happens if this is not funded?
+
+## Now/Next/Later Example
+
+| Timing | Work | Why |
+|--------|------|-----|
+| Now | Fix blockers and ship low-effort/high-confidence template changes | Creates early wins and removes obvious friction |
+| Next | Build scalable product-led surfaces | Requires cross-functional planning but creates durable growth |
+| Later | Large migrations or deep architecture changes | High risk; wait for clearer business case or necessary trigger |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/knowledge.md
new file mode 100644
index 00000000..7dc6ca2a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/knowledge.md
@@ -0,0 +1,59 @@
+# SEO Roadmap Prioritization Knowledge
+
+Core concepts for turning SEO work into roadmap-ready product initiatives.
+
+## Source References
+
+| Topic | Durable Reference |
+|-------|-------------------|
+| SEO at scale and tradeoffs | *Product-Led SEO*, SEO at scale and organizational tradeoffs |
+| Prioritization roadmap, data, and people | *Product-Led SEO*, prioritization across roadmap, data, and people constraints |
+| Incremental wins | *Product-Led SEO*, incremental SEO improvements |
+| SEO as a product function | *Product-Led SEO*, treating SEO as product work |
+| Project management and scoring columns | *Product-Led SEO*, project management and SEO scoring models |
+| Quarterly and annual planning | *Product-Led SEO*, quarterly and annual SEO planning |
+| Multidisciplinary implementation | *Product-Led SEO*, cross-functional implementation |
+| Executive case and forecasting | *Product-Led SEO*, executive buy-in and forecasting |
+
+## Key Concepts
+
+### SEO At Scale
+
+**Definition**: SEO work in organizations or sites where changes require tradeoffs, approvals, engineering queues, QA, legal review, or multiple teams.
+
+Best practices do not change, but execution changes. The SEO lead must make the ask legible and valuable enough to compete with other roadmap work.
+
+### SEO As Product Function
+
+**Definition**: Treat SEO as a product with users, surfaces, roadmap, owners, dependencies, investment, and measurement.
+
+SEO can sit in marketing, but the work should be planned like product work when it requires engineering, design, content, data, or cross-functional delivery.
+
+### Incremental Wins
+
+**Definition**: Small scoped improvements that can ship inside existing processes and accumulate into larger gains.
+
+Large revamps often stall. Smaller, specific changes are easier to sell, implement, measure, and compound.
+
+### Roadmap-Ready Ask
+
+**Definition**: An SEO request written so product, engineering, and executives can understand the problem, proposed fix, impact, effort, confidence, owner, and timing.
+
+Weak asks sound like SEO chores. Strong asks sound like product or business opportunities.
+
+### Executive Pitch
+
+**Definition**: A resource request framed in the same KPIs and planning language the company uses for other teams.
+
+Use business impact, not SEO jargon. Ask for the product or capability to be built, not a pile of SEO tasks.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Impact | Expected business value or strategic upside |
+| Effort | Relative implementation difficulty and resource need |
+| Confidence | Strength of evidence behind impact and effort |
+| Owner | Person or function accountable for progress |
+| Dependency | Team, system, approval, or data needed to ship |
+| Leading indicator | Early metric such as indexation, impressions, query growth, or engagement |
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/rules.md
new file mode 100644
index 00000000..bcf43f4e
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/references/core/rules.md
@@ -0,0 +1,62 @@
+# SEO Roadmap Prioritization Rules
+
+Use these rules when scoring, sequencing, or pitching SEO work.
+
+## Core Rules
+
+### 1. Translate SEO Into Business Language
+
+Avoid asking for abstract SEO work when requesting resources.
+
+- State the customer, business problem, and expected outcome.
+- Use the same KPIs other teams use.
+- Replace "fix SEO issues" with "build X to unlock Y business result."
+
+### 2. Score Every Initiative
+
+Each roadmap item should include impact, effort, confidence, owner, dependency, and measurement.
+
+- Score impact on business value, not ranking improvement.
+- Score effort with the team that will do the work.
+- Score confidence based on evidence, not enthusiasm.
+
+### 3. Prefer Shippable Increments
+
+Break large SEO plans into small wins.
+
+- Avoid full-site revamps unless the business need justifies the risk.
+- Ship scoped template, page, link, metadata, or reporting improvements.
+- Use early wins to earn political capital.
+
+### 4. Plan Resources Up Front
+
+Product-led SEO fails when dependencies are discovered after approval.
+
+- Name engineering, design, content, analytics, product, support, legal, and executive needs.
+- Reserve those resources when the initiative is approved.
+- Include missing resources as blockers, not footnotes.
+
+### 5. Pitch Outcomes, Not Process
+
+Executives and roadmap owners fund outcomes.
+
+- Present the product, capability, or measurable business result.
+- Be transparent about lag and payback period.
+- Use proxies when direct attribution is hard.
+- Keep SEO jargon out of the pitch.
+
+### 6. Keep A Living Roadmap
+
+SEO roadmaps must track progress and preserve institutional memory.
+
+- Keep the request, rationale, fix, score, ticket, owner, shipped date, and notes in one place.
+- Re-score as evidence changes.
+- Use completed work and learnings in future planning cycles.
+
+## Red Flags
+
+- The roadmap has tasks but no business outcomes.
+- Effort is guessed without engineering/product input.
+- The pitch asks for "SEO fixes" instead of a product/business result.
+- The plan assumes resources will appear later.
+- The annual plan uses traffic percentage goals without revenue or business framing.
diff --git a/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/workflows/prioritize-seo-roadmap.md b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/workflows/prioritize-seo-roadmap.md
new file mode 100644
index 00000000..06c5515d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/seo-roadmap-prioritization/workflows/prioritize-seo-roadmap.md
@@ -0,0 +1,92 @@
+# Prioritize SEO Roadmap Workflow
+
+Use this workflow to turn SEO ideas, audit findings, or strategy into a roadmap.
+
+## When to Use
+
+- The user has a list of SEO initiatives and needs priorities.
+- The user needs a quarterly or annual SEO plan.
+- SEO work needs engineering, product, design, content, data, or executive resources.
+- The user needs to pitch SEO work in business language.
+
+## Prerequisites
+
+- List of initiatives or audit findings.
+- Business goals and available KPIs.
+- Known teams, owners, and planning cadence.
+- Evidence: Search Console, analytics, crawl data, customer data, competitor data, or strategic rationale.
+
+**Reference**: `references/core/knowledge.md`, `references/core/rules.md`
+
+## Workflow Steps
+
+### Step 1: Normalize The Initiatives
+
+**Goal**: Make every ask clear enough to evaluate.
+
+- [ ] Rewrite each initiative as a build/fix with a specific outcome.
+- [ ] Add the affected page type, template, product surface, or process.
+- [ ] Remove vague entries such as "improve SEO" or "optimize content."
+
+### Step 2: Add Business Rationale
+
+**Goal**: Connect each item to value.
+
+- [ ] Identify the customer or user problem.
+- [ ] Identify the business KPI or proxy metric.
+- [ ] Add available evidence.
+- [ ] State the cost of doing nothing when relevant.
+
+### Step 3: Score Priority
+
+**Goal**: Rank work consistently.
+
+- [ ] Score impact.
+- [ ] Score effort with input from delivery owners.
+- [ ] Score confidence.
+- [ ] Note strategic fit, risk, and time-to-signal.
+- [ ] Calculate or manually assign rank.
+
+### Step 4: Map Owners And Dependencies
+
+**Goal**: Make the roadmap shippable.
+
+- [ ] Assign owner and contributors.
+- [ ] Note engineering, product, design, content, data, legal, support, or executive dependencies.
+- [ ] Link ticket or create ticket-ready acceptance criteria.
+- [ ] Identify blockers.
+
+### Step 5: Sequence Now, Next, Later
+
+**Goal**: Create an executable roadmap.
+
+- [ ] Put high-impact/high-confidence/low-effort work in "now."
+- [ ] Put strategic cross-functional builds in "next" with planning detail.
+- [ ] Put high-risk or under-evidenced work in "later" or validation.
+- [ ] Define what evidence would move later work forward.
+
+### Step 6: Prepare The Pitch
+
+**Goal**: Help the roadmap win resources.
+
+- [ ] Use company KPI language.
+- [ ] Ask for the product/capability, not SEO chores.
+- [ ] Include resource needs up front.
+- [ ] Explain payback timing and leading indicators.
+- [ ] Keep jargon out of the executive version.
+
+## Quick Checklist
+
+```text
+[ ] Initiatives normalized
+[ ] Business rationale added
+[ ] Impact/effort/confidence scored
+[ ] Owners and dependencies mapped
+[ ] Now/next/later sequence created
+[ ] Executive pitch written
+[ ] Metrics and leading indicators defined
+```
+
+## Exit Criteria
+
+Task is complete when the roadmap can be handed to product, engineering, marketing, or executives without additional explanation of what is being requested, why it matters, who owns it, and how success will be measured.
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/SKILL.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/SKILL.md
new file mode 100644
index 00000000..1828c542
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/SKILL.md
@@ -0,0 +1,46 @@
+---
+name: technical-seo-triage
+description: Diagnose technical SEO issues using discovery, crawling, indexing, ranking, Google Search Console, internal links, crawl budget, canonicals, duplicate content, redirects, and migration risk. Use when traffic drops, pages are not indexed, Search Console shows errors, canonicals differ, migrations are planned, or a technical SEO audit is needed.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Technical SEO Triage
+ category: Marketing
+ tags: seo,technical-seo,search-console,indexing,crawling
+---
+
+# Technical SEO Triage
+
+Use this skill to diagnose technical SEO problems by moving from symptoms to search-system stages: discovery, crawling, indexing, ranking, and user outcomes.
+
+This skill is derived from Eli Schwartz's *Product-Led SEO* and uses transformed guidance with durable book-topic references. Do not copy book prose into user outputs.
+
+## Quick Start
+
+1. Load `guidelines.md` to choose relevant references.
+2. Use `workflows/triage-seo-issue.md` for traffic drops, indexing issues, canonical issues, migration risk, or crawl problems.
+3. Prefer Google Search Console as the primary search visibility source.
+4. Segment by URL, query, device, country, brand/non-brand, and date before proposing fixes.
+5. Separate technical blockers from content, UX, and business-fit issues.
+
+## Default Output
+
+When asked to triage an issue, return:
+
+1. **Symptom summary** - what changed and where.
+2. **Likely search stage** - discovery, crawl, index, rank, click, or conversion.
+3. **Evidence to inspect** - GSC reports, logs, crawl data, redirects, canonicals, robots, schema, templates.
+4. **Priority fixes** - ordered by risk and likely impact.
+5. **Validation plan** - how to verify recovery or improvement.
+6. **Cautions** - migration, redirect, duplicate, or crawl-budget risks.
+
+## Contents
+
+| Need | Start Here |
+|------|------------|
+| Understand technical SEO systems | `references/core/knowledge.md` |
+| Apply triage rules | `references/core/rules.md` |
+| See diagnosis examples | `references/core/examples.md` |
+| Triage a problem | `workflows/triage-seo-issue.md` |
+| Route by task | `guidelines.md` |
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/agents/openai.yaml b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/agents/openai.yaml
new file mode 100644
index 00000000..fd3ba2f3
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+ display_name: "Technical SEO Triage"
+ short_description: "Diagnose technical SEO indexing, crawling, and migration issues."
+ default_prompt: "Triage this technical SEO issue and recommend fixes."
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/guidelines.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/guidelines.md
new file mode 100644
index 00000000..1e4f861a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/guidelines.md
@@ -0,0 +1,45 @@
+# Technical SEO Triage Guidelines
+
+Load the minimum files needed for the task.
+
+## By Task
+
+| What you're doing | Load these files |
+|-------------------|------------------|
+| Diagnosing a traffic drop | `references/core/knowledge.md`, `references/core/rules.md`, `workflows/triage-seo-issue.md` |
+| Investigating indexing/canonical issues | `references/core/rules.md`, `references/core/examples.md` |
+| Planning a migration or URL change | `references/core/rules.md`, `workflows/triage-seo-issue.md` |
+| Reviewing internal linking or crawl budget | `references/core/knowledge.md`, `references/core/examples.md` |
+| Explaining technical SEO to non-technical stakeholders | `references/core/knowledge.md` |
+
+## By Problem
+
+| If you notice... | Load these files |
+|------------------|------------------|
+| Pages discovered but not indexed | `references/core/knowledge.md`, `references/core/rules.md` |
+| Traffic drop after an update | `workflows/triage-seo-issue.md` |
+| Canonical selected by Google differs from declared canonical | `references/core/rules.md` |
+| Large site has orphaned or weakly linked pages | `references/core/knowledge.md`, `references/core/examples.md` |
+| Migration would change many URLs | `references/core/rules.md` |
+
+## Decision Tree
+
+```text
+What is the symptom?
+|
++-- Not found by Google -> discovery/internal links/sitemaps
++-- Crawled less than expected -> crawl budget, low-value URLs, internal links
++-- Crawled but not indexed -> duplicate, thin, canonical, quality, robots
++-- Indexed but no clicks -> relevance, snippets, CTR, intent mismatch
++-- Drop after migration -> redirects, URL map, canonicals, internal links
++-- Drop after algorithm update -> segment URL/query winners and losers in GSC
+```
+
+## File Index
+
+| File | Purpose |
+|------|---------|
+| `references/core/knowledge.md` | Search stages, GSC, internal links, crawl budget, duplicate, migrations |
+| `references/core/rules.md` | Triage rules and cautions |
+| `references/core/examples.md` | Diagnosis examples and check tables |
+| `workflows/triage-seo-issue.md` | Step-by-step technical triage workflow |
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/examples.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/examples.md
new file mode 100644
index 00000000..f9f4ea9e
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/examples.md
@@ -0,0 +1,44 @@
+# Technical SEO Triage Examples
+
+Examples for classifying and diagnosing technical SEO issues.
+
+## Symptom Classification
+
+| Symptom | Likely Stage | First Checks |
+|---------|--------------|--------------|
+| Page not in Google | Discovery or indexing | Internal links, sitemap, robots, URL inspection, canonical |
+| Crawled but excluded | Indexing | Duplicate, thin content, canonical, quality, noindex |
+| Impressions dropped, clicks stable | SERP display or reporting shift | GSC comparison, query/page segmentation |
+| Clicks dropped, impressions stable | CTR or snippet issue | Title, meta, SERP features, intent mismatch |
+| All old URLs lose traffic after relaunch | Migration | Redirect map, redirect status, canonicals, internal links |
+| Important pages rarely crawled | Crawl budget/link graph | Internal links, low-value URL traps, sitemap, logs |
+
+## Internal Linking Patterns
+
+| Pattern | Issue | Better Approach |
+|---------|-------|-----------------|
+| Hub-only linking | Crawlers repeatedly pass through the same hubs | Add multiple paths between related and important pages |
+| Popular-to-popular modules | New or niche pages remain hidden | Include recent, exploratory, and random/discovery modules |
+| No HTML sitemap on large site | Deep pages may be hard to discover | Add a useful site directory or sitemap linked from stable pages |
+| Dead-end pages | External authority does not flow onward | Add contextual links to related and priority pages |
+
+## Migration Checklist Example
+
+| Area | Check |
+|------|-------|
+| URL map | Every old URL has a mapped destination or intentional retirement |
+| Redirect type | Permanent moves use 301 redirects |
+| Pre-launch crawl | Old URLs resolve to expected new URLs |
+| Canonicals | New URLs self-canonicalize or point to the intended canonical |
+| Internal links | Navigation and content links point to new URLs |
+| Monitoring | GSC, logs, and analytics are reviewed after launch |
+
+## Traffic Drop Interpretation
+
+### Weak Diagnosis
+
+"Google updated the algorithm and punished the site."
+
+### Strong Diagnosis
+
+"The drop is concentrated in non-brand informational URLs on mobile in the US. Impressions fell on some query groups while clicks stayed stable on others. We should inspect affected URLs in GSC, compare canonical/index status, and review recent template/content changes before assuming an algorithm-wide issue."
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/knowledge.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/knowledge.md
new file mode 100644
index 00000000..4bbc4f9d
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/knowledge.md
@@ -0,0 +1,63 @@
+# Technical SEO Triage Knowledge
+
+Core concepts for diagnosing technical SEO issues.
+
+## Source References
+
+| Topic | Durable Reference |
+|-------|-------------------|
+| Discovery, crawling, indexing, ranking | *Product-Led SEO*, how search engines discover, crawl, index, and rank pages |
+| Algorithm updates and traffic drops | *Product-Led SEO*, algorithm updates and diagnosing traffic changes |
+| Internal linking and link graph | *Product-Led SEO*, internal linking and site architecture |
+| Crawl budget | *Product-Led SEO*, crawl budget and crawler attention |
+| Google Search Console | *Product-Led SEO*, Google Search Console diagnostics |
+| Duplicate content | *Product-Led SEO*, duplicate content and canonicalization |
+| Site updates and migrations | *Product-Led SEO*, site updates, redirects, and migration risk |
+
+## Key Concepts
+
+### Search Stages
+
+**Discovery**: Google learns a URL exists from links, sitemaps, submissions, analytics, browser signals, or other sources.
+
+**Crawling**: Google decides whether to spend resources fetching the URL.
+
+**Indexing**: Google decides whether and how to store the page, including duplicate and canonical decisions.
+
+**Ranking**: Google matches indexed pages to queries based on intent, relevance, quality, usability, and context.
+
+Do not diagnose all SEO issues as ranking issues. First identify the stage where the failure happens.
+
+### Google Search Console As Source Of Truth
+
+GSC is the primary source for how Google sees visibility, queries, pages, indexing, canonical choices, and search performance.
+
+Third-party tools are useful, but they estimate. Use them to explore, not to override GSC.
+
+### Internal Link Graph
+
+Internal links distribute authority and help crawlers discover important pages. Large sites often create orphaned or near-orphaned pages when related-content modules only reinforce already popular pages.
+
+### Crawl Budget
+
+Crawl budget is best treated as scarce crawler attention. Low-value URLs, duplicate pages, blocked paths, and weak internal links can waste attention before crawlers reach valuable pages.
+
+### Duplicate Content
+
+Duplicate content is usually a canonicalization and quality-selection issue, not automatically a penalty. The risk rises when duplication exists to manipulate search or makes the site look low quality.
+
+### Migrations And Redirects
+
+URL changes create risk because search engines must accept the new URL as equivalent to the old one. Permanent redirects, complete URL mapping, pre-launch crawls, and long-term redirect maintenance are core safeguards.
+
+## Terminology
+
+| Term | Definition |
+|------|------------|
+| Canonical | The primary URL Google or the site selects for duplicate/similar content |
+| Orphan page | A page with few or no internal links pointing to it |
+| Crawl demand | Google's reason to revisit and refresh URLs |
+| 301 redirect | Permanent redirect used for moved URLs |
+| 302 redirect | Temporary redirect; usually not appropriate for permanent migrations |
+| Brand traffic | Queries that include the brand or depend on brand awareness |
+| Non-brand traffic | Queries from users who may not know the brand |
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/rules.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/rules.md
new file mode 100644
index 00000000..42f1802f
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/references/core/rules.md
@@ -0,0 +1,74 @@
+# Technical SEO Triage Rules
+
+Use these rules when diagnosing technical SEO issues.
+
+## Core Rules
+
+### 1. Diagnose The Search Stage First
+
+Classify the issue before recommending fixes.
+
+- Discovery issue: Google does not know the URL exists.
+- Crawl issue: Google knows the URL but does not fetch enough.
+- Index issue: Google crawls but excludes, canonicalizes, or distrusts the page.
+- Ranking/click issue: Google indexes the page but users do not see or click it.
+- Conversion issue: search traffic arrives but does not produce value.
+
+### 2. Segment Before Explaining
+
+Do not explain a traffic drop from aggregate charts alone.
+
+- Segment by URL, query, country, device, date, brand/non-brand, and page type.
+- Identify winners as well as losers after algorithm updates.
+- Compare impressions, clicks, CTR, and conversions separately.
+
+### 3. Treat GSC As The Primary Search Evidence
+
+Use Google Search Console first for search visibility and indexation.
+
+- Inspect URL-level data when a specific page is involved.
+- Check whether declared canonicals match Google's selected canonicals.
+- Treat many GSC errors as informational, but prioritize robots, crawl, schema, and indexation blockers.
+
+### 4. Fix Internal Link Graphs Before Chasing Links
+
+Large sites often have discovery and authority-flow problems.
+
+- Ensure important pages are reachable from multiple paths.
+- Avoid related-content modules that only link popular pages to popular pages.
+- Add HTML sitemaps or site directories when they help discovery.
+- Mix related, recent, important, and exploratory links where appropriate.
+
+### 5. Reduce Low-Value Crawl Waste
+
+Do not force crawlers through endless low-value URLs.
+
+- Block, noindex, canonicalize, consolidate, or remove pages that waste crawl attention.
+- Protect valuable pages from being buried behind weak architecture.
+- Keep user value as the deciding principle.
+
+### 6. Do Not Panic About Duplicate Content
+
+Duplicate content is not automatically a penalty.
+
+- Ask whether the duplicate content helps users.
+- Use canonicals when a preferred URL exists.
+- Avoid manipulative doorway pages or large-scale low-quality duplication.
+
+### 7. Treat Migrations As High-Risk Projects
+
+URL changes require deliberate planning.
+
+- Build a complete old-to-new URL map.
+- Use 301 redirects for permanent moves.
+- Crawl old URLs before launch to verify redirects.
+- Maintain redirects long term.
+- Consider staged migrations when business risk is high.
+
+## Red Flags
+
+- A migration has no URL map.
+- A traffic drop is explained without URL/query segmentation.
+- Robots, noindex, canonicals, or redirects are changed without validation.
+- Large sites rely only on homepage/category links for discovery.
+- The fix optimizes crawlers while making pages worse for users.
diff --git a/plugins/LVTD-LLC/skills/skills/technical-seo-triage/workflows/triage-seo-issue.md b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/workflows/triage-seo-issue.md
new file mode 100644
index 00000000..30dde7c4
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/technical-seo-triage/workflows/triage-seo-issue.md
@@ -0,0 +1,86 @@
+# Triage SEO Issue Workflow
+
+Use this workflow to diagnose traffic drops, indexing issues, technical SEO errors, and migration risk.
+
+## When to Use
+
+- Organic impressions, clicks, or conversions changed unexpectedly.
+- Important URLs are not indexed or canonicalized as expected.
+- Google Search Console reports errors.
+- A migration, redesign, URL change, or platform change is planned.
+- A technical SEO audit needs prioritization.
+
+## Prerequisites
+
+- URL(s), date range, and symptom.
+- GSC access or exported data.
+- Analytics, logs, crawl data, or CMS change history if available.
+- Knowledge of recent releases, migrations, content changes, or template changes.
+
+**Reference**: `references/core/knowledge.md`, `references/core/rules.md`
+
+## Workflow Steps
+
+### Step 1: Define The Symptom
+
+**Goal**: Make the problem specific.
+
+- [ ] Record what changed: impressions, clicks, CTR, average position, index status, conversions, or revenue.
+- [ ] Record when it changed.
+- [ ] Identify affected URL patterns, page types, countries, devices, and query groups.
+- [ ] Separate brand and non-brand traffic.
+
+### Step 2: Locate The Search Stage
+
+**Goal**: Classify where the failure happens.
+
+- [ ] Discovery: Is the URL linked, in sitemap, and known to Google?
+- [ ] Crawling: Is Google fetching the URL?
+- [ ] Indexing: Is it indexed, excluded, duplicate, or canonicalized elsewhere?
+- [ ] Ranking/clicking: Is it indexed but losing impressions or clicks?
+- [ ] Conversion: Is traffic present but business value missing?
+
+### Step 3: Inspect Evidence
+
+**Goal**: Use primary data before proposing fixes.
+
+- [ ] Use GSC URL inspection and performance comparison.
+- [ ] Check canonical selected by Google versus declared canonical.
+- [ ] Check robots, noindex, redirects, status codes, schema, and load errors.
+- [ ] Crawl affected URL sets.
+- [ ] Review release history and content/template changes.
+
+### Step 4: Prioritize Fixes
+
+**Goal**: Order work by risk and impact.
+
+- [ ] Fix blockers first: robots, noindex, broken redirects, status errors, broken canonicals.
+- [ ] Fix architecture issues: orphan pages, weak internal links, low-value URL traps.
+- [ ] Fix content/UX issues only after technical blockers are understood.
+- [ ] For migrations, prefer staged changes when risk is high.
+
+### Step 5: Validate Recovery
+
+**Goal**: Confirm the fix worked.
+
+- [ ] Re-crawl affected URLs.
+- [ ] Request reinspection or resubmission where appropriate.
+- [ ] Monitor impressions first, then clicks, then conversions.
+- [ ] Compare against unaffected controls when possible.
+- [ ] Document the root cause and prevention step.
+
+## Quick Checklist
+
+```text
+[ ] Symptom narrowed
+[ ] Search stage identified
+[ ] GSC inspected
+[ ] Canonicals/robots/status/redirects checked
+[ ] Internal links/crawl paths reviewed
+[ ] Fixes prioritized
+[ ] Validation plan defined
+```
+
+## Exit Criteria
+
+Task is complete when the issue has a classified search stage, evidence-backed root cause hypothesis, prioritized fixes, and a measurable validation plan.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-bullseye/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-bullseye/SKILL.md
new file mode 100644
index 00000000..2105ccf9
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-bullseye/SKILL.md
@@ -0,0 +1,159 @@
+---
+name: traction-bullseye
+description: Apply the Bullseye framework from Traction to brainstorm, rank, test, and focus startup traction channels. Use when choosing growth channels, overcoming channel bias, prioritizing marketing experiments, or deciding which acquisition channel deserves focused effort.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Bullseye
+ category: Marketing
+ tags: traction,growth,marketing,startups,prioritization
+---
+
+# Traction Bullseye
+
+Use this skill to turn vague growth ideas into a ranked set of traction channel
+tests and one focused core channel. It is based on the Bullseye framework from
+Traction by Gabriel Weinberg and Justin Mares.
+
+## Source Traceability
+
+Primary source: Traction, chapters 1, 3, and 5.
+
+- Chapter 1 introduces the 19 traction channels and warns against dismissing
+ unfamiliar channels too early. Authoring notes: converted lines 238-393.
+- Chapter 3 defines Bullseye: outer ring, middle ring, inner ring, and focus on
+ one core channel. Authoring notes: converted lines 555-674.
+- Chapter 5 covers channel bias and the 19-channel review. Authoring notes:
+ converted lines 787-902.
+
+See [source-map.md](references/source-map.md) for the channel list and line
+references used while authoring this skill.
+
+## Workflow
+
+### 1. Define The Current Traction Goal
+
+Start with the measurable outcome the company needs next. A channel cannot be
+ranked well until the goal is explicit.
+
+Capture:
+
+- Stage: phase I, phase II, or phase III.
+- Target metric: users, revenue, customers, usage, qualified leads, market
+ share, or another growth metric.
+- Deadline.
+- Required volume.
+- Constraint: budget, team capacity, geography, product readiness, sales cycle,
+ or regulatory constraint.
+
+If the user has no goal, ask for one or propose a provisional goal and label it
+as an assumption.
+
+### 2. Fill The Outer Ring
+
+Generate at least one plausible strategy for each traction channel before
+ranking anything. This counters default bias toward familiar channels.
+
+Use this full channel list:
+
+1. Targeting blogs
+2. Publicity
+3. Unconventional PR
+4. Search engine marketing
+5. Social and display ads
+6. Offline ads
+7. Search engine optimization
+8. Content marketing
+9. Email marketing
+10. Viral marketing
+11. Engineering as marketing
+12. Business development
+13. Sales
+14. Affiliate programs
+15. Existing platforms
+16. Trade shows
+17. Offline events
+18. Speaking engagements
+19. Community building
+
+For each channel, write:
+
+- One specific strategy.
+- Why it might work for this product.
+- What evidence would make it more promising.
+- What assumption would kill it.
+
+Do not discard a channel because it feels unfashionable, manual, or outside the
+team's comfort zone. Mark concerns, then continue.
+
+### 3. Promote The Middle Ring
+
+Choose roughly three promising channels for cheap tests. Prefer channels that:
+
+- Could plausibly move the traction goal.
+- Have reachable customers now.
+- Can be tested cheaply within the current stage.
+- Produce interpretable data quickly.
+- Are underused by competitors or unusually well-matched to the product.
+
+When the ranking is uncertain, use the stronger testability criterion: pick the
+channel where a small test would teach the most.
+
+### 4. Define Tests
+
+For each middle-ring channel, design one cheap test that answers:
+
+1. How much could it cost to acquire a customer?
+2. How many relevant customers may be reachable?
+3. Are these the right customers right now?
+
+Keep phase I tests small. The point is signal, not scale.
+
+### 5. Pick Or Defer The Inner Ring
+
+Recommend an inner-ring core channel only if one test result is meaningfully
+stronger than the others. If no channel has enough evidence, recommend another
+Bullseye pass using what was learned.
+
+Once a core channel is chosen, focus. Other channels may support it, but should
+not become parallel growth strategies unless the core channel stops moving the
+needle.
+
+## Output Format
+
+Use this structure:
+
+```markdown
+# Bullseye Recommendation
+
+## Traction Goal
+- Goal:
+- Deadline:
+- Stage:
+- Constraints:
+
+## Outer Ring
+| Channel | Strategy | Why It Could Work | Evidence Needed | Key Assumption |
+|---------|----------|-------------------|-----------------|----------------|
+
+## Middle Ring
+| Rank | Channel | Test | Budget/Time | Success Signal |
+|------|---------|------|-------------|----------------|
+
+## Inner Ring Decision
+[Choose core channel, defer decision, or repeat Bullseye.]
+
+## Next Actions
+1. [Action]
+2. [Action]
+3. [Action]
+```
+
+## Quality Bar
+
+- Do not recommend a channel just because it is popular.
+- Do not skip channels without naming the bias or constraint.
+- Do not optimize tactics before choosing a promising strategy.
+- Use numbers whenever possible, even if they are explicit estimates.
+- Preserve losing channel ideas for later Bullseye rounds.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-bullseye/references/source-map.md b/plugins/LVTD-LLC/skills/skills/traction-bullseye/references/source-map.md
new file mode 100644
index 00000000..823c2194
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-bullseye/references/source-map.md
@@ -0,0 +1,43 @@
+# Source Map
+
+This skill paraphrases operational ideas from Traction by Gabriel Weinberg and
+Justin Mares. The authoring process used a local text conversion for line-based
+traceability; no book text or extraction artifact is committed in this skill.
+
+## Relevant Source Sections
+
+| Topic | Book Section | Authoring Lines |
+|-------|--------------|-----------------|
+| Traction definition and channel overview | Chapter 1, Traction Channels | 238-393 |
+| Bullseye framing | Chapter 3, Bullseye | 555-572 |
+| Bullseye outer ring | Chapter 3, The Outer Ring: What's Possible | 573-584 |
+| Bullseye middle ring | Chapter 3, The Middle Ring: What's Probable | 585-606 |
+| Bullseye inner ring | Chapter 3, The Inner Ring: What's Working | 607-628 |
+| Why Bullseye exists | Chapter 3, Why Use Bullseye? | 629-650 |
+| Bullseye and Lean comparison | Chapter 3, Comparison to Lean | 651-664 |
+| Chapter 3 target checklist | Chapter 3, Targets | 665-674 |
+| Traction goal and Critical Path context | Chapter 5, Defining Your Traction Goal / Critical Path | 787-840 |
+| Bias against channels | Chapter 5, Overcoming Your Traction Biases | 841-892 |
+| Chapter 5 target checklist | Chapter 5, Targets | 893-902 |
+
+## Nineteen Traction Channels
+
+1. Targeting blogs
+2. Publicity
+3. Unconventional PR
+4. Search engine marketing
+5. Social and display ads
+6. Offline ads
+7. Search engine optimization
+8. Content marketing
+9. Email marketing
+10. Viral marketing
+11. Engineering as marketing
+12. Business development
+13. Sales
+14. Affiliate programs
+15. Existing platforms
+16. Trade shows
+17. Offline events
+18. Speaking engagements
+19. Community building
diff --git a/plugins/LVTD-LLC/skills/skills/traction-channel-research/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-channel-research/SKILL.md
new file mode 100644
index 00000000..9c9c4aea
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-channel-research/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: traction-channel-research
+description: Research and shortlist startup traction channels before running Bullseye tests. Use when comparing acquisition channels, studying how similar companies grew, finding underused distribution strategies, or preparing the outer ring for a Traction-style growth process.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Channel Research
+ category: Marketing
+ tags: traction,growth,research,marketing,startups
+---
+
+# Traction Channel Research
+
+Use this skill before `traction-bullseye` when the agent needs evidence about
+which channels might work. The job is to replace founder guesses with grounded
+channel ideas.
+
+## Source Traceability
+
+Primary source: Traction, chapters 1, 3, and 5. Authoring notes: converted
+lines 238-393, 555-674, and 787-902. The canonical channel list also appears
+in `../traction-bullseye/references/source-map.md`.
+
+## Research Workflow
+
+1. Define the product, target customer, business model, ACV or price point, and
+ current growth stage.
+2. List all 19 channels, even if some look unlikely:
+ targeting blogs, publicity, unconventional PR, search engine marketing,
+ social and display ads, offline ads, search engine optimization, content
+ marketing, email marketing, viral marketing, engineering as marketing,
+ business development, sales, affiliate programs, existing platforms, trade
+ shows, offline events, speaking engagements, and community building.
+3. For each channel, research comparable companies, adjacent markets, failed
+ examples, and underused tactics.
+4. Separate channel from strategy. "SEO" is a channel; "comparison pages for
+ high-intent alternatives" is a strategy.
+5. Estimate reach, cost, speed, confidence, and customer fit.
+6. Shortlist the top three to five strategies for Bullseye middle-ring tests.
+
+## Evidence To Look For
+
+- Founder interviews, teardown posts, podcasts, and launch retrospectives.
+- Competitor traffic sources, ad libraries, backlink patterns, and content
+ footprints.
+- Marketplaces, communities, events, newsletters, podcasts, and niche platforms
+ where the customer already gathers.
+- Signs of saturation: crowded ad auctions, copied content, high affiliate
+ competition, or low response rates.
+- Signs of underuse: unfashionable offline channels, narrow communities,
+ ignored partners, or new platforms.
+
+## Output Format
+
+```markdown
+# Traction Channel Research
+
+## Context
+- Product:
+- Customer:
+- Stage:
+- Traction goal:
+
+## Channel Scan
+| Channel | Strategy Idea | Evidence | Reach | Cost | Speed | Fit | Confidence |
+|---------|---------------|----------|-------|------|-------|-----|------------|
+
+## Shortlist
+1. [Channel + strategy] - [why test this]
+2. [Channel + strategy] - [why test this]
+3. [Channel + strategy] - [why test this]
+4. [Optional channel + strategy] - [why test this]
+5. [Optional channel + strategy] - [why test this]
+
+## Bias Check
+- Channels the team may be overvaluing:
+- Channels the team may be ignoring:
+
+## Recommended Next Tests
+[Hand off to traction-test-planner.]
+```
+
+## Quality Bar
+
+- Prefer specific strategies over broad channel labels.
+- Include at least one uncomfortable or underused channel.
+- Distinguish evidence from guesses.
+- Flag channels that cannot plausibly move the user's current traction goal.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-critical-path/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-critical-path/SKILL.md
new file mode 100644
index 00000000..1c20bd9c
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-critical-path/SKILL.md
@@ -0,0 +1,129 @@
+---
+name: traction-critical-path
+description: Set traction goals and identify the Critical Path from Traction so teams focus only on milestones needed for growth. Use when a startup has too many priorities, needs growth goals, is debating product versus marketing work, or wants to decide what not to do.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Critical Path
+ category: Marketing
+ tags: traction,growth,strategy,startups,prioritization
+---
+
+# Traction Critical Path
+
+Use this skill to convert an ambiguous growth objective into a measurable
+traction goal, required milestones, and a disciplined "not now" list.
+
+## Source Traceability
+
+Primary source: Traction, chapters 2 and 5.
+
+- Chapter 2 covers the 50 percent rule, moving the needle, growth phases, and
+ bright spots. Authoring notes: converted lines 394-554.
+- Chapter 5 defines traction goals, Critical Path milestones, reassessment, and
+ channel bias. Authoring notes: converted lines 787-902.
+
+## Workflow
+
+### 1. Identify The Growth Stage
+
+Classify the current stage:
+
+| Stage | Main Question | Typical Goal |
+|-------|---------------|--------------|
+| Phase I | Can the product get real traction? | First engaged customers or proof of demand |
+| Phase II | Can this become sustainable? | Enough customers or revenue to approach sustainability |
+| Phase III | Can this scale profitably? | Larger growth, market position, or profit expansion |
+
+If the product is early, keep tests small and feedback-rich. If it is later,
+insist on goals large enough to move the business.
+
+### 2. Define The Traction Goal
+
+The traction goal should be quantitative, time-bound, and meaningful enough to
+change the company's situation.
+
+Good goals include:
+
+- Reach 1,000 paying customers by a date.
+- Add 100 qualified trials per week.
+- Hit a break-even revenue number.
+- Reach a market-share threshold that changes partnership or investor leverage.
+
+Weak goals include:
+
+- Get more awareness.
+- Do marketing.
+- Improve engagement without defining the metric.
+
+### 3. Work Backward Into Necessary Milestones
+
+List milestones that are absolutely necessary to hit the goal. Include product,
+distribution, hiring, analytics, partnership, or operational milestones only if
+they are required.
+
+For each candidate milestone, ask:
+
+- If this does not happen, can we still hit the traction goal?
+- Is this a prerequisite or just attractive?
+- What evidence supports this being necessary?
+- What would make us remove or replace it?
+
+### 4. Cut Off-Path Work
+
+Create an explicit off-path list. This matters because founders often spend
+scarce time on useful work that is not necessary for the current traction goal.
+
+Off-path work can include:
+
+- Feature requests that do not unlock the next growth stage.
+- Marketing activities that cannot move the needle.
+- Partnerships, events, or content that produce activity without traction.
+- Infrastructure polish that does not affect the current bottleneck.
+
+### 5. Reassess After Every Milestone
+
+The Critical Path changes as evidence changes. After each milestone, update:
+
+- Goal confidence.
+- Bottleneck.
+- Milestone order.
+- Off-path list.
+- Next test or build decision.
+
+## Output Format
+
+```markdown
+# Critical Path Plan
+
+## Traction Goal
+- Metric:
+- Target:
+- Deadline:
+- Why it matters:
+
+## Stage
+[Phase I, II, or III, with reasoning.]
+
+## Critical Path
+| Order | Milestone | Why Required | Evidence Needed | Owner/Deadline |
+|-------|-----------|--------------|-----------------|----------------|
+
+## Off-Path List
+| Activity | Why It Is Off Path | Revisit Trigger |
+|----------|--------------------|-----------------|
+
+## Reassessment Cadence
+- Review after:
+- Metrics to inspect:
+- Decision rules:
+```
+
+## Quality Bar
+
+- Do not accept vague growth goals.
+- Do not include milestones merely because they are valuable.
+- Do not let product work crowd out traction work by default.
+- Name bright spots when growth is weak but some users are highly engaged.
+- Recommend a pivot only after checking engagement evidence and timing risk.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-email-marketing/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-email-marketing/SKILL.md
new file mode 100644
index 00000000..05f0b407
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-email-marketing/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: traction-email-marketing
+description: Design email marketing traction tests from Traction for acquisition, engagement, retention, revenue, and referrals. Use when planning email courses, newsletter sponsorships, lifecycle sequences, retention emails, or email-driven growth experiments.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Email Marketing
+ category: Marketing
+ tags: traction,email-marketing,lifecycle,retention,marketing
+---
+
+# Traction Email Marketing
+
+Use this skill when email can help find, activate, retain, monetize, or refer
+customers. The output should be a measurable email experiment, not just copy.
+
+## Source Traceability
+
+Primary source: Traction, chapter 14 and the appendix. Authoring notes:
+converted lines 1863-1996 and 3347-3348.
+
+## Email Jobs
+
+- Find new customers through sponsorships, newsletter placements, or lead
+ magnets.
+- Engage prospects with a course, onboarding sequence, or useful series.
+- Retain customers through lifecycle nudges and value reminders.
+- Increase revenue through timely upsell or conversion prompts.
+- Drive referrals through shareable offers or customer prompts.
+
+## Workflow
+
+1. Choose one email job.
+2. Define the list source or audience segment.
+3. Write the promise for the sequence or sponsorship.
+4. Map the conversion path.
+5. Set deliverability, tracking, and unsubscribe safeguards.
+6. Define success by qualified action, not open rate alone.
+
+## Output Format
+
+```markdown
+# Email Traction Test
+
+## Job
+[Acquisition, engagement, retention, revenue, or referral.]
+
+## Audience
+- Source/segment:
+- Why they care:
+
+## Sequence Or Placement
+| Email | Purpose | Subject Angle | CTA |
+|-------|---------|---------------|-----|
+
+## Tracking
+- Primary metric:
+- Secondary metrics:
+- Customer quality check:
+
+## Decision Rules
+- Double down:
+- Iterate:
+- Kill:
+```
+
+## Quality Bar
+
+- Do not optimize subject lines before clarifying the audience and promise.
+- Include list quality and consent considerations.
+- Measure downstream behavior, not only opens or clicks.
+- Keep the sequence short enough to test quickly.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-events-community/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-events-community/SKILL.md
new file mode 100644
index 00000000..b15201fa
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-events-community/SKILL.md
@@ -0,0 +1,80 @@
+---
+name: traction-events-community
+description: Plan existing-platform, trade show, offline event, speaking, and community-building traction experiments from Traction. Use when testing platform distribution, conferences, meetups, talks, forums, local events, or community-led startup growth.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Events Community
+ category: Marketing
+ tags: traction,community,events,platforms,speaking
+---
+
+# Traction Events Community
+
+Use this skill for channels where distribution comes from existing gatherings,
+platforms, events, talks, or communities.
+
+## Source Traceability
+
+Primary source: Traction, chapters 20-24 and the appendix. Authoring notes:
+converted lines 2704-3218 and 3359-3372.
+
+## Channel Options
+
+- **Existing platforms**: reach users already active on a major or niche
+ platform.
+- **Trade shows**: use industry events to meet buyers, partners, or press.
+- **Offline events**: host or sponsor gatherings for the target market.
+- **Speaking engagements**: teach or tell a useful story to a relevant room.
+- **Community building**: participate in or build a community around the
+ problem, product, or audience.
+
+## Workflow
+
+1. Identify where the target audience already gathers.
+2. Choose one channel strategy: platform tactic, event, talk, or community
+ contribution.
+3. Define the role: attendee, exhibitor, sponsor, speaker, host, or member.
+4. Prepare the asset: talk, booth offer, platform post, community guide, event
+ agenda, or follow-up sequence.
+5. Track conversations, signups, qualified leads, partnerships, and retention.
+6. Decide whether to repeat, deepen, or stop.
+
+## Output Format
+
+```markdown
+# Events/Community Traction Plan
+
+## Strategy
+- Channel:
+- Gathering/platform/community:
+- Target audience:
+- Role:
+
+## Plan
+| Step | Action | Owner | Success Signal |
+|------|--------|-------|----------------|
+
+## Conversion Path
+- First interaction:
+- Follow-up:
+- Conversion event:
+
+## Measurement
+- Quantitative metrics:
+- Qualitative signals:
+- Revisit date:
+
+## Decision Rules
+- Double down if:
+- Iterate if:
+- Kill if:
+```
+
+## Quality Bar
+
+- Do not join communities just to pitch.
+- Match the event or platform to the exact customer segment.
+- Plan follow-up before the event or activity starts.
+- Value conversations and customer learning, not only attendee counts.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-paid-acquisition/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-paid-acquisition/SKILL.md
new file mode 100644
index 00000000..9423a9fe
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-paid-acquisition/SKILL.md
@@ -0,0 +1,85 @@
+---
+name: traction-paid-acquisition
+description: Plan paid acquisition tests from Traction across SEM, social/display ads, and offline ads. Use when designing ad experiments, keyword tests, audience tests, paid channel budgets, or deciding whether a paid channel can acquire the right customers profitably.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Paid Acquisition
+ category: Marketing
+ tags: traction,ads,sem,paid-acquisition,marketing
+---
+
+# Traction Paid Acquisition
+
+Use this skill to design paid acquisition experiments that validate customer
+quality and economics before scaling spend.
+
+## Source Traceability
+
+Primary source: Traction, chapters 9-11 and the appendix. Authoring notes:
+converted lines 1233-1627 and 3335-3340.
+
+## Channels
+
+- **SEM**: test high-intent search demand and conversion economics.
+- **Social and display ads**: test targeted audiences, creative, and offer
+ resonance.
+- **Offline ads**: test channels that competitors may ignore, especially niche
+ podcasts, local media, or audience-specific placements.
+
+## Workflow
+
+1. State the buying intent or audience hypothesis.
+2. Select one paid channel strategy, not a broad paid marketing mix.
+3. Define the conversion event that matters.
+4. Set a small budget and time box.
+5. Create a minimal landing path with tracking.
+6. Estimate break-even CAC from price, margin, and LTV.
+7. Run the test and compare CAC, conversion quality, and reachable volume.
+
+## Output Format
+
+```markdown
+# Paid Acquisition Test
+
+## Hypothesis
+[Audience/intent + offer + expected conversion.]
+
+## Channel Strategy
+- Channel:
+- Audience or keywords:
+- Offer:
+- Budget:
+- Duration:
+
+## Economics
+| Metric | Estimate |
+|--------|----------|
+| Price/LTV | |
+| Gross margin | |
+| Break-even CAC | |
+| Target CAC for test | |
+
+## Creative/Copy
+- Ad angle 1:
+- Ad angle 2:
+- Landing page promise:
+
+## Tracking
+- Conversion event:
+- Attribution method:
+- Customer quality check:
+
+## Decision Rules
+- Double down:
+- Iterate:
+- Kill:
+```
+
+## Quality Bar
+
+- Track conversions, not only clicks.
+- Compare CAC against LTV or expected customer value.
+- Keep early tests narrow enough to interpret.
+- Avoid large budgets before one strategy has signal.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-partnership-sales/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-partnership-sales/SKILL.md
new file mode 100644
index 00000000..370e77c4
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-partnership-sales/SKILL.md
@@ -0,0 +1,77 @@
+---
+name: traction-partnership-sales
+description: Plan business development, sales, and affiliate traction experiments from Traction. Use when testing partnerships, direct sales conversations, outbound lists, affiliate programs, channel partners, or revenue-oriented startup acquisition channels.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Partnership Sales
+ category: Marketing
+ tags: traction,sales,business-development,affiliate-marketing,partnerships
+---
+
+# Traction Partnership Sales
+
+Use this skill when growth depends on direct human channels: partnerships,
+sales, channel deals, or affiliates.
+
+## Source Traceability
+
+Primary source: Traction, chapters 17-19 and the appendix. Authoring notes:
+converted lines 2287-2703 and 3353-3358.
+
+## Channel Options
+
+- **Business development**: create strategic relationships that benefit both
+ parties.
+- **Sales**: directly convert prospects into paying customers and learn from
+ the conversation.
+- **Affiliate programs**: motivate third parties to promote the product with a
+ clear payout and onboarding path.
+
+## Workflow
+
+1. Choose the commercial channel and target segment.
+2. Define the mutual value proposition.
+3. Build a small target list.
+4. Write a conversation or outreach script.
+5. Track meetings, objections, conversion, and customer quality.
+6. Decide whether the channel can scale or should remain a learning channel.
+
+## Output Format
+
+```markdown
+# Partnership/Sales Traction Plan
+
+## Channel
+- Channel:
+- Target:
+- Offer:
+- Desired outcome:
+
+## Target List
+| Prospect/Partner Type | Why Fit | Outreach Angle | Next Step |
+|-----------------------|---------|----------------|-----------|
+
+## Conversation Plan
+- Opening:
+- Discovery questions:
+- Proof:
+- Ask:
+
+## Metrics
+| Metric | Target |
+|--------|--------|
+
+## Decision Rules
+- Double down:
+- Iterate:
+- Kill:
+```
+
+## Quality Bar
+
+- Do not confuse a vague partnership idea with a deal path.
+- Include both sides of value for BD.
+- Treat sales objections as product and positioning data.
+- Onboard affiliates personally before expecting performance.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-pr-playbook/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-pr-playbook/SKILL.md
new file mode 100644
index 00000000..ba78ac83
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-pr-playbook/SKILL.md
@@ -0,0 +1,83 @@
+---
+name: traction-pr-playbook
+description: Plan PR-oriented traction experiments from Traction, including targeting blogs, publicity, and unconventional PR. Use when pitching bloggers or reporters, designing publicity stunts, earning launch coverage, or validating PR as a startup growth channel.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction PR Playbook
+ category: Marketing
+ tags: traction,pr,publicity,marketing,startups
+---
+
+# Traction PR Playbook
+
+Use this skill for the PR-side traction channels: targeting blogs, publicity,
+and unconventional PR. The output should be a concrete pitch/test plan, not a
+generic awareness strategy.
+
+## Source Traceability
+
+Primary source: Traction, chapters 6-8 and the appendix. Authoring notes:
+converted lines 903-1232 and 3323-3334.
+
+## Channel Selection
+
+- **Targeting blogs**: use when niche audiences trust independent writers,
+ newsletters, or community blogs.
+- **Publicity**: use when the company has a local, industry, timely, data, or
+ human-interest angle.
+- **Unconventional PR**: use when a remarkable stunt, contest, comparison,
+ customer delight move, or creative asset can carry the story.
+
+## Workflow
+
+1. Define the traction goal and target customer.
+2. Choose the PR channel most likely to reach that customer.
+3. Build a media or creator list with relevance notes.
+4. Write the hook in one sentence.
+5. Create the asset: demo, data point, customer story, contest, giveaway,
+ founder narrative, or visual.
+6. Draft outreach that makes the recipient's job easier.
+7. Define conversion tracking before outreach starts.
+8. Run a small test, then decide whether to expand or stop.
+
+## Output Format
+
+```markdown
+# PR Traction Plan
+
+## Goal And Audience
+- Traction goal:
+- Customer:
+- PR channel:
+
+## Story Hook
+[One sentence.]
+
+## Target List
+| Target | Why Relevant | Angle | Outreach Path |
+|--------|--------------|-------|---------------|
+
+## Outreach Draft
+[Short pitch customized to the target type.]
+
+## Test Design
+- Sample size:
+- Asset:
+- Tracking:
+- Success threshold:
+- Kill threshold:
+
+## Decision Rules
+- Double down if:
+- Iterate if:
+- Kill if:
+```
+
+## Quality Bar
+
+- Do not pitch generic product announcements.
+- Make the recipient's audience fit explicit.
+- Tie coverage to a measurable conversion path.
+- Keep early tests small before scaling outreach.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-review/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-review/SKILL.md
new file mode 100644
index 00000000..90c99099
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-review/SKILL.md
@@ -0,0 +1,72 @@
+---
+name: traction-review
+description: Review traction experiment results and recommend whether to double down, iterate, repeat Bullseye, or pivot. Use when analyzing growth test data, comparing channel performance, deciding if a channel moved the needle, or reassessing startup traction strategy.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Review
+ category: Marketing
+ tags: traction,growth,experiments,analytics,strategy
+---
+
+# Traction Review
+
+Use this skill after traction tests have run. The goal is to turn results into a
+decision: focus, iterate, repeat Bullseye, or reconsider the product or market.
+
+## Source Traceability
+
+Primary source: Traction, chapters 2-5. Authoring notes: converted lines
+394-902.
+
+## Review Workflow
+
+1. Restate the traction goal and current growth stage.
+2. Compare results against the prewritten success and kill thresholds.
+3. Evaluate customer quality, not only volume.
+4. Decide whether the result moved the needle for the current stage.
+5. Identify bright spots: small customer groups with unusually strong
+ engagement, conversion, retention, or willingness to pay.
+6. Recommend one decision:
+ - double down on the core channel,
+ - run inner-ring optimization,
+ - run another middle-ring test,
+ - repeat Bullseye with new information,
+ - revisit product, market, or positioning.
+
+## Output Format
+
+```markdown
+# Traction Review
+
+## Goal And Context
+- Goal:
+- Stage:
+- Test period:
+
+## Results
+| Channel/Strategy | Cost | Reach | Conversion | Customer Fit | Notes |
+|------------------|------|-------|------------|--------------|-------|
+
+## Decision
+[Double down, iterate, repeat Bullseye, or revisit product/market.]
+
+## Reasoning
+- What moved the needle:
+- What failed:
+- Bright spots:
+- Risks:
+
+## Next Actions
+1. [Action]
+2. [Action]
+3. [Action]
+```
+
+## Quality Bar
+
+- Do not declare success from vanity metrics.
+- Do not pivot before checking bright spots and engagement evidence.
+- Do not keep secondary channels alive just because they somewhat worked.
+- Reassess the Critical Path after meaningful evidence.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-seo-content/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-seo-content/SKILL.md
new file mode 100644
index 00000000..b522a303
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-seo-content/SKILL.md
@@ -0,0 +1,76 @@
+---
+name: traction-seo-content
+description: Plan SEO and content marketing traction experiments from Traction. Use when creating organic growth tests, SEO page strategies, content calendars, blog experiments, link-building tests, or deciding whether content can become a core acquisition channel.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction SEO Content
+ category: Marketing
+ tags: traction,seo,content-marketing,organic-growth,marketing
+---
+
+# Traction SEO Content
+
+Use this skill to test whether organic search or content can acquire meaningful
+customers, not just traffic.
+
+## Source Traceability
+
+Primary source: Traction, chapters 12-13 and the appendix. Authoring notes:
+converted lines 1628-1862 and 3341-3346.
+
+## Strategy Options
+
+- **Fat-head SEO**: validate high-volume, high-intent keywords before investing.
+- **Long-tail SEO**: create many useful pages around specific customer needs.
+- **Content marketing**: publish surprising, useful, data-rich, or opinionated
+ material that attracts and converts a specific audience.
+- **Guest content and amplification**: use other audiences to jump-start the
+ core organic strategy.
+
+## Workflow
+
+1. Define the customer intent or reader problem.
+2. Choose SEO, content marketing, or a supporting blend.
+3. Identify conversion path before content production.
+4. Pick a small set of pages or posts to test.
+5. Promote intentionally; do not wait passively for organic discovery.
+6. Measure qualified conversions, assisted conversions, links, and audience
+ growth.
+7. Decide whether to expand, reposition, or stop.
+
+## Output Format
+
+```markdown
+# SEO/Content Traction Plan
+
+## Goal
+- Traction goal:
+- Target customer:
+- Conversion event:
+
+## Strategy
+- Organic strategy:
+- Why this can move the needle:
+
+## Page/Post Plan
+| Asset | Intent | Angle | Promotion | Conversion Path |
+|-------|--------|-------|-----------|-----------------|
+
+## Measurement
+| Metric | Target | Tool/Method |
+|--------|--------|-------------|
+
+## Decision Rules
+- Double down:
+- Iterate:
+- Kill:
+```
+
+## Quality Bar
+
+- Do not treat traffic as success without customer fit.
+- Prefer specific intent clusters over generic topics.
+- Include promotion and link acquisition work.
+- Tie every asset to a conversion path.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-test-planner/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-test-planner/SKILL.md
new file mode 100644
index 00000000..f4b3f356
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-test-planner/SKILL.md
@@ -0,0 +1,152 @@
+---
+name: traction-test-planner
+description: Design cheap, measurable traction tests from Traction for startup growth channels. Use when planning marketing experiments, middle-ring tests, A/B tests, acquisition test spreadsheets, channel validation, or growth experiment success criteria.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Test Planner
+ category: Marketing
+ tags: traction,growth,experiments,marketing,analytics
+---
+
+# Traction Test Planner
+
+Use this skill to design traction tests that create decision-quality evidence.
+It turns a candidate channel strategy into a scoped experiment with assumptions,
+metrics, budget, duration, and next-step rules.
+
+## Source Traceability
+
+Primary source: Traction, chapters 3 and 4, plus the appendix.
+
+- Chapter 3 defines the three core test questions for middle-ring channels.
+ Authoring notes: converted lines 585-606.
+- Chapter 4 distinguishes cheap channel tests from optimization and explains
+ inner-ring testing. Authoring notes: converted lines 675-786.
+- The appendix lists phase I test prompts for the 19 traction channels.
+ Authoring notes: converted lines 3323-3372.
+
+See [middle-ring-test-prompts.md](references/middle-ring-test-prompts.md) for
+paraphrased starter tests by channel.
+
+## Test Types
+
+### Middle-Ring Test
+
+Use when validating whether a channel strategy could become the core channel.
+Keep it cheap, fast, and strategy-level.
+
+Answer:
+
+1. Acquisition cost: what would it cost to acquire a customer?
+2. Reach: how many relevant customers may be available?
+3. Fit: are these customers desirable right now?
+
+### Inner-Ring Test
+
+Use after a core channel is chosen. Inner-ring tests optimize the winning
+strategy or search for a better strategy inside the same channel.
+
+Examples:
+
+- Test a new audience, keyword group, offer, landing page, creative angle, or
+ partner segment.
+- Run A/B tests where traffic and measurement are already in place.
+- Use other channels only as support for the core channel, not as competing
+ strategies.
+
+## Workflow
+
+### 1. State The Decision
+
+Write the decision the test must enable. Good tests decide something specific:
+
+- Continue, kill, or revise this channel strategy.
+- Promote this channel into the inner ring.
+- Scale spend, hold spend, or change audience.
+- Choose between two channel strategies.
+
+### 2. Write Assumptions
+
+List the assumptions that must be true for the strategy to work.
+
+Use this structure:
+
+| Assumption | How Test Measures It | Kill Threshold |
+|------------|----------------------|----------------|
+
+### 3. Set Metrics
+
+At minimum, include:
+
+- Reach available.
+- Conversion rate.
+- Cost to acquire a customer.
+- Customer quality or intent.
+- Lifetime value estimate, if available.
+
+If the user lacks analytics, include a setup step before the test. A test
+without tracking creates anecdotes, not evidence.
+
+### 4. Bound Budget And Time
+
+For early-stage tests, prefer less than one month and a small budget. If the
+user proposes a large test before there is evidence, reduce scope.
+
+### 5. Define Outcomes Before Running
+
+Every test needs decision rules:
+
+- **Double down** when results beat the success threshold and customer quality is
+ acceptable.
+- **Iterate** when one metric fails but the channel shows a fixable signal.
+- **Kill** when reach, cost, or customer fit cannot plausibly move the traction
+ goal.
+
+## Output Format
+
+```markdown
+# Traction Test Plan
+
+## Decision
+[What this test will decide.]
+
+## Channel Strategy
+- Channel:
+- Strategy:
+- Target customer:
+- Stage:
+
+## Assumptions
+| Assumption | Measurement | Threshold |
+|------------|-------------|-----------|
+
+## Experiment Design
+- Setup:
+- Audience/source:
+- Offer/message:
+- Landing or conversion path:
+- Budget:
+- Duration:
+
+## Metrics
+| Metric | Target | Tracking Method |
+|--------|--------|-----------------|
+
+## Decision Rules
+- Double down if:
+- Iterate if:
+- Kill if:
+
+## Next Step After Test
+[What to do for each likely outcome.]
+```
+
+## Quality Bar
+
+- Do not design tests that only measure vanity traffic.
+- Do not optimize multiple variables before validating strategy-level promise.
+- Make tracking explicit before the test starts.
+- Prefer comparable metrics across channels.
+- Call out when the test cannot plausibly move the user's traction goal.
diff --git a/plugins/LVTD-LLC/skills/skills/traction-test-planner/references/middle-ring-test-prompts.md b/plugins/LVTD-LLC/skills/skills/traction-test-planner/references/middle-ring-test-prompts.md
new file mode 100644
index 00000000..b19faade
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-test-planner/references/middle-ring-test-prompts.md
@@ -0,0 +1,40 @@
+# Middle-Ring Test Prompts
+
+Paraphrased starter tests from Traction's appendix. Use these as defaults for
+phase I startups, then adapt them to the product, market, budget, and traction
+goal.
+
+## Starter Tests By Channel
+
+| Channel | Starter Test |
+|---------|--------------|
+| Targeting blogs | Contact a small set of niche blogs and ask for reviews, walkthroughs, giveaways, or low-cost sponsorships. |
+| Publicity | Pitch a handful of local or niche reporters with a product walk-through and local or industry relevance. |
+| Unconventional PR | Run a contest, stunt, infographic, or video that naturally ties back to the product and can be promoted through paid and earned media. |
+| Search engine marketing | Run a few tightly targeted search ads against high-intent keywords and track actual conversion, not just clicks. |
+| Social and display ads | Run a small campaign against two narrow audiences with a few creative variants and clear conversion tracking. |
+| Offline ads | Test a niche podcast, local publication, or similarly targeted offline placement where audience fit is strong. |
+| SEO | Create a small set of useful long-tail pages or validate fat-head keywords with search ads before investing in organic work. |
+| Content marketing | Publish weekly for a month, promote each post, engage commenters, and watch audience growth plus conversion quality. |
+| Email marketing | Sponsor a couple of niche newsletters or build a short email course with a clear product upsell. |
+| Viral marketing | Map the viral loop, measure the weakest step, and run several small tests to improve that step. |
+| Engineering as marketing | Build a simple free tool for the target audience, collect opt-ins, and personally follow up with users. |
+| Business development | Identify partner categories, contact a few smaller players in each, and try to create one concrete deal. |
+| Sales | Build a small prospect list, get warm intros where possible, and run direct customer conversations or cold outreach. |
+| Affiliate programs | Join or create a relevant affiliate setup, recruit a small group of affiliates, and onboard them personally. |
+| Existing platforms | Choose one niche platform where the audience already gathers and test the platform's native promotion patterns. |
+| Trade shows | List relevant events, interview people who attended, and exhibit at or attend the most promising event. |
+| Offline events | Host a small event or sponsor several local events and ask for a brief speaking slot. |
+| Speaking engagements | Pitch local meetups or regional conferences with a talk grounded in the founder story and customer problem. |
+| Community building | Join relevant forums or communities, contribute substantially over time, and mention the product only where appropriate. |
+
+## Standard Test Questions
+
+For every test, answer:
+
+1. What customer segment is this test trying to reach?
+2. What is the smallest version of the test that can produce useful evidence?
+3. What conversion event proves interest?
+4. What budget and time box are acceptable?
+5. What result would justify a bigger test?
+6. What result would kill the strategy?
diff --git a/plugins/LVTD-LLC/skills/skills/traction-viral-engineering/SKILL.md b/plugins/LVTD-LLC/skills/skills/traction-viral-engineering/SKILL.md
new file mode 100644
index 00000000..0f1e5a9a
--- /dev/null
+++ b/plugins/LVTD-LLC/skills/skills/traction-viral-engineering/SKILL.md
@@ -0,0 +1,80 @@
+---
+name: traction-viral-engineering
+description: Plan viral marketing and engineering-as-marketing traction experiments from Traction. Use when designing referral loops, viral coefficients, engineered acquisition tools, calculators, microsites, widgets, or product-led assets that acquire customers; use make-product-viral instead for landing-page audits, shareability reviews, pricing-page polish, or social-preview optimization.
+license: MIT
+compatibility: Codex, Claude Code, and other Agent Skills-compatible clients.
+metadata:
+ version: "0.1.0"
+ displayName: Traction Viral Engineering
+ category: Marketing
+ tags: traction,viral-marketing,engineering-as-marketing,referrals,growth
+---
+
+# Traction Viral Engineering
+
+Use this skill for growth loops and useful engineered assets: referral systems,
+viral sharing, free tools, calculators, widgets, microsites, and product-led
+lead magnets.
+
+For landing-page audits, pricing-page polish, social previews, or broad
+shareability reviews, use `make-product-viral` instead. This skill is for
+designing measurable traction experiments around loops and engineered assets.
+
+## Source Traceability
+
+Primary source: Traction, chapters 15-16 and the appendix. Authoring notes:
+converted lines 1997-2286 and 3349-3352.
+
+## Strategy Options
+
+- **Viral loop**: users invite or expose the product to more users as part of
+ normal use.
+- **Referral loop**: customers are prompted and rewarded to bring in similar
+ customers.
+- **Engineering as marketing**: a useful free tool attracts prospects and leads
+ them back to the core product.
+
+## Workflow
+
+1. Choose loop or tool.
+2. Define the target user and the moment of motivation.
+3. Map each step from exposure to signup to share or lead capture.
+4. Identify the weakest step.
+5. Design small tests to improve that step.
+6. Measure coefficient, cycle time, conversion quality, and follow-up value.
+
+## Output Format
+
+```markdown
+# Viral/Engineering Growth Plan
+
+## Growth Mechanism
+- Type:
+- Target user:
+- Core motivation:
+
+## Loop Or Tool Map
+| Step | User Action | Metric | Weakness |
+|------|-------------|--------|----------|
+
+## Tests
+| Test | Step Improved | Expected Effect | Tracking |
+|------|---------------|-----------------|----------|
+
+## Follow-Up
+- Lead capture:
+- Product handoff:
+- Retention/referral prompt:
+
+## Decision Rules
+- Double down:
+- Iterate:
+- Kill:
+```
+
+## Quality Bar
+
+- Do not call ordinary word-of-mouth a viral loop.
+- Measure the weakest step before proposing a large build.
+- Keep engineered tools useful without requiring a sales pitch.
+- Ensure the asset attracts the same people the product wants as customers.
+
+# LVTD Skills
+
+Reusable agent skills for LVTD projects, Django SaaS workflows, and agent-first software development.
+
+This repository is intentionally simple: every skill lives in `skills/