@rosetears/aili-pi 0.1.0

package/skills/requirements-grilling/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Addy Osmani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/requirements-grilling/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/NOTICE.md

@@ -0,0 +1,9 @@
+# Upstream reference notice
+
+- Repository: `https://github.com/addyosmani/agent-skills`
+- Commit: `6bcfeb9dae52b11eaad23511acc165109746dbc3`
+- Copyright: Copyright (c) 2025 Addy Osmani
+- License: root MIT `LICENSE` copied beside this notice
+- Mapping: `skills/interview-me/SKILL.md` → `interview-me/SKILL.upstream.md`
+
+The pinned closure is inert provenance/reference data, not a runnable skill, command, approval, integrity authority, or permission grant. Canonical behavior remains `.agents/skills/requirements-grilling/SKILL.md`.

package/skills/requirements-grilling/references/upstream/addyosmani-agent-skills/6bcfeb9dae52b11eaad23511acc165109746dbc3/interview-me/SKILL.upstream.md

@@ -0,0 +1,225 @@
+---
+name: interview-me
+description: Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
+---
+
+# Interview Me
+
+## Overview
+
+What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.
+
+The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
+
+This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven-development` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
+
+## When to Use
+
+Apply this skill when:
+
+- The ask is missing at least one of: **who** the user is, **why** they want it, what **success** looks like, what the binding **constraint** is
+- The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
+- You're tempted to start with assumptions you haven't surfaced
+- The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
+- The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"
+
+**When NOT to use:**
+
+- The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
+- The user has explicitly asked for speed over verification
+- Pure information requests ("how does X work?", "what does this code do?")
+- Mechanical operations (renames, formats, file moves)
+- You already have ≥95% confidence; re-read the stop condition below before assuming you don't
+
+## Loading Constraints
+
+This skill needs a live, responsive user. **Do not invoke in non-interactive contexts** like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.
+
+## The Process
+
+### Step 1: Hypothesize, with a confidence number
+
+Before asking anything, write down your current best read of what the user wants in **one sentence**, plus an honest confidence number (0–100%):
+
+```
+HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
+CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like
+```
+
+The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.
+
+When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal.
+
+### Step 2: Ask one question at a time, each with a guess attached
+
+Format:
+
+```
+Q: <one focused question>
+GUESS: <your hypothesis for the answer, with the reasoning that produced it>
+```
+
+Wait for the user to react before asking the next question.
+
+**Why one at a time, not a batch:**
+
+- The user can't react to your hypotheses if you bury them in a list
+- Batches encourage skim-reading and surface answers
+- The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
+- The user's energy for thinking carefully is finite; spend it one question at a time
+
+**Why attach a guess:**
+
+- The user reacts faster to a wrong guess than they generate an answer from scratch
+- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
+- It surfaces *your* assumptions, which is what the interview is meant to expose
+
+The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
+
+### Step 3: Listen for "want vs. should want"
+
+The most dangerous answers are the ones where the user says what a thoughtful answer *sounds like* rather than what they actually want. Watch for:
+
+- Answers that pattern-match best-practice talk ("I want it to be scalable", "clean architecture") without specifics
+- Answers that defer to convention ("the way most apps do it", "the standard approach")
+- Phrases like "I should probably…", "I think I'm supposed to…", "good engineering practice says…"
+- Buzzwords as goals — when "modern", "scalable", "robust" are the answer instead of a specific outcome
+
+When you hear these, the question to ask is:
+
+> *"If you didn't have to justify this to anyone, what would you actually want?"*
+
+That single question often does more work than the previous five.
+
+### Step 4: Restate intent in the user's own words
+
+When your confidence is high, write back what you now think the user wants. Keep it tight (5–8 lines), use their language where possible, and structure it so the user can confirm or correct line by line:
+
+```
+Here's what I now think you want:
+
+- Outcome:      <one line>
+- User:         <one line — who benefits>
+- Why now:      <one line — what changed>
+- Success:      <one line — how we know it worked>
+- Constraint:   <one line — the binding limit>
+- Out of scope: <one line — what we're explicitly not doing>
+
+Yes / no / refine?
+```
+
+Including "Out of scope" is non-negotiable. Half of misalignment is silent disagreement about what is *not* being built.
+
+### Step 5: Confirm — explicit yes, not "whatever you think"
+
+The gate is an explicit "yes." The following are **not** yes:
+
+- "Whatever you think is best." → The user is delegating, which means they don't have 95% confidence either. Re-ask with two concrete options framed as a choice.
+- "Sounds good." → Ambiguous. Ask: "Anything you'd refine?" Silence isn't confirmation.
+- "Sure, let's go." → Often a polite exit, not an endorsement. Same follow-up.
+- Silence followed by "okay let's start." → The user has given up on the interview, not converged. Stop and ask whether you've missed something.
+
+If they correct you, fold the correction in and restate. Loop until you get an explicit yes.
+
+### The 95% Confidence Stop
+
+You're done when you can answer yes to this:
+
+> *Can I predict the user's reaction to the next three questions I would ask?*
+
+If yes, you have shared understanding. Stop interviewing and produce the restate. If no, you're not done; ask the next question.
+
+This is a checkable test, not a vibe. It also has a floor: if you've gone several rounds and still can't predict, that's information about the ask, not a reason to keep grinding. Stop and tell the user: "I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?"
+
+## Output
+
+The output of this skill is a **confirmed statement of intent**: the restate from Step 4, with an explicit yes from Step 5. That's the deliverable. Specs, plans, and task lists are downstream; they consume the intent this skill produces.
+
+If the user wants the intent to persist (a multi-session project, a handoff to another collaborator), offer to save it to `docs/intent/[topic].md`. Only save if they confirm.
+
+## Example
+
+A short before-and-after.
+
+**Without `interview-me`:**
+
+```
+User:  build me a dashboard for our metrics
+Agent: <starts proposing chart libraries and layouts>
+```
+
+The agent has assumed: who it's for, what metrics, what "for our team" means, what success looks like. None of these are stated. Every assumption is a place the user can later say "that's not what I meant."
+
+**With `interview-me`:**
+
+```
+User: build me a dashboard for our metrics
+
+Agent:
+HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" came to mind because that's the conventional answer.
+CONFIDENCE: ~30% — missing: who it's for, what "metrics" are, and what success looks like
+
+Q:     When you say "how are we doing?", who's asking — you alone, the engineering team in standup, or up the chain (e.g., your manager, an exec, a board)?
+GUESS: engineering team in standup, because "we" usually scopes that way and standups are where this question gets asked. If it's for execs the metrics and the framing change a lot.
+
+User: It's actually for me. I keep losing track of which experiments are running and what their early signal looks like.
+
+Agent:
+Updated read: not a team dashboard at all. It's a personal experiment tracker. Confidence: ~60% — still missing: what "early signal" means and what done looks like.
+
+Q:     Is the gap that you don't know which experiments exist, or that you can't see their results in one place?
+GUESS: the second one. You have a list of experiments somewhere, but their results live in five different tools, and reconciling them by hand is what you're tired of.
+
+User: First one actually. I literally don't have a list. They're spread across different docs.
+
+Agent: <continues>
+```
+
+Two questions in, the agent has discovered the actual ask isn't "a dashboard." It's "a list." Different artifact, different scope, different work. The dashboard would have been wrong.
+
+## Interaction with Other Skills
+
+- **`idea-refine`**: downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to `idea-refine` to generate variations against the now-explicit intent.
+- **`spec-driven-development`**: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to `spec-driven-development` to write it down.
+- **`planning-and-task-breakdown`**: two hops downstream of this skill (after the spec).
+- **`doubt-driven-development`**: opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
+- **`source-driven-development`**: orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. They don't compete.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The ask is clear enough" | If you can't write the user's desired outcome in one sentence right now, the ask isn't clear. Run Step 1 before deciding. |
+| "Asking too many questions wastes their time" | Time wasted by 4–6 targeted questions is small. Time wasted by building the wrong thing is enormous, and the user is the one bearing that cost. |
+| "I'll figure it out as I build" | Switching costs after code exists are 10x what they are now. Discovery during implementation is rework. |
+| "They said 'whatever you think,' so I should just decide" | "Whatever you think" is delegation, not decision. Re-ask with two concrete options as a choice. |
+| "I should give them several options to pick from" | Options work when the user knows what they want and is choosing between trade-offs. They don't know what they want yet. Listing options widens the search; asking narrows it. |
+| "If I attach my guess, I'm leading them" | Leading is the point. Reacting is faster than generating from scratch. The risk is sycophancy, not leading; mitigate by being visibly willing to be wrong. |
+| "We've talked enough, I get it" | Test it: can you predict their reaction to the next three questions? If not, you don't get it yet. |
+| "The user said yes, we're done" | If the yes followed a vague restate or an open-ended "sounds good," the yes is hollow. Restate concretely and re-confirm. |
+
+## Red Flags
+
+- Three or more questions in a single message: that's batching, not interviewing
+- A question without your hypothesis attached: that's surveying, not committing
+- Accepting "whatever you think is best" as a terminal answer
+- Producing a spec, plan, or task list before the user has explicitly confirmed your restate
+- Questions framed as "what would be best practice?" instead of "what do you actually want?"
+- The user gives a sophistication-signaling answer ("scalable", "clean", "modern") and you accept it without probing whether it's what they actually want
+- Three or more rounds without your confidence visibly rising: you're asking the wrong questions, step back and reframe
+- A confidence number below ~70% with no reason attached: the user can't help close the gap if they don't know what's missing
+- Saving the intent doc before the user has confirmed (the doc itself implies a yes the user didn't give)
+- Skipping the "Out of scope" line in the restate (silent disagreement about non-goals is half of misalignment)
+
+## Verification
+
+After applying interview-me:
+
+- [ ] An explicit hypothesis with a confidence number was stated in the first turn
+- [ ] Every confidence number below ~70% was accompanied by a one-line reason (what's still unresolved or missing)
+- [ ] Questions were asked one at a time, each with the agent's guess attached
+- [ ] At least one "what would you actually want if you didn't have to justify it?" probe ran when the user gave a sophistication-signaling or convention-signaling answer
+- [ ] A concrete restate (Outcome / User / Why now / Success / Constraint / Out of scope) was written back to the user
+- [ ] The user confirmed the restate with an explicit yes (not "whatever you think," not "sounds good," not silence)
+- [ ] At the stop point, the agent could predict reactions to the next three questions it would ask
+- [ ] Any handoff to a downstream skill (`idea-refine`, `spec-driven-development`) was framed in terms of the confirmed intent, not the original underspecified ask

package/skills/requirements-grilling/references/upstream/mattpocock-skills/9603c1cc8118d08bc1b3bf34cf714f62178dea3b/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/requirements-grilling/references/upstream/mattpocock-skills/9603c1cc8118d08bc1b3bf34cf714f62178dea3b/NOTICE.md

@@ -0,0 +1,12 @@
+# Upstream reference notice
+
+- Repository: `https://github.com/mattpocock/skills`
+- Commit: `9603c1cc8118d08bc1b3bf34cf714f62178dea3b`
+- Copyright: Copyright (c) 2026 Matt Pocock
+- License: root MIT `LICENSE` copied beside this notice
+- Mappings:
+  - `skills/productivity/grill-me/SKILL.md` → `grill-me/SKILL.upstream.md`
+  - `skills/productivity/grilling/SKILL.md` → `grilling/SKILL.upstream.md`
+  - `skills/in-progress/batch-grill-me/SKILL.md` → `batch-grill-me/SKILL.upstream.md`
+
+The pinned closure is inert provenance/reference data, not a runnable skill, command, approval, integrity authority, or permission grant. Upstream `batch-grill-me` is in progress; canonical behavior remains `.agents/skills/requirements-grilling/SKILL.md` with AILI routing, artifact, evidence, and approval boundaries.

package/skills/requirements-grilling/references/upstream/mattpocock-skills/9603c1cc8118d08bc1b3bf34cf714f62178dea3b/batch-grill-me/SKILL.upstream.md

@@ -0,0 +1,15 @@
+---
+name: batch-grill-me
+description: A relentless interview that asks every frontier question at once, round by round.
+disable-model-invocation: true
+---
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+
+Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask *now* without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+
+Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a *later* round, not this one.
+
+Finding *facts* is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The *decisions* are the user's — put each to them and wait.
+
+The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

package/skills/requirements-grilling/references/upstream/mattpocock-skills/9603c1cc8118d08bc1b3bf34cf714f62178dea3b/grill-me/SKILL.upstream.md

@@ -0,0 +1,7 @@
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session.

package/skills/requirements-grilling/references/upstream/mattpocock-skills/9603c1cc8118d08bc1b3bf34cf714f62178dea3b/grilling/SKILL.upstream.md

@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not act on it until I confirm we have reached a shared understanding.

package/skills/review-pipeline/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: review-pipeline
+description: Optional focused post-implementation review routing. Use only when the user requests review or the changed surface has a clear specialist evidence need that direct diff inspection and the smallest relevant check cannot cover. Never creates an automatic review swarm.
+---
+
+# Review Pipeline
+
+## Goal
+
+Obtain the minimum additional review evidence needed for a specific risk.
+
+## Trigger
+
+Use only when:
+
+- the user asks for review; or
+- a specialist capability is required for a concrete unresolved risk.
+
+Direct ROSE diff inspection and the smallest relevant check are the default. Multi-file work alone does not trigger this skill.
+
+Near misses: implementation completion, SHIP wording, a pending merge, test failures, or broad quality concerns without one review question do not trigger routing. `code-review-and-quality` may be the primary loop for an explicit direct review; use this pipeline only when the current intent is specifically specialist review routing.
+
+ROSE/`aili-delivery-flow` owns lifecycle state, approvals, repairs, verification, and final judgment. This skill runs one bounded routing pass and does not invoke another process skill; it returns any missing capability or material delta to ROSE. Canonical approval and claim-matched verification rules win.
+
+## Method
+
+1. Name the unresolved review question.
+2. Resolve one repository/cwd and applicable target rules. For A33, reference one current `WT-001` context, keep artifacts in the owning repository, disclose the shared-trust soft boundary, and do not scan the host broadly.
+3. Choose at most one auxiliary specialist capability after the proactive delegation scan. Dispatch when its Task trigger is met. Default concurrency is at most two but is not a hard cap; larger bounded fan-out requires independent non-overlapping contexts, concrete benefit, suitable owners, and an explicit join plan.
+4. Send the compact packet from `subagent-task-packet.md` and require the canonical result/finding envelope in `subagent-result.md`.
+5. Inspect their evidence and resolve only the named question without voting.
+6. If a blocking issue is fixed, run one targeted recheck. Stop after that and report any remaining blocker.
+
+Do not automatically fan out code, test, security, coverage, AI, silent-failure, convergence, browser, or E2E lanes. Do not create a fixed multi-cycle repair loop.
+
+## Result
+
+Report the reviewed scope, evidence, blocking findings, skipped specialist checks, freshness, and remaining `Unverified` risks. ROSE owns the final judgment. A33 results reference rather than duplicate or rebind WT identity, keys, approvals, Git state, rules, or command/cwd.

package/skills/rose-memory/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: rose-memory
+description: Use the legacy/pre-runtime ROSE project-local SQLite continuity backend through memory_cli.py for scoped user facts, checkpoints, candidates, and focused retrieval; never treat it as native/global memory or formal authority.
+license: MIT
+metadata:
+  tool: references/memory_cli.py
+  state: project-local memory/memory.db
+---
+
+# ROSE Memory
+
+## Purpose
+
+This skill provides the legacy/pre-runtime ROSE continuity protocol and bundled SQLite CLI. It is project-local compatibility infrastructure, not native backend memory, global state, or formal lifecycle authority.
+
+The CLI implementation is distributed with this skill:
+
+`references/memory_cli.py` from the active Skill root resolved by the current adapter.
+
+The memory database is always the exact project-local path, resolved from the canonical project root:
+
+`memory/memory.db`
+
+Never store project memory inside a global backend configuration directory.
+
+## When to Use
+
+Use this skill when:
+
+- starting or resuming a ROSE task
+- checking current ROSE memory status
+- recording a scoped task checkpoint or completion receipt
+- default-writing an explicit user-stated requirement, preference, decision, correction, or acceptance criterion when identity, scope, metadata, permission, and content safety are clear
+- recording evidence-backed model-derived material only as a candidate when the existing backend supports that exact operation
+- retrieving focused project memory as one bounded input during explicit resume
+- recovering from interrupted work
+
+## Rules
+
+- Never edit `memory/memory.db` manually.
+- Never create `memory.md`, JSON sidecars, or alternate memory state files.
+- Never store project state under a backend configuration home.
+- Invoke only the existing `rose-memory` shim or the adapter-resolved bundled `references/memory_cli.py`, always with the literal project-relative argument `--db memory/memory.db` from the canonical project root. Reject an absolute, user-supplied, alternate, parent-relative, aliased, or manual database path. If `memory/memory.db` or a path component is presented as a symlink, stop without following it; do not substitute another path.
+- Memory is additive, scoped continuity context. It is never the active OpenSpec contract, test-plan acceptance, permission, Git truth, review verdict, or completion proof.
+- Default-write only explicit, reusable user requirements, preferences, corrections, decisions, and acceptance criteria when project/change/session identity, source reference/type, CLI timestamp, permission, and content safety are clear. Use only the existing `text`, `source`, `project`, session/task identity, timestamp, and receipt behavior. Do not ask a redundant per-fact write question in that safe case.
+- If identity, scope, required metadata, or permission is ambiguous, ask one focused scope/identity question or keep the item in the active change artifact; do not create an unscoped record.
+- Before invoking the CLI, reject or rewrite to a safely redacted existing-field value any text containing an embedded token, private key, credentialed URL, cookie, credential, private user data, or ambiguous sensitive content. Ambiguous permission blocks the write. Sensitive bytes must not appear in CLI arguments, memory, a receipt, or a new field; retain only a non-sensitive outcome/reference when useful.
+- This policy does not add a command, field, schema, migration, storage path, or storage hardening. Existing backend file-mode enforcement, backend symlink handling, and retention behavior remain `Unverified`.
+- Ordinary one-turn or report-only work that neither opens nor uses memory and has no formal long-running, resume, or context-loss need writes no session/task start or completion receipt by default. A missing receipt in that case is not a continuity failure.
+- Active formal long-running, resume, or context-loss work, and any current task that actually opens or uses memory, records the applicable scoped checkpoint/completion receipt with current evidence references. The receipt remains navigation/evidence metadata and never establishes contract, permission, Git truth, verification, or completion.
+- Model-derived repository facts, patterns, risks, review findings, history/log observations, and procedural rules are not user facts. Keep them as evidence-backed candidates or change-local `Unverified` items. If the existing CLI cannot represent the exact candidate lifecycle, keep the item in the appropriate change artifact instead of inventing a command, schema, or bridge.
+- Memory does not depend on DCP, compression thresholds, stale chat, or old logs. None of those sources has active-task authority.
+- If memory writeback fails, retry once when the fix is obvious. If it still fails, continue safe task progress, keep a pending TodoWrite item for memory writeback, retry before final handoff, and report any remaining failure.
+- If the current directory is not inside a project, stop and report `SETUP_BLOCKED_NO_PROJECT_ROOT`.
+- 🔴 CHECKPOINT: before any promotion, confirm the existing backend supports the exact candidate/promotion operation and that the item is scoped, reusable, evidence-backed, non-secret, and not contradicted by the active formal contract or current user instruction. Otherwise use `--no-durable-memory-promoted` and keep the item in change-local evidence or mark it `Unverified`.
+
+## Memory Layers
+
+Task checkpoint:
+- Goal, scope, progress, files touched, and verification evidence.
+- Use for deliberate checkpoint/resume continuity; `progress.txt` remains the current execution ledger for a formal change.
+
+Requirement memory:
+- User-stated requirements, preferences, corrections, decisions, and acceptance criteria.
+- This is the only default-write layer, and only under the scope/metadata/permission/security gates above.
+
+Candidate:
+- Model-derived facts or rules with explicit evidence links, never disguised as user facts.
+- Candidate status does not make the item authoritative. Do not promote when support or evidence is uncertain.
+
+Conflict rule:
+- Current user instruction and the active formal contract govern the task; fresh filesystem/Git/review/verification evidence governs current state.
+- Memory, handoff, chat summaries, old logs, and task checkboxes are navigation/context only.
+- If memory suggests a conflict that changes the next action, surface it before acting.
+
+Conflict next-action table:
+
+| Conflict found | Next action |
+|---|---|
+| Current user instruction or active OpenSpec contract conflicts with memory | Follow the current authority; do not promote the stale memory. |
+| Chat summary, old log, or task checkbox claims completion | Re-read the contract, progress, bounded drift, root/Git identity, and fresh verification; do not infer completion. |
+| Memory claims lack evidence | Treat as context only; mark `[UNVERIFIED]` and avoid durable promotion. |
+| Memory contains possible secret, raw log, or credential | Do not repeat or store it; report a redacted concern. |
+| Conflict changes what you would do next | Stop and ask or state the conflict before acting. |
+
+## Command
+
+If a short shim exists, use it:
+
+```bash
+rose-memory --help
+```
+
+If the shim is unavailable and the active adapter resolves the Skill root, call the bundled tool directly:
+
+```bash
+python <skill-root>/references/memory_cli.py --help
+```
+
+For every example below, replace `rose-memory` with `python <skill-root>/references/memory_cli.py` when no shim exists.
+
+## Standard Operations
+
+Initialize project memory:
+
+```bash
+mkdir -p memory
+rose-memory init --db memory/memory.db
+```
+
+Check health:
+
+```bash
+rose-memory doctor --db memory/memory.db --record
+```
+
+Start a session:
+
+```bash
+rose-memory session start --db memory/memory.db --session-key "<session-key>"
+```
+
+Start a task:
+
+```bash
+rose-memory task start --db memory/memory.db --session-key "<session-key>" --title "<task summary>"
+```
+
+Use session/task start and later checkpoint/completion operations only for the receipt-triggering cases above. Do not run them merely because an ordinary task started or ended.
+
+Record an event checkpoint:
+
+```bash
+rose-memory event add --db memory/memory.db --event-type CHECKPOINT --state ACTIVE --summary "<summary>"
+```
+
+Record a structured task checkpoint:
+
+```bash
+rose-memory checkpoint \
+  --db memory/memory.db \
+  --goal "<goal>" \
+  --scope "<scope>" \
+  --progress "<progress>" \
+  --file "<path>" \
+  --evidence-ref "<file/command/result>"
+```
+
+Record requirement memory:
+
+```bash
+rose-memory remember-requirement \
+  --db memory/memory.db \
+  --text "<user requirement/preference/correction/decision>" \
+  --source "user:conversation:<message-reference>" \
+  --project "<canonical-project>" \
+  --session-key "<session-key>" \
+  --task-key "<change-or-task-key>"
+```
+
+The CLI records its timestamp. Run this only when the arguments above represent the required project/change/session scope; otherwise keep the item in the active change artifact and resolve scope first.
+
+Retrieve memory context:
+
+```bash
+rose-memory pack --db memory/memory.db "<query>" --mode direct --budget 800
+rose-memory search --db memory/memory.db "<query>" --limit 10
+```
+
+Retrieve the focused current-task pack:
+
+```bash
+rose-memory pack-current --db memory/memory.db --task-key "<task>" --budget 1200
+```
+
+During explicit resume, use `pack-current` only as one scoped hydration input after resolving the active project/change/task. Re-read the active OpenSpec contract, `progress.txt`, bounded `drift-log.md`, root/Git state, and fresh review/verification evidence before acting:
+
+```bash
+rose-memory pack \
+  --db memory/memory.db \
+  "current active task requirements decisions evidence" \
+  --mode direct \
+  --budget 1200
+```
+
+Complete a task with no durable memory promoted:
+
+```bash
+rose-memory complete --db memory/memory.db --summary "<completion summary>" --no-durable-memory-promoted
+```
+
+Most completions should include `--no-durable-memory-promoted`. Any model-derived architecture fact, project finding, or procedural rule must first remain an evidence-backed candidate and follow the existing explicit candidate/promotion workflow; never promote it directly as requirement memory or invent a promotion path.
+
+## Success Signal
+
+A memory write succeeds only when the CLI returns JSON containing:
+
+- `ok: true`
+- `receipt_id`
+- `result` with the operation-specific payload
+
+If the receipt is missing, treat the operation as failed and do not claim writeback completion.
+
+A valid receipt proves only that the existing CLI reported that scoped operation. It grants no authority over the active contract, permissions, Git/filesystem state, verification, or task completion.
+
+## References
+
+- `references/memory_cli.py` - executable memory CLI
+- `references/schema.sql` - current SQLite schema emitted by the CLI
+- `references/README.md` - operator notes for global install and project-local state

package/skills/rose-memory/references/README.md

@@ -0,0 +1,48 @@
+# ROSE Memory References
+
+This directory is distributed with the `rose-memory` skill. The CLI is a legacy/pre-runtime compatibility tool; all state remains project-local and has no native/global or formal lifecycle authority.
+
+Files:
+
+- `memory_cli.py` - the only supported interface for schema creation, migrations, reads, writes, receipts, checkpoints, requirement memory, evidence, findings, and retrieval packs.
+- `schema.sql` - the current SQLite schema emitted by `memory_cli.py` for review and auditing.
+
+State boundary:
+
+- Global skill directory: tool and protocol only.
+- Project directory: `memory/memory.db` state only.
+
+Do not store `memory.db` in this directory. Do not edit SQLite rows manually.
+
+Memory policy:
+
+- Default-write only explicit user-stated requirements, preferences, decisions, corrections, and acceptance criteria when identity, project/change/session scope, source metadata, timestamp, permission, and content safety are clear.
+- Use only the existing `text`, `source`, `project`, session/task identity, CLI timestamp, and receipt behavior; do not add a field, command, schema, migration, or storage path.
+- Block or keep the item in the active change artifact when scope, metadata, identity, or permission is ambiguous. Before CLI invocation, reject or safely redact embedded tokens, private keys, credentialed URLs, cookies, credentials, private user data, and ambiguous sensitive content so no sensitive bytes enter CLI arguments, memory, or receipts.
+- Invoke only the existing shim or bundled CLI from the canonical project root with literal `--db memory/memory.db`. Reject absolute, alternate, parent-relative, user-supplied, manual, aliased, or symlink database paths without following them.
+- Ordinary one-turn/report-only work with no actual memory use and no formal long-running/resume/context-loss boundary writes no start/end receipt. Formal long-running/resume/context-loss work or actual current-task memory use requires the applicable scoped checkpoint/completion receipt.
+- A receipt is operation evidence only, never contract, permission, Git truth, verification, or completion authority.
+- Use checkpoints as bounded continuity input. Formal `progress.txt`, OpenSpec artifacts, fresh Git/filesystem state, and fresh verification retain their own authority.
+- Keep model-derived facts as evidence-backed candidates or change-local `Unverified` items. Do not invent storage operations when the current CLI cannot represent the required lifecycle.
+- DCP, compression thresholds, stale chat summaries, task checkboxes, and old logs have no active-task authority.
+- Do not import, migrate, dual-read, dual-write, or bridge this database to native/global or reserved `.aili` state.
+- Memory writeback failure should be retried once, tracked, retried before handoff, and reported if still failing; it should not block otherwise safe task progress.
+- Backend file-mode enforcement, backend symlink handling, and retention remain `Unverified`; this routing/default-write policy makes no broader storage-hardening claim.
+
+If a `rose-memory` command is available:
+
+```bash
+rose-memory doctor --db memory/memory.db --record
+```
+
+Direct fallback:
+
+```bash
+python ~/.agents/skills/rose-memory/references/memory_cli.py doctor --db memory/memory.db --record
+```
+
+Focused current-task pack:
+
+```bash
+rose-memory pack-current --db memory/memory.db --budget 1200
+```