quantumquirkxyz Contract
- Input: problem description and inputs defined by the skill body.
- Output: Markdown artifact with completed process steps.
- Side effects: none.
- Dependencies: none.
- Stop condition: all process steps executed; artifact saved with required sections.
- Risk: low.
- Boundary: produces reasoning artifact only; no system changes.
Architecture Decisions
Document and evaluate a software architecture decision using the ADR format — context, decision, consequences — with an explicit trade-off review.
When to use
- The user needs to record or review a major architecture choice.
- A decision has long-lasting impact (language, framework, database model, deployment model).
- A team needs a durable explanation of why a system is shaped a certain way.
Process
- Title — short, unique identifier.
- Status — proposed / accepted / deprecated / superseded.
- Context — what problem, constraints, and forces led to this decision? Use leading words.
- Decision — what we decided, with the decision stated as positive (not negative) behaviour.
- Consequences — positive, negative, and neutral. Explicit trade-offs.
- Alternatives considered — with brief evaluation of each.
- Review — adversarial pass: what assumption could turn wrong? What is the rollback / change path if the decision is superseded?
- Deliver — artifact: ADR document with all sections present; no vague language.