All authors
Claude Skills by ryanthedev
github.com/ryanthedev38 skills0 installs34 views
- Aposd Designing Deep ModulesEnforce Design-It-Twice workflow: generate 2-3 radically different approaches, compare them, then implement. Use when designing modules, APIs, or classes before implementation. Triggers on: design, create class, add module, implement feature, new service, API design, before implementing. Produces structured design document with approaches, comparison table, choice rationale, and depth check.Votes: 0GitHub stars: 369
- Aposd Improving Code ClarityEnforce comments-first workflow for new code and improve naming/documentation for existing code. Use when writing new classes, methods, or functions; when code is 'confusing' or 'hard to understand'; when naming precision is poor; or when variable documentation lacks units, bounds, or ownership. Triggers on: new code, comments-first, naming review, documentation review, not obvious, hard to understand. Produces well-documented code with precise naming, or identifies design problems when comme...Votes: 0GitHub stars: 369
- Aposd Maintaining Design QualityEnforce strategic programming discipline when modifying existing code. Guide through STOP-ASK-DECIDE-VERIFY workflow with urgency tier assessment (trivial/minor/standard/emergency). Include when NOT to refactor (Chesterton's Fence, performance-critical, no tests) and block tactical shortcuts via anti-rationalization tables. Use when fixing bugs, extending features, or tempted to make quick fixes. Triggers on: modify code, fix bug, extend feature, quick fix, tactical change.Votes: 0GitHub stars: 369
- Aposd Optimizing Critical PathsOptimize performance through mandatory measure-first workflow with 3 stages: MEASURE (gate) -> FUNDAMENTAL FIX -> CRITICAL PATH REDESIGN. Use when code is too slow, laggy, hangs, doesn't scale, has timeouts, OOM errors, or high CPU/memory. Emphasize that simpler code usually runs faster. Triggers on: performance issues, optimization needed, takes forever, profiling. Produces profiling-backed optimization with verified improvement.Votes: 0GitHub stars: 369
- Aposd Reviewing Module DesignEvaluate module design using APOSD principles with 40-item checklist. Detect complexity symptoms (change amplification, cognitive load, unknown unknowns), shallow modules, information leakage, pass-through methods, and structural anti-patterns. Produce categorized design review (Critical/Moderate/Observations/Positive). Use when reviewing code, assessing interfaces, during PR review, or evaluating 'is this too complex?' Triggers on: code review, design review, module complexity, interface ass...Votes: 0GitHub stars: 369
- Aposd Simplifying ComplexitySimplify complex code through the Error Reduction Hierarchy: Define out > Mask > Aggregate > Crash. Use when code is too complex, has scattered error handling, configuration explosion, or callers doing module work. Produce technique analysis table with gate checks before simplified code. Triggers on: too complex, simplify, scattered errors, configuration proliferation, verbose error handling. Complements cc-defensive-programming with design-level error elimination.Votes: 0GitHub stars: 369
- Aposd Verifying CorrectnessVerify code correctness before claiming done or committing. Run 6-dimension checklist: requirements coverage, concurrency safety, error handling, resource management, boundary conditions, and security. Output PASS/FAIL per dimension with final DONE/NOT DONE verdict. Use after implementation as pre-commit gate. Triggers on: is it done, ready to commit, verify correctness, did I miss anything, pre-commit check.Votes: 0GitHub stars: 369
- Cc Code Layout And StyleReview code formatting and documentation using 74-item checklist from Code Complete. Two modes: CHECKER executes checklists with evidence tables, APPLIER guides layout decisions and commenting strategy. Use when code has inconsistent formatting, poor visual structure, unclear comments, or readability issues. Triggers on: review formatting, check layout, code style review, commenting style, make readable, multiple statements per line, endline layout, comments repeat code.Votes: 0GitHub stars: 369
- Cc Construction PrerequisitesVerify construction prerequisites using 66-item checklists across requirements, architecture, and coding conventions. Output status tables (VIOLATION/WARNING/PASS) in CHECKER mode or prerequisite allocation recommendations in APPLIER mode. Use when unsure if project is ready to code, requirements feel incomplete, architecture unclear, no coding conventions defined, or noticing urge to skip planning. Triggers on: ready to start coding, review requirements, check architecture, define convention...Votes: 0GitHub stars: 369
- Cc Control Flow QualityReview control flow quality using 87-item checklist. Use when code has deep nesting (3+ levels), complex conditionals, loop design questions, high cyclomatic complexity (McCabe >10), or callback hell. Symptoms: arrow-shaped code, repeated conditions, confusing loop exits, lengthy if-else chains. Provide refactoring patterns (guard clauses, named booleans, table-driven methods) and modern guidance (async/await, pattern matching, functional pipelines). Produce verified code with pass/fail asses...Votes: 0GitHub stars: 369
- Cc Data OrganizationAudit and fix data organization: variable declarations, data types, magic numbers, naming conventions, and global data. Three modes: CHECKER (92-item checklist -> status table), APPLIER (type selection and naming guidance), TRANSFORMER (fix violations). Cover modern types: concurrent/shared state, nullable/optional, temporal/timezone, security-sensitive. Use when reviewing code for data organization issues, choosing data types, or fixing magic numbers. Triggers on: review variables, data type...Votes: 0GitHub stars: 369
- Cc DebuggingGuide systematic debugging using scientific method: STABILIZE -> HYPOTHESIZE -> EXPERIMENT -> FIX -> TEST -> SEARCH. Two modes: CHECKER audits debugging approach (outputs status table with violations/warnings), APPLIER guides when stuck (outputs stabilization strategy, hypothesis formation, fix verification). Use when encountering ANY bug, error, test failure, crash, wrong output, flaky behavior, race condition, regression, timeout, hang, or code behavior differing from intent. Triggers on: d...Votes: 0GitHub stars: 369
- Cc Defensive ProgrammingReview error handling, input validation, and exception patterns using 24-item checklist. Use when auditing defensive code, designing barricades, choosing assertion vs error handling, or deciding correctness vs robustness strategy. Triggers on: empty catch blocks, missing input validation, assertions with side effects, wrong exception abstraction level, garbage in garbage out mentality, deadline pressure to skip validation, trusted source rationalization. Produce status table with VIOLATION/WA...Votes: 0GitHub stars: 369
- Cc Developer CharacterEnforce developer discipline under pressure by detecting rationalization patterns and providing counter-arguments. Use when stuck debugging, considering skipping reviews, feeling overconfident about technical decisions, resisting unfamiliar techniques, or treating methodology as dogma. Triggers on: just compile and see, ignoring warnings, 90% complete for weeks, gonzo programming, I don't need to test this, unrealistic estimates.Votes: 0GitHub stars: 369
- Cc Documentation QualityReview documentation quality across README, comments, API docs, changelog, and AI documentation (CLAUDE.md, .cursorrules, copilot-instructions). Use when checking if documentation matches code, comments are stale, new features lack docs, or reviewing PR documentation. Triggers on: review docs, stale comments, update changelog, documentation debt, README accuracy, PR documentation review, missing docs.Votes: 0GitHub stars: 369
- Cc Integration PracticesAudit integration strategy and daily build processes (CHECKER) or select optimal integration approach and configure CI/CD (APPLIER). Use when integrating components, planning integration order, setting up build processes, or diagnosing integration failures. Triggers on: integration hell, late-stage defects, unclear integration order, no daily build, broken builds, Big Bang integration, smoke test stale. Produce integration strategy recommendations, build process configuration, 13-item checkli...Votes: 0GitHub stars: 369
- Cc Performance TuningEnforce measure-first discipline for code optimization using a 7-step gated decision tree and 40-item checklist. Use when code is too slow, has performance issues, timeouts, OOM errors, high CPU/memory, or doesn't scale. Triggers on: profiler hot spots, latency complaints, unresponsive UI, memory allocation slow, needs optimization. Produce violation/warning/pass table with evidence.Votes: 0GitHub stars: 369
- Cc Pseudocode ProgrammingGuide routine design using the Pseudocode Programming Process (PPP). Produce pseudocode design, header comments, and implementation plan. Use when designing routines, stuck on where to start coding, caught in compile-debug loops, or code works but you don't understand why. Triggers on: can't name the routine, Just One More Compile syndrome, staring at screen, coded into a corner, keep hacking but still broken, too many compiler warnings, overwhelmed by where to start.Votes: 0GitHub stars: 369
- Cc Quality PracticesExecute quality checklists (112+ items) for code review, testing strategy, and debugging. CHECKER mode audits QA practices with evidence tables. APPLIER mode generates test cases (5:1 dirty ratio), runs Scientific Debugging Method (STABILIZE-HYPOTHESIZE-EXPERIMENT-FIX-VERIFY-SEARCH), or sets up inspection procedures. Use when planning QA, choosing review methods, designing tests, or debugging fails. Triggers on: defects found late, tests pass but production bugs, coverage disputes, review ine...Votes: 0GitHub stars: 369
- Cc Refactoring GuidanceGuide safe refactoring with research-backed discipline and small-change rigor. Produce refactoring approach, step sequence, and risk assessment. Use when modifying existing code, improving structure without changing behavior, or deciding between refactor, rewrite, or fix-first. Triggers on: code smells, technical debt, just cleaning while I fix, small change treated casually, regression from trivial change, one-line change errors, production down with cleanup urge.Votes: 0GitHub stars: 369
- Cc Routine And Class DesignEvaluate routine and class design quality using Code Complete checklists (43 items). Use when designing routines or classes, reviewing class interfaces, choosing between inheritance and containment, or evaluating routine cohesion. Also trigger when tempted to use inheritance as a quick fix under deadline pressure, or when rationalizing 'but it works' for code with deep inheritance or many parameters. Produce severity-tagged reviews (VIOLATION/WARNING/PASS) in CHECKER mode or design decisions ...Votes: 0GitHub stars: 369
- Cc Table Driven MethodsReplace complex conditional logic with table lookups. CHECKER mode identifies opportunities where if/else chains or inheritance hierarchies should become tables. APPLIER mode designs table structure, access method (direct/indexed/stair-step), and key transformations. Use when writing 4+ if/else branches, switch statements keep growing, subclasses differ only in data not behavior, or data changes without code changes. Triggers on: too many if statements, switch growing, subclass per type, cust...Votes: 0GitHub stars: 369
- Code FoundationsClassify code tasks and execute task-specific checklists with quality gates. Route to WRITE, DEBUG, REVIEW, OPTIMIZE, REFACTOR, SIMPLIFY, or SECURE workflows, each invoking relevant CC and APOSD skills. Produce classification statement plus DONE/NOT DONE verdict with mandatory pre-commit verification. Use when writing, debugging, reviewing, fixing, implementing, optimizing, refactoring, simplifying, or securing code. Triggers on: implement, build, create, debug, fix bug, broken, error, review...Votes: 0GitHub stars: 369
- Concise Doctrine**Question:** when the build agent is given the *same* checklist content, does delivering it via the **Skill tool** (`Skill(code-foundations:<name>)`, self-loads checklists — current main) produce different code than delivering it via **`Read()`** of the same `SKILL.md` + `checklists.md`? **Design:** arms differ ONLY in the build-agent's (+ review-agent's) "Load Phase Skills" section. Identical dispatch, identical content (SKILL.md + checklists.md for cc-defensive-programming, cc-routine-and-...Votes: 0GitHub stars: 369
- ArmsDiscovery, design, and implementation in one pass. Scopes phase work, makes design decisions, stubs the interface, implements it, then validates with tests.Votes: 0GitHub stars: 369
- ArmsIndependent, execution-grounded review of a build phase against its done-when requirements. Runs the suite first, verifies each requirement with evidence and a trace, returns PASS or FAIL with specific findings.Votes: 0GitHub stars: 369
- Placeholder SkillPlaceholder skill directory required by skill-eval's run_eval tool signature. This benchmark runs configurations=['without_skill'] only — we are measuring raw model tiers, not a skill — so this file's content is never mounted or read by a subject session.Votes: 0GitHub stars: 369
- Build DoctrineImplements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: stub the interface, implement it, then write tests that validate the Done-When items and any important behavior beyond them.Votes: 0GitHub stars: 369
- Build DoctrineImplements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: write failing tests first then code to pass (red-green), covering the Done-When items and important behavior beyond them.Votes: 0GitHub stars: 369
- TddImplements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: for each Done-When item, write a failing test first, then the minimum code to make it pass (red-green).Votes: 0GitHub stars: 369
- Ca Architecture BoundariesApplies Clean Architecture's dependency-direction and SRP-by-actor rules to system-level boundary design: separates business logic from infrastructure, identifies actor-coupling risks, and enforces inward-pointing dependency arrows. For system scope (multiple components, layers, or services), not routine or module scope (use cc-routine-and-class-design).Votes: 0GitHub stars: 369
- ClarifyDecomposes underspecified requests by classifying gaps (missing info, ambiguity, false premises) and generating targeted clarifying questions. Produces a confirmed problem statement before any implementation begins. For sharpening a request that already exists; not for open-ended requirement discovery from a vague idea (use the research command).Votes: 0GitHub stars: 369
- Code Clarity And DocsAudits and improves code clarity and documentation using APOSD's obviousness rules: naming quality, comment accuracy, AI-facing doc completeness, and the comments-first workflow for new code. Not for generating project-wide convention docs (use code-standards) or structural simplification of the code itself (use aposd-simplifying-complexity).Votes: 0GitHub stars: 369
- Code StandardsGenerates or updates docs/code-standards.md by scanning the codebase for actual conventions. Produces an example-rich standards file optimized for LLM consumers, grounded in the project's real patterns. Not for auditing one file's naming, comments, or clarity (use code-clarity-and-docs).Votes: 0GitHub stars: 369
- Gof Design PatternsMaps code symptoms — exploding subclass combinations, switch-on-type dispatch, tangled object construction, incompatible interfaces, one-to-many update cascades — to the matching Gang of Four pattern, then loads that pattern's structural recipe from its 23 reference files. For selecting and implementing a design pattern; not for system-level boundaries (use ca-architecture-boundaries) or module interface depth (use aposd-designing-deep-modules).Votes: 0GitHub stars: 369
- Performance OptimizationApplies measure-first performance optimization: profiles to find hot spots, applies algorithm and data-structure improvements before micro-optimizations, and validates each change prevents regression. For single-process code tuning; not for correctness bugs (use cc-debugging) or concurrency, distributed, and real-time tuning (explicitly out of scope).Votes: 0GitHub stars: 369
- PlanningImplements the Standard/Full planning pipeline for Medium and Complex tasks: multi-step discovery, phase decomposition with skill matching, cross-cutting concerns, and plan emission with Gate fields.Votes: 0GitHub stars: 369
- Welc Legacy CodeSafely modifies untested legacy code by getting it under test first: characterization tests, seam identification, sprout/wrap techniques, and pinch-point testing before any production changes. Not for refactoring code that already has test coverage (use cc-refactoring-guidance).Votes: 0GitHub stars: 369