stark AI Developer

View saved version →

---
name: animated-readme-logo
description: Create, transform, animate, or audit GitHub README logos and their verified SVG/PNG/GIF delivery. Use when a repository needs branding assets, not ordinary README prose or app/site motion.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.5.4"
---

# Animated README Logo

## Goal

Audit an existing README logo pipeline or deliver a portable, verified animation from a validated SVG master, deterministic motion specification, and executable repository recipe.

## When to use

- Create, redesign, transform, animate, export, or review a repository or profile-README logo.
- Audit GitHub README logo compatibility, transparency, reduced motion, or local asset references.
- Turn an existing SVG or raster mark into a validated README asset pipeline.

## When not to use

- Ordinary README prose editing with no logo or image concern.
- App/site motion unrelated to repository branding delivery.
- Generic image generation with no README or repository-logo target.

## Workflow selection

Always expose exactly these public workflows:

- `audit`: read-only assessment of existing README logo sources, animation assets, delivery markup, and validation evidence.
- `create`: design a new mark or intentional redesign and deliver the complete verified animation stack.
- `transform`: faithfully recreate or clean up an existing mark and deliver the complete verified animation stack.
- `animate`: use an acceptable existing SVG source and deliver the complete verified animation stack.

There is no `auto` workflow and no public export workflow. Export is an internal rendering stage of every mutating route.

Route from task intent:

- review, compatibility, or quality assessment selects `audit`;
- a new mark or intentional redesign selects `create`;
- faithful work from a raster, screenshot, poster, or unsuitable SVG selects `transform`;
- an acceptable existing SVG that needs motion or raster delivery selects `animate`.

On every activation, show all four workflows, then `Selected`, `Reason`, source evidence, write scope, required outputs, protected originals, and remaining paid/tool/install/overwrite approvals. Proceed after the announcement when intent and mutation authority are unambiguous. A bare invocation, conflicting source evidence, or ambiguity about identity preservation, outcome, scope, or write authority asks the user to choose before substantive inspection. Agent-initiated activation may select `audit`; it may select a mutating workflow only when the existing task explicitly requested that outcome and scope.

Source routing is internal. Provider evaluation is available only within `create`, and selection never authorizes a credit-consuming call or tool installation.

For clear intent, a compact disclosure of `audit | create | transform | animate` and the selected route is sufficient; do not repeat a selection question or details already established in the conversation. Reuse an explicit approval only when it still covers the exact action, target, tool/provider, cost when relevant, and write scope. Separate approval boundaries remain separate: authorization for one never implies another. Ask again only for a changed or missing decision.

## Inputs to inspect

- Repository identity, public brand copy, target surface, and requested task.
- README markup and root-bounded local asset references.
- Existing logo sources, reference-media fidelity needs, transparency, themes, dimensions, accessibility, and export constraints.
- Live provider, authoring, validator, exporter, and inspector capabilities without assuming availability.

## Workflow

1. Resolve and announce the intent-bound workflow. Stop before inspection only when routing or authority is ambiguous.
2. For `audit`, inspect with an explicit repository root, treat local README references as untrusted and root-bounded, run available read-only validation, report remediation, and write nothing. Retur

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 19 — file references are metadata, not package contents.

View saved version →

---
name: architecture-compass
description: Set up ADR governance, audit architecture and drift, or plan and execute bounded refactors and code simplification. Use when work needs binding architecture decisions, library reuse, shared-code ownership, provider-to-local mapping, or architecture PR review.
license: Apache-2.0
compatibility: Designed for Codex, Cursor, Claude Code, ChatGPT Chat/Work, Codex web, and other Agent Skills hosts; adapts to host planning, review, question, and permission controls while keeping one portable ADR workflow.
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.13.1"
---

# Architecture Compass

## Goal

Make architecture decisions explicit, binding, locally traceable, and executable. Establish repository-native governance, audit implementation, or perform an ADR-guided refactor without overwriting accepted history or broadening authority.

## When to use

- Establish/reconcile ADR governance or audit architecture, decision coverage, drift, risk, and evidence.
- Plan or execute bounded ADR-governed work, including broad work that first requires durable decisions.

## When not to use

- Tiny/style-only or ordinary governed edits with no architecture consequence or ADR-aware boundary check.
- Generic framework education or requests without target evidence and a governance, audit, planning, or refactoring outcome.

## Activation and receipt presentation

Route activation and receipt presentation through [AC-ADR-053 Short](references/ac-adr-053-use-capability-aware-presentation-profiles-for-portable-agent-receipts.short.md) · [Long](references/ac-adr-053-use-capability-aware-presentation-profiles-for-portable-agent-receipts.long.md) · [Guide](references/ac-adr-053-use-capability-aware-presentation-profiles-for-portable-agent-receipts.guide.md). Start with Short and load Long before conditionally loading `AC-INTERNAL-002` from the internal index for renderer-selection mechanics. This dispatcher does not define a presentation profile or renderer policy.

## Workflow selection

Every direct invocation exposes exactly these public workflows:

- `setup`: establish or reconcile repository-native ADR governance with `recommended` or `complete` coverage.
- `audit`: perform a strictly read-only architecture, ADR-coverage, drift, and validation assessment.
- `refactor`: execute explicit bounded work already governed by accepted local ADRs.
- `plan-refactor`: collaborate on and persist an approved bounded refactoring specification without implementing it.
- `plan-run-refactor`: plan, persist, recheck, and execute an approved broad or decision-bearing refactor.

Begin activation with a compact line exposing `setup | audit | refactor | plan-refactor | plan-run-refactor`, then name the selected route, rationale and authorized scope. Keep this disclosure in response-only assessments too; a short answer still exposes all five choices.

There is no `auto` workflow. Route by task evidence:

| Intent evidence                                                       | Selected workflow   |
| --------------------------------------------------------------------- | ------------------- |
| Establish or reconcile ADR governance                                 | `setup/recommended` |
| Review architecture, ADR coverage, drift, or risk                     | `audit`             |
| Produce a refactoring plan without execution                          | `plan-refactor`     |
| Broad implementation or unresolved durable decisions before execution | `plan-run-refactor` |
| Explicit bounded work fully governed by accepted local ADRs           | `refactor`          |

For clear direct or agent-discovered intent with sufficient authority, state the complete workflow set, selected workflow and rationale compactly, then proceed. Name write scope and any material capability, protected-state, or separate approval boundary; put detailed evidence in the matching receipt. A bare activation, conflicting cues, or amb

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 230 — file references are metadata, not package contents.

View saved version →

---
name: architecture-zoom
description: Plan a product or feature as a readable architecture blueprint and complete product increments. Use when the user needs a whole-product view, progressive detail, module contracts, or an MVP delivery map. Not for direct implementation, codebase audits, or exhaustive implementation specs.
license: Apache-2.0
compatibility: Uses available repository and document tools; supports conversational planning without assuming native skill chaining, installation, or enforcement.
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.2.0"
---

# Architecture Zoom

## Goal

Make the agreed whole product understandable, then describe only the detail needed for the next decision. Deliver a linked architecture blueprint and a path to complete, usable product increments, not an exhaustive specification or a tree of unfinished components.

This is one planning workflow. Architecture views describe structure; delivery views describe user outcomes. Neither implies extra processes, services, agents, or mandatory abstraction layers.

## When to use

- Plan a new product, initial feature, or architecture before detailed implementation.
- Explain the whole system with optional drill-down into responsibilities and contracts.
- Cut a broad goal into releases that each fulfill a complete, bounded user promise.
- Update an existing blueprint after a material requirement or contract change.

## When not to use

- A current implementation spec already resolves the requested change.
- A tiny correction needs no meaningful product or architecture decision.
- The request is an audit of existing code, direct refactoring, implementation, or formal proof.
- The user only wants brainstorming; do not turn that into mandatory specification work.

## Inputs to inspect

Reuse the request, prior answers, product goals, release map, accepted local ADRs, relevant instructions, and existing work items. Inspect representative code and actual sources when needed to distinguish current state from intended behavior. Record material revisions and unavailable evidence; never invent paths, commands, interfaces, or test results.

## Workflow

1. **Resolve scope and reuse.** Identify the user promise, audiences, constraints, non-goals, delivery intent, and existing artifacts. Ask only unresolved material questions. Respect active Plan and observed permissions independently. Continue independent planning while a dependent decision is unresolved.
2. **Show the whole picture.** Draft the overview using [the blueprint template](assets/blueprint-template.md): complete agreed functional breadth, core journeys, system responsibilities, important cross-cutting requirements, and visible risks. Separate current state, target, assumptions, and proposals. Complete breadth does not mean predicting every future requirement.
3. **Refine contracts only where useful.** Apply [design contracts](references/design-contracts.md). Give modules stable IDs and one authoritative contract. Link parents, children, dependencies, and cross-cutting invariants; do not duplicate shared modules. Stop refining when the next decision has sufficient responsibilities, interfaces, assumptions, and acceptance criteria. Keep deferred detail and its revisit trigger visible.
4. **Cut complete product increments.** Keep the architecture map separate from the delivery map. A release must fulfill its own user promise using existing capabilities plus its own work, never a future release. Prefer a narrow end-to-end path over completing database, backend, and UI separately. A ticket is not automatically an MVP. Bound necessary enabling work and POCs, link their consuming increment, and do not report them as usable products.
5. **Check bottom-up and across modules.** Trace each material requirement through a journey, release, relevant contracts, and planned acceptance. Check compatibility, composition, error recovery, side effects, ownership, and global invariants

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: codegraph-ast-grep
description: Set up, update, or diagnose CodeGraph and ast-grep so coding agents can use semantic repository scope and structural syntax evidence automatically. Use when a repository needs an idempotent CodeGraph/ast-grep installation, stable tool and index migrations, MCP reconnection, persisted agent guidance, or a read-only setup diagnosis.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.3.4"
---

# CodeGraph + ast-grep

## Goal

Make a repository's coding agents ready to use CodeGraph for semantic scope and ast-grep CLI for structural evidence. Public workflows manage that capability; repository exploration and refactoring are ordinary internal coding behaviors after setup.

## When to use

- Install or reconcile CodeGraph, ast-grep CLI, MCP exposure, indexing, and agent guidance.
- Update the installed analysis stack and run required configuration, index, or schema migrations.
- Diagnose a missing, stale, disconnected, or apparently broken setup without repairing it.

## When not to use

Do not activate this skill merely because a coding task can benefit from an already-ready analysis stack. Follow the persisted repository guidance instead. Do not use it for general dependency audits, compiler/runtime proof, or an unreviewed broad rewrite.

## Workflow selection

The complete finite workflow inventory, in plain, benefit-first language, is:

- `setup`: supercharge the repository with Semantic Code Intelligence and structural code search, helping coding agents answer faster with fewer tool calls. Install missing pieces, connect the coding client, build the code index, add repository guidance, and safely reuse or repair any existing setup.
- `update`: bring an existing setup to current stable versions without changing how it was installed. Migrate configuration or index data when needed, reconnect the coding client, and verify that everything still works.
- `doctor`: diagnose setup health and report analytics without repairing anything.

Show the complete finite workflow inventory in its documented order for a bare or materially ambiguous invocation, or an explicit options request. An options request alone does not authorize execution or repository/tool inspection; answer from the documented inventory. For clear authorized intent, announce only the selected workflow and rationale, with material scope and evidence fields, and proceed.

There is no `auto` workflow. Select by intent:

- An explicit setup or installation request selects `setup`.
- An explicit stable-tool update, migration, or refresh request selects `update`.
- “Something is broken,” a health check, or a request for setup analytics selects `doctor`.
- A bare invocation or ambiguous intent requires showing all three workflows and asking the user to choose.

For clear direct intent, state only the selected workflow, rationale, root, expected writes/artifacts, and protected state, then proceed. Agent-initiated activation may select and announce only `doctor`; it must not infer setup or update authority. Selecting `setup` or `update` is allowed only when the user already requested that outcome for the stated root. Privileged/global installation, paid or external services, publication/deployment, destructive replacement, telemetry changes, and scope expansion retain separate approval.

## Inputs to inspect

- Exact repository root, nested repositories or monorepo packages, package/declarative policy, and protected Git state.
- Effective `CODEGRAPH_DIR` (default `.codegraph/`), root `codegraph.json` when supported, `sgconfig.yml`/`sgconfig.yaml`, and repository instruction files.
- Executable paths, installer channel and scope, version pins, installed help, configured client, and exposed MCP tools.
- Approved scope for package/config/index writes and any exact-root project opening that may migrate generated metadata.

## Workflow

### `setup`

1. Capture the exact root, protected state, r

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: codex-memory-curator
description: Audit and safely curate Codex memory, including stale claims, cross-repo leakage, sensitive entries, and memory configuration. Use when reviewing or cleaning Codex memory, not generic repository docs.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: codex-operations
  version: "0.2.4"
---

# Codex Memory Curator

## Goal

Audit Codex memory as user-owned durable state; classify stale, unsafe, duplicated, or misplaced claims and route review, planning, persistence, and cleanup. Even when invoked from Cursor, inspect only Codex memory/config, not Cursor state.

## Core principle

Memory is context, not truth. The latest user request, current repo files, `AGENTS.md`, package files, ADRs, and live evidence override stored memories.

## When to use

- Use for review, placement, configuration, planning, or cleanup of Codex memory and its durable configuration.
- Use when memory is stale, conflicting, sensitive, noisy, cross-repository, or causing degraded behavior.

## When not to use

- Do not use for ordinary docs, generic prompt work, or Cursor state unless Codex memory/config is explicitly involved.
- Keep review requests read-only and inspect no personal files beyond Codex memory/config plus the minimum repository evidence needed for conflicts.

## Workflow selection

Expose all eight workflows in this stable order, compactly when intent is clear. Recommend the route matching the requested outcome and delivery; for a bare invocation recommend `review-chat` while asking the user to choose:

| Workflow                | Delivery and result                                                          |
| ----------------------- | ---------------------------------------------------------------------------- |
| `plan-run-cleanup-file` | One record: review, approved plan, backup, cleanup, verification.            |
| `review-chat`           | Chat: read-only review and recommendations.                                  |
| `review-file`           | One record: read-only review and recommendations.                            |
| `cleanup-chat`          | Chat and backup: review, high-confidence atomic cleanup, verification.       |
| `cleanup-file`          | One record and backup: review, high-confidence atomic cleanup, verification. |
| `plan-cleanup-chat`     | Chat: review and approved plan; no cleanup.                                  |
| `plan-cleanup-file`     | One record: review and approved plan; no cleanup.                            |
| `plan-run-cleanup-chat` | Chat and backup: review, approved plan, cleanup, verification.               |

Route from intent instead of adding an `auto` workflow:

- Direct review defaults to `review-chat`; explicit persistence selects `review-file`.
- Explicit cleanup without a delivery preference selects `plan-run-cleanup-file`.
- A clear direct request may select another matching route when delivery and execution intent are explicit.
- Agent-initiated activation may select only a relevant read-only route. Use `review-file` only when the existing task already requests persistence; never infer cleanup.
- A bare invocation, conflicting cues, or ambiguity about review versus cleanup, chat versus file, execution, Codex home, or mutation authority exposes the table and asks the user to choose.
- A mutating route may be selected only when the user already requested cleanup of the identified Codex memory scope.

Before substantive inspection, disclose the complete finite options once and state `Selected`, `Reason`, Codex home/repo target, write scope, expected artifacts, protected state, Plan-mode capability, and unresolved approvals. Reuse facts and exact authority already established in the task; combine known fields into a short announcement. If selection is unambiguous, announce it and proceed. If it is ambiguous, stop before inventory and ask only the unresolved choice. Do not repeat the selector or ask for an unchanged selection again.

W

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 15 — file references are metadata, not package contents.

View saved version →

---
name: codex-spec-interviewer
description: Turn ambiguous coding requests into verified Codex implementation specs. Use when the user wants requirements, an implementation plan, or a spec before coding; include source checks, needed ADRs, and agreed delivery. Do not use for already specified direct implementation or memory cleanup.
license: Apache-2.0
compatibility: Targets Codex evidence and execution prompts across Agent Skills hosts. Use the current execution host's available controls and permissions, with conversational support for older hosts.
metadata:
  author: stark-ai-de
  category: codex-operations
  version: "0.5.1"
---

# Codex Spec Interviewer

## Goal

Produce a user-verified implementation spec with bounded scope, testable acceptance criteria, source-backed decisions, validation, and any required ADRs. Deliver it to the agreed repository path, or in chat when explicitly requested. One approval covers the unchanged result and its concrete authorized writes.

This is one end-to-end workflow. A clear request selects it; do not invent review/save variants or add a workflow-selection checkpoint. For a bare invocation, ask for the task to specify.

## When to use

- The user has a rough idea but not a production-ready implementation spec.
- The task spans multiple files or concerns, or requires tradeoff decisions.
- The request needs acceptance criteria, validation commands, rollout notes, or risk handling.
- The user wants a reusable written artifact before implementation begins.
- Requirements, feature shape, ADR assumptions, or the implementation approach should be challenged against repo reality and current external sources before coding.

## When not to use

- The user already provided a complete implementation spec with files, constraints, tests, and acceptance criteria.
- The task is a tiny one-file edit without meaningful ambiguity.
- The user wants brainstorming only and no concrete implementation artifact.
- The user only wants `AGENTS.md` content or Codex memory entries authored, not an implementation spec.
- The task is primarily a policy, legal, or business-decision document.
- The user asks to audit or clean up Codex memory state; use a Codex memory skill instead.

## Inputs to inspect

- The current user request and any follow-up answers.
- Relevant `AGENTS.md`, `README.md`, issue descriptions, ADRs, repo docs, and `docs/agents/` files.
- Existing specs, plans, requirements, and PRDs the user wants preserved or challenged.
- A coordinated product-planning work item, when supplied: product/release/slice IDs, canonical contracts and revisions, prior answers, non-goals, evidence limits and genuine authorization. Do not require it for independent use.
- File layout, naming conventions, scripts, package manager, lint/test/type-check commands, and CI expectations.
- Current framework, library, API, or platform documentation through available MCP tools or web search when a decision depends on up-to-date behavior.
- Error messages, screenshots, logs, PR feedback, or example files the user supplied.

## Workflow

Follow [workflow-details.md](references/workflow-details.md) for the shared interview, approval and delivery lifecycle. Use [host-adapters.md](references/host-adapters.md) only when a host control or transition matters.

1. Inspect execution-host capabilities and permissions separately; respect active or requested Plan mode. Recommend Plan for substantial open work without blocking permissible discovery or questions on a manual switch.
2. For an existing coordinated handoff, read [product-planning handoffs](references/product-planning-handoffs.md) without restarting upstream skills. Inspect relevant repository context and prior answers. Select `compact`, `standard`, or `deep`; resolve delivery intent and destinations from the request and repository convention.
3. Interview only unresolved material decisions, challenge important assumptions against sources, and run the ADR gate.
4. Prepare the complet

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 18 — file references are metadata, not package contents.

View saved version →

---
name: drawio-diagrams
description: Create, edit, review, or export editable draw.io diagrams. Use when the user needs .drawio architecture, flow, sequence, network, or other technical diagrams; not data plots or artistic images.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.7.5"
---

# drawio-diagrams

## Goal

Produce, edit, verify, and deliver high-quality draw.io / diagrams.net diagrams as editable `.drawio` files. Prefer self-contained diagrams that work in both light and dark mode.

## First response contract

For the first substantive response, expose the available presentation choices before authoring: `design_profile` (`technical`, `operator-grid`, `isometric-air`, `neon-hub`, `aurora-story`, or `adapted-<short-name>`), `theme_mode` (`adaptive`, `light`, or `dark`), `animation` (`on`, `off`, or `preserve`), and icon mode (`official-first` with semantic fallback for unresolved or generic nodes). State the selected profile and styling options, or ask only when the requested outcome is materially ambiguous; do not hide these choices until delivery.

## Official icon and logo policy

Use official organization/product/service artwork first when available and supported by the notation; use a semantic glyph only for generic, vendor-neutral, or unresolved nodes. Preserve source artwork, brand colors, proportions, viewBox, and variant. Do not arbitrarily tint, recolor, monochromatize, invert, filter, crop, stretch, or restyle official marks; solve contrast with surrounding neutral surfaces. Record per-node substitutions and disclose any explicitly requested or necessary accessibility recolor.

## When to use

Use this skill for requests to create, draw, generate, edit, repair, convert, verify, or export draw.io diagrams, including architecture diagrams, flowcharts, sequence diagrams, ER/UML/state diagrams, BPMN, SysML, ML/DL, swimlanes, timelines, network diagrams, C4-style diagrams, and icon-rich technical visuals.

## When not to use

Do not use for bar/line/pie charts, data analysis plots, photo editing, artistic images, or non-editable illustrations unless the user explicitly wants a draw.io diagram.

## Workflow selection

When invoked directly, always expose these finite workflows:

- `create`: create a new diagram or convert supplied semantics into editable draw.io.
- `edit-repair`: edit, repair, or intentionally restyle an existing `.drawio` file.
- `review`: read-only semantic, structural, validation, or visual assessment.
- `export`: export an already acceptable `.drawio` source without redesigning it.

There is no `auto` workflow. Infer only from task intent and authority:

- Creating or converting semantics into a new editable diagram selects `create`.
- Editing, repairing, or intentionally restyling an existing diagram selects `edit-repair`.
- A semantic, structural, validation, or visual assessment with no requested changes selects `review`.
- Exporting an already acceptable `.drawio` source without redesign selects `export`.

For clear direct intent, state all four workflows, the selected workflow and rationale, inputs, requested outputs, design profile, theme/animation/icon modes, recommended authoring/render route (`direct-xml | transactional-native | approved-raw-cli-manual | fixed-theme-browser-raster | browser-url-preview | html-viewer-preview`), write scope, expected artifacts, protected files, and later approval boundaries, then proceed. A bare invocation, mixed outcomes with materially different scope, or unresolved source/destination requires showing the options and asking. Agent-initiated activation may select and announce `review` without confirmation; it may select a mutating workflow only when the user's existing request already authorizes that outcome and scope. Installation, hosted content transfer, browser rasterization, file-writing fallback helpers, destructive overwrite, paid/external actions, and scope expansion retain separate approval

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 39 — file references are metadata, not package contents.

View saved version →

---
name: jev-capability-advisor
description: Recommend available skills or MCP tools using TypeSafe Jev, or explicitly choose one next skill. Use when the user requests capability advice, candidate inspection, selection evaluation, or reusable host integration. Native client selection remains the default and fallback.
license: Apache-2.0
compatibility: >-
  Requires Python 3.10+, TypeSafe API credentials, and host-authorized
  HTTPS access to api.typesafe.ai for recommendations.
metadata:
  author: stark-ai-de
  category: skill-maintenance
  version: "0.3.3"
---

# Jev Capability Advisor

## Goal

Return a task-specific recommendation from capabilities actually available in the current client. The default `general` profile can recommend one to three capabilities; explicit `next_skill` recommends one skill without assessing remaining work. The client retains discovery, activation, permissions, and execution.

## Network prerequisite

Recommendations need host-authorized HTTPS access to `api.typesafe.ai:443` and
existing TypeSafe credentials. Installation, hook trust, processing consent and
network permission are separate. The user or administrator owns permissions;
the skill never edits sandbox, firewall, proxy or approval policy. Use an
applicable native approval route only when needed. A denial ends the attempt:
no alternate route, repeated prompt or automatic retry. Follow the
[network and failure contract](references/network-access.md) for actionable,
secret-free messages. Without usable API access, no Jev recommendation was
produced; native selection and local `Inspect` are not Jev advice.

The contract is the same on native Windows, macOS and Linux; WSL is a separate
environment, not a prerequisite. Use the installed OS-native Python interpreter.
Concrete host approval controls belong in the [hook reference](references/hook-integration.md).

## Enabled-hook entry

Hook guidance requests **Recommend**, `general/current`. First distinguish the delivered mode. A `repository-adopted` reminder follows the [repository policy prerequisites](references/hook-integration.md#repository-adopted-policy), including adoption, scoped host-owner processing authority and qualification; it has no installer binding and must not invent one. The following bound-status and receipt steps apply to the optional installer-managed reminder. Resolve this `SKILL.md` from its current eligible host card. Use that exact directory for every reference and script; a repository/workspace search cannot establish whether installed support files exist. First read this copy's `references/hook-integration.md`, then run this copy's `scripts/jev_hooks.py status` with the delivered registration's `--host` and `--scope`; add `--project-root` only for project scope. Use absolute paths or that skill directory as the command working directory. Require an active registration and `advice_consent.status: recorded`; a key or native hook trust does not establish processing consent. Never install or grant consent to repair a missing prerequisite during ordinary advice.

Read the [capture procedure](references/hook-catalog.md) before judging catalog availability. A prebuilt JSON export or complete inventory is not required: construct a bounded bare array from the current model-visible skill cards and loaded MCP definitions, keeping only source-backed eligible entries. A missing structured export alone is not a prerequisite failure. Build the hook catalog from current skill cards and actual MCP definitions, excluding built-in host tools. Candidate enrichment may extract name, description and invocation-policy metadata, but must not load candidate workflow instructions before advice. The CLI catalog is a **bare JSON array**, never a `{"capabilities": [...]}` wrapper or a Session frame. Keep current-source snapshots and exclusions in the private [catalog evidence sidecar](references/hook-catalog.md), check it with `scripts/hook_catalog.py`, and retain its declared coverage limit

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 19 — file references are metadata, not package contents.

View saved version →

---
name: karakeep-knowledge
description: Set up or use a local persistent Karakeep knowledge collection through its official MCP server. Use when configuring Karakeep for coding agents, checking an existing connection, checking project readiness, saving factual session reports, synchronizing approved canonical documents and separate drafts, maintaining approved source-backed aggregates, curating lists and tags, or consulting saved web sources for development work.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.6.2"
  hermes:
    tags: [knowledge, karakeep, repositories]
    category: engineering-workflows
---

# Karakeep Knowledge

## Goal

Give coding agents one persistent collection of saved websites, source content,
screenshots and searchable text. Reuse the official Karakeep MCP server and the
user's existing account. A cloud account or external AI provider is not required.

## When to use

- Set up Karakeep, connect another coding agent, or check the local knowledge service.
- Consult saved component libraries, frameworks, design references or instructions
  when they are relevant to the user's coding task.
- Save or import references the user has requested to add to this collection.
- Check project readiness and reconcile approved documents, separate drafts and factual session reports during meaningful work.
- Organize saved knowledge on request or under an existing automatic curation policy.

## When not to use

- A task has no meaningful connection to the saved collection.
- The user requests QMD, a Markdown export pipeline, a new app database or cloud
  sharing. Those require their own scoped work; this skill does not add them.

## Inputs to inspect

- The current execution host, installed MCP tools and effective client configuration.
- The selected connection and account. Follow [connection selection](references/setup.md#select-an-existing-connection)
  when several candidates are known; localhost or proxy settings alone do not identify an instance.
- Existing Karakeep endpoints, local account/collection, Compose project, mounts,
  service manager and declarative configuration owner. Do not dump environments.
- Private config/data locations and the current operation's authority. Follow the
  host's existing Docker/runtime choice; do not install a second engine.

## Access selection

Prefer the existing local Karakeep MCP server or supported local API for information
retrieval and authorized operations. Inspect callable MCP schemas and the installed
release's supported API capabilities before choosing browser automation. A missing
MCP tool alone does not establish an API gap; verify support rather than guessing
endpoint names. Reuse the intended account and approved credential source.

Use Playwright/browser MCP only when MCP and API cannot provide the information or
operation needed for the task, such as UI-only settings or visual verification.
Briefly explain the concrete gap and limit browser use to that gap; return to MCP
or API for the rest. A request sent through a browser session to an internal web API
is browser-assisted access, not proof of public API support.

Denied approval, insufficient privileges or a restricted read key are not capability
gaps to work around. Changing access methods never expands authorization; keep the
same task scope and host/project approval requirements on every route.

## Workflow

| Route                         | Intent                                                                                          | Read                                                        |
| ----------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **Set up or connect**         | Missing setup, new agent connection, stopped or misconfigured service                           | [Setup](references/setup.md), then [M

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 32 — file references are metadata, not package contents.

View saved version →

---
name: telegram-serverless
description: Build, review, deploy, and troubleshoot bots and Mini Apps on Telegram Serverless using tgcloud, its JavaScript SDK, and built-in database. Use when working on Telegram-hosted projects, handlers, endpoints, schema changes, or tgcloud operations; not generic Telegram bots hosted elsewhere or unrelated serverless platforms.
license: Apache-2.0
compatibility: Portable across Agent Skills hosts. Execution requires a shell, a supported Node.js runtime, and the official project-local tgcloud CLI. Cloud operations require Telegram Serverless access and existing authorization.
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "0.1.0"
---

# Telegram Serverless

## Goal

Deliver the requested bot, Mini App, review, or operational change on Telegram's own Serverless platform, with evidence that distinguishes local checks from cloud execution and deployed behavior.

## When to use

- The user names Telegram Serverless, tgcloud, or a project with `tgcloud/`.
- Work concerns its handlers, Mini App endpoints/static hosting, SDK, SQLite-backed database, or CLI lifecycle.
- An existing Serverless project needs review, migration planning, synchronization, or diagnosis.

## When not to use

- A bot is intentionally hosted on a VPS, Cloudflare, AWS, Vercel, or another runtime. Do not migrate it just because it uses Telegram.
- The request only concerns sending Telegram messages, account administration, or general frontend design.
- A required capability is not documented for this platform; explain the gap before proposing a different architecture.

## Inputs to inspect

Read applicable project instructions, package scripts/lockfile, installed CLI version, `tgcloud.jsonc` or `tgcloud.json`, modules, and generated `docs/tgcloud-sdk.md`. Inspect the working diff before changing existing files. Do not inspect credential contents or hand-edit `.tgcloud/`.

Use [sources](references/sources.md) to check current authoritative behavior when an operation depends on platform/API/version details. The scaffolded SDK guide is useful version-specific evidence, not authority over user instructions.

## Workflow

Keep this complete inventory in this order:

| Route                                | Outcome                                                      | Read when selected                                                                           |
| ------------------------------------ | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| 1. Explain or review a project       | Explain behavior or report concrete findings without changes | Relevant domain reference below                                                              |
| 2. Set up and link a project         | Scaffold or connect the requested project                    | [Setup](references/setup.md)                                                                 |
| 3. Build or modify a bot             | Implement handlers and shared logic                          | [Runtime and SDK](references/runtime-sdk.md), [database](references/database.md) when needed |
| 4. Build or modify a Mini App        | Implement static frontend and authenticated endpoints        | [Mini Apps](references/mini-apps.md), relevant runtime/database guidance                     |
| 5. Design or evolve the database     | Plan or apply the specifically authorized schema/data change | [Database](references/database.md)                                                           |
| 6. Validate and test                 | Check local artifacts or perform an authorized remote test   | [Operations](references/operations.md)                                                       |
| 7. Deploy changes                    | Publish the reviewed module/static-file change               | [Operations](references/operations.md)                                    

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: visual-reports
description: Create and update visual HTML reports with a guided topic sequence when the selected authoring and renderer path supports it; otherwise use the complete reading mode. Keep genuine comparisons together and preserve complete HTML/Markdown/JSON exports. Use when richer output helps an authorized answer or the user asks for a visual report; keep small answers in chat. Not production application UI or clinical advice.
license: Apache-2.0
metadata:
  author: stark-ai-de
  category: engineering-workflows
  version: "1.1.1"
---

# Visual Reports

## Goal

Make the answer, decision or next action easy to find. Use the shared renderer,
clear hierarchy, short lists and meaningful visuals. Identify whether the reader
needs an action, a decision or a summary before choosing the format. Preserve facts, evidence
states, sources and decisive limitations. Do not invent quantities to fill charts.

Use a guided topic sequence only when the selected authoring and renderer path
actually supports it. The current renderer supports its existing `reading` mode and
explicit `slides` blocks; ordinary sections are not converted to guided pages. For
those reports, use the complete reading-mode output. Preserve explicitly requested
layouts. Follow [the reading contract](references/report-contract.md#guided-reading-when-supported)
before choosing blocks; it defines the supported fallback and exceptions for layouts
and joint comparisons.

## When to use

Use reports for comparisons, multi-step plans, relationships and data-rich findings
within the authorized answer. Keep tiny answers in chat.

## When not to use

Do not use for production application UI, unrelated artwork, external service
operation or medical/clinical advice.

## Workflow

| Route                | Authorized outcome                                             | Read when selected                                                                                                                             |
| -------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Create or update     | Complete report from the same source snapshot                  | [Reader experience](references/report-contract.md#reader-experience), [selection](references/selection.md), [v2 model](references/model-v2.md) |
| Preview and continue | Stable local URL, version history, explicit revision switching | [Managed reports](references/managed-reports.md)                                                                                               |
| Present or prototype | Slides, opt-in motion or validated state simulation            | [Legacy blocks and 24 recipes](references/renderer.md)                                                                                         |
| Edit locally         | Board, flags or prompt draft with separate export              | [Editor contract](references/renderer.md#browser-state-exports-and-safety)                                                                     |
| Explore styles       | Current, balanced and calm previews with identical facts       | [Presentation](references/report-contract.md#presentation-and-styles)                                                                          |
| Adopt preference     | Persist an explicitly selected style in ignored local state    | [Preference contract](references/report-contract.md#local-preference)                                                                          |

For clear intent, announce the route and proceed. For a bare invocation or options
request, show the complete inventory; options alone authorize no execution.
Choose a report automatically when it improves the authorized answer, especially
comparisons, relationships, multi-step plans or data-rich findings. Keep one fact
or a short action in

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 44 — file references are metadata, not package contents.