tbh/breadcrumb-the-shire
1
0
Fork 0
forked from fa/breadcrumb-the-shire
Code Pull Requests Activity
Files
545bcc789bc4797ec69d51d1d8f5a6b4fbcb647f
breadcrumb-the-shire/.agents/skills/starterkit-planner/SKILL.md
fs 545bcc789b docs: replace ASCII umlaut fallbacks with proper äöüß across all .md 
Most German docs were written with `ue`/`ae`/`oe`/`ss` ASCII fallbacks
(`fuer`, `aenderung`, `koennen`, `gemaess`) — relic from older toolchain
constraints. Replaced 237 occurrences across 38 .md files with proper
umlauts and ß so the docs read naturally.

Substitutions are constrained to plain prose: fenced code blocks
(```...```), inline code spans (`...`), markdown link targets `[..](..)`,
and HTML comments are preserved verbatim. Path references like
`docs/howto-erste-aenderung.md` keep their original (umlaut-replaced)
filenames — only the surrounding prose is normalised.

Tool: bin/fix-md-umlauts.py (idempotent — no-op on already-clean files).
Re-runnable if ASCII fallbacks creep back in via copy-paste.

Doc-link-check + doc-drift-check stay green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 09:57:22 +02:00

2.1 KiB
Raw Blame History

name, description
name description
starterkit-planner Planungs-Skill für Architektur-, Rollout-, Refactor- und Standardisierungsaufgaben im Starterkit. Verwenden, wenn ein decision-complete Plan mit klaren Interfaces, Tests, Risiken und Annahmen benötigt wird.

Starterkit Planner

Ziel

Planungen so strukturieren, dass Implementierung ohne offene Entscheidungen möglich ist. Bei Agent-Workflows muss der Plan maschinenlesbar in die Projekt-Contracts passen.

Verbindliches Ausgabeformat

  1. Ziel + Success Criteria
  2. In/Out-of-Scope
  3. Entscheidungsmatrix (Optionen + Gruende)
  4. Decision-complete Implementierungsplan
  5. Tests/Abnahme
  6. Risiken/Migrationshinweise
  7. Annahmen/Defaults

Wenn .agents/ verwendet wird:

  1. Plan muss dem Schema .agents/contracts/planner.schema.json entsprechen.
  2. Success Criteria müssen stabile IDs tragen (SC-001, SC-002, ...).
  3. Success Criteria müssen so formuliert sein, dass Reviewer Acceptance sie direkt gegen criterion_id prüfen kann.
  4. Guard- und Quality-Gate-IDs müssen aus den Katalogen kommen (GR-*, QG-*).

Vorgehen

  1. Ist-Zustand kurz aus Repo-Fakten ableiten.
  2. Entscheidungen mit Tradeoffs transparent machen.
  3. Oeffentliche Contracts explizit benennen.
  4. Success Criteria frueh mit stabilen IDs (SC-*) definieren.
  5. Reihenfolge und Rollout so planen, dass Rueckbau möglich bleibt.
  6. Teststrategie nach Risiko priorisieren.

Qualitaetskriterien

  1. Keine vagen TODO-Entscheidungen im Plan.
  2. Jeder betroffene Bereich hat klare Akzeptanzkriterien mit stabiler ID (SC-*).
  3. Risiken sind priorisiert und beobachtbar.
  4. Ungeklaerte Themen stehen explizit unter Annahmen.
  5. Guard-/Gate-Referenzen sind vollstaendig und prüfbar (GR-*, QG-*).

Out of Scope

  • Extension-Mechanik ist aktuell nicht standardisiert.
  • Keine impliziten Extension-Regeln definieren.

Referenzen

  • Plan-Grundgeruest: references/plan-template.md
  • Entscheidungsraster: references/tradeoff-matrix.md
  • Agent Planner Contract: .agents/contracts/planner.schema.json
  • Guard Catalog: .agents/checks/guard-catalog.json
  • Quality Gates: .agents/checks/quality-gates.json
View Git Blame Copy Permalink