teambrilliant

Publish docs (plans, research, shapes, alignment atlases) to the private Dossier platform at teambrilliant.dev, pull them back with comments on any machine, and manage external share links. Use when someone says "publish to dossier", "dossier publish", "publish this doc/plan", "push this to teambrilliant.dev", "share this doc with the team", "share this externally", "pull the plan from dossier", "get the comments on the doc", or when resuming work on a plan that lives on Dossier. Scope guard - "publish" alone is ambiguous (npm, blog, git); this skill is only for the Dossier doc platform. Requires DOSSIER_TOKEN in the environment. Pairs with tap-skills:render-doc, which produces the HTML this skill uploads.

Generate and maintain an alignment-diagram atlas — a self-contained file:// viewer in a target directory (default `.tap/diagrams/atlas/`; supports several atlases per repo, e.g. per PARA area) whose tiles open per-flow alignment grids (layers × steps, line of visibility, moments of truth, coverage honesty). Use when someone says "alignment diagram", "alignment map", "experience atlas", "map this flow", "diagram how this works end to end", "service blueprint", "Kalbach map", or wants one navigable surface showing how a product behaves / an engine runs, flow by flow. Auto-detects scaffold / map-a-flow / review mode. Outputs to `.tap/diagrams/atlas/`.

Curate and maintain `.tap/product.md` — a compressed, agent-readable product-context file (what we build, audience, current focus, bets, non-goals). Use when someone says "curate product context", "install product context", "update product context", "product vision in repo", "what are we building", or when an agent enters a repo and can't find durable product-strategic context. Auto-detects interview / review / refresh mode. Outputs to `.tap/product.md`.

Explore a running web app in a browser and build or update `.tap/smoke-tests.md` — a lean catalog of post-release smoke-test cases. Use whenever someone says "build smoke tests", "create a smoke test catalog", "explore the site for testing", "what should we smoke test", "update the smoke test catalog", "add smoke test cases", or wants exploratory testing of a web app to capture what matters before a release. Use it proactively when entering an app that has no `.tap/smoke-tests.md` and the user wants release coverage. Pairs with `qa-smoke-run`, which executes the catalog this skill produces. Outputs to `.tap/smoke-tests.md`.

Deterministically convert a markdown doc (plan, research, shape, report) into one self-contained HTML file with house styling, TOC, checklists, and mermaid support. Use when someone says "render this doc", "render this plan", "make this markdown a web page", "convert md to html", "make this plan shareable as HTML", or before publishing a markdown doc with tap-skills:dossier-publish. NOT for authoring content — the markdown is the source of truth; this only renders it.

Just-in-time retrospective focused on improving agent autonomy. Use when someone says "retro", "retrospective", "what did we learn", "what went wrong", "post-mortem", "incident review", or after a feature ships, an incident resolves, a pattern of agent failures emerges, or any event worth reflecting on. Analyzes what happened, identifies what blocked agent autonomy, and produces concrete improvements (learnings + tickets). Not calendar-driven — event-driven. The learning loop that makes the system self-improving.

Measure the health of a software development system using stocks, flows, and feedback loops. Use when someone says "systems health", "how's the project going", "health check", "measure our process", "are we shipping fast enough", "what's slowing us down", or for periodic check-ins on development velocity and quality. Pulls data from git, GitHub, and CI to diagnose what's working and what's broken. Outputs to .tap/system-health.md.

Assess how ready a repository is for autonomous agent work. Use when someone says "audit this repo", "tap audit", "how ready is this codebase", "assess this project", or when an agent enters an unfamiliar codebase and needs to understand it before working. Scans documentation, MCP servers, CLI tools, permissions, test infrastructure, environments, and process to produce a readiness assessment with actionable leverage points. Outputs to .tap/tap-audit.md.

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.

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.

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.

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.

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).

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.

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.

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.