unifylabs-dev

humanizer

Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, passive voice, negative parallelisms, and filler phrases.

analyze-comms

Analyze incoming communications (emails, PDFs, vendor messages, client messages, legal reviews) against full project context. Produces structured reports with implications, risk assessment, and action items. Optionally drafts humanized replies and proposes repo updates. Use when the user says "/analyze-comms", "analyze this email", "review this communication", provides an incoming message to analyze, or pastes vendor correspondence, client emails, or legal feedback that needs project-context analysis and response.

extract-prototype-review

Extract acceptance criteria and visual specs from a *sanctioned* prototype branch (under `prototype/*`, with a Draft PR + screenshots, where the junior intentionally skipped auth/validation/tests per CLAUDE-PROTOTYPE.md) and create a GitHub issue for `/work-issue` to implement. Use when the user says "/extract-prototype-review <branch>" with a prototype branch name. For non-prototype external branches that need standards-compliance auditing and routing (salvage / rebuild / discard), use `/integrate-branch` instead. (Formerly `/review-prototype` — renamed to clarify scope: this skill *extracts specs from* a prototype; `/integrate-branch` is the true *review-and-integrate* skill.)

handoff

Write a structured session-handoff doc so a fresh Claude session can resume the current work cold — same decisions, same task state, same world state, same do-not-re-litigate guardrails. The canonical response when conversational context gets full and quality starts degrading. Use proactively when the user says or clearly implies any of: explicit slash commands (/handoff, /handoff-resume, /handoff-list, /handoff-done, /handoff-revive, /handoff lean, /handoff emergency); context-pressure framings ("getting close to context limits", "this convo is getting long", "save the session state", "dump what I've got so a fresh session can pick up", "context rescue", "session transfer"); mid-mode framings ("im in the middle of orchestrating", "about to checkpoint this phase mid-flight", "this brainstorm is getting deep, wanna save it", "i need to bail out of this session"); or resume-side language ("yesterday i left off mid-something, can you pick up", "what was i working on", "there's a pending handoff somewhere", "pick

integrate-branch

Take an external/untrusted branch (built outside the standard workflow — by a junior dev with GSD, a contractor, a quick spike, etc.) and audit it against the full set of project standards plus cross-cutting impact on other features, then route to one of three execution paths: salvage (fix the existing code in place via /work-issue), rebuild (extract specs to an issue and rebuild from scratch via /extract-prototype-review + /work-issue), or discard. Every successful invocation ends in a PR that meets every CLAUDE.md standard, OR a documented decision to discard with rationale. Use when the user says "/integrate-branch <branch>", "audit and integrate this branch", "is this branch safe to merge", or has a branch from outside the standard workflow that needs to be brought up to standards.

iterative-review

Iterative review-fix-verify loop for code, docs, and phasing-run artifacts. Runs review → fix → verify → re-review with severity-gated stopping: Critical always gates the user, Important auto-fixes by default (per-finding flip available), Suggestions surface in the report only. 3-iteration hard cap, skip-if-clean pre-gate (avoids the Snorkel self-critique 41pt accuracy drop), fixed-point early exit, 5× token-budget circuit breaker. Auto-detects mode: code (PR or local diff), doc (.md / .txt / .rst / specs/ / docs/), or phase (phasing-run deliverables vs. spec). In phase mode, plan-affecting findings flow through the existing handoff "Open questions for downstream" channel without modifying the locked master plan. Use when the user says "/iterative-review", "review and fix", "loop the review", "verify phase N output", "review the spec against the PR", or wants more than a one-shot review. Use proactively after `/pr-review-toolkit:review-pr` returns Critical findings or after a phasing phase completes and its d

phasing

Orchestrate multi-phase work across fresh Claude sessions with mandatory plan-mode gating and self-verification. Use this skill whenever a user has a plan or task that touches multiple subsystems, has natural break points, would benefit from re-grounding mid-execution, or when the user wants to stay in the loop on every decision instead of dispatching subagents. Trigger this when a presented plan looks too big for one execution, when the user invokes /phase, or when a user mentions phasing, breaking work into chunks, multi-step implementation, or wanting fresh context between work units. Even if the user doesn't explicitly say "phase it," consider this skill whenever a plan spans backend + frontend + DB, has 8+ task items across different domains, or where context rot in a single session is likely.

ship

Commits staged and unstaged changes, pushes to origin, and creates a pull request in one command. Use when the user says "ship", "ship it", "commit and PR", "push and PR", or wants to complete the git workflow quickly.

spec-it

Turns a raw feature idea into a `/work-issue`-ready GitHub issue with an embedded draft spec, grounded in repo + memory + external standards research. Mirrors `/work-issue`'s gated phased workflow but UPSTREAM of it — `/spec-it` produces the issue, `/work-issue` implements it. Adapts to whatever spec conventions the target repo defines (optics-style behavioral modules+journeys, unify-kit-style numbered specs, ADR-style decision records, or none → bootstrap from kit templates). Use when the user says "/spec-it <one-liner>", "/spec-it" with no args, "draft a spec for ...", "turn this idea into an issue", "I want to add <feature>", "create an issue for this", or otherwise wants to start a new feature/fix/process change from scratch. Also use proactively whenever the user describes a not-yet-tracked feature idea before `/work-issue` would have an issue number to consume. Strongly prefer this over filing an issue manually — it grounds the spec in research and enforces the project's spec discipline.

work-issue

Orchestrates GitHub issue-driven development with 8 gated phases: issue analysis, branch creation, planning, strict TDD implementation, verification, automated acceptance testing, review, and PR creation. Use when the user says "/work-issue 83", "work on issue 83", "pick up issue 83", or wants to start working on a GitHub issue. Also use when the user mentions working from GitHub issues, linking branches to issues, or issue-driven development.

promote-to-marketplace

Move a personal skill or hook from ~/.claude/ into the unifylabs-workflow marketplace plugin so the rest of the team gets it. Use when the user says "/promote-to-marketplace <name>" or wants to share a skill/hook they created locally.