All authors
Claude Skills by Cristhianzl
github.com/Cristhianzl31 skills0 installs57 views
- Api DesignDesign and review HTTP/REST (and choose between REST/GraphQL/gRPC) APIs that are contract-first, resource-oriented, backward-compatible, and secure by default. Use whenever the task touches an API surface — designing an API, adding or changing an endpoint or route, picking an HTTP method or status code, naming resources, paginating a list, versioning, deprecating a field, modeling errors, idempotency, concurrency, webhooks, or writing an OpenAPI spec. Triggers: "design an API", "add an endpoi...Votes: 0GitHub stars: 5
- Building Frontend UiBuild, refactor, and review frontend UI in any framework — components, accessibility, forms, client state and data fetching, responsive layout, performance, client-side security/PII, and UX/visual design (design plan, tokens, typography, color, spacing, motion). Use whenever the task touches the UI layer: creating or changing a component, page, or screen; designing a site, landing page, or product surface from scratch; styling or theming; accessibility/a11y; forms; client state; responsive/mo...Votes: 0GitHub stars: 5
- Debugging Agent RunsRecover when the AGENT itself is stuck — looping, repeating the same failed action, burning tokens/budget, overflowing context, drifting from the goal, or acting on stale state. Use when a run isn't converging and reworded retries aren't helping. This is a workflow you follow, not a hidden runtime that auto-heals. For bugs in the product code use fixing-bugs.Votes: 0GitHub stars: 5
- Developing Features TddBuild a new feature using strict test-driven development — UNDERSTAND → DESIGN → RED → VERIFY RED → GREEN → VERIFY GREEN → REFACTOR → VALIDATE → REPEAT. Use when building a new feature with TDD, when the user says "TDD this", "tests first", "red green refactor", or asks for feature work that needs to be verifiable from the spec. For bug fixes use fixing-bugs; for non-TDD production code use developing-features.Votes: 0GitHub stars: 5
- Developing FeaturesWrite production code with security-first thinking, SOLID design, pragmatic principles, observability, and strict file-structure limits. Use when implementing a new feature, designing a system, refactoring code, or whenever the task is "build production code" rather than fix a bug or write tests. This is the default for feature and production-code work — use it unless the user explicitly asks for TDD (tests-first / red-green-refactor), which is developing-features-tdd. Pairs with ensuring-cro...Votes: 0GitHub stars: 5
- Documenting FeaturesProduce living, DDD-aligned feature documentation as a single Markdown file with 10 fixed sections — overview, ubiquitous language, domain model, Gherkin behaviors, ADRs, technical spec, observability, deployment & rollback, C4 diagrams, platform compatibility. Use when the user asks to document a feature, write feature docs, create ADRs, document the domain model, or produce living docs alongside the code.Votes: 0GitHub stars: 5
- Ensuring Cross PlatformApply platform-agnostic engineering rules so code, tests, and Docker builds behave identically on Linux, macOS, and native Windows. Use when writing or reviewing code that touches the filesystem, shell, subprocess, encoding, time, paths, native dependencies, or CI matrix — or when the user mentions Windows, macOS, Linux, "works on my machine", cross-platform, portability, or Docker.Votes: 0GitHub stars: 5
- Evaluating Ai OutputEvaluate non-deterministic LLM/AI output with evals instead of one-shot "it worked" — define expected behavior first, measure pass@k / pass^k, and grade with code / model / human graders. Use when building or changing an AI/LLM feature, an agent, a prompt, a RAG pipeline, or a classifier, where a single good run is not proof of correctness. Complements writing-tests (deterministic logic) and developing-features-tdd.Votes: 0GitHub stars: 5
- Exploratory TestingRun structured exploratory testing — write a charter, time-box a session, apply heuristics and oracles to discover bugs the scripted suite never looks for, then debrief and file solid bug reports. Use when the user says "test this manually", "find bugs", "explore the feature", "edge cases", "risk-based testing", "session-based", or asks for a charter, a test session, or a bug hunt on a flow that already "works". Framework- and stack-agnostic. Not for writing automated tests — use writing-test...Votes: 0GitHub stars: 5
- Fixing BugsFix a bug using strict TDD — UNDERSTAND → REPRODUCE (RED) → VERIFY RED → FIX → VERIFY GREEN → VALIDATE → REFACTOR. Use when the user reports a bug, asks to fix something, mentions a Sentry/error/regression, or pastes a stack trace. Bugs require a failing test that proves the bug existed before any code change. For building new features use developing-features-tdd; for non-TDD code work use developing-features.Votes: 0GitHub stars: 5
- Reviewing CodeReview a pull request and produce a human-voiced, copy-paste-safe review — first person, evidence first, findings as complete sentences ordered by severity (Blocker / Important / Recommended / Nice-to-have as internal triage, never as labels), each with file:line evidence and a disposition. Use when the user asks to review a PR, "code review", "review this diff", "verify the changes before merge", or asks for a second opinion on someone else's branch. Output is the review in chat — never run ...Votes: 0GitHub stars: 5
- Running Agent LoopsRun a multi-step or unattended agent loop safely — sequential pipelines, implement→review→fix (PR) loops, parallel fan-out, and RFC→DAG orchestration. Use when the user wants to "loop", "run autonomously", "iterate until it's done", chain `claude -p` calls, fan out parallel agents on a spec, or set up an implement→verify→commit cycle. Covers the cross-iteration context bridge and the de-sloppify pass. Not for a single one-shot task.Votes: 0GitHub stars: 5
- Security ReviewReview an application's code for security across frontend AND backend and produce a prioritized, safe-to-apply remediation plan — OWASP Top 10 (2025), OWASP API Top 10, plus privacy (LGPD/GDPR). Use when the user asks for a "security review", "security audit", "harden this", "is this secure?", "check for vulnerabilities", "OWASP", "pentest-style review", or wants a focused security pass on a feature/PR/app (secrets, access control, injection, auth/session, headers/CORS/CSRF, file upload, supp...Votes: 0GitHub stars: 5
- Threat ModelingStructured security design analysis — find what can go wrong before an attacker does. Build a Data Flow Diagram with trust boundaries, apply STRIDE per element, add abuse/misuse cases, and map every threat to a control and a test. Use when the user asks to threat model a feature/system, run STRIDE, map the attack surface, do a security design review, write abuse cases, identify trust boundaries, ask "what could go wrong" / "what are the security risks of this feature", or draw a data flow dia...Votes: 0GitHub stars: 5
- Validating In RealityValidate a bugfix or feature against the REAL running system — execute the user's cURL, assert actual responses, check persisted database state, and drive the UI end-to-end — instead of assuming the code change works. Use whenever the user provides a cURL command, a localhost/endpoint URL, or asks to "validate", "test it for real", "check the database", "no assumptions", or when finishing a bugfix/feature in a project with a running server. The user's cURL IS the acceptance test. Not a substi...Votes: 0GitHub stars: 5
- Writing PrdAuthor product requirements — PRDs, product specs, one-pagers, PR-FAQs, product briefs — that lead with the problem, define testable success metrics and acceptance criteria, and make non-goals explicit. Use when the user asks to write a PRD, write/define product requirements, write a product spec, write a one-pager, write a PR-FAQ, "write a spec", "define requirements", scope a feature, or draft a product brief. Also use when the request is a half-baked feature idea that needs a problem frame...Votes: 0GitHub stars: 5
- Writing Pull RequestsGenerate conventional-commit PR titles, commit messages, and concise PR descriptions from staged changes or a branch diff. Use when the user asks to create a PR, write a PR title, generate a commit message, or draft a PR description. Output goes directly to the chat — never to a file.Votes: 0GitHub stars: 5
- Writing TestsWrite unit, integration, and E2E tests that follow the testing pyramid, the Arrange-Act-Assert pattern, the should_X_when_Y naming convention, and meet a 75% (target 80%) branch coverage gate per supported OS. Use when the user asks to write tests, add coverage, build a test suite, fix flaky tests, or verify a feature with tests. For TDD bug fixes use fixing-bugs; for TDD feature work use developing-features-tdd.Votes: 0GitHub stars: 5
- Building Langflow ComponentsCreate, evolve, and ship Langflow Components — the building blocks of every flow. Use when the user asks to "create a component", "add a provider component", "build an LLM component", "add Anthropic / OpenAI / Chroma / etc. integration", "expose this as a Component", or "wrap this LangChain class as a Component". Enforces the immutable-class-name rule, the inputs/outputs API, the hot-reload workflow, ComponentTestBase fixtures, and the bundle-vs-base placement decision. For refactoring an exi...Votes: 0GitHub stars: 5
- Developing Features TddBuild a Langflow feature with strict TDD — UNDERSTAND → DESIGN → RED → VERIFY RED → GREEN → VERIFY GREEN → REFACTOR → VALIDATE → REPEAT — applying Langflow's prefer-real-integrations-over-mocks policy, ComponentTestBase fixtures, and the graph test pattern from AGENTS.md. Use when building a new feature with TDD, when the user says "TDD this", "tests first", "red green refactor", or asks for feature work in Langflow that needs to be verifiable from the spec. For bug fixes use fixing-bugs; for...Votes: 0GitHub stars: 5
- Developing FeaturesWrite production code in Langflow with security-first thinking, SOLID design, pragmatic principles, observability, and strict file-structure limits — tuned for Langflow conventions (uv workspaces, SQLModel, lfx vs langflow-base split, pre-commit invoked via uv run). Use when implementing a new feature, designing a service, refactoring backend code, adding an API route, or whenever the task is "build production code" rather than fix a bug or write tests. This is the default for feature and pro...Votes: 0GitHub stars: 5
- Documenting FeaturesProduce Langflow feature documentation — engineering-side as a 10-section single Markdown file (overview, ubiquitous language, domain model, Gherkin behaviors, ADRs, technical spec, observability, deployment, C4 diagrams, platform compatibility) AND user-facing pages in the Docusaurus site at docs/docs/ (Concepts, Components, Bundles, Contributing). Use when the user asks to document a Langflow feature, write feature docs, create ADRs, document a Component for users, update BUNDLE_API.md, or ...Votes: 0GitHub stars: 5
- Ensuring Cross PlatformApply platform-agnostic engineering rules so Langflow code, tests, and Docker images behave identically on Ubuntu, macOS (Intel x86_64 + Apple Silicon arm64), and native Windows — plus the linux/amd64 + linux/arm64 Docker matrix and the separate Langflow Desktop distribution for Windows and macOS. Use when writing or reviewing code that touches the filesystem, shell, subprocess, encoding, time, paths, native dependencies, the cross-platform-test workflow, or Docker — or when the user mentions...Votes: 0GitHub stars: 5
- Fixing BugsFix a Langflow bug using strict TDD — UNDERSTAND → REPRODUCE (RED) → VERIFY RED → FIX → VERIFY GREEN → VALIDATE → REFACTOR — with Langflow hotspot awareness (lfx vs langflow-base split, dynamic component discovery, expand-contract Alembic migrations, pre-commit must invoke uv run git commit). Use when the user reports a bug in Langflow, mentions Sentry/error/regression, pastes a stack trace, or asks to fix something. Bugs require a failing test that proves the bug existed before any code chan...Votes: 0GitHub stars: 5
- Writing Pull RequestsGenerate Langflow-shaped PR titles, commit messages, and descriptions from staged changes or a branch diff — conventional-commit format with Langflow scopes (auth, components, graph, api, frontend, bundles/<name>, lfx, docs, ci), Fixes #N allowed in description, no Co-Authored-By trailer, version bumps via make patch v=X.Y.Z, BUNDLE_API.md callout when bundles change, breaking-change ! flag when a Component class rename or public surface change is involved. Use when the user asks to create a ...Votes: 0GitHub stars: 5
- Writing TestsWrite unit, integration, and E2E tests in Langflow that follow the pyramid, AAA structure, should_X_when_Y naming, the 75% (target 80%) branch coverage gate per supported OS, AND Langflow's specific conventions (prefer real integrations over mocks per AGENTS.md, ComponentTestBase[With/Without]Client fixtures, uv run pytest, sub-package dev sync, marks like api_key_required and no_blockbuster). Use when writing tests, adding coverage, building a test suite, or fixing flaky tests in Langflow. F...Votes: 0GitHub stars: 5
- Reviewing CodeReview a pull request and produce a GitHub-comment-shaped review document with severity-labeled findings (Blocker / Important / Recommended / Nice-to-have) plus a copy-paste-safe action checklist for the author. Use when the user asks to review a PR, "code review", "review this diff", "verify the changes before merge", or asks for a second opinion on someone else's branch. Output is the review comment in chat — never run git or post to GitHub directly.Votes: 0GitHub stars: 5
- Optimizing DiscoverabilityOptimize a site or content to be found — SEO (rank and earn the click on Google/Bing), AEO (be the direct answer in featured snippets, People Also Ask, and voice assistants), and GEO (be the source that ChatGPT, Claude, Perplexity, and Google AI Overviews cite). Use whenever the task involves search visibility or AI visibility: "SEO", "AEO", "GEO", "rank on Google", "organic traffic", "featured snippet", "meta description", "keywords", "be cited by AI / ChatGPT", "AI Overviews", "llms.txt", c...Votes: 0GitHub stars: 5
- Stress TestingPlan, run, and interpret load and stress tests — smoke, average-load, stress, spike, breakpoint, and soak — with realistic workload modeling (open vs closed model, coordinated omission) and SLO-based thresholds (p95/p99, error rate). Use ONLY when the user explicitly asks for a load test, stress test, performance test under load, capacity check, spike/soak/breakpoint test, or "how much traffic can this handle". NEVER run or suggest running load tests proactively — they hammer real systems, co...Votes: 0GitHub stars: 5
- Developing Features TddBuild a new feature using strict test-driven development — UNDERSTAND → DESIGN → RED → VERIFY RED → GREEN → VERIFY GREEN → REFACTOR → VALIDATE → REPEAT. Use when building a new feature with TDD, when the user says "TDD this", "tests first", "red green refactor", or asks for feature work that needs to be verifiable from the spec. For bug fixes use fixing-bugs; for non-TDD production code use developing-features.Votes: 0GitHub stars: 2
- Developing FeaturesWrite production code with security-first thinking, SOLID design, pragmatic principles, observability, and strict file-structure limits. Use when implementing a new feature, designing a system, refactoring code, or whenever the task is "build production code" rather than fix a bug or write tests. This is the default for feature and production-code work — use it unless the user explicitly asks for TDD (tests-first / red-green-refactor), which is developing-features-tdd. Pairs with ensuring-cro...Votes: 0GitHub stars: 2