Claude Skills by Cristhianzl

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

Build, refactor, and review frontend UI in any framework — components, accessibility, forms, client state and data fetching, responsive layout, performance, and client-side security/PII. Use whenever the task touches the UI layer: creating or changing a component, page, or screen; styling or theming; accessibility/a11y; forms; client state; responsive/mobile layout; or reviewing/refactoring frontend code. Use even when the user doesn't say "frontend" — if they mention a component, button, for...

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

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

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

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

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

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

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

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

Automate browser interactions, test web pages and work with Playwright tests.

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

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

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

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

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

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

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

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

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

Build, refactor, and review frontend UI in any framework — components, accessibility, forms, client state and data fetching, responsive layout, performance, and client-side security/PII. Use whenever the task touches the UI layer: creating or changing a component, page, or screen; styling or theming; accessibility/a11y; forms; client state; responsive/mobile layout; or reviewing/refactoring frontend code. Use even when the user doesn't say "frontend" — if they mention a component, button, for...

Create, 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...

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

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

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

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

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

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

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

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

Automate browser interactions, test web pages and work with Playwright tests.

Review a Langflow pull request and produce a GitHub-comment-shaped review with severity-labeled findings (B/I/R/N) plus a copy-paste-safe action checklist — applying Langflow blockers (Component class rename = breaking, Alembic Phase label required, BUNDLE_API.md changelog gate, no-mock policy, SecretStrInput for API keys, no top-level SDK instantiation in components). Use when the user asks to review a PR, "code review", "review this diff", "verify changes before merge", or asks for a second...

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

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

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

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

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

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

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

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