All authors
Claude Skills by 001-Himal
github.com/001-Himal15 skills0 installs0 views
- CleanupAfter major work check: - unused files / functions / components - unused dependencies / imports - obsolete comments - stale docs - abandoned experiments - duplicate implementations Remove safely, one at a time, with verification after each removal.Votes: 0GitHub stars: 2
- Code ReviewReview the diff, do NOT modify code: 1. Matches approved plan? 2. Unrelated files touched? 3. Duplication? Error handling? Edge cases? 4. Style consistent? 5. Silent API/schema changes? Report by severity, then recommended fixes.Votes: 0GitHub stars: 2
- Dead CodeFind unused exports/components/functions and remove them. Verify tests/build after removal.Votes: 0GitHub stars: 2
- Debugging1. Reproduce first, get the exact error. 2. State the hypothesis before fixing. 3. Verify with evidence. 4. Fix the root cause, not the symptom. 5. Add a regression test where possible.Votes: 0GitHub stars: 2
- Dependency CleanupAudit package.json/lockfile: remove unused deps, check for duplicates, run security audit, update deliberately.Votes: 0GitHub stars: 2
- Documentation1. Behavior changed → update docs/. 2. Architecture changed → update context/architecture.md + ADR. 3. Structure changed → update context/structure.md. 4. Keep docs accurate; delete stale docs.Votes: 0GitHub stars: 2
- Implementation1. Follow the approved plan only. 2. Keep scope; reuse existing patterns. 3. If the plan no longer fits, stop and report — don't improvise. 4. Summarize changes when done.Votes: 0GitHub stars: 2
- Migration1. Inspect current schema. 2. Plan: exact changes, rollback, data impact. 3. Get approval. 4. Implement migration + code updates. 5. Test and verify.Votes: 0GitHub stars: 2
- Performance1. Measure first (profiling, not guessing). 2. Fix the biggest bottleneck first. 3. Re-measure after the change. 4. Watch N+1, bundle size, re-renders.Votes: 0GitHub stars: 2
- Planning1. Read spec + context docs. 2. Inspect existing code. 3. Produce plan: assumptions, files to change/NOT change, steps, risks, open questions. 4. Stop. Wait for human approval.Votes: 0GitHub stars: 2
- Refactoring1. State the goal (readability/perf/dedup). 2. Behavior must remain unchanged — run tests before and after. 3. Smallest change that achieves the goal.Votes: 0GitHub stars: 2
- Release1. Verify tests/typecheck/lint green. 2. Security review done if relevant. 3. Update changelog + release notes. 4. Run production checklist. 5. Deploy and smoke-test the live app.Votes: 0GitHub stars: 2
- Security ReviewCheck for: auth flaws, authz failures/IDOR, injection, CSRF, insecure endpoints, exposed secrets, unsafe env usage, weak validation, data leakage, dependency risks. Do NOT modify code. Report: findings, severity, affected files, exploit scenario, recommended fix.Votes: 0GitHub stars: 2
- Testing1. Run typecheck, lint, tests; report real output. 2. Ensure happy/error/edge tests for new behavior. 3. If a test cannot run, say why.Votes: 0GitHub stars: 2
- Ui Polish1. Check screen vs design-system. 2. Fix spacing/alignment/type/color. 3. Verify loading/empty/error states. 4. Verify mobile. 5. Never invent new styles — extend the design system. 6. Audit all UI text: strip any leaked tech stack, database names, auth providers, or protocol badges (e.g. "Powered by...", "WebSocket", "Supabase", "PostgreSQL"). Ensure language is 100% user- and domain-centric.Votes: 0GitHub stars: 2