mohammadhprp
UserA primary AI engineering agent that plans, reviews work, and reports back across multiple projects.
Categories
Indexed Skills (47)
agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
architect
Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.
arena
Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.
gh
Expert guidance for using the GitHub CLI (gh) to work with repositories, issues, pull requests, Actions, releases, and the GitHub API from the command line. Use this skill whenever the user needs to perform a GitHub workflow or asks to use gh.
how
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.
improve
Audit an entire repository as a read-only senior advisor, identify evidence-backed bugs, security risks, performance issues, test gaps, technical debt, DX/docs problems, and grounded roadmap opportunities, then produce prioritized handoff plans for another agent. Use for repository-wide audits, improvement roadmaps, and implementation planning from existing code. Do not use for reviewing a specific diff or pull request, security-only audits (use security-best-practices), documentation-only edits (use docs-writer), greenfield feature design or implementation (use tlc-spec-driven), or creating and evaluating agent skills (use skill-creator).
ponytail
Apply the ponytail workflow to coding, implementation, refactoring, design, dependency choices, and over-engineering reviews. Use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "YAGNI", "do less", "shortest path", "what can I delete", "find bloat", or asks for a ponytail review, audit, debt ledger, gain scoreboard, or help reference. This single skill replaces the former ponytail commands and companion skills; select the requested operation from its references. Do not use for non-coding requests such as general knowledge, prose, translation, summaries, or recipes.
tdd
Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.
tlc-spec-driven
Feature planning and implementation with 4 adaptive phases (Specify, Design, Tasks, Execute). Auto-sizes depth by complexity. Writes testable requirements in EARS notation, atomic tasks, atomic Conventional Commits, and requirement traceability. Ships deterministic Python validation scripts so structural gates are enforced by code, not memory. Features an independent Verifier (author != verifier, evidence-or-zero), a discrimination sensor, a decision log (STATE.md), a test-coverage matrix, and a self-improving lessons layer. Stack-agnostic and tool-agnostic. Use when (1) planning features, (2) implementing with verification and atomic commits, (3) validating an implementation against a spec. Triggers on "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "record decision", "pause work", "resume work". Do NOT use for pure architecture decomposition analysis or standalone technical design documents.
why
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.
adhd
Shape output for a reader with ADHD: lead with the next action, number multi-step work, restate state across turns, suppress tangents, give specific time estimates, make wins visible. Invoke with /adhd; stays on until "stop adhd mode".
docs-writer
Write, review, and edit documentation files with consistent structure, tone, and technical accuracy. Use when creating docs, reviewing markdown files, writing READMEs, updating `/docs` directories, or when user says "write documentation", "review this doc", "improve this README", "create a guide", or "edit markdown". Do NOT use for code comments, inline JSDoc, or API reference generation.
find-skills
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
notion-cli
Use the Notion CLI (`ntn`) to interact with the Notion API, manage workers, and upload files. Use when the user asks to "call the Notion API", "deploy a worker", "upload a file to Notion", "create a page", "query a database", or any task involving the `ntn` command.
review
Review local Git changes, GitHub pull requests, or GitLab merge requests and produce a structured review.json artifact. Use this skill whenever the user asks for a code review, diff review, PR review, MR review, or production-readiness assessment. Use the gh skill for GitHub and the glab skill for GitLab; never publish review comments.
show-me
Help the user understand the current topic visually with concise diagrams, code-shape sketches, and focused HTML artifacts.
skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
skill-doctor
Grades agent skills by scoring agent conversations against efficiency and code-quality rubrics, then drafts concrete skill edits and a shareable report. Use when the user wants their agent setup graded from real conversation history, or asks which of their installed skills are actually working.
accept-assignment
Read the brief before spending effort: restate the goal and every acceptance criterion, name the files or area involved, and detect ambiguity. Use the moment a worker receives an assignment — especially a terse brief whose criteria look partial or whose instructions could conflict — to start on a confirmed understanding or ask one precise question instead of building on a guess.
bootstrap-project
Prepare a target project before delegating: use `find-skills` to install the skills the work needs, then create or update the project's `AGENTS.md` (and `CONTEXT.md`) with its stack, commands, conventions, and acceptance bar. Use before the first delegation into a project, when a new project has no `AGENTS.md`, when the work needs a capability the project lacks (for example web design, testing, or a framework), or when a worker's output was thin because the project's context was. Do this first, not after a bad result.
commit-changes
Turn approved, verified changes into atomic conventional commits that match the project: group related edits into one logical unit each, stage only the intended files, and keep behavior separate from formatting. Use when the developer has approved work and committing is in scope, when finalizing a task, or whenever a change must be split into commits — not for unverified, unapproved, or project-managed work.
compact-context
Keep the primary's context small by treating the ledger as off-context memory: checkpoint a compact resume packet with `tm session checkpoint`, ask the developer to compact the harness session, then reload with `tm session resume` and reconcile with `recover-run`; read raw briefs, reports, and diffs on demand with `tm report` / `tm diff`, never wholesale. Use at a safe boundary (a worker just settled, before the developer sees a report), before a large read, or whenever the developer asks to compact or reduce context.
debug-issue
Separate a failure's cause from a guess: reproduce and capture the exact failure, test one hypothesis at a time, make the minimal root-cause fix, then prove the fix and the absence of regression with the project's own checks. Use whenever something fails without an obvious cause — a failing test, a broken command, a crash, a build error, a regression, a bug assigned to a worker, or a symptom that moved after an earlier fix — and whenever asked to 'fix this', 'debug this', or 'why is this broken'.
delegate-task
Delegate one worker by calling your harness's native subagent tool with a scoped, self-contained brief built from the task's goal and acceptance criteria, then link the worker to its ledger task. Use when starting one worker for one assignment, or when the assignment needs a specialized worker.
escalate-decision
Interrupt the developer only when a decision is truly theirs, and make the interruption answerable in one step: lead with the situation and the exact question, add the smallest evidence that makes the call possible, and list the real options. Use when a worker returns a question or fails, acceptance criteria are ambiguous, an action is risky or consequential (commit, merge, push, publish, deploy, delete, or exposing secrets), a review is inconclusive or disputed, or the rework iteration limit is reached — not for routine progress.
handoff-report
Write the one structured report contract that closes a task or hands a result between the primary and its workers. Use whenever finishing work or handing off a result — a worker's end-of-task report or the primary's result report; back every claim with evidence from `verify-evidence` and state honestly what is unresolved.
implement-task
Build the smallest change that satisfies the accepted criteria: orient in the codebase, follow the project's own patterns and commands, keep the diff inside the accepted scope, and run the project's checks as you go. Use when an assignment needs code, config, tests, or documentation changes and `accept-assignment` has confirmed the criteria — not for investigation-only work.
independent-review
Prevent an implementer from being the only judge of its own work: once `review-work`'s gate warrants a separate reviewer, delegate that reviewer through the harness's subagent tool with the objective, acceptance criteria, and evidence — never the implementer's conclusion — and collect findings only. Use when the change is important or risky — auth, money, user data, migrations, public interfaces, concurrency, or parallel writers — when a criterion is hard to self-check, or whenever the developer asks for a second opinion — even if the implementer already reported success.
investigate-issue
Investigate a question about a codebase read-only: gather evidence from files, logs, history, and tests, separate a proven conclusion from a hypothesis, change nothing unrelated, and report the evidence with a confidence level. Use when a worker is delegated a diagnosis, root-cause, or feasibility question that does not include a fix — even when the wording is 'figure out why' and the cause looks obvious enough to fix on the spot.
monitor-agents
Track each worker subagent until it returns and collect its evidence: a foreground subagent call returns its result, a background one notifies on completion, so there is no polling — read `.teammate-report.md` with `tm report` and record the settle. Use after delegating work and before reviewing it, or whenever a worker seems stalled or the developer asks what an agent is doing; a lost or orphaned worker is `recover-run`'s.
multi-project-context
Resolve a task to exactly one project root and keep each project's context isolated, covering the one-project-per-worker model. Use before delegating whenever a request names a project, spans or touches multiple repositories, uses an informal or ambiguous project name, or could route a worker's context into the wrong project.
onboard-developer
Introduce the developer to Team Mate on your first turn in a new session, or whenever they are new or ask who you are, what you can do, or how to use you: a short, friendly orientation to what Team Mate is, the harnesses it runs in, the ledger, and example prompts they can try — plus what they still control. Not when they have already given you a concrete task.
parallel-coordination
Run several independent worker streams at once without corrupting shared state: check `max_concurrent`, start background subagents through the harness, fix a merge order before starting, keep parallel writers off the same files, and land results in the primary. Use whenever more than one worker will run at the same time, when the developer says to run things in parallel or 'have two agents look at it', or when deciding whether two work streams are independent enough to overlap.
plan-work
Turn an ambiguous goal into explicit, testable work before any worker is dispatched: restate the outcome, derive acceptance criteria a reviewer could check, choose serial vs parallel, size the smallest useful team, and pick each worker's role. Use whenever a request is non-trivial, should be delegated, spans more than a trivial local edit, arrives vague ('make the app faster', 'add auth'), or reaches a point where it must become tasks — and use it to ask the developer up front instead of spending agents on the wrong work.
raise-blocker
Turn a stall into one answerable question: state the blocker, give the smallest evidence that makes it decidable, ask exactly one precise question, propose the options with a recommendation, then stop and wait instead of guessing. Use when a worker hits an ambiguous brief, a missing decision, or a risky action outside its scope — anything it should not resolve alone — even when pushing ahead feels faster than asking.
recover-run
Reconcile the durable ledger with the evidence a run left behind after a primary restart or a lost worker: `tm` cannot list live subagents, so classify each task from its brief, report, and diff, cancel what is unsafe, re-delegate what was lost, and never resend a brief that may already have landed. Use when the primary session restarted or compacted mid-run, when a worker is missing or stalled, or when the developer asks what happened to work that was running.
report-progress
Deliver the developer-facing report and request a decision: fill the shared handoff-report contract in templates/report.md and back every claim with evidence. Use when work reaches a state the developer should see; whether that warrants an interrupt is `escalate-decision`'s call.
report-result
Close a worker task with the shared `handoff-report` shape — requested, implemented, changed, verified, issues, remaining concerns, assessment, decision — and state honestly what is unresolved. Use when a worker's assignment is finished or blocked and the primary needs a reviewable result, so review can start without a follow-up round-trip.
review-change
Review a diff against its acceptance criteria with fresh evidence: read the full changed files, run the project's own checks, record one actionable finding per observation with severity and category, and give a pass/fail/inconclusive verdict that names the checks run. Use when a completed change must be judged against agreed criteria — even if the request only says 'check this' or 'does this look right'.
review-task
Act as an independent reviewer for another worker's output: apply the shared `review-change` method to judge the work rather than the summary, name the checks you actually ran, and return findings with severity and category plus a pass/fail/inconclusive verdict while making no changes yourself. Use when a worker is delegated as a reviewer, or any agent is asked to independently check a change it did not write — insufficient evidence is `inconclusive`, never a pass.
review-work
Coordinate review of delegated work: decide who reviews a returned worker's result, obtain an independent review or apply the shared review-change method yourself, record the verdict, and route a fail to run-rework. Use when a worker returns and its result needs checking, or when a rework round came back for another pass.
run-rework
Turn a failing review into a bounded fix loop that converges or stops: send only the open blocker and major findings back to the same worker, grouped by severity with file/line and the expected behavior, ban scope expansion, require the same report, then monitor and re-review until it passes or hits max_iterations. Use when a review returns a fail verdict with open blocker/major findings, when a rework round comes back still failing or regressed, or when the developer requests changes — not when only minor/nit findings remain.
commit
Create atomic Git commits with conventional messages. Use this skill whenever the user asks to commit changes, create commits, or prepare commit messages.
grilling
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
merge-request
Create a GitLab merge request (MR) for the current branch using the glab CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitLab MR or merge request.
release
Create a software release by reviewing commits, determining the semantic version, updating the changelog and package versions, committing release metadata, and tagging the result. Use this skill whenever the user asks to cut, prepare, publish, or tag a release.
load-project-context
Read the target project's own instructions — AGENTS.md, CONTEXT.md, local skills, commands, and conventions — before acting in it, and resolve conflicts with the context precedence order. Use when starting any work in a project, before editing files, delegating, or verifying, and whenever project instructions may conflict.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.