Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-71-system-design-baseline-builder
Creates a project baseline of architecture drivers and constraints. Use before design or planning; not for target design, plan review, implementation, or architecture audit.
3 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 5 comparable cases; this report requires 8.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
We built a baseline requirements document for `services/ledger-sync`. We identified two critical architecture drivers (cross-region data sync consistency and max acceptable data loss RPO) that currently have no designated owner and no confirmed target values. What verdict must be assigned in Section 1 of the baseline summary?
| Checked | Without skill | With skill |
|---|---|---|
| Result verdict is set to INCOMPLETE when consequential drivers lack owners. | Missed | Passed |
| Completion section details unproven driver gaps and required next actions. | Passed | Passed |
The instructions your model reads when the skill loads.
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: 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.
| 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.
docs/architecture/system-design-baseline.md.APPLICABLE or NOT_APPLICABLE, with evidence for exclusions.DRIVER, SUPPORTING, or INFORMATIONAL.CONFIRMED, ASSUMED, or UNKNOWN.BLOCKED if the destination is ambiguous and choosing one could split project truth.test cases passed with the skill
More skills from the same source and nearby in the registry, with their headline benchmark lift.