contextcompass 2.15.0__py3-none-any.whl

contextcompass_cli/_package/agent_onboarding/default/design_engineer/README.md

@@ -0,0 +1,62 @@
+
+# Design Engineer Career
+
+Purpose
+- Design-engineer-specific onboarding deltas on top of the shared `general` baseline and the `engineer` implementation baseline.
+- Optimized for software/system design, architecture planning, and high-quality handoff to implementation.
+
+Scope rule
+- Keep only design-engineer-specific policy/behavior here.
+- Shared rules remain in:
+  - `agent_onboarding/default/general/` (process, ticketing, gates, certification)
+  - `agent_onboarding/default/engineer/` (implementation and engineering quality discipline)
+- Design Engineer extends `engineer` and must remain a delta layer:
+  no path overlap with `agent_onboarding/default/engineer/SKILLS.MD`.
+
+Design Engineer inventory
+- `agent_onboarding/default/design_engineer/SKILLS.MD`: design-engineer-specific read sequence.
+- `skills/architecture_contexts.md`: architecture/components source-of-truth policy.
+- `skills/src_architecture_instructions.md`: creation/maintenance mechanics for
+  `system_docs/src_architecture.md`.
+- `skills/src_components_instructions.md`: creation/maintenance mechanics for
+  `system_docs/src_components.md`.
+- `agent_onboarding/default/engineer/skills/src_graph_usage.md`: how to read
+  `system_docs/src_graph_index.md` and slice `system_docs/src_graph.md`.
+  Inherited from `engineer`; it does not live in this folder.
+- `agent_onboarding/default/engineer/skills/src_graph_generation.md`: how those
+  two files are produced by `tools/system_documents/python/`.
+- `agent_onboarding/default/engineer/skills/system_document_build.md`: authoring
+  format and index mechanics for the authored system documents. Inherited from
+  `engineer`; it does not live in this folder.
+- `skills/tests_architecture_instructions.md`: creation/maintenance mechanics
+  for `system_docs/tests_architecture.md`.
+- `skills/tests_components_instructions.md`: creation/maintenance mechanics for
+  `system_docs/tests_components.md`.
+- `skills/design_engineer_execution.md`: design execution discipline and artifact expectations.
+- `skills/requirements_to_architecture.md`: convert goals to requirements, constraints, and acceptance criteria.
+- `skills/system_design_method.md`: system design structure (components, data flows, failure modes).
+- `skills/decomposition_and_boundaries.md`: decomposition, boundaries, and coupling control.
+- `skills/api_and_interface_design.md`: interface/API design discipline (contracts, versioning, errors).
+- `skills/data_modeling.md`: schema and data modeling discipline.
+- `skills/architecture_tradeoffs.md`: tradeoff analysis and option evaluation.
+- `skills/adr_and_decision_hygiene.md`: ADR format, decision recording, and decision hygiene.
+- `skills/nonfunctional_requirements.md`: NFR design (performance, reliability, security, operability).
+- `skills/design_review_protocol.md`: review/checkpoint protocol and handoff to tickets.
+- `policies/design_quality_policy.md`: design artifact quality bar.
+- `policies/decision_record_policy.md`: ADR and decision-record gating.
+- `policies/design_review_policy.md`: review gate rules before implementation.
+- `behavioral_guidelines/design_engineer_workflow.md`: design task execution flow.
+- `behavioral_guidelines/design_validation_and_handoff.md`: validation and implementation handoff flow.
+- `examples/design_task_flow.md`: example design task flow.
+- `examples/adr_example.md`: ADR example template.
+
+Overlap rules
+- If a skill is already defined in `engineer` or `general`, reference it instead of duplicating.
+- Implementation tasks still follow engineer execution discipline:
+  - `agent_onboarding/default/engineer/skills/engineer_execution.md`
+  - `agent_onboarding/default/engineer/behavioral_guidelines/task_execution_and_validation.md`
+
+Unknowns Gate
+- Apply the canonical policy in
+  `agent_onboarding/default/general/skills/unknowns_gate_reference.md`.
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/SKILLS.MD

@@ -0,0 +1,74 @@
+
+# SKILLS.MD - design_engineer
+
+Purpose
+- Define required baseline design-engineer skills for the `design_engineer` role.
+- This role is optimized for designing software engineering projects with high-quality handoff.
+
+Inheritance
+- `INHERITS_SKILLS_FROM: agent_onboarding/default/engineer/SKILLS.MD`
+
+Skill classes (non-negotiable)
+- This role ADDS two classes of its own:
+  A) **Required baseline skills** (always required for onboarding/certification)
+  B) **On-demand design-context skills** (required only when the active task triggers them)
+- It also INHERITS the parent chain's classes, which include `engineer`'s
+  **Baseline system orientation** - `system_docs/system_docs_read_first.md`,
+  `src_architecture.md`, `src_architecture_index.md`, `src_components_index.md`.
+  Those are baseline for this role too. This section describes what this file adds;
+  it is not the complete list of what you must read.
+
+Rules
+- You MUST read **all** paths listed under **Required baseline skills** for this role
+  to be considered onboarded/certifiable as `design_engineer`, **plus** every
+  baseline section in the inherited chain.
+- You MUST NOT claim an on-demand skill was read unless:
+  1) a trigger condition was met, AND
+  2) you actually read it in full.
+- When a trigger condition is met, the on-demand skills become mandatory and MUST be
+  read **before** any work in that scope.
+
+Required baseline skills
+- `agent_onboarding/default/design_engineer/AGENTS.MD`
+- `agent_onboarding/default/design_engineer/WORKFLOWS.MD`
+- `agent_onboarding/default/design_engineer/skills/architecture_contexts.md`
+- `agent_onboarding/default/design_engineer/skills/patch_framework_design.md`
+- `agent_onboarding/default/design_engineer/skills/architecture_patch_contracts.md`
+- `agent_onboarding/default/design_engineer/skills/component_patch_contracts.md`
+- `agent_onboarding/default/design_engineer/skills/code_description_patch_contracts.md`
+- `agent_onboarding/default/design_engineer/skills/src_architecture_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/src_components_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/tests_architecture_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/tests_components_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/design_engineer_execution.md`
+- `agent_onboarding/default/design_engineer/skills/requirements_to_architecture.md`
+- `agent_onboarding/default/design_engineer/skills/system_design_method.md`
+- `agent_onboarding/default/design_engineer/skills/decomposition_and_boundaries.md`
+- `agent_onboarding/default/design_engineer/skills/api_and_interface_design.md`
+- `agent_onboarding/default/design_engineer/skills/data_modeling.md`
+- `agent_onboarding/default/design_engineer/skills/architecture_tradeoffs.md`
+- `agent_onboarding/default/design_engineer/skills/adr_and_decision_hygiene.md`
+- `agent_onboarding/default/design_engineer/skills/nonfunctional_requirements.md`
+- `agent_onboarding/default/design_engineer/skills/design_review_protocol.md`
+- `agent_onboarding/default/design_engineer/policies/design_quality_policy.md`
+- `agent_onboarding/default/design_engineer/policies/decision_record_policy.md`
+- `agent_onboarding/default/design_engineer/policies/design_review_policy.md`
+- `agent_onboarding/default/design_engineer/policies/system_document_quality_rubric.md`
+- `agent_onboarding/default/design_engineer/behavioral_guidelines/design_engineer_workflow.md`
+- `agent_onboarding/default/design_engineer/behavioral_guidelines/design_validation_and_handoff.md`
+- `agent_onboarding/default/design_engineer/examples/design_task_flow.md`
+- `agent_onboarding/default/design_engineer/examples/adr_example.md`
+
+On-demand design-context skills
+Trigger conditions (any one makes these mandatory):
+- The user asks for a full system/software design, architecture plan, or component boundary redesign.
+- The task requires a design that changes an existing public contract, API, schema, or lifecycle boundary.
+- The task requires creating/updating `system_docs/*` or making P0/P1 claims about architecture/components/tests.
+
+If triggered:
+- Apply the `engineer` on-demand system-context readset. The inheritance
+  header at the top of this file already puts it in the resolved chain, so
+  the paths are declared in the parent file and are not repeated here. The
+  triggers above are additional to the parent's, not a replacement.
+- Do not proceed with architecture claims or edits until that on-demand readset is satisfied.
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/WORKFLOWS.MD

@@ -0,0 +1,15 @@
+# WORKFLOWS.MD - design_engineer
+
+Purpose
+- Define role-local workflow availability for the `design_engineer` role.
+
+Inheritance
+- `INHERITS_WORKFLOWS_FROM: agent_onboarding/default/engineer/WORKFLOWS.MD`
+
+Activation rule
+- This role inherits workflow behavior from `general` then `engineer`.
+- Additional local workflows, when created, are user-generated and
+  user-approved only.
+
+Active workflows
+- none

contextcompass_cli/_package/agent_onboarding/default/design_engineer/behavioral_guidelines/design_engineer_workflow.md

@@ -0,0 +1,25 @@
+
+# design_engineer_workflow
+
+Purpose
+- Describe the expected execution flow for design-engineer tasks.
+
+Story steps
+1) Confirm the goal and constraints.
+   - Ask clarifying questions before producing architecture.
+2) Identify current state.
+   - Read tickets, `system_docs/*`, and code symbols as needed.
+3) Produce a design draft.
+   - Include explicit options, tradeoffs, and UNKNOWNs.
+4) Run a design review checkpoint.
+   - Request approval when required.
+5) Produce handoff artifacts.
+   - Ticketize the work and define validation/rollout.
+6) Transition to implementation (if requested).
+   - Follow `engineer` execution discipline.
+
+References
+- `agent_onboarding/default/design_engineer/behavioral_guidelines/design_validation_and_handoff.md`
+- `agent_onboarding/default/engineer/skills/engineer_execution.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/behavioral_guidelines/design_validation_and_handoff.md

@@ -0,0 +1,25 @@
+
+# design_validation_and_handoff
+
+Purpose
+- Define what "validated design" means and how to hand off to implementation.
+
+Validation checklist
+- Interfaces are explicit (API/schema/event contracts).
+- Failure modes are identified with mitigations.
+- Test strategy is explicit and covers core invariants.
+- Rollout strategy is explicit and includes backout.
+- Observability hooks are defined for the new behavior.
+- Tickets are broken down into actionable units with dependencies.
+
+Handoff rules
+- If implementation is requested:
+  - identify the minimal set of files/modules to change,
+  - hand off to `engineer` execution discipline,
+  - ensure each ticket has acceptance criteria and validation steps.
+
+References
+- `agent_onboarding/default/general/skills/ticketing_skill_contract.md`
+- `agent_onboarding/default/engineer/behavioral_guidelines/task_execution_and_validation.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/examples/adr_example.md

@@ -0,0 +1,40 @@
+
+# ADR Example (Template)
+
+Title
+- ADR-000: <short decision name>
+
+Status
+- proposed | accepted | superseded
+
+Context
+- What problem are we solving?
+- What constraints exist?
+- What evidence links to current state?
+
+Decision
+- What are we doing?
+
+Options considered
+- Option A:
+- Option B:
+- Option C (optional):
+
+Tradeoffs
+- Why this option wins
+- What we give up
+
+Consequences
+- What changes for implementers and operators?
+- Compatibility and migration impacts
+
+Validation
+- Tests and checks
+- Observability and rollout plan
+
+Links
+- Ticket:
+- Code:
+- Docs:
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/examples/design_task_flow.md

@@ -0,0 +1,33 @@
+
+# Design Engineer Example: Design Task Flow
+
+Context
+- The user asks for a new feature that requires architectural changes.
+- Goal: produce an implementable design and break work into tickets.
+
+Example flow
+1) Clarify goal, constraints, and compatibility requirements.
+2) Read current system docs or code to understand boundaries.
+3) Draft design:
+   - components + responsibilities,
+   - interfaces + contracts,
+   - data model impacts,
+   - failure modes + mitigations,
+   - test strategy,
+   - rollout/observability.
+4) Present options + tradeoffs and recommend one.
+5) Request design approval checkpoint (if required).
+6) Ticketize:
+   - create story/task breakdown with dependencies and acceptance criteria.
+7) Hand off to implementation plan (if requested).
+
+Expected output format (sample)
+- Questions:
+- Current state (evidence):
+- Design draft:
+- Options + tradeoffs:
+- Recommendation:
+- Approval needed:
+- Ticket breakdown:
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/policies/decision_record_policy.md

@@ -0,0 +1,23 @@
+
+# decision_record_policy
+
+Purpose
+- Require durable decision recording for high-impact architecture/design changes.
+
+Policy
+- When a design decision changes:
+  - public APIs,
+  - schemas/data models,
+  - component boundaries/ownership,
+  - lifecycle invariants,
+  - cross-cutting behavior (auth/retries/caching/observability),
+  you MUST record the decision as an ADR or ticket-linked decision artifact.
+- The decision record must include:
+  - context, decision, options, tradeoffs, consequences, validation, rollout.
+- Do not proceed to implementation until decision recording is complete
+  when the change is hard to reverse.
+
+References
+- `agent_onboarding/default/design_engineer/skills/adr_and_decision_hygiene.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/policies/design_quality_policy.md

@@ -0,0 +1,30 @@
+
+# design_quality_policy
+
+Purpose
+- Establish the quality bar for design artifacts produced by `design_engineer`.
+
+Policy
+- Design output must be implementable and testable, not conceptual only.
+- For any non-trivial design, include:
+  - goal/non-goals,
+  - constraints,
+  - assumptions + UNKNOWNs,
+  - options + tradeoffs,
+  - architecture + interfaces,
+  - NFR coverage,
+  - test/validation plan,
+  - rollout/observability plan,
+  - ticketization plan.
+- Use evidence pointers for current-state claims.
+- Do not hide risks: call them out with severity and proposed mitigations.
+
+Unknowns Gate
+- Apply the canonical policy in
+  `agent_onboarding/default/general/skills/unknowns_gate_reference.md`.
+
+References
+- `agent_onboarding/default/design_engineer/skills/system_design_method.md`
+- `agent_onboarding/default/design_engineer/skills/architecture_tradeoffs.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/policies/design_review_policy.md

@@ -0,0 +1,22 @@
+
+# design_review_policy
+
+Purpose
+- Enforce a design-review checkpoint before implementation for high-impact changes.
+
+Policy
+A design review checkpoint is mandatory when:
+- the design changes public contracts, schemas, or major component boundaries, OR
+- the design introduces non-trivial operational risk, OR
+- the user requested "design first" explicitly.
+
+Checkpoint rule
+- Provide a structured design summary + open questions.
+- Request explicit approval before implementation.
+- Approval must be recorded (in the response and ideally in the ticket notes).
+
+References
+- `agent_onboarding/default/design_engineer/skills/design_review_protocol.md`
+- `agent_onboarding/default/general/skills/ticket_microcycle.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/policies/system_document_quality_rubric.md

@@ -0,0 +1,236 @@
+
+
+# system_document_quality_rubric
+
+Purpose
+- Score the four system documents on whether they *say* anything, not merely
+  whether their required fields exist.
+- Give downstream work a threshold it can refuse on.
+
+Scope
+- Applies to `system_docs/src_architecture.md`, `src_components.md`,
+  `tests_architecture.md`, and `tests_components.md`, whenever one is created,
+  recomposed, or reviewed.
+- One rubric, four profiles. The criteria and weights below are shared; only the
+  anchors change per document. Two rubric idioms in one repository drift apart,
+  and then neither is trusted.
+- Vocabulary is deliberately the same as
+  `agent_onboarding/default/engineer/policies/ctx_autonomy_rubric.md`: weighted
+  criteria, 0/3/5 anchors, 0-100 bands, a refusal threshold. Learn it once.
+
+## The hole this fills
+
+Every other gate in this system is binary. The Quality Gate asks whether
+`Concurrency/Threading` is present. It is present, so the gate passes:
+
+> Concurrency/Threading: Uses a lock.
+
+That scores identically to:
+
+> Concurrency/Threading: Single writer lock held across the flush; readers take
+> the snapshot instead. Acquired before the queue lock, never after - the
+> reverse order deadlocked under concurrent flush and drain.
+
+Both satisfy the contract. Only one is worth reading. Structural gates verify a
+field exists; nothing until now verified it carries information. That gap is the
+difference between a document that satisfies a contract and one a reader can act
+on after compaction.
+
+This rubric does not replace the Quality Gate or the Content Preservation Gate.
+Those are pass/fail and come first. A document that fails either is not scored -
+it is fixed.
+
+## Ranking model (0-100)
+
+Score each criterion 0-5, then compute `sum((score / 5) * weight)`.
+
+| criterion | weight |
+| --- | --- |
+| Fidelity to source | 30 |
+| Contract completeness | 15 |
+| Depth | 15 |
+| Addressability | 15 |
+| Join integrity | 15 |
+| Mirror agreement | 10 |
+
+Fidelity carries double weight because every other criterion is recoverable by
+editing. A confidently wrong claim is not - it propagates into decisions before
+anyone tests it.
+
+## Shared anchors (0/3/5)
+
+**Fidelity to source**
+- 5: every non-obvious claim carries a file or symbol reference a reader can
+  open. Claims match what is there.
+- 3: mostly accurate; some claims plausible but uncited.
+- 0: claims contradicted by the sources, or inferred from names alone. Naming
+  inference is the specific failure - `*_manager` does not establish that a
+  thing manages anything.
+
+**Contract completeness**
+- 5: every required section and field present, in contract order, and each one
+  populated with content specific to this subject.
+- 3: all present, one or more hollow - a field restating its own name.
+- 0: required sections missing, or reordered so a reader cannot navigate by
+  contract.
+
+Scoring note: a field deliberately marked not-applicable, with the reason, is a
+5. A field left blank is a 0. They look identical to a reader, and only one of
+them is a decision.
+
+**Depth**
+- 5: names the mechanism, the ordering it depends on, and the failure it
+  prevents. Testable as written.
+- 3: correct but one clause; a reader knows *that* something happens, not how or
+  why it must.
+- 0: aspirational or decorative. "Handles errors gracefully."
+
+**Addressability**
+- 5: exactly one H1; navigable units at consistent depth; every section name
+  unique; no wrapped headings; no container heading usable as a read target.
+- 3: unique and unwrapped, but a container heading exists that a reader could
+  select by mistake.
+- 0: duplicate section names, or a heading spanning two physical lines. Both
+  return content on a slice - the wrong content, confidently.
+
+**Join integrity**
+- 5: every cited path resolves, and every range was measured on this pass.
+- 3: paths resolve; ranges carried forward from a previous pass without
+  remeasuring.
+- 0: unresolvable citations, a stale index, or ranges that parse and point
+  somewhere else.
+
+The join differs by side and the difference is not cosmetic - see the profiles.
+
+**Mirror agreement**
+- 5: the document pairs with its counterpart - same section contract shape, same
+  terms for the same things, no boundary described one way here and another way
+  there.
+- 3: structurally aligned, terminology drifted.
+- 0: the pair contradict each other, or one is current and the other describes a
+  boundary that moved.
+
+`system_document_build.md` already declares these are mirrors and that
+divergence *is* the defect. That makes this scoreable in both directions: when a
+pair disagree, both documents lose the points, because the rubric cannot tell
+which one is wrong and neither can a reader.
+
+## Score bands
+
+- 90-100: A - trusted as an input to design decisions
+- 75-89: B - usable
+- 60-74: C - usable, schedule a refresh before high-risk work
+- 40-59: D - weak
+- 0-39: F - unusable
+
+Actions:
+- **< 60: refuse downstream work that depends on this document.** Refresh it
+  first. Do not synthesize a higher-level claim from it, and do not cite it as
+  evidence in a ticket.
+- 60-74: proceed if necessary, and record the score and the weak criterion in
+  the active ticket so the next reader inherits the caveat rather than the
+  false confidence.
+- 75+: proceed.
+
+## Profiles
+
+### src_architecture
+
+- **Navigable unit**: the H2 concern.
+- **Depth** means boundaries, invariants and failure paths stated concretely
+  enough to test. A boundary claim scores 5 when a reader can name what crosses
+  it and what is refused.
+- **Join integrity** is the C1 map: cited paths resolve into the graph index,
+  ranges measured.
+- **Mirror**: pairs with `tests_architecture.md`.
+
+### src_components
+
+- **Navigable unit**: the H3 component entry.
+- **Depth is assessed per entry across the twelve fields**, then averaged - not
+  judged from the document as a whole. One excellent entry does not lift eleven
+  hollow ones, and a document-level impression is exactly how hollow entries
+  survive review.
+- **Join integrity** is `Key Files (C1)`, verified with the recipe in
+  `src_components_instructions.md`, not assumed.
+- **Mirror**: pairs with `tests_components.md`.
+
+### tests_architecture
+
+Mirror of the source architecture profile, plus one criterion that overrides
+Fidelity when it fails:
+
+- **Does it describe the test system's own boundaries, layers and harness
+  ownership** - or does it restate source architecture in test vocabulary? A
+  document whose diagram could be dropped into `src_architecture.md` unchanged
+  is describing the wrong system, and scores 0 on Fidelity regardless of how
+  accurate its sentences are. It is accurate about the wrong subject.
+
+- **Join integrity is weaker here, and knowing that is the point.** The graph is
+  built from the source tree, so source-side citations are checked against
+  `src_graph_index.md` for free. This document cites test paths, which appear in
+  no graph. Nothing will tell you a path here has rotted. Score 5 only when
+  existence was checked and ranges were remeasured on this pass; carried-forward
+  ranges cap this criterion at 3.
+
+### tests_components
+
+Mirror of the source components profile, plus:
+
+- **Does each test surface name what it validates and who owns it?** An entry
+  that describes a harness without naming the behaviour it protects scores at
+  most 3 on Depth. "Runs the suite" is not a responsibility.
+- **`Key Files (C1)` cites test paths**, and the join is existence plus
+  remeasurement, per `tests_components_instructions.md`.
+
+## Weight the test side equally, and expect it to score lower
+
+The test profiles carry the same weights as the source profiles. Not because the
+two halves are equally mature - they are usually not - but because weighting the
+test side lower encodes the neglect instead of measuring it.
+
+Expect lower scores at first. In the repository this rubric was developed
+against, both source indexes had been maintained and both test indexes were
+stale. That asymmetry is the normal case: the test-side documents are written
+once, during a push, and then nothing forces them forward, because no build
+breaks when they rot.
+
+A rubric that scores all four surfaces makes that visible on every pass rather
+than letting it sit. The first run against an established repository should be
+read as a baseline, not an indictment - what matters is the second run.
+
+## Scoring discipline
+
+- **Score against the document, not your memory of building it.** Re-read it.
+- **Cite what you scored.** A criterion scored below 5 needs a `path:line`
+  example of the weakness, otherwise the score is unactionable and the next
+  reader re-derives it from scratch.
+- **Score the whole document once, not each section separately**, except where a
+  profile says otherwise - the components profiles average per entry precisely
+  because whole-document impressions hide hollow entries.
+- **Do not score your own work as the last step of building it.** The build pass
+  and the scoring pass want opposite postures. If the same agent must do both,
+  score from the file on disk after the index rebuild, never from the draft in
+  context.
+- Record the total, the per-criterion scores, and the band in the active ticket.
+  A score with no record is a score nobody can challenge.
+
+## Anti-patterns (reject)
+
+- Scoring 5 on Fidelity because nothing looked wrong. Absence of a caught error
+  is not evidence of accuracy.
+- Rounding a document up to clear the 60 threshold so work can continue. The
+  threshold exists to stop exactly that.
+- Treating a high Contract completeness score as a proxy for quality. It is 15
+  points of 100, and it is the one criterion a structural gate already covers.
+- Averaging the four documents into a single repository score. They are read
+  separately, they rot separately, and a strong source half will mask a
+  worthless test half.
+
+## References
+- `agent_onboarding/default/engineer/policies/ctx_autonomy_rubric.md`
+- `agent_onboarding/default/engineer/skills/system_document_build.md`
+- `agent_onboarding/default/design_engineer/skills/src_architecture_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/src_components_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/tests_architecture_instructions.md`
+- `agent_onboarding/default/design_engineer/skills/tests_components_instructions.md`

contextcompass_cli/_package/agent_onboarding/default/design_engineer/skills/adr_and_decision_hygiene.md

@@ -0,0 +1,38 @@
+
+# adr_and_decision_hygiene
+
+Purpose
+- Keep architecture decisions durable, searchable, and explainable.
+- Prevent re-litigating decisions after compaction/handoffs.
+
+When to write a decision record (ADR or ticket-linked decision)
+- Any change to:
+  - public API contracts,
+  - persistent schemas/data models,
+  - component boundaries and ownership,
+  - lifecycle invariants and cleanup behavior,
+  - cross-cutting behavior (auth, caching, retries, observability).
+- Any decision that is hard to reverse.
+
+ADR template (minimal)
+- Title:
+- Status: proposed | accepted | superseded
+- Context:
+- Decision:
+- Options considered:
+- Tradeoffs:
+- Consequences:
+- Rollout/migration:
+- Test/validation:
+- Links: tickets, code, docs
+
+Rules
+- One ADR = one decision.
+- Link ADR to the ticket that implements it.
+- If superseded, link to the newer ADR and keep the old one for history.
+
+References
+- `agent_onboarding/default/design_engineer/policies/decision_record_policy.md`
+- `agent_onboarding/default/design_engineer/examples/adr_example.md`
+
+

contextcompass_cli/_package/agent_onboarding/default/design_engineer/skills/api_and_interface_design.md

@@ -0,0 +1,36 @@
+
+# api_and_interface_design
+
+Purpose
+- Define interface design discipline for APIs and internal contracts.
+- Prevent breaking changes and ambiguous error behavior.
+
+Core rules
+- Every interface must define:
+  - inputs (types, validation),
+  - outputs (types, semantics),
+  - error behavior (codes, retries, invariants),
+  - versioning/compatibility strategy.
+- Prefer explicit, stable, boring contracts over "smart" implicit behavior.
+- If idempotency matters, define it explicitly.
+- If pagination matters, define it explicitly.
+- If timeouts/retries matter, define them explicitly.
+
+Error semantics checklist
+- What errors are user-correctable vs system errors?
+- What errors are retryable and under what conditions?
+- Are errors stable enough to be relied on by callers?
+- Do errors leak secrets or sensitive details?
+
+Versioning/compatibility checklist
+- Backward compatibility window
+- Deprecation mechanism
+- Migration strategy
+- Rollout plan that supports mixed versions
+
+References
+- `agent_onboarding/default/design_engineer/skills/adr_and_decision_hygiene.md`
+- `agent_onboarding/default/design_engineer/skills/nonfunctional_requirements.md`
+- `agent_onboarding/default/engineer/skills/documentation_standards.md`
+
+