[hanna-paasivirta]

Description

This PR adds slash-command skills (/design, /diagnose, /qa) to the global assistant and stores Apollo's conversation history so it can be sent back unchanged. It is the Lightning side of OpenFn/apollo#711.

Closes BLD-71
Closes OFN-4757

Decisions

• Apollo owns the history. Lightning stores what Apollo returns and sends it back unchanged, instead of rebuilding it from messages. This is what lets a skill like /design keep working over several turns: its instructions stay in the history, and there is no skill mode that ends, which is also how Claude Code handles skills.
• Lightning recognises the slash command and names it in skill, only on the turn that starts with /name. Apollo strips the command and keeps the skill in its history.
• Lightning keeps its own list of skills for the slash menu for now. It needs a way to sync with Apollo's list, which we'll add once this work is validated, to avoid complexity we may not need and get this out for testing sooner.

Changes

• New nullable apollo_history column on ai_chat_sessions. After each successful response, the history from the final complete event is saved as received, for job, workflow and global chat. The next request sends it back as history. Sessions from before this fall back to rebuilding history from messages.
• Global chat messages that start with a known /name send skill: {name} to Apollo.
• A slash-command menu in the assistant's chat input, listing the skills from the backend (ai_skills in the session context). The chosen skill shows as a pill, on the input and on sent messages.
• Adds tests for storing and sending back history, detecting skills, and the slash menu.

Validation steps

1. Run Apollo from the slash-command-preset branch (Add skills as slash commands apollo#711) and point Lightning at it.
2. Open the global assistant, type / and check design, diagnose and qa are listed.
3. Run /design and answer its questions over a few turns. It should keep asking design questions rather than building straight away.
4. Check the session's apollo_history column holds the full history, including the skill instructions and [pg:...] page prefixes.

Additional notes for the reviewer

1. Deploy Add skills as slash commands apollo#711 first. Apollo on main ignores skill, so with Lightning first the menu works but no skill runs. Apollo alone changes nothing for current Lightning.
2. If two tabs send in the same session at once, the last response to finish overwrites the stored history. This is rare, so it's left as is.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Security Review ✅

• S0 (project scoping): The only new channel addition (lib/lightning_web/channels/workflow_channel.ex:1382) is a static ai_skills list from Lightning.AiAssistant.Skills.list/0; no new queries touch project-scoped resources, and session reads/writes still flow through pre-existing session-scoped paths.
• S1 (authorization): N/A — no new web-layer actions or policy-gated operations; the slash-command path only sets a skill on an existing authenticated chat flow and the after_join auth in workflow_channel.ex already gates the context payload.
• S2 (audit trail): N/A — the new apollo_history jsonb column on ai_chat_sessions (migration 20261005181455) stores AI conversation state, not project/instance configuration, so it falls outside the audit domains listed in the agent's reference modules.

[elias-ba]

Great work Hanna 👏🏽, I enjoyed reading this one, and letting Apollo own the history is the right call. I have left a few comments and questions below, could you please feel free to let me know what you think?

The one I would fix is Escape in the slash menu. Press it once and the menu never comes back. The other two are about /qa, which we describe as a review when the skill rewrites job code, and a comment that gets Apollo's rule for valid skill names slightly wrong.

Worth checking the deploy order with whoever ships this. Apollo on main doesn't know what skill is, so if Lightning goes first the menu works and nothing happens.

The changelog has no entry, and the note saying the landing screen has no slash menu is out of date now.

Thanks!

[elias-ba]

Escape is sticky here. dismissedMenuFor is set to whatever is in the input and never cleared, not on send and not in reset, so one Escape stops a bare / opening the menu for as long as the panel is mounted, which is the whole editor session. Clearing the input by hand doesn't bring it back. The Escape test sends straight afterwards, so nothing catches it.

While you're in here, the handler calls preventDefault but not stopPropagation, so the same Escape carries on to the window and the editor's Escape handlers run with it. The other menus join the keyboard registry instead, SnapshotVersionDropdown.tsx:67 and AdaptorSelector.tsx:79. Could this one do the same?

[hanna-paasivirta]

Confirmed, thanks. It's now cleared on any change and on reset, with a test that the menu opens again after Escape.

For the propagation I used stopPropagation rather than the keyboard registry: the registry would mean wrapping every ChatInput test render in a provider, and the effect is the same because the editor's shortcuts listen on window. There's a test for that too, and I checked it in the browser with a step open in the code editor: Escape closes only the menu. Happy to switch if you'd prefer the registry anyway.

[elias-ba]

This reads as a lint, but Apollo's qa reviews the workflow against what it is meant to do, and its body has the job code agent fix every step on the way through. So someone who picked "review for bugs and risky patterns" gets their job code rewritten. I've asked about the skill itself on OpenFn/apollo#711, so it may change on that side first, but whichever way it lands the menu line and the skill should say the same thing.

[hanna-paasivirta]

Agreed. Apollo #711 now makes /qa report first and fix only when asked, and the menu line reads "Review this workflow and list what should change" to match.

[elias-ba]

Small one, but this comment is the only thing keeping our list in step with Apollo's. Apollo splits its skills folder by whether the frontmatter has metadata.agent, and only the ones without it can be asked for by name. OpenFn/apollo#711 adds qa-code, which has a SKILL.md at exactly the path described here and would still come back as a 400. Could this say a skill folder with no metadata.agent?

[hanna-paasivirta]

Good point, reworded to say a skill folder with no metadata.agent.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.5%. Comparing base (e0b92ae) to head (199a500).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #5236   +/-   ##
=====================================
  Coverage   91.5%   91.5%           
=====================================
  Files        465     466    +1     
  Lines      23787   23803   +16     
=====================================
+ Hits       21756   21776   +20     
+ Misses      2031    2027    -4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hanna-paasivirta]

Thanks @elias-ba! Apollo #711 goes out first: old Lightning never sends skill and ignores the returned history, so deploying Apollo on its own changes nothing. I've put the order in the PR body. Syncing the skill list from Apollo later would remove the constraint altogether.

Changelog entry added, the landing-screen note is gone, and the branch is up to date with main.

[elias-ba]

Nice job @hanna-paasivirta. Thanks for taking into account the changes