@dsalazardev/ai-hub-cli 0.2.0 → 0.3.1

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

@@ -1,36 +0,0 @@
----
-name: speckit-converge
-description: Verify that the implemented codebase satisfies every requirement before archiving the change. Use after speckit-implement reports DONE.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/, specs/ and the project test commands.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Close the loop between what was specified and what exists.
-
-**Input**: `spec.md`, `plan.md`, `tasks.md`, `analysis.md` and the implemented code.
-
-**Steps**
-
-1. Read every requirement and locate its implementation and test.
-2. Run the full verification commands from the plan and record the result.
-3. Write `convergence.md`:
-   - `## Requisito → evidencia` — table with requirement, code path, test.
-   - `## Tareas` — every task checked; list any unchecked.
-   - `## Deriva` — behavior implemented but not specified.
-   - `## Veredicto` — `CONVERGED` or `NEEDS_WORK` with the exact gap.
-4. If `NEEDS_WORK`, return to `implement` or `specify`; do not patch here.
-5. On `CONVERGED`, hand off to the human approval gate and then archive.
-
-**Artifacts**: `specs/<feature>/convergence.md`
-
-**Exit states**
-- `CONVERGED` — every requirement proven and every task complete.
-- `NEEDS_WORK` — a requirement lacks evidence or unspecced behavior exists.
-
-**Guardrails**
-- Never mark `CONVERGED` from a summary; cite code and test output.
-- Never delete or archive the feature while a task is open.
-- Do not rewrite the spec to match the implementation.

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

@@ -1,32 +0,0 @@
----
-name: speckit-implement
-description: Execute the approved task list in an isolated worktree and produce verified code. Use only after analysis passes and a human approved the spec hash.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/, specs/ and a Git repository.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Implement the tasks exactly as approved, with evidence.
-
-**Input**: `specs/<feature>/tasks.md`, `plan.md` and the approved SHA-256 of `spec.md + plan.md + tasks.md`.
-
-**Steps**
-
-1. Verify the approval hash still matches the three artifacts. If not, stop: the approval is invalid.
-2. Work in the assigned worktree or feature branch. Never implement on the trunk.
-3. For each task in order: make the smallest change, run its verification, and only then mark it `[x]`.
-4. Keep a trace in `.planning/impl_<feature>.md`: task, files, command, result.
-5. If a task needs scope beyond the spec, stop and return to `specify` or `plan`.
-
-**Artifacts**: source code, tests, `.planning/impl_<feature>.md` and updated `tasks.md`.
-
-**Exit states**
-- `DONE` — every task verified and the full suite is green.
-- `BLOCKED` — a task needs a design or scope decision; record why and stop.
-
-**Guardrails**
-- Never weaken a test to pass.
-- Never edit `spec.md`, `plan.md` or `tasks.md` to match what was built.
-- No `TODO`, placeholder or commented-out code.

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.