@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/geo-fundamentals/SKILL.md

@@ -1,156 +1,93 @@
 ---
 name: geo-fundamentals
-description: Generative Engine Optimization for AI search engines (ChatGPT, Claude, Perplexity).
-allowed-tools: Read, Glob, Grep
+description: "Use when optimizing content for AI search engines (ChatGPT, Claude, Perplexity) using Generative Engine Optimization techniques and citation-worthy content patterns."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # GEO Fundamentals
 
-> Optimization for AI-powered search engines.
+## Purpose
 
----
-
-## 1. What is GEO?
-
-**GEO** = Generative Engine Optimization
-
-| Goal | Platform |
-|------|----------|
-| Be cited in AI responses | ChatGPT, Claude, Perplexity, Gemini |
-
-### SEO vs GEO
-
-| Aspect | SEO | GEO |
-|--------|-----|-----|
-| Goal | #1 ranking | AI citations |
-| Platform | Google | AI engines |
-| Metrics | Rankings, CTR | Citation rate |
-| Focus | Keywords | Entities, data |
-
----
+Use when optimizing content for AI search engines (ChatGPT, Claude, Perplexity) using Generative Engine Optimization techniques and citation-worthy content patterns.
 
-## 2. AI Engine Landscape
+## When to Use
 
-| Engine | Citation Style | Opportunity |
-|--------|----------------|-------------|
-| **Perplexity** | Numbered [1][2] | Highest citation rate |
-| **ChatGPT** | Inline/footnotes | Custom GPTs |
-| **Claude** | Contextual | Long-form content |
-| **Gemini** | Sources section | SEO crossover |
+- Optimizing content to be cited by AI search engines and LLM-powered tools.
+- Understanding the differences between traditional SEO and Generative Engine Optimization.
+- Creating content that performs well in RAG retrieval pipelines.
+- Configuring AI crawler access and structured data for LLM consumption.
+- Designing content strategies that work across both traditional and AI-powered search.
 
----
-
-## 3. RAG Retrieval Factors
-
-How AI engines select content to cite:
-
-| Factor | Weight |
-|--------|--------|
-| Semantic relevance | ~40% |
-| Keyword match | ~20% |
-| Authority signals | ~15% |
-| Freshness | ~10% |
-| Source diversity | ~15% |
+## Instructions
 
----
+1. Understand the AI search landscape — how Perplexity, ChatGPT, and Claude cite sources differently.
+2. Optimize for RAG retrieval factors — semantic relevance (~40%), keyword match (~20%), authority (~15%), freshness (~10%), diversity (~15%).
+3. Create citation-worthy content — original statistics, expert quotes, clear definitions, step-by-step guides, comparison tables.
+4. Implement technical GEO — schema markup, author credentials, AI crawler access, FAQ sections.
+5. Measure and iterate — track AI citation frequency and adapt content strategy.
 
-## 4. Content That Gets Cited
+### SEO vs GEO comparison
 
-| Element | Why It Works |
-|---------|--------------|
-| **Original statistics** | Unique, citable data |
-| **Expert quotes** | Authority transfer |
-| **Clear definitions** | Easy to extract |
-| **Step-by-step guides** | Actionable value |
-| **Comparison tables** | Structured info |
-| **FAQ sections** | Direct answers |
+| Aspect  | Traditional SEO            | Generative Engine Optimization      |
+| ------- | -------------------------- | ----------------------------------- |
+| Target  | Search engine results page | AI-generated answers                |
+| Goal    | Click-through from SERP    | Citation in AI response             |
+| Content | Keyword-optimized pages    | Citation-worthy, structured content |
+| Links   | Backlink building          | Authority signals for RAG           |
+| Schema  | For rich snippets          | For LLM understanding               |
 
----
+### Content patterns that get cited
 
-## 5. GEO Content Checklist
+- Original statistics and data points
+- Expert quotes with credentials
+- Clear, concise definitions
+- Step-by-step guides with numbered steps
+- Comparison tables with concrete data
+- Unique frameworks or methodologies
 
-### Content Elements
+### AI crawler user agents
 
-- [ ] Question-based titles
-- [ ] Summary/TL;DR at top
-- [ ] Original data with sources
-- [ ] Expert quotes (name, title)
-- [ ] FAQ section (3-5 Q&A)
-- [ ] Clear definitions
-- [ ] "Last updated" timestamp
-- [ ] Author with credentials
+| Crawler         | Engine             |
+| --------------- | ------------------ |
+| GPTBot          | ChatGPT / OpenAI   |
+| Claude-Web      | Claude / Anthropic |
+| PerplexityBot   | Perplexity         |
+| Google-Extended | Google AI features |
 
-### Technical Elements
+### GEO content checklist
 
-- [ ] Article schema with dates
-- [ ] Person schema for author
-- [ ] FAQPage schema
-- [ ] Fast loading (< 2.5s)
-- [ ] Clean HTML structure
+- Question-based titles and headings
+- Author credentials and expertise signals
+- FAQ sections with structured data
+- Article and FAQPage schema markup
+- Clear, quotable sentences in the first paragraph
+- Data-backed claims with sources
 
----
+### Constraints
 
-## 6. Entity Building
+- Never block AI crawlers unless there's a specific business reason.
+- Never create content solely for AI citation without user value.
+- Always maintain content accuracy — AI engines amplify both good and bad information.
+- Always include proper attribution for data and quotes.
 
-| Action | Purpose |
-|--------|---------|
-| Google Knowledge Panel | Entity recognition |
-| Wikipedia (if notable) | Authority source |
-| Consistent info across web | Entity consolidation |
-| Industry mentions | Authority signals |
+## Output Format
 
----
+Provide GEO audit findings, content optimization recommendations, schema markup, and crawler configuration guidance.
 
-## 7. AI Crawler Access
+## References
 
-### Key AI User-Agents
+No reference files for this skill right now.
 
-| Crawler | Engine |
-|---------|--------|
-| GPTBot | ChatGPT/OpenAI |
-| Claude-Web | Claude |
-| PerplexityBot | Perplexity |
-| Googlebot | Gemini (shared) |
-
-### Access Decision
-
-| Strategy | When |
-|----------|------|
-| Allow all | Want AI citations |
-| Block GPTBot | Don't want OpenAI training |
-| Selective | Allow some, block others |
-
----
-
-## 8. Measurement
-
-| Metric | How to Track |
-|--------|--------------|
-| AI citations | Manual monitoring |
-| "According to [Brand]" mentions | Search in AI |
-| Competitor citations | Compare share |
-| AI-referred traffic | UTM parameters |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Publish without dates | Add timestamps |
-| Vague attributions | Name sources |
-| Skip author info | Show credentials |
-| Thin content | Comprehensive coverage |
-
----
-
-> **Remember:** AI cites content that's clear, authoritative, and easy to extract. Be the best answer.
-
----
+## Scripts
 
-## Script
+No helper scripts are required for this skill right now.
 
-| Script | Purpose | Command |
-|--------|---------|---------|
-| `scripts/geo_checker.py` | GEO audit (AI citation readiness) | `python scripts/geo_checker.py <project_path>` |
+## Examples
 
+- "Optimize our documentation to be cited by AI search engines"
+- "Create a GEO content strategy for our developer blog"
+- "Configure AI crawler access and structured data for our site"

package/workflows/powers/git-workflow/POWER.md

@@ -0,0 +1,135 @@
+````markdown
+---
+inclusion: manual
+name: git-workflow
+description: "Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Git Workflow
+
+## Purpose
+
+Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards.
+
+## When to Use
+
+- Working on git workflow related tasks
+
+## Instructions
+
+1. **Choose a branching model** — trunk-based for high-velocity teams, short-lived feature branches for teams needing review gates.
+2. **Keep branches short-lived** — merge within 1-2 days. Long-lived branches create merge pain and integration risk.
+3. **Write meaningful commits** — each commit should be a logical, reviewable unit. Squash fixup commits before merge.
+4. **Review before merge** — every change to protected branches goes through PR review. No direct pushes.
+5. **Automate what you can** — branch protection, CI gating, auto-merge on approval, changelog generation.
+
+### Branching strategies
+
+### Trunk-based development (recommended)
+
+- All developers commit to `main` (directly or via short-lived branches).
+- Feature branches live for hours to 1-2 days, never weeks.
+- Use feature flags for incomplete work that must be merged.
+- Release from `main` via tags or release branches cut at the moment of release.
+- Best for: teams with strong CI, continuous deployment capability.
+
+### GitHub Flow
+
+- `main` is always deployable.
+- Create feature branches from `main`, open PR, review, merge back.
+- Deploy from `main` after merge.
+- Simpler than GitFlow. No develop branch, no release branches unless needed.
+- Best for: SaaS products with single production environment.
+
+### Release branches (when needed)
+
+- Cut `release/X.Y` from `main` when preparing a release.
+- Cherry-pick critical fixes to release branch. Never merge `main` into release.
+- Tag releases from the release branch.
+- Delete release branch after final patch version.
+
+### Commit conventions
+
+### Conventional Commits
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer]
+```
+
+Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`.
+
+- `feat`: new feature visible to users → triggers minor version bump.
+- `fix`: bug fix → triggers patch version bump.
+- `feat!` or `BREAKING CHANGE:` footer → triggers major version bump.
+
+### Commit message rules
+
+- Subject line: imperative mood, under 72 characters, no period.
+- Body: explain WHY, not WHAT (the diff shows what changed).
+- One logical change per commit. Do not mix refactoring with behavior changes.
+
+### Pull request standards
+
+- Title follows conventional commit format.
+- Description includes: what changed, why it changed, how to test.
+- Link related issues with `Closes #123` or `Fixes #456`.
+- Keep PRs under 400 lines of meaningful change. Split larger work into stacked PRs.
+- Request review from domain owners, not random team members.
+
+### Merge strategy
+
+| Strategy     | When to use                                                         |
+| ------------ | ------------------------------------------------------------------- |
+| Squash merge | Default for feature PRs — clean single-commit history on main.      |
+| Merge commit | When preserving individual commits matters (multi-author, long PR). |
+| Rebase merge | When linear history is required and branch is small/clean.          |
+
+- Configure repository default in GitHub settings.
+- Delete branches after merge — do not accumulate stale branches.
+
+### Protected branch rules
+
+- [ ] Require PR reviews (minimum 1 reviewer)
+- [ ] Require status checks to pass (CI, lint, test)
+- [ ] Require branches to be up to date before merge
+- [ ] Disable force push to `main` and release branches
+- [ ] Require signed commits (optional but recommended for regulated environments)
+- [ ] Enable merge queue for high-traffic repositories
+
+### Constraints
+
+- Avoid long-lived feature branches (>3 days) — merge pain grows exponentially.
+- Avoid merge commits from `main` into feature branches — rebase instead.
+- Avoid commit messages like "fix", "wip", "stuff" — they provide no value in history.
+- Avoid bypassing CI checks with `--no-verify` — fix the issue instead.
+- Avoid cherry-picking without tracking — document which commits were cherry-picked and why.
+- Avoid force-pushing to shared branches — coordinate with collaborators first.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                | Purpose                                                                                             |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/pr-review-checklist.md` | Code review process, reviewer responsibilities, approval criteria, and common review anti-patterns. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with git workflow best practices in this project"
+- "Review my git workflow implementation for issues"
+````

package/workflows/powers/git-workflow/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: git-workflow
+description: "Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Git Workflow
+
+## Purpose
+
+Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards.
+
+## When to Use
+
+- Working on git workflow related tasks
+
+## Instructions
+
+1. **Choose a branching model** — trunk-based for high-velocity teams, short-lived feature branches for teams needing review gates.
+2. **Keep branches short-lived** — merge within 1-2 days. Long-lived branches create merge pain and integration risk.
+3. **Write meaningful commits** — each commit should be a logical, reviewable unit. Squash fixup commits before merge.
+4. **Review before merge** — every change to protected branches goes through PR review. No direct pushes.
+5. **Automate what you can** — branch protection, CI gating, auto-merge on approval, changelog generation.
+
+### Branching strategies
+
+### Trunk-based development (recommended)
+
+- All developers commit to `main` (directly or via short-lived branches).
+- Feature branches live for hours to 1-2 days, never weeks.
+- Use feature flags for incomplete work that must be merged.
+- Release from `main` via tags or release branches cut at the moment of release.
+- Best for: teams with strong CI, continuous deployment capability.
+
+### GitHub Flow
+
+- `main` is always deployable.
+- Create feature branches from `main`, open PR, review, merge back.
+- Deploy from `main` after merge.
+- Simpler than GitFlow. No develop branch, no release branches unless needed.
+- Best for: SaaS products with single production environment.
+
+### Release branches (when needed)
+
+- Cut `release/X.Y` from `main` when preparing a release.
+- Cherry-pick critical fixes to release branch. Never merge `main` into release.
+- Tag releases from the release branch.
+- Delete release branch after final patch version.
+
+### Commit conventions
+
+### Conventional Commits
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer]
+```
+
+Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`.
+
+- `feat`: new feature visible to users → triggers minor version bump.
+- `fix`: bug fix → triggers patch version bump.
+- `feat!` or `BREAKING CHANGE:` footer → triggers major version bump.
+
+### Commit message rules
+
+- Subject line: imperative mood, under 72 characters, no period.
+- Body: explain WHY, not WHAT (the diff shows what changed).
+- One logical change per commit. Do not mix refactoring with behavior changes.
+
+### Pull request standards
+
+- Title follows conventional commit format.
+- Description includes: what changed, why it changed, how to test.
+- Link related issues with `Closes #123` or `Fixes #456`.
+- Keep PRs under 400 lines of meaningful change. Split larger work into stacked PRs.
+- Request review from domain owners, not random team members.
+
+### Merge strategy
+
+| Strategy     | When to use                                                         |
+| ------------ | ------------------------------------------------------------------- |
+| Squash merge | Default for feature PRs — clean single-commit history on main.      |
+| Merge commit | When preserving individual commits matters (multi-author, long PR). |
+| Rebase merge | When linear history is required and branch is small/clean.          |
+
+- Configure repository default in GitHub settings.
+- Delete branches after merge — do not accumulate stale branches.
+
+### Protected branch rules
+
+- [ ] Require PR reviews (minimum 1 reviewer)
+- [ ] Require status checks to pass (CI, lint, test)
+- [ ] Require branches to be up to date before merge
+- [ ] Disable force push to `main` and release branches
+- [ ] Require signed commits (optional but recommended for regulated environments)
+- [ ] Enable merge queue for high-traffic repositories
+
+### Constraints
+
+- Avoid long-lived feature branches (>3 days) — merge pain grows exponentially.
+- Avoid merge commits from `main` into feature branches — rebase instead.
+- Avoid commit messages like "fix", "wip", "stuff" — they provide no value in history.
+- Avoid bypassing CI checks with `--no-verify` — fix the issue instead.
+- Avoid cherry-picking without tracking — document which commits were cherry-picked and why.
+- Avoid force-pushing to shared branches — coordinate with collaborators first.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                | Purpose                                                                                             |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/pr-review-checklist.md` | Code review process, reviewer responsibilities, approval criteria, and common review anti-patterns. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with git workflow best practices in this project"
+- "Review my git workflow implementation for issues"

package/workflows/powers/git-workflow/references/pr-review-checklist.md

@@ -0,0 +1,63 @@
+# PR Review Checklist
+
+## Reviewer responsibilities
+
+Before approving, verify each area:
+
+### Correctness
+
+- [ ] Does the code do what the PR description says it does?
+- [ ] Are edge cases handled (empty input, null, boundary values)?
+- [ ] Are error states handled appropriately (not swallowed, not over-caught)?
+- [ ] Does the logic match the linked issue or acceptance criteria?
+
+### Security
+
+- [ ] No secrets, tokens, or credentials in the code
+- [ ] User input is validated and sanitized at system boundaries
+- [ ] No SQL injection, XSS, or command injection vectors
+- [ ] Auth checks are present for protected operations
+- [ ] No PII logged or exposed in error messages
+
+### Performance
+
+- [ ] No N+1 queries or unbounded loops
+- [ ] No unnecessary re-renders in UI components
+- [ ] Large data sets are paginated, not loaded entirely
+- [ ] Expensive operations are cached or debounced where appropriate
+
+### Maintainability
+
+- [ ] Code is readable without extensive comments
+- [ ] Names are clear and consistent with codebase conventions
+- [ ] No dead code, commented-out code, or TODO without tracking issue
+- [ ] Test coverage exists for new behavior and critical paths
+
+### Architecture
+
+- [ ] Changes follow existing patterns in the codebase
+- [ ] No unnecessary abstractions or premature generalization
+- [ ] Dependencies are justified (not adding a library for one function)
+- [ ] Public API surface changes are intentional and documented
+
+## Review anti-patterns to avoid
+
+- **Rubber-stamping**: approving without reading — undermines the entire review process.
+- **Nitpicking style**: formatting fights belong in linters, not reviews.
+- **Rewriting in review**: if the approach is fundamentally wrong, say so early — don't micro-edit via 50 comments.
+- **Blocking on taste**: if the code works, is readable, and follows conventions, approve it even if you would have written it differently.
+- **Delayed reviews**: review within 4 hours during business hours. Stale PRs kill velocity.
+
+## When to request changes vs. comment
+
+- **Request changes**: correctness bugs, security issues, missing tests for critical paths.
+- **Comment (non-blocking)**: style suggestions, alternative approaches, minor improvements that can be done later.
+- **Approve with comments**: minor nits that do not block merge.
+
+## Stacked PR review
+
+When PRs are stacked (PR 2 depends on PR 1):
+
+1. Review PR 1 first. Approve and merge before deep-reviewing PR 2.
+2. Reviewer should check the diff against the base branch, not the full stack.
+3. Author should rebase the stack after each merge, not merge `main` into feature branches.

package/workflows/powers/golang-pro/POWER.md

@@ -5,55 +5,66 @@ name: "golang-pro"
 description: "Use for modern Go services and tooling with Go 1.26-era language/runtime patterns, concurrency safety, and production operations."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "go"
-  baseline: "Go 1.26"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Golang Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern Go development covering APIs, workers, CLIs, and microservices. Focuses on explicit error handling, context-propagated concurrency, generics where they simplify, and production profiling discipline.
+
+## When to Use
 
 - Building APIs, workers, CLIs, and microservices in Go.
-- Designing concurrency with goroutines/channels/context.
-- Optimizing latency, allocations, and reliability.
+- Designing concurrency patterns with goroutines, channels, and context.
+- Optimizing latency, allocations, and reliability in Go services.
+
+## Instructions
+
+1. **Define package boundaries and interfaces** — keep interfaces small and accept them where consumed, not where implemented. Prefer composition over deep inheritance-like abstractions.
+
+2. **Pass `context.Context` as the first parameter** in all APIs that cross network or scheduling boundaries. Do not store contexts in structs because they represent request-scoped lifetimes.
+
+3. **Handle every error with actionable wrapping** — wrap with `%w` for traceable error chains. Define sentinel errors for well-known failure conditions. Use custom error types when errors carry structured context. Do not discard errors silently; document any intentional discard with a comment. Do not use stringly-typed error comparisons (`err.Error() == "something"`) because sentinel values and type assertions are safer and refactor-proof.
+
+4. **Design concurrency with clear ownership** — use channels for ownership transfer, not shared mutation. Choose sync primitives (`Mutex`, `RWMutex`, `atomic`) deliberately. Keep goroutine lifecycles bounded with cancellation via `select` with `ctx.Done()`. Bound worker pools with fixed goroutine counts reading from a shared channel. Use `errgroup.Group` for coordinated fan-out with shared error propagation.
+
+5. **Use generics where they simplify** — generics serve well when the abstraction covers 3+ distinct types. Prefer concrete types when a function has only one or two callers because generics add cognitive cost. Avoid deeply nested type parameter lists; if a generic needs 4+ parameters, break it into smaller pieces.
+
+6. **Test with table-driven subtests and race detection** — use `t.Run` for systematic input coverage. Run `go test -race -count=1 ./...` in CI. Use `httptest.NewServer` for HTTP handler tests. Use `t.Cleanup()` for teardown. Use `testing.B` benchmarks with `b.ReportAllocs()` to prove optimization impact.
+
+7. **Lint and format consistently** — use `golangci-lint` with `govet`, `staticcheck`, `errcheck`, `gosec`, and `revive` at minimum. Enforce `gofmt`/`goimports` in CI. Use `gofumpt` for stricter formatting.
+
+8. **Thread observability through the stack** — use structured logs with request IDs and trace context. Make cancellation, retries, and deadlines visible in logging. Reproduce concurrency issues with race tests and deterministic fixtures first.
 
-## Core workflow
+9. **Profile before optimizing** — benchmark hot paths with `testing.B` and `b.ReportAllocs()`. Use `pprof` (CPU, heap, goroutine, block, mutex) for production profiling. Do not fire-and-forget goroutines without a cancellation path because they leak resources. Do not use panic-based control flow because it circumvents explicit error handling. Do not create over-generalized interfaces without real callers because they add indirection without value.
 
-1. Define package boundaries and interfaces.
-2. Implement with explicit error handling and context propagation.
-3. Add tests and race checks for behavior under load.
-4. Profile before optimization.
+10. **Build for production** — use `go build -trimpath -ldflags='-s -w'` for release binaries. Keep `go.mod` tidy. Use `ko` or multi-stage Docker for container builds.
 
-## Baseline standards
+## Output Format
 
-- Keep APIs context-aware: pass `context.Context` first.
-- Handle every error with actionable wrapping.
-- Use table-driven tests and subtests for logic coverage.
-- Run `go test -race` for concurrency-sensitive paths.
-- Prefer composition over deep inheritance-like abstractions.
+Produces Go code following standard project layout with explicit error handling, context propagation, and bounded concurrency patterns. Includes table-driven tests and structured error types where applicable.
 
-## Implementation guidance
+## References
 
-- Use channels for ownership transfer, not shared mutation.
-- Choose sync primitives deliberately (`Mutex`, `RWMutex`, `atomic`).
-- Keep goroutine lifecycles bounded with cancellation.
-- Use generics where they simplify, not where they obscure.
-- Benchmark hot paths (`testing.B`, `pprof`) before tuning.
+| File                              | Load when                                                                     |
+| --------------------------------- | ----------------------------------------------------------------------------- |
+| `references/concurrency.md`       | Concurrency ownership, channels, mutexes, or cancellation safety need detail. |
+| `references/generics.md`          | Generics tradeoffs or reusable type-safe helpers are in scope.                |
+| `references/interfaces.md`        | Interface boundaries and package seams need review.                           |
+| `references/testing.md`           | Test strategy, race checks, or benchmark setup is needed.                     |
+| `references/project-structure.md` | Package layout or service/module decomposition needs guidance.                |
 
-## Avoid
+## Scripts
 
-- Fire-and-forget goroutines without cancellation path.
-- Panic-based control flow.
-- Over-generalized interfaces without real callers.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Reference files
+## Examples
 
-- `references/concurrency.md`
-- `references/generics.md`
-- `references/interfaces.md`
-- `references/testing.md`
-- `references/project-structure.md`
+- "Design the error handling strategy for this Go API service with custom error types and middleware-based error mapping."
+- "Refactor this unbounded goroutine fan-out into a bounded worker pool with context cancellation."
+- "Set up a table-driven test suite for this parser with race detection and benchmark coverage."
 ````