teambrilliant
12 verified skills53 total stars
strategic-thinker
Use for cross-domain strategic reasoning, approach selection, and systems-level analysis. Trigger when the user wants to: think through how to approach a problem, evaluate tradeoffs between architectural or technical approaches, sanity-check a plan or direction, understand second-order effects of a decision, get a holistic view across code/org/time dimensions, or pressure-test assumptions. The core signal is the user asking "what's the right approach?", "think about this", "what am I not seeing?", "sanity check", "tradeoffs", "how should we tackle this?", or any request for multi-level reasoning that spans product, architecture, and organization. Also use when the user needs help deciding which workflow skill to invoke next. NOT for: product/user/business decisions (→ product-thinker), work definition (→ shaping-work), file-level technical planning (→ implementation-planning), writing code, test authoring, or PR review.
development5
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.
development5
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.
development5
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.
tools5
working-backwards
Write a PR-FAQ to pressure-test a product idea customer-first — before committing engineering. Use when someone says "write a PR-FAQ", "press release", "working backwards", "PRFAQ", "start from the customer", "what's the press release for this", "before we build this", "is this idea clear enough to build", "draft the launch announcement", or has a fuzzy product idea and wants to force clarity on what to build and why. Amazon's Working Backwards method: define the desired customer experience as a mock press release + FAQ, iterate on the document until the thinking is clear, and kill weak ideas cheaply on paper. Sits between product-thinker (should we?) and shaping-work (what exactly?), alongside product-discovery (will it work?) — this skill answers "what is the customer-facing end-state, stated so plainly that the holes show?" NOT for validating risky assumptions with experiments (use product-discovery), NOT for breaking shaped work into a build plan (use shaping-work / implementation-planning).
development5
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.
testing4
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).
development4
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.
development4
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.
development4
design-language
Capture and enforce a product's visual design language — principles and patterns that make it feel like itself. Use when the user wants to: distill design inspiration into a durable reference ("capture this design from figma", "distill this screenshot", "extract our design language", "capture design direction"), or check an implementation against the product's design language ("review design fidelity", "check against design direction", "does this match our design?", review a PR for design drift). Core signal: user points at a design source (Figma URL, screenshot, live URL) OR built UI and asks how it relates to the product's visual language. Operates on a consumer-repo `docs/design.md` — proposes diffs, never writes directly. Pairs with shaping-work, implementation-planning, implement-change, and qa-test. NOT for: generating new UI (→ frontend-design), translating a Figma design into code (→ figma-implement-design), accessibility audits (→ a11y-debugging), or token extraction.
development4
tighten-loop
Harvest course-corrections from the current conversation and convert them into durable fixes so the agent doesn't need the same steer next time. Use when someone says "tighten the loop", "tighten loop", "debrief this session", "session debrief", "what should I update so next time you don't…", "how can I make your life easier", "what tripped you up", "what slowed you down", or at the end of a session when the user reflects on agent friction. The scope marker is THIS SESSION / THIS CONVERSATION — that's the discriminator from sibling skills. Reads the transcript only, classifies each steer, routes to the right fix tool. NOT for: assessing repo readiness before work (use loop-check), retros on past PRs/incidents/releases (use tap-skills:retrospective), coding, or applying edits inline.
tools4
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.
development4