All authors
Claude Skills by gitRasheed
github.com/gitRasheed16 skills0 installs0 views
- MetisUse before building a feature, refactoring, designing APIs or module boundaries, doing performance work, or reviewing a pull request or diff, in any repo. Covers plain data, call-site-first API design, simple control flow, boundary parsing, behavior-first tests, and lens-based code review. Skip it only for small bug fixes, one-line edits, and questions that change no code.Votes: 0GitHub stars: 2
- P10 HybridWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules - Writing tests...Votes: 0GitHub stars: 2
- P11 GatedWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Before anything else, name the phase you are in, then read ONLY the sections listed for that phase plus the Design principles. Actively skip the other sections — holding out-of-phase rules in mind dilutes the in-phase ones. - Designing or starting a...Votes: 0GitHub stars: 2
- P12 ModularWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. FIRST, name the phase you are in. THEN read the matching phase file below IN FULL before starting, and hold only it plus the Design principles in mind. Do not read the other phase's file — out-of-phase rules dilute in-phase attention. - Implementing...Votes: 0GitHub stars: 2
- P13 FinalWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, the Testing checklist when the change needs tests, plus the SOLI...Votes: 0GitHub stars: 2
- P14a ReviewpatchWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules - Writing tests...Votes: 0GitHub stars: 2
- P14b ValidassertWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules - Writing tests...Votes: 0GitHub stars: 2
- P14c CombinedWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules - Writing tests...Votes: 0GitHub stars: 2
- P15 LensscopedWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules - Writing tests...Votes: 0GitHub stars: 2
- P8 AgenticWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. Strong defaults, not laws: follow the codebase, framework, and language when they clearly matter more.Votes: 0GitHub stars: 2
- P9 StructuralWrite code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more. Apply sections by phase instead of holding everything at once: - Designing or starting a task: Design principles, LLM agent process - Implementing: Working rules, plus the SOLID checklist for non-trivial modules - Writing tests: Testing checklist - ...Votes: 0GitHub stars: 2
- CLITEUse when an LLM is doing non-trivial coding work, including implementing features, fixing bugs, refactoring, designing APIs or module boundaries, writing tests, reviewing code, or preparing to commit. Guides the model toward plain data, top-down API design, simple control flow, SOLID without ceremony, boundary assertions, behavior-first testing, final verification, anti-slop cleanup, and a tiered lens-based code review. Not needed for trivial one-line edits, pure prose, or rote mechanical cha...Votes: 0GitHub stars: 2
- CONCUse when an LLM is doing non-trivial coding work, including implementing features, fixing bugs, refactoring, designing APIs or module boundaries, writing tests, reviewing code, or preparing to commit. Guides the model toward plain data, top-down API design, simple control flow, SOLID without ceremony, boundary assertions, behavior-first testing, final verification, anti-slop cleanup, and a tiered lens-based code review. Not needed for trivial one-line edits, pure prose, or rote mechanical cha...Votes: 0GitHub stars: 2
- RICHUse when an LLM is doing non-trivial coding work, including implementing features, fixing bugs, refactoring, designing APIs or module boundaries, writing tests, reviewing code, or preparing to commit. Guides the model toward plain data, top-down API design, simple control flow, SOLID without ceremony, boundary assertions, behavior-first testing, final verification, anti-slop cleanup, and a tiered lens-based code review. Not needed for trivial one-line edits, pure prose, or rote mechanical cha...Votes: 0GitHub stars: 2
- SYNTHUse when an LLM is doing non-trivial coding work, including implementing features, fixing bugs, refactoring, designing APIs or module boundaries, writing tests, reviewing code, or preparing to commit. Guides the model toward plain data, top-down API design, simple control flow, SOLID without ceremony, boundary assertions, behavior-first testing, final verification, anti-slop cleanup, and a tiered lens-based code review. Not needed for trivial one-line edits, pure prose, or rote mechanical cha...Votes: 0GitHub stars: 2
- MetisUse before building a feature, refactoring, designing APIs or module boundaries, doing performance work, or reviewing a pull request or diff, in any repo. Covers plain data, call-site-first API design, simple control flow, boundary parsing, behavior-first tests, and lens-based code review. Skip it only for small bug fixes, one-line edits, and questions that change no code.Votes: 0GitHub stars: 2