@dsalazardev/ai-hub-cli 0.1.0 → 0.3.0

package/skills/shared/sdd-init/SKILL.md

@@ -3,7 +3,8 @@ name: sdd-init
 description: "Use when calibrating an existing repo for the ai-hub Spec-Kit chain: detect stack, package manager, test runners and apply/verify commands, refresh the skill registry, and write the runtime config at 02-DOCS/wiki/sdd/config.yaml. NOT the dispatcher that routes SDD phases (that is `sdd`), NOT first-contact user/workspace bootstrap (that is `init`)."
 tags: [sdd, init, config, testing, registry]
 recommends: [sdd, specify, implement, verify]
-profiles: [core, full]
+profiles: [full]
+runtime: false
 origin: ai-hub
 ---
 

package/skills/shared/ship/SKILL.md

@@ -3,7 +3,8 @@ name: ship
 description: "Use when a verified, review-approved branch has to land — the close of the ai-hub Spec-Kit chain: safety checks, then three landing options (merge, PR, park/discard), authorship always Daner Alejandro Salazar Colorado and never an AI trailer. NOT running the gates (that is `verify`), NOT reading the diff for defects (that is `review`), NOT shipping to a server (that is `deployment`)."
 tags: [sdd, ship, release, pr]
 recommends: []
-profiles: [core, full]
+profiles: [full]
+runtime: false
 origin: ai-hub
 ---
 

package/skills/shared/specify/SKILL.md

@@ -3,7 +3,8 @@ name: specify
 description: "Use when a feature, change, or product idea is still fuzzy and must become an approved WHAT/WHY spec before any planning or code — the brainstorming front door of SDD. Turns a one-line intent into problem, goals, users, scope, behaviour and acceptance criteria, via frontier-round dialogue and 2-3 approaches with a recommendation, carrying zero implementation detail. Fires whenever someone jumps to HOW before WHAT is agreed, in any language. NOT the technical plan (that is `plan`), NOT the de-risking ambiguity sweep (that is `clarify`), NOT project-wide principles (that is `constitution`)."
 tags: [sdd, spec, requirements]
 recommends: [clarify, plan]
-profiles: [core, full]
+profiles: [full]
+runtime: false
 origin: ai-hub
 ---
 

package/skills/shared/tasks/SKILL.md

@@ -3,7 +3,8 @@ name: tasks
 description: "Use when an approved plan needs slicing into an ordered task list before any code — the SDD `tasks` phase. Each row carries a literal done-check, dependencies, a parallel-safe marker and a spec trace, appended to the plan artifact. NOT writing the plan (that is `plan`), NOT the consistency gate (that is `analyze`), NOT executing the tasks (that is `implement`)."
 tags: [sdd, tasks, breakdown]
 recommends: [analyze, implement]
-profiles: [core, full]
+profiles: [full]
+runtime: false
 origin: ai-hub
 ---
 

package/skills/shared/verify/SKILL.md

@@ -3,7 +3,8 @@ name: verify
 description: "Use when implementation is finished and about to be called done or merged — the ai-hub Spec-Kit evidence gate: runs the stack's scripts/verify.sh (lint, type, test, audit), walks every task done-check and acceptance criterion, records a dated verdict. NOT judging the diff by eye (that is `review`, spec-less `code-review`), NOT diagnosis (that is `debug`)."
 tags: [sdd, verify, test]
 recommends: [review]
-profiles: [core, full]
+profiles: [full]
+runtime: false
 origin: ai-hub
 ---
 

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

@@ -1,35 +0,0 @@
----
-name: speckit-analyze
-description: Check consistency, coverage and traceability across spec, plan, checklist and tasks before implementation. Use after speckit-tasks.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Find contradictions before code makes them expensive.
-
-**Input**: `spec.md`, `plan.md`, `checklist.md` and `tasks.md` for the same feature.
-
-**Steps**
-
-1. Build a matrix: requirement → plan component → checklist gate → task.
-2. Report every gap, orphan and contradiction in `analysis.md`:
-   - `## Cobertura` — requirements without a task or test.
-   - `## Contradicciones` — spec vs plan vs checklist.
-   - `## Duplicados` — tasks or components that solve the same thing.
-   - `## Ambigüedades` — language that still admits two implementations.
-   - `## Veredicto` — `PASS` or `NEEDS_FIX` with the exact artifact to edit.
-3. Fix nothing in this phase; return findings to the owning artifact.
-
-**Artifacts**: `specs/<feature>/analysis.md`
-
-**Exit states**
-- `PASS` — full coverage and no contradiction.
-- `NEEDS_FIX` — at least one gap or contradiction; name the artifact.
-
-**Guardrails**
-- Never edit the spec or plan from this skill.
-- A requirement covered only by a "misc" task is not covered.
-- Do not silence a finding because implementation is already underway.

package/skills/shared/speckit-assess-decide/SKILL.md

@@ -1,36 +0,0 @@
----
-name: speckit-assess-decide
-description: Score the assessment and produce a GO, KILL or NEEDS_CLARIFICATION decision. Use when intake, research, problem and concept are complete.
-license: MIT
-compatibility: Requires the Spec Kit layout under `.specify/assessments/`.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Close the assessment lane with an explicit, auditable decision.
-
-**Input**: `intake.md`, `research.md`, `problem.md` and `concept.md` for the same slug.
-
-**Steps**
-
-1. Score each dimension from 1 to 5 in `decision.md`:
-   - `## Scorecard` — problema, evidencia, impacto, esfuerzo, reversibilidad.
-   - `## Decisión` — `GO`, `KILL` or `NEEDS_CLARIFICATION`.
-   - `## Justificación` — two paragraphs tied to the scorecard.
-   - `## Condiciones` — what must remain true for the decision to hold.
-   - `## Siguiente paso` — the exact change name for the feature lane, or the archive path.
-2. Apply the thresholds: `GO` requires evidence >= 3, impacto >= 3 and reversibilidad >= 3.
-3. If the decision is `KILL`, state what would have to change to reopen it.
-4. Hand off to the feature lane only with a human acknowledgment when the issue is `ai::spec-ready`.
-
-**Artifacts**: `.specify/assessments/<slug>/decision.md`
-
-**Exit states**
-- `GO` — proceed to `/speckit.constitution` and `/speckit.specify`.
-- `KILL` — archive the assessment directory with the decision.
-- `NEEDS_CLARIFICATION` — return to `assess-define` with the open question.
-
-**Guardrails**
-- Never approve your own `ai::spec-ready`; the human gate is mandatory.
-- Do not hide a low score behind optimistic prose.

package/skills/shared/speckit-assess-define/SKILL.md

@@ -1,36 +0,0 @@
----
-name: speckit-assess-define
-description: Define the problem, users, goals and success metrics of an idea with evidence. Use after assess-research confirmed the assumptions.
-license: MIT
-compatibility: Requires the Spec Kit layout under `.specify/assessments/`.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Write the problem definition that the rest of the assessment will be judged against.
-
-**Input**: `intake.md` and `research.md` for the same slug.
-
-**Steps**
-
-1. Write `problem.md`:
-   - `## Problema` — one paragraph, present tense, no solution.
-   - `## Usuarios` — primary and secondary, with frequency and context.
-   - `## Objetivos` — numbered, each measurable.
-   - `## No objetivos` — what this change deliberately excludes.
-   - `## Métricas` — baseline, target and how each is collected.
-   - `## Restricciones` — technical, legal or operational limits found in research.
-2. Check that every objective maps to at least one metric and one user.
-3. Remove adjectives that cannot be measured ("rápido", "fácil", "robusto").
-
-**Artifacts**: `.specify/assessments/<slug>/problem.md`
-
-**Exit states**
-- `GO` — problem, users, objectives and metrics are complete and consistent.
-- `NEEDS_CLARIFICATION` — an objective has no metric or an affected user is unknown.
-- `KILL` — the problem is real but the cost or constraints make it unviable now.
-
-**Guardrails**
-- Do not write requirements, user stories or acceptance criteria yet; that belongs to `spec.md`.
-- Never set a target without a baseline.

package/skills/shared/speckit-assess-intake/SKILL.md

@@ -1,38 +0,0 @@
----
-name: speckit-assess-intake
-description: Capture and normalize a raw idea before investing in research. Use when an issue or request arrives without a clear problem statement, owner or success signal.
-license: MIT
-compatibility: Requires the Spec Kit layout under `.specify/assessments/`.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Capture the idea exactly as it arrived, then normalize it without judging it yet.
-
-**Input**: the raw request (issue, message or note) and an optional slug.
-
-**Steps**
-
-1. Read the request and separate facts from assumptions. Do not research solutions yet.
-2. Assign a kebab-case slug and create `.specify/assessments/<slug>/`.
-3. Write `intake.md` with these headings only:
-   - `## Petición original` — verbatim, quoted.
-   - `## Problema observado` — one paragraph, no solution language.
-   - `## Afectados` — who suffers the problem and how often.
-   - `## Señal de éxito` — observable metric or event.
-   - `## Supuestos` — numbered, each falsifiable.
-   - `## Preguntas abiertas` — numbered, each answerable by research.
-4. Reject ideas that cannot name an affected user or a success signal: record why.
-
-**Artifacts**: `.specify/assessments/<slug>/intake.md`
-
-**Exit states**
-- `GO` — problem, users and success signal exist; continue to `assess-research`.
-- `NEEDS_CLARIFICATION` — a question blocks research; ask the human and stop.
-- `KILL` — no affected user or no observable outcome; archive with the reason.
-
-**Guardrails**
-- Never propose architecture, libraries or estimates in this phase.
-- Never invent quotes, metrics or owners.
-- Keep every assumption falsifiable; vague language such as "mejorar" is not a success signal.

package/skills/shared/speckit-assess-research/SKILL.md

@@ -1,36 +0,0 @@
----
-name: speckit-assess-research
-description: Gather evidence for and against an idea before shaping a solution. Use after assess-intake produced a problem statement with falsifiable assumptions.
-license: MIT
-compatibility: Requires the Spec Kit layout under `.specify/assessments/`.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Turn the intake assumptions into evidence, not opinions.
-
-**Input**: `.specify/assessments/<slug>/intake.md`.
-
-**Steps**
-
-1. For each assumption, search the repository, the GitLab issues and the public documentation.
-2. Record evidence in `research.md`:
-   - `## Evidencia a favor` — claim, source, date and how it was verified.
-   - `## Evidencia en contra` — same shape; do not omit inconvenient findings.
-   - `## Precedentes` — existing modules or issues that already solved part of this.
-   - `## Coste de oportunidad` — what the team stops doing if this proceeds.
-   - `## Supuestos refutados` — the intake assumptions that did not survive.
-3. Prefer primary sources (code, API docs, telemetry) over blog posts.
-4. Mark every unverifiable claim as `NO VERIFICADO`; never present it as fact.
-
-**Artifacts**: `.specify/assessments/<slug>/research.md`
-
-**Exit states**
-- `GO` — at least one assumption confirmed and none refuted fatally.
-- `NEEDS_CLARIFICATION` — the evidence is insufficient and a human can unblock it.
-- `KILL` — the evidence refutes the core problem or a cheaper precedent already exists.
-
-**Guardrails**
-- Cite sources with paths or URLs; an uncited claim is not evidence.
-- Do not design the solution, estimate effort or choose libraries.

package/skills/shared/speckit-assess-shape/SKILL.md

@@ -1,36 +0,0 @@
----
-name: speckit-assess-shape
-description: Compare solution shapes and choose an appetite before committing to a feature specification. Use after assess-define fixed the problem and metrics.
-license: MIT
-compatibility: Requires the Spec Kit layout under `.specify/assessments/`.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Explore two or three viable shapes, then choose one to carry into the feature lane.
-
-**Input**: `problem.md` and `research.md` for the same slug.
-
-**Steps**
-
-1. Describe at least two options in `concept.md`:
-   - `## Opción A/B/C` — approach, affected modules, data changes, risks.
-   - `## Esfuerzo` — appetite in days, not a detailed estimate.
-   - `## Coste de mantenimiento` — what the team must keep working.
-   - `## Reversibilidad` — how to undo it if the metrics do not move.
-2. Recommend one option and state the trade-off accepted.
-3. Define the smallest version that can validate the main metric.
-4. Record explicitly what is deferred to a later change.
-
-**Artifacts**: `.specify/assessments/<slug>/concept.md`
-
-**Exit states**
-- `GO` — one option fits the appetite and validates the metric.
-- `NEEDS_CLARIFICATION` — the options differ only in cost and a human must choose.
-- `KILL` — no option fits the appetite or every option is irreversible.
-
-**Guardrails**
-- Do not write file-level plans, schemas or code; `design.md` owns that.
-- Never present one option as the only possibility without comparing it.
-- The appetite is a constraint, not a promise: do not expand it silently.

package/skills/shared/speckit-bug-assess/SKILL.md

@@ -1,38 +0,0 @@
----
-name: speckit-bug-assess
-description: Diagnose a bug without editing code. Use when a defect needs a reproducible root cause before any fix is authorized.
-license: MIT
-compatibility: Requires access to logs, tests and the repository.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Produce a diagnosis that another engineer could reproduce.
-
-**Input**: the failing report, logs, and the affected route or component.
-
-**Steps**
-
-1. Reproduce the defect or record why it cannot be reproduced.
-2. Write `assessment.md`:
-   - `## Síntoma` — observed vs expected, with the exact request or action.
-   - `## Reproducción` — numbered steps and environment.
-   - `## Evidencia` — logs, stack traces, failing test names.
-   - `## Causa raíz` — the smallest code path or data state that explains it.
-   - `## Alcance` — modules affected and modules explicitly not affected.
-   - `## Fix propuesto` — approach only, no patch.
-   - `## Riesgo de regresión` — tests that must stay green.
-3. Point to file and line for the root cause; if unknown, say `NO DETERMINADA`.
-4. Do not edit source, tests or configuration in this phase.
-
-**Artifacts**: `.specify/bugs/<slug>/assessment.md`
-
-**Exit states**
-- `ROOT_CAUSE` — diagnosis complete; continue to `bug-fix`.
-- `NEEDS_DATA` — reproduction or evidence is missing; list exactly what is needed.
-
-**Guardrails**
-- Never guess a root cause from a stack trace alone.
-- Do not propose a fix that changes architecture; that requires a feature change.
-- Never mark a bug fixed from this phase.

package/skills/shared/speckit-bug-fix/SKILL.md

@@ -1,37 +0,0 @@
----
-name: speckit-bug-fix
-description: Apply a scoped repair for a diagnosed bug and document the change. Use after speckit-bug-assess produced ROOT_CAUSE.
-license: MIT
-compatibility: Requires a workspace with tests.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Fix only what the diagnosis proved, and leave the evidence behind.
-
-**Input**: `.specify/bugs/<slug>/assessment.md` with exit state `ROOT_CAUSE`.
-
-**Steps**
-
-1. Re-read the root cause and the declared scope. If the scope must grow, stop and return to `bug-assess`.
-2. Write the smallest change that removes the cause; do not refactor adjacent code.
-3. Add or update a regression test that fails before the fix and passes after it.
-4. Write `fix.md`:
-   - `## Causa corregida` — one sentence tied to the diagnosis.
-   - `## Archivos` — path and purpose of every touched file.
-   - `## Prueba de regresión` — test name and command.
-   - `## Fuera de alcance` — what was deliberately not touched.
-   - `## Riesgos` — remaining uncertainty.
-5. Run the narrow test suite and the package typecheck.
-
-**Artifacts**: `.specify/bugs/<slug>/fix.md` plus the code and test changes.
-
-**Exit states**
-- `FIXED` — regression test green and typecheck clean; continue to `bug-test`.
-- `BLOCKED` — the fix requires a scope or design change; record why and stop.
-
-**Guardrails**
-- Never weaken an existing test to make the suite pass.
-- Never include unrelated formatting or dependency updates.
-- No `TODO`, `FIXME` or placeholder code.

package/skills/shared/speckit-bug-test/SKILL.md

@@ -1,37 +0,0 @@
----
-name: speckit-bug-test
-description: Verify a bug fix against reproduction, regression and adjacent behavior, then issue a verdict. Use after speckit-bug-fix produced FIXED.
-license: MIT
-compatibility: Requires the project test commands.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Independently verify the repair; do not trust the implementer's summary.
-
-**Input**: `assessment.md`, `fix.md` and the changed files.
-
-**Steps**
-
-1. Reproduce the original defect with the pre-fix revision or a fixture that simulates it.
-2. Run the regression test and confirm it fails without the patch and passes with it.
-3. Run the package suite and record the command, duration and result.
-4. Write `test.md`:
-   - `## Reproducción original` — pass/fail with evidence.
-   - `## Regresión` — test name and result.
-   - `## Suite` — command and totals.
-   - `## Riesgo residual` — areas not covered.
-   - `## Veredicto` — `VERIFIED`, `PARTIAL` or `FAILED`.
-5. If `FAILED`, return to `bug-assess` with the new evidence; do not patch the code here.
-
-**Artifacts**: `.specify/bugs/<slug>/test.md`
-
-**Exit states**
-- `VERIFIED` — original defect gone, regression test proven, suite green.
-- `PARTIAL` — fix works but evidence or environment is incomplete; list the gap.
-- `FAILED` — the defect persists or a new regression appears; reopen the diagnosis.
-
-**Guardrails**
-- Never edit the fix or the tests in this phase.
-- Never issue `VERIFIED` from a skipped or flaky test without saying so.

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

@@ -1,35 +0,0 @@
----
-name: speckit-checklist
-description: Build and run the quality gate for a feature plan before implementation. Use after speckit-plan and before speckit-tasks.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Decide whether the plan is safe to implement.
-
-**Input**: `spec.md`, `plan.md` and the project constitution.
-
-**Steps**
-
-1. Create `checklist.md` with one section per gate:
-   - `## Constitución` — every principle checked.
-   - `## Cobertura` — every requirement mapped to a component and test.
-   - `## Seguridad` — secrets, permissions, input validation, destructive operations.
-   - `## Compatibilidad` — platforms, data migration, rollback.
-   - `## Observabilidad` — logs, metrics and failure signals.
-2. Mark each item `PASS`, `FAIL` or `N/A` with one line of evidence.
-3. A single `FAIL` blocks implementation; return to `plan` or `specify`.
-
-**Artifacts**: `specs/<feature>/checklist.md`
-
-**Exit states**
-- `PASS` — no blocking findings.
-- `NEEDS_FIX` — at least one `FAIL`; name the artifact to revise.
-
-**Guardrails**
-- Do not mark `PASS` from intention; cite the plan or test that proves it.
-- Do not add new requirements in the checklist.
-- Never waive a security or data-loss finding without a human decision.

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

@@ -1,32 +0,0 @@
----
-name: speckit-clarify
-description: Resolve ambiguities in an existing specification by asking targeted questions and encoding the answers. Use when speckit-specify left open questions or inconsistent requirements.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/ and specs/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Turn ambiguity into a decision the implementation can follow.
-
-**Input**: `specs/<feature>/spec.md` with open questions or disputed requirements.
-
-**Steps**
-
-1. List every ambiguity as a question with the requirement it affects.
-2. Ask at most five questions per round, each answerable with a fact or a choice.
-3. For each answer, update the requirement and its scenario; do not append a parallel note.
-4. Record the decision and the discarded alternative in `## Decisiones`.
-5. Remove the resolved question from `## Preguntas abiertas`.
-
-**Artifacts**: `specs/<feature>/spec.md`
-
-**Exit states**
-- `RESOLVED` — no open questions remain and requirements are consistent.
-- `OPEN` — a question still needs a human decision; list the blocker.
-
-**Guardrails**
-- Do not answer a product question on the user's behalf.
-- Do not change scope silently while clarifying; surface any new behavior.
-- Every answer must land in the spec, not only in the conversation.

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

@@ -1,35 +0,0 @@
----
-name: speckit-constitution
-description: Create or update the project constitution that every Spec Kit artifact must obey. Use before specifying a feature, or when the team ratifies a new non-negotiable rule.
-license: MIT
-compatibility: Requires the Spec Kit layout under .specify/.
-metadata:
-  author: onna
-  version: "1.0"
----
-
-Establish the rules that outrank every feature decision.
-
-**Input**: the project's values, non-negotiables and any existing `.specify/memory/constitution.md`.
-
-**Steps**
-
-1. Read the current constitution and the repository conventions. Do not invent rules the team has not accepted.
-2. Write or update `.specify/memory/constitution.md`:
-   - `## Principios` — numbered, each with a one-line rationale.
-   - `## Restricciones técnicas` — stack, compatibility, security, data handling.
-   - `## Calidad` — test thresholds, review gates, definition of done.
-   - `## Gobierno` — who can change the constitution and how.
-3. Mark every principle as `MUST`, `MUST NOT` or `SHOULD`; avoid vague language.
-4. Record the version and the date of ratification.
-
-**Artifacts**: `.specify/memory/constitution.md`
-
-**Exit states**
-- `CREATED` — first constitution written.
-- `UPDATED` — existing constitution amended with a recorded reason.
-
-**Guardrails**
-- Never overwrite a ratified principle without an explicit human decision.
-- Do not encode feature-specific requirements here; those belong to `spec.md`.
-- A constitution change invalidates prior approvals bound to it.

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.