16 added, 26 removed. Audit A to A.
---
name: ln-71-system-design-baseline-builder
- description: "Creates a project baseline of architecture drivers and constraints. Use before design or planning; not for target design, plan review, implementation, or architecture audit."
+ description: "Creates architecture-driving requirements and constraints before design. Not for target design, plan review, or implementation audits."
---
# System Design Baseline Builder
**Goal:** Create or update one durable source of truth for the project's architecture-driving requirements and constraints. Change only the approved architecture document; do not design the solution, review a plan, audit implementation, edit product code, or invent missing targets.
- **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Track every checkbox as `PENDING`, then resolve it to `PROVEN` with concrete evidence, `CLEARED` with evidence that its conditional trigger is absent, or `UNPROVEN`; reading, mentioning, delegating, skipping, or tool failure is not proof.
- Before returning, resolve every `PENDING`, count only `PROVEN` and `CLEARED` items as complete, apply this skill's verdict, decision, and approval rules to every `UNPROVEN`, and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every `UNPROVEN` item.
+ **Execution contract:** The ordered checkboxes are the Definition of Done. Track every item internally as `PENDING`, `PROVEN` with concrete evidence, `CLEARED` with evidence that its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all `PENDING` and count only `PROVEN` and `CLEARED`; apply the skill's verdict and approval rules to every gap.
+ Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
## Tool Routing
| Need | Preferred capability | Fallback |
|---|---|---|
| Repository rules and document conventions | Native file reads plus focused search | User-provided convention with an explicit limitation |
| Existing requirements and architecture artifacts | Narrow repository search and direct reads | Conversation evidence marked with its source |
| Current workload or service evidence | Metrics, dashboards, logs, manifests, or checked-in reports | Mark `UNKNOWN`; never manufacture production numbers |
| Current external limits or standards | Official documentation or specifications | Mark the claim `UNVERIFIED` |
| Document mutation | Minimal patch to the approved Markdown artifact | Return `BLOCKED` if no safe writable path is authorized |
Use external research only when a time-sensitive fact changes a constraint. Do not browse for values that must come from product owners, operators, the repository, or measured workload.
## Artifact Rules
- Prefer an existing unambiguous architecture-requirements document.
- Otherwise use `docs/architecture/system-design-baseline.md`.
- Read before writing, preserve unrelated content, and update facts in place instead of creating parallel truth.
- Classify applicability separately as `APPLICABLE` or `NOT_APPLICABLE`, with evidence for exclusions.
- Rank each applicable item as `DRIVER`, `SUPPORTING`, or `INFORMATIONAL`.
- Classify evidence separately as `CONFIRMED`, `ASSUMED`, or `UNKNOWN`.
- - Record source, owner, confirmation date, and review trigger for each architecture driver.
- Separate observed current values, required targets, hard limits, and future evolution triggers.
- - Use measurable quality-attribute scenarios; avoid words such as "fast", "scalable", or "secure" without a response measure.
+ - Express quality attributes through observable scenarios and response measures; record undecided targets as missing decisions rather than inventing numbers.
- Treat the baseline as versioned project knowledge, not an immutable promise.
## Checklist
### 1. Establish Scope and Destination
- [ ] Resolve the project, business outcome, intended readers, approved documentation scope, and language.
- [ ] Read applicable repository instructions and inspect Git state so unrelated changes remain untouched.
- [ ] Search for existing requirement, architecture, SLO, recovery, security, cost, and ownership documents.
- [ ] Select one canonical artifact: reuse a clear equivalent or choose the default path; explain why no duplicate will be created.
- [ ] Return `BLOCKED` if the destination is ambiguous and choosing one could split project truth.
### 2. Build the Evidence Ledger
- - [ ] Extract confirmed business goals, actors, critical journeys, scope, non-goals, and decision horizon.
+ - [ ] Collect business goals, actors, journeys, scope, non-goals, and decision horizon with their sources and confidence for the driver analysis; do not create a second context inventory.
- [ ] Record sources for current workload, data volume, service behavior, platform limits, and existing commitments.
- [ ] Separate repository facts from stakeholder choices and estimates.
- [ ] Detect contradictions between documents, code, configuration, and stated requirements; preserve both claims until resolved.
- [ ] Ask only for choices whose absence materially changes architecture; mark all other gaps `UNKNOWN`.
### 3. Define and Prioritize Architecture Drivers
- [ ] **Business and scope:** Record actors, critical journeys, business horizon, scope, non-goals, and externally committed outcomes.
- [ ] **Demand and data scale:** Record current and target users, rates, concurrency, payloads, growth, retention, and forecast horizon where relevant.
- [ ] **User-observable service quality:** Define SLIs and SLOs for availability, latency, throughput, error rate, correctness, or freshness with measurement windows.
- [ ] **Data semantics and recovery:** Define consistency, ordering, idempotency, reconciliation, durability, backup, RTO, RPO, and acceptable data loss at affected boundaries.
- [ ] **Security, privacy, and compliance:** Define trust boundaries, data classification, residency, access, audit, and destructive-action constraints.
- [ ] **Operations and economics:** Define ownership, operational capacity, cost envelope, supported regions, delivery cadence, and platform or vendor constraints.
- [ ] **Evolution:** Record thresholds, business events, or evidence that justify revisiting an assumption, target, or deferred capability.
- [ ] Separate applicability, criticality, and evidence status; do not use `UNKNOWN` to mean unimportant or `NOT_APPLICABLE`.
- [ ] Prioritize the few scenarios most likely to shape architecture and express each as source/stimulus/environment/artifact/response/measure.
### 4. Write the Baseline
- [ ] Create or update the artifact with: identity and status; business context; scope and non-goals; critical scenarios; workload and data; quality targets; recovery; consistency; security; cost and operations; constraints; assumptions and unknowns; review triggers.
- - [ ] Give every material parameter its theme, applicability, criticality, evidence status, value or range, source, owner, as-of date, and review trigger.
+ - [ ] Give material parameters their theme, applicability, criticality, evidence status, value/range, source, owner, as-of date, and review trigger. State shared metadata once with explicit inheritance; use `UNKNOWN` for missing ownership or values.
- [ ] Keep calculations reproducible and label estimates separately from observed measurements.
- [ ] Link shared architecture artifacts only by repository path or document title; never require a particular workflow or tool.
- [ ] Preserve historical context needed to understand changed requirements instead of silently rewriting prior commitments.
### 5. Validate and Report
- [ ] Re-read the written artifact and verify that no unknown was converted into a confident fact.
- [ ] Check that targets are measurable, internally consistent, and proportionate to the evidenced business horizon.
- [ ] Check that every architecture-critical gap has an owner or exact next evidence action.
- - [ ] Confirm no product code, tests, unrelated documents, or external systems changed.
- [ ] Use `READY` only when the baseline is usable for decisions and no material unknown lacks a safe handling rule; use `INCOMPLETE` for a useful artifact with consequential open drivers; use `BLOCKED` when scope, authority, or destination prevents safe creation.
- ## Output Contract
-
- ```markdown
- # System Design Baseline
+ ## Self-Check
- **Verdict:** READY | INCOMPLETE | BLOCKED
- **Artifact:** path
+ - [ ] **Reconcile before returning.** Check item-level evidence, requirement coverage, contradictions, scope, verdict, and applicable cleanup. Correct the report or authorized artifacts. Reuse valid evidence; do not automatically rescan the repository or rerun successful commands. Repeat checks only for relevant changes, failures, or unresolved evidence. Disclose remaining gaps.
- ## Established drivers
- - Prioritized architecture-driving scenarios
- - Applicable business, demand, quality, data, security, operational, economic, and evolution constraints
+ ## Output Contract
- ## Driver register
- | Theme | Parameter | Applicability | Criticality | Evidence status | Value or measure | Source and owner | Review trigger |
- |---|---|---|---|---|---|---|---|
+ Report in the user's language, in this order; retain all five fields and state each fact once. Small results may use one line per field; omit empty tables and do not copy linked artifacts:
- ## Changes made
- - Created or updated sections
- - Preserved conventions and related artifacts
+ 1. **Result:** Skill-specific verdict and supported outcome.
+ 2. **Scope:** Reviewed/changed scope, exclusions, baseline, and material assumptions.
+ 3. **Evidence:** Skill-specific fields below; distinguish facts, inferences, and unverified claims. Link artifacts; use tables when useful.
+ 4. **Verification:** Checks/results, unavailable evidence, and applicable cleanup/external state.
+ 5. **Completion:** `Checklist: X/Y complete`; `Incomplete: None` or each `UNPROVEN` item's reason, outcome impact, and exact next action; residual risks and required decisions.
- ## Residual risks
- Only constraints that can still reverse an architecture decision.
- ```
+ **Skill-specific evidence:** Artifact path, established drivers and prioritized quality scenarios, applicable constraints, and changed sections. The artifact owns the driver register: theme/parameter, applicability, criticality, evidence status, value/measure, source/owner, as-of date, and review trigger. Summarize only decision-changing gaps; do not copy the register into the response.