chore: commit all workspace changes

.github/skills/spec-kit-next-best-one-shot/SKILL.md

@@ -0,0 +1,383 @@
+---
+name: spec-kit-next-best-one-shot
+description: Select the most suitable next TenantPilot/TenantAtlas spec from roadmap and spec-candidates, then create Spec Kit preparation artifacts in one pass: spec.md, plan.md, and tasks.md. Use when the user wants the agent to choose the next best spec based on roadmap fit, current candidates, repository state, platform priorities, governance foundations, UX improvements, architecture cleanup, or implementation readiness. This skill must not implement application code.
+---
+
+# Skill: Spec Kit Next-Best One-Shot Preparation
+
+## Purpose
+
+Use this skill when the user wants the agent to select the most suitable next spec from existing product planning sources and then create the Spec Kit preparation artifacts in one pass:
+
+1. choose the next best spec candidate
+2. create `spec.md`
+3. create `plan.md`
+4. create `tasks.md`
+5. provide a manual analysis prompt
+
+This skill prepares implementation work, but it must not perform implementation.
+
+The intended workflow is:
+
+```text
+roadmap.md + spec-candidates.md
+→ select next best spec
+→ one-shot spec + plan + tasks preparation
+→ manual repo-based analysis/review
+→ explicit implementation step later
+```
+
+## When to Use
+
+Use this skill when the user asks things like:
+
+```text
+Nimm die nächste sinnvollste Spec aus roadmap und spec-candidates.
+```
+
+```text
+Wähle die nächste geeignete Spec und erstelle spec, plan und tasks.
+```
+
+```text
+Schau in roadmap.md und spec-candidates.md und mach daraus die nächste Spec.
+```
+
+```text
+Such die beste nächste Spec aus und bereite sie in einem Rutsch vor.
+```
+
+```text
+Nimm angesichts Roadmap und Spec Candidates das sinnvollste nächste Thema.
+```
+
+## Hard Rules
+
+- Work strictly repo-based.
+- Do not implement application code.
+- Do not modify production code.
+- Do not modify migrations, models, services, jobs, Filament resources, Livewire components, policies, commands, or tests unless the user explicitly starts a later implementation task.
+- Do not execute implementation commands.
+- Do not run destructive commands.
+- Do not invent roadmap priorities not supported by repository documents.
+- Do not pick a spec only because it is listed first.
+- Do not select broad platform rewrites when a smaller dependency-unlocking spec is more appropriate.
+- Prefer specs that unlock roadmap progress, reduce architectural drift, harden foundations, or remove known blockers.
+- Prefer small, reviewable, implementation-ready specs over large ambiguous themes.
+- Preserve TenantPilot/TenantAtlas terminology.
+- Follow the repository constitution and existing Spec Kit conventions.
+- If repository truth conflicts with roadmap/candidate wording, keep repository truth and document the deviation.
+- If no candidate is suitable, create no spec and explain why.
+
+## Required Repository Checks
+
+Before selecting the next spec, inspect:
+
+1. `.specify/memory/constitution.md`
+2. `.specify/templates/`
+3. `specs/`
+4. `docs/product/spec-candidates.md`
+5. roadmap documents under `docs/product/`, especially `roadmap.md` if present
+6. nearby existing specs related to top candidate areas
+7. current spec numbering conventions
+8. application code only as needed to verify whether a candidate is already done, blocked, duplicated, or technically mis-scoped
+
+Do not edit application code.
+
+## Candidate Selection Criteria
+
+Evaluate candidate specs using these criteria.
+
+### 1. Roadmap Fit
+
+Prefer candidates that directly support the current roadmap sequence or unlock the next roadmap layer.
+
+Examples:
+
+- governance foundations before advanced compliance views
+- evidence/snapshot foundations before auditor packs
+- control catalog foundations before CIS/NIS2 mappings
+- decision/workflow surfaces before autonomous governance
+- provider/platform boundary cleanup before multi-provider expansion
+
+### 2. Foundation Value
+
+Prefer candidates that strengthen reusable platform foundations:
+
+- RBAC and workspace/tenant isolation
+- auditability
+- evidence and snapshot truth
+- operation observability
+- provider boundary neutrality
+- canonical vocabulary
+- baseline/control/finding semantics
+- enterprise detail-page or decision-surface patterns
+
+### 3. Dependency Unblocking
+
+Prefer specs that unblock multiple later candidates.
+
+A good next spec should usually make future specs smaller, safer, or more consistent.
+
+### 4. Scope Size
+
+Prefer a candidate that can be implemented as a narrow, testable slice.
+
+Avoid selecting:
+
+- broad platform rewrites
+- vague product themes
+- multi-feature bundles
+- speculative future-provider frameworks
+- large UX redesigns without a clear first slice
+
+### 5. Repo Readiness
+
+Prefer candidates where the repository already has enough structure to implement the next slice safely.
+
+Check whether related models, services, UI pages, tests, or concepts already exist.
+
+### 6. Risk Reduction
+
+Prefer candidates that reduce current architectural or product risk:
+
+- legacy dual-world semantics
+- unclear truth ownership
+- inconsistent operator UX
+- missing audit/evidence boundaries
+- repeated manual workflow friction
+- false-positive calmness in governance surfaces
+
+### 7. User/Product Value
+
+Prefer specs that produce visible operator value or make the platform more sellable without creating heavy scope.
+
+## Candidate Selection Output
+
+Before creating files, prepare a concise decision summary for the final response.
+
+The selected candidate should include:
+
+- selected candidate title
+- why it was selected
+- why the nearest alternatives were not selected now
+- roadmap relationship
+- expected implementation slice
+
+Do not create multiple specs unless the repository convention explicitly supports it and the user asked for it.
+
+## Selection Matrix
+
+When comparing candidates, use a small matrix internally or in the final summary:
+
+| Candidate | Roadmap fit | Foundation value | Scope size | Repo readiness | Risk reduction | Decision |
+|---|---:|---:|---:|---:|---:|---|
+
+Keep it concise. Do not over-analyze if the best candidate is obvious.
+
+## Spec Directory Rules
+
+Create a new spec directory using the next valid spec number and a kebab-case slug:
+
+```text
+specs/<number>-<slug>/
+```
+
+The exact number must be derived from the current repository state and existing numbering conventions.
+
+Create or update only these preparation artifacts inside the selected spec directory:
+
+```text
+specs/<number>-<slug>/spec.md
+specs/<number>-<slug>/plan.md
+specs/<number>-<slug>/tasks.md
+```
+
+If the repository templates require additional preparation files, create them only when consistent with existing Spec Kit conventions.
+
+Do not create implementation files.
+
+## `spec.md` Requirements
+
+The spec must be product- and behavior-oriented.
+
+Include:
+
+- Feature title
+- Selected-candidate rationale
+- Problem statement
+- Business/product value
+- Roadmap relationship
+- Primary users/operators
+- User stories
+- Functional requirements
+- Non-functional requirements
+- UX requirements
+- RBAC/security requirements
+- Auditability/observability requirements
+- Data/truth-source requirements where relevant
+- Out of scope
+- Acceptance criteria
+- Success criteria
+- Risks
+- Assumptions
+- Open questions
+- Follow-up spec candidates if the selected candidate had to be narrowed
+
+TenantPilot/TenantAtlas specs should preserve enterprise SaaS principles:
+
+- workspace/tenant isolation
+- capability-first RBAC
+- auditability
+- operation/result truth separation
+- source-of-truth clarity
+- calm enterprise operator UX
+- progressive disclosure where useful
+- no false positive calmness
+- provider/platform boundary clarity where relevant
+- versioned governance semantics where relevant
+
+## `plan.md` Requirements
+
+The plan must be repo-aware and implementation-oriented, but must not implement.
+
+Include:
+
+- Technical approach
+- Existing repository surfaces likely affected
+- Domain/model implications
+- UI/Filament implications
+- Livewire implications where relevant
+- OperationRun/monitoring implications where relevant
+- RBAC/policy implications
+- Audit/logging/evidence implications where relevant
+- Data/migration implications where relevant
+- Test strategy
+- Rollout considerations
+- Risk controls
+- Implementation phases
+
+Where relevant, clearly distinguish:
+
+- execution truth
+- artifact truth
+- backup/snapshot truth
+- evidence truth
+- recovery confidence
+- operator next action
+
+Use those distinctions only when relevant to the selected spec.
+
+## `tasks.md` Requirements
+
+Tasks must be ordered, small, and verifiable.
+
+Include:
+
+- checkbox tasks
+- phase grouping
+- tests before or alongside implementation tasks where practical
+- final validation tasks
+- documentation/update tasks if needed
+- explicit non-goals where useful
+
+Avoid vague tasks such as:
+
+```text
+Clean up code
+Refactor UI
+Improve performance
+Make it enterprise-ready
+```
+
+Prefer concrete tasks such as:
+
+```text
+- [ ] Add a feature test covering workspace isolation for <specific behavior>.
+- [ ] Update <specific Filament page/resource> to display <specific state>.
+- [ ] Add policy coverage for <specific capability>.
+```
+
+If exact file names are not known yet, phrase tasks as repo-verification tasks first rather than inventing file paths.
+
+## Scope Control
+
+If the selected roadmap/candidate item is too broad, narrow it into the smallest valuable first implementation slice.
+
+Add a `Follow-up spec candidates` section for deferred concerns.
+
+Examples of follow-up candidates:
+
+- assigned findings
+- pending approvals
+- personal work queue
+- notification delivery settings
+- evidence pack export hardening
+- operation monitoring refinements
+- autonomous governance decision surfaces
+- compliance mapping library expansion
+- MSP portfolio rollups
+- provider-specific adapters
+
+Do not force follow-up candidates into the primary spec.
+
+## Final Response Requirements
+
+After creating or updating the artifacts, respond with:
+
+1. Selected candidate
+2. Why this candidate was selected
+3. Why close alternatives were deferred
+4. Created or updated spec directory
+5. Files created or updated
+6. Important repo-based adjustments made
+7. Assumptions made
+8. Open questions, if any
+9. Recommended next manual analysis prompt
+10. Explicit statement that no implementation was performed
+
+Keep the response concise, but include enough detail for the user to continue immediately.
+
+## Required Next Manual Analysis Prompt
+
+Always provide a ready-to-copy prompt like this, adapted to the created spec number and slug:
+
+```markdown
+Du bist ein Senior Staff Software Architect und Enterprise SaaS Reviewer.
+
+Analysiere die neu erstellte Spec `<spec-number>-<slug>` streng repo-basiert.
+
+Ziel:
+Prüfe, ob `spec.md`, `plan.md` und `tasks.md` vollständig, konsistent, implementierbar, roadmap-konform und constitution-konform sind.
+
+Wichtig:
+- Keine Implementierung.
+- Keine Codeänderungen.
+- Keine Scope-Erweiterung.
+- Prüfe nur gegen Repo-Wahrheit.
+- Prüfe auch, ob die ausgewählte Spec wirklich die sinnvollste nächste Spec aus `docs/product/spec-candidates.md` und `docs/product/roadmap.md` war.
+- Benenne konkrete Konflikte mit Dateien, Patterns, Datenflüssen oder bestehenden Specs.
+- Schlage nur minimale Korrekturen an `spec.md`, `plan.md` und `tasks.md` vor.
+- Wenn alles passt, gib eine klare Implementierungsfreigabe.
+```
+
+## Example Invocation
+
+User:
+
+```text
+Nutze den Skill spec-kit-next-best-one-shot.
+Wähle aus roadmap.md und spec-candidates.md die nächste sinnvollste Spec und erstelle spec, plan und tasks in einem Rutsch.
+Keine Implementierung.
+```
+
+Expected behavior:
+
+1. Inspect constitution, templates, specs, roadmap, and spec candidates.
+2. Compare candidate suitability.
+3. Select the next best candidate.
+4. Determine the next valid spec number.
+5. Create `spec.md`, `plan.md`, and `tasks.md`.
+6. Keep scope tight.
+7. Do not implement.
+8. Return selection rationale, artifact summary, and next manual analysis prompt.