@hanzlaa/rcode 2.7.2 → 3.1.0

package/rihal/skills/core/rihal-advanced-elicitation/SKILL.md

@@ -1,167 +1,67 @@
 ---
 name: rihal-advanced-elicitation
-description: 'Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.'
+description: Push the LLM to reconsider, refine, and improve its recent output through structured methods like socratic questioning, first principles, pre-mortem, and red-teaming. Use when the user asks for deeper critique, says "push harder on this", "go deeper", "challenge this", "stress-test this section", or names a specific elicitation method. For prose editing use rihal-editorial-review-prose; for structural review use rihal-editorial-review-structure.
 agent_party: '{project-root}/.rihal/team.yaml'
 triggers:
   - "advanced elicitation"
----
-
-# Advanced Elicitation
-
-**Goal:** Push the LLM to reconsider, refine, and improve its recent output.
-
+  - "push deeper"
+  - "go deeper"
+  - "challenge this"
+  - "stress-test this"
+  - "pre-mortem"
+  - "red team this"
+  - "first principles"
+user-invocable: true
 ---
 
 ## Overview
 
-Advanced elicitation skill for Rihal Code.
-
-## CRITICAL LLM INSTRUCTIONS
+Iterative menu-driven enhancement of recently-generated content. Presents 5 contextually-chosen elicitation methods (from `methods.csv`), runs the user's pick against the current content, shows the improvement, and re-offers the menu until the user picks `x` to proceed. Designed to be invoked indirectly from a parent prompt that just produced a section, then return the enhanced version. Detailed method registry, response cases, and execution rules live in [`references.md`](references.md).
 
-- **MANDATORY:** Execute ALL steps in the flow section IN EXACT ORDER
-- DO NOT skip steps or change the sequence
-- HALT immediately when halt-conditions are met
-- Each action within a step is a REQUIRED action to complete that step
-- Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution
-- **YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the `communication_language`**
+## Process
 
----
-
-## INTEGRATION (When Invoked Indirectly)
-
-When invoked from another prompt or process:
-
-1. Receive or review the current section content that was just generated
-2. Apply elicitation methods iteratively to enhance that specific content
-3. Return the enhanced version back when user selects 'x' to proceed and return back
-4. The enhanced content replaces the original section content in the output document
-
----
+1. **Method registry loading.** Read `./methods.csv` and `{agent_party}` from `.rihal/team.yaml`.
+2. **Context analysis.** Use conversation history to detect content type, complexity, stakeholder needs, risk level, creative potential.
+3. **Smart selection.** Pick 5 methods from the CSV that best match the context. Balance foundational and specialised techniques.
+4. **Present menu.** Show the 5 options + `r` (reshuffle), `a` (list all), `x` (proceed). HALT for input.
+5. **Execute on selection.** Apply the chosen method to the current content. Show the enhanced version. Ask the user `apply changes? y/n`. HALT.
+6. **On `y`** apply changes; on `n` discard. Re-present the menu — every method runs against the latest enhanced version.
+7. **On `x`** return the fully enhanced content to the invoking skill.
 
-## FLOW
-
-### Step 1: Method Registry Loading
-
-**Action:** Load and read `./methods.csv` and `{agent_party}`
-
-#### CSV Structure
-
-- **category:** Method grouping (core, structural, risk, etc.)
-- **method_name:** Display name for the method
-- **description:** Rich explanation of what the method does, when to use it, and why it's valuable
-- **output_pattern:** Flexible flow guide using arrows (e.g., "analysis -> insights -> action")
-
-#### Context Analysis
-
-- Use conversation history
-- Analyze: content type, complexity, stakeholder needs, risk level, and creative potential
-
-#### Smart Selection
-
-1. Analyze context: Content type, complexity, stakeholder needs, risk level, creative potential
-2. Parse descriptions: Understand each method's purpose from the rich descriptions in CSV
-3. Select 5 methods: Choose methods that best match the context based on their descriptions
-4. Balance approach: Include mix of foundational and specialized techniques as appropriate
-
----
+**Iterative enhancement:** every method (1-5) applies to the current enhanced version, not the original. The loop continues until `x`.
 
-### Step 2: Present Options and Handle Responses
-
-#### Display Format
+## Output Format
 
 ```
 **Advanced Elicitation Options**
 _If party mode is active, agents will join in._
 Choose a number (1-5), [r] to Reshuffle, [a] List All, or [x] to Proceed:
 
-1. [Method Name]
-2. [Method Name]
-3. [Method Name]
-4. [Method Name]
-5. [Method Name]
+1. <Method name>
+2. <Method name>
+3. <Method name>
+4. <Method name>
+5. <Method name>
 r. Reshuffle the list with 5 new options
 a. List all methods with descriptions
-x. Proceed / No Further Actions
+x. Proceed / No further actions
 ```
 
-#### Response Handling
-
-**Case 1-5 (User selects a numbered method):**
-
-- Execute the selected method using its description from the CSV
-- Adapt the method's complexity and output format based on the current context
-- Apply the method creatively to the current section content being enhanced
-- Display the enhanced version showing what the method revealed or improved
-- **CRITICAL:** Ask the user if they would like to apply the changes to the doc (y/n/other) and HALT to await response.
-- **CRITICAL:** ONLY if Yes, apply the changes. IF No, discard your memory of the proposed changes. If any other reply, try best to follow the instructions given by the user.
-- **CRITICAL:** Re-present the same 1-5,r,x prompt to allow additional elicitations
-
-**Case r (Reshuffle):**
-
-- Select 5 random methods from methods.csv, present new list with same prompt format
-- When selecting, try to think and pick a diverse set of methods covering different categories and approaches, with 1 and 2 being potentially the most useful for the document or section being discovered
-
-**Case x (Proceed):**
-
-- Complete elicitation and proceed
-- Return the fully enhanced content back to the invoking skill
-- The enhanced content becomes the final version for that section
-- Signal completion back to the invoking skill to continue with next section
-
-**Case a (List All):**
-
-- List all methods with their descriptions from the CSV in a compact table
-- Allow user to select any method by name or number from the full list
-- After selection, execute the method as described in the Case 1-5 above
+After execution: show the enhanced version, then ask `apply changes? (y/n/other)`, HALT, and re-present the menu.
 
-**Case: Direct Feedback:**
-
-- Apply changes to current section content and re-present choices
-
-**Case: Multiple Numbers:**
-
-- Execute methods in sequence on the content, then re-offer choices
-
----
-
-### Step 3: Execution Guidelines
-
-- **Method execution:** Use the description from CSV to understand and apply each method
-- **Output pattern:** Use the pattern as a flexible guide (e.g., "paths -> evaluation -> selection")
-- **Dynamic adaptation:** Adjust complexity based on content needs (simple to sophisticated)
-- **Creative application:** Interpret methods flexibly based on context while maintaining pattern consistency
-- Focus on actionable insights
-- **Stay relevant:** Tie elicitation to specific content being analyzed (the current section from the document being created unless user indicates otherwise)
-- **Identify personas:** For single or multi-persona methods, clearly identify viewpoints, and use party members if available in memory already
-- **Critical loop behavior:** Always re-offer the 1-5,r,a,x choices after each method execution
-- Continue until user selects 'x' to proceed with enhanced content, confirm or ask the user what should be accepted from the session
-- Each method application builds upon previous enhancements
-- **Content preservation:** Track all enhancements made during elicitation
-- **Iterative enhancement:** Each selected method (1-5) should:
-  1. Apply to the current enhanced version of the content
-  2. Show the improvements made
-  3. Return to the prompt for additional elicitations or completion
-
-## Output Format
+## Examples
 
-Interactive menu loop presenting 5 elicitation methods, then the enhanced content after each method application. Final output is the user-approved enhanced version of the original content.
+**Happy path** — `push deeper on this PRD section` → menu of 5 → user picks "Pre-Mortem" → analysis surfaces 3 blind spots → user approves → menu re-offered → user types `x` → return enhanced content to caller.
 
-## Workflow
+**Edge case — no content in context** — skill asks the user to provide or point to the content to enhance.
 
-1. Read the user request and extract key parameters.
-2. Execute the skill logic as described in the Overview.
-3. Return output in the format specified below.
+**Negative — wrong skill** — `review this code for bugs` is code review, not elicitation. Route to `rihal-code-review`.
 
-## Examples
+## Memory Bank Hooks
 
-### Happy path
-**User:** "push deeper on this PRD section"
-**Result:** Menu of 5 methods → user picks "Pre-Mortem" → analysis reveals 3 blind spots → user approves changes → re-offered menu → user selects 'x' to proceed
+- **Reads:** `methods.csv`, `.rihal/team.yaml` (agent_party), the section content being enhanced
+- **Writes:** the enhanced content is returned to the invoking skill — this skill does not write Memory Bank files itself
 
-### Edge case
-**User:** "elicit" (no content in context)
-**Result:** Skill asks user to provide or point to the content to enhance
+## Detailed reference
 
-### Negative boundary
-**User:** "review this code for bugs"
-**Result:** Not elicitation → route to `rihal-code-review` or `rihal-review-adversarial-general`
+See [`references.md`](references.md) for: the CSV schema, the full case-by-case response handler (1-5 / r / a / x / direct feedback / multiple numbers), execution guidelines, and HALT conditions.

package/rihal/skills/core/rihal-advanced-elicitation/references.md

@@ -0,0 +1,101 @@
+# Advanced Elicitation — Detailed Reference
+
+Detailed method registry semantics, response handling, and execution rules for [`SKILL.md`](SKILL.md).
+
+---
+
+## CSV schema (`methods.csv`)
+
+| Column | Meaning |
+|---|---|
+| `category` | Method grouping — core, structural, risk, etc. |
+| `method_name` | Display name shown in the menu |
+| `description` | Rich explanation of what the method does, when to use it, why it's valuable |
+| `output_pattern` | Flexible flow guide using arrows (e.g. `analysis → insights → action`) |
+
+The CSV is the single source of truth for available methods. Adding a method = adding a row.
+
+---
+
+## Smart selection (Step 3 of the process)
+
+Apply this when picking the 5 methods to surface:
+
+1. **Analyse context** — content type, complexity, stakeholder needs, risk level, creative potential.
+2. **Parse descriptions** — understand each method's purpose from the rich descriptions.
+3. **Select 5** — choose methods that best match the context based on their descriptions.
+4. **Balance approach** — include a mix of foundational and specialised techniques.
+
+Slot 1 and Slot 2 should be the most relevant for the section being enhanced — users skim before reading.
+
+---
+
+## Response handling (full case list)
+
+**Cases 1-5 — user selects a numbered method:**
+- Execute the method using its CSV description.
+- Adapt complexity and output format to the current context.
+- Apply creatively to the section content being enhanced.
+- Display the enhanced version showing what the method revealed or improved.
+- Ask `apply changes? (y/n/other)` and HALT.
+- On `y` → apply. On `n` → discard. Other → follow user's instructions as best as possible.
+- Re-present the menu.
+
+**Case `r` — reshuffle:**
+- Pick 5 random methods from the CSV.
+- Aim for diversity across categories.
+- Slot 1 and Slot 2 should still be the most useful for the current content.
+
+**Case `x` — proceed:**
+- Return the fully enhanced content to the invoking skill.
+- The enhanced content becomes the final version for that section.
+- Signal completion so the parent skill continues with the next section.
+
+**Case `a` — list all:**
+- Show every method with its description in a compact table.
+- Allow selection by name or number from the full list.
+- Then execute as if selected from cases 1-5.
+
+**Case — direct feedback:**
+- Apply the user's feedback to the current section content.
+- Re-present the menu.
+
+**Case — multiple numbers (e.g. `1,3`):**
+- Execute methods in sequence on the content.
+- Show the cumulative enhancement after each.
+- Re-present the menu.
+
+---
+
+## Execution guidelines
+
+- **Method execution.** Use the CSV description to understand and apply each method.
+- **Output pattern.** Treat the pattern as a flexible guide, not a contract.
+- **Dynamic adaptation.** Adjust complexity to content needs (simple to sophisticated).
+- **Creative application.** Interpret methods flexibly while maintaining pattern consistency.
+- **Stay relevant.** Tie elicitation to the specific content being analysed.
+- **Identify personas.** For single- or multi-persona methods, name viewpoints clearly. Use party members from memory if available.
+- **Loop behaviour.** Always re-offer the menu after each execution.
+- **Build cumulatively.** Each method runs against the current enhanced version, not the original.
+- **Track enhancements.** Maintain history so the user can see the trajectory.
+- **End on `x` or explicit user confirmation.**
+
+---
+
+## HALT conditions
+
+- HALT after presenting the menu — wait for user choice.
+- HALT after applying a method — wait for `y/n/other` on whether to keep the change.
+- HALT if `methods.csv` is missing or empty — report and exit.
+- HALT if the section content to enhance is missing — ask the user to provide it.
+
+---
+
+## Integration when invoked indirectly
+
+When the parent skill or workflow calls this skill mid-flow:
+
+1. Receive the section content that was just generated.
+2. Apply elicitation methods iteratively to enhance only that section.
+3. Return the enhanced version when the user picks `x`.
+4. The enhanced content replaces the original section in the parent's output document.

package/rihal/skills/core/rihal-auth-audit/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: rihal-auth-audit
+description: Audit Keycloak ↔ Active Directory sync, JWT validation, and tenant isolation in multi-org Postgres. Use when seeing authentication weirdness — users disappearing, tokens accepted post-deactivation, "phantom" sessions, or tenant data leaking across orgs. Specifically encodes the lessons from the Rihal Keycloak data-loss incident — sync drift between Keycloak and AD silently broke logins.
+triggers:
+  - "auth audit"
+  - "keycloak ad sync"
+  - "users disappearing"
+  - "ghost session"
+  - "tenant leak"
+  - "jwt validation check"
+  - "stale token"
+  - "session not invalidating"
+user-invocable: true
+---
+
+## Overview
+
+Authentication bugs are usually silent — the user just gets logged out, or worse, sees someone else's data. This skill encodes the specific failure modes that have actually bitten Rihal projects, with a runnable 10-minute checklist. Default scope is Keycloak + Active Directory + Postgres; adapt the specifics to whatever provider is in use.
+
+## The 10-minute checklist
+
+### Keycloak ↔ AD sync (the load-bearing one)
+
+- [ ] Keycloak's AD federation is configured with **periodic sync ENABLED**, not just on-login. Without periodic sync, a user deactivated in AD keeps working in Keycloak until their token expires.
+- [ ] Sync interval ≤ 1 hour for production. Longer windows are how the Rihal incident happened.
+- [ ] Sync errors land in Sentry, not just Keycloak's internal log. If sync silently fails, no one notices for weeks.
+- [ ] On AD deactivation, the corresponding Keycloak session is **explicitly invalidated** — don't rely on the JWT expiring.
+
+### JWT validation
+
+- [ ] `iss`, `aud`, `exp`, signature — all four checked on every protected request.
+- [ ] JWKS keys are **fetched dynamically with caching**, not pinned. Keycloak rotates them.
+- [ ] Clock-skew tolerance is ≤ 60s. Larger windows give attackers reuse room.
+- [ ] Token revocation list (or short TTL + refresh) is in place. Stateless JWTs are a CVE waiting for "logout doesn't actually log out".
+
+### Tenant isolation in Postgres
+
+- [ ] Every query that reads tenant data has `WHERE tenant_id = $1` where `$1` is **derived from the JWT**, never from a request parameter or cookie.
+- [ ] Postgres Row-Level Security (RLS) policies are enabled OR a query middleware enforces tenant_id (belt + suspenders preferred).
+- [ ] No raw SQL strings interpolate tenant_id — always parameterised.
+- [ ] Audit log captures the tenant_id from the JWT for every write.
+
+### Session lifecycle
+
+- [ ] Password change → ALL sessions for that user invalidated (not just the current device).
+- [ ] Permission change (role removed) → token re-validation forced on next request.
+- [ ] Logout actually deletes the server-side session record, not just the cookie.
+
+## Workflow
+
+1. **Inventory the auth surfaces.** Login, refresh, password reset, role change, permission change, logout, OAuth callbacks if present.
+2. **Run the checklist** above for each surface. Cite the actual file and line for each pass / fail.
+3. **For each fail:** write a malicious test case before fixing — the test is the proof of regression-locked.
+4. **Persist findings** to `.rihal/memory/incidents/known-issues.md` if not fixable in this session, or `.rihal/memory/change-records/` if fixed.
+
+## Output Format
+
+```
+Auth audit — <date>
+Surfaces: <count>
+
+Keycloak ↔ AD sync:
+  ✓ periodic sync enabled (interval: <X>)
+  ✗ sync errors not in Sentry
+  ⚠ <other findings>
+
+JWT validation:
+  ✓ all 4 fields checked
+  ⚠ <other>
+
+Tenant isolation:
+  ✗ <table>.<query> missing tenant_id filter — file:line
+
+Session lifecycle:
+  ✓ <findings>
+
+Critical (block launch / production): <count>
+High (fix this sprint): <count>
+Medium (track in known-issues.md): <count>
+```
+
+## Examples
+
+**Happy path — sync drift caught** — Audit shows Keycloak sync is configured but interval is 24h, and errors aren't in Sentry. Findings: 2 critical. Fix: drop interval to 1h + wire sync errors to Sentry. Verify by deactivating a test user in AD and confirming Keycloak removes them within 1h.
+
+**Edge case — RLS enabled but middleware bypasses it** — Postgres RLS is on, but the Strapi controllers use a service-role connection that bypasses RLS. Findings: critical. Fix: switch to per-request connections with the user's JWT-derived role.
+
+**Negative — "we use OAuth so we're fine"** — Refuse. OAuth ≠ correctly-configured. Run the checklist anyway.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rihal/memory/incidents/post-mortems/` (prior auth incidents), `.rihal/memory/project/stack.md` (auth provider)
+- **Writes:** `.rihal/memory/incidents/known-issues.md` (deferred); `.rihal/memory/change-records/YYYYMMDD-NNN.md` (the audit itself)

package/rihal/skills/core/rihal-brainstorming/SKILL.md

@@ -96,3 +96,8 @@ Follow the instructions in ./workflow.md.
 ### Negative boundary
 **User:** "brainstorm which tech stack to use"
 **Result:** Redirects to `/rihal:council` or Waleed (CTO) — architecture decisions need structured ADR evaluation, not open ideation.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rihal/memory/project/glossary.md` (so generated ideas use project domain terms)
+- **Writes:** the brainstorm output document at the user-specified path; if any idea becomes a committed direction, the user should run `rcode-memory-update` to log it as a decision

package/rihal/skills/core/rihal-client-gate/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: rihal-client-gate
+description: Client requirement freeze gates and async-comm patterns to stop late requirements from derailing delivery. Use when a project keeps slipping because the client adds requirements mid-sprint, or when the client takes a week to respond to a blocking question. Specifically encodes Rihal's "client late requirements caused project delays" pain — the fix isn't to "communicate better", it's structural gates that the project actually enforces.
+triggers:
+  - "client gate"
+  - "freeze requirements"
+  - "scope creep"
+  - "client slow response"
+  - "requirements freeze"
+  - "client comm pattern"
+  - "stop late requirements"
+  - "delivery slipping"
+user-invocable: true
+---
+
+## Overview
+
+Late client requirements aren't the client's fault — they're the project's structural failure to define when input is welcome and when it's not. This skill installs three gates: a **scope freeze** at sprint start, a **decision deadline** for blocking questions, and a **change-control** path for everything that arrives after the freeze. Without these, every client comment becomes a potential mid-sprint pivot.
+
+## The 3 gates
+
+### Gate 1 — Scope freeze at sprint start
+
+- Sprint scope is locked at sprint kickoff, in writing, with the client signing off.
+- "Locked" means: no new stories enter the sprint without going through Gate 3 (change control).
+- The scope doc lives in `.rihal/memory/milestones/current.md` (not just a Slack message).
+- Sign-off is explicit — a thumbs-up emoji doesn't count. Email or document sign-off.
+
+### Gate 2 — Decision deadline for blocking questions
+
+- Every blocking question to the client carries a deadline: e.g. "we need an answer by Wed EOD or we ship the default option".
+- Deadlines are enforced — when missed, the team picks the documented default and moves on.
+- Defaults are documented BEFORE asking — "if you don't reply, we'll do X".
+- Stakeholder response cadences from `.rihal/memory/people/stakeholders.md` inform the deadline (don't give a 24h deadline to a stakeholder with a documented 1-week cadence).
+
+### Gate 3 — Change control after the freeze
+
+- Anything new that arrives after the sprint kickoff goes into a queue, not the current sprint.
+- Each change-request gets evaluated weekly:
+  - **Critical** (broken core flow, security): emergency mid-sprint slot — but explicit, with a story shipped late.
+  - **High** (next sprint priority): goes to top of next sprint's backlog.
+  - **Medium / nice-to-have**: parked, reviewed at next milestone.
+- Client sees the queue; transparency prevents "where did my request go?" friction.
+
+## Workflow
+
+1. **At project kickoff:** install the 3 gates. Walk the client through them — explain that this is how delivery dates stay credible.
+2. **At each sprint kickoff:** run Gate 1. Write down the scope. Get sign-off.
+3. **Throughout the sprint:** any blocking question gets Gate 2 (deadline + default). Any new requirement gets Gate 3 (queue).
+4. **At sprint close:** review the change queue with the client. Triage.
+5. **Persist all gate events** to `.rihal/memory/people/stakeholders.md` and the change-records folder. The pattern of "client always responds Friday afternoon" becomes a planning input.
+
+## Output Format
+
+For each sprint:
+
+```
+Sprint kickoff — <date>
+Scope (signed off by <client>):
+  - Story 1
+  - Story 2
+  ...
+
+Active blocking questions:
+  Q1 (asked <date>, deadline <date>): <question>
+  Default if no answer: <documented default>
+
+Change queue (post-freeze):
+  Critical:   <count>
+  High:       <count>
+  Medium:     <count>
+
+Memory Bank update:
+  → .rihal/memory/milestones/current.md (scope sign-off)
+  → .rihal/memory/people/stakeholders.md (cadence observations)
+```
+
+## Examples
+
+**Happy path — government client** — Client has documented 1-week response cadence. Gate 2 deadline becomes 5 days, with a default ("we'll go with option B unless you reply"). Project ships on time despite slow comms.
+
+**Happy path — scope freeze enforced** — Day 4 of sprint, client adds 3 requirements. Gate 3 queues all 3. Client sees them in the next-sprint backlog. No mid-sprint pivot.
+
+**Edge case — "but this requirement is critical"** — Run the Gate 3 critical-or-not test: does this break a core flow? Is it a security issue? If yes, emergency mid-sprint slot with explicit story shipped late. If no, it's a next-sprint priority. Don't let "critical" be a synonym for "I'd really like this".
+
+**Negative — "we'll just be more flexible"** — Refuse. Flexibility without gates is how every Rihal-style late-requirements incident happens. Gates make the flexibility explicit and survivable.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rihal/memory/people/stakeholders.md` (response cadences), `.rihal/memory/milestones/current.md`
+- **Writes:** scope sign-offs to `.rihal/memory/milestones/current.md`; client change requests to `.rihal/memory/change-records/YYYYMMDD-NNN.md`