with one click
autospec
autospec contains 37 collected skills from berlinguyinca, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
Use when the user wants to plan a feature — bootstrap repo if missing, brainstorm a design spec, decompose into linked GitHub issues, or split an existing spec into issues. Stops after Phase 3 and hands off to /autospec-run for autonomous implementation.
Use when the user has already run /autospec-define (or otherwise has a populated set of auto-implement GitHub issues) and wants the implementation half — Phases 4-6 — to run autonomously with admin auto-merge. Supports --profile <name> filtering against ~/.autospec/model-profiles.yml.
Use when the user wants /autospec-autonomous to run the autospec machinery unattended for weeks — a perpetual self-driving conductor that walks a never-idle priority waterfall (Tier 0 control channel + Tier 1 backlog→main + Tier 1.5 open-issue promotion + Tier 2 local discovery + Tier 3 architecture/coverage improvement + Tier 4 internet/operator discovery + capability-gated Tiers 5-7 growth outbound/define/measure), parks before quota exhaustion, obeys a GitHub control channel for live steering, and resumes automatically.
Use when the user wants to revalidate a running app against a spec, regenerate missing or weak tests, audit UI controls/forms/validation/dropdowns/API behavior/accessibility, or prove implemented features actually work after autospec-run.
Observe a live autospec-autonomous conductor read-only by summarizing typed status, timeline, launch, heartbeat, tier, and discovery artifact surfaces.
Use when Autospec runtime provisioning detects Docker Compose files that require migration for isolated worktree environments.
Use when the user wants to ship a feature end-to-end across multiple commits — bootstraps repo if missing, brainstorms a design spec, decomposes into linked GitHub issues, or splits an existing spec into issues, then runs an autonomous implementation loop with auto-merge.
Use when the user wants to retro-apply autospec's Phase 3.5 model-fit rubric to already-existing auto-implement issues — walks open issues in the current GitHub repo, classifies each with ctx:* / reasoning:* labels, and inserts a
Use when the user wants /autospec-explore to start a perpetual autonomous research + ship loop on an isolated sandbox branch — 7 universal + 4 discovery (quality-resilience, dogfooding, self-leverage, style-normalization) + N domain-specialist researchers propose features and defects from spec/code gaps, prior reports, codebase signals, open issues, repo source analysis, dependency health, competitor research, live run-state, frontend style drift, and domain lenses, are filtered through an adversarial verify + ROI + severity-first rank, then drain via /autospec-run with PRs targeting the sandbox branch (never main). Can also be reached via an explore/discover build-intent phrase through autospec-listen (which requires one explicit confirmation first), but is not a bare-keyword trigger on its own.
Use when the user wants to supervise autospec-run across multiple GitHub repositories from an empty workspace - initializes fleet config, clones or syncs repos, and runs per-repo autospec-run workers.
Use when a fresh process must detect an interrupted autospec run from durable run-state plus heartbeats and auto-continue it after a host, session, or terminal crash — without adding a second lock, without stealing a genuinely-live worker on another host, without deleting un-pushed work, and capped at AUTOSPEC_RESUME_MAX_ATTEMPTS (default 3) consecutive attempts. Supports --resume-partial, --repo <owner/name>, and --dry-run.
Use when the user wants to generate, regenerate, or audit per-audience project documentation (user, developer, admin, general) as docs-as-tests — incremental by default, with --full, --audit, --audience <name>, and an init scaffolder. Single-source palette, verified examples, and llms-full.txt output. Hands generation to doc-orchestrator.mjs.
Use when you want to run disciplined no-mock Playwright UI-test authoring (Stage 2A) for a project. Detects the .autospec/test.yml authoring blocks, invokes autospec-test Stage 2A, and prints the coverage report.
Use when the user wants to refine a prompt or feature request over N rounds of repo-grounded lenses before handing off to /autospec for implementation. Supports --rounds, --lenses, --autonomous, --interactive, --dry-run, and --continue (continuous iteration mode).
Use when a project needs first-run autospec configuration, recurring spec-vs-reality sweeps, or continuous improvement across docs, tests, and code health.
Use when the user wants to upgrade an Angular, Next.js, or React project to the latest official versions safely — by locking observable behavior before touching versions, upgrading one major at a time with official codemods, and gating completion on mutation score rather than coverage theater.
Use when the user wants to run diagnostics on the optional autospec-db telemetry module — resolves the `autospec-db` binary (PATH, then `~/.autospec/bin/autospec-db`), runs `autospec-db doctor`, and maps each reported FAIL to a concrete operator fix. Degrades gracefully (prints the install one-liner and stops) when the binary is not installed. Never echoes a DSN.
Use when the user wants to autonomously implement, validate, and release parametric 3D / CAD-as-code features whose output is 3D-printable STL — proven watertight, structurally sound, fluid/airflow-correct, and visually inspected — across any repo that opts in via `.autospec/fab.yml`.
Drain the growth backlog — implement growth:artifact issues via /autospec-run with a content-quality gate, run the growth:outbound draft→ethics→approval-queue pipeline (package-only, never auto-post), and measure/attribute via live adapters that re-weight the next define cycle. Use after /autospec-grow-define has filed issues.
Use when the user wants /autospec-grow-define to run the planning half of the autospec-growth pipeline for a product opted into `.autospec/growth.yml` — sync/measure current metrics, fan out the 6-lens growth researcher roster (technical-seo, keyword-gap, content-opportunity, community, directory, backlink), adversarially verify + ROI/severity-rank candidates through the deterministic pipeline, then decompose survivors into linked GitHub issues (growth:artifact / growth:outbound). Stops after decomposition and hands off to /autospec-grow-run for autonomous drain.
Inspect, guide, pause, resume, and understand local Autospec autonomy work through existing scripts and GitHub issue comments when explicitly confirmed.
Use when the user wants to audit design specs against open + closed issues to find gaps, file high-priority regression issues, and feed them back through autospec. Runs as `/autospec-review` (manual) or auto-fires after each autospec-run batch unless `~/.autospec/no-review.flag` exists.
Use when a repo needs an end-to-end release readiness sweep across specs, docs, implementation, tests, QA proof artifacts, legacy cleanup, and merge readiness using existing autospec skills.
Use when the user expresses an imperative intent to file an issue, write a spec, design a feature, implement/build/ship something, review code, or run autospec mid-conversation. Trigger keywords are "file an issue", "new issue", "open an issue", "create a ticket", "write a spec", "design spec", "new spec", "start a spec", "design", "new feature", "implement", "build", "ship", "review", "autospec". On an "issue" trigger, drafts a body from the last ~10 conversation turns and asks the user to approve before running gh issue create. On a "spec" trigger, hands off to /autospec-define. On a build/change verb, gates intent via the deterministic listener-match classifier and auto-routes to the mapped autospec skill with a one-line opt-out. Lives at github.com/berlinguyinca/autospec/skills/autospec-listen.
Use when the operator wants to calibrate autospec to their judgment — runs a repo-grounded calibration interview (≤50 questions in themed AskUserQuestion batches), interleaves calibration questions whose answers are inferable from memory/charter to measure agreement, and writes ~/.autospec/operator-persona.answers.json. Resumable — re-running continues at the next pending batch and never re-asks done batches.
Use when the user wants to run a single task repeatedly in a loop until a goal is reached — "loop until the build passes", "keep going until done", "run X in a loop until Y". Interactively refines the request into a frozen contract, then runs a goal-conditioned loop with conservative guardrails. Claims goal/completion loop phrasings; defers bare interval polling ("loop every 5m") to the native /loop.
Use when you need to provision an isolated, scaled-down, anonymized clone of a production environment for autospec-test E2E testing (Mode II). Handles snapshot capture, PII anonymization, edge-case data seeding, and URL exposure.
Use when the operator wants to harmonize a codebase's design tokens — discover palette/type/spacing drift, generalize a baseline design, generate variants (minimal, high-contrast, dense, bold), preview them, and produce a dated migration spec. Triggers on "harmonize design", "design tokens", "style drift", "palette inconsistency", "design migration spec".
Reports current context % and last rollover event for the active autospec-session monitor. Use when the user asks about context status, rollover status, how close to rollover, or whether a compaction/handoff is imminent.
Use when the user wants to split an existing tracked docs/specs/*.md design spec into GitHub issues, then stop after Phase 3.5 and hand off to /autospec-run.
Use when the user wants to halt a running autospec monitor gracefully or immediately — writes the ~/.autospec/stop.flag sentinel so the monitor exits after the current issue (--graceful) or aborts at the next step boundary (--immediate). Also supports --status, --resume, and inline stop sub-mode matching `^\s*stop(\s+--\w+)*\s*$`.
Use when the user wants a repo-level product story, implementation-state overview, or narrative synthesis from local specs plus GitHub issues and PRs for the current repository.
Use when you want to gate every Phase 4 PR on unit + E2E test coverage against an isolated environment, auto-heal coverage gaps within a 60-minute coding budget, and block assertion-loosening rewrites before auto-merge.
Use when the user wants to inspect, rebuild, or act on the autospec-explore outcome ledger — the recursive-self-improvement memory that records which research sources actually ship clean PRs, derives dynamic source weights, and produces a learnings memo. Subcommands — show, stats, rebuild, weights, learnings.
Use when the user wants to scan generated code for security vulnerabilities, secret/credential leaks, IP/copyright/license violations, PII/data leaks, SQL injection, prompt injection, and backdoors. Runs as `/autospec-secaudit` (manual repo-wide sweep) or auto-fires after each autospec-run batch unless `~/.autospec/no-secaudit.flag` exists. Also powers the blocking Phase 4 per-PR gate.
Use when the user wants /continue to extract the most recent assistant message's actionable recommendation, pipe it through /autospec-refine, and hand off to /autospec --autonomous for end-to-end implementation. Supports --skip-refine, --ask-confirm, --lens-mode, and --from-message.
Use when the user wants to adopt a vendor design language for the current repo — fetches the per-vendor DESIGN.md from the berlinguyinca/awesome-design-md catalog, scores the repo against candidate vendors, writes DESIGN.md at the project root, and optionally hands off a migration spec to /autospec-define. Subcommands suggest, apply, and migrate.