// Teklens.AI — Settings ▸ Skills & Agents.
// Replaces the old single "Plugins" nav item with two reusable-entity collections:
// • Skills — the user-facing routed capability (description drives WHEN it runs),
// owns the OUTPUT (none / markdown / html / widget, optionally templated).
// • Agents — reusable investigators that return DATA to the thread; no user output.
// Scope-aware: Workspace (built-in locked except template; custom full) and Project
// (workspace items inherited read-only except template override; project-specific full).
// Reuses globals: Icon, Field, Picker, SettingsToggle, IconPicker, SETTINGS_INPUT.
// ============================================================
// Vocabulary — badges & output types
// ============================================================
// Skills and agents each render ONE canonical icon — never per-item.
// These match the Settings menu (Skills = puzzle, Agents = robot).
const SKILL_ICON = "puzzle";
const AGENT_ICON = "robot";
const SA_OUTPUT = {
none: { label: "Dynamic", short: "Dynamic", icon: "sparkles", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
markdown: { label: "Markdown", short: "Markdown", icon: "file", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
html: { label: "HTML", short: "HTML", icon: "code", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
widget: { label: "Widget", short: "Widget", icon: "grid", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
};
// Lineage is a neutral attribute too — the icon differentiates, not a hue.
const SA_LINEAGE = {
"built-in": { label: "Built-in", icon: "shield", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
custom: { label: "Custom", icon: "wand", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
inherited: { label: "Inherited", icon: "merge", tint: "var(--text-muted)", bg: "var(--surface-inset)" },
project: { label: "Project", icon: "grid", tint: "var(--text-2)", bg: "color-mix(in srgb, var(--text-faint) 16%, transparent)" },
};
const SA_MODELS = ["Claude Sonnet 4.5", "Claude Opus 4.1", "Gemini 3.1 Pro", "GPT-5.2", "Grok 4"];
function LineageBadge({ lineage, overridden }) {
const l = SA_LINEAGE[lineage] || SA_LINEAGE.custom;
return (
{l.label}
{overridden && (
Overridden
)}
);
}
function OutputBadge({ output }) {
const o = SA_OUTPUT[output] || SA_OUTPUT.none;
return {o.short};
}
// Whether an item is read-only in the current scope (and what *can* still be changed).
// Workspace: built-in is locked except its template. Custom is fully editable.
// Project: everything inherited is read-only except template override + enable toggle.
function saLockState(item, scope) {
if (scope === "project" && item.lineage !== "project")
return { locked: true, templateEditable: true, reason: "inherited" };
if (scope === "workspace" && item.lineage === "built-in")
return { locked: true, templateEditable: true, reason: "built-in" };
return { locked: false, templateEditable: true, reason: null };
}
// In Project scope, a workspace item is presented as "inherited".
function saEffLineage(item, scope) {
if (scope === "project" && item.lineage !== "project") return "inherited";
return item.lineage;
}
// ============================================================
// Seeds
// ============================================================
// Source: docs/design/skills-catalog.json — agents are reusable investigators; they
// never choose output format. No tools concept (capabilities are automatic at runtime).
const AGENTS_SEED = [
{ id: "code-analysis", name: "Codebase Investigator", lineage: "built-in", icon: "code", model: "Current Conversation model",
desc: "Traces architecture, ownership, and dependencies across the connected repositories to explain how a part of the codebase works. Pick this when a skill needs grounded understanding of implementation, structure, call graphs, or risk areas before producing output.",
instructions: "You investigate the connected repositories. Locate the modules relevant to the request, follow imports and call graphs, and identify the components involved, how they interact, who owns them, and where the risks are. Cite exact file paths as evidence. Return a structured summary of components, responsibilities, dependencies, owners, and risk areas. Do not propose final user-facing wording — return findings only; the calling skill formats the output." },
{ id: "find-experts", name: "Expert Finder", lineage: "built-in", icon: "search", model: "Current Conversation model",
desc: "Identifies and ranks subject-matter experts for a code area using git history and code ownership. Pick this when a skill needs to know who to assign work to, who to consult, or who owns a part of the system.",
instructions: "Given a topic or code area, find the files involved, analyze their git history and line ownership, and aggregate contributions per author. Filter out bots and automation accounts. Rank contributors by depth of involvement — commits, lines owned, and recency. Return a ranked list of experts, each with the ownership evidence behind the ranking. Return findings only — the calling skill renders them." },
{ id: "estimate-feature", name: "Feature Estimator", lineage: "built-in", icon: "lab", model: "Current Conversation model",
desc: "Assesses the complexity, effort, risk, and impact of a proposed feature or change, grounded in the actual codebase. Pick this when a skill needs a defensible estimate or a scoping breakdown.",
instructions: "Investigate the area a feature would touch, identify the work involved, and surface unknowns and dependencies. Assess complexity, effort, risk, and impact, breaking the work into parts where that adds clarity. Ground every judgment in evidence from the code and its history. Return a structured estimate with the reasoning behind it. Return findings only." },
{ id: "release-scanner", name: "Release Scanner", lineage: "custom", icon: "branch", model: "Current Conversation model",
desc: "Collects everything that shipped in a release window — merged pull requests, commits, and closed tickets — and groups them by type. Pick this when a skill needs the raw change set behind a release.",
instructions: "Given a release window (since the last tag or a date range), gather the merged pull requests, commits, and closed Jira issues in that range. De-duplicate, drop noise (chore, CI, dependency bumps) unless explicitly asked to include it, and classify each item as a feature, fix, improvement, or breaking change. Attach the author and any linked ticket. Return a structured, grouped change set. Return findings only." },
{ id: "risk-assessor", name: "Risk Assessor", lineage: "custom", icon: "target", model: "Current Conversation model",
desc: "Evaluates a change area for delivery and technical risk — coupling/blast radius, test-coverage gaps, ownership concentration, and code churn. Pick this when a skill needs a risk picture rather than a feature explanation.",
instructions: "For the given area, assess risk along several axes: blast radius and coupling, test-coverage gaps, ownership concentration (bus factor), recent churn and instability, and external dependencies. Ground each judgment in evidence — specific files, history, and owners. Assign a severity and likelihood to each risk and explain the reasoning. Return a structured risk assessment. Return findings only." },
{ id: "component-mapper", name: "Component Mapper", lineage: "custom", icon: "hierarchy", model: "Current Conversation model",
desc: "Discovers components and features and the relationships between them from code structure, imports, and naming. Pick this when a skill needs a map of the whole system rather than a deep dive into one part.",
instructions: "Cluster the codebase into components and features based on directory structure, imports, and naming conventions. For each component, capture its purpose, key files, owners, and the components it depends on. Identify the edges between components. Return a structured component map suitable for diagramming. Return findings only." },
{ id: "feedback-miner", name: "Feedback Miner", lineage: "custom", icon: "message", model: "Current Conversation model",
desc: "Mines connected sources (tickets, docs, comments) for recurring themes related to a topic. Pick this when a skill needs the voice-of-the-user signal behind a feature or problem.",
instructions: "Search the connected sources for material related to the topic. Extract recurring themes, pain points, and requests, each with a representative quote and a source reference. Group by theme and indicate the strength of the signal (how often it recurs). Return a structured themes summary. Return findings only." },
{ id: "sprint-analyst", name: "Sprint Analyst", lineage: "custom", icon: "calendar", model: "Current Conversation model",
desc: "Analyzes sprint and issue data to surface scope, progress, spillover, and velocity trends. Pick this when a skill needs the state of work in flight rather than codebase facts.",
instructions: "Given a sprint or board, gather its issues with statuses, points, assignees, and history. Compute scope (committed vs added mid-sprint), progress (done / in-progress / blocked), spillover carried from prior sprints, and a velocity trend across recent sprints. Flag at-risk items — blocked, unassigned, or oversized. Return a structured sprint summary. Return findings only." },
{ id: "dependency-auditor", name: "Dependency Auditor", lineage: "custom", icon: "shield", model: "Current Conversation model",
desc: "Inventories third-party dependencies across the repositories and flags outdated, duplicated, or risky versions. Pick this when a skill needs the supply-chain and version picture.",
instructions: "Scan the repositories' manifests and lockfiles to inventory dependencies and their versions. Identify outdated packages, duplicate versions across workspaces, and unmaintained or known-risky ones. Note where each dependency is used. Return a structured audit grouped by severity. Return findings only." },
{ id: "doc-synthesizer", name: "Doc Synthesizer", lineage: "custom", icon: "book", model: "Current Conversation model",
desc: "Gathers and synthesizes content from connected documentation sources (Confluence, SharePoint, docs) on a topic. Pick this when a skill needs written or tribal knowledge rather than code.",
instructions: "Search the connected documentation sources for material on the topic. Read the most relevant pages, reconcile overlaps and contradictions, and synthesize a coherent summary with citations back to each source. Call out gaps where documentation is missing or stale. Return a structured synthesis. Return findings only." },
];
// Source: docs/design/skills-catalog.json — skills are user-facing, own the output,
// and reference AGENTS (never tools) for grounding.
const SKILLS_SEED = [
{ id: "code-analysis", name: "Code Analysis", lineage: "built-in", icon: "code", enabled: true, output: "none", gatedBy: "git",
useTemplate: false, templateOverridden: false,
availability: "Requires a linked Git repository",
desc: "Investigate code architecture, patterns, and implementation details. Use when the user asks \"how does X work?\", \"what would be affected by changing Y?\", or \"what's the architecture of Z?\"",
instructions: "Start the code-analysis agent and then wait for its results before answering. If the first pass isn't sufficient, run another investigation with a more specific question. Run multiple agents in parallel when useful.",
agents: ["code-analysis"], template: null },
{ id: "find-experts", name: "Find Experts", lineage: "built-in", icon: "entity", enabled: true, output: "widget", gatedBy: "git",
availability: "Requires a linked Git repository", bespoke: true, widgetTool: "display_experts",
desc: "Identify subject matter experts by analyzing git history and code ownership. Use when the user asks \"who knows X?\", \"who should I assign this to?\", or \"who should I talk to about Y?\"",
instructions: "To find experts: start_agent with agent=\"find-experts\", then wait_for_agent to get the results, then display_experts with the result data.",
agents: ["find-experts"],
template: "Ranked expert cards. Each card: name, linked identity (GitHub/Jira), ownership strength, last active, and top files owned. Header shows the query and how many files were analyzed.",
schema: `{\n "query": "string",\n "filesAnalyzed": "number",\n "experts": [{ "name": "string", "email": "string", "commits": "number", "linesOwned": "number", "lastActive": "string", "topFiles": ["string"] }]\n}`,
sample: `{\n "query": "search ranking",\n "filesAnalyzed": 142,\n "experts": [\n { "name": "Maya Chen", "email": "maya@teklens.ai", "commits": 214, "linesOwned": 3800, "lastActive": "2 days ago", "topFiles": ["search/ranker.ts", "search/index.ts"] },\n { "name": "Tomas Vidal", "email": "tomas@teklens.ai", "commits": 97, "linesOwned": 1600, "lastActive": "1 week ago", "topFiles": ["search/query.ts"] }\n ]\n}` },
{ id: "estimate-feature", name: "Estimate Feature", lineage: "built-in", icon: "lab", enabled: true, output: "widget", gatedBy: "git",
availability: "Requires a linked Git repository", bespoke: true, widgetTool: "display_estimation",
desc: "Estimate effort, complexity, and risk for feature work. Use when the user asks \"how big is this?\", \"estimate this feature\", \"what's the effort?\", or \"how complex would X be?\".",
instructions: "Before estimating, investigate the codebase first — estimates grounded in real code are far more accurate than guesses. Ask 1-2 clarifying questions only if there's genuine ambiguity about scope.\n\nTo run estimation: start_agent with agent=\"estimate-feature\", then wait_for_agent to get the results, then display_estimation with the result data.\n\n**Presenting results:** Lead with the story point estimate and confidence level. Explain what drives complexity in PM terms — number of affected areas, risk of regressions, test coverage gaps. When confidence is below 70%, flag the uncertainty and explain what's missing.\n\n**Next steps to offer:** Draft a Jira ticket with the estimation data pre-filled, find experts for the riskiest area, or break a large estimate into smaller scoped stories.",
agents: ["estimate-feature"],
template: "Estimation card: headline complexity and effort, an impact indicator, a list of risks, and an optional breakdown of the work into parts.",
schema: `{\n "complexity": "string",\n "effort": "string",\n "impact": "string",\n "risks": ["string"],\n "breakdown": [{ "part": "string", "effort": "string" }]\n}`,
sample: `{\n "complexity": "Medium",\n "effort": "~8 points",\n "impact": "High",\n "risks": ["Reindex backfill has no rollback path", "Tokenizer change affects every locale"],\n "breakdown": [\n { "part": "Index schema migration", "effort": "3 pts" },\n { "part": "Reindex job", "effort": "5 pts" }\n ]\n}` },
{ id: "story-drafting", name: "Story Drafting", lineage: "built-in", icon: "story", enabled: true, output: "widget", essential: true,
createsArtifact: true, artifactType: "Story",
availability: "Requires a linked Git repository OR a linked Jira project", bespoke: true, widgetTool: "draft_jira_ticket",
templatableBody: true, useTemplate: true, templateOverridden: false,
bodyTemplate: "## User Story\n{As a [role], I want [capability], so that [benefit].}\n\n## Background\n{1–2 sentences on why this is needed; link the triggering conversation or evidence.}\n\n## Acceptance Criteria\n{Bulleted, testable conditions — each independently verifiable.}\n\n## Technical Notes\n{Affected components and files, patterns to follow, risks surfaced during investigation.}\n\n## Out of Scope\n{What this ticket explicitly does not cover.}",
bodyExample: "## User Story\nAs a user, I want to attach screenshots and files to a message, so that the agent has visual context for my request.\n\n## Background\nRaised in the spec-review for **TEK-140**. Users paste image URLs by hand today, which the agent cannot read.\n\n## Acceptance Criteria\n- Drag-and-drop upload onto the composer\n- 50 MB per-file limit with an inline error when exceeded\n- Thumbnail preview before send\n- Attachments persist on the created Jira issue\n\n## Technical Notes\nTouches `composer/Attachments.tsx` and `api/upload.ts`; follows the existing `useDropzone` pattern. Risk: object-storage signing for large files.\n\n## Out of Scope\nVideo attachments and clipboard paste — tracked separately.",
bodyTypes: ["Story", "Epic", "Bug", "Task"],
bodyByType: {
Story: {
template: "## User Story\n{As a [role], I want [capability], so that [benefit].}\n\n## Background\n{1–2 sentences on why this is needed; link the triggering conversation or evidence.}\n\n## Acceptance Criteria\n{Bulleted, testable conditions — each independently verifiable.}\n\n## Technical Notes\n{Affected components and files, patterns to follow, risks surfaced during investigation.}\n\n## Out of Scope\n{What this ticket explicitly does not cover.}",
example: "## User Story\nAs a user, I want to attach screenshots and files to a message, so that the agent has visual context for my request.\n\n## Background\nRaised in the spec-review for **TEK-140**. Users paste image URLs by hand today, which the agent cannot read.\n\n## Acceptance Criteria\n- Drag-and-drop upload onto the composer\n- 50 MB per-file limit with an inline error when exceeded\n- Thumbnail preview before send\n- Attachments persist on the created Jira issue\n\n## Technical Notes\nTouches `composer/Attachments.tsx` and `api/upload.ts`; follows the existing `useDropzone` pattern. Risk: object-storage signing for large files.\n\n## Out of Scope\nVideo attachments and clipboard paste — tracked separately.",
},
Epic: {
template: "## Epic Summary\n{One sentence describing the outcome this epic delivers.}\n\n## Goal & Success Metrics\n{What success looks like, with measurable targets.}\n\n## Scope\n{The major capabilities or child stories this epic groups together.}\n\n## Out of Scope\n{What this epic explicitly excludes.}\n\n## Dependencies\n{Other epics, teams, or systems this relies on.}",
example: "## Epic Summary\nGive every conversation rich attachment support — images, files, and pasted media — so the agent can reason over visual context.\n\n## Goal & Success Metrics\n80% of spec-review threads include at least one attachment within two sprints; zero attachment-related data-loss reports.\n\n## Scope\n- Drag-and-drop and clipboard upload in the composer\n- Per-file size limits and inline error handling\n- Thumbnail previews and attachment persistence on Jira issues\n\n## Out of Scope\nVideo transcoding and external CDN delivery — tracked under the Media Pipeline epic.\n\n## Dependencies\nObject-storage signing service (Platform), Jira attachment API quota increase.",
},
Bug: {
template: "## Summary\n{One sentence: what's broken and where.}\n\n## Steps to Reproduce\n{Numbered, deterministic steps that trigger the defect.}\n\n## Expected vs Actual\n{What should happen, and what actually happens.}\n\n## Environment\n{Browser/OS/version, release, feature flags in play.}\n\n## Technical Notes\n{Suspected root cause, affected components/files, related tickets.}",
example: "## Summary\nLarge image uploads (>20 MB) silently fail in the composer — no error, no attachment.\n\n## Steps to Reproduce\n1. Open any conversation\n2. Drag a 30 MB PNG onto the composer\n3. Send the message\n\n## Expected vs Actual\nExpected: an inline \"file too large\" error at the 50 MB limit, or a successful upload.\nActual: the thumbnail spins, then disappears; the message sends with no attachment and no error.\n\n## Environment\nChrome 124 / macOS 14.4, release v3.4.0, `attachments` flag on.\n\n## Technical Notes\nObject-storage signing in `api/upload.ts` times out for payloads over ~20 MB; the rejection is swallowed in `composer/Attachments.tsx`. Related: TEK-140.",
},
Task: {
template: "## Task\n{One sentence describing the unit of work.}\n\n## Details\n{What needs to be done, with enough context to start.}\n\n## Definition of Done\n{Checklist of conditions that mark this complete.}\n\n## Technical Notes\n{Affected components/files, patterns to follow.}",
example: "## Task\nAdd a 50 MB per-file size guard to the upload endpoint with a typed error response.\n\n## Details\nEnforce the limit server-side in `api/upload.ts` before signing the storage URL, returning a structured `FILE_TOO_LARGE` error the composer can surface inline.\n\n## Definition of Done\n- Requests over 50 MB rejected with a 413 and `FILE_TOO_LARGE` code\n- Composer shows the inline error from the typed response\n- Unit test covers the boundary at exactly 50 MB\n\n## Technical Notes\nMirror the existing validation pattern in `api/validate.ts`; no client changes beyond reading the error code.",
},
},
desc: "Draft Jira tickets grounded in codebase evidence. Use when the user asks to \"draft a ticket\", \"create a story\", \"write a Jira issue\", or \"make a task for X\"",
instructions: "**Always check for duplicates first.** Run the core search tool with `sources: [\"atlassian\"]` and `entityTypes: [\"jira:issue\"]` using a broad query that covers the feature or bug. Scan for partial matches, not just exact ones. If a potential duplicate exists, surface it with the issue key, status, and assignee. Ask if the user wants to update the existing ticket instead.\n\n**Investigate when it adds value.** For most tickets, use start_agent with code-analysis to understand the implementation area (affected files, existing patterns, risks) and start_agent with find-experts to identify who has expertise. Then call list_jira_users to match the top expert to a Jira account. Skip these when the user provides very specific requirements and the area is already well-understood — use judgment.\n\n**Draft with context.** Jira ticket drafts must be created with `draft_jira_ticket`. Do not use `generate_ui`, `render_widget`, raw HTML, or widget JSON for Jira drafts; those are visual-only surfaces and cannot create Jira issues. When calling `draft_jira_ticket`:\n\n- Reference specific components and files in acceptance criteria\n- Set the matched expert as assignee (assigneeAccountId + assigneeDisplayName)\n- Include risk areas identified during investigation\n- Keep description focused on what and why, not implementation details",
agents: ["code-analysis", "find-experts"],
template: "Editable ticket draft (interactive): summary, description, acceptance criteria, issue type, story points, labels, assignee, sprint — with a submit action.",
schema: `{\n "summary": "string",\n "description": "string",\n "acceptanceCriteria": ["string"],\n "issueType": "string",\n "storyPoints": "number",\n "labels": ["string"],\n "assignee": "string",\n "sprint": "string"\n}`,
sample: `{\n "summary": "Allow attachments in conversations",\n "description": "As a user I want to attach screenshots and files to a message so the agent has visual context.",\n "acceptanceCriteria": ["Drag-and-drop upload", "50 MB per-file limit", "Inline preview before send"],\n "issueType": "Story",\n "storyPoints": 8,\n "labels": ["chat", "attachments"],\n "assignee": "Maya Chen",\n "sprint": "Sprint 42"\n}` },
{ id: "atlassian", name: "Jira & Confluence", lineage: "built-in", icon: "jira", enabled: true, output: "none", gatedBy: "atlassian",
availability: "Requires an Atlassian connection AND a linked Jira project",
desc: "Jira and Confluence integration — tickets, sprints, search, and documentation. Use when the user asks about Jira tickets, sprints, project tracking, or says \"check this ticket\", \"show me the sprint\", \"find open bugs\"",
instructions: "**Ticket references:**\n\n- When users say \"this ticket\", \"this one\", \"the ticket\", \"this epic\", or similar without specifying a key, they ALWAYS mean the currently pinned ticket(s) in Active Context — not tickets mentioned earlier in conversation. Do not fetch unrelated tickets unless the user explicitly names them by key.\n- When users reference a specific ticket key (e.g. \"check TEK-70\") or need full Jira fields, use get_jira_issue. When they need the indexed entity shape, use get_entity with `sources: [\"atlassian\"]` and `entityTypes: [\"jira:issue\"]`.\n\n**Tool selection:**\n\n- For ticket refinement questions (is it well-defined? what are the requirements?), always fetch full details with get_jira_issue first — pinned context only shows a summary. Only use get_jira_issue when the user wants details OF the ticket itself (e.g. \"check this ticket\", \"what's the status of this epic?\").\n- CRITICAL: If the user asks what's UNDER a ticket (e.g. \"what are the stories under this epic?\", \"show sub-tasks\"), use list_related_entities with the ticket entity and `labels: [\"children\"]`. Do not use text search for hierarchy lookup.\n- Use the core search tool for general issue or sprint discovery (e.g. \"find open bugs\", \"show me auth stories\", \"list sprints\"). Set `sources: [\"atlassian\"]` and narrow with `entityTypes: [\"jira:issue\"]` or `entityTypes: [\"jira:sprint\"]`.\n- Use list_related_entities for graph lookups such as sprint issues (`labels: [\"issues\"]`), issue sprints (`labels: [\"sprints\"]`), and issue children (`labels: [\"children\"]`).\n- **Label/status/type/priority/assignee filters:** Use the typed search filter hints for available values. They are case-sensitive; copy exact values and do not invent fallback terms.\n- When users ask follow-up questions about previously shown results (\"which of those are not done?\", \"find the open ones\"), do NOT run a new search. Filter and reference the tickets already in the conversation.\n\n**Ticket management:**\n\n- You can update issue fields (summary, description, issue type, story points, labels, priority, parent) with update_jira_issue. This includes converting between types (e.g. Story → Epic) and setting the parent/epic of an issue (e.g. \"add TEK-161 to epic TEK-89\" → update TEK-161 with parentKey \"TEK-89\").\n- You can link two issues together with link_jira_issues (e.g. \"Relates\", \"Blocks\"). Use this when the user asks to connect stories to an epic or link related tickets.\n- You can change status with transition_jira_issue. Always check available transitions first.\n- You can add comments with add_jira_comment. To @mention someone, first call list_jira_users to get the team roster, then include @DisplayName in the comment body and pass the mentions array with their accountId and displayName.\n- Use list_jira_users to resolve a person's name to their Jira account ID before assigning tickets or @mentioning them. Call it once per conversation — the roster rarely changes.\n- Use assign_jira_issue to assign issues after looking up the account ID via list_jira_users.\n- When drafting a Jira ticket, call draft_jira_ticket. Do not use generate_ui, render_widget, raw HTML, or widget JSON for Jira drafts — those are visual-only surfaces and cannot create Jira issues.\n\n**CRITICAL:** Never execute write operations (update, transition, comment) without explicit user approval. Before the first write in a conversation, present what you plan to do and ask for permission. Once the user approves, you may proceed with related writes in that conversation without asking again for each one. But never assume permission — always get that first explicit \"yes\".",
agents: [] },
{ id: "file-watcher", name: "Local Files", lineage: "built-in", icon: "folder", enabled: true, output: "none", gatedBy: "folder",
availability: "Requires at least one watched folder",
desc: "The user's private knowledge base — personal notes, client records, health data, design docs, and any markdown/text/PDF/Office files they've synced from their machine. Load this skill whenever the user asks about anything that isn't obviously code, a Jira ticket, or about the codebase. When in doubt, load it and search; the cost of missing private context is higher than the cost of an empty search.",
instructions: "**Local files — the user's private knowledge base:**\n\nUse the unified `search` tool to search indexed local files. Limit to local file entities with `sources: [\"file-watcher\"]` or `entityTypes: [\"file-watcher:file\"]` when the user is specifically asking about synced documents.\n\nWhen to call it:\n- Any question mentioning a person, client, company, event, or domain term that is not obviously a code symbol or ticket ID.\n- When the user says \"my ...\" such as my notes, my clients, my lab results, my meeting prep, or my briefing.\n- When a factual question could plausibly be answered from private synced files.\n- When code/Jira/GitHub search returns nothing and the question could be about personal or project documents.\n\nHow to search:\n- Use broad semantic search terms first. Refine only if the first hit set is noisy.\n- Prefer `sources: [\"file-watcher\"]` for local-file-only questions.\n- Prefer `entityTypes: [\"file-watcher:file\"]` when the query should return file entities specifically.\n- Cite the file path from the result instead of summarizing vaguely.\n\nCombine with other sources by leaving `sources` unset when the question spans local files, Jira, GitHub, and other indexed entities.",
agents: [] },
{ id: "release-note-generator", name: "Release Note Generator", lineage: "custom", icon: "book", enabled: true, output: "html",
useTemplate: true, templateOverridden: false, createsArtifact: true, artifactType: "Release Note",
desc: "Use when the user asks to generate release notes, a changelog, or a 'what shipped' summary for a release or date range.",
instructions: "Use the Release Scanner to collect and classify everything that shipped in the window. Then fill the HTML template below: keep every entry user-facing (describe the value, not the commit message), group by category, and credit the author or ticket where useful. Omit a section that has no entries.",
agents: ["release-scanner"],
structure: "# Release {{version}} — {{date}}\n\nHeader band: the version, the date, and a one-line summary of the release theme.\n\n## New Features\nOne user-facing line per feature — what it does, with ticket and author.\n\n## Fixes\nOne line per fix — what was broken and is now resolved, with ticket.\n\n## Breaking Changes\nOne line per breaking change — what changed and the action required. (rendered with an amber heading)",
template: `Release
{{version}} · {{date}}
{{one-line summary of the release theme}}
New Features
{{per feature: a user-facing line — what it does (ticket · author)}}
Fixes
{{per fix: what was broken and is now resolved (ticket)}}
Breaking Changes
{{per breaking change: what changed and the action required}}
`,
example: `Release
v3.4.0 · Apr 22, 2026
Faster chat streaming, a redesigned context rail, and safer pinned-context migration.
New Features
Streaming responses now render token-by-token for snappier replies. (TEK-412 · Maya Chen)
Redesigned context rail with a pinned dock and breadcrumbs. (TEK-388 · Sol Park)
Fixes
Pinned context no longer disappears when reopening an in-flight chat. (TEK-401)
Virtualized message list stops jumping on rapid updates. (TEK-377)
Breaking Changes
contextChips[] is replaced by contextGraph — run the migration before upgrading. (TEK-410)
` },
{ id: "risk-analyzer", name: "Risk Analyzer", lineage: "custom", icon: "target", enabled: true, output: "widget",
useTemplate: true, templateOverridden: false, comp: "RiskAnalyzer",
desc: "Use when the user asks about the risk of a change, an area, or a release — delivery risk, technical risk, or what could go wrong.",
instructions: "Use the Risk Assessor — and the Codebase Investigator when deeper grounding helps — to evaluate the area. Produce a risk widget: an overall score and headline, then each risk with severity, score, likelihood, impact, the evidence (file · lines · owner) behind it, and a recommended mitigation.",
agents: ["risk-assessor", "code-analysis"],
widgetHtml: `
{{headline}}
{{summary}}
{{counts.total}} risks · {{counts.high}} high · {{counts.medium}} medium · {{counts.low}} low
{{/each}}
`,
schema: `{\n "overall": "number (0-100)",\n "headline": "string",\n "summary": "string",\n "counts": { "total": "number", "high": "number", "medium": "number", "low": "number" },\n "risks": [{\n "severity": "high | medium | low",\n "score": "number (0-100)",\n "title": "string",\n "area": "string (file path)",\n "lines": "string",\n "likelihood": "Likely | Possible | Unlikely",\n "impact": "High | Medium | Low",\n "desc": "string",\n "mitigation": "string",\n "owner": "string",\n "effort": "S | M | L"\n }]\n}`,
sample: `{\n "overall": 68,\n "headline": "Implementation Risk",\n "summary": "Branch features/new-chat-frontend diverges 38 commits from main. Risk is concentrated in two adjacent surfaces: streaming state and message virtualization. Migration of the pinned-context schema is the highest-blast-radius item if shipped without backfill.",\n "counts": { "total": 5, "high": 2, "medium": 2, "low": 1 },\n "risks": [\n { "severity": "high", "score": 84, "title": "Race condition between streaming chunks and optimistic user message", "area": "src/chat/useChatStream.ts", "lines": "L42–L78", "likelihood": "Likely", "impact": "High", "desc": "Stream subscription opens before the optimistic insert resolves. On poor network, chunks may target a stale message id and silently drop.", "mitigation": "Defer stream subscription until the optimistic id is committed; introduce a pending-buffer keyed by clientMsgId and replay on bind.", "owner": "felix.h", "effort": "M" },\n { "severity": "high", "score": 76, "title": "Virtualization breaks scroll-to-bottom on tool-call expansion", "area": "src/chat/MessageList.tsx", "lines": "L120–L165", "likelihood": "Possible", "impact": "High", "desc": "Variable-height tool cards aren't measured before next render. Auto-scroll lands above the latest message ~12% of the time in repro.", "mitigation": "Use ResizeObserver per row; gate auto-scroll on a 1-frame post-measure RAF. Add an at-bottom sentinel.", "owner": "anita.r", "effort": "S" },\n { "severity": "medium", "score": 64, "title": "Pinned-context store migration has no backfill", "area": "src/state/contextGraph.ts", "lines": "—", "likelihood": "Likely", "impact": "Medium", "desc": "Schema changes contextChips[] → contextGraph. Existing users would lose pins on first load.", "mitigation": "Write one-shot migrator on hydrate; emit telemetry per migrated user; add rollback flag.", "owner": "lukas.b", "effort": "M" }\n ]\n}` },
{ id: "component-analyzer", name: "Component Analyzer", lineage: "custom", icon: "hierarchy", enabled: true, output: "widget",
desc: "Use when the user asks for an overview of the system's components or features, an architecture map, or how the parts fit together.",
instructions: "Use the Component Mapper to cluster the codebase, then present an interactive component map: each component with its purpose, owners, and dependencies, plus the relationships between components.",
agents: ["component-mapper"],
template: "Component map. A node per component (name, purpose, owner count, file count) with edges for dependencies, plus a side list of components showing details on selection.",
schema: `{\n "components": [{ "name": "string", "purpose": "string", "owners": ["string"], "files": "number", "dependsOn": ["string"] }],\n "edges": [{ "from": "string", "to": "string" }]\n}`,
sample: `{\n "components": [\n { "name": "Search", "purpose": "Indexing & ranking", "owners": ["Maya Chen"], "files": 34, "dependsOn": ["Storage"] },\n { "name": "Storage", "purpose": "Persistence layer", "owners": ["Tomas Vidal"], "files": 21, "dependsOn": [] }\n ],\n "edges": [{ "from": "Search", "to": "Storage" }]\n}` },
{ id: "idea-estimator", name: "Idea Estimator", lineage: "custom", icon: "lab", enabled: true, output: "widget",
useTemplate: true, templateOverridden: false, comp: "IdeaEstimatorWidget",
desc: "Use when the user floats a new idea, feature, or tool and wants a quick first-pass estimate — complexity, total risk, the top risks, who should build it, and a fuller breakdown — before committing.",
instructions: "Use the Feature Estimator to size the idea against the real codebase, the Risk Assessor to surface delivery and technical risk, and the Expert Finder to recommend who should own it. Produce an estimate widget: a complexity and total-risk score, the top risks ranked by severity, recommended team members with why, and a collapsible full estimation analysis.",
agents: ["estimate-feature", "risk-assessor", "find-experts"],
widgetHtml: `
{{idea}}
{{subtitle}}
{{complexity}}%
Complexity
{{totalRisk}}%
Total risk
Top 3 risks
{{#each risks}}
{{title}}{{severityLabel}}
{{/each}}
Recommended team members
{{#each team}}
{{initials}}
{{name}}
{{role}}
{{why}}
{{/each}}
Full estimation analysis
{{analysis}}
`,
schema: `{\n "idea": "string",\n "subtitle": "string",\n "complexity": "number (0-100)",\n "totalRisk": "number (0-100)",\n "risks": [{ "title": "string", "severity": "high | medium | low", "severityLabel": "HIGH | MEDIUM | LOW" }],\n "team": [{ "initials": "string", "name": "string", "role": "string", "why": "string" }],\n "analysis": "string"\n}`,
sample: `{\n "idea": "AI Legal Summary Tool",\n "subtitle": "Resource & Risk Assessment",\n "complexity": 72,\n "totalRisk": 55,\n "risks": [\n { "title": "Data Privacy Compliance (GDPR)", "severity": "high", "severityLabel": "HIGH" },\n { "title": "Latency in AI Inference", "severity": "medium", "severityLabel": "MEDIUM" },\n { "title": "Frontend State Complexity", "severity": "low", "severityLabel": "LOW" }\n ],\n "team": [\n { "initials": "AR", "name": "Alex Rivera", "role": "Backend Architect", "why": "Recent commits in high-concurrency data pipelines and database scaling." },\n { "initials": "JS", "name": "Jordan Smith", "role": "Security & DevOps", "why": "Handled the last 3 security audits and Auth0 migrations." }\n ],\n "analysis": "Net-new surface with a heavy compliance dimension. Inference latency and GDPR handling dominate the risk; frontend is well-understood. Recommend a spike on data residency before committing the estimate."\n}` },
{ id: "tech-debt-report", name: "Tech Debt Report", lineage: "custom", icon: "target", enabled: true, output: "markdown",
useTemplate: true, templateOverridden: false,
desc: "Use when the user asks about technical debt, hotspots, or where the codebase needs investment.",
instructions: "Use the Risk Assessor, Component Mapper, and Dependency Auditor to find debt hotspots. Then fill the Markdown template: an overall debt summary with a score and the top three concerns, followed by a hotspot section per area ranked by severity — each with the evidence behind it and a suggested remediation with rough effort.",
agents: ["risk-assessor", "component-mapper", "dependency-auditor"],
template: "# Technical Debt Report — {{scope}}\n\n**Debt score: {{0-100}}** · {{one-line headline}}\n\nTop concerns:\n- {{concern 1}}\n- {{concern 2}}\n- {{concern 3}}\n\n## Hotspots\n\n### {{component}} · {{severity}}\n{{evidence: churn, coverage, ownership, outdated deps}}\n**Fix:** {{remediation}} ({{rough effort}})",
example: "# Technical Debt Report — Chat & Context\n\n**Debt score: 64** · Concentrated in the streaming layer and the pinned-context store\n\nTop concerns:\n- Streaming state machine has high churn and no test coverage\n- Pinned-context store migration lacks a backfill path\n- Three core dependencies are two majors behind\n\n## Hotspots\n\n### Streaming layer · High\n12 commits in 30 days, 0% test coverage, single owner (bus factor 1).\n**Fix:** Extract a tested reducer and add contract tests (~3 days)\n\n### Pinned-context store · High\nSchema migration drops existing pins for in-flight chats; no backfill path.\n**Fix:** Add a migration with backfill behind a feature flag (~2 days)\n\n### Dependency freshness · Medium\nreact-flow, zod, and tiptap are two majors behind with open advisories.\n**Fix:** Stage upgrades behind CI smoke tests (~1.5 days)" },
{ id: "sprint-digest", name: "Sprint Digest", lineage: "custom", icon: "calendar", enabled: true, output: "widget",
createsArtifact: true, artifactType: "Sprint Summary", comp: "SprintDigestWidget",
desc: "Use when the user asks for a sprint status, a sprint summary, or 'where are we' on the current sprint.",
instructions: "Use the Sprint Analyst to assess the sprint, then present a digest widget: completion, quality and test-coverage scores, story-points progress (completed vs planned), at-risk and off-spec items, mid-sprint bugs, and verbose notes per story.",
agents: ["sprint-analyst"],
template: "Sprint digest widget: completion / quality / test-coverage scores, a story-points progress bar (completed vs planned), and a verbose per-story breakdown flagging off-spec work, missing tests, scope creep and mid-sprint bugs.",
schema: `{\n "sprintName": "string",\n "scores": { "completion": "number (0-100)", "quality": "number (0-100)", "testCoverage": "number (0-100)" },\n "points": { "done": "number", "planned": "number" },\n "stories": [{ "key": "string", "title": "string", "owner": "string", "points": "number", "flag": "done | off-spec | no-tests | scope-creep | bug", "note": "string" }],\n "notes": "string"\n}`,
sample: `{\n "sprintName": "Sprint 42",\n "scores": { "completion": 76, "quality": 58, "testCoverage": 41 },\n "points": { "done": 34, "planned": 45 },\n "stories": [\n { "key": "TEK-388", "title": "Redesigned context rail", "owner": "anita.r", "points": 8, "flag": "off-spec", "note": "Shipped without design sign-off; dropped the agreed compact variant." },\n { "key": "TEK-401", "title": "Pinned context survives reopen", "owner": "lukas.b", "points": 5, "flag": "no-tests", "note": "Data-loss fix landed with no regression test." },\n { "key": "TEK-412", "title": "Token-by-token streaming", "owner": "felix.h", "points": 8, "flag": "scope-creep", "note": "Also swapped the markdown renderer and added code-splitting — ~11 unestimated pts." },\n { "key": "TEK-431", "title": "Safari paste regression", "owner": "felix.h", "points": 2, "flag": "bug", "note": "Introduced day 3 by the dropzone change." }\n ],\n "notes": "Quality is the story of the sprint — merges are landing ahead of test and design sign-off."\n}` },
{ id: "prd-collector", name: "Product Requirements Collector", lineage: "custom", icon: "file", enabled: true, output: "markdown",
useTemplate: true, templateOverridden: false, createsArtifact: true, artifactType: "PRD",
desc: "Use when the user wants to capture or structure a product requirement — when they say \"write a PRD\", \"spec this out\", \"capture the requirements for X\", or describe a feature they want to formalise.",
instructions: "Collect requirements through a short, focused conversation — don't dump a blank template on the user. Ask about the problem, the target user, and the success metric first; infer the rest from context (linked tickets, the codebase, prior conversations) before asking. Use the Codebase Investigator to ground feasibility and surface constraints. Then fill the Markdown template: lead with the problem and the user, make goals measurable, write requirements as testable statements (P0/P1/P2), and always include what's explicitly out of scope. Flag any section where you're guessing so the user can confirm.",
agents: ["code-analysis"],
template: "# {{feature name}}\n\n**Status:** {{Draft · Review · Approved}} · **Owner:** {{owner}} · **Updated:** {{date}}\n\n## Problem\n{{the user problem in 2–3 sentences — who hurts and why now}}\n\n## Target user\n{{the primary persona and the job they're trying to do}}\n\n## Goals & success metrics\n- {{measurable goal — the metric that proves this worked}}\n\n## Requirements\n- **P0** {{must-have, testable statement}}\n- **P1** {{should-have}}\n- **P2** {{nice-to-have}}\n\n## Out of scope\n- {{what this explicitly does not cover}}\n\n## Open questions\n- {{unresolved decision needing an owner}}",
example: "# Inline attachments in conversations\n\n**Status:** Draft · **Owner:** Sam · **Updated:** Apr 22, 2026\n\n## Problem\nUsers can't give the agent visual context — screenshots, error states, design mockups — without pasting raw URLs it can't read. Support threads stall and tickets get drafted with missing detail. With attachments now expected in every modern tool, the gap is increasingly the reason teams bounce in the first session.\n\n## Target user\nProduct managers and support specialists drafting tickets mid-conversation, who already have the evidence on their screen but no way to hand it to the agent.\n\n## Goals & success metrics\n- 40% of ticket drafts include at least one attachment within two sprints of launch\n- Time-to-first-draft drops by 25% on conversations that start with an image\n- Zero increase in p95 message-send latency\n\n## Requirements\n- **P0** Drag-and-drop and click-to-upload on the composer, 50 MB per file\n- **P0** Inline thumbnail preview before send, with remove\n- **P0** Attachments persist onto the created Jira issue\n- **P1** Clipboard paste of images directly into the composer\n- **P2** Auto-extract text from uploaded screenshots for search\n\n## Out of scope\n- Video and audio attachments — tracked separately\n- Server-side virus scanning — handled by the existing upload pipeline\n\n## Open questions\n- Retention policy for attachments on deleted conversations — needs legal sign-off\n- Do we count an attachment against the user's storage quota? Owner: Billing" },
];
// ============================================================
// Side-panel item lists (rendered inside SettingsSidePanel)
// ============================================================
// ============================================================
// Activation model — built-in skills are governed by their connection
// (or are essential); only custom skills get a manual on/off switch.
// ============================================================
const SA_CONNECTIONS = {
git: { label: "Git repository", connected: true },
atlassian: { label: "Atlassian", connected: true },
folder: { label: "watched folder", connected: true },
};
function skillActivation(s) {
if (s.essential) return { mode: "always" };
if (s.gatedBy) { const c = SA_CONNECTIONS[s.gatedBy] || { label: s.gatedBy, connected: false }; return { mode: "gated", conn: c, active: !!c.connected }; }
return { mode: "toggle" };
}
function ActivationControl({ skill, onToggle, compact }) {
const a = skillActivation(skill);
if (a.mode === "toggle") return ;
const base = "inline-flex items-center gap-1.5 rounded-full border font-medium " + (compact ? "px-2 py-0.5 text-[10.5px]" : "px-2.5 py-1 text-[11.5px]");
if (a.mode === "always")
return Always on;
// gated
return a.active
? Active
: Unavailable;
}
// Whether a skill can be modified in the current scope. Built-ins with no
// template / body and no widget to override are read-only.
function skillEditable(s, scope) {
if (!saLockState(s, scope).locked) return true;
if (s.templatableBody) return true;
if ((s.output === "markdown" || s.output === "html") && s.useTemplate) return true;
if (s.output === "widget" && !s.bespoke) return true;
return false;
}
function SkillSideRow({ s, scope, active, onClick }) {
const lock = saLockState(s, scope);
return (
);
}
function SkillItems({ ws }) {
const { scope } = ws;
const inScope = (s) => scope === "workspace" ? s.lineage !== "project" : true;
const list = ws.skills.filter(inScope);
const groups = scope === "workspace"
? [["Built-in", "ship with Teklens", list.filter((s) => s.lineage === "built-in")],
["Custom", "defined for this workspace", list.filter((s) => s.lineage === "custom")]]
: [["Built-in", "ship with Teklens", list.filter((s) => s.lineage === "built-in")],
["Inherited", "from the workspace", list.filter((s) => s.lineage === "custom")],
["Project", "specific to this project", list.filter((s) => s.lineage === "project")]];
return (
);
}
// ============================================================
// Shared editor chrome
// ============================================================
function SAHeader({ crumb, label, hint, right }) {
return (
Settings
{label}
{hint && {hint}}
{right &&
{right}
}
);
}
function SAScopeNote({ scope }) {
return (
{scope === "workspace"
? Editing the workspace library. Changes apply to every project unless a project overrides them.
: Editing this project. Workspace items are inherited and read-only here, except their template.}
);
}
// ============================================================
// Markdown / template preview (reuses .ctx-doc styles)
// ============================================================
function renderTemplatePreview(text) {
const lines = (text || "").split("\n");
const out = [];
let list = null;
const flush = () => { if (list) { out.push(React.createElement("ul", { key: "u" + out.length }, list)); list = null; } };
const fmt = (s) => s.replace(/\{[^}]+\}/g, (m) => `\u2039${m.slice(1, -1)}\u203a`)
.split(/(\*\*[^*]+\*\*)/g).map((part, i) => part.startsWith("**") ? {part.slice(2, -2)} : part);
lines.forEach((ln, i) => {
const t = ln.trim();
if (/^###\s/.test(t)) { flush(); out.push(
{fmt(t.replace(/^###\s/, ""))}
); }
else if (/^##\s/.test(t)) { flush(); out.push(
{fmt(t.replace(/^##\s/, ""))}
); }
else if (/^#\s/.test(t)) { flush(); out.push(
{fmt(t.replace(/^#\s/, ""))}
); }
else if (/^[-*]\s/.test(t)) { (list = list || []).push(
A skill is a capability used to perform tasks. Each skill creates an output — markdown, HTML, or a fixed, configured widget. Skills may use sub-agents to perform their job.
This skill is {lineage === "inherited" ? "inherited from the workspace" : "built-in"} and read-only.{((skill.output === "markdown" || skill.output === "html") && skill.useTemplate) ? <> You can modify its template for {ws.scope === "project" ? "this project" : "your workspace"}. : skill.templatableBody ? <> You can modify the ticket body template for {ws.scope === "project" ? "this project" : "your workspace"}. : " Its description, instructions and output are fixed."}
)}
{skill.desc || No description yet.}
{skill.instructions ? renderTemplatePreview(skill.instructions) : No instructions yet.}