fwd-skills

Implements exactly ONE feature of a mission inside the mission worktree, following the existing codebase patterns, then commits it on the mission branch with a conventional message and returns a structured handoff. Spawned by either mission orchestrator — serially by fwd:mission-run, or into a per-feature slot worktree by fwd:mission-run-parallel (where sibling coders run concurrently; sibling awareness arrives via the spawn prompt). Never pushes, never opens PRs, never asks questions.

Adversarial code reviewer for a completed mission milestone. Reads the milestone's diff and judges each scrutiny-review assertion (VC-ID) from the validation contract PASS or FAIL with concrete evidence. Has never seen how the code was written. Structurally cannot modify code — it only judges. Spawned by the fwd:mission-run orchestrator.

QA-style user-testing validator for a mission milestone. The app is already running (the orchestrator booted it); this agent exercises it end-to-end via CLI/HTTP (and Playwright if the project has it) and judges each user-testing assertion (VC-ID) PASS or FAIL with evidence. Read + execute only — never modifies code, never boots or kills the app. Spawned by the fwd:mission-run orchestrator.

Stage and commit with conventional message — pre-flight scan blocks risky files (.env, logs, keys, secrets, >1MB)

Interactief een GitHub issue opstellen volgens een vast 5-secties template (probleem, voorbeelden, bevindingen, potentiële oplossing, tests). Skill leest input uit een argument óf de huidige conversatie-context, detecteert bestaande repo-labels, vraagt om een assignee, en laat de gebruiker de complete draft per sectie reviewen voordat `gh issue create` wordt aangeroepen. Use when user wants to create a GitHub issue from a problem they are describing, runs `/fwd:issue-create`, says "maak een issue", or "create issue from context".

Privately work through your assigned GitHub issues overnight — pick the oldest open issue, fix it in an isolated worktree, run tests, commit (no push). Driven by /loop. Strictly read-only on GitHub (no labels, no comments, no PRs) so collaborators can't tell the work was automated; all state local in `.claude/issue-loop/state.json`. Use when user says "work through my GitHub issues overnight", runs `/loop /fwd:issue-fix`, or invokes `/fwd:issue-fix` to fix one issue.

Plan a multi-agent "mission" — scope a software goal through conversation, write a PRD plus a validation contract (what "done" means, before any code), decompose into features and milestones, then create the mission branch and persist the plan on it. The interactive half of the fwd:mission-* orchestration layer (modelled on Factory.ai Missions); execution is handled afterwards by /fwd:mission-run. Use when the user wants to plan a larger feature as an orchestrated mission, says "plan a mission", "start a mission", "scope this as a mission", or invokes /fwd:mission-plan.

Execute a planned mission in parallel waves — the opt-in, faster, riskier sibling of fwd:mission-run. Reads a v2 mission (one that has depends_on fields) and executes independent features concurrently: each wave spawns up to FWD_MISSION_MAX_PARALLEL (default 3) coder subagents, each in its own slot worktree, then integrates their work sequentially onto the mission branch through the unchanged record-feature machinery. Uses the same state.json checkpoint format, same adversarial validators, and same milestone boundaries as fwd:mission-run — switching runners between ticks is safe. Use when the user runs /fwd:mission-run-parallel <slug>, says "run mission <slug> in parallel" or "wave-based parallel execution", and the mission plan contains a dependency DAG. Refuses v1 missions (no depends_on anywhere) with a clear pointer to /fwd:mission-run. Typing this command is explicit risk acceptance: parallel coders are blind to each other, missed plan dependencies cost conflict round-trips, and tokens do not drop with wall-clock.