oris-skills 2.0.0 → 2.2.0

package/skills/oris-flow/references/plan.md

@@ -0,0 +1,58 @@
+# Technical Plan
+
+Interview the technical owner until another agent or developer could execute the plan
+without guessing.
+
+RULES: `references/conventions.md`. Doc standards: `references/doc-policy.md`.
+
+## Before asking
+
+1. EXPLORE: `functional-analysis.md` + `acceptance-criteria.md` when present (preferred,
+   not required — offer discovery only when the functional source is too weak to plan
+   safely), task docs, setup map, standards, code, tests, build scripts.
+2. PREFER existing project patterns over new abstractions. Keep uncertainty visible.
+
+## Interview
+
+ASK one technical decision at a time, recommended answer first, early exit always
+present. Cover:
+- ownership boundaries, files/symbols to touch;
+- APIs/contracts, data model, migrations;
+- permissions, feature flags, frontend integration;
+- verification strategy;
+- rollout, risk, sequencing.
+
+## Generation gate
+
+SHOW compact recap: approach, touched areas, sequence, verification, risks, open points.
+ASK: generate the document | keep interviewing | explain.
+ON generate → write `{tasksRoot}/{task}/implementation-plan.md` (language `artifactLanguage`):
+
+```markdown
+# {Feature} — Implementation Plan
+## Approach        (decisions + why, existing patterns referenced)
+## Implementation plan
+### 1. {task}      (files, changes, completion criteria)
+### 2. …
+## Verification    (commands, tests, what proves each step)
+## Risks & open points
+## Change history  (date | source | change | reason)
+```
+
+Numbered `### n.` tasks are the execution steps the implement route will follow — keep
+each one bounded and independently verifiable.
+
+AFTER: offer implement (`skills/oris-flow/references/implement.md`) | stop.
+
+## Never
+
+- Write code, Git, or DevOps — this skill only plans.
+- Invent architecture, field names, or commands — uncertainty goes to open points.
+- Re-ask functional/QA questions already answered by docs or confirmed chat.
+- Write the document before the explicit generation choice, or auto-start implement.
+
+## Done when
+
+- [ ] Explored before asking; only implementation questions asked.
+- [ ] Plan tasks bounded with completion criteria.
+- [ ] Document written only after the explicit generation choice.

package/skills/oris-flow/references/setup.md

@@ -0,0 +1,100 @@
+# Oris Setup
+
+Make the repo cheap for agents to understand — manifest + maps + AI-readiness + loop
+readiness. ADAPT to what the repo IS; never force one structure. Writes ONLY after the
+user confirms the recap.
+
+RULES: `references/conventions.md`. Map format: `references/repo-map.md`.
+IF the repo is empty or brand-new → route to `skills/oris-flow/references/new.md` instead.
+
+## Mode
+
+IF `.oris-flow/manifest.json` exists → CHECK freshness first:
+`npx oris-skills flow scan --repository-root <repo> --check` — `fresh: true` → say so
+(a rescan would be a no-op); stale → the `changedFiles` list names the areas worth
+refreshing. THEN ask ONE question with these options:
+- refresh all (keeps `confirmed` values — scan merges, never overwrites them)
+- update one area (`--area <section>`)
+- review stale sections
+- show summary (no writes)
+- recreate from scratch
+- language & profiles → Local Preferences below; touches only `~/.oris/settings.json`
+- clean runtime → preview with `npx oris-skills flow clean-runtime --repository-root <repo> --dry-run`, confirm, run without `--dry-run`
+
+ELSE → create from scratch.
+
+## 1. Explore first
+
+1. CONFIRM the target repository root (ask only if multiple roots are plausible).
+2. SCAN: `npx oris-skills flow scan --repository-root <repo> --json` — deterministic
+   baseline: `projectType`, stacks, commands (with confidence), sections, `truncated`
+   flag. Scan output = draft evidence, not truth.
+3. IF `truncated: true` → say so; large monorepos may need per-area subagent scans.
+4. ADD parallel subagent scans (docs, frontend, backend/data, tests/build, local
+   skills/rules) only when the baseline leaves real gaps.
+
+## 2. Present findings, decide one at a time
+
+SHOW compactly: detected project type + evidence, stacks, commands, AI-readiness (below).
+Then WALK decisions ONE per turn — short explainer first, recommended answer first:
+
+- **Project type** — confirm `projectType` (webapp | api | library | cli | monorepo); it
+  drives which map sections matter and how criteria/verify observe behavior.
+- **Tasks root** — where Oris writes task documents. Default `.oris-flow/tasks` (keeps
+  the project clean); keep `docs/tasks` only when the team already treats task docs as
+  project docs. Record in `setup.tasksRoot`.
+- **Verify commands** — show detected build+test commands; user confirms or corrects →
+  mark `confirmed`. They feed implement, verify, and loop VERIFIER; unconfirmed = a guess.
+- **Refresh policy** (manual | monthly | after refactor | after test-layout change) —
+  advisory only, never a scheduler.
+- **Version control for `.oris-flow/`** — commit (team default) or gitignore. Task docs
+  follow the same choice.
+
+## 3. AI-readiness check
+
+COMPARE the repo against the agent-native standards; report gaps, one line each, with a
+fix offer:
+
+| Check | Why it matters |
+|-------|----------------|
+| `AGENTS.md` (or `CLAUDE.md`) at root | the cross-tool entry point — one-line purpose + commands; every token loads on every request |
+| `CONTEXT.md` | domain glossary — the names agents must use for the product's concepts |
+| `docs/adr/` | decisions agents must not re-litigate |
+| project skills/rules (`.claude/skills`, `.cursor/rules`) | repeatable workflows as source of truth |
+| confirmed test/build commands | deterministic feedback loop — agents verify instead of guessing |
+
+ON explicit confirmation per file → scaffold the missing ones minimal.
+
+## 4. Recap + write
+
+1. RECAP: repo, mode, project type, tasksRoot, files to write, AI-readiness gaps,
+   choices. CONFIRM explicitly.
+2. WRITE `.oris-flow/manifest.json` + `.oris-flow/maps/**` (confirmed facts get
+   confidence `confirmed` so refresh preserves them), then apply:
+   - `npx oris-skills flow version-control --repository-root <repo> --mode commit|gitignore`
+   - `npx oris-skills loop bootstrap --repository-root <repo>` when adapter/hooks are missing.
+3. OFFER next: discovery | technical plan | loop (`npx oris-skills loop demo` for
+   first-timers) | refresh one area | stop.
+
+## Local Preferences
+
+1. READ `~/.oris/settings.json` (defaults in `references/settings.md`).
+2. ASK what to change: uiLanguage | artifactLanguage | responseStyle (standard |
+   caveman — maximum token density in chat) | default test profile | profiles.
+3. SHOW masked summary (passwords `***`), CONFIRM, write ONLY the settings file.
+
+## Never
+
+- Write before the recap is explicitly confirmed.
+- Overwrite `confirmed` values on refresh — the scan merges; missing evidence marks
+  stale, never deletes.
+- Overwrite existing agent files: edit the file that exists, never create `AGENTS.md`
+  beside `CLAUDE.md`.
+- Copy secrets into `.oris-flow/**`, docs, or loop state.
+
+## Done when
+
+- [ ] Mode chosen; scan ran before questions; decisions asked one at a time with explainers.
+- [ ] Project type and tasksRoot recorded; confirmed commands marked `confirmed`.
+- [ ] AI-readiness gaps reported; files scaffolded only on explicit per-file confirmation.
+- [ ] Explicit confirmation before every write; no secrets in repository files.

package/skills/oris-flow/references/verify.md

@@ -0,0 +1,57 @@
+# Verify
+
+Check every acceptance criterion against the REAL product once, with evidence. One pass,
+no loop ceremony.
+
+RULES: `references/conventions.md`. Doc standards: `references/doc-policy.md`.
+
+## Prepare
+
+1. FIND `{tasksRoot}/{task}/acceptance-criteria.md` ({task} per doc-policy). IF missing →
+   offer: define criteria first (`skills/oris-flow/references/criteria.md`) | verify against a
+   confirmed chat recap | stop.
+2. READ setup map + verification conventions (test commands, run scripts, environments)
+   before improvising.
+3. PLAN one check per AC: command, test, API call, or observed behavior.
+
+## Verify (read-only on product code)
+
+For EACH `AC-xxx`, in order:
+- EXECUTE the numbered steps against the real product (tests, running app, API, CLI —
+  whatever the criterion observes).
+- MARK: `Pass` | `Fail` | `Not verifiable` (say why: missing data, blocked env, needs setup).
+- CAPTURE evidence: command + output excerpt, observed behavior, or pointer to logs.
+  Facts, not impressions.
+
+## Report gate
+
+SHOW compact results: `AC-xxx → Pass/Fail/Not verifiable — one-line evidence` + totals.
+ASK ONE question: Save report | Fix failures now | Stop.
+ON save → write `{tasksRoot}/{task}/verification-report.md` (language `artifactLanguage`):
+
+```markdown
+# {Feature} — Verification Report
+Date: … | Source: acceptance-criteria.md | Verified by: oris-flow verify route
+## Results
+| AC | Result | Evidence |
+## Failures        (reproduction + observed vs expected)
+## Not verifiable  (reason + what would unblock)
+## Change history  (date | source | change | reason)
+```
+
+ON fix → enter `skills/oris-flow/references/fix.md` with the failing AC as the bug report.
+LONG iterative fixing with re-verification each pass → recommend
+`skills/oris-flow/references/loop.md` only when one fix-verify pass is clearly not enough.
+
+## Never
+
+- Edit product code — failures are recorded and routed, never fixed here.
+- Mark Pass from code reading alone when the criterion describes observable behavior.
+- Skip an AC silently — every criterion gets a result or a reason.
+- Write the report before the gate.
+
+## Done when
+
+- [ ] Every AC checked against real behavior or explicitly marked Not verifiable.
+- [ ] Evidence captured per criterion; no Pass without observation.
+- [ ] Report written only after the gate; failures routed, not fixed here.

package/skills/{oris-loop → oris-flow}/templates/debriefer.md

@@ -13,6 +13,7 @@ IMPROVE MODE = {{IMPROVE_MODE}}:
 - propose → write the smallest evidence-backed change to proposals/; change nothing else.
 
 RULE: one improvement per debrief. No improvement without receipt evidence.
+NEVER weaken verification to make passes green — fix the loop, not the bar.
 
-RETURN compact JSON only:
+RETURN compact JSON only (```json fenced):
 { "role": "debriefer", "outcome": "keep|tuned|proposed", "insight": "", "changedFiles": [], "proposalPath": "" }

package/skills/oris-flow/templates/doctor.md

@@ -0,0 +1,22 @@
+# Doctor prompt — edit freely; decides continue / stop each pass
+
+You are the doctor of the Oris loop "{{OBJECTIVE_SLUG}}".
+Diagnose from executor + verifier evidence, never from confidence.
+
+STOP RULES for this loop:
+{{STOP_RULES}}
+
+DECIDE one (canonical, references/loop-contract.md):
+- continue — criteria progressing; run another pass.
+- advance — this phase is done; move to the next declared phase.
+- complete — the loop goal is met with evidence.
+- ask-user — missing authority, scope, or product decision.
+- propose-patch — loop design gap; describe the minimal patch (improve mode decides where it lands).
+- blocked — environment, tooling, scope violation, or no progress ({{iteration}} vs limits).
+
+DISTINGUISH: loop design issue | execution choice | environment | changed goal | insufficient evidence.
+
+NEVER: edit product files, edit loop.md scope/limits/permissions directly.
+
+RETURN compact JSON only (```json fenced):
+{ "role": "doctor", "decision": "continue|advance|complete|ask-user|propose-patch|blocked", "classification": "", "diagnosis": "", "evidence": "", "patchSummary": "", "approvalRequired": true }

package/skills/{oris-loop → oris-flow}/templates/executor.md

@@ -1,6 +1,7 @@
 # Executor prompt — edit freely; the orchestrator sends this file to the executor subagent each pass
 
-You are the executor of the Oris loop "{{OBJECTIVE_SLUG}}".
+ORIS LOOP ACTIVE — approved pass of the loop "{{OBJECTIVE_SLUG}}".
+You are its executor.
 
 GOAL: {{OBJECTIVE}}
 
@@ -8,6 +9,11 @@ THIS PASS (runtime values filled by the orchestrator):
 - Iteration: {{iteration}} | Phase: {{phase}} | Target: {{currentTarget}}
 - DO exactly one bounded action: {{BOUNDED_ACTION}}
 
+DISCIPLINE:
+- RE-READ the fresh state of every file you touch before editing it.
+- The action proves bigger than bounded → STOP and return blocked with what you found. Half-done work is worse than none.
+- claim = what changed + the exact command or observation that proves it.
+
 SCOPE:
 - Allowed paths: {{ALLOWED_PATHS}}
 - Out of scope: {{OUT_OF_SCOPE}}
@@ -15,5 +21,5 @@ SCOPE:
 
 NEVER: commit, push, deploy, expose credentials, edit .oris-flow/runtime/**, self-verify.
 
-RETURN compact JSON only:
+RETURN compact JSON only (```json fenced):
 { "role": "executor", "state": "claimed|blocked", "summary": "", "changedFiles": [], "claim": "", "evidenceHint": "", "blocker": "" }

package/skills/{oris-loop → oris-flow}/templates/orchestrator.md

@@ -3,6 +3,7 @@
 ORIS LOOP RUN — pass {{iteration}}/{{maxIterations}}
 Loop: {{loop}} | Phase: {{phase}} ({{phaseIndex}}/{{phaseCount}}) | Do: {{instruction}}
 Definition: {{loopPath}} | Context: {{contextPath}} | Prompts: {{promptsDir}}
+Active roles: {{roles}}
 Models: executor={{executorModel}} verifier={{verifierModel}} doctor={{doctorModel}} debriefer={{debrieferModel}} ("inherit" = current session model)
 Improve mode: {{improveMode}}
 
@@ -12,13 +13,15 @@ EACH PASS:
 1. READ {{contextPath}}; pick exactly ONE bounded next step.
 2. SPAWN executor subagent with {{promptsDir}}/executor.md (fill runtime values), model {{executorModel}}.
 3. SPAWN verifier subagent with {{promptsDir}}/verifier.md + the executor claim, model {{verifierModel}}.
-4. SPAWN doctor subagent with {{promptsDir}}/doctor.md + both compact summaries, model {{doctorModel}}.
+4. DECIDE the state:
+   - doctor in active roles → SPAWN doctor subagent with {{promptsDir}}/doctor.md + both compact summaries, model {{doctorModel}}; use its decision.
+   - no doctor → map the verifier verdict: pass + goalMet → complete; pass → continue; fail → continue; blocked or inconclusive → ask-user.
 5. WRITE a compact receipt to the loop receipts/ folder; update context.md with durable facts only.
-6. RUN: `oris-skills loop chat --action set-state --state <continue|advance|complete|blocked>`.
-7. END the turn with exactly: `ORIS_LOOP_STATE: continue | advance | complete | blocked | ask_user`.
+6. RUN: `npx oris-skills loop chat --action set-state --state <continue|advance|complete|blocked|ask-user> --progress <yes|no>` (progress yes = the verifier confirmed forward movement).
+7. END the turn with exactly: `ORIS_LOOP_STATE: <continue|advance|complete|blocked|ask-user>`.
 
-IMPROVE ({{improveMode}}):
-- auto → after the doctor verdict, the debriefer may rewrite files under {{promptsDir}} (archive the old version to history/ first). It must NEVER change scope, limits, permissions, or verification in loop.md — those go to proposals/.
+IMPROVE ({{improveMode}}, only when debriefer is in active roles):
+- auto → after the verdict, the debriefer may rewrite files under {{promptsDir}} (archive the old version to history/ first). It must NEVER change scope, limits, permissions, or verification in loop.md — those go to proposals/.
 - propose → the debriefer writes proposals/ only; nothing changes until the user approves.
 
 ALWAYS:
@@ -26,8 +29,8 @@ ALWAYS:
 - Tell the user in one line what this pass will do before spawning workers.
 
 NEVER:
-- Continue when the doctor says blocked, scope is violated, or the same failure repeats.
+- Continue when the verdict is blocked, scope is violated, or the same failure repeats.
 - Commit, push, deploy, edit .oris-flow/runtime/**, or touch paths outside the approved scope.
 - Ask "run next pass?" after continue/advance — end the turn; the hook schedules the next pass.
 
-IF prompts files are missing or subagents cannot be spawned: `set-state --state blocked`, say why, end the turn.
+IF prompt files are missing or subagents cannot be spawned: `set-state --state blocked`, say why, end the turn.

package/skills/{oris-loop → oris-flow}/templates/verifier.md

@@ -13,9 +13,12 @@ THIS PASS: iteration {{iteration}}, phase {{phase}}, target {{currentTarget}}.
 Executor claim: supplied by the orchestrator.
 
 RULES:
-- Read-only on product files.
+- ORDER: run the checks FIRST, judge after. A claim you could not check = inconclusive, never pass.
+- Read-only on product files. NEVER fix anything — you only observe.
 - Store raw logs under .oris-flow/runtime/evidence/; return pointers, not dumps.
 - Report pass, fail, blocked, or inconclusive — with reproducible evidence.
 
-RETURN compact JSON only:
-{ "role": "verifier", "state": "pass|fail|blocked|inconclusive", "summary": "", "evidence": "", "evidencePath": "", "nextRecommendation": "" }
+RETURN compact JSON only (```json fenced):
+{ "role": "verifier", "state": "pass|fail|blocked|inconclusive", "goalMet": false, "summary": "", "evidence": "", "evidencePath": "", "failureSignal": "", "nextRecommendation": "" }
+
+goalMet = true ONLY when the LOOP goal (not just this pass) is satisfied per the criteria above.

package/references/questions.md

@@ -1,38 +0,0 @@
-# Oris Question Contract
-
-How every Oris skill asks. Base rules live in `references/conventions.md`; this file adds the standard options and localized labels.
-
-## Standard options
-
-Include in every Oris question, localized to `uiLanguage`:
-
-| Option | `en` | `it` |
-|--------|------|------|
-| explanation (always) | `Explain the options` | `Spiega le opzioni` |
-| early exit (interviews only) | `Enough questions — proceed` | `Basta domande — procedi` |
-
-- Explanation → explain briefly, re-ask the same question.
-- Early exit → stop asking, go to the matching generation gate. It is NOT approval to write or execute.
-
-## Generation gates
-
-Standard labels:
-
-| `en` | `it` |
-|------|------|
-| `Generate the document` | `Genera il documento` |
-| `Approve document` | `Approva documento` |
-| `Continue the interview` | `Continua l'intervista` |
-| `Cancel` | `Annulla` |
-
-Rules:
-1. NEVER write documents, code, or external changes before the explicit gate choice.
-2. Exception: `oris-flow-criteria` writes the file first, then asks once — confirmed only on `Approve document` / `Generate the document`.
-3. After a document is written: concise summary + contextual next-step menu. NEVER auto-start the next phase.
-
-## Interview standard
-
-Oris is a guided product, not a silent task runner.
-1. READ everything the repo can answer first; ask only real decisions.
-2. ONE focused question per turn until outcome, authority, evidence, and stop rules are clear.
-3. The agent recommends; the user's explicit choice decides the approved scope.

package/skills/oris-flow-criteria/SKILL.md

@@ -1,49 +0,0 @@
----
-name: oris-flow-criteria
-description: Generate or audit business-readable acceptance criteria with stable IDs, numbered steps, and observable outcomes. Use for acceptance-criteria intent or acceptance-criteria.md work. Ambiguous request - route to /oris-flow.
----
-
-# Acceptance Criteria
-
-Generate verifiable, browser-observable criteria. These later feed loop VERIFIER prompts — precision here pays twice.
-
-RULES: follow `references/conventions.md`. Doc standards: `references/doc-policy.md`.
-NEVER write code, Git, or DevOps here.
-
-## Generate privately first
-
-1. SOURCES in order of trust: confirmed chat > task docs (`functional-analysis.md` preferred, never required — say once when missing) > current UI > code and tests.
-2. DEDUCE create vs update: existing `acceptance-criteria.md` → update, PRESERVE IDs; never recycle a removed ID for different behavior.
-3. IDs: `AC-001`, `AC-002`, … stable across revisions.
-4. Each scenario: role + starting state, deterministic data, numbered user steps, observable outcome placed under the step that causes it, negative coverage, regressions to keep.
-5. CLASSIFY each: `Verifiable` | `Needs setup/data` | `Blocked by Open QA`.
-6. DISCARD criteria not checkable through observable product behavior. For unbuilt features: only confirmed intended behavior — NEVER invent labels or messages.
-
-## Interview (only high-impact gaps)
-
-ASK one at a time, only what docs/UI/code cannot answer: actor boundaries, required data/state, success message + visible result, blocked/negative cases, async states visible to the user, regressions, ambiguous wording. NEVER ask "anything else?".
-
-## Write + gate
-
-WRITE `docs/tasks/{task}/acceptance-criteria.md` (language `artifactLanguage`):
-
-```markdown
-# {Feature} — Acceptance Criteria
-## AC-001 {scenario title}   [Verifiable | Needs setup/data | Blocked by Open QA]
-Role/state: … | Data: …
-Steps:
-1. …
-   → observable outcome
-Negative: … | Regressions: …
-## Open QA
-## Change history (date | source | change | reason)
-```
-
-THEN ask ONE question: Approve document | Regenerate | Edit specific criteria | Cancel.
-Document is confirmed ONLY on approval. AFTER: offer technical plan | verification loop | stop.
-
-## Done when
-
-- [ ] IDs stable; every scenario observable and classified.
-- [ ] Questions only for gaps evidence could not close.
-- [ ] Approval asked exactly once after writing.

package/skills/oris-flow-discover/SKILL.md

@@ -1,58 +0,0 @@
----
-name: oris-flow-discover
-description: Business-first functional discovery interview. Use to clarify what a feature should do, define product behavior, or produce functional-analysis.md. Ambiguous request - route to /oris-flow.
----
-
-# Discovery
-
-Interview the stakeholder until the desired business behavior is clear enough to document. The cornerstone of the flow: everything downstream (criteria, plan, loops) builds on this.
-
-RULES: follow `references/conventions.md`. Doc standards: `references/doc-policy.md`.
-NEVER write code, Git, or DevOps here. WRITE `functional-analysis.md` only after the user explicitly chooses generation.
-
-## Before asking
-
-1. EXPLORE first: task folder (`docs/tasks/{task}/`), existing `functional-analysis.md` / `acceptance-criteria.md` / `implementation-plan.md`, project docs, setup map, code evidence, DevOps context when available.
-2. DEDUCE create vs update: existing `functional-analysis.md` → update; missing → create. Ask only on contradictory signals.
-3. Technical evidence = private input. TRANSLATE it to business language; never show file paths or code to the stakeholder.
-
-## Interview
-
-ASK one business decision at a time, recommended answer first, early-exit option always present.
-BUSINESS ONLY: actors, roles, permissions, goals, current vs desired behavior, visible states, labels, messages, navigation, edge cases, empty/error states, scope in/out/deferred, rollout, priority.
-NEVER ask about: files, APIs, services, tables, selectors, branches, tests, frameworks, implementation order.
-WALK every branch of the decision tree until intent, boundaries, cases, and open points are explicit or intentionally parked. Do not stop at the first plausible answer.
-ESTIMATE complexity in Fibonacci Story Points (1–21) from scope, dependencies, uncertainty, QA impact.
-
-## Generation gate
-
-SHOW compact summary: goal, confirmed behavior, scope in/out, open points, estimate.
-ASK: generate the document | keep interviewing | explain.
-ON generate → write `docs/tasks/{task}/functional-analysis.md` per the template below (language: `artifactLanguage`).
-
-## Document template
-
-```markdown
-# {Feature} — Functional Analysis
-## Goal            (business value, one paragraph)
-## Actors & permissions
-## Behavior        (current → desired, user-visible only, numbered flows)
-## States & messages (labels, empty/error/loading states)
-## Edge cases
-## Scope           (included | excluded | deferred)
-## Open points
-## Estimate        (Story Points + rationale)
-## Change history  (date | source | change | reason)
-```
-
-FACTS only from confirmed sources; open questions go to Open points — NEVER invent behavior.
-
-## After writing
-
-OFFER: acceptance criteria | technical plan | stop. Never auto-start the next phase.
-
-## Done when
-
-- [ ] Explored before asking; questions stayed business-only, one at a time.
-- [ ] Document written only after explicit generation choice.
-- [ ] No code, Git, or DevOps writes.

package/skills/oris-flow-docs/SKILL.md

@@ -1,31 +0,0 @@
----
-name: oris-flow-docs
-description: Update existing task documents after a later functional, QA, or implementation change. Use when documented behavior changed and docs/tasks files must record it.
-disable-model-invocation: true
----
-
-# Update Task Docs
-
-Bring `docs/tasks/{task}/` documents in line with a later change, keeping the change traceable.
-
-RULES: follow `references/conventions.md`. Doc standards: `references/doc-policy.md`.
-
-## Workflow
-
-1. IDENTIFY the task folder. IF unclear → ask which task; recommend the obvious recent one.
-2. IF the change itself is vague → ask what changed before reading further.
-3. READ the existing docs, COMPARE with the new reality, CLASSIFY the change: functional | criteria | technical.
-4. ASK only unresolved questions, one at a time.
-5. SUMMARIZE proposed updates; CONFIRM before writing.
-6. UPDATE affected documents in place (language `artifactLanguage`):
-   - rewrite sections to the new behavior — no "changed!" notes scattered in the body;
-   - add one change-history row per document: date | source | short change | reason;
-   - keep unresolved risks in open points, never silently drop them;
-   - preserve acceptance-criteria IDs.
-7. NEVER create a replacement task folder unless the user wants a new feature.
-8. CLOSE with a concise summary. Offer next steps without auto-starting them.
-
-## Done when
-
-- [ ] Every affected document updated in place with a change-history row.
-- [ ] Confirmation before writing; nothing else touched.

package/skills/oris-flow-fix/SKILL.md

@@ -1,42 +0,0 @@
----
-name: oris-flow-fix
-description: Triage, diagnose, and fix a bug with the smallest safe change. Use for broken behavior, regressions, failed QA checks, or expected-vs-actual mismatches - reporter may be non-technical.
-disable-model-invocation: true
----
-
-# Fix
-
-Smallest safe change near the failing behavior. The caller may be non-technical — reconstruct context yourself.
-
-RULES: follow `references/conventions.md`.
-NEVER edit code before root cause, proposed fix, and verification plan are summarized and explicitly confirmed.
-
-## Triage
-
-1. IF no details given → ask ONE question (localized): "Which bug? Paste the link/ID if you have one, and describe what happens, what you expected, where."
-2. GATHER before asking more: reproduction steps, expected vs actual, task docs (`functional-analysis.md`, `acceptance-criteria.md`, `implementation-plan.md`), tracker context when available, recent commits, relevant code and tests.
-3. ASSUME bug report, not redesign. NEVER broaden scope or change product decisions unless documented behavior is impossible.
-
-## Diagnose
-
-- REPRODUCE or trace the failure path in code before proposing anything.
-- FIND root cause, not symptom. Check whether the documented behavior (criteria/analysis) defines "correct".
-- SUMMARIZE: root cause → proposed minimal fix → files → verification plan. CONFIRM explicitly.
-
-## Fix
-
-- SURGICAL change near the failure. NO refactors, cleanup, formatting churn, or opportunistic improvements.
-- PRESERVE unrelated user changes.
-- ADD a regression test when the area has test conventions.
-
-## Verify + close
-
-1. RUN the reproduction + targeted tests; broaden if the surface is shared.
-2. SUMMARIZE: cause, change, verification, residual risk.
-3. RECOMMEND: `/oris-loop` verification when criteria exist; docs update when documented behavior changed.
-
-## Done when
-
-- [ ] Root cause identified and confirmed before edits.
-- [ ] Minimal change; regression verified.
-- [ ] No unrelated code touched.

package/skills/oris-flow-implement/SKILL.md

@@ -1,43 +0,0 @@
----
-name: oris-flow-implement
-description: Implement a confirmed feature from implementation-plan.md or an explicitly confirmed technical recap. Use for build, code, implement, apply-the-plan intents after planning.
-disable-model-invocation: true
----
-
-# Implement
-
-Execute the confirmed plan — nothing more, nothing less.
-
-RULES: follow `references/conventions.md`.
-NEVER edit code before BOTH the source (plan or recap) and the execution mode are confirmed.
-
-## Prepare
-
-1. FIND `docs/tasks/{task}/implementation-plan.md`. IF missing → reconstruct a technical recap from chat, task docs, and code; SHOW it; CONFIRM before any edit.
-2. READ setup map, project standards, local skills/rules, tests and build conventions for the touched area.
-3. MAP the code, tests, config, and translations the plan touches (parallel subagents when available).
-
-## Execution mode (ask before first edit)
-
-- `Step by step` (recommended) — one numbered `### n.` plan task per step; SUMMARIZE touched files + completion criteria; WAIT for explicit confirmation before the next task.
-- `One shot` — all tasks in order, no stops between tasks.
-
-## While coding
-
-- FOLLOW existing project patterns; no new abstractions without need.
-- STAY inside the confirmed scope; park discoveries as notes, don't chase them.
-- ADD or update focused tests when practical.
-- CLEAN as you finish (`references/clean-code-checklist.md`): remove dead code, debug leftovers, and duplication you introduced; match the file's naming and style — no drive-by refactors of untouched code.
-- NEVER update DevOps unless explicitly asked.
-
-## Verify + close
-
-1. RUN targeted verification first; broaden when the touched surface is shared.
-2. SUMMARIZE: touched files, verification results, residual risk.
-3. RECOMMEND next: `/oris-loop` verification loop when acceptance criteria exist; otherwise update docs (`oris-flow-docs`).
-
-## Done when
-
-- [ ] Source and mode confirmed before edits.
-- [ ] Only planned scope touched; verification ran.
-- [ ] Next step recommended, not auto-started.

package/skills/oris-flow-plan/SKILL.md

@@ -1,51 +0,0 @@
----
-name: oris-flow-plan
-description: Technical implementation-plan interview before coding - file mapping, architecture choices, sequencing, verification strategy, implementation-plan.md. Ambiguous request - route to /oris-flow.
----
-
-# Technical Plan
-
-Interview the technical owner until another agent or developer could execute the plan without guessing.
-
-RULES: follow `references/conventions.md`. Doc standards: `references/doc-policy.md`.
-NEVER write code, Git, or DevOps here. WRITE `implementation-plan.md` only after explicit generation choice.
-
-## Before asking
-
-1. EXPLORE: `functional-analysis.md` + `acceptance-criteria.md` when present (preferred, not required — offer discovery only when the functional source is too weak to plan safely), task docs, setup map, standards, code, tests, build scripts.
-2. NEVER re-ask functional/QA questions already answered by docs or confirmed chat.
-3. PREFER existing project patterns over new abstractions. Keep uncertainty visible — never invent architecture, field names, or commands.
-
-## Interview
-
-ASK one technical decision at a time, recommended answer first, early-exit always present:
-ownership boundaries, files/symbols to touch, APIs/contracts, data model, permissions, feature flags, frontend integration, migrations, verification strategy, rollout, risk, sequencing.
-
-## Generation gate
-
-SHOW compact recap: approach, touched areas, sequence, verification, risks, open points.
-ASK: generate the document | keep interviewing | explain.
-ON generate → write `docs/tasks/{task}/implementation-plan.md` (language `artifactLanguage`):
-
-```markdown
-# {Feature} — Implementation Plan
-## Approach        (decisions + why, existing patterns referenced)
-## Implementation plan
-### 1. {task}      (files, changes, completion criteria)
-### 2. …
-## Verification    (commands, tests, what proves each step)
-## Risks & open points
-## Change history  (date | source | change | reason)
-```
-
-Numbered `### n.` tasks are the execution steps `oris-flow-implement` will follow — keep each one bounded and independently verifiable.
-
-## After writing
-
-OFFER: implement | verification loop | stop. Never auto-start.
-
-## Done when
-
-- [ ] Explored before asking; only implementation questions asked.
-- [ ] Plan tasks bounded with completion criteria.
-- [ ] Document written only after explicit generation choice.