@dsalazardev/ai-hub-cli 0.2.0 → 0.3.0

package/skills/shared/speckit-plan/SKILL.md

@@ -1,37 +0,0 @@
----
-name: speckit-plan
-description: Produce the technical plan that implements an approved specification. Use after the spec is READY and before writing tasks.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Translate requirements into a design without changing them.
-
-**Input**: `specs/<feature>/spec.md` in state `READY` and the project constitution.
-
-**Steps**
-
-1. Read every requirement and scenario. Map each to a design element.
-2. Write `plan.md`:
-   - `## Contexto` — current behavior and constraints.
-   - `## Decisiones` — numbered, each with rationale and rejected alternatives.
-   - `## Componentes` — modules, responsibilities and data flow.
-   - `## Contratos` — APIs, schemas, events and error cases.
-   - `## Trazabilidad` — requirement id → component → test.
-   - `## Riesgos` — mitigation per risk.
-   - `## Migración` — rollout, rollback and compatibility.
-3. Verify every requirement has at least one component and one test.
-4. Keep the plan implementable in one change; split otherwise.
-
-**Artifacts**: `specs/<feature>/plan.md`
-
-**Exit states**
-- `READY` — every requirement is covered and no design decision is open.
-
-**Guardrails**
-- Never add a requirement that the spec does not contain.
-- Do not write task lists here; `tasks.md` owns sequencing.
-- Name the trade-off of every significant decision.

package/skills/shared/speckit-specify/SKILL.md

@@ -1,36 +0,0 @@
----
-name: speckit-specify
-description: Write the behavioral specification of a feature with EARS requirements and testable scenarios. Use after the constitution and before planning.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Describe what the system must do, not how it will do it.
-
-**Input**: the approved assessment or feature request and the project constitution.
-
-**Steps**
-
-1. Choose a kebab-case feature id and create `specs/<feature>/`.
-2. Write `spec.md`:
-   - `## Purpose` — one paragraph, user-visible outcome.
-   - `## Requisitos` — EARS statements using `MUST`, `MUST NOT`, `WHEN`, `IF`.
-   - `## Escenarios` — one block per requirement with exactly `#### Scenario:` and WHEN/THEN.
-   - `## Fuera de alcance` — what this feature deliberately excludes.
-   - `## Preguntas abiertas` — numbered; none may remain before approval.
-3. Give every requirement at least one scenario and a stable identifier (`R1`, `R2`, ...).
-4. Keep each requirement to one behavior; split compound requirements.
-
-**Artifacts**: `specs/<feature>/spec.md`
-
-**Exit states**
-- `DRAFT` — requirements exist but open questions remain.
-- `READY` — no open questions and every requirement has a scenario.
-
-**Guardrails**
-- No architecture, library choices or file paths in `spec.md`.
-- Never mark `READY` with an untestable requirement.
-- Do not modify the constitution from this skill.

package/skills/shared/speckit-tasks/SKILL.md

@@ -1,34 +0,0 @@
----
-name: speckit-tasks
-description: Break an approved plan into atomic, ordered, verifiable implementation tasks. Use after the checklist passes.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Produce the executable sequence the implementers will follow.
-
-**Input**: `spec.md`, `plan.md` and `checklist.md` in state `PASS`.
-
-**Steps**
-
-1. Create `tasks.md` grouped by phase (foundation, core, integration, release).
-2. Each task MUST be one checkbox with:
-   - a concrete action,
-   - the files or modules it touches,
-   - an explicit verification criterion.
-3. Order tasks by dependency; a task may only depend on earlier tasks.
-4. Map every requirement to at least one task; add a traceability table.
-5. Estimate nothing; split any task that cannot be verified in one run.
-
-**Artifacts**: `specs/<feature>/tasks.md`
-
-**Exit states**
-- `READY` — every task has a verification criterion and every requirement is covered.
-
-**Guardrails**
-- No `TODO`, "investigar" or unverifiable tasks.
-- Do not include implementation code in the task list.
-- Do not mark a task complete from this skill.