All authors
Claude Skills by Linchi1997yeh
github.com/Linchi1997yeh10 skills0 installs16 views
- Adversarial ReviewNon-sycophantic code critique that finds concrete bugs, edge cases, silent failures and security issues with failing inputs, saved to .specs/reviews/. Use when the user asks for a code review, 'what could break', a security check, or before merging; typically runs after /draft-scaffold.Votes: 0GitHub stars: 2
- Arch TradeoffsCompares three distinct conceptual architectures (minimal, modular, decoupled) with a trade-off matrix and a recommendation, written to .specs/02-conceptual-architecture.md. Use when the user asks 'how should we structure this', wants architecture options or design trade-offs, after /problem-spec and before /runtime-topology.Votes: 0GitHub stars: 2
- Behavior TestsWrites black-box behavioral tests from the spec and from adversarial-review findings (happy, boundary, adversarial and failure paths) with no tautological assertions. Use when the user asks for tests, regression tests for review findings or edge-case coverage, after /adversarial-review.Votes: 0GitHub stars: 2
- Dev DocsWrites PR summaries, ADRs or maintainer runbooks grounded in what was actually built and verified. Use when the user asks for a PR description, ADR, decision record, runbook or docs for a finished feature or milestone, at the end of the pipeline.Votes: 0GitHub stars: 2
- Draft ScaffoldImplements one backlog task as a minimal, un-abstracted first draft limited to that task's files, then runs its verification command. Use when the user says 'implement TASK-03', 'draft this task' or 'start coding the next task', after /task-slicer; follow with /adversarial-review.Votes: 0GitHub stars: 2
- Env FoundryPicks and pins the tech stack and builds a reproducible local dev environment (docker-compose, version files, .env.example, smoke test), documented in .specs/04-environment-setup.md. Use when the user asks to set up the dev environment, choose a stack or pin versions, after /runtime-topology and before /task-slicer.Votes: 0GitHub stars: 2
- Problem SpecFrames the problem before any design or code: core problem, personas, hard constraints, explicit non-goals and success metrics, written to .specs/01-problem-spec.md. Use when the user starts a new project, feature or component, says 'scope this', 'write requirements' or 'what are we building', or has a vague idea. First pipeline step; run before /arch-tradeoffs.Votes: 0GitHub stars: 2
- Runtime TopologyDesigns runtime mechanics: compute boundaries, sync vs async split, storage and caching, queues, retries and failure handling, written to .specs/03-runtime-topology.md. Use when the user asks about system topology, background jobs, data stores or failure modes, after /arch-tradeoffs and before /env-foundry.Votes: 0GitHub stars: 2
- Safe RefactorSimplifies working code without changing behavior, public APIs or dependencies, verified by the existing tests. Use when the user asks to clean up, simplify, flatten nesting or untangle code that already works; not for bug fixes or new features. Typically runs after /adversarial-review.Votes: 0GitHub stars: 2
- Task SlicerBreaks a designed system into atomic, verifiable tasks (at most 2 files and about 50 lines each) ordered schema-first, written to .specs/05-task-backlog.md. Use when the user says 'break this down', 'small tasks', 'backlog', 'task list' or 'implementation plan', after /env-foundry and before /draft-scaffold. If earlier specs are missing, say which skill to run first.Votes: 0GitHub stars: 2