igor1309
@igor1309
Public Skills
job-search-strategy
by igor1309
Comprehensive job search strategy toolkit for analyzing job postings, discovering hidden insights, interviewing candidates to match skills, developing targeted skills, and executing creative outreach strategies. Use when helping candidates strategize their job search, prepare tailored applications, or develop competitive advantages in their job hunt.
arch-doc-review
by igor1309
Checklist for reviewing architecture and design docs in PRs
testing-schedulers
by igor1309
Testing time-dependent behavior with RxSwift schedulers. Use when testing delays, debouncing, background operations, or any time-based behavior that requires advancing virtual time.
spec-writing
by igor1309
Spec structure, required sections, and constraints for defining component contracts before implementation
rx-tdd-essentials
by igor1309
Use when developing or migrating Rx reducers and effect handlers with a test-first workflow before moving code into production files.
product-intent-review
by igor1309
Use when a Product Intent artifact needs review for story centrality, actor/outcome clarity, acceptance signals, boundaries, traceability, or downstream change-impact discipline.
research
by igor1309
Use when a concrete question, tension, or uncertainty needs problem-space exploration, constraint discovery, terminology alignment, risk identification, and decision-useful output before design commitment.
spec-drafting
by igor1309
Use when accepted Product Intent or architectural decisions need to be translated into explicit behavior, contracts, flows, edge cases, and testable expectations before implementation.
pre-adr-drafting
by igor1309
Use when research and discussion need to be turned into structured architectural exploration with options, tradeoffs, provisional boundaries, and open questions before committing to an ADR.
adr-drafting
by igor1309
Use when architectural exploration is complete enough to lock a decision and write or revise an ADR as the commitment artifact.
pre-adr-review
by igor1309
Use when a pre-ADR exists and needs review for option quality, tradeoff clarity, provisional boundary clarity, or open-question quality before commitment moves to ADR.
product-intent-drafting
by igor1309
Use when user-facing capability, actors, user stories, acceptance signals, boundaries, or downstream traceability need to be captured before research, ADRs, specs, implementation plans, or code.
spec-review
by igor1309
Use when a spec exists and needs adversarial review for behavioral clarity, contract completeness, edge-case coverage, or boundary discipline before or during downstream work.
implementation-plan-drafting
by igor1309
Use when an accepted spec needs to be turned into an ordered delivery path with slices, dependencies, risks, validation gates, and completion signals before coding starts.
adr-review
by igor1309
Use when an ADR exists and needs adversarial review for decision quality, boundary clarity, consistency, or stability before or during downstream work.
implementation-plan-review
by igor1309
Use when an implementation plan exists and needs adversarial review for sequencing, dependency handling, risk isolation, validation gates, or boundary respect before or during execution.
bug-analysis
by igor1309
Analyze a reported bug by tracing the likely execution path, forming evidence-based root-cause hypotheses, and producing a structured debugging report. Use when the task is to investigate or explain a bug before implementing a fix.
tactical-action-plan-guide
by igor1309
Use when an approved review finding needs a safe, dependency-aware implementation plan that keeps the codebase working after every step.
component-arch-review
by igor1309
Use when reviewing an implemented component and you need a principle-driven critique focused on root causes, strategic impact, and verifiable improvement paths rather than a laundry list of code smells.
executable-spec-scaffolding
by igor1309
Use when drafting executable specifications for service, orchestrator, or collaborator-heavy components where responsibility boundaries, shared orchestration, and collaborator contracts must be made explicit before implementation.
feature-spec-protocol
by igor1309
Use when creating a feature specification through an ordered clarification protocol that asks one question at a time, avoids hidden assumptions, and fills the spec incrementally.
arch-spec-review
by igor1309
Review architecture specifications for completeness, appropriate abstraction level, separation of concerns, implicit architectural risk, and the intentionality of mature architecture decisions. Use when reviewing top-level, implementation-agnostic architecture documents that define system boundaries, responsibilities, flows, constraints, and rationale without prescribing implementation details.
arch-reviewer
by igor1309
Structured, detached evaluation of component or system architecture clarity and intent. Use when reviewing early-stage or medium-fidelity design docs, component boundaries, or system flow sketches to assess whether they communicate ownership, direction, and rationale clearly.
tdd-essentials
by igor1309
Use when implementing a feature or bug fix under strict TDD rules with red, green, commit, and refactor checkpoints.