ReddRadar
Topic: developer-workflow
28 skills in this topic.
-
error-audit
Audit code for silent error swallowing, fallbacks to degraded alternatives, backwards compatibility shims, and UI that fails to show errors to the user. Finds and fixes all occurrences in the specified scope.
markmdev/meridian 146
-
create-docs
Create or update .meridian/docs/ knowledge files for a module or directory. Produces reference docs with frontmatter for context routing.
markmdev/meridian 146
-
add-frontmatter
Scan all .md files in the project and add or fix YAML frontmatter (summary + read_when) so they can be discovered by context routers like Reflex.
markmdev/meridian 146
-
planning
Interview-driven planning methodology that produces implementation-ready plans. Always use this skill INSTEAD of EnterPlanMode — it provides structured interviewing (20-40 clarifying questions), exhaustive parallel codebase exploration (5-15 Explore agents), verbatim requirements capture, and automated plan validation via plan-reviewer (must score 9+). Use for new features, refactoring, architecture changes, migrations, or any non-trivial implementation work.
markmdev/meridian 146
-
observability-audit
Audit code for observability gaps — debug logs left in, errors caught without being logged, missing context on log entries, untracked slow operations. Uses the app's existing observability tooling exclusively.
markmdev/meridian 146
-
ux-states-audit
Audit UI code for missing loading states, empty states, and error states. Every async operation and data-driven UI must handle all three. Finds gaps and implements the missing states using the app's existing patterns.
markmdev/meridian 146
-
shaping-work
Shape rough ideas into clear, actionable work definitions. Use this skill whenever someone has an unstructured idea that needs to become a concrete work definition — feature requests, bug reports, PRDs, customer feedback, Slack threads, stakeholder asks, or vague "we should do X" statements. Trigger phrases include "shape this", "scope this", "write a PRD", "define this work", "turn this into a ticket", "flesh this out", "spec this out", "what should we build for X", "I have an idea for...", or any rough input that needs structure before implementation can begin.
teambrilliant/dev-skills 3
-
qa-test
Browser-based QA verification after any implementation. Use when someone says "QA this", "test this in browser", "verify the feature", "qa test", "browser test", or after completing an /implement-change to verify acceptance criteria in a real browser. Opens Chrome via MCP, exercises each acceptance criterion, verifies via DOM snapshots, and reports pass/fail. The "closer" for every implementation — proof it works, not just that tests pass.
teambrilliant/dev-skills 3
-
product-thinker
Use for product decisions, user behavior analysis, and UX evaluation. Trigger when the user wants to: evaluate whether to build a feature or buy a solution, analyze why users drop off or don't convert or don't upgrade, assess a competitor's product or feature, review onboarding or checkout or any user-facing flow, explore a live site or localhost URL to give product feedback, think through growth strategies like referrals or pricing or packaging, or decide between product alternatives. The core signal is the user asking "should we?" or "is it worth?" or "why are users?" or "what do you think about [product/feature/flow]?" or asking you to look at a product and assess it. Also use alongside shaping-work when the user needs product thinking before defining work. NOT for: writing/fixing code, test authoring, PR review, database operations, CI/CD, or decomposing PRDs into tickets.
teambrilliant/dev-skills 3
-
product-primitives
Break down complex products, features, or systems into fundamental primitives and building blocks from a software creator's perspective. Use when starting a new application, designing a large feature, or needing to understand a complex system's moving parts before building. Trigger phrases: "break down X", "decompose this", "what are the primitives", "building blocks of Z", "map the architecture", "what are the moving parts", "analyze this system", or any situation where you need to identify the atomic, reusable capabilities that compose a system. Complements product-thinker (user perspective) with the builder's perspective (system-level connections).
teambrilliant/dev-skills 3
-
product-discovery
Validate whether a product idea is worth building before committing engineering investment. Use when someone says "should we build this", "validate this idea", "discovery", "run an experiment", "test this hypothesis", "what are the risks", "is this worth building", "feasibility check", "prototype plan", or when a team has a shaped feature or product idea and needs to assess risks and design experiments before building. Sits between product-thinker (should we?) and shaping-work (what exactly?) — this skill answers "will this actually work?" by identifying what you don't know, designing the cheapest way to find out, and defining evidence gates that justify (or kill) the investment. Also trigger when someone has a feature request and you sense high uncertainty — if the team is about to spend weeks building something nobody tested, this skill should intervene.
teambrilliant/dev-skills 3
-
loop-check
Assess what's needed to make feedback loops autonomous in a repo. Use when someone says "loop check", "what do I need to work autonomously", "check my feedback loops", "what's manual here", "what should I automate", "can an agent iterate here", or before starting work in an unfamiliar repo to understand what's missing for autonomous iteration. Also use when the user asks "what do you need to make this autonomous?" or describes a workflow they want to close the loop on. NOT for: full repo audits (use tap-audit), coding, test writing, or implementation.
teambrilliant/dev-skills 3
-
implementation-planning
Create technical implementation plans and architecture designs. Use when someone needs a detailed technical approach before coding begins — "create a plan", "plan this ticket", "how should we implement this", "technical design", "architect this", "design the approach", "plan the migration", "refactor plan", "how should we structure this", or when shaped work or a groomed ticket needs a concrete implementation strategy with phases, file changes, and verification steps.
teambrilliant/dev-skills 3
-
implement-change
Execute code changes from an implementation plan. Use when someone says "implement this", "build this", "code this", "start building", "let's implement", "execute the plan", "make the changes", "do the work", or has an approved implementation plan ready for coding. Takes implementation plans and produces working code, phase by phase with verification.
teambrilliant/dev-skills 3
-
writing-plans
Structured implementation planning for multi-step development tasks. Use when you have a spec or requirements and need to break work into executable steps.
CodingCossack/agent-skills-library 17
-
brainstorming
Collaborative design exploration that refines ideas into validated specs through iterative questioning. Use before any creative work including creating features, building components, adding functionality, or modifying behavior.
CodingCossack/agent-skills-library 17
-
verification-before-completion
Verification discipline for completion claims. Use when about to assert success, claim a fix is complete, report tests passing, or before commits and PRs. Enforces evidence-first workflow.
CodingCossack/agent-skills-library 17
-
using-superpowers
Meta-skill enforcing skill discovery and invocation discipline through mandatory workflows. Use when starting any conversation to check for relevant skills before any response, ensuring skill-first workflow before proceeding.
CodingCossack/agent-skills-library 17
-
using-git-worktrees
Git worktree–based workspace isolation for parallel or non-disruptive development. Use when work must occur without modifying or interfering with the current working tree.
CodingCossack/agent-skills-library 17
-
test-driven-development
Red-green-refactor development methodology requiring verified test coverage. Use for feature implementation, bugfixes, refactoring, or any behavior changes where tests must prove correctness.
CodingCossack/agent-skills-library 17
-
requesting-code-review
Use when you need to request a code review for a PR/MR and want a consistent review brief (context, scope, risk areas, test instructions, acceptance criteria) before merge.
CodingCossack/agent-skills-library 17
-
receiving-code-review
Assesses and responds to incoming code review feedback on PRs (reviewer comments, requested changes), especially when suggestions are unclear, technically questionable, or scope-expanding. Use before implementing review suggestions to align on intent and keep changes minimal.
CodingCossack/agent-skills-library 17
-
finishing-a-development-branch
Git branch completion workflow. Use when implementation is complete, tests pass, and a feature branch needs to be integrated via merge, pull request, or cleanup.
CodingCossack/agent-skills-library 17
-
executing-plans
Disciplined plan execution for implementation tasks. Use when executing a saved implementation plan, following step-by-step instructions from a plan document.
CodingCossack/agent-skills-library 17