Claude Skills by rubenzarroca

Fetch, read, and cache external API documentation before planning or implementing integrations. Use when the user says 'fetch api docs', 'cache api', 'api-docs', 'document external api', or when /sdd:plan detects external services without cached docs. Prevents Claude from assuming API behavior based on training data.

Refine a feature specification by identifying gaps, ambiguities, and edge cases. Use when the user says 'clarify spec', 'find ambiguity', 'what's missing', 'review spec for gaps', or wants to tighten a spec before planning. Runs after /sdd:specify.

Define or edit the project's non-negotiable principles (architecture, testing, security, dependencies, code standards). Use when the user says 'set up rules', 'define principles', 'edit constitution', 'update project standards', 'what are our rules', or wants to establish or modify the project's technical guardrails.

Execute one or more tasks from the SDD task list. Use when the user says 'implement task', 'execute task', 'build task', 'do TASK-001', 'next task', 'start implementing', or wants to work on specific tasks. Reads only task blocks and their listed files. Auto-batches small tasks when possible.

Initialize SDD (Specification-Driven Development) workflow in a project. Use when setting up SDD for the first time, when the user says 'start SDD', 'init project', 'initialize specs', or asks to add specification-driven development to an existing codebase. Generates CLAUDE.md, constitution.md, state.json, and project structure.

Design the technical approach for a specified feature. Use when the user says 'plan the feature', 'design the architecture', 'how should we build this', 'create a technical plan', or wants to move from spec to implementation design. Generates plan.md and an ADR. Runs after /sdd:clarify.

Generate a Product Requirements Document (PRD) as the foundation for Specification-Driven Development. Use when starting a new product, defining a new product vision, or when the user says "create PRD", "generate PRD", "product requirements", "define the product", "documento madre", or references needing a high-level product definition before writing feature specs. This is the first step in the SDD workflow — the PRD feeds context to all downstream /sdd:specify commands. Always use this skill...

Post-feature retrospective that summarizes what the user learned during a feature's lifecycle. Use when the user says 'retro', 'retrospective', 'what did I learn', 'debrief', or wants to reflect on a completed feature. Completely optional — never suggested automatically, never blocks any workflow step.

Generate a comprehensive feature specification following the SDD 11-section methodology, with integrated technical coaching that teaches spec-writing best practices in context. Use when the user says "specify", "create spec", "write spec", "define feature", "especificar", or runs /sdd:specify. This skill produces specs that are detailed enough for an LLM to implement directly: context, goals, user stories, functional and non-functional requirements, technical design, data models, API contract...

Show current SDD state and progress at a glance. Use when the user says 'status', 'where are we', 'where we left off', 'session recovery', 'what's the progress', or wants a quick overview of feature and task progress. Ultra-lightweight — reads only state.json.

Decompose a technical plan into an atomic, ordered task list. Use when the user says 'break it down', 'create task list', 'decompose the plan', 'what are the implementation steps', or wants to go from plan to actionable work items. Runs after /sdd:plan.

Verify implementation against the spec and detect drift. Use when the user says 'validate', 'check spec vs code', 'verify implementation', 'are we done', 'any drift', or all tasks are completed and the feature needs final review. Checks coverage, orphan code, constitution compliance, and cross-layer consistency.