All authors

Claude Skills by theultimate-dev
github.com/theultimate-dev31 skills0 installs81 views
- Decision RecordsKeeps a project's decision log: short decision records (ADRs) in a decisions/ directory with an indexed README linked from AGENTS.md or CLAUDE.md. Use when the user settles a trade-off, asks to record or write up a decision, asks why something was chosen, mentions ADRs or architecture decisions, or when a project has no decision log yet and a structural choice is being made. Also use to adopt or tidy an existing docs/adr or docs/decisions folder.Votes: 0GitHub stars: 2
- Release ProcessMaintains a project's CHANGELOG.md in Keep a Changelog form and cuts releases: picks the SemVer bump from Conventional Commits, moves Unreleased into a dated version section, bumps declared version files, commits, tags vX.Y.Z on main, pushes, and relies on a GitHub Action to publish the GitHub Release. Also handles repositories whose components (packages, plugins) are versioned independently, each with its own changelog and tags such as api--v1.2.0. Use when the user asks to add a changelog e...Votes: 0GitHub stars: 2
- Marginal GainsReviews a working session with a coding agent and proposes the two or three smallest changes to the user's harness that would pay off most: instruction files such as AGENTS.md or CLAUDE.md, skills, memory, hooks, permissions and settings, repository checks, and the user's own prompts. Reads the session for corrections, restated instructions, failures, rediscovery, and wins; ranks by frequency, cost, reach, and the user's goals; returns each as a card with the evidence, the exact change, and a...Votes: 0GitHub stars: 2
- Curating Product RequirementsMaintains the product layer of a product context repository: overview, glossary, actors and use cases, and a requirement catalogue with permanent capability-prefixed IDs, priorities, target versions and statuses, plus non-functional requirements with stated targets. Integrates product briefs, product/design handoffs and feedback without duplicates, maps their local IDs to catalogue IDs, and drops or defers rows with a reason, never deletes. Use when the user says add this to the requirement c...Votes: 0GitHub stars: 2
- Designing System ArchitectureDesigns and evolves the architecture in a product context repository: C4 context and container views, components where they pay, runtime scenarios, data, deployment, cross-cutting concepts, and the versioned contracts several bets share, each section tagged with the version it arrives in and whether it is planned or built. Writes the baseline before a version's milestones are shaped and each contract before a bet consumes it, raises consequential choices as decision records, and leaves code-l...Votes: 0GitHub stars: 2
- Planning Product RoadmapsPlans a product's versions and milestones in a product context repository: the gates between versions, version briefs with outcome, done-when, scope in and out, milestones as release slices with observable exit criteria, requirement coverage per milestone derived from the catalogue, prerequisites outside the code, and one risk register and one open-question register. Answers what's next and what's the status from the bet files. Use when the user says plan the next version, plan the milestones...Votes: 0GitHub stars: 2
- Reconciling Product ContextFolds delivered work back into a product context repository and keeps it coherent. Closes a bet after its pull requests merge: confirms every acceptance criterion was observed on merged code, updates requirement statuses and the architecture as built, writes contract details settled during implementation into the contracts, links implementation decision records that moved the architecture, updates risks and open questions, writes the bet's outcome log, and rewrites the derived indexes. Also a...Votes: 0GitHub stars: 2
- Shaping BetsShapes a milestone of a product context repository into bets: epic-sized, appetite-bounded work units with an observable outcome, the requirement IDs they cover, acceptance criteria, no-gos, rabbit holes, cuttable scope, the contracts and decisions they rely on, and an ordered context pack. Checks that every requirement of the milestone is covered exactly once, checks readiness, pins the context repository's commit, and hands a ready bet to the implementation loop in the code repository. Use ...Votes: 0GitHub stars: 2
- Structuring Product ContextCreates or adopts a product context repository: a Markdown repository, kept apart from the code, that holds a long-running product's whole context in layers sorted by how often they change (product, architecture, decisions, a roadmap with bets, design, research), with an AGENTS.md map, folder indexes and house rules. Adopts existing PRDs, specs and design docs by mapping every section to its new home, listing conflicts and duplicates as open questions, and moving content only after the user a...Votes: 0GitHub stars: 2
- Building Html PrototypesBuild responsive UI sketches and interactive prototypes as offline HTML: by default one self-contained file with embedded CSS, assets, and minimal JavaScript, or a design tree of pages that link the project's shared tokens and component styles by relative path. Use to compare design directions or refine an agreed application or feature experience before production implementation.Votes: 0GitHub stars: 2
- Designing Ux FlowsTranslate product requirements into UX flows, information hierarchy, screen responsibilities, interaction rules, content needs, and relevant interface states. Use when a user journey or feature behavior needs to be worked out before visual design or implementation.Votes: 0GitHub stars: 2
- Exploring Visual DirectionsDevelop and compare distinct visual direction briefs for a user-facing application or feature, including composition, typography, spacing, density, color, imagery, and motion, for a responsive page or a native platform surface such as a menu-bar panel, desktop window, phone widget, watch face, TV or car screen. Use when visual identity or UI design is unresolved, before rendering and choosing HTML prototype directions.Votes: 0GitHub stars: 2
- Guiding Product DiscoveryGuide a rough product, application, feature, or proof-of-concept idea through requirements, UX flows, visual directions, offline HTML prototypes, and a product/design handoff. Use to coordinate discovery across phases or resume unfinished design work; individual artifact requests belong to the relevant specialist.Votes: 0GitHub stars: 2
- Preparing Implementation HandoffsConsolidate requirements, UX flows, selected visual decisions, HTML prototypes, acceptance criteria, and suggested delivery slices into a product/design handoff. Use when discovery artifacts need to become a coherent brief for engineering planning, without inventing architecture or API contracts.Votes: 0GitHub stars: 2
- Shaping Product BriefsTurn a rough application, feature, or proof-of-concept idea into a product brief with audience, outcomes, scope, prioritized functional requirements, assumptions, and acceptance criteria. Use before design or implementation when the problem and intended behavior need clarification.Votes: 0GitHub stars: 2
- Brainstorming SolutionsResearches the codebase for prior art, reusable utilities, and constraints, generates two to four genuinely distinct technical approaches to an agreed spec.md, compares them in a table of architecture fit, risk, effort, and reversibility with a clear recommendation, and writes the approach the user picks, the rejected alternatives, and the consequences into the Approach section of spec.md, plus a decision record when the choice is consequential. Stage 2 of the product-engineering loop, gate G...Votes: 0GitHub stars: 2
- Defining VerificationAgrees with the user how the agent will prove its own work before implementation starts (stage 3 of the product-engineering loop, gate G3 Verification). Discovers the project's test, lint, typecheck, build and CI commands, how to install, seed and start the app, and which browser-driving and other verification tools the host exposes; writes or confirms docs/product-engineering/verification-profile.md; drafts one observable check per acceptance criterion in the Verification section of spec.md;...Votes: 0GitHub stars: 2
- Implementing PlansImplements one PR slice, a whole plan or one of its phases, from plans/NN-slug.md at stage 5 of the product-engineering loop: checks the assignment against spec.md, branches from a freshly synced base, writes a failing check first, makes the smallest coherent change, commits per logical step, runs targeted checks, updates the plan status, and hands the branch and its commits to verification. Also runs repair cycles for review findings by ID, verification failures with a repro, CI failures, an...Votes: 0GitHub stars: 2
- Planning ImplementationPlans the implementation of an agreed spec.md at stage 4 of the product-engineering loop and runs gate G4, whose approval launches autonomous work. Decomposes the work item into plans and phases, chooses PR slices that each stay green and releasable, sets dependencies and parallel work, predicts each slice's human or agent review category, maps acceptance criteria to phases, and drafts the autonomy contract after detecting the default branch, branch protection and deploy-on-merge and asking t...Votes: 0GitHub stars: 2
- Reviewing Code ChangesReviews a code change through five lenses (architecture, security, conventions and idioms, efficiency, intent), each run by a fresh-context reviewer that forms its own view, then deduplicates and substantiates the findings, rates them blocking, should-fix or nit, and gives an APPROVE or REQUEST CHANGES verdict pinned to the reviewed head SHA. Quick mode (stage 7) runs one intent reviewer on the committed branch before the pull request (merge request) opens and hands the findings back for fixi...Votes: 0GitHub stars: 2
- Running Implementation LoopsEntry point of the product-engineering loop: takes a work item from request to merged pull requests. Classifies it into a track (quick fix, bugfix, small change, feature, new app, refactor, spike), runs gates G1–G4 with the user, then runs each PR slice through implement, verify, review, PR and merge within the autonomy contract. Also implements a bet from a product context repository, read-only at its pinned commit and within its appetite, and hands the results back. Resumes from spec.md, ro...Votes: 0GitHub stars: 2
- Shipping Pull RequestsOpens, categorizes and lands one pull request per PR slice at stages 8 and 10 of the product-engineering loop. Pushes the branch, opens the PR with the verification report, computes the human or agent review category from the actual diff, watches required CI on the current head, runs the full review and fix loop, then merges an agent-category PR only through a head-pinned merge gate within the autonomy contract in roadmap.md, or requests human review and moves on to independent plans. Handles...Votes: 0GitHub stars: 2
- Specifying Work ItemsInterviews the user to turn an issue, product brief, product-design handoff, or a bet from a product context repository into an agreed spec.md with numbered requirements (R1…), observable acceptance criteria (AC1…), non-goals, constraints, and assumptions. Grounds itself in the code first so it never asks what the repository can answer, ranks the unknowns by impact, asks in short rounds where every question carries a recommended default and options, and ends with the user's explicit confirmat...Votes: 0GitHub stars: 2
- Verifying ImplementationVerifies a committed candidate for real, without the user (stage 6 of the product-engineering loop). Checks out the handed-over branch, confirms HEAD is the handed-over commit SHA and never commits, starts the app itself from that checkout with docs/product-engineering/verification-profile.md, runs the automated checks, drives the running product through every acceptance criterion in the Verification section of spec.md with the agreed tool (a browser-driving tool, an HTTP client, a CLI, a dat...Votes: 0GitHub stars: 2
- Improving PromptsRewrites a rough prompt into an engineered one. Classifies where the prompt will run (chat request, system prompt, coding or research agent task, agent operating instructions, long-document job, extraction or classification), diagnoses its gaps, applies the prompt and context engineering techniques that close them, and returns the techniques applied with reasons, the techniques rejected with reasons, placeholders for facts it could not infer, and a copy-paste-ready enhanced prompt inside an e...Votes: 0GitHub stars: 2
- Curating Design SystemsKeep a project's design home, the long-lived folder of shared design foundations such as tokens.css and components.css with a folder per platform and per view, to its four layout rules, and check after every change that each page's links, sources and CSS url() references resolve inside it. Use when adding to or reviewing a design home, or when asked where a token, component, platform style or view stylesheet belongs.Votes: 0GitHub stars: 2
- Building Prototype BetsBuilds an approved prototype bet in a loop until intent and result match: reads the bet at the commit it was approved at, plans, implements and commits each step as it finishes within the autonomy line, verifies every acceptance check by its named method with quoted evidence, has an independent reviewer in a fresh context compare the result with the bet's intent, fixes, and repeats. Starts as soon as the bet is approved and runs without the person until the result is ready to try, stopping on...Votes: 0GitHub stars: 2
- Closing Prototype BetsCloses a prototype bet after the person has tried it: asks keep or remove at Gate 2, showing the build log's checks with evidence, the checks only the person's eye can judge, and the bet's keep-or-remove signal. Keep folds the result into the context: requirement rows become built, planned architecture becomes built, decisions are recorded, the changelog entry stays. Remove reverts the bet's code commits, records its new requirements as dropped with the reason, deletes its planned architectur...Votes: 0GitHub stars: 2
- Framing Prototype IdeasFrames a prototype idea before any bet exists: checks what the prototype context and code already settle, compares two or three options, recommends one with a signal for removing it after a try, and gives a verdict of shape, park or stop in a one-page dated research note. Use when the user says I have an idea, should we try X, think this through, research this before we build it, or is this worth a bet. Not for shaping the bet (shaping-prototype-bets) or choosing the technical approach to an ...Votes: 0GitHub stars: 2
- Shaping Prototype BetsShapes one prototype bet from a framed idea: an observable outcome, an appetite of half a day to two days, requirement deltas with reserved permanent IDs, acceptance checks that each name how they are verified, no-gos, rabbit holes, cuttable scope, a keep-or-remove signal, a context pack, and an autonomy line. Checks readiness, gets the person's approval at Gate 1, records the commit the bet was approved at, and starts the build. Also reshapes a stopped bet, or a bet paused for a contract or ...Votes: 0GitHub stars: 2
- Structuring Prototype ContextCreates or adopts a prototype context: a context/ folder beside a prototype's code that keeps product, architecture, decisions, bets and notes in a light profile where ideas are tried and then kept or removed, with an AGENTS.md map, derived indexes, a decision record for the graduation trigger and a Keep a Changelog file per app. Adopts existing READMEs, specs, agent instructions and full-profile skeletons through an approved migration map. Use when the user says set up context for this proto...Votes: 0GitHub stars: 2