@flitzrrr/agent-skills 1.0.3 → 1.2.0

package/skills/execute-work-package/SKILL.md

@@ -0,0 +1,300 @@
+---
+name: execute-work-package
+description: Execute a significant implementation unit (phase or major slice) using a gated subagent loop (blueprint -> gate -> execute -> digest) without creating new persistent artifacts.
+license: MIT
+compatibility:
+  opencode: ">=0.1"
+  claude-code: ">=1.0"
+  cursor: ">=0.40"
+  copilot: ">=1.0"
+  codex: ">=0.1"
+  windsurf: ">=1.0"
+metadata:
+  category: execution
+  phase: implementation
+  transport_options: [mcp, stateful, fresh]
+---
+
+# Skill: Execute Work Packet
+
+This skill standardizes **execution/implementation** once planning is gated.
+
+It is a small, repeatable protocol:
+
+1) **BLUEPRINT**: Subagent returns an **Execution Blueprint** (step list)
+2) **GATE**: Primary approves (primary-internal)
+3) **EXECUTE**: Fresh subagent implements and verifies
+4) **DIGEST**: Subagent returns a compact digest (no raw logs/diffs)
+
+This skill deliberately **does not** create new persistent artifacts in `docs/` or `plans/`.
+
+---
+
+## When to Use
+
+Use this skill when:
+
+- A plan/phase (or a major slice of a phase) already has a clear **DoD** and **verification** approach.
+- You want to offload implementation to a subagent without causing primary context bloat.
+- You want predictable, reviewable execution with a single explicit gate.
+
+If your phase implementation plan is still vague or unverified against the repo, run `author-and-verify-implementation-plan` first.
+
+Do **not** use this skill to:
+
+- (Re-)do planning (scope, risks, alternatives) — that is **Primary** work.
+- Generate documentation/planning artifacts — use `generate-docs`, `create-plan`, `update-plan`, `update-docs`.
+
+---
+
+## Execution Model
+
+### Roles
+
+- **Primary (maintainer)**
+  - Owns scope/DoD/risk decisions and gating.
+  - Chooses the work packet (phase or significant phase slice).
+  - Owns Git operations (stage/commit/PR) unless explicitly delegated.
+  - Updates plan/todo via `update-plan` as needed.
+
+- **Subagent (implementer)**
+  - Does execution only.
+  - First returns a **step list**.
+  - After approval, executes those steps and returns a **digest**.
+  - Does not do Git operations.
+
+## Routing Matrix (Who does what)
+
+- **Writes**: code files in the target repository (working tree changes) and runs verification commands.
+- **Does NOT write**: `plans/**` or `docs/**` artifacts.
+- **Primary**: owns gating/approval, Git operations, and any updates to `plans/**` (typically via `update-plan`).
+- **implementer**: execution only (blueprint → execute → digest), no Git.
+- **doc-explorer**: not used for this skill (unless you explicitly want docs/plan artifacts, in which case use the appropriate planning/doc skills).
+
+### Why `docs/` and `plans/` matter here
+
+- `plans/` provides the gated intent/DoD and references for what to implement.
+- `docs/` (if present) provides curated inventories (modules/features/symbols) so the subagent does not rediscover everything.
+
+### Transport
+
+This skill supports three transport mechanisms. **If l4l-oci MCP tools are available** (check: do you have `create_handle`, `generate_blueprint`, `submit_gate`, `execute_handle`, `get_digest` tools?), **always use Option A.** Only fall back to B/C if MCP is not configured.
+
+#### Pre-flight: Ensure l4l-oci server is running
+
+Before using Option A, run the bundled helper:
+
+```bash
+skills/execute-work-package/scripts/start-l4l-oci.sh
+```
+
+Behavior:
+- Uses `L4L_OCI_ROOT` (default: `$HOME/git/l4l-oci`)
+- Starts `python -m l4l_oci` in background if needed
+- Waits for MCP `health` to return `ok`
+- Exports `L4L_OCI_DEFAULT_MODEL=qwen-openrouter` for startup unless already set
+
+Prerequisites:
+- `OPENROUTER_API_KEY` (or `QWEN_API_KEY`) must be available in the environment
+
+#### Option A: MCP via l4l-oci (Default)
+
+Use the l4l-oci MCP server. The primary calls MCP tools directly — no Agent spawning needed:
+
+1. `create_handle(project_root)` → returns `handle_id`
+2. `generate_blueprint(handle_id, prompt)` → async; poll with `get_status(handle_id)` until complete
+3. `get_blueprint(handle_id, format="markdown")` → review the Execution Blueprint
+4. `submit_gate(handle_id, decision="accept"|"reject", notes=...)` → explicit gate
+5. `execute_handle(handle_id)` → async; poll with `get_status(handle_id)` until complete
+6. `get_digest(handle_id, format="markdown")` → returns Execution Digest
+7. `cleanup_handle(handle_id)` → optional cleanup
+
+Benefits: state persistence across restarts, model decoupling (cheap Sub-LLM), scope enforcement, iterative blueprint refinement.
+
+Additional tools: `health()` (service health check), `list_handles()` (list all active handles).
+
+#### Option B: Stateful Subagent (OpenCode)
+
+Original design using `resumeSessionId` to maintain subagent state between BLUEPRINT and EXECUTE:
+
+- BLUEPRINT and EXECUTE use the **same** session (resumed via `resumeSessionId`)
+- The subagent retains context from the BLUEPRINT phase
+
+This is the native OpenCode pattern.
+
+#### Option C: Fresh Agent (Claude Code / Cursor / Copilot)
+
+BLUEPRINT and EXECUTE use **separate** Agent invocations (not SendMessage to resume):
+
+- **BLUEPRINT Agent**: spawned with `mode: auto`, returns the step list, then terminates.
+- **EXECUTE Agent**: spawned as a **new** Agent with the approved step list baked into the prompt. This avoids unreliable SendMessage-based resumption of idle agents.
+
+The EXECUTE prompt must include the full approved step list and all references — the agent has no memory of the BLUEPRINT agent's context.
+
+#### Platform Decision Table
+
+| Platform | Recommended | Fallback |
+|----------|------------|----------|
+| Claude Code | Option A (MCP) | Option C (Fresh Agent) |
+| Cursor | Option A (MCP) | Option C (Fresh Agent) |
+| Copilot | Option A (MCP) | Option C (Fresh Agent) |
+| Codex | Option C (Fresh Agent) | — |
+| Windsurf | Option A (MCP) | Option C (Fresh Agent) |
+| OpenCode | Option B (Stateful) | Option A (MCP) |
+
+---
+
+## Protocol
+
+### 0) Primary inputs (for any work packet)
+
+Before delegating:
+
+- Ensure the work packet is already gated (scope/DoD decided).
+- Provide an explicit **task statement** plus **references** to the relevant planning artifacts.
+  The subagent should read these references itself (the primary does not need to paste content).
+  Recommended references:
+  - `plans/<plan>/plan.md`
+  - `plans/<plan>/phases/phase-N.md`
+  - `plans/<plan>/implementation/phase-N-impl.md`
+  - `plans/<plan>/todo.md` (optional)
+- If project documentation exists, also provide references to it so the subagent can use the curated inventories
+  (symbols, modules, features) instead of rediscovering everything from scratch:
+  - `docs/overview.md` (optional)
+  - `docs/modules/*.md` (optional)
+  - `docs/features/*.md` (optional)
+- Provide a **Verify Command** if one is already decided.
+  If not, the subagent proposes exactly **one** verify command in the BLUEPRINT (to be gated by the primary).
+
+### 1) MODE: BLUEPRINT (Execution Blueprint)
+
+> **Option A (MCP):** Call `create_handle(project_root)`, then `generate_blueprint(handle_id, prompt)`. Poll `get_status(handle_id)` until complete, then `get_blueprint(handle_id, format="markdown")` to review.
+
+Primary delegates to `implementer` with a prompt based on `tpl-implementer-preflight-prompt.md`.
+
+**Gate:** Primary reviews the step list and either:
+
+- Approves (GO)
+- Requests revision (feedback)
+- Aborts and replans
+
+#### Invariant: explicit approval token
+
+Primary provides an explicit approval token before execution (primary-internal gate). Example:
+
+- `APPROVE-WP1`
+
+If the user requests changes, the step list must be revised and re-approved with a new approval token.
+
+### 2) Execute (new Agent)
+
+> **Option A (MCP):** Call `submit_gate(handle_id, decision="accept")` then `execute_handle(handle_id)`. Poll `get_status(handle_id)` until complete, then `get_digest(handle_id, format="markdown")` for the digest.
+
+Primary spawns a **new** `implementer` Agent with a prompt based on `tpl-implementer-execute-prompt.md`. The prompt includes the full approved step list, all references, and the verify command. Do NOT use SendMessage to resume the BLUEPRINT agent — spawn a fresh Agent instead.
+
+#### Invariant: MODE lock
+
+The execute prompt MUST start with a clear mode indicator:
+
+- `MODE: EXECUTE`
+
+and MUST include the approval token.
+
+> **Option A (MCP):** Skip the Agent spawn above. Call `submit_gate` → `execute_handle` → poll `get_status` → `get_digest` directly via MCP tools.
+
+### 3) Digest back to Primary
+
+Subagent responds with a compact digest:
+
+- Outcome (succeeded/failed)
+- Files changed (paths)
+- Verification result (command + exit)
+- If failure: only a small, relevant excerpt (no full logs)
+
+### 4) Primary post-processing
+
+Read the digest carefully. The subagent's verification result determines next steps:
+
+- **Verification passed:** Spot-check with `git diff --stat` to confirm expected changes. Do not re-run the full test suite yourself – the subagent already did.
+- **Verification failed or incomplete:** If additional testing is needed, spawn a new subagent with specific test instructions and relevant references. Do not run large test suites in the primary session.
+- **BLOCKED / no verification ran:** Decide whether to provide missing input and re-delegate, or run a targeted check yourself.
+
+Then:
+
+- Updates `plans/<plan>/todo.md` and phase status via `update-plan`
+- Commits / creates PR **only** when explicitly requested by the user
+
+Optional but recommended (Primary):
+
+- Before execute: capture baseline via `git status` / `git diff --name-only`
+- After execute: confirm changes exist via `git diff --stat`
+
+---
+
+## Output Contracts
+
+### Step List Contract (Subagent -> Primary)
+
+Subagent returns an **Execution Blueprint** in the format of `tpl-execution-blueprint.md`.
+
+The blueprint is expected to be **concrete** (file paths and/or symbol/component targets), not a restatement of plan text.
+
+#### Mode: BLUEPRINT
+
+In BLUEPRINT mode, the subagent must NOT:
+
+- apply patches
+- run commands
+- claim that code was changed
+
+### Digest Contract (Subagent -> Primary)
+
+Subagent MUST return only:
+
+- **Outcome**: succeeded | failed
+- **Edits**: list of files changed + 1-line note each
+- **Verify**: command + exit code + (if failed) small excerpt
+- **Next**: 1–3 bullets (or “ready for Primary Git/commit”)
+
+#### Mode: EXECUTE
+
+In EXECUTE mode, the subagent must:
+
+- implement changes (typically via patch/apply_patch)
+- run the verify command (via bash)
+- if neither happened: return **BLOCKED** with a concrete reason
+
+---
+
+## Rules
+
+- Subagent must not run Git operations (commit, rebase, push).
+- Skill-first: when this skill is invoked, follow its MODE + output contracts before doing anything else.
+- Keep verification minimal: **one** explicit verify command unless the work packet DoD requires more. The verify command must **exercise the changed behavior** (e.g., run relevant tests, hit the affected endpoint, trigger the modified flow) — not just compile, lint, or type-check.
+- No raw diffs or long logs in responses.
+- If verify fails: apply **minimal, targeted fixes** (no refactors) and re-run verify. If still failing or a larger change is required, stop and report a digest with a minimal relevant excerpt.
+- If the step list must change during execution: stop and ask Primary for a new gate.
+
+---
+
+## Coding Standards
+
+These apply to all code written during execution – by the implementer subagent or the primary.
+
+1. **No hardcoded defaults.** Use configuration files or environment variables for values that may change across environments.
+2. **Analyze root cause.** Don't patch symptoms. Understand why something is broken before changing code.
+3. **Minimal changes.** Only touch what the work packet requires. Don't refactor adjacent code you weren't asked to change.
+4. **Preserve existing patterns.** Match the conventions already established in the codebase (naming, structure, error handling).
+5. **No silent failures.** Don't swallow errors or add fallbacks that hide problems. If something fails, it should be visible.
+6. **Respect the dependency boundary.** Don't introduce new dependencies without explicit approval from the primary/user.
+
+If `docs/coding-standards.md` exists in the target repo, read and follow it as well – project-specific standards take precedence.
+
+---
+
+## Templates
+
+- `tpl-implementer-preflight-prompt.md` — Primary -> Subagent (MODE: BLUEPRINT) prompt
+- `tpl-implementer-execute-prompt.md` — Primary -> Subagent (MODE: EXECUTE) prompt (same `task_id`)
+- `tpl-execution-blueprint.md` — canonical blueprint format (step list)
+- `tpl-execution-digest.md` — canonical digest format

package/skills/execute-work-package/scripts/start-l4l-oci.sh

@@ -0,0 +1,75 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+L4L_OCI_ROOT="${L4L_OCI_ROOT:-$HOME/git/l4l-oci}"
+L4L_OCI_URL="${L4L_OCI_URL:-http://127.0.0.1:8765/mcp}"
+L4L_OCI_DEFAULT_MODEL="${L4L_OCI_DEFAULT_MODEL:-qwen-openrouter}"
+L4L_OCI_LOG_FILE="${L4L_OCI_LOG_FILE:-$L4L_OCI_ROOT/logs/l4l-oci-service.log}"
+L4L_OCI_PID_FILE="${L4L_OCI_PID_FILE:-$L4L_OCI_ROOT/.l4l-oci/l4l-oci.pid}"
+
+PY="$L4L_OCI_ROOT/.venv/bin/python"
+if [ ! -x "$PY" ]; then
+  echo "ERROR: Python not found at $PY" >&2
+  exit 1
+fi
+
+if [ -z "${OPENROUTER_API_KEY:-}" ] && [ -z "${QWEN_API_KEY:-}" ]; then
+  echo "ERROR: Neither OPENROUTER_API_KEY nor QWEN_API_KEY is set." >&2
+  exit 1
+fi
+
+health_ok() {
+  "$PY" - <<'PY'
+import asyncio
+import os
+from fastmcp import Client
+
+url = os.environ["L4L_OCI_URL"]
+
+async def main() -> int:
+    try:
+        async with Client(url) as client:
+            res = await client.call_tool("health", {})
+        status = (res.data or {}).get("status")
+        return 0 if status == "ok" else 1
+    except Exception:
+        return 1
+
+raise SystemExit(asyncio.run(main()))
+PY
+}
+
+export L4L_OCI_URL
+
+if health_ok; then
+  echo "l4l-oci already reachable at $L4L_OCI_URL"
+  exit 0
+fi
+
+if [ -f "$L4L_OCI_PID_FILE" ]; then
+  OLD_PID="$(cat "$L4L_OCI_PID_FILE" 2>/dev/null || true)"
+  if [ -n "$OLD_PID" ] && ! kill -0 "$OLD_PID" 2>/dev/null; then
+    rm -f "$L4L_OCI_PID_FILE"
+  fi
+fi
+
+mkdir -p "$(dirname "$L4L_OCI_LOG_FILE")" "$(dirname "$L4L_OCI_PID_FILE")"
+
+(
+  cd "$L4L_OCI_ROOT"
+  export L4L_OCI_DEFAULT_MODEL
+  nohup "$PY" -m l4l_oci >>"$L4L_OCI_LOG_FILE" 2>&1 &
+  echo "$!" >"$L4L_OCI_PID_FILE"
+)
+
+for _ in $(seq 1 30); do
+  if health_ok; then
+    echo "l4l-oci started at $L4L_OCI_URL"
+    exit 0
+  fi
+  sleep 0.5
+done
+
+echo "ERROR: l4l-oci did not become healthy. Last log lines:" >&2
+tail -n 40 "$L4L_OCI_LOG_FILE" >&2 || true
+exit 1

package/skills/execute-work-package/tpl-execution-blueprint.md

@@ -0,0 +1,39 @@
+---
+type: execution
+entity: blueprint
+skill: execute-work-package
+created: "{{date}}"
+---
+
+# Execution Blueprint (Step List)
+
+## Work Packet
+
+- intent: {{intent}}
+- scope_paths: {{scope_paths}}
+
+## References
+
+### Plans
+- plan: {{plan_ref}}
+- phase: {{phase_ref}}
+- implementation_plan: {{implementation_plan_ref}}
+- todo (optional): {{todo_ref}}
+
+### Docs (optional)
+- overview: {{docs_overview_ref}}
+- modules: {{docs_modules_ref}}
+- features: {{docs_features_ref}}
+
+## Steps
+
+1. <concrete step; include file path and/or symbol/component>
+2. ...
+
+## Touched Files
+
+- path/to/file
+
+## Verify
+
+`<single command>`

package/skills/execute-work-package/tpl-execution-digest.md

@@ -0,0 +1,24 @@
+---
+type: execution
+entity: digest
+skill: execute-work-package
+created: "{{date}}"
+---
+
+# Execution Digest (Reference Format)
+
+### Outcome
+- state: succeeded|failed
+
+### Edits
+- files_changed:
+  - path/to/file.ext — one-line summary
+
+### Verify
+- cmd: `...`
+- exit: 0|1|...
+- excerpt (only if failed): |
+    <few relevant lines>
+
+### Next
+- 1–3 bullets

package/skills/execute-work-package/tpl-implementer-execute-prompt.md

@@ -0,0 +1,57 @@
+---
+type: execution
+entity: subagent-execute-prompt
+skill: execute-work-package
+created: "{{date}}"
+---
+
+# Implementer Execute Prompt (Run Approved Steps)
+
+MODE: EXECUTE
+
+You are the **implementer** subagent. This is a **fresh** agent — you have no prior context.
+Read the referenced files yourself to build context, then execute.
+
+Execute the **approved** step list exactly.
+
+Constraints:
+- Do NOT re-plan. Do NOT add new steps unless required to fix an immediate error that blocks the final verify.
+- Do NOT run Git operations.
+- Run the single verify command at the end.
+- Return an **Execution Digest** (no raw diffs/logs).
+
+Execution invariants (must):
+- You MUST perform at least one concrete action: write/edit files and/or run a command.
+- You MUST run the verify command.
+- If you cannot change files or run commands, return:
+  - Outcome: BLOCKED
+  - Concrete reason
+  - What input is missing
+
+<!-- IF MCP: This prompt is used for Options B/C (Stateful/Fresh Agent). For Option A (MCP), run `skills/execute-work-package/scripts/start-l4l-oci.sh` first, then call `submit_gate()` and `execute_handle()`. -->
+
+## Approved Step List
+{{approved_steps}}
+
+## Planning References (read these yourself for context)
+- Plan: {{plan_ref}}
+- Phase: {{phase_ref}}
+- Implementation Plan: {{implementation_plan_ref}}
+
+## Documentation References (read these yourself if needed)
+- Overview (optional): {{docs_overview_ref}}
+- Modules (optional): {{docs_modules_ref}}
+- Features (optional): {{docs_features_ref}}
+
+<!-- IF MCP: When using l4l-oci MCP (Option A), poll `get_status()` and fetch digest via `get_digest()`. -->
+
+## Verify Command
+{{verify_command}}
+
+## Output
+
+Return a Markdown **Execution Digest** using the canonical format in:
+
+- `skills/execute-work-package/tpl-execution-digest.md`
+
+Do not restate the template. Just produce the digest.

package/skills/execute-work-package/tpl-implementer-preflight-prompt.md

@@ -0,0 +1,66 @@
+---
+type: execution
+entity: subagent-preflight-prompt
+skill: execute-work-package
+created: "{{date}}"
+---
+
+# Implementer Preflight Prompt (Step List)
+
+MODE: BLUEPRINT
+
+You are the **implementer** subagent.
+
+Your job: return an **Execution Blueprint** (step list) for the work packet below.
+
+Constraints:
+- Execution-only: do NOT do planning (no risks/alternatives/architecture commentary).
+- Do NOT run Git operations.
+- Keep verification minimal: provide exactly **one** verify command.
+- Output must be compact and structured.
+
+In BLUEPRINT mode:
+- Do NOT apply patches.
+- Do NOT run commands.
+- Do NOT claim you changed code.
+
+<!-- IF MCP: This prompt is used for Options B/C (Stateful/Fresh Agent). For Option A (MCP), run `skills/execute-work-package/scripts/start-l4l-oci.sh` first, then call `create_handle()` and `generate_blueprint()`. -->
+
+## Work Packet
+
+### Intent
+{{intent}}
+
+### Scope (paths / modules)
+{{scope_paths}}
+
+### Planning References (read them yourself)
+- Plan: {{plan_ref}}
+- Phase: {{phase_ref}}
+- Implementation Plan: {{implementation_plan_ref}}
+- Todo (optional): {{todo_ref}}
+
+### Documentation References (if present, read them yourself)
+- Overview (optional): {{docs_overview_ref}}
+- Modules (optional): {{docs_modules_ref}}
+- Features (optional): {{docs_features_ref}}
+
+### DoD (short)
+{{dod}}
+
+### Verify Command
+{{verify_command}}
+
+If `{{verify_command}}` is empty/unknown, propose exactly **one** verify command.
+
+<!-- IF MCP: When using l4l-oci MCP (Option A), pass planning/doc refs through the `generate_blueprint` prompt and retrieve results with `get_blueprint()`. -->
+
+## Output
+
+Return a Markdown **Execution Blueprint** using the canonical format in:
+
+- `skills/execute-work-package/tpl-execution-blueprint.md`
+
+Rules for BLUEPRINT:
+- Do NOT restate phase/impl-plan steps. Concretize using docs inventories (symbols/features/modules) plus a brief code cross-check.
+- Each step must include at least one concrete target (file path and/or symbol/component name).

package/skills/product-description-seo/CROSS-SELL.md

@@ -0,0 +1,31 @@
+# Cross-Sell Matrix — Template
+
+Define which product categories should reference each other in descriptions. Each description should mention 1-2 complementary products to encourage browsing and increase average order value.
+
+## How to Use
+
+For each category, list which other categories make natural companions — products that customers typically buy together or that solve related problems.
+
+## Template
+
+| Category     | Cross-Sell To              | Example Phrasing                        |
+| ------------ | -------------------------- | --------------------------------------- |
+| [Category A] | [Category B], [Category C] | "Pairs well with our [Category B]..."   |
+| [Category B] | [Category A], [Category D] | "For a complete setup, combine with..." |
+
+## Example (Industrial Equipment)
+
+| Category         | Cross-Sell To                | Example Phrasing                                                    |
+| ---------------- | ---------------------------- | ------------------------------------------------------------------- |
+| Power Drills     | Drill Bits, Safety Equipment | "For optimal results, pair with our professional drill bit sets..." |
+| Drill Bits       | Power Drills, Storage Cases  | "Designed for use with our industrial power drills..."              |
+| Safety Equipment | All tool categories          | "Complete your safety setup with our full PPE range..."             |
+| Hand Tools       | Tool Storage, Safety Gloves  | "Store your set securely in our professional tool cases..."         |
+| Tool Storage     | Hand Tools, Power Tools      | "Organize your complete toolkit with matching drawer inserts..."     |
+
+## Principles
+
+- Cross-sells should be genuinely useful, not random upsells
+- Mention the complementary product naturally in the application paragraph (paragraph 3)
+- Use phrasing like "combines well with", "for a complete setup", "pairs with"
+- Maximum 2 cross-sell references per description to avoid sounding salesy

package/skills/product-description-seo/KEYWORDS.md

@@ -0,0 +1,35 @@
+# Keyword Map — Template
+
+Define SEO keywords per product category. Fill in with your catalog's categories and industry-specific terms.
+
+## How to Use
+
+For each category in your catalog, define three keyword tiers:
+
+- **Primary:** Main search term — typically [product type] + [industry term]
+- **Secondary:** Related terms, synonyms, specifications people search for
+- **Longtail:** Purchase-intent phrases, specific use cases
+
+## Template
+
+### [Category Name]
+- **Primary:** [main product term] + [industry]
+- **Secondary:** [synonym 1], [synonym 2], [specification term]
+- **Longtail:** "[product] buy", "[product] for [use case]"
+
+## Example (Industrial Equipment)
+
+### Power Drills
+- **Primary:** power drill industrial, cordless drill professional
+- **Secondary:** drill driver, impact drill, hammer drill, brushless motor
+- **Longtail:** "heavy duty power drill buy", "cordless drill for construction site"
+
+### Safety Equipment
+- **Primary:** safety helmet industrial, work gloves professional
+- **Secondary:** PPE, hard hat, cut-resistant gloves, safety goggles
+- **Longtail:** "safety equipment for warehouse buy", "EN 388 gloves"
+
+### Hand Tools
+- **Primary:** hand tools professional, wrench set industrial
+- **Secondary:** socket set, torque wrench, pliers, screwdriver set
+- **Longtail:** "professional hand tools for mechanics", "torque wrench buy"