crustacean-dev

@crustacean-dev source repo

12 skills
0 followers
6 hours ago last updated

▌
Rust · crustacean-dev
Mandatory guardrails for writing idiomatic, production-quality Rust code. This skill enforces zero-tolerance rules for unwrap()/expect(), correct thiserror vs anyhow usage, ownership and borrowing best practices, visibility minimalism (pub(crate) by default), and idiomatic patterns like the Entry API. Consult this skill for ANY task that writes, modifies, reviews, or refactors Rust code — including .rs files, Cargo.toml edits, CLI tools, libraries, error handling rewrites, and porting code to Rust. It catches the recurring mistakes that LLM-generated Rust makes and produces code that passes clippy and looks like it was written by someone who ships Rust in production.

0
installs
▌
Nodejs · crustacean-dev
ALWAYS consult this skill before writing, editing, reviewing, or refactoring any Node.js code. It prevents the most common LLM-generated Node.js mistakes: bare 'fs'/'path' imports without the node: prefix, sync APIs (readFileSync) in async contexts, exec() shell injection, JSON.parse(JSON.stringify()) instead of structuredClone(), Math.random() instead of crypto.randomUUID(), missing graceful shutdown, and callback-style APIs when promise versions exist. Trigger on: any server-side JavaScript/TypeScript, CLI tools, scripts, Express/Fastify/Koa apps, anything importing fs/path/crypto/child_process/http/stream/worker_threads, package.json edits, require()-to-ESM refactors, or any mention of Node.js, npm, or server-side JS. Also trigger when you see code with require(), readFileSync, exec(), JSON.parse(JSON.stringify()), or Math.random() in a Node.js context — the skill tells you what to replace them with. Do NOT trigger for browser-only JS, React/Vue/Svelte components, Deno, or Bun-specific code.

0
installs
▌
Typescript · crustacean-dev
Enforces strict TypeScript guardrails whenever writing, reviewing, refactoring, or generating .ts/.tsx/.mts/.cts code. Applies automatically to any TypeScript task — creating functions, components, types, configs, utility libraries, or converting JS to TS. Catches violations like enum (use as const), any (use unknown), default exports, barrel files, empty catch blocks, var, @ts-ignore, missing return types, and non-readonly properties. Also triggers for tsconfig changes, React/JSX with TypeScript props, API clients, CLI tools, and code reviews mentioning type safety. If the file extension or code context is TypeScript, use this skill — even if the user doesn't say 'TypeScript' explicitly.

0
installs
▌
Plan · crustacean-dev
Create technical architecture and planning documents. Two modes — project-level (produces .knowledge/architecture.md + .knowledge/conventions.md with directory structure, package dependencies, build pipeline, testing strategy, coding conventions, commit format, CI/CD) and feature-level (produces .knowledge/features/<feature>/plan.md + api/*.d.ts TypeScript contracts with exact data models, integration maps, and architectural decisions). Every decision includes a rejected alternative with rationale. Use this skill whenever the user wants to plan architecture, define conventions, structure a project, design how a feature should be built technically, figure out package layout or module boundaries, establish coding standards, or determine build/test/CI workflows. Trigger on "plan", "plan <feature>", "architecture", "conventions", "how should we build this", "design the system", "structure the project", "what should the technical approach be", "figure out the data model", or any request to make technical decisions

0
installs
▌
Spec · crustacean-dev
Create or amend feature specifications with typed code examples, verifiable acceptance criteria, and explicit edge cases. Produces .knowledge/features/<feature>/spec.md — the definitive WHAT document for a feature. ALWAYS use this skill when the user wants to define what a feature does before building it, whether they say "spec", "specify", "requirements", "user stories", "acceptance criteria", "what should this do", "define the feature", "expected behavior", "edge cases for", or any variant asking about feature behavior, inputs/outputs, or success criteria. Also trigger when the user wants to amend an existing spec, add user stories, refine acceptance criteria, or define what's in/out of scope for a feature. This skill describes WHAT to build (behavior, contracts, verification) — never HOW (architecture, algorithms, data structures → use /plan), never task breakdowns (→ /tasks), never code (→ /implement), never project principles (→ /constitution).

0
installs
▌
Tasks · crustacean-dev
Break a feature into ordered implementation tasks. Use this skill whenever the user says "tasks", "tasks <feature>", "break this down", "what needs to be built", "implementation order", "task list", "what's next", "story breakdown", or wants to know what to implement and in what order. Also use when the user wants to update task status ("mark TASK-3 done"), reorder tasks, add tasks, split tasks, or check progress on existing tasks. Trigger even for casual phrasing like "what's left to build", "figure out the implementation steps", "create stories for this feature", or "what do I need to build first". Produces .knowledge/features/<feature>/tasks.md from spec.md + plan.md. Does NOT produce specs (/spec), plans (/plan), code (/implement), or review specs (/clarify).

0
installs
▌
Review · crustacean-dev
Code review — check if implementation matches specs, conventions, and constitution. Use this skill ANY time the user wants to verify, check, audit, or review code that has been written. This includes explicit requests like "review", "review TASK-3", "review auth", "code review" AND indirect requests like "check my work", "check the code", "does this match the spec", "does this follow conventions", "is this clean", "sanity check", "look over the code", "did I miss anything", "any violations", "is the implementation correct", "can we merge this", "is TASK-N done", "are there constitution violations", "check test coverage". ALSO trigger after /implement completes to suggest a review. ALSO trigger when user mentions checking code against knowledge files, acceptance criteria, or convention conformity. This skill reads code and knowledge files, then produces a structured ✅/⚠️/❌ report with file:line references — it never modifies code. Do NOT trigger for spec review (/clarify), writing code (/implement), planning (

0
installs
▌
Clarify · crustacean-dev
Adversarial spec reviewer — runs 10 systematic checks against an existing .knowledge/features/<feature>/spec.md to find gaps, vague criteria, missing edge cases, constitution violations, scope leaks, and implementation details that leaked into the spec. Every FAIL comes with a concrete example and a fix proposal. ALWAYS use this skill when the user wants to validate, audit, challenge, stress-test, or review a feature spec before planning or implementation — whether they say "clarify", "clarify <feature>", "review the spec", "is the spec complete", "what's missing", "find gaps", "challenge the spec", "stress test", "audit the spec", "are we missing anything", "check the spec", or any variant asking about spec quality, completeness, or readiness. Also trigger when the user is about to move from spec to plan and wants confidence the spec is tight. This skill reads and updates spec.md ONLY — it does not create new specs (use /spec), produce plans or architecture (use /plan), break down tasks (use /tasks), write c

0
installs
▌
Bootstrap · crustacean-dev
Reverse-engineer an existing codebase into .knowledge/ files (constitution.md, architecture.md, conventions.md, feature specs) by analyzing code, config, tests, and git history. This is the entry point for brownfield projects — existing repos that have code but no .knowledge/ directory yet. It produces the same artifacts that /constitution + /plan + /spec produce for greenfield projects, but derived from what already exists instead of from an interview. ALWAYS use this skill when the user says "bootstrap", "bootstrap this project", "set up knowledge files", "generate knowledge files from code", "analyze this codebase", "create specs from existing code", "reverse engineer this repo", "document this project", "I already have code and need knowledge files", or any request to derive .knowledge/ artifacts from an existing codebase. Also trigger when a project has source code but no .knowledge/ directory and the user wants to start using the plugin — this is the brownfield onboarding path. Do NOT use this skill for

0
installs
▌
Challenge · crustacean-dev
Challenge

0
installs
▌
Implement · crustacean-dev
Write code and tests for a single task from .knowledge/features/<feature>/tasks.md. Picks the next TODO task (or a specific TASK-N), reads its acceptance criteria, referenced user stories, plan, architecture, and conventions, then writes exactly the code and tests needed to satisfy the ACs. Updates task status to DONE when complete. Use this skill whenever the user wants to write code for a planned task — trigger phrases include "implement", "implement auth", "implement TASK-3", "build this", "code this task", "start building", "next task", "what's next to implement", "work on TASK-5", "implement the next task", or any variant asking to write code against a task breakdown. Also trigger for casual phrasing like "ok build it", "let's code the first task", "I finished planning, now write the code", or "pick up where we left off". This skill handles ONE task per invocation — it does NOT write specs (/spec), create plans (/plan), break down tasks (/tasks), review code (/review), challenge implementations (/challen

0
installs
▌
Constitution · crustacean-dev
Create or amend .knowledge/constitution.md — the governing document that defines a project's non-negotiable principles, tech stack (with versions), interdits (what's explicitly forbidden), and quality standards. Use this skill whenever the user wants to start a new project, define or revisit project principles, establish ground rules before implementation, settle recurring technical debates ("should we use an ORM?"), amend an existing constitution, add or remove interdits, or check what the current constitution says. Trigger phrases include "constitution", "new project", "let's start", "define principles", "project setup", "what's forbidden", "ground rules", "project charter", "interdits". Also trigger when no .knowledge/constitution.md exists yet and the user is about to begin spec or implementation work. This skill ONLY produces constitution.md — it does not produce architecture.md, specs, API designs, README files, or implementation code.

0
installs

12 published skills