Menü
test-driven development workflow
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Remote control tmux sessions for interactive CLIs by sending keystrokes and scraping output.
Review a codebase, PR, or module for requirement fidelity, clean architecture quality, and production robustness. Verifies the change actually implements the stated requirement/user goal before checking structure, distinguishing design-level defects (right code, wrong product) from behavior bugs. Detects cross-layer business logic mixing, dependency direction violations, SOLID problems, module depth issues, information leakage, and KISS/over-engineering smells. Reports findings prioritized with SRE-style severity levels (P0-P3).
Practical guidance for writing, refactoring, and reviewing friendly Go code that is simple, idiomatic, and maintainable. Use whenever working with Go (.go) files, designing Go packages or APIs, structuring a new Go project, reviewing Go code, or refactoring Go modules. Also use when the user mentions goroutines, channels, context, error wrapping, interfaces, go.mod, package layout (cmd/internal/pkg), or Go project structure. Even if the user doesn't say "Go" explicitly, trigger this skill when the context involves .go files or go.mod/go.sum.
Validate and lint Agent Skill SKILL.md files and diagnose why a skill fails to load. Use whenever the user wants to check if a skill's frontmatter is valid, find out why a skill "vanished" or is not discovered, lint a single skill, or scan an entire skills directory before committing. Triggers on requests like "validate my skill", "why isn't my skill loading", "check the SKILL.md format", "lint my skills", "diagnose this frontmatter", or any request to verify skill name and description rules. Make sure to use this skill whenever a skill is unexpectedly missing from the available-skills list, since the usual cause is a silent frontmatter parse error rather than a discovery problem.
Write a grounded design/implementation doc for existing code, author a forward-looking design doc before code exists, or apply the embedded principles/checklist to review any design doc. Use whenever the user wants to understand, document, or reverse-engineer how a system, feature, or subsystem is architected (e.g. "how does X work in this repo", "document the Y subsystem", "reverse-engineer Z", "explain the design of W"), or wants to plan and write a new design doc before implementation (e.g. "write a design doc for X", "draft a design for this feature", "I need a design doc to coordinate this work"), or wants design-doc writing principles and a review checklist. Triggers on requests to analyze/document a system's internals, plan a new system's design, or review a design doc for completeness. Output follows a house format: prose + ASCII/Unicode/mermaid flowcharts, a key-file index, behavioral contracts, and a BDD scenario table, validated against checklist.md.
Guide a reverse-engineering proof-of-concept on a macOS crackme / license-check binary, for learning and interview preparation. Use this whenever the user is analyzing a app's authorization / license-gating module and wants to reconstruct its gating model, call chain, architecture differences (arm64 / x86_64 / universal Mach-O), and validate a minimal binary patch with LLDB and code signing. Trigger on mentions of crackme, license-check PoC, Mach-O / IDA / LLDB / objc_msgSend analysis, "find the gating branch", patch validation, universal binary slices, keygen-me vs patch-me, or CTF-style binary patching — even when the user does not say the word "skill".
| name | tdd |
| description | test-driven development workflow |
Tests are living documentation. They describe what the product does, not how the code is wired internally. A test that breaks on a refactor (while behavior is unchanged) is a bad test -- it was coupled to implementation, not behavior.
Test observable behavior from the user/caller's perspective. Do not test internal mechanics.
Ask before writing any test:
| Test Type | Example | Verdict |
|---|---|---|
| Behavior | "rejected tool call shows error in red" | Good -- tests what user sees |
| Behavior | "CJK character at buffer edge stays in bounds" | Good -- tests an invariant |
| Surface | "reducer calls replace(state, field=X)" | Bad -- coupled to implementation |
| Surface | "_process_queue is called 3 times" | Bad -- tests internal wiring |
Surface tests verify that code does what it already says it does. They add no confidence and break on every refactor. They reflect the current implementation, not the product design intention.
Behavior tests verify what the system promises to its users/callers. They survive refactoring because they are anchored to outcomes, not code paths.
Understand: What product behavior is this test validating?
Root Cause: Why failing?
Fix Hierarchy (preference order):
Remember: Test failures are signals to investigate, not obstacles to bypass.
