TenantAtlas/.agent/skills/workflows/spec-readiness-gate/SKILL.md
ahmido 332f6325cb feat: add tenantpilot agent skill layer v1 (#483)
Automated PR provided by Codex via Gitea API.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #483
2026-06-25 23:03:47 +00:00

4.2 KiB

name description
tenantpilot-spec-readiness-gate Validate an active TenantPilot Spec Kit package before implementation or merge-readiness claims.

Purpose

Use this skill to check whether an active TenantPilot/TenantAtlas spec package is ready for implementation or review without inventing scope.

Activate When

  • Implementing an active or explicitly named spec.
  • Reviewing spec.md, plan.md, and tasks.md for implementation readiness.
  • A spec introduces new runtime behavior, tests, UI, persistence, abstractions, statuses, or workflow/tooling artifacts.

Do Not Activate When

  • The user asks for a simple code explanation with no implementation or readiness claim.
  • The active work is a tiny non-spec maintenance task and the repo rules do not require Spec Kit artifacts.
  • A completed historical spec is being read only as context.

Maturity

L3 checklist.

Gate Type

checklist.

Source Evidence

  • AGENTS.md
  • .specify/README.md
  • .specify/memory/constitution.md
  • .specify/memory/spec-approval-rubric.md
  • .specify/templates/spec-template.md
  • .specify/templates/plan-template.md
  • .specify/templates/tasks-template.md
  • docs/ai-coding-rules.md
  • specs/416-tenantpilot-agent-skill-layer-v1/spec.md
  • specs/416-tenantpilot-agent-skill-layer-v1/plan.md
  • specs/416-tenantpilot-agent-skill-layer-v1/tasks.md

External Anchors

Not applicable.

Required Repo Context

  • Current branch and git status --short.
  • Active spec directory.
  • Active spec.md, plan.md, tasks.md, and checklist if present.
  • Constitution and relevant .specify/templates/.
  • Nearby related specs as read-only context.
  • Code and tests named by the active plan.

Execution Checklist

  • Confirm exactly one active spec directory is in scope.
  • Confirm required spec artifacts exist.
  • Confirm the spec has problem, user value, functional requirements, non-goals, acceptance criteria, assumptions, risks, and open questions.
  • Confirm the plan names affected repo surfaces and does not contradict architecture.
  • Confirm tasks are ordered, bounded, verifiable, and include validation.
  • Confirm Product Surface, RBAC, workspace/managed-environment scope, OperationRun, evidence, provider boundary, test governance, and proportionality sections are complete where relevant.
  • Confirm completed specs are read-only context.
  • Confirm dirty worktree entries are either active-spec artifacts or explicitly user-intended for this operation.

Stop Conditions

  • Active spec cannot be determined safely.
  • spec.md, plan.md, or tasks.md is missing.
  • Open questions block safe implementation.
  • New persisted truth, abstraction, enum/status family, taxonomy, or framework lacks proportionality review.
  • Runtime/UI changes are required but the spec says no runtime/UI impact.
  • The implementation would rewrite completed specs or historical close-out evidence.
  • Dirty unrelated work would be overwritten or mixed into the change.

Required Evidence After Use

  • Active spec path.
  • Gate result: pass, pass with conditions, or fail.
  • Blocking gaps or explicit statement that no blocking gaps remain.
  • Exact files used as source evidence.
  • Any residual risks with reason: out of scope, separate spec, existing unrelated debt, not reproducible, risky refactor, or blocked decision.

Common Failure Modes

  • Treating .specify/spec.md legacy content as the active feature spec.
  • Filling missing scope from assumptions instead of stopping.
  • Normalizing completed specs to satisfy newer templates.
  • Letting a docs-only spec drift into runtime changes.
  • Marking tasks complete before evidence exists.

Quarantined Rules

Full Spec 416 quarantine list applies: tenant_id as platform-core ownership truth; Coverage v1 vocabulary as customer truth; v1-v2 adapters; fallback readers; dual writes; fallback-to-latest evidence; OperationRun as default customer proof; stale provider Healthy/Ready semantics; limited customer download vocabulary; raw provider/evidence payload default display; Product Surface runtime framework; historical audits as current truth.

Review / Expiry

Review this skill whenever Spec Kit templates, the constitution, or the active Spec Kit workflow changes. No planned expiry.