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 turning an observed defect into a bug ticket a developer can act on without a follow-up question — reproduction steps, expected versus actual result, environment and version, time of occurrence, reproducibility, impact and severity, evidence. May read code or logs to get names, versions, and error text…
Workflow for turning a feature or change 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. NOT for…
★not rated 9 1mo agoA87 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: