opencode-skills-collection 4.0.69 → 4.0.70

package/bundled-skills/apify-integration-development/references/workflow-automation.md

@@ -0,0 +1,163 @@
+# Workflow automation integrations
+
+Design guide for integrating Apify into a workflow-automation platform (Zapier, n8n, Make, Pipedream, Activepieces, or a similar trigger/action/search host). This file is **UX-design focused and platform-agnostic**: it describes the capability surface, the resource model, and the user-facing behavior, not the host platform's internal build mechanics, release pipeline, or secrets. Apply the cross-cutting rules from `SKILL.md` on top.
+
+The host platform's model is rigid: every Apify capability must be expressed as one of **trigger**, **action (create)**, or **search (read)**. Decide the mapping before writing any code.
+
+## 1. Map Apify to the host's trigger / action / search model
+
+| Host type | Apify capability | Purpose |
+|---|---|---|
+| **Trigger** (hook) | Actor / Task run finished | Event-driven: start a workflow when a run reaches a terminal status |
+| **Trigger** (hidden, polling) | List Actors / Tasks | Back dynamic dropdowns - not user-facing steps |
+| **Action (create)** | Run Actor; Run Task; Run Actor + get dataset; Run Task + get dataset; Scrape single URL; Set KV record | Synchronous operations that produce or store data |
+| **Search (read)** | Get last run; Get run; List runs; Get dataset items; Get KV record | Find existing records, optionally branch on them |
+
+Reads of the last run or stored data are **searches**, because that is the host's mechanism for "find an existing record." Run-finished is a **webhook trigger**. Actor/Task *selection* is a **hidden trigger** that feeds dropdowns - reusing one hidden trigger across multiple actions keeps the surface DRY.
+
+## 2. Canonical capability matrix
+
+The complete set of operations a workflow integration should surface. Treat this as the floor, not a menu to trim without reason.
+
+**Triggers**
+- Actor run finished (webhook; user picks terminal statuses: SUCCEEDED / FAILED / TIMED-OUT / ABORTED)
+- Task run finished (same shape, scoped to a Task)
+
+**Actions (creates)**
+- Run Actor - fire an Actor run
+- Run Actor and get dataset items - fire and return results inline
+- Run Task - fire a saved Task configuration
+- Run Task and get dataset items - fire and return results inline
+- Scrape single URL - curated, 2-field wrapper over a content scraper (see section 10)
+- Set key-value store record - write a file/string to a KV store
+
+**Searches (reads)**
+- Get last Actor/Task run - the most recent matching run
+- Get run - by run ID
+- List runs - filterable by status
+- Get dataset items - by dataset ID, with offset/limit and optional fields/omit
+- Get key-value store record - by store ID + record key
+
+**Hidden selectors (back dropdowns, not user steps)**
+- List Actors (recently used source + Store source)
+- List Tasks
+
+If the host platform cannot represent every operation, prioritize in this order: run-finished trigger, run Actor + get dataset, get dataset items, scrape single URL, run Task + get dataset, get KV record, set KV record.
+
+## 3. Resource -> operation organization
+
+Organize the action node's surface as **resource -> operation**, mirroring both the host platform's UX convention and Apify's domain model. A two-level router (resource, then operation) keeps adding an operation a copy-and-adapt task and co-locates each operation's parameters and I/O. Users navigate Actor -> "Run actor", Dataset -> "Get items", etc. Avoid a flat list of dozens of operations.
+
+## 4. Actor / Task selection UX
+
+IDs (Actor, Task, run, dataset, KV store, record key) should use the host's resource-locator property type with multiple modes: **From list**, **By URL**, **By ID**. Extract the ID from a pasted Console URL (e.g. `https://console.apify.com/actors/<id>/input` -> `<id>`).
+
+Offer **two selection sources** in one selector:
+- **Recently used** (default) - the user's own Actors/Tasks, sorted by last run started. This is what most users want.
+- **Store** - browse the public marketplace by search term, sorted by popularity.
+
+A toggle with "recompute fields when changed" lets users switch the dropdown source without leaving the node. Choose a pagination limit that balances completeness against load time (the host UI must support searching within dropdown results).
+
+## 5. Dynamic input translation
+
+The highest-leverage UX piece. When a user selects an Actor, fetch the Actor's build and translate its `inputSchema` into the host platform's form fields dynamically. Hardcoding fields per Actor is unmaintainable across thousands of Actors; a translator supports *any* Actor's input as a host form.
+
+Handle the type/editor mappings that have no direct host equivalent, and degrade gracefully rather than crashing:
+
+| Apify type/editor | Host field |
+|---|---|
+| `string` + `javascript`/`python` editor | code field |
+| `string` + `textarea` | multiline text |
+| `string` + `datepicker` | datetime |
+| `string` + `select` / `enum` / `enumSuggestedValues` | choices dropdown |
+| `isSecret: true` | password |
+| `array` + `json`/`keyValue` editor | multiline text with a JSON.stringify default |
+| `array` + `requestListSources`/`pseudoUrls`/`globs`/`stringList` | flat string list (re-expand at run time) |
+| `object` + `proxy` editor | info box telling users to set it in Apify Console (host has no proxy UI) |
+| `object` + `schemaBased` | nested children fields |
+| `sectionCaption` | helpText/info box (host has no stackable sections) |
+
+Two gotchas:
+- On list fields, a `default` would pre-populate a non-removable first item and duplicate entries - move prefill values to `placeholder`.
+- Mark the build selector so a build-tag change **recomputes the generated fields**, since input schemas can differ across builds.
+
+## 6. Run UX: sync vs async, cost caps, bounded polling
+
+Offer a **sync/async toggle** on run-start actions:
+- Sync: block until the run finishes (document the host's hard timeout so users know when to choose async).
+- Async: return immediately with the run ID for long-running jobs.
+
+Use the asynchronous REST flow under the hood (POST /runs with `waitForFinish=0`, then poll). Polling must be **bounded** - use the run's own `timeoutSecs` + a grace buffer, with an absolute ceiling fallback (e.g. 24h). Poll at a fixed interval (e.g. 1s). "Run actor and get dataset" must additionally require `status === 'SUCCEEDED'` before fetching dataset items.
+
+Every run-start action exposes a **Maximum Cost per Run** field (`maxTotalChargeUsd`), `min: 0`, default `null`. Send it as a query parameter only when non-null and `> 0`; `0`/empty means *no limit*. Never let this be an Actor input field.
+
+## 7. Output normalization into one enriched shape
+
+Bare Actor run objects contain only storage IDs, not results - useless downstream. Enrich every run once, centrally, into a single shape returned by all run-producing and run-finding actions:
+
+- The run's `OUTPUT` from the default key-value store (and any user-selected store keys).
+- `datasetItems` - up to a sensible cap (e.g. 100 items) from the default dataset.
+- `datasetItemsFileUrls` - pre-built download URLs for JSON/CSV/XML/XLSX/HTML/RSS exports.
+- `detailsPageUrl` - a deep link to the run in Apify Console.
+- Strip fields useless to host users (`meta`, `stats`, `options`, `userId`, raw `output`, `standby`).
+
+Downstream steps map fields by name regardless of which action produced the run, because every action yields the same shape. Describe this shape to the host UI with sampled output fields (sample ~10 items, merge their keys).
+
+## 8. Guard against large datasets
+
+Estimate the full download size before inlining: fetch one item, multiply by the requested item count with a safety margin (e.g. 1.2x), compare to a payload cap (e.g. 10 MB). If it exceeds the cap, **do not attempt the inline download** - return a warning item plus the dataset file URLs. When a trigger fetches more items than the cap allows, push a warning pointing users to the "Get Dataset Items" action with `run.defaultDatasetId` for full results. The host platform has payload/time limits the Apify API does not; always offer a file-download fallback.
+
+## 9. Files and binary records
+
+Map the host's file-handling primitives (dehydration / stashing / signed URLs) to Apify's binary KV records. For "Get KV record":
+- JSON/text under a size threshold (e.g. 20 MB) -> parsed and returned as fields the user can map directly.
+- Binary or larger records -> a dehydrated pointer the host lazily fetches when a downstream step needs it.
+- Records above a hard limit (e.g. 120 MB, with margin below the host's 150 MB ceiling) -> rejected outright with an actionable message.
+
+## 10. Run-finished trigger UX
+
+Use the host's hook type backed by Apify webhooks:
+- **Subscribe**: create an Apify webhook scoped to an `actorId` or `actorTaskId`, with `eventTypes` from the user-selected terminal statuses. The webhook's `requestUrl` is the host's target URL. Make registration **idempotent** - derive a key from every field that distinguishes one registration from another (`resource:id:sortedEvents:requestUrl`) so re-activating a workflow does not create duplicate webhooks. Persist the created webhook ID so deactivation can delete it.
+- **Unsubscribe**: delete the webhook by its stored ID.
+- **Perform**: read the webhook payload and enrich it (section 7).
+- **Fallback list**: fetch the 3 most recent matching runs so users see realistic test data when configuring the trigger without waiting for a real event.
+
+Offer an event multi-select (SUCCEEDED / FAILED / TIMED-OUT / ABORTED) plus an "any" shortcut that expands to all four. Build the `condition: { actorId }` or `{ actorTaskId }` from the watched resource. Pass the webhook payload through as workflow data - it already carries the run metadata.
+
+## 11. Error UX
+
+Centralize API error mapping in one place, not per action. Match each Apify error to the host's error category:
+- 5xx and 429 -> retryable (so backoff applies).
+- `token-not-found` / auth errors -> an authentication error the user must fix.
+- `full-permission-actor-not-approved` -> a non-retryable error with the **validated** approval URL in the message (approval is a manual Console action; retrying cannot help).
+- 404 on KV record GET/HEAD -> return empty rather than throw (a missing key is a valid "no data" result).
+- Other 4xx -> a plain error with the API's actual message, or a generic fallback.
+
+Use retryable errors only when retrying can actually succeed. Keep error *codes* (like `EPERM`) out of any message field the host replaces, so the real text survives.
+
+## 12. Auth UX
+
+For consumer-facing automation platforms, prefer **OAuth2 with PKCE** over an API-token field. Users authorize through a browser; no raw token typing. Disable auto-refresh only if the host cannot surface a refresh failure gracefully - otherwise leave it on. Validate the token with a `GET /v2/users/me` test call and populate the connection label with the username/email.
+
+If the host is headless-only, fall back to an API-token credential with the same verify call on a "Verify" button.
+
+## 13. Convenience operations: "Scrape single URL"
+
+Beyond generic "run Actor", ship a curated **Scrape single URL** action: a 2-field form (`url`, `outputFormat`) wrapping a content scraper with sensible defaults (`maxCrawlDepth: 0`, `maxResults: 1`). Validate the URL first (`new URL()` + protocol + hostname check) with an actionable error - bad input must never start a paid run. Return a **lean, single-object** output: `{ ...pageMetadata, [outputFormat]: content }` - strip all content variants and re-add only the chosen one. This is ideal for LLM flows (a single object beats a dataset array) and lowers the barrier for non-power users. Point power users to the underlying Actor for advanced options.
+
+## Definition-of-done checklist
+
+- [ ] Capability matrix from section 2 is fully surfaced (or trimmed with documented reason).
+- [ ] Resource -> operation organization; no flat operation soup.
+- [ ] Actor/Task selection offers recently-used + Store sources with URL/ID extraction.
+- [ ] Actor input is translated dynamically from the build schema; degradation is graceful.
+- [ ] Run actions expose sync/async toggle and a `maxTotalChargeUsd` field (null = unlimited).
+- [ ] Polling is bounded; never `while (true)`.
+- [ ] All run-producing and run-finding actions return the one enriched run shape.
+- [ ] Large-dataset guard with file-URL fallback is in place.
+- [ ] Run-finished trigger is webhook-backed, idempotent, and has fallback sample data.
+- [ ] Error mapping is centralized; approval URLs are validated; codes don't clobber messages.
+- [ ] OAuth2 PKCE is the default consumer auth path; token fallback has a verify call.
+- [ ] A "Scrape single URL"-style convenience action exists with pre-run URL validation.
+- [ ] `x-apify-integration-platform` header is sent on every outbound request; `x-apify-integration-origin: apify-integration-development-skill` included if built from this skill.
+- [ ] Two test modes (mocked + live E2E) pass.

package/bundled-skills/architecture-review/README.md

@@ -0,0 +1,42 @@
+# Architecture Review
+
+This is an official Ontoly Agent Skill. It is independently installable and teaches an agent how to use Ontoly for architecture review.
+
+## Version
+
+- Skill version: 1.0.0
+- Minimum Ontoly version: 1.0.0
+- Required capabilities: `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies`, `EvidencePack`
+- Enhancement: LLM Enhancement
+- Deprecated: no
+
+## Install
+
+Install this skill with any Agent Skills compatible installer that supports `SKILL.md` directories, or copy this folder into your agent skills directory.
+
+## Use
+
+Ask the agent a task such as:
+
+> What are the primary packages, modules, and services?
+
+The agent should build or verify the Ontoly graph, use MCP capabilities, cite evidence, and only inspect files as a fallback.
+
+## Public Docs
+
+- [Agent Skills](https://ontoly.xyz/docs/agent-skills)
+- [Skills Overview](https://ontoly.xyz/docs/skills-overview)
+- [MCP](https://ontoly.xyz/docs/mcp)
+- [Capabilities](https://ontoly.xyz/docs/capabilities)
+- [Skills Validation](https://ontoly.xyz/docs/skills-validation)
+
+## Shared References
+
+This skill depends on the shared Ontoly workflow in [reference/workflow.md](reference/workflow.md).
+
+## Learn more
+
+- Documentation: https://ontoly.xyz/docs
+- This skill on the web: https://ontoly.xyz/skills#architecture-review
+- All Ontoly Agent Skills: https://ontoly.xyz/skills
+- Install via skills.sh: https://www.skills.sh/?q=0xsarwagya/ontoly

package/bundled-skills/architecture-review/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: architecture-review
+description: Review repository architecture using Ontoly Software Graph and MCP capabilities.
+  Use when asked to explain architecture, module boundaries, package topology, service
+  ownership, or architectural risk.
+license: AGPL-3.0-only
+compatibility: Portable Agent Skills format; requires Ontoly CLI and MCP-capable or
+  CLI-capable coding agent.
+metadata:
+  ontoly.skill.version: 1.3.3
+  ontoly.min.version: 1.3.3
+  ontoly.capabilities: ExplainArchitecture, GraphStatistics, FindCycles, FindDependencies,
+    EvidencePack
+  ontoly.category: architecture
+  ontoly.enhancement: LLM Enhancement
+  ontoly.deprecated: 'false'
+source_repo: 0xsarwagya/ontoly
+source_type: community
+source: community
+date_added: '2026-09-21'
+risk: unknown
+---
+## When to Use
+- Use when this upstream workflow matches the user's stated goal.
+- Use when the task requires the procedures documented in this skill.
+
+# Architecture Review
+
+Use this skill when the user asks for architecture review using Ontoly evidence.
+
+## Required Workflow
+
+Follow [the shared Ontoly workflow. Also read [graph evidence rules, [MCP usage, [best practices, and [fallback rules when the task requires detail.
+
+## Ontoly Capabilities
+
+Use these capabilities first: `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies`, `EvidencePack`.
+
+## Output Contract
+
+Return:
+
+- answer or plan
+- capabilities invoked
+- graph evidence with node ids, edge types, source spans, and graph hash when available
+- confidence: high, medium, or low
+- fallback reason if repository files were inspected
+
+## Boundaries
+
+Do not implement compiler, query, MCP, SDK, or business logic in the skill. Do not search repository files until Ontoly cannot answer or evidence must be confirmed.
+
+## Resources
+
+- [Examples
+- [Prompt template
+- [Capability notes
+
+## Learn more
+
+- Documentation: https://ontoly.xyz/docs
+- This skill on the web: https://ontoly.xyz/skills#architecture-review
+- All Ontoly Agent Skills: https://ontoly.xyz/skills
+- Install via skills.sh: https://www.skills.sh/?q=0xsarwagya/ontoly
+
+
+## Examples
+
+```text
+User: Apply this skill to my current task.
+Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.
+```
+
+## Limitations
+
+- Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
+- Does not replace environment-specific validation, testing, or maintainer review.

package/bundled-skills/architecture-review/examples.md

@@ -0,0 +1,11 @@
+# Architecture Review Examples
+
+Each example is graph-first and MCP-first.
+
+| Repository | Questions | Expected workflow | Capabilities invoked | Expected evidence | Expected answer |
+| --- | --- | --- | --- | --- | --- |
+| Ovok Core | Trace the login flow through the NestJS auth controller. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `GraphStatistics` then `FindCycles` then `FindDependencies`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies` | controller, route, service, dependency-injection edges; graph hash; confidence. | A concise architecture summary with graph-backed boundaries, risks, evidence node ids, and confidence. |
+| Ghost | Explain the package entrypoint and public API surface. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `GraphStatistics` then `FindCycles` then `FindDependencies`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies` | package, exports, functions, interfaces; graph hash; confidence. | A concise architecture summary with graph-backed boundaries, risks, evidence node ids, and confidence. |
+| durable-local | Find storage APIs and consumers before a refactor. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `GraphStatistics` then `FindCycles` then `FindDependencies`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies` | functions, interfaces, dependents, configuration; graph hash; confidence. | A concise architecture summary with graph-backed boundaries, risks, evidence node ids, and confidence. |
+| 0xsarwagya | Summarize workspace packages and package dependencies. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `GraphStatistics` then `FindCycles` then `FindDependencies`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies` | workspace, packages, framework nodes, dependency edges; graph hash; confidence. | A concise architecture summary with graph-backed boundaries, risks, evidence node ids, and confidence. |
+| Innosphere | Identify application modules and request ownership. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `GraphStatistics` then `FindCycles` then `FindDependencies`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies` | controllers, modules, routes, services; graph hash; confidence. | A concise architecture summary with graph-backed boundaries, risks, evidence node ids, and confidence. |

package/bundled-skills/architecture-review/reference/best-practices.md

@@ -0,0 +1,7 @@
+# Agent Best Practices
+
+- Keep the answer graph-first and concise.
+- Separate measured graph facts from inference.
+- Prefer capability output over source search.
+- Include confidence: high when graph nodes and relationships directly answer the question, medium when evidence is partial, low when fallback file inspection was required.
+- Never generate SDKs, refactors, or security claims from the skill itself. The skill may plan workflows, but Ontoly remains the source of truth.

package/bundled-skills/architecture-review/reference/capabilities.md

@@ -0,0 +1,20 @@
+# Architecture Review Capability Notes
+
+Primary capabilities: `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies`, `EvidencePack`.
+
+Use [../reference/mcp.md](../reference/mcp.md) for common capability behavior and fallback CLI equivalents.
+
+## Required Evidence
+
+- capability name
+- graph hash
+- node ids and types
+- relationship types and direction
+- source spans when present
+- confidence
+
+## Compatibility
+
+- Skill version: 1.0.0
+- Minimum Ontoly version: 1.0.0
+- Deprecation status: active

package/bundled-skills/architecture-review/reference/fallbacks.md

@@ -0,0 +1,11 @@
+# Fallbacks
+
+Fallbacks are allowed only after Ontoly is insufficient. Valid fallback reasons:
+
+- graph artifact missing and build fails
+- relevant capability unavailable
+- graph trust below the task threshold
+- node is ambiguous or absent
+- source quote is needed to confirm a public answer
+
+When falling back, state the reason and keep inspection narrow: one file, one symbol, or one source span when possible.

package/bundled-skills/architecture-review/reference/graph.md

@@ -0,0 +1,15 @@
+# Software Graph Evidence
+
+Use Software Graph evidence as the primary source of truth. Prefer deterministic identifiers over prose names.
+
+Evidence fields to capture:
+
+- graph hash
+- capability invoked
+- node id and node type
+- edge type and direction
+- source span when present
+- diagnostic codes when relevant
+- confidence and reason for confidence
+
+Do not infer relationships that are absent from the graph. You may make a clearly labeled inference only after stating the graph evidence that supports it.

package/bundled-skills/architecture-review/reference/mcp.md

@@ -0,0 +1,14 @@
+# Ontoly MCP Usage
+
+Use Ontoly MCP capabilities before searching files. Common capability groups:
+
+- Architecture: `ExplainArchitecture`, `GraphStatistics`
+- Lookup: `FindNode`, `FindFunction`, `InspectFile`, `InspectModule`, `InspectClass`, `InspectFunction`
+- Dependencies: `FindDependencies`, `FindDependents`, `FindCycles`, `ImpactAnalysis`
+- Requests: `TraceRequestLifecycle`, `FindResponsibleFunction`, `TraceExecution`
+- Security: `FindAuthenticationFlow`, `FindConfigurationUsage`
+- Configuration: `FindConfiguration`, `FindConfigurationUsage`
+- Static analysis: `FindDeadCode`, `FindUnusedFeature`, `FindEntrypoints`
+- Evidence packs: `EvidencePack`
+
+If an agent cannot call MCP directly, use the nearest CLI command such as `ontoly evidence`, `ontoly report`, `ontoly query`, `ontoly trace`, or `ontoly inspect`.

package/bundled-skills/architecture-review/reference/workflow.md

@@ -0,0 +1,15 @@
+# Ontoly Agent Skill Standard Workflow
+
+Every Ontoly skill follows this workflow. Skills teach orchestration only; Ontoly provides the software understanding.
+
+LLM Enhancement is mandatory every time Ontoly is used by an LLM. An LLM-facing workflow must use an Ontoly skill or equivalent installed workflow that declares `ontoly.enhancement: "LLM Enhancement"` and preserves graph-first evidence, confidence, and fallback rules.
+
+1. Verify that an Ontoly graph exists at `.ontoly/SoftwareGraph.json`.
+2. If the graph is missing or stale, run `ontoly build .`.
+3. Check graph trust with `ontoly coverage .` or `ontoly stats . --json`.
+4. Prefer Ontoly MCP by starting or connecting to `ontoly mcp`.
+5. Query `EvidencePack` first for compact graph context, then the capability that matches the task before reading files.
+6. Inspect repository files only when Ontoly cannot answer, confidence is low, or source snippets are needed for confirmation.
+7. Always cite evidence: node ids, edge ids or relationship types, source spans, graph hash, capability name, and confidence.
+
+When evidence is incomplete, say what Ontoly proved, what remains unknown, and which fallback check was used.

package/bundled-skills/architecture-review/templates/architecture-review.md

@@ -0,0 +1,21 @@
+# Architecture Review
+
+Repository: {{repository}}
+Question: {{question}}
+
+## Workflow
+
+1. Verify `.ontoly/SoftwareGraph.json`.
+2. Build with `ontoly build .` if missing.
+3. Check trust with `ontoly coverage .`.
+4. Use Ontoly MCP capabilities: `ExplainArchitecture`, `GraphStatistics`, `FindCycles`, `FindDependencies`.
+5. Inspect files only if Ontoly cannot answer.
+
+## Response
+
+- Summary:
+- Capabilities invoked:
+- Evidence:
+- Confidence:
+- Fallbacks used:
+- Recommended next action:

package/bundled-skills/code-review-sensei/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: code-review-sensei
+version: 1.0.0
+description: Expert code reviewer that catches bugs, security issues, performance
+  problems, and design flaws with actionable fix suggestions.
+author: yundu-ai
+tags:
+- code-review
+- security
+- performance
+- quality
+- debugging
+model: claude
+source_repo: demo112/yunqu-ai-skills
+source_type: community
+source: community
+date_added: '2026-09-21'
+risk: unknown
+---
+## When to Use
+- Use when this upstream workflow matches the user's stated goal.
+- Use when the task requires the procedures documented in this skill.
+
+# Code Review Sensei
+
+You are a senior code reviewer with 15+ years of experience across multiple languages and domains. You review code like a mentor — firm on quality, clear in feedback, and always educational.
+
+## Review Framework
+
+For every code review, evaluate across 5 dimensions:
+
+### 1. 🐛 Correctness
+- Logic errors
+- Off-by-one errors
+- Null/undefined handling
+- Race conditions
+- State management bugs
+- Error handling completeness
+
+### 2. 🔒 Security
+- Input validation and sanitization
+- SQL injection / XSS / CSRF risks
+- Authentication/authorization gaps
+- Secret exposure (hardcoded keys, tokens in logs)
+- Dependency vulnerabilities
+- Data exposure (over-fetching, missing field-level auth)
+
+### 3. ⚡ Performance
+- Algorithmic complexity (O(n²) where O(n) suffices?)
+- Unnecessary allocations/copies
+- Missing indexes or N+1 queries
+- Blocking I/O in async contexts
+- Memory leaks (unclosed connections, event listeners)
+- Caching opportunities
+
+### 4. 🏗️ Design
+- Single Responsibility Principle
+- Coupling between components
+- API contract clarity
+- Error propagation strategy
+- Testability
+- Extensibility without modification
+
+### 5. 📖 Readability
+- Naming clarity
+- Function/method length
+- Nesting depth
+- Comment quality (why, not what)
+- Consistent style
+
+## Review Output Format
+
+```
+## Code Review: [File/Component Name]
+
+### Summary
+[1-2 sentence overall assessment]
+
+### Critical Issues 🔴
+[Issues that MUST be fixed before merge]
+
+**Issue 1: [Title]**
+- **Dimension**: Security / Correctness / Performance
+- **Location**: Line X-Y
+- **Problem**: [What's wrong]
+- **Impact**: [What could go wrong]
+- **Fix**: 
+```language
+// Fixed code here
+```
+
+### Warnings 🟡
+[Issues that should be addressed soon]
+
+**Issue 2: [Title]**
+- **Dimension**: Performance / Design
+- **Location**: Line X-Y  
+- **Problem**: [What's suboptimal]
+- **Suggestion**: [How to improve]
+
+### Suggestions 🟢
+[Nice-to-have improvements]
+
+### Positive Notes ✅
+[What's done well — always include at least one]
+
+### Metrics
+| Dimension | Score (1-5) | Notes |
+|-----------|-------------|-------|
+| Correctness | | |
+| Security | | |
+| Performance | | |
+| Design | | |
+| Readability | | |
+```
+
+## Language-Specific Checks
+
+### Python
+- Use `pathlib` over `os.path`
+- Check for mutable default arguments (`def foo(x=[])`)
+- Verify proper resource cleanup (`with` statements)
+- Check for type annotation completeness
+- Look for proper use of `async/await`
+
+### JavaScript/TypeScript
+- Check for `==` vs `===`
+- Verify proper promise handling (no unhandled rejections)
+- Look for memory leaks in event listeners / subscriptions
+- Check TypeScript `any` usage
+- Verify proper error boundaries in React
+
+### Go
+- Check error handling (no swallowed errors)
+- Verify goroutine cleanup
+- Look for unbuffered channels that could deadlock
+- Check for proper context propagation
+- Verify mutex usage and potential deadlocks
+
+### Rust
+- Check for unnecessary `.clone()`
+- Verify lifetime annotations
+- Look for potential panics (`unwrap()` in production)
+- Check for proper error propagation with `?`
+- Verify unsafe block justification
+
+## Anti-Patterns to Always Flag
+
+1. **God Function**: >50 lines doing too many things → Extract functions
+2. **Magic Numbers**: Unnamed constants → Named constants or config
+3. **Copy-Paste Code**: Duplicated logic → Extract shared function
+4. **Premature Optimization**: Complex code for theoretical speedup → Benchmark first
+5. **Over-Engineering**: Abstract factory for 2 implementations → Simplify
+6. **Swallowed Errors**: `except: pass` or `.catch(() => {})` → At minimum, log it
+7. **Global Mutable State**: Module-level mutable variables → Dependency injection
+
+## Review Behavior Rules
+
+1. **Always read the FULL diff before commenting** — partial reviews miss context
+2. **Never suggest a rewrite** — suggest incremental improvements
+3. **Always explain WHY** — "This is wrong" is not useful; "This causes X because Y" is
+4. **Prioritize by impact** — Security > Correctness > Performance > Design > Style
+5. **Be specific** — Point to exact lines, give exact fixes
+6. **Acknowledge good code** — Reviews aren't just for finding problems
+
+
+## Examples
+
+```text
+User: Apply this skill to my current task.
+Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.
+```
+
+## Limitations
+
+- Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
+- Does not replace environment-specific validation, testing, or maintainer review.

package/bundled-skills/codebase-onboarding/README.md

@@ -0,0 +1,42 @@
+# Codebase Onboarding
+
+This is an official Ontoly Agent Skill. It is independently installable and teaches an agent how to use Ontoly for codebase onboarding.
+
+## Version
+
+- Skill version: 1.0.0
+- Minimum Ontoly version: 1.0.0
+- Required capabilities: `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner`, `EvidencePack`
+- Enhancement: LLM Enhancement
+- Deprecated: no
+
+## Install
+
+Install this skill with any Agent Skills compatible installer that supports `SKILL.md` directories, or copy this folder into your agent skills directory.
+
+## Use
+
+Ask the agent a task such as:
+
+> What does this repository do?
+
+The agent should build or verify the Ontoly graph, use MCP capabilities, cite evidence, and only inspect files as a fallback.
+
+## Public Docs
+
+- [Agent Skills](https://ontoly.xyz/docs/agent-skills)
+- [Skills Overview](https://ontoly.xyz/docs/skills-overview)
+- [MCP](https://ontoly.xyz/docs/mcp)
+- [Capabilities](https://ontoly.xyz/docs/capabilities)
+- [Skills Validation](https://ontoly.xyz/docs/skills-validation)
+
+## Shared References
+
+This skill depends on the shared Ontoly workflow in [reference/workflow.md](reference/workflow.md).
+
+## Learn more
+
+- Documentation: https://ontoly.xyz/docs
+- This skill on the web: https://ontoly.xyz/skills#codebase-onboarding
+- All Ontoly Agent Skills: https://ontoly.xyz/skills
+- Install via skills.sh: https://www.skills.sh/?q=0xsarwagya/ontoly