igor1309
@igor1309
Public Skills
vortex-seasoned-ios-developer
by igor1309
Use when generating or reviewing Swift and SwiftUI code for Vortex and you need its formatting, documentation, and XCTest conventions.
tdd-flow
by igor1309
Use when enforcing a strict test-driven development cycle with explicit stop points at red and after refactor.
tdd-spec-review
by igor1309
Use when reviewing a TDD executable specification for clarity, completeness, and alignment with implementation-driving tests.
tdd-practitioner
by igor1309
Use when implementing a feature or bug fix with test-driven development and you need guidance through the red-green-refactor cycle.
swift-xctest-testing-master-prompt
by igor1309
Use when writing or reviewing XCTest suites for Swift code and you need standards for structure, naming, async testing, spies, and formatting.
tdd-interactive
by igor1309
"Interactive Test-Driven Development workflow with reviewer-in-the-loop. Implements the RED-GREEN-REFACTOR cycle with two mandatory verification gates where a reviewer (human or AI) approves work before progression. Applies to any code development that follows test-first methodology: features, bug fixes, refactoring, or enhancements. Invoked when TDD discipline with step-by-step verification is required."
doc-drift-audit
by igor1309
This skill should be used when the user asks to "audit documentation", "check if docs are up to date", "verify docs match code", "run a doc drift audit", "find stale documentation", "check README accuracy", or after large refactors that may have left documentation out of sync with the codebase. Detects factual mismatches between markdown documentation and code — wrong names, signatures, paths, behaviors. Does not rewrite, reformat, or improve docs.
tdd-scaffold-review
by igor1309
"Evaluates test name scaffolds for TDD readiness by determining if each test name provides enough specification clarity to write a failing test. Use when reviewing test scaffolds, evaluating executable specifications, or assessing whether test names clearly define testable behavior without implementation ambiguity."