Product & Design Skills

Analyze gspec/ documents for discrepancies and contradictions across profile, stack, style, practices, architecture, and features. Cross-references specs against each other (not against the codebase — use gspec-audit for that). Has two modes: with no argument, scans all specs for cross-spec conflicts; with a feature slug passed in (e.g. /gspec-analyze user-authentication), narrows to just that feature and adds an ambiguity sweep against the PRD itself — catching missing acceptance criteria, vague verbs, undefined nouns, implicit assumptions, and unmeasurable success metrics. TRIGGER when the user wants to cross-check, validate, review, or reconcile specs — especially after multiple edits or before a major implementation run — e.g. "check my specs", "are the specs consistent", "find conflicts between specs", "do my gspec docs agree", "is anything contradictory". ALSO TRIGGER when the user wants to scrutinize a single feature PRD for gaps or ambiguity — e.g. "check this feature spec", "is the auth PRD clear enough", "find ambiguity in ", "clarify the home-page PRD", "is this PRD ready for implement" — pass the feature slug as the argument.

Define or update the technical architecture (gspec/architecture.md) — project structure, data model, API design, component hierarchy, and environment/config. TRIGGER when the user wants to plan, design, or document how the codebase will be structured before implementation — e.g. "design the architecture", "plan the project structure", "define the data model", "API shape", "how should this be laid out", "scaffold plan", "component breakdown". Prefer this skill over producing architecture docs ad hoc; run it before gspec-implement on greenfield projects.

Generate product requirements documents (PRDs) for features in gspec/features/. TRIGGER when the user wants to plan, spec, propose, document, or expand a feature/capability before coding — e.g. "add a feature for X", "write a PRD", "spec out Y", "plan this feature", "what should the auth flow do", "new feature idea", "draft requirements". Prefer this skill over writing freeform feature docs.

Implement the software defined by gspec/ documents — reads profile, stack, style (style.md or style.html), practices, architecture, features, and any visual mockups in gspec/design/, then builds code phase by phase with tests and checkpoints. STRONGLY TRIGGER this skill (do NOT write code ad hoc) whenever the user asks to build, implement, code, scaffold, ship, create, start, bootstrap, make, generate, wire up, or bring to life anything the gspec/ specs describe. Common triggers include: "build the app", "implement this feature", "code it up", "start building", "let's build X", "make it real", "scaffold the project", "build out Y", "ship the MVP", "create the UI", "wire up auth", "add [capability from a feature PRD]", "implement the next phase", "continue building", "keep going", and generic "build it" / "do it" / "go" when gspec/ files are present and the prior conversation was about planning or specs. Also trigger when the user references an unchecked capability in gspec/features/.md. Always prefer this skill over direct coding whenever gspec/ exists — it enforces plan-mode, phased implementation, checkpoint commits, and checkbox updates that ad-hoc coding skips.