alessioscarfone/barespec

Autonomous knowledge base for the mini-SDD framework. Always read this skill when working on a mini-SDD project or when any message mentions mini-SDD, init-context, spec-create, spec-plan, spec-implement, spec-code-review, spec-visualize, init-config, context.md, spec.yaml, plan.md, visual.html, hooks config, or spec-driven development. Do not use for creating context files, writing specs, planning, implementing features, or reviewing code — those have their own skills.

Scaffold or update the barespec configuration file (barespec.config.yml) that defines pre and post hooks for the context, spec, plan, implement, review, and visualize steps. Use when setting up hook customization, configuring hooks, adding new hooks, reviewing or editing hook settings, or when asked to "setup barespec", "configure hooks", "edit the config yml", or "add a pre-hook". Do not use for implementing features, writing specs, or creating project context.

Create or update the project context document that captures product vision, architecture, and tech stack in a single file. Use when bootstrapping a new project with mini-SDD, onboarding AI agents to an existing codebase, or updating project context after completing a feature. Do not use for writing feature specs or implementing code.

Reviews the changes since a fixed point (commit, branch, tag, or merge-base) along two independent axes: Coding Standards (does the code follow the conventions in barespec/context.md, the repo standards docs, and a code-smell baseline?) and Spec (does the code implement what the barespec spec.yaml requirements and plan.md tasks asked for?). Runs both axes as parallel sub-agents and reports them side by side without merging findings. Use when reviewing a branch, a PR, work-in-progress changes, an implemented spec, or when asked to review since a given ref. Do not use for creating specs, generating plans, implementing tasks, or applying fixes automatically.

Create or update a feature spec — define functional requirements and cross-cutting constraints for a single feature in a structured spec.yaml. Use when defining a new feature, capturing a requirement, writing a user story, drafting a spec, or refining an existing spec. Do not use for generating the implementation plan (use spec-plan) or implementing code.

Implement a feature from an existing spec file — write code, create tests, and update files to make a spec done. Use when executing development work defined in a spec, building or developing a feature, coding from a spec, or when asked to "implement the spec", "code this up", "develop the feature", or "follow the specification". Do not use for creating specs, updating project context, or proposing new features.

Generate or update the implementation plan for an existing spec — read spec.yaml and break it into an ordered, testable task checklist. Use when creating a plan from a spec, generating tasks, planning how to implement a feature, or refreshing a plan after the spec changed. Do not use for writing the spec itself (use spec-create) or implementing code (use spec-implement).

Generate a self-contained, interactive HTML view of a barespec spec and its plan — requirement tree, requirement-to-task traceability, plan progress, an inferred flow diagram, touched files, non-goals and notes — so a human can review a spec without reading raw YAML and Markdown. Use when asked to visualise, render, preview, or review a spec or plan visually, or to "open the spec in a browser". Do not use for writing or editing specs (use spec-create), generating plans (use spec-plan), implementing code, or reviewing diffs (use spec-code-review).