Cristhianzl
UserBattle-tested Claude Code configs — opinionated CLAUDE.md baselines, skills, slash commands and enforcement hooks you drop into any project
Categories
Indexed Skills (18)
debugging-agent-runs
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.
developing-features-tdd
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 non-TDD production code use developing-features; for new Components use building-langflow-components.
developing-features
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 production-code work — use it unless the user explicitly asks for TDD (tests-first / red-green-refactor), which is developing-features-tdd. For new Components specifically, use building-langflow-components. Pairs with ensuring-cross-platform for portability and writing-tests for coverage.
documenting-features
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 produce living docs alongside the code.
ensuring-cross-platform
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 Windows, macOS, Linux, ARM, Desktop, "works on my machine", or Docker in a Langflow context.
evaluating-ai-output
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.
exploratory-testing
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-tests for unit/integration/E2E coverage and regression checks.
fixing-bugs
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 change. For building new features use developing-features-tdd; for non-TDD code work use developing-features.
playwright-cli
Automate browser interactions, test web pages and work with Playwright tests.
reviewing-code
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.
running-agent-loops
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.
security-review
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, supply chain, logging, privacy). Applies a strict anti-regression protocol so fixes don't break the app. For designing security up front use threat-modeling; for the always-on security blockers in a normal PR use reviewing-code.
threat-modeling
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 diagram. Use at design time (before building) and again on any significant change (new data flow, new trust boundary, new third party, new auth path, new PII). A living activity, not a one-time document.
validating-in-reality
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 substitute for writing-tests (automated coverage) or /verify (static gates) — this is live-system proof on top of them.
writing-prd
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 framed before any solution. Not for engineering design docs / the technical "how" — that is a separate design doc (the PRD owns the what/why, the design doc owns the how).
writing-pull-requests
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
writing-tests
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. For TDD bug fixes use fixing-bugs; for TDD feature work use developing-features-tdd; for the React frontend Langflow ships its own .agents/skills/frontend-testing.
building-langflow-components
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 existing component, also see Langflow's bundled `.agents/skills/component-refactoring` skill.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.