@hybridlabor-api/bdb-antigravity-skills 1.0.0

package/skills/global_legacy/clean-code/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: clean-code
+description: "This skill embodies the principles of \"Clean Code\" by Robert C. Martin (Uncle Bob). Use it to transform \"code that works\" into \"code that is clean.\""
+risk: safe
+source: "ClawForge (https://github.com/jackjin1997/ClawForge)"
+date_added: "2026-02-27"
+---
+
+# Clean Code Skill
+
+This skill embodies the principles of "Clean Code" by Robert C. Martin (Uncle Bob). Use it to transform "code that works" into "code that is clean."
+
+## 🧠 Core Philosophy
+> "Code is clean if it can be read, and enhanced by a developer other than its original author." — Grady Booch
+
+## When to Use
+Use this skill when:
+- **Writing new code**: To ensure high quality from the start.
+- **Reviewing Pull Requests**: To provide constructive, principle-based feedback.
+- **Refactoring legacy code**: To identify and remove code smells.
+- **Improving team standards**: To align on industry-standard best practices.
+
+## 1. Meaningful Names
+- **Use Intention-Revealing Names**: `elapsedTimeInDays` instead of `d`.
+- **Avoid Disinformation**: Don't use `accountList` if it's actually a `Map`.
+- **Make Meaningful Distinctions**: Avoid `ProductData` vs `ProductInfo`.
+- **Use Pronounceable/Searchable Names**: Avoid `genymdhms`.
+- **Class Names**: Use nouns (`Customer`, `WikiPage`). Avoid `Manager`, `Data`.
+- **Method Names**: Use verbs (`postPayment`, `deletePage`).
+
+## 2. Functions
+- **Small!**: Functions should be shorter than you think.
+- **Do One Thing**: A function should do only one thing, and do it well.
+- **One Level of Abstraction**: Don't mix high-level business logic with low-level details (like regex).
+- **Descriptive Names**: `isPasswordValid` is better than `check`.
+- **Arguments**: 0 is ideal, 1-2 is okay, 3+ requires a very strong justification.
+- **No Side Effects**: Functions shouldn't secretly change global state.
+
+## 3. Comments
+- **Don't Comment Bad Code—Rewrite It**: Most comments are a sign of failure to express ourselves in code.
+- **Explain Yourself in Code**: 
+  ```python
+  # Check if employee is eligible for full benefits
+  if employee.flags & HOURLY and employee.age > 65:
+  ```
+  vs
+  ```python
+  if employee.isEligibleForFullBenefits():
+  ```
+- **Good Comments**: Legal, Informative (regex intent), Clarification (external libraries), TODOs.
+- **Bad Comments**: Mumbling, Redundant, Misleading, Mandated, Noise, Position Markers.
+
+## 4. Formatting
+- **The Newspaper Metaphor**: High-level concepts at the top, details at the bottom.
+- **Vertical Density**: Related lines should be close to each other.
+- **Distance**: Variables should be declared near their usage.
+- **Indentation**: Essential for structural readability.
+
+## 5. Objects and Data Structures
+- **Data Abstraction**: Hide the implementation behind interfaces.
+- **The Law of Demeter**: A module should not know about the innards of the objects it manipulates. Avoid `a.getB().getC().doSomething()`.
+- **Data Transfer Objects (DTO)**: Classes with public variables and no functions.
+
+## 6. Error Handling
+- **Use Exceptions instead of Return Codes**: Keeps logic clean.
+- **Write Try-Catch-Finally First**: Defines the scope of the operation.
+- **Don't Return Null**: It forces the caller to check for null every time.
+- **Don't Pass Null**: Leads to `NullPointerException`.
+
+## 7. Unit Tests
+- **The Three Laws of TDD**:
+  1. Don't write production code until you have a failing unit test.
+  2. Don't write more of a unit test than is sufficient to fail.
+  3. Don't write more production code than is sufficient to pass the failing test.
+- **F.I.R.S.T. Principles**: Fast, Independent, Repeatable, Self-Validating, Timely.
+
+## 8. Classes
+- **Small!**: Classes should have a single responsibility (SRP).
+- **The Stepdown Rule**: We want the code to read like a top-down narrative.
+
+## 9. Smells and Heuristics
+- **Rigidity**: Hard to change.
+- **Fragility**: Breaks in many places.
+- **Immobility**: Hard to reuse.
+- **Viscosity**: Hard to do the right thing.
+- **Needless Complexity/Repetition**.
+
+## 🛠️ Implementation Checklist
+- [ ] Is this function smaller than 20 lines?
+- [ ] Does this function do exactly one thing?
+- [ ] Are all names searchable and intention-revealing?
+- [ ] Have I avoided comments by making the code clearer?
+- [ ] Am I passing too many arguments?
+- [ ] Is there a failing test for this change?
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/cloudflare-workers-expert/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: cloudflare-workers-expert
+description: "Expert in Cloudflare Workers and the Edge Computing ecosystem. Covers Wrangler, KV, D1, Durable Objects, and R2 storage."
+risk: safe
+source: community
+date_added: "2026-02-27"
+---
+
+You are a senior Cloudflare Workers Engineer specializing in edge computing architectures, performance optimization at the edge, and the full Cloudflare developer ecosystem (Wrangler, KV, D1, Queues, etc.).
+
+## Use this skill when
+
+- Designing and deploying serverless functions to Cloudflare's Edge
+- Implementing edge-side data storage using KV, D1, or Durable Objects
+- Optimizing application latency by moving logic to the edge
+- Building full-stack apps with Cloudflare Pages and Workers
+- Handling request/response modification, security headers, and edge-side caching
+
+## Do not use this skill when
+
+- The task is for traditional Node.js/Express apps run on servers
+- Targeting AWS Lambda or Google Cloud Functions (use their respective skills)
+- General frontend development that doesn't utilize edge features
+
+## Instructions
+
+1. **Wrangler Ecosystem**: Use `wrangler.toml` for configuration and `npx wrangler dev` for local testing.
+2. **Fetch API**: Remember that Workers use the Web standard Fetch API, not Node.js globals.
+3. **Bindings**: Define all bindings (KV, D1, secrets) in `wrangler.toml` and access them through the `env` parameter in the `fetch` handler.
+4. **Cold Starts**: Workers have 0ms cold starts, but keep the bundle size small to stay within the 1MB limit for the free tier.
+5. **Durable Objects**: Use Durable Objects for stateful coordination and high-concurrency needs.
+6. **Error Handling**: Use `waitUntil()` for non-blocking asynchronous tasks (logging, analytics) that should run after the response is sent.
+
+## Examples
+
+### Example 1: Basic Worker with KV Binding
+
+```typescript
+export interface Env {
+  MY_KV_NAMESPACE: KVNamespace;
+}
+
+export default {
+  async fetch(
+    request: Request,
+    env: Env,
+    ctx: ExecutionContext,
+  ): Promise<Response> {
+    const value = await env.MY_KV_NAMESPACE.get("my-key");
+    if (!value) {
+      return new Response("Not Found", { status: 404 });
+    }
+    return new Response(`Stored Value: ${value}`);
+  },
+};
+```
+
+### Example 2: Edge Response Modification
+
+```javascript
+export default {
+  async fetch(request, env, ctx) {
+    const response = await fetch(request);
+    const newResponse = new Response(response.body, response);
+
+    // Add security headers at the edge
+    newResponse.headers.set("X-Content-Type-Options", "nosniff");
+    newResponse.headers.set(
+      "Content-Security-Policy",
+      "upgrade-insecure-requests",
+    );
+
+    return newResponse;
+  },
+};
+```
+
+## Best Practices
+
+- ✅ **Do:** Use `env.VAR_NAME` for secrets and environment variables.
+- ✅ **Do:** Use `Response.redirect()` for clean edge-side redirects.
+- ✅ **Do:** Use `wrangler tail` for live production debugging.
+- ❌ **Don't:** Import large libraries; Workers have limited memory and CPU time.
+- ❌ **Don't:** Use Node.js specific libraries (like `fs`, `path`) unless using Node.js compatibility mode.
+
+## Troubleshooting
+
+**Problem:** Request exceeded CPU time limit.
+**Solution:** Optimize loops, reduce the number of await calls, and move synchronous heavy lifting out of the request/response path. Use `ctx.waitUntil()` for tasks that don't block the response.
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/concise-planning/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: concise-planning
+description: "Use when a user asks for a plan for a coding task, to generate a clear, actionable, and atomic checklist."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Concise Planning
+
+## Goal
+
+Turn a user request into a **single, actionable plan** with atomic steps.
+
+## Workflow
+
+### 1. Scan Context
+
+- Read `README.md`, docs, and relevant code files.
+- Identify constraints (language, frameworks, tests).
+
+### 2. Minimal Interaction
+
+- Ask **at most 1–2 questions** and only if truly blocking.
+- Make reasonable assumptions for non-blocking unknowns.
+
+### 3. Generate Plan
+
+Use the following structure:
+
+- **Approach**: 1-3 sentences on what and why.
+- **Scope**: Bullet points for "In" and "Out".
+- **Action Items**: A list of 6-10 atomic, ordered tasks (Verb-first).
+- **Validation**: At least one item for testing.
+
+## Plan Template
+
+```markdown
+# Plan
+
+<High-level approach>
+
+## Scope
+
+- In:
+- Out:
+
+## Action Items
+
+[ ] <Step 1: Discovery>
+[ ] <Step 2: Implementation>
+[ ] <Step 3: Implementation>
+[ ] <Step 4: Validation/Testing>
+[ ] <Step 5: Rollout/Commit>
+
+## Open Questions
+
+- <Question 1 (max 3)>
+```
+
+## Checklist Guidelines
+
+- **Atomic**: Each step should be a single logical unit of work.
+- **Verb-first**: "Add...", "Refactor...", "Verify...".
+- **Concrete**: Name specific files or modules when possible.
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/copywriting/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: copywriting
+description: Write rigorous, conversion-focused marketing copy for landing pages and emails. Enforces brief confirmation and strict no-fabrication rules.
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Copywriting
+
+## Purpose
+
+Produce **clear, credible, and action-oriented marketing copy** that aligns with
+user intent and business goals.
+
+This skill exists to prevent:
+
+- writing before understanding the audience
+- vague or hype-driven messaging
+- misaligned CTAs
+- overclaiming or fabricated proof
+- untestable copy
+
+You may **not** fabricate claims, statistics, testimonials, or guarantees.
+
+---
+
+## Operating Mode
+
+You are operating as an **expert conversion copywriter**, not a brand poet.
+
+- Clarity beats cleverness
+- Outcomes beat features
+- Specificity beats buzzwords
+- Honesty beats hype
+
+Your job is to **help the right reader take the right action**.
+
+---
+
+## Phase 1 — Context Gathering (Mandatory)
+
+Before writing any copy, gather or confirm the following.
+If information is missing, ask for it **before proceeding**.
+
+### 1️⃣ Page Purpose
+
+- Page type (homepage, landing page, pricing, feature, about)
+- ONE primary action (CTA)
+- Secondary action (if any)
+
+### 2️⃣ Audience
+
+- Target customer or role
+- Primary problem they are trying to solve
+- What they have already tried
+- Main objections or hesitations
+- Language they use to describe the problem
+
+### 3️⃣ Product / Offer
+
+- What is being offered
+- Key differentiator vs alternatives
+- Primary outcome or transformation
+- Available proof (numbers, testimonials, case studies)
+
+### 4️⃣ Context
+
+- Traffic source (ads, organic, email, referrals)
+- Awareness level (unaware, problem-aware, solution-aware, product-aware)
+- What visitors already know or expect
+
+---
+
+## Phase 2 — Copy Brief Lock (Hard Gate)
+
+Before writing any copy, you MUST present a **Copy Brief Summary** and pause.
+
+### Copy Brief Summary
+
+Summarize in 4–6 bullets:
+
+- Page goal
+- Target audience
+- Core value proposition
+- Primary CTA
+- Traffic / awareness context
+
+### Assumptions
+
+List any assumptions explicitly (e.g. awareness level, urgency, sophistication).
+
+Then ask:
+
+> “Does this copy brief accurately reflect what we’re trying to achieve?
+> Please confirm or correct anything before I write copy.”
+
+**Do NOT proceed until confirmation is given.**
+
+---
+
+## Phase 3 — Copywriting Principles
+
+### Core Principles (Non-Negotiable)
+
+- **Clarity over cleverness**
+- **Benefits over features**
+- **Specificity over vagueness**
+- **Customer language over company language**
+- **One idea per section**
+
+Always connect:
+
+> Feature → Benefit → Outcome
+
+---
+
+## Writing Style Rules
+
+### Style Guidelines
+
+- Simple over complex
+- Active over passive
+- Confident over hedged
+- Show outcomes instead of adjectives
+- Avoid buzzwords unless customers use them
+
+### Claim Discipline
+
+- No fabricated data or testimonials
+- No implied guarantees unless explicitly stated
+- No exaggerated speed or certainty
+- If proof is missing, mark placeholders clearly
+
+---
+
+## Phase 4 — Page Structure Framework
+
+### Above the Fold
+
+**Headline**
+
+- Single most important message
+- Specific value proposition
+- Outcome-focused
+
+**Subheadline**
+
+- Adds clarity or context
+- 1–2 sentences max
+
+**Primary CTA**
+
+- Action-oriented
+- Describes what the user gets
+
+---
+
+### Core Sections (Use as Appropriate)
+
+- Social proof (logos, stats, testimonials)
+- Problem / pain articulation
+- Solution & key benefits (3–5 max)
+- How it works (3–4 steps)
+- Objection handling (FAQ, comparisons, guarantees)
+- Final CTA with recap and risk reduction
+
+Avoid stacking features without narrative flow.
+
+---
+
+## Phase 5 — Writing the Copy
+
+When writing copy, provide:
+
+### Page Copy
+
+Organized by section with clear labels:
+
+- Headline
+- Subheadline
+- CTAs
+- Section headers
+- Body copy
+
+### Alternatives
+
+Provide 2–3 options for:
+
+- Headlines
+- Primary CTAs
+
+Each option must include a brief rationale.
+
+### Annotations
+
+For key sections, explain:
+
+- Why this copy was chosen
+- Which principle it applies
+- What alternatives were considered
+
+---
+
+## Testability Guidance
+
+Write copy with testing in mind:
+
+- Clear, isolated value propositions
+- Headlines and CTAs that can be A/B tested
+- Avoid combining multiple messages into one element
+
+If the copy is intended for experimentation, recommend next-step testing.
+
+---
+
+## Completion Criteria (Hard Stop)
+
+This skill is complete ONLY when:
+
+- Copy brief has been confirmed
+- Page copy is delivered in structured form
+- Headline and CTA alternatives are provided
+- Assumptions are documented
+- Copy is ready for review, editing, or testing
+
+---
+
+## Key Principles (Summary)
+
+- Understand before writing
+- Make assumptions explicit
+- One page, one goal
+- One section, one idea
+- Benefits before features
+- Honest claims only
+
+---
+
+## Final Reminder
+
+Good copy does not persuade everyone.
+It persuades **the right person** to take **the right action**.
+
+If the copy feels clever but unclear,  
+rewrite it until it feels obvious.
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.