Claude Skills by getappz

Use when an algorithm is non-trivial enough that getting the logic right matters more than the syntax — concurrency-sensitive code, a non-obvious data-structure choice, or anything where a subtle off-by-one or complexity mistake is expensive to find after implementation. Write the algorithm in language-agnostic pseudocode with an explicit complexity analysis before writing real code. Skip for straightforward CRUD or glue code where the implementation is a direct restatement of the requirement...

Use before any creative or ambiguous request — a new feature, a "can we..." feasibility question, a vague bug report with no clear fix yet — to classify how much process it needs and block implementation until that process is done and approved. Skip once the ask is already concrete and scoped; requirements-specification picks up from there. Skip for a one-line, obviously-correct fix where there is nothing to classify.

Use when writing or maintaining an OpenAPI/Swagger 3.0 specification for a REST API — new endpoints, request/response schemas, auth schemes, or error responses that need to be documented accurately and stay in sync with the implementation. Skip for internal-only functions/modules with no HTTP surface, and skip for GraphQL APIs — this is REST/OpenAPI specific.

Product management for any project — read-only reporting (/pm:standup, /pm:groom, /pm:plan, /pm:health, /pm:portfolio) plus PM mode, an explicitly-activated execution arm that creates and dispatches work via handoff instead of implementing it directly. Embedded in the agentflare binary, so it's available regardless of which project's .claude/skills is on disk.

Use when a feature request or bug report is vague enough that "what does done look like" isn't obvious yet — turns a fuzzy ask into testable functional/non-functional requirements, constraints, and Gherkin-style acceptance criteria before any design or code starts. Skip for small, already-unambiguous changes, and skip once a spec exists — use superpowers:writing-plans to turn an existing spec into an implementation plan instead of re-deriving requirements.

Use when a change is big enough to need a deliberate structural decision first — new service boundaries, a data model that will be expensive to change later, a technology choice, or anything crossing multiple components — and you want the trade-offs and rationale written down, not just the diagram. Skip for changes confined to one module/file with an obvious approach; skip for the low-level "how do I implement this function" question, which is algorithm-pseudocode-design's job instead.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes — walks through root-cause investigation, pattern comparison, and a single tested hypothesis before any code changes. Skip when there's no failure to explain yet (greenfield feature work) — use algorithm-pseudocode-design or system-architecture-design instead.

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Al...