@rmrdeveloper/sideroom-pi 8.6.0 → 8.7.0

package/extensions/ask/index.ts

@@ -15,8 +15,8 @@ export const ASK_PROMPT_SNIPPET =
   'Ask the user one or more questions with a recommended option, in their language.';
 
 export const ASK_PROMPT_GUIDELINES = [
-  'When a non-trivial request is not yet a settled spec, follow the sideroom-grill skill before implementing; it owns the interview and drives sideroom_ask rounds. One sideroom_ask call is one batch; call it again for another round.',
-  'A decision the repository already settles consistently is a project fact: read the code and reuse it. A decision that materially affects architecture, dependencies, cost, security, operations, persistence, public contracts, or future change difficulty is an architectural decision: expose it through sideroom_ask before committing, with the practical consequences of each alternative and one recommendation that carries a one-line justification, never a list of technology names. If the repository shows two inconclusive patterns for the same kind of decision, name the inconsistency in the prompt. Everything else is a minor decision: take it yourself.',
+  'When a non-trivial request is not yet a settled spec, follow the sideroom-grill skill before implementing; it drives sideroom_ask rounds. One sideroom_ask call is one batch; call it again for another round.',
+  'A decision the repository already settles consistently is a project fact: read the code and reuse it. A decision that materially affects architecture, dependencies, cost, security, operations, persistence, public contracts, or future change difficulty is an architectural decision: never assume it; follow the sideroom-architecture skill and expose it through sideroom_ask before committing, with the practical consequences of each alternative and one recommendation carrying a one-line justification, never technology names. If the repository shows two inconclusive patterns for the same decision, name the inconsistency in the prompt. Everything else is a minor decision: take it yourself.',
   'Write sideroom_ask prompts, tab labels, option labels, and option descriptions in the language the user is speaking; keep ids and option values in English.',
   'sideroom_ask always adds Out of scope and a write-your-own answer; never send them yourself. A single-selection question needs recommendationIndex; a multiple-selection question needs recommendedIndices and never recommendationIndex.',
   'sideroom_ask only works in the interactive TUI; it errors in print, JSON, and RPC modes.',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rmrdeveloper/sideroom-pi",
-  "version": "8.6.0",
+  "version": "8.7.0",
   "description": "Pi coding-agent package that asks clarifying questions, shows a live todo board, enforces coding guidelines, and will not call it done while your checks are red.",
   "type": "module",
   "files": [

package/skills/sideroom-architecture/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: sideroom-architecture
+description: "Surface the architectural decisions a change forces so they are asked, not silently assumed. Use when a feature or change touches module boundaries, data ownership, integration contracts, failure behavior, quality attributes, operations, cost, lock-in, or reversibility, or when the user says the architecture is not settled. Do not use for a trivial or reversible change, a pure glossary lookup, or an already-closed spec."
+license: MIT
+metadata:
+  author: RMRdeveloper
+  version: "1.0"
+---
+
+# Sideroom architecture
+
+## Purpose
+
+An LLM's default failure is to assume the architecture and start typing. This
+skill forces the opposite: name the architectural decisions a change forces and
+ask the ones that matter, instead of picking them silently. It does not turn
+every change into an interrogation.
+
+## Activation Contract
+
+Load this skill when a change is about to commit an architectural decision:
+something that materially affects module boundaries, data ownership,
+integration contracts, failure behavior, quality attributes (latency,
+throughput, availability), operations, cost, lock-in, or the difficulty of
+changing course later. It runs under `sideroom-grill` for the architectural
+part of an interview, and on its own when only the architecture is open.
+
+Do not load it for a minor decision (reversible, no boundary or contract
+impact), or for a word conflict — that is `sideroom-domain-modeling`.
+
+## Hard Rules
+
+- Assume nothing architectural. When a change forces an architectural decision
+  the code does not already settle, expose it through `sideroom_ask` before
+  writing the code. Silent selection of an architectural default is the failure
+  this skill exists to prevent.
+- Pick the dimensions this decision actually touches; do not march the whole
+  catalog. Two sharp questions beat nine shallow ones. A dimension the change
+  does not touch is not asked.
+- Read the code first. A decision the repository already settles consistently
+  is a project fact: reuse it, never ask it. When the repository shows two
+  inconclusive patterns for the same kind of decision, name that inconsistency
+  in the prompt instead of picking one.
+- Quantify or decline. An architectural dimension does not close without a
+  number, a range, or an explicit `Out of scope` from the user. A decision
+  without a figure is a preference in disguise.
+- Every option of an architectural question carries a `description`: its
+  practical consequence, its cost, and the obligation it imposes. The label
+  names the choice; the description carries the trade-off. Never a one-word
+  technology label.
+- Present the decision as the current situation, the alternatives by their
+  practical consequences, and one recommendation with a one-line justification.
+  Never reduce it to technology names.
+- One open architectural dimension blocks implementation. `Out of scope` closes
+  a thread, is recorded, and is not re-asked.
+
+## Dimension catalog
+
+Reference, not a checklist. Pick only what the change touches; force a number or
+an explicit `Out of scope` on each one you pick.
+
+| Dimension | The question it forces |
+| --- | --- |
+| Boundaries | Which modules are in, which are out, which dependency direction is forbidden |
+| Data | What is the source of truth, who owns it, how the schema evolves and migrates |
+| Integration | Synchronous or asynchronous, backward compatibility, version window |
+| Quality attributes | Expected latency and volume, availability target — in figures |
+| Failure | What degrades, what retries, what must be idempotent |
+| Operations | How it deploys, how it rolls back, which signal warns it is going wrong |
+| Cost and lock-in | Operating cost, the cost of leaving the provider or dependency |
+| Ownership | Who maintains it, who responds when it breaks |
+| Reversibility | What reopens the decision, and how expensive undoing it is |
+
+## Execution Steps
+
+1. Read the code around the change. Settle every project fact from the
+   codebase, and note any inconsistent pattern to name in a prompt.
+2. List the architectural decisions the change forces. Drop the ones the code
+   already settles.
+3. For each remaining decision, pick the dimensions it touches and run one
+   `sideroom_ask` round: situation, alternatives by consequence, one
+   recommendation, each option with a `description`. Force a number or an
+   explicit `Out of scope`.
+4. Repeat rounds until no architectural dimension is open. Do not implement
+   with one open.
+5. Record an accepted decision as an ADR under `docs/adr/` only when it clears
+   the three `sideroom-domain-modeling` gates: hard to reverse, surprising
+   without context, the result of a real trade-off. The ADR names the rejected
+   alternatives and what reopens the decision.
+
+## Output Contract
+
+Before the first round: a one-line statement of what is built, what it touches,
+what is out. After the rounds: the architectural decisions closed with their
+figures, the dimensions marked out of scope, and any ADR written with its
+rejected alternatives and its revision trigger. No architectural default
+reaches the code without having been asked or read from the repository.
+
+## References
+
+- Driven by `sideroom-grill` for the architectural part of an interview; that
+  skill owns the interview, this one owns the architectural interrogation.
+- Hands qualifying decisions to `sideroom-domain-modeling` for the ADR
+  three-gate offer and records shared vocabulary through it.