All authors
Claude Skills by connorpham
github.com/connorpham41 skills1 installs34 views
- BaBA pipeline — turns the upstream spec into a runnable backlog that /dev and /qa can execute. Reads the spec + schema + existing backlog → shards the spec into docs/specs/<feature>.md (index + per-feature files, the repo's citable oracle) → decomposes a feature into user stories with TESTABLE acceptance criteria (Given/When/Then, each tracing to a spec section) → flags every gap/contradiction as a question for the owner instead of inventing requirements → challenger review → creates the ticket...Votes: 0GitHub stars: 6
- DevTicket-driven DEV pipeline, end-to-end — preflight (tracker/design-source/git/DB pinged for real) → fetch the ticket → read spec + schema (the ticket is a claim, the spec is the spec) → UI tickets pull the design from the ticket's design link (design source = visual oracle; exact colors/spacing/text from node data) → implement on a feature branch → /verify gate + evidence → self-review with machine-measured design fidelity → 2 fresh review agents must approve (+1 on high-stakes diffs; committ...Votes: 0GitHub stars: 6
- DocsDocumentation bootstrapper for mature-but-undocumented repos — the 'read then ask' lane. Reads the codebase FIRST (structure, manifests, routes/entrypoints/models/migrations, existing README, git-log themes) and drafts a 'what this system appears to do' map where every inference is marked ⚠ UNVERIFIED → interviews the owner in ONE batched question table (each question carries what the code suggests, what is ambiguous, and a proposed answer acceptable in one word) → writes the standard oracle ...Votes: 0GitHub stars: 6
- GuidelinesBehavioral guidelines to reduce common LLM coding mistakes. Loaded by /dev before planning; applies when writing, reviewing, or refactoring code — avoid overcomplication, make surgical changes, surface assumptions, define verifiable success criteria.Votes: 0GitHub stars: 6
- PlanGreenfield planning intake — for projects that have NEITHER code NOR documentation. Interviews the owner section by section (a five-field kernel: Why, Capabilities, Constraints, Non-goals, Success signal), with a one-round elicitation menu after every drafted section → writes a BRIEF, then a PRD whose requirement rows carry gate-compatible codes, then an optional architecture spine → registers the PRD as a SOURCE document (specs.sources) so the verbatim gate guards everything /ba later shards...Votes: 0GitHub stars: 6
- PmPM+SA orchestration lane — one command runs the whole virtual team so the owner only watches results. Reads the tracker + the sprint plan + the decision queue → picks the highest-value UNBLOCKED work → dispatches to the right lane (/ba for backlog, /dev for code, /qa for verification, the SA lane for ADRs) with every child gate intact → ends each session with the 'your desk' report: done / needs-you / upcoming deadlines. Blocked work stays blocked — open business questions are collected for t...Votes: 0GitHub stars: 6
- QaVERIFY-ONLY QA pipeline for a ticket a dev claims done (the spec is the oracle). Reads the ticket + spec + schema to derive expected behavior → designs 2–5 test cases (exact repro, boundary, whole-screen sanity, read-only DB verify for writes) → self-provisions missing data through the REAL UI flow (write-gated) → runs them HEADED in the browser → collects evidence (named screenshots, annotated images with in-image captions) → cross-checks every ticket claim against an evidence file → machine...Votes: 0GitHub stars: 6
- TeamOne command puts the whole virtual team to work. /team runs a full 'workday' — clears the owner's decision queue first (batched questions), then works through every UNBLOCKED item (DEV tickets via /dev — one at a time, or up to team.parallel agents in their own worktrees on disjoint scopes, merged serially; BA drafts and SA ADRs in parallel background worktrees; QA verification between dev tasks) until everything left needs the owner, then prints one end-of-day desk report. The autonomous ent...Votes: 0GitHub stars: 6
- VerifyCreate and run the verification gate for this repo — the profile's ordered step manifest (ledgers → lockfile → lint → types → unit → build → reality checks → integration → e2e), with exact closing lines recorded. Also the standard for WRITING tests — expected values cite the spec or the schema, every behavior gets a boundary pair, no tests that mirror the implementation. Invoked standalone and as the /dev verify step, and before declaring ANY code change done.Votes: 0GitHub stars: 6
- SetupBootstrap the vteam proof-of-done harness in the current repo — grade it first (npx vteam-harness audit), install (npx vteam-harness init), verify (npx vteam-harness doctor). Use when the user asks to set up vteam, add proof-of-done gates, or install the virtual AI team.Votes: 0GitHub stars: 6
- Ba Acceptance CriteriaUse when writing the acceptance criteria for a story, and when a criterion is about to say 'works correctly', 'handles errors', 'is fast' or 'the user can'. Also when a criterion describes clicks instead of outcomes, when one criterion carries three behaviours, and when nobody can name the value that proves it passed.Votes: 0GitHub stars: 6
- Ba Story SlicingUse when a story is too big for one developer to finish in about two days, when it contains the word 'and', or when it names a whole screen, module or role. Also when a split has produced a 'backend story' and a 'frontend story', and when nobody can say what a user could do after the first slice ships.Votes: 0GitHub stars: 6
- Dev Api DesignUse when adding or changing an HTTP endpoint, server action, RPC, webhook or public function contract — its URL, verbs, payload, errors, pagination or auth — and when a client complains that the API 'sometimes' behaves differently.Votes: 0GitHub stars: 6
- Dev Async WorkUse when work leaves the request — a queue, a worker, a scheduled job, a webhook you send or receive, an email, a report, a third-party call that can be slow. Also when a dependency starts failing and the question is what your system does about it, and when a job has run twice and someone was charged twice.Votes: 0GitHub stars: 6
- Dev Codebase DesignUse when deciding where new code lives, when adding a function, module, service or abstraction, when a change touches more than two files for one behavior, or when a test needs to reach past a public interface to check something.Votes: 0GitHub stars: 6
- Dev Concurrency And TransactionsUse when two requests can touch the same row — balances, stock, seats, invites, slugs, counters — and when a write depends on a value the code read a moment earlier. Also when a transaction is opened, when an isolation level is chosen or left to a default, and when a bug report says a duplicate or a wrong total appeared that 'could not happen'.Votes: 0GitHub stars: 6
- Dev Content PipelinesUse when a repository's asset is structured data rather than code — content, docs, translations, catalogs, config — and it is contributed by outsiders or synced two-way with a database, CMS or API. Also when a filename or slug carries a key, when a parse/serialize pair exists, and when a job deletes or rewrites files in bulk.Votes: 0GitHub stars: 6
- Dev Data ModelingUse when a ticket adds or changes tables, columns, relations, enums, indexes or migrations — including 'just one nullable column' — when a value is money, time, or an identifier, and when a bug smells like a constraint the database should have enforced.Votes: 0GitHub stars: 6
- Dev DebuggingUse when a test, gate, build or user report says something is broken and the cause is not yet proven — especially under time pressure, when the fix 'looks obvious', or after a second attempt has already failed.Votes: 0GitHub stars: 6
- Dev Domain ModelingUse when a ticket introduces or reuses business nouns (order, wallet, lot, member, tier…), when two names seem to mean the same thing, when a name in the spec differs from the name in the code, or before modeling any data — the vocabulary is decided before the table is.Votes: 0GitHub stars: 6
- Dev Error HandlingUse when writing anything that can fail — I/O, network, database, parsing, user input — when deciding whether to throw, return, retry, log or swallow, and when a production error is unhelpful ('something went wrong') or duplicated across logs.Votes: 0GitHub stars: 6
- Dev Frontend CraftUse when a ticket touches the browser — a component, a screen, styling, client state, data fetching, routing, or a rendering strategy — and when choosing between the six or seven tools that all solve the same frontend problem. Also when a UI is 'done' but nobody has said which states it has.Votes: 0GitHub stars: 6
- Dev IdentityUse when a /dev session starts on any ticket, before the first plan or edit — and whenever the work has drifted into writing code the ticket did not ask for, guessing at names, or explaining instead of proving.Votes: 0GitHub stars: 6
- Dev Mobile CraftUse when a ticket targets a phone or tablet — native Android or iOS, React Native, or Flutter. Especially when the change touches a screen's lifecycle, stored data, permissions, background work, or anything that must survive rotation, a lost network, or the OS killing the app. Also when deciding native vs cross-platform.Votes: 0GitHub stars: 6
- Dev ObservabilityUse when a change ships something you will have to debug from the outside — a new endpoint, worker, integration or migration — and when the only answer to 'is it working?' is a screenshot. Also when an incident is being investigated and the logs do not say enough, and when an alert fires that nobody can act on.Votes: 0GitHub stars: 6
- Dev Query PerformanceUse when a page or endpoint is slow, when a list grows, when an ORM sits between the code and the database, and when a query is written inside a loop. Also when pagination is added, when a cache is introduced, and when a fix is 'add an index' before anyone has looked at a plan.Votes: 0GitHub stars: 6
- Dev Security BasicsUse when code handles a request, a session, a secret, a file upload, a query built from input, or anything a user can address by id — and whenever the change touches auth, roles, money, personal data or deletion.Votes: 0GitHub stars: 6
- Dev Stack Nextjs PrismaUse when the project runs Next.js (App Router) with Prisma — when writing a route handler, server action, server/client component, Prisma query, transaction or migration, and when a page is slow, a query returns stale data, or a bulk update 'lost' rows.Votes: 0GitHub stars: 6
- Dev Testing CraftUse when deciding which tests to write for a change, how to name and structure them, what data they use, and how deep to go — and when an existing test is flaky, asserts nothing meaningful, or breaks on every refactor.Votes: 0GitHub stars: 6
- Pm PrioritisationUse when choosing what the team does next and more than one thing is ready, when everything is labelled high priority, and when an item has been in progress longer than the others. Also when work is blocked on a person and the question is whether to wait, escalate or start something else.Votes: 0GitHub stars: 6
- Qa Accessibility VerificationUse when verifying any user interface — web or mobile — and the ticket, spec or design says nothing about accessibility. Also when an automated scan came back clean, when a design hands over only the default state, and when 'accessible' has to become a pass or fail with a number behind it.Votes: 0GitHub stars: 6
- Qa Case WritingUse when writing a test case record or filling in its result — when a title names a topic instead of a behaviour, steps hide the typed value, EXPECTED says 'works correctly', or ACTUAL says 'failed'.Votes: 0GitHub stars: 6
- Qa Combinatorial DesignUse when a feature has several independent inputs and the honest combination count is too large to run — roles by plans by locales, payment method by currency by coupon, OS by browser by network by font scale. Also when deciding which tier a test belongs in, and when a suite is red often enough that people re-run it instead of reading it.Votes: 0GitHub stars: 6
- Qa HeuristicsUse when the spec is silent and you need a defensible finding anyway, when choosing the exploratory case, or when a boundary needs a sharper edge — consistency oracles, coverage walks, data shapes, interruptions, tours.Votes: 0GitHub stars: 6
- Qa Hostile InputsUse when choosing the concrete values for a boundary case — text, numbers, money, dates, files, emails, ids — and when a field has only ever been tested with the value the developer typed.Votes: 0GitHub stars: 6
- Qa IdentityUse when a /qa session starts on any ticket, before deriving a single expected value — and whenever a verdict is about to be written from reading code, from the dev's claim, or from what 'obviously' should happen.Votes: 0GitHub stars: 6
- Qa Report WritingUse when writing the verification report or the evidence folder — when the reader is a product owner or developer who needs the verdict and the proof without reading code, and when 'PASS' rests on a folder nobody else can follow.Votes: 0GitHub stars: 6
- Qa Requirement SmellsUse when reading a ticket or spec before verification — when criteria contain words like should, properly, fast, handle, show an error, the user, always — and when a 'done' claim rests on a sentence nobody could test as written.Votes: 0GitHub stars: 6
- Qa Security ProbesUse when a ticket touches authentication, sessions, roles, money, personal data, uploads, or any server that trusts client input — the input an attacker sends on purpose, provable with the lane's own browser, API recorder and read-only database.Votes: 0GitHub stars: 6
- Qa Test DesignUse when choosing the two-to-five cases for a verification — what deserves the budget, which boundary earns its place, when an exploratory or security slot is warranted — and when a case pack is all happy path.Votes: 0GitHub stars: 6
- Qa User MindsetUse when designing or running any UI verification — when every case in the pack could have been written by someone who has never watched a real person use software, and when a PASS came from typing perfect values in perfect order.Votes: 0GitHub stars: 6