Run any Skill in Manus with one click

rule-curator

Stars1

Forks1

UpdatedJune 14, 2026 at 19:11

Ingest new material (articles, docs, snippets, reference links, code review feedback) and fold it into the rules in `claude/rules/`. MUST be invoked when the user shares a new convention, style guide, blog post, library doc, or reference and wants it captured, when deciding whether guidance belongs in an existing rule or needs a new one, or when auditing or refreshing rules with fresh material.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

JoshKarpel

JoshKarpel/dotfiles

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	rule-curator
description	Ingest new material (articles, docs, snippets, reference links, code review feedback) and fold it into the rules in `claude/rules/`. MUST be invoked when the user shares a new convention, style guide, blog post, library doc, or reference and wants it captured, when deciding whether guidance belongs in an existing rule or needs a new one, or when auditing or refreshing rules with fresh material.

Rule Curator

Takes in new material, researches it, and decides whether it belongs in an existing rule in claude/rules/ or needs a new one.

Workflow

1. Read the material

Fetch URLs, read pasted text, or read referenced files in full. Pull out the concrete, actionable conventions, not just "this seems useful." Vague inspiration isn't rule content; a specific, reasoned rule is.

2. Verify before recording

Don't transcribe claims you haven't checked. If the material asserts that a tool behaves a certain way or a pattern works, try it or cross-check current docs. Blog posts and forum answers drift out of date faster than official references do.

3. Survey the existing rules

ls claude/rules/

Read each candidate's paths frontmatter and skim its body to judge fit. Match on both axes:

Format or language: is this Dockerfile, shell, Python, markdown, etc.?
Topic: does it extend something a rule already covers, or is it a genuinely new area for that format?

4a. If it fits an existing rule, edit it in place

Find the right spot: an existing ## heading to extend, or a new heading that matches the rule's existing structure and voice.
Match the target rule's example density and tone; don't import the source material's style wholesale.
Run the proposed edit past the user before writing it. They may want it trimmed, placed elsewhere, or skipped.

4b. If it doesn't fit any existing rule, propose a new one

Name it <topic>.md and place it in claude/rules/.
Add YAML frontmatter with paths: globs that match the relevant file types so the rule loads automatically when Claude works with those files.
Per CLAUDE.md, new rules live in claude/rules/ in this repo, never directly under ~/.claude/, so they travel with the dotfiles and get symlinked into place by bin/link-claude.
Propose the name, scope, paths globs, and outline to the user before writing files.

5. Prune as you go

Keep only what's non-obvious, durable, and actionable. A rule that restates what any competent engineer already knows is a tax on every future session that loads it, not an asset.

Rules are read by Claude, which already knows what the language, tool, or concept is. Don't open a rule with a definition or general background (no "A secret is any value that grants access", no explaining what configuration is). Capture only the user's preferences and suggested approaches, and start at the first real convention rather than a scene-setting intro. A short scoping or cross-reference line is fine when it marks a genuine boundary (what the rule deliberately excludes, or where a related concern lives), not background.

More from this repository

same repository

hook-creator

JoshKarpel/dotfiles

Guide for designing and writing Claude Code hooks. MUST be invoked when creating a new hook, adding hooks to settings.json, debugging hook behavior, understanding what hook events are available and what JSON they receive, or implementing patterns like behavior correction, pre-stop checklists, context injection, side effects, and permission control.

2026-07-191

optimize-postgres

JoshKarpel/dotfiles

PostgreSQL performance: find slow queries, read plans, and tune indexes, writes, and server config. MUST be invoked when a Postgres query is slow, a query needs an index, EXPLAIN shows a Seq Scan on a large table, inserts or bulk loads are slow, autovacuum/bloat is suspected, or you're choosing index types or server settings. Covers pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS), index types (btree/partial/expression/covering, GIN, GiST, BRIN), ANALYZE and autovacuum, COPY and bulk-load tuning, and the shared_buffers / work_mem / effective_cache_size baseline.

2026-07-181

optimize-pytest

JoshKarpel/dotfiles

Make a pytest suite faster and more trustworthy. MUST be invoked when a pytest run is slow, CI test time needs cutting, a suite should be parallelized, or tests are flaky/order-dependent. Covers measuring with --durations and pytest-durations, diagnosing fixture-scope waste (make read-only, then widen), replacing time.sleep with deterministic synchronization, parallelizing with pytest-xdist (-n, --dist worksteal/loadscope/loadgroup), hardening isolation with pytest-randomly so flakiness surfaces before CI, and cutting startup cost (collection, imports, coverage backend, testpaths, running fewer tests).

2026-07-181

optimize-python

JoshKarpel/dotfiles

Python performance profiling and optimization. MUST be invoked when investigating CPU hotspots, memory usage, I/O slowness, async event loop blocking, or when optimizing slow Python code. Covers tools (cProfile, line_profiler, austin/speedscope, scalene), flamegraph generation, common optimization patterns (concurrent awaits, regex combining, recursive memoization, eliminating duplicate work, moving blocking I/O off the event loop), and profiling Python processes in Kubernetes pods.

2026-07-181

optimize-sqlite

JoshKarpel/dotfiles

SQLite performance: query optimization plus write and connection tuning. MUST be invoked when a SQLite query is slow, a query needs an index, EXPLAIN QUERY PLAN shows a full-table SCAN, inserts/writes are slow, or you're choosing an index or connection PRAGMAs. Covers reading EXPLAIN QUERY PLAN, the experimental `.expert` index recommender, index types (covering, expression, partial), ANALYZE / sqlite_stat1, transaction and bulk-insert speed, and the WAL + synchronous=NORMAL connection PRAGMA baseline.

2026-07-181

skill-creator

JoshKarpel/dotfiles

Create, improve, and troubleshoot Claude Code agent skills. MUST be invoked when asked to make a new skill, write a SKILL.md file, improve skill discoverability, debug why a skill isn't activating, answer questions about skills, or review skill best practices.

2026-07-181

name	rule-curator
description	Ingest new material (articles, docs, snippets, reference links, code review feedback) and fold it into the rules in `claude/rules/`. MUST be invoked when the user shares a new convention, style guide, blog post, library doc, or reference and wants it captured, when deciding whether guidance belongs in an existing rule or needs a new one, or when auditing or refreshing rules with fresh material.

Rule Curator

Takes in new material, researches it, and decides whether it belongs in an existing rule in claude/rules/ or needs a new one.

Workflow

1. Read the material

2. Verify before recording

3. Survey the existing rules

ls claude/rules/

Read each candidate's paths frontmatter and skim its body to judge fit. Match on both axes:

Format or language: is this Dockerfile, shell, Python, markdown, etc.?
Topic: does it extend something a rule already covers, or is it a genuinely new area for that format?

4a. If it fits an existing rule, edit it in place

Find the right spot: an existing ## heading to extend, or a new heading that matches the rule's existing structure and voice.
Match the target rule's example density and tone; don't import the source material's style wholesale.
Run the proposed edit past the user before writing it. They may want it trimmed, placed elsewhere, or skipped.

4b. If it doesn't fit any existing rule, propose a new one

Name it <topic>.md and place it in claude/rules/.
Add YAML frontmatter with paths: globs that match the relevant file types so the rule loads automatically when Claude works with those files.
Per CLAUDE.md, new rules live in claude/rules/ in this repo, never directly under ~/.claude/, so they travel with the dotfiles and get symlinked into place by bin/link-claude.
Propose the name, scope, paths globs, and outline to the user before writing files.

5. Prune as you go

Keep only what's non-obvious, durable, and actionable. A rule that restates what any competent engineer already knows is a tax on every future session that loads it, not an asset.