Add support to local agent skill

[zzzuhaibmohd]

Preflight

• I searched existing issues and discussions and this isn't a duplicate.

Problem / motivation

1. The current agent skills supports only public skills
2. add support to allow users to add custom local skills

Proposed solution

Support adding private/local agent skills

Which area?

frontend

Alternatives considered

No response

Additional context

No response

[prithvee07]

Thanks for filing this — I dug into how skills work today and want to propose a concrete shape before anyone starts building, since it touches four components.

What exists today

Agent skills aren't actually locked to a fixed "public" set — AgentSkillEditor already lets you create fully custom skills, stored in the shared agent_skills Postgres table. The gap is that each one is materialized as a single synthesized SKILL.md built from one content text column (engine/open_kritt_engine/workspace.py:_skill_markdown), so there's no way to point at a real skill folder (the kind Claude Code/Codex-native skills usually are — SKILL.md plus scripts/resources) without hand-copying its contents into a browser textarea.

Proposed shape: mirror the existing local-repos feature

The repo already solves the "reference something from the local filesystem instead of the DB/network" problem for repos (backend/src/lib/localRepos.js + LOCAL_REPOS_PATH / local_repos/). Local agent skills would follow the identical pattern:

• New env var LOCAL_AGENT_SKILLS_PATH (default ./local_agent_skills host-side), same .env.example treatment as LOCAL_REPOS_PATH.
• Each immediate subdirectory of that root is one local skill, named by its folder name, expected to contain a SKILL.md (optionally with the same YAML frontmatter native skills use). Any other files in the folder (scripts, resources) travel with it as-is.

Backend

• src/lib/localAgentSkills.js + src/routes/localAgentSkills.js (GET /api/local-agent-skills) — near-identical to localRepos.js/routes/localRepos.js, including the same traversal/symlink-escape protections.
• Scan validation accepts a new localAgentSkillNames: string[], checked against the listed names the same way repoFull is checked against localRepoNames() for repoKind: 'local'.
• Storage: no schema migration for a first pass — store selection in scans.configuration.local_agent_skill_names, the same way post_script_ids/agent_skill_ids are already duplicated into configuration JSON today. The real agent_skill_ids column stays bigint[]-only (DB skill IDs); local skills are name-keyed, not id-keyed, so they don't fit it. A dedicated text[] column is a reasonable follow-up if this sees real usage.

Engine

• db.py: load_local_agent_skills(scan) alongside load_agent_skills, resolving names against the engine's own LOCAL_AGENT_SKILLS_PATH mount with the same fd-based, symlink-safe opening repository.py's local-repo checkout already uses.
• workspace.py: _install_agent_skills currently only synthesizes a single SKILL.md per DB skill. Local skills need a sibling path that shutil.copytrees the whole folder into codex_home/skills/<slug>/ (and the Claude equivalent) instead, with _selected_agent_skills_markdown merging both sources so the harness prompt still lists everything selected regardless of origin.
• Worth flagging early: jobs run in sibling Docker containers (_scan_docker_command), not nested in the engine container, so the engine needs the host path for LOCAL_AGENT_SKILLS_PATH, not its in-container path — this is why the engine's docker-compose.yml block mounts LOCAL_REPOS_PATH to a different in-container path than the env var it hands the app, going through a host-path resolution helper. Local skills need identical treatment, so that mapping needs to be traced carefully rather than assumed.

Frontend

• CreateScan.jsx's existing agent-skill selection UI gets local skills merged in (likely tagged "local" since they can't be edited/duplicated the way DB skills can).
• Optionally a read-only listing in AgentSkills.jsx so they're discoverable outside scan creation.

Sequencing

Given the size, I'd split this into three PRs rather than one: (1) backend + docker-compose plumbing (ships something inspectable on its own), (2) engine consumption, (3) frontend selection UI.

Open question for a maintainer

Is storing the selection in configuration.local_agent_skill_names (no migration) acceptable for a first pass, or would you rather it land as a first-class text[] column on scans from the start, matching how agent_skill_ids already got one? That decision affects PR 1's shape, so flagging it before writing code.

Happy to pick this up if the shape above sounds right.