Cygnusfear
@Cygnusfear
Public Skills
code-review
by Cygnusfear
This skill should be used when reviewing pull requests, performing comprehensive code review, analyzing code changes before merge, or when the user asks for thorough/ultra-critical code review. Performs EXTREMELY CRITICAL 6-pass analysis identifying runtime failures, code consistency issues, architectural problems, environment compatibility risks, and verification strategies. Posts structured review as GitHub PR comment. Use when user asks to "review PR", "review this code", "review changes", "check this PR", "analyze PR", "post review", or for Phase 3 of devflow. Supports parallel review mode with multiplier (code-review-3, code-review 6X) for consensus-based reviews. This is an ultra-critical reviewer that does not let things slip and desires only perfection.
obsidian-upgrade
by Cygnusfear
Upgrade Obsidian wikis to latest format. Handles structure migration (phases/tasks → features/specs), comment format upgrades (adding emoji prefixes), and Johnny Decimal feature organization. Use when user mentions "upgrade wiki", "migrate wiki", "update wiki format", or has old-format comments.
check-plan
by Cygnusfear
Audit implementation progress against a plan ticket, verify completed work, identify remaining tasks, and validate quality. Use when user asks to check plan status, verify implementation, see what's left to do, or validate plan completion.
requesting-code-review
by Cygnusfear
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
using-git-worktrees
by Cygnusfear
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
create-plan
by Cygnusfear
Create comprehensive implementation plan as a ticket based on analysis or report. Use when user asks to create a plan, plan implementation, design a solution, or structure work for a feature/refactor/fix.
receiving-code-review
by Cygnusfear
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
by Cygnusfear
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
ctx
by Cygnusfear
Use when starting a session on a project, returning after time away, or before making significant changes. Essential for building comprehensive understanding of project state through total recall and deep exploration.
executing-plans
by Cygnusfear
Use when you have a written implementation plan to execute in a separate session with review checkpoints
systematic-debugging
by Cygnusfear
ONLY USE THIS SKILL UPON USER/HOOMAN REQUEST TO USE EXACTLY THIS SKILL, ONLY RUN ON HOOMAN [OK]. Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
the-archivist
by Cygnusfear
This skill should be used when engineering decisions are being made during code implementation. The Archivist enforces decision documentation as a standard practice, ensuring every engineering choice includes rationale and integrates with Architecture Decision Records (ADRs). Use when writing code that involves choosing between alternatives, selecting technologies, designing architectures, or making trade-offs.
teams-driven-development
by Cygnusfear
Use when executing implementation plans with independent tasks in the current session
dispatching-parallel-agents
by Cygnusfear
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies