calumjs

The ARMADA builder. Works a single GitHub issue end-to-end: research, plan, implement in an isolated git worktree, validate with the project's own build/test/lint commands, and open a PR. Trigger when the user says "work on issue", "pick up #123", "build this issue", "implement #123", "start on the backlog item", references a GitHub issue number to implement, or invokes /shipwright. Also the default target that crows-nest dispatches to. Has an address-review mode: given a PR and its review comments, it triages each (agree/discuss/disagree), implements the agreed changes, re-validates, pushes, and replies per thread — triggered by "address review comments", "respond to the review", "fix the PR feedback". Accepts a GitHub issue number, a free-text description, or a PR number plus review findings. Stack-agnostic — it runs whatever build/test commands the repo configures.

The ARMADA cartographer. Owns *per-repo* knowledge: it mines completed fleet runs for reusable, actionable heuristics and maintains a reviewable knowledge base under `.armada/cartography/`, so the fleet specialises to a repo over time without anyone hand-writing AGENTS.md guidance. It analyses one completed run from the evidence already on the issue/PR — the original issue, the PR diff, commit/retry history, muster + human review comments, build/test failures, and the resolution path — and emits `heuristic / evidence / confidence` entries, paying special attention to human corrections, repeated failures, and repeated successes. It dedupes, updates, and prunes against existing cartography, then commits the changes into the active ARMADA PR so they ride the muster review + autoMerge gate. shipwright reads cartography before building; crows-nest auto-runs it (best-effort, side-channel) at its reconcile points when the `cartography` config key is on. Trigger when the user says "learn from this run", "update the c

The ARMADA inspection before sailing. Reviews an open pull request through two independent lenses in parallel — a conventions/correctness code-review pass and a codex-rescue root-cause second opinion — consolidates and dedupes the findings, posts them as inline PR review comments plus a top-level summary, and returns the findings as structured data for the fleet to act on. Trigger when the user says "muster", "review this PR", "inspect the diff", "run a review pass", "review PR #123", or invokes /muster. Also the review stage that crows-nest dispatches inside its ready-PR pipeline. Accepts a PR number (or the current branch's PR) and an optional review effort level.

The ARMADA lookout. A single, maximally parallel scheduler that watches two tracks over a GitHub repo at once: a new-issue track that dispatches each labelled issue into the fleet to be built, and a ready-PR track that drives each labelled pull request through a review → address → re-validate → gated-merge pipeline. Runs as a recurring watch via /loop: each tick scans both tracks in one batched scan, builds a dependency/conflict graph spanning them, and dispatches every independent runnable unit — builds and reviews together — concurrently up to a bound, serialising only where a true dependency or file-level conflict forces it. Can also run an opt-in public-intake track that screens unsolicited issues from the general public for prompt-injection and abuse, then re-authors the safe, good ones as fresh chartered issues. Trigger when the user says "watch for issues", "start the crows-nest", "keep an eye on the backlog", "listen for new issues", "watch for ready PRs", "review and merge PRs", "screen public sugges

The ARMADA lighthouse — the fleet's autonomous reconnaissance. Every other ship is reactive (shipwright builds existing issues, muster reviews existing PRs); lighthouse is the one that *proactively finds* work. It surveys the repository for valuable future work — failing/skipped tests, TODO/FIXME, missing coverage, stale or contradicted docs, dependency/security smells, architectural gaps, recurring pitfalls — and, when the app is runnable, explores it live with Playwright to surface UX/functional findings (degrading to static-only when there's no runnable app). It turns each high-value, non-duplicate finding into a well-formed GitHub issue via the charter flow, filed UNARMED by default (charter --no-arm) so a human review stays the gate. Every run is bounded by a configurable budget (runtime, Playwright time, issues, findings) and reports what it did and did not cover. crows-nest dispatches it opportunistically as low-priority background work only when the fleet has spare capacity; existing build and review

The ARMADA sea-trial — the shakedown run. The fleet's true RUNTIME verification step: beyond unit tests, lint, and static validate, it actually LAUNCHES the project's app (via .armada/config.json → commands.run) and DRIVES a real user flow with Playwright to prove a change behaves correctly live — then reports pass/fail with evidence (screenshots, console/network errors). It is the runtime layer on top of shipwright's own validate step and the repo-local `verify` skill: green tests prove the code compiles and the old assertions still hold; sea-trial proves the change actually works when a user drives it. Every run is BOUNDED by a runtime budget and is READ-ONLY w.r.t. the fleet/source tree — it launches and drives the app, it never Writes/Edits, stages, or commits; the project commands it runs are fenced on a clean checkout and their side effects are never committed. It DEGRADES GRACEFULLY: no runnable app (no commands.run) → skip with a clear note; no Playwright/ browser → launch-only smoke, no drive; a rout

Commission the ARMADA fleet in the current repository — the one-time (idempotent) setup that every other ARMADA skill depends on. Detects the project's build/test/lint/run commands and base branch, writes .armada/config.json, creates the GitHub trigger + state labels, checks gh auth, and prints how to arm the crows-nest watch. Trigger when the user says "commission armada", "set up armada", "initialise armada", "armada bootstrap", "get armada ready", just installed the ARMADA plugin, or invokes /commission. Also auto-invoked by crows-nest and shipwright when they find the repo isn't commissioned yet. Safe to re-run.

The ARMADA lookout's instrument — a live, procedurally-charted view of the fleet. Renders the whole armada:* label state machine that crows-nest runs as a beautiful, animated sea-chart in the browser: the horizon (new-issue track), the harbour (ready-PR pipeline), the crows-nest vantage (the scheduler's current tick — what's dispatched / held and why), and an optional cartography layer (the repo's learned chart). It reads the SAME GitHub state crows-nest scans (§2a) into a fleet-state.json and never mutates anything — it is a view, not a controller. Ships move through their real states; the coastline is procedurally generated and seeded from repo identity (stable run-to-run); weather reflects fleet health (storms when units are blocked). Trigger when the user says "show the fleet", "open spyglass", "visualise the armada", "watch the fleet on a chart", "fleet dashboard", "what's the fleet doing", or invokes /spyglass. Accepts an optional trigger label (defaults to .armada/config.json) and an optional watch cad

Process a VTT transcript into a comprehensive, multi-tab HTML dashboard using specialized analysis agents. Use when the user provides a .vtt file, has a transcript to process, or mentions a meeting recording. This is the PRIMARY skill for handling transcripts.

Extract insights from a meeting transcript including summary, action items, decisions, and key topics. Use when the user wants to analyze a transcript, extract meeting notes, find action items, or summarize a meeting.

Deploy a meeting dashboard to surge.sh for public sharing. Use when the user wants to deploy, publish, share, or host a dashboard online.

Generate an HTML dashboard from meeting analysis. Use when the user wants to create a visual summary, build a dashboard, generate a report, or visualize meeting insights.

List all projects and their meeting history. Use when the user asks about projects, wants to see what meetings exist, or needs an overview of the workspace.

File a VTT transcript into the correct project folder. Use when the user provides a .vtt file, mentions a meeting transcript, or says they have a recording to process.

Examine a room, the body, or an object for physical clues in the current murder mystery. Use when the user says "examine <place>", "search <room>", "inspect <object>", "look at <place>", "check the body", or runs /examine.

Question a suspect in the current murder mystery. Use when the user says "interrogate <name>", "ask <name> about ...", "question <suspect>", "talk to <suspect>", "press <suspect>", or runs /interrogate.

Start a new murder mystery game — invent a fresh cast and crime, fairly pick the murderer, and seal the solution so it stays hidden. Use when the user says "start a murder mystery", "new case", "deal a mystery", "let's play detective", "begin the whodunit", or runs /start-case.

Make a final accusation to solve the murder mystery. Use when the user says "accuse <name>", "I accuse ...", "it was <name>", "my answer is <name>", "the murderer is <name>", or runs /accuse.

Show the sealed-room high-scores table — past games, their scores, and how they were solved. Use when the user says "scores", "high scores", "leaderboard", "show the scores", "my stats", "score table", or runs /scores.

Review the public briefing and suspect list for the current murder mystery. Use when the user says "case file", "show the briefing", "who are the suspects", "recap the case", "remind me of the suspects", or runs /case-file.

Generates and maintains a public-facing static website for a GitHub repo. Use this skill when the user wants to set up Docent, update the Docent site, write a journal post or digest, generate release notes, triage new issues, or file feedback about Docent itself (the "suggest" mode). Also triggers on mentions of "docent site", "docs site update", operations on /docs/content/ in a repo that has docent.config.json, or phrases like "I want to suggest something about Docent" / "report a Docent bug".

Semantic search for code and engineering context — find implementations, docs, and synced GitHub issues/PRs by meaning, not just keywords. Use when searching for concepts, understanding how things work, or locating code that grep can't find.

Reverse-engineer the prompt that most likely produced a given piece of text. Fans out many subagents that each guess a candidate prompt, runs each guess one-shot in a clean room (the executor never sees the target), scores the output against the target, then steers the best candidates over several rounds until the reproduction matches as closely as possible. Trigger when the user says "reverse engineer this prompt", "what prompt produced this", "guess the prompt", "reverse prompt engineer", or invokes /reverse-prompt-engineer. Accepts: the target text (required), and optional tuning — fanout, rounds, keep, threshold.