opencode-skills-collection 4.0.69 → 4.0.70

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

@@ -0,0 +1,77 @@
+---
+name: codebase-onboarding
+description: Onboard a developer to a repository using Ontoly graph summaries. Use
+  when asked to explain a new codebase, identify entrypoints, map packages, or suggest
+  first files to inspect.
+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, FindEntrypoints, GraphStatistics, FindFeatureOwner,
+    EvidencePack
+  ontoly.category: onboarding
+  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.
+
+# Codebase Onboarding
+
+Use this skill when the user asks for codebase onboarding 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`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner`, `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#codebase-onboarding
+- 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/codebase-onboarding/examples.md

@@ -0,0 +1,11 @@
+# Codebase Onboarding 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 `FindEntrypoints` then `GraphStatistics` then `FindFeatureOwner`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner` | controller, route, service, dependency-injection edges; graph hash; confidence. | A first-day onboarding map with entrypoints, packages, owners, evidence, and confidence. |
+| Ghost | Explain the package entrypoint and public API surface. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `FindEntrypoints` then `GraphStatistics` then `FindFeatureOwner`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner` | package, exports, functions, interfaces; graph hash; confidence. | A first-day onboarding map with entrypoints, packages, owners, evidence, and confidence. |
+| durable-local | Find storage APIs and consumers before a refactor. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `FindEntrypoints` then `GraphStatistics` then `FindFeatureOwner`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner` | functions, interfaces, dependents, configuration; graph hash; confidence. | A first-day onboarding map with entrypoints, packages, owners, evidence, and confidence. |
+| 0xsarwagya | Summarize workspace packages and package dependencies. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `FindEntrypoints` then `GraphStatistics` then `FindFeatureOwner`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner` | workspace, packages, framework nodes, dependency edges; graph hash; confidence. | A first-day onboarding map with entrypoints, packages, owners, evidence, and confidence. |
+| Innosphere | Identify application modules and request ownership. | Follow shared workflow, run `EvidencePack` first, then `ExplainArchitecture` then `FindEntrypoints` then `GraphStatistics` then `FindFeatureOwner`, inspect files only if graph evidence is missing. | `EvidencePack`, `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner` | controllers, modules, routes, services; graph hash; confidence. | A first-day onboarding map with entrypoints, packages, owners, evidence, and confidence. |

package/bundled-skills/codebase-onboarding/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/codebase-onboarding/reference/capabilities.md

@@ -0,0 +1,20 @@
+# Codebase Onboarding Capability Notes
+
+Primary capabilities: `ExplainArchitecture`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner`, `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/codebase-onboarding/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/codebase-onboarding/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/codebase-onboarding/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/codebase-onboarding/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/codebase-onboarding/templates/repository-onboarding.md

@@ -0,0 +1,21 @@
+# Repository Onboarding
+
+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`, `FindEntrypoints`, `GraphStatistics`, `FindFeatureOwner`.
+5. Inspect files only if Ontoly cannot answer.
+
+## Response
+
+- Summary:
+- Capabilities invoked:
+- Evidence:
+- Confidence:
+- Fallbacks used:
+- Recommended next action:

package/bundled-skills/connection-auth-rules/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: connection-auth-rules
+description: Build a Connection Auth Rules for a Monte Carlo connection type. Fetches
+  live connector schemas and transform steps from the apollo-agent repo.
+bucket: Setup
+version: 1.0.0
+source_repo: monte-carlo-data/mc-agent-toolkit
+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.
+
+# Connection Auth Rules Builder
+
+Use this skill when the user wants to build a Connection Auth Rules (stored as `ctp_config`) for a Monte Carlo connection. The config is stored on the `Connection` object in the monolith and tells the Apollo agent how to transform flat credentials into the driver-specific `connect_args` format.
+
+## When to activate this skill
+
+Activate when the user:
+
+- Asks to create, build, or generate a Connection Auth Rules
+- Asks what fields are needed for a connection type's Connection Auth Rules
+- Wants to customize credential transformation for a connection
+- Asks about `MapperConfig`, `TransformStep`, or `CtpConfig`
+- Says things like "help me write Connection Auth Rules for X", "what's the connection auth rules format for X"
+
+## When NOT to activate this skill
+
+Do not activate when the user is:
+
+- Creating monitors (use the monitor-creation skill)
+- Investigating data incidents (use the analyze-root-cause skill)
+- Setting up a connection in the UI (this skill builds the JSON config, not UI flows)
+
+---
+
+## Step 1 — List available connection types
+
+Locate the companion script with Bash:
+
+```bash
+find -L ~/.claude . -name fetch_schema.py -path "*/connection-auth-rules/*" 2>/dev/null | head -1
+```
+
+Then run it:
+
+```bash
+python3 <script_path> --list
+```
+
+The script outputs JSON. Parse `result.connectors` — each entry has a `name` field. Present the names to the user and ask which connection type they want to build a config for.
+
+**If the script fails:** Show the error output and offer to retry. Do not proceed until you have the connector list.
+
+---
+
+## Step 2 — Fetch the connector schema
+
+Once the user selects a connection type, run the script with that connector name:
+
+```bash
+python3 <script_path> --connector <name>
+```
+
+The script outputs JSON. Parse `result.schema`:
+
+- **`output_keys`** — the driver-level `connect_args` keys the mapper must produce (from the connector's `TypedDict`)
+- **`default_field_map`** — the existing default mapping (credential field → Jinja2 template)
+- **`default_steps`** — any default transform steps already configured
+
+Present a summary to the user:
+
+- The output keys
+- The default mapper field_map entries
+- Any existing steps with their types
+
+---
+
+## Step 3 — Optionally fetch available transform steps
+
+If the connector's default config (from Step 2) already includes steps, or if the user indicates they need custom transform steps, run:
+
+```bash
+python3 <script_path> --connector <name> --transforms
+```
+
+Parse `result.transforms` — each entry has:
+- `name` — the step type string used in `"type"`
+- `step_input` — fields the step reads from the pipeline state
+- `step_output` — derived fields the step writes, referenceable as `{{ derived.<key> }}` in the mapper
+- `step_field_map` — typical mapper entry to wire the step's output into `connect_args`
+
+Present the available steps with their full contracts (input, output, and field_map hint).
+
+**If the script fails:** Tell the user and offer to retry. You can continue without step data — just describe steps as unknown and ask the user to specify them manually.
+
+---
+
+## Step 4 — Build the mapper
+
+Walk the user through each output key in the TypedDict:
+
+1. Show the default template from the connector's `MapperConfig` (if one exists).
+2. Ask if they want to keep the default or customize it.
+3. For custom values, help the user write a Jinja2 template expression.
+
+### Jinja2 template help
+
+The template context has two namespaces:
+
+- **`raw`** — the flat credential dict as received. Use `{{ raw.field_name }}` to reference a credential field directly. Example: `{{ raw.client_id }}`
+- **`derived`** — fields added by transform steps. Use `{{ derived.field_name }}` to reference a step's output. Example: `{{ derived.private_key_pem }}`
+
+Common patterns:
+- Simple field reference: `"{{ raw.username }}"`
+- Conditional/default: `"{{ raw.port | default('1433') }}"`
+- Concatenation: `"{{ raw.host }}:{{ raw.port }}"`
+
+When the user doesn't know their credential field names, remind them these come from the Data Collector's credential dict — the keys are whatever the DC sends for that connection type.
+
+---
+
+## Step 5 — Configure transform steps (optional)
+
+If the connector needs steps (e.g. decoding a PEM certificate, constructing a derived field), help the user configure each step. A step dict has these fields:
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `type` | yes | Step type name (e.g. `"load_private_key"`) |
+| `input` | yes | Dict of template strings the step reads (e.g. `{"pem": "{{ raw.private_key_pem }}"}`) |
+| `output` | yes | Dict mapping the step's logical output names to derived key names (e.g. `{"private_key": "private_key_der"}`) |
+| `when` | no | Jinja2 boolean expression — step only runs if this evaluates to true (e.g. `"raw.ssl_ca_pem is defined"`) |
+| `field_map` | no | Mapper entries contributed only when this step runs — useful for conditional fields |
+
+Walk the user through `type`, `input`, and `output` for each step. Ask about `when` if the step should only run under certain credential conditions (e.g. when an optional SSL cert is present).
+
+Steps run in order before the mapper. The mapper can reference step outputs via `{{ derived.<key> }}`.
+
+---
+
+## Step 6 — Output the final config
+
+Produce the complete Connection Auth Rules as a Python dict (ready to serialize to JSON for storage). This is stored as `ctp_config` on the `Connection` model:
+
+```python
+{
+    "steps": [
+        # each step as a dict, e.g.:
+        {
+            "type": "load_private_key",
+            "input": {
+                "pem": "{{ raw.private_key_pem }}"
+            },
+            "output": {
+                "private_key": "private_key_der"
+            }
+            # optional: "when": "raw.private_key_pem is defined"
+        }
+    ],
+    "mapper": {
+        "field_map": {
+            "output_key": "{{ raw.credential_field }}",
+            # step output referenced as: "private_key": "{{ derived.private_key_der }}"
+            # ...
+        }
+    }
+}
+```
+
+Also show the equivalent JSON, since this is what gets stored in the monolith's `Connection.ctp_config` field and entered in the "Connection auth rules" field in the UI.
+
+Remind the user that validation happens server-side via `validateConnectionCtpConfig` — they should test the config through that mutation (or the Validate button in the UI) after saving it.
+
+---
+
+## Notes
+
+- **No in-skill validation.** The skill helps construct the config but does not execute or validate it. The user validates via the monolith's `validateConnectionCtpConfig` GraphQL mutation or the Validate button in the "Connection auth rules" UI section.
+- **`is not None` pattern.** An empty `field_map` (`{}`) is valid — do not treat it as missing. The monolith checks `ctp_config is not None`, not truthiness.
+- **Steps are optional.** Most simple connectors use `steps: []`. Only add steps when the user needs credential transformation (e.g. PEM decoding, composite field construction).
+- **Fetch failures are recoverable.** If the GitHub API fetch fails, tell the user exactly what failed and offer to retry. Do not silently fall back to guessed schemas.
+- **Naming:** The user-facing name for this feature is "Connection auth rules". The underlying field and backend model remain `ctp_config` / `CtpConfig`.
+
+
+## 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.