nearform

Keep Last Light's docs in sync with the code. Use before committing changes to apps/server/workflows/, skills/, config/default.yaml, src/connectors, src/state, src/engine/router.ts, src/config/, packages/cli/src, packages/shared/src (providers/overlay helpers), or agent-context/ — or whenever the docs-check pre-commit hook fires. Maps each changed file to the doc surfaces it affects (the in-repo apps/server/spec/*.md AND the apps/www site) and updates them.

Install the `lastlight` CLI and connect it as a CLIENT to an existing Last Light server — log in, save the token, and verify the connection. Use when the user wants to "connect / point my lastlight CLI at a server", "log in to Last Light", "set up the lastlight client", or run lastlight commands against a remote instance. For standing up the server itself use lastlight-server; for editing a deployment's config use lastlight-overlay.

Debug a running Last Light instance over its admin API with the `lastlight` CLI — no SSH. Use when the user wants to "look at / debug a failed or stuck workflow", "why didn't the bot do X", "check a bad agent run / phase error on <instance>", "tail a session", "search the logs", "read the server/docker logs", "list/trigger a cron", "resolve an approval", or "check stats/cost" against a deployed server. Needs a CLI already connected (see lastlight-client to log in). For standing up the server use lastlight-server; for editing config/workflows use lastlight-overlay.

Orientation & router for the Last Light skills. Use ONLY when the user has NOT named a concrete Last Light task — i.e. they're unsure which skill/flow they need, ask "what can Last Light do / where do I start", say "help me with Last Light" with no specific goal, or want a guided tour across server / client / overlay / debug / evals. Do NOT use when the ask already names a task — "set up/deploy a server" → lastlight-server, "connect/log in my CLI" → lastlight-client, "customize a workflow/prompt/persona/config" → lastlight-overlay, "debug a failed/stuck workflow or run on an instance" → lastlight-debug, "run evals / compare models / author a case / build a PR-review dataset" → lastlight-evals, "iteratively improve an eval toward a target score" → lastlight-evals-loop: invoke that skill directly. This skill only routes and, when the goal is ambiguous, asks. Also invocable as /lastlight-guide.

Install and configure a Last Light SERVER — the GitHub maintenance agent plus its docker-compose stack — on a host. Use when the user wants to "set up / install / deploy / stand up a Last Light server or instance", configure its GitHub App, models, managed repos, or domain, or get the agent running for the first time. Drives the `lastlight` CLI; for connecting an existing CLI to a server use lastlight-client instead, and for editing a running deployment's config use lastlight-overlay.

Drive a Last Light EVAL toward a target score with a disciplined, anti-gaming improvement loop — run → mine failures → propose candidate fix(es) → re-measure → keep the best or revert → repeat. Use when the user wants to "improve / raise the pr-review F1", "make the reviewer better against the eval", "close the loop on evals", "iterate on prompts/skills to pass more cases", or "tune the workflow to hit a score target". The loop diagnoses on a TRAIN split and validates on a BLIND held-out split so fixes must generalize, not overfit; it prefers generic overlay prompt/skill edits, and stops for human sign-off before editing any gold answer. For a one-off run/compare use lastlight-evals; to hand-fork a workflow/prompt use lastlight-overlay. Needs an already-scaffolded evals workspace (lastlight-evals) with a pr-review dataset.

Scaffold, configure and run a Last Light EVALS workspace — the harness that runs Last Light's real workflows against a mocked GitHub and grades them deterministically. Use when the user wants to "set up / scaffold Last Light Evals", "create an evals workspace or instance", "run evals", "compare models", or author new eval cases — including "create an eval dataset/case from this PR/issue <github url>" and "create a PR-review eval dataset from these gold PRs" (triage / code-fix / pr-review instances, via `add-case --pr <url> --review|--code-fix` / `--issue`). GitHub is mocked when running, so no real GitHub token is needed — only a model provider API key (the one exception is `add-case`, which reads real PRs/issues via `gh`).

Create or customize a Last Light deployment OVERLAY (the private instance/ repo) — scaffold it, then fork built-in workflows, prompts, skills, or the agent persona (agent-context) so a deployment can override them. Use when the user wants to "create a Last Light overlay / instance repo", "customize / fork a workflow", "override a prompt or skill", "change the agent's persona/soul/rules", or tune a deployment's config without forking the whole codebase. For first-time server install use lastlight-server.

Use after unwind:uw-plan to EXECUTE the rebuild — interview the user about scope/order/target, dispatch technology-agnostic per-layer builder agents that reproduce the [MUST] contracts in the target stack, hold rebuild state in a local file, and maintain a source→target verification graph that measures completeness. Supports a loop-until-verified mode.

Use to visually explore the rebuild knowledge graph. Builds and launches the Unwind dashboard (React + React Flow + ELK) pointed at docs/unwind/rebuild-graph.json with coverage, priority, and contract views.

Optional. Publish the Unwind dashboard to the scanned project's GitHub Pages gh-pages branch so it's viewable at https://<owner>.github.io/<repo>/unwind/. Builds the dashboard at the correct sub-path and commits it into an `unwind/` subdir — never blatting an existing gh-pages branch. Confirms the target, then pushes.

Use when dispatched by unwind:uw-build to rebuild ONE layer/slice of a codebase in the target stack. Technology-agnostic builder that reproduces the layer's [MUST] contracts (API surface, data model, business rules) as idiomatic target-stack code and records the source→target mapping for verification.

Use when starting any reverse engineering task - establishes how to find and use Unwind skills for codebase analysis, service mapping, and documentation

Use after layer analysis is complete to interview the user about the rebuild strategy (target stack, what to keep vs rebuild, phasing, risk) and generate a data-grounded REBUILD-PLAN.md that records those decisions.

Start here. The entry point for reverse-engineering a codebase with Unwind — orients you, checks prerequisites, handles restart vs update, then runs the rebuild pipeline (scan → analyze → plan → dashboard) with a checkpoint at each phase. Use when beginning Unwind on a repo, or when unsure which uw- skill to run first.

Use when analyzing build/dependency config, runtime configuration, program entrypoints, and deployment/ops assets the rebuild must reproduce

Adapt existing designs to work effectively across different contexts - different screen sizes, devices, platforms, or use cases. Use when the user needs responsive adaptation or cross-platform design changes.

Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight. Use when the user wants to add motion or animation to their interface.

Run systematic quality checks and generate a comprehensive audit report with prioritized issues and actionable recommendations. Use when the user wants to assess design or code quality.

Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming. Use when the user wants to make their design more striking or memorable.

Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use. Use when the user wants to improve UX copy or microcopy.

Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality. Use when the user wants to add or improve color in their interface.

Conduct a holistic design critique, evaluating whether the interface actually works as a designed experience. Use when the user wants design feedback or a design review.

Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences. Use when the user wants to add delight or personality to their UI.

Use this skill when writing or reviewing BDD/Cucumber feature files and step definitions. It keeps Gherkin declarative and behaviour-focused, keeps step definitions thin, and delegates all framework mechanics (selectors, waiting, network, assertions) to the matching framework skill.

Generate reviewer-ready, traceable test cases from Jira issues using an available Jira MCP server.

Compress a supplied text (pasted or a file path) to its load-bearing minimum: remove filler, keep every claim, qualifier and scope. EXPLICIT INVOCATION ONLY: use only when the user names the skill; never auto-trigger on generic requests to shorten or tighten text, and never apply to your own chat replies.

Compact the current conversation into a handoff markdown document for another agent or session to pick up. Use when handing off a side task, spawning a prototype session, passing work to a different agent (Cursor, Codex, GitHub Copilot CLI, Claude Code), or keeping the current session focused while continuing work elsewhere. Also use when the user says handoff, hand off, or wants a handoff document.

Scaffold a new Python project that follows modern best practices, using uv by default to initialize and manage the project (with pip/venv, pipenv, or manual fallbacks if uv isn't available). Sets up ruff (lint + format), mypy type checking, pre-commit, a tests/ folder with pytest, and optionally Docker, a CI workflow, coverage, placeholder structure, and a git repo with .gitignore. Use when the user wants to start/create/bootstrap a new Python project, says "set up a Python project", "init a python repo", "new python project with best practices", or similar.

Use this skill when writing, reviewing, or refactoring database queries with @nearform/sql — Nearform's tagged-template library that produces SQL-injection-safe parameterized queries for pg, mysql, and mysql2. Covers installation, the SQL tag (.text/.sql/.values/.debug), helpers (glue, map, unsafe, quoteIdent), Fastify integration, dynamic/bulk queries, and security best practices. Trigger terms: SQL, query, parameterized query, SQL injection, pg, postgres, mysql, @nearform/sql, glue, quoteIdent.

Rules and frameworks for writing high-quality LLM system prompts. Use this skill whenever you are authoring, reviewing, editing, or optimizing a system prompt — including when generating a system prompt as part of building an agent, tool, or workflow. Trigger on any task that involves writing instructions for an LLM, crafting a system message, tuning prompt wording, or reviewing an existing prompt for quality. Even if the user doesn't say 'system prompt' explicitly, use this skill when the output will be consumed as LLM instructions.

Assess security advisories against a Git repository by creating an isolated worktree, building a PoC exploit, and validating whether the described vulnerability is real and exploitable. Use when given a CVE, GitHub Security Advisory, or vulnerability description to verify.

The shared rubric for reviewing a code change — finding tiers (Critical/Important/Suggestions/Nits) and what to check (correctness, security, edge cases, regression risk, test coverage). Use when reviewing a PR or a branch diff.

Answer a question directly — a sourced, neutral reply to an information/explanation/comparison request, from a GitHub issue or a Slack thread. Research repo docs and the web, output the answer, label `question` (GitHub only), leave open. Never write an agent brief, mark ready-for-agent, or change code.

Handle a non-build maintainer comment on an issue or PR — close, reopen, label, dedupe, answer a brief question, or triage. Action-only; redirect anything that needs code changes to /build.

Triage GitHub issues through the canonical state machine — classify, label, deduplicate, request missing info, write agent briefs, and manage stale issues. Use on demand or on a triage cron.

Review a GitHub pull request and post one formal review — advance the existing discussion, verify by building, and give tiered feedback. Use when asked to review a PR or on a cron PR scan.

Diff-scoped security review of SDLC concerns GitHub's scanners miss — workflow/CI hardening, auth changes, secret handling, supply-chain churn. Files one dated summary issue with a task-list of findings. Use on a security cron or when asked to scan a repo.

Read-only deep analysis role. Diagnose problems, analyze codebases, and recommend approaches with file:line evidence. Never writes or edits files. Use for build request analysis, complex PR reviews, debugging investigations, and architecture questions.

Pre-flight check before implementation work. Verifies a repo has the foundational dev guardrails (test framework, linting, type checking) the build cycle depends on, and reports a READY / BLOCKED verdict the workflow uses to gate.

Inspect and analyze codebases using pygount for LOC counting, language breakdown, and code-vs-comment ratios. Use when asked to check lines of code, repo size, language composition, or codebase stats.

Review a code change (a PR diff or a working-tree diff) for correctness, security, quality, testing, performance, and docs. Produces a structured verdict; does not post it.

Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.

Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.

Use this skill whenever the user wants to implement an approved fix spec for a failure mode and verify that it works. Trigger on phrases like "implement fm_…", "start the implementation for fm_…", "the spec is approved, proceed", "implement and verify fm_…", or any request to move a failure mode from spec_approved into implemented and verified state. Requires a SPEC.md that has been approved (status fix_approved). Use research-failure-mode first if no spec exists yet.

Use this skill whenever the user wants to investigate a failure mode, understand its root cause, gather evidence from traces, identify what SME input is needed, and draft a fix spec for human review. Trigger on phrases like "research fm_…", "investigate this failure mode", "draft a spec for fm_…", "understand why fm_… is happening", "what's causing fm_…", or any request to move a failure mode from discovered/triaged into a specced, reviewable state. This skill is read-only with respect to agent code — it only reads traces, source, and config, then writes a SPEC.md and updates failure_modes.json status. Use implement-failure-mode after the spec is approved.

Use this skill whenever the user asks to analyze, classify, cluster, or harvest failure modes from a Tracebound trace file (JSONL under `tracebound/<agent>/traces/`). Trigger on phrases like "run analyze-traces", "process this langfuse dump", "cluster the failures in traces/foo.jsonl", "update failure_modes.json from these traces", or any request to batch-process production agent traces into a failure-mode catalogue. The skill takes ONE agent and ONE trace file per invocation, filters traces with negative feedback signals, classifies each into existing or newly-created failure modes (biased toward reuse), and writes back enriched traces + an updated `failure_modes.json` — running `tracebound validate --agent <agent>` after every batch and self-correcting until it passes.

Use this skill whenever the user wants to create a Tracebound adapter — a CLI script that reads a raw traces file (JSON or JSONL) from a third-party system and converts it into the Tracebound on-disk format (one JSONL index file under `tracebound/<agent>/traces/` + one raw file per trace under `tracebound/<agent>/traces/original/`). Trigger on phrases like "create an adapter for…", "write a converter for my traces", "I have traces from X, help me import them", "build an adapter script", or "convert this JSON dump to Tracebound format". The skill inspects a concrete example of the source data, designs the field mapping, and generates a ready-to-run CLI script scoped to one agent.

Write and run Node.js CLI scripts using modern built-in APIs. Use when the user asks to build or run a CLI tool, one-off script, or automation task in Node.js. Enforces zero-dependency best practices: built-in argument parsing (parseArgs), util.styleText for terminal colors, and native Node.js APIs instead of third-party packages.