Workflow for drafting a logo mark for a side project or utility, producing a self-contained HTML gallery of 4–6 concept directions per round — each rendered in SVG at large, medium, and favicon sizes on both light and dark backgrounds. The user opens the gallery in a browser, picks favorites by short letter code, and…
Workflow for compacting the current conversation into a handoff document that another Claude Code session can pick up from later. Produces a single Markdown file capturing the goal, current state, in-flight work, decisions made, open questions, paths touched, and a recommended next-session skill — referencing existing…
Read-only workflow for investigating how a system behaves — understanding how something works, confirming whether it does what it claims, and diagnosing bugs, errors, or unexpected behavior. Forms and tests hypotheses against real evidence (code, logs, runtime state, reproductions), traces to root cause, and reports a…
Workflow for understanding and operating Linux — kernel, processes, memory, filesystems, networking, init, permissions, and the distinctions between general OS concepts, POSIX, Linux-specific behavior, and distro-specific quirks. Calibrates between teaching the why (mental models, system internals) and helping operate…
Workflow for authoring or revising any Claude Code configuration — skills (SKILL.md), CLAUDE.md guardrails, settings.json (permissions, hooks, env, model), sub-agents, slash commands, MCP server entries, plugins, and the install or sync scripts around them. Operates from working knowledge of LLMs, agent harnesses, and…
Workflow for discussing product and UX decisions — user flows, interaction design, information architecture, mental models, feature framing, and the product trade-offs that sit between what users want and what the team can build. Engages with technical context when relevant, but the focus stays on the product and the…
Read-only workflow for code review, PR review, or feedback on a diff, branch, or specific files. Produces structured, prioritized feedback with blockers, should-fix items, nits, questions, and notable strengths — does not modify code. NOT for making changes (use /ship for that).
Workflow for extending, fixing, or evolving existing production code — bugs, features, refactors, or shipping changes that touch APIs, data models, integrations, business logic, or user-facing behavior. NOT for greenfield prototypes or throwaway scripts, NOT for read-only investigation of how existing code works or…
Workflow for writing tests against requirements — verifying that a feature, endpoint, or function behaves correctly according to its specification, not according to its current implementation. Reads the spec/requirement and the surface being tested (signatures, contracts, observable behavior); deliberately avoids…
Workflow for turning a feature, change, or bug into a well-scoped ticket for a development team. May read code to understand the system well enough to write a good ticket — but the output is product-level, not an implementation plan. Produces concise tickets focused on the problem, behavior, and acceptance criteria.…
9 1mo agoA76 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: