All authors

Claude Skills by yizhao95
github.com/yizhao9510 skills0 installs0 views
- BrainstormingYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.Votes: 0GitHub stars: 26
- Executing PlansUse IMMEDIATELY after writing-plans, OR whenever a plan exists in ~/skill-workspace/orchestrator.db. Owns ALL post-publish writes to the orchestrator database via the deterministic-flow scripts in scripts/ (run-step is the preferred path for shell work). Never bypass these scripts; never write to the DB ad-hoc. Triggers on every plan execution: code, SQL, schema, build, test, fix, implement, deploy, refactor, run, execute, continue, resume. When a test fails: never patch the test silently — f...Votes: 0GitHub stars: 26
- LedgerAsk the ledger why / whether we tried — read-only. Use when the user types `/ledger <question>` or asks why something in this project is the way it is, why a value was chosen, who decided it, whether an alternative was ever tried, or whether a change was ever verified. Answers ONLY from recorded rows: every sentence cites the record id it rests on, absences are computed by code, and the searched range is stated. Changes nothing the project depends on.Votes: 0GitHub stars: 26
- Project State GraphUse when setting up a new project, creating a new app, kicking off a new initiative, onboarding an existing repo, or whenever you need a repo graph / code graph / project state graph / map of a codebase before working in it. Keywords - set up project, new project, new app, new initiative, project state graph, repo graph, code graph, codebase map, architecture overview.Votes: 0GitHub stars: 26
- ReceiptsHelp the user reply to a colleague who questioned a decision — read-only. Use when the user types `/receipts <what they said>`, or asks how to answer someone who challenged a number, a change or a choice in this project (\"why did you change this\", \"didn't we agree the other way\", \"where did this number come from\"). Writes a reply grounded ONLY in recorded rows, lists the evidence under it with a record id per line, and names what the user should confirm or add before sending. Never send...Votes: 0GitHub stars: 26
- Subagent Driven DevelopmentUse ANY time work should be delegated to sub-agents (Agent tool) instead of done in the main session: (a) executing a plan task-by-task, a fresh sub-agent per task with two-stage review; (b) parallel dispatch for 2+ independent problem domains; (c) routing a task to the RIGHT agent type (Explore, Plan, a project or plugin agent) instead of a generic one; (d) one-shot huge reads (giant logs, full API references, monorepo scans) handed to one sub-agent that returns only a summary. CRITICAL TRIG...Votes: 0GitHub stars: 26
- Systematic DebuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesVotes: 0GitHub stars: 26
- Test Driven DevelopmentMUST BE ACTIVATED BEFORE EVERY CODING TASK — NO EXCEPTIONS. Applies to all production code, schema and config work: features, bugfixes, refactors, functions, classes, SQL schemas, migrations, YAML/JSON configs, API endpoints, CLI tools, scripts, handlers, parsers, validators, lint rules — anything that runs or gets validated. Iron law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. RED → GREEN → REFACTOR; code written before its test gets deleted. No qualifier exempts you: 'simple', 'trivia...Votes: 0GitHub stars: 26
- Update Project State GraphUse when a plan that touched a registered project reaches the NEEDS_REVIEW state, when reviewing plan completion for a project-state change, or when checking whether a git diff broke consistency with a project's deep state graph. Keywords - NEEDS_REVIEW, project state review, maintain project state, stale reference check, renamed function still called, code graph consistency, agent review close, review plan completion.Votes: 0GitHub stars: 26
- Writing PlansALWAYS loaded FIRST when starting any new task — non-negotiable, before any tool use, regardless of whether the task seems trivial. Triggers on EVERY user turn: questions, requests, code, debugging, design, build, create, make, write, fix, add, change, set up, plan, implement, refactor, install, deploy, schema, SQL, database, YAML, JSON, config, API, function, class, test, document, hello, help me. Workflow: (1) If other skills apply (domain, language, framework, integration), load them FIRST...Votes: 0GitHub stars: 26