Cristhianzl
- 20 skills
- 0 followers
- 13 hours ago last updated
- ▌ Reviewing Code 2 · cristhianzl bundleReview 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.
- ▌
- ▌ Fixing Bugs · cristhianzl bundleFix 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.
- ▌ Writing Prd · cristhianzl bundleAuthor 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 Tests · cristhianzl bundleWrite 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.
- ▌ Reviewing Code · cristhianzl bundleReview 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.
- ▌ Security Review · cristhianzl bundleReview 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 · cristhianzl bundleStructured 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.
- ▌ Developing Features · cristhianzl bundleWrite 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-cross-platform for portability and writing-tests for coverage.
- ▌ Exploratory Testing · cristhianzl bundleRun 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.
- ▌ Running Agent Loops · cristhianzl bundleRun 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.
- ▌
- ▌ Debugging Agent Runs · cristhianzl bundleRecover 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.
- ▌ Documenting Features · cristhianzl bundleProduce 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.
- ▌ Evaluating AI Output · cristhianzl bundleEvaluate 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.
- ▌ Validating In Reality · cristhianzl bundleValidate 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 Pull Requests · cristhianzl bundleGenerate 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.
- ▌ Developing Features Tdd · cristhianzl bundleBuild 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.
- ▌ Ensuring Cross Platform · cristhianzl bundleApply 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.
- ▌ Building Langflow Components · cristhianzl bundleCreate, 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.