yschiang
@yschiang
Public Skills
spec-to-plan
by yschiang
Use when a feature's handoff package is ready and its design and implementation plan must be written before work starts, or when a plan was sent back at the start-of-work approval. Used by the Engineer or the coordinator of the feature loop. Not for writing the spec (feature-to-spec) or for implementing tasks (plan-to-code).
feature-to-spec
by yschiang
Use when a feature chosen on the roadmap needs its OpenSpec change, spec and ticket before engineering starts, or when the spec of an existing feature must change, whether still in preparation, blocked on scope inside the feature loop, or sent back because the requirement changed. Used by the Project Lead or the Engineer. Not for project-level planning or close-out (project-lead), and not for design and plan (spec-to-plan), implementation (plan-to-code) or pull requests and gates (to-pr).
project-lead
by yschiang
Use when starting or importing a Loop Engineering project, when its roadmap must be planned, re-cut or re-confirmed, when new evidence breaks an accepted requirement, when a feature's PR Pass needs the acceptor's decision recorded, or when a feature was accepted and needs close-out. Not for preparing a single feature's spec (feature-to-spec), and not for design and plan (spec-to-plan), implementation (plan-to-code) or pull requests and gates (to-pr).
review-panel
by yschiang
Use when a change needs an independent review that should not rest on one reviewer's blind spots, such as the whole-change review (G2) of a feature's pull requests or the per-task review of a high-risk task. Recommended, not required; the Engineer may choose a single reviewer. Not for fixing findings (plan-to-code) or running the gates (to-pr).
plan-to-code
by yschiang
Use when a feature's plan (design.md and tasks.md) has its start-of-work approval and its tasks must be implemented, or when review findings, a failed gate or an acceptor's rejection send fixes back to a feature's tasks. Used by the Engineer or the coordinator of the feature loop. Not for writing the plan (spec-to-plan) or opening pull requests (to-pr).
to-pr
by yschiang
Use when every task of a feature has passed its per-task review and the feature needs its pull requests, an independent whole-change review and CI before the acceptor sees it, or when open pull requests must be verified again after new commits. Not for implementing tasks (plan-to-code) or for recording acceptance (project-lead).
dispatching-parallel-agents
by yschiang
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
using-superpowers
by yschiang
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions
writing-plans
by yschiang
Use when you have a spec or requirements for a multi-step task, before touching code
brainstorming
by yschiang
"You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
systematic-debugging
by yschiang
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
retro
by yschiang
"Conduct a retrospective on a coding session."
subagent-driven-development
by yschiang
Use when executing implementation plans with independent tasks in the current session
pr
by yschiang
"Use when writing a PR body."
requesting-code-review
by yschiang
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
executing-plans
by yschiang
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
receiving-code-review
by yschiang
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
diagnosing-superpowers
by yschiang
Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
research-codebase
by yschiang
Research how an existing codebase works, trace component interactions, and write an evidence-backed Markdown report before requirements or design work. Adapted from HumanLayer's research_codebase command; focused on current behavior, not a code review or implementation plan.
openspec-sync-specs
by yschiang
Sync delta specs from an OpenSpec change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change. Also use when the user says "openspec sync" or "opsx sync".
openspec-explore
by yschiang
Enter OpenSpec explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements in a project that uses OpenSpec. Use when the user wants to think through something before or during an OpenSpec change. Also use when the user says "openspec explore" or "opsx explore".
openspec-update-change
by yschiang
Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Also use when the user says "openspec update change" or "opsx update". If the user means the openspec update CLI command, which refreshes generated files, run that command instead. Never edits code.
openspec-propose
by yschiang
Propose a new OpenSpec change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation. Also use when the user says "openspec propose" or "opsx propose".
openspec-update-change
by yschiang
Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Also use when the user says "openspec update change" or "opsx update". If the user means the openspec update CLI command, which refreshes generated files, run that command instead. Never edits code.