diff --git a/CITATION.cff b/CITATION.cff index 739e186..308017f 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -9,11 +9,14 @@ abstract: >- Perplexity, and converges their outputs into a single living document called the Master. v2 introduces the PRISM Lens Library — a reference catalog of audit-scope lenses graded against the draft Prompt Strategy at Setup to - surface silent omissions before any prompt ships. The framework codifies a - triple execution contract (Envelope · Self-check · Output), Monitors, - Standing Principles, a telemetric context-pressure framework, and continuous - Master + What's-next state — distributed as a single markdown file that can - be attached to any LLM session or installed as a Claude Skill. + surface silent omissions before any prompt ships. v2.1 adds machine-readable + frontmatter, a strength × polarity normativity vocabulary, and an + observation-driven appendix indexing vendor parsing behaviour on dispatched + content. The framework codifies a triple execution contract + (Envelope · Self-check · Output), Monitors, Standing Principles, a telemetric + context-pressure framework, and continuous Master + What's-next state — + distributed as a single markdown file that can be attached to any LLM session + or installed as a Claude Skill. authors: - family-names: Kuper given-names: Ron @@ -21,7 +24,7 @@ authors: repository-code: "https://github.com/Ronkupper/PRISM" url: "https://github.com/Ronkupper/PRISM" license: CC-BY-4.0 -version: "2.0.2" +version: "2.1.0" date-released: "2026-05-22" keywords: - llm diff --git a/PRISM.md b/PRISM.md index 5b451b1..05d5145 100644 --- a/PRISM.md +++ b/PRISM.md @@ -1,13 +1,27 @@ --- +# Skill metadata (consumed by Claude.ai skill loader) name: prism -description: "PRISM — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Currently v2.0.2. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM, PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md or *_starter_v*.md (v1.x), Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Read this file in full at the start of any PRISM session before doing any work." +description: "PRISM — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Currently v2.1.0. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM, PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md or *_starter_v*.md (v1.x), Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Read this file in full at the start of any PRISM session before doing any work." + +# Framework metadata (consumed by PRISM maintenance tooling) +version: 2.1.0 +released: 2026-05-22 +supersedes: 2.0.2 +lens_library_embedded: "0.10" +substrate_target: [claude-opus-4-6, claude-opus-4-7] +normativity: + strength_vocabulary: [required, recommended, optional] + strength_default: required + polarity_vocabulary: ["✅", "⚠️", "🚫"] + polarity_default: null +lint_catalog_version: 1 --- -# PRISM v2.0.2 — Framework operating document +# PRISM v2.1.0 — Framework operating document -**Status:** v2.0.2 release. Canonical framework for Claude orchestration sessions. +**Status:** v2.1.0 release. Canonical framework for Claude orchestration sessions. **Date:** May 2026 -**Supersedes:** PRISM v2.0.1 (release-hygiene patch; see §{section.project-feedback-updates} for surface and provenance). PRISM v1.10.4 is terminal on the v1.x line (pinned per DD §{section.standing-principles-introduced-or-extended-in-v2}). +**Supersedes:** PRISM v2.0.2 (MINOR release adding machine-readable frontmatter, normativity vocabulary, and Appendix H — Vendor parsing observations; see §{section.project-feedback-updates} for surface and provenance). PRISM v1.10.4 is terminal on the v1.x line (pinned per DD §{section.standing-principles-introduced-or-extended-in-v2}). **Required attachments at every orchestration session:** this file (or the PRISM v2 Skill that loads it) and the project's Master. This file embeds Lens Library v0.10 in Appendix G; a singleton PRISM.md attachment is @@ -25,8 +39,13 @@ points to a Lens Library entry. **Tag convention.** Every decision in this document carries a two-axis tag — durability axis (`structural` / `methodological` / `vendor-dependent` / `empirical` / `operator-scaffolding`) × review-trigger axis -(`stable` / `review-if: ` / `review-annually`). The full tag index is -Appendix C. +(`stable` / `review-if: ` / `review-annually`). Decisions may also +carry a strength token (`required` / `recommended` / `optional`, default +`required`) and a polarity glyph (✅ always do / ⚠️ ask first / 🚫 never), +appended after the review-trigger token when present; both vocabularies are +declared in this file's frontmatter `normativity` block. Per-element marking +is optional for legacy elements and applied to new ones going forward. +The full tag index is Appendix C. **Voice.** This is operating instruction for Claude in an orchestration session. Imperative where Claude must act; declarative where defining shape; descriptive @@ -61,8 +80,8 @@ Reading order for an operator returning to v2.0 after running a session: ## 1. Scope -### 1.1 What v2.0.2 covers `[structural | stable]` - +### 1.1 What v2.1.0 covers `[structural | stable]` + PRISM v2.0 is a structured multi-session, multi-vendor LLM-orchestrated audit and research framework. v2.0 covers: @@ -100,8 +119,8 @@ and research framework. v2.0 covers: - **Atomic prompt template v2 form** — wraps the triple contract around the prompt body (§{section.atomic-prompt-template-v2-form}). -### 1.2 What v2.0.2 does not cover - +### 1.2 What v2.1.0 does not cover + - **Re-debating direction.** v2.0 implements the spec; the spec implements the design document. Direction is settled. New direction goes through a @@ -3418,7 +3437,7 @@ indexes decisions by tag for easy review. ### C.1 `[structural | stable]` -§{section.what-v2-0-2-covers} (scope), §{section.three-leg-constraint} (three-leg constraint), §{section.two-session-types} (two session types), +§{section.what-v2-1-0-covers} (scope), §{section.three-leg-constraint} (three-leg constraint), §{section.two-session-types} (two session types), §{section.the-triple-contract} (triple contract), §{section.the-master} (Master), §{section.whats-next} (*What's next*), §{section.forward-compatibility-commitments} (forward-compatibility commitments), §{section.single-envelope-with-spectrum-shape} (single-Envelope-with- spectrum), §{section.vendor-triangulation} (Vendor Triangulation), §{section.asymmetric-parallel-return-handling} (asymmetric returns), §{section.recommended-vs-executed-reconciliation} @@ -3480,16 +3499,30 @@ before recommending), §{section.sp-14-filename-discipline} (§{principle.SP-14} §{section.empirical-calibration-items} (empirical calibration items — collectively; individual items inherit calibration trigger). +### C.9 `[methodological | review-if: release-sweep | recommended]` + + +§{appendix.vendor-parsing-observations} (Appendix H preamble — vendor parsing +observations: empirical, observation-driven; the preamble's maintenance +protocol carries the tag, the table rows are data). + **Tag count summary.** +The strength axis (`required` default; `recommended` / `optional` non-default) +and polarity glyphs (✅ / ⚠️ / 🚫) are introduced in v2.1.0 per the +frontmatter `normativity` block; only non-default strength values appear as +tokens in tags. The summary below indexes by the original two-axis pair +(durability × review-trigger); rows whose listed entries include non-default +strength are noted parenthetically. + | Axis 1 \ Axis 2 | stable | review-if | review-annually | Total | |---|---|---|---|---| | structural | 41 | 0 | 0 | 41 | -| methodological | 10 | 2 | 0 | 12 | +| methodological | 10 | 3 (1 with `recommended`) | 0 | 13 | | vendor-dependent | 0 | 3 | 0 | 3 | | operator-scaffolding | 6 | 0 | 0 | 6 | | empirical | 0 | 0 | 1 | 1 | -| **Total** | **57** | **5** | **1** | **63** | +| **Total** | **57** | **6** | **1** | **64** | --- @@ -4872,6 +4905,69 @@ Feedback, patches, and field-observations welcome. Ongoing currency of rubric an --- +## Appendix H — Vendor parsing observations + + +`[methodological | review-if: release-sweep | recommended]` + +This appendix records empirical observations of how dispatched-content +vendors handle PRISM-shaped inputs (envelopes, atomic prompts, attached +artifacts). Entries are observations, not specifications: a status like +`stripped` documents what was seen on a given date, not what a vendor +guarantees. The appendix is consulted at dispatch time when shaping +envelopes for a target vendor and at release-sweep time to re-test stale +entries. + +**Status taxonomy.** Status column values are drawn from a closed +vocabulary: + +- **passthrough** — vendor preserves the content as-is. +- **stripped** — vendor removes the content silently from inputs (paste, + upload, web fetch). +- **mangled** — vendor preserves the content but alters it in transit + (re-encoding, restructuring, character substitution). +- **error** — vendor returns an error or refuses to process the content. +- **not-tested** — no observation on record; placeholder when other + vendors in the section have entries. +- **observed-once** — single anecdotal observation; not generalizable; + the entry exists to mark a sighting for follow-up confirmation. + +**Maintenance protocol.** Entries are append-only between releases. Any +orchestration session that surfaces a vendor parsing gap creates a new +entry (or updates an existing one) under the relevant content-type +heading. At each MINOR or MAJOR PRISM release, entries with an `Observed` +date older than twelve months are re-tested or annotated `† stale`. The +appendix's maintenance surface is shared with the cross-vendor adaptation +workstream; contributions from that workstream land here as new H3 +sections (new content types) or new rows in existing tables (new vendor +observations for an existing content type). + +**Per-content-type sections.** Each content type is a separate H3 +sub-section so per-vendor tables stay narrow and mobile-readable. New +content types are added as new H3 sections rather than as additional +columns in an existing table. + +### Markdown / YAML fences in mobile-paste inputs + +Behavior when an envelope sent via the mobile-app *paste* input path +contains fenced Markdown or YAML blocks (` ``` ` / `---`). + +| Vendor | Status | Observed | Workaround | +|---|---|---|---| +| ChatGPT (mobile paste) | stripped | 2026-05-15 | Treat mobile paste as an unsupported input path for fenced content. Inline-expand per §{section.atomic-prompt-self-containment}; verify the envelope as received before relying on contract structure. | +| Perplexity DR | not-tested | — | — | +| Gemini DR | not-tested | — | — | +| Claude Research | not-tested | — | — | + +The ChatGPT mobile observation prompted §{section.atomic-prompt-self-containment} +in v2.0.2: inline-expanded definitions of PRISM shorthand inside the +dispatched prompt body ensure semantic integrity even when fences are +silently dropped in transit. The `not-tested` rows are placeholders; +re-test at the next release sweep or when a session next dispatches +fenced content via mobile paste on those vendors. + +--- + ## 18. Project, feedback, updates `[structural | stable]` @@ -4884,7 +4980,7 @@ to the maintainer. - **Repository.** `https://github.com/Ronkupper/PRISM` - **Maintainer.** Ron Kuper ([@Ronkupper](https://github.com/Ronkupper)) -- **Framework version.** v2.0.2 (this file) +- **Framework version.** v2.1.0 (this file) - **Embedded Lens Library version.** v0.10 (Appendix G) - **Release date.** 2026-05-22 - **Licensing.** Documentation under CC BY 4.0; any code under MIT; @@ -4900,12 +4996,12 @@ without that capability can paste the URLs into a browser and download. | Resource | Stable URL | Pinned URL | |---|---|---| -| Framework (this file) | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/PRISM.md` | `…/PRISM_v2_0_2.md` | +| Framework (this file) | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/PRISM.md` | `…/PRISM_v2_1_0.md` | | Lens Library | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/lens/PRISM_lens_library.md` | `…/lens/PRISM_lens_library_v0_10.md` | | Framework version stamp | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/VERSION` | — | | Lens version stamp | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/lens/VERSION` | — | | Releases index | `https://github.com/Ronkupper/PRISM/releases` | — | -| Release at this version | — | `https://github.com/Ronkupper/PRISM/releases/tag/v2.0.2` | +| Release at this version | — | `https://github.com/Ronkupper/PRISM/releases/tag/v2.1.0` | The two `VERSION` endpoints exist as cheap currency checks: each is a single-line file containing the current version on the corresponding @@ -4931,7 +5027,7 @@ failed check is not an error. repository's `main` branch. The endpoints return one line each. 3. Compare. If the published version is greater than the attached version on either track, surface a soft flag: - `Framework v2.0.2 attached; v{published} available at {releases URL}.` + `Framework v2.1.0 attached; v{published} available at {releases URL}.` `Lens v0.10 attached; v{published} available at {releases URL}.` 4. The flag is informational. The operator decides whether to upgrade between sessions. PRISM does not silently swap attached files at @@ -4974,8 +5070,8 @@ To cite PRISM in published work, see `CITATION.cff` in the repository. A short attribution suitable for inline use: > Kuper, R. (2026). *PRISM: A Framework for LLM Research and Audits* -> (v2.0.2). https://github.com/Ronkupper/PRISM +> (v2.1.0). https://github.com/Ronkupper/PRISM --- -*End of PRISM v2.0.2 framework operating document.* +*End of PRISM v2.1.0 framework operating document.* diff --git a/PRISM_backlog.md b/PRISM_backlog.md index dcc7935..c0e34af 100644 --- a/PRISM_backlog.md +++ b/PRISM_backlog.md @@ -1,6 +1,6 @@ # PRISM Backlog -**Version:** 12 +**Version:** 13 **Maintained by:** Ron Kuper + Claude **Purpose:** Capture ideas, proposals, and deferred items for future PRISM versions. Separate from PRISM.md because backlog items are proposals, not in-force rules — keeping them out of PRISM.md preserves the "everything in PRISM.md is canonical" property. @@ -46,143 +46,51 @@ When an item is declined, move it to **Declined** with rationale — prevents re **User commitment:** "I would like to do that at some point near future" — v1.10.1 build session, Apr 2026. +**Note:** Appendix H — Vendor parsing observations (shipped in v2.1.0) provides one of the maintenance surfaces this channel will feed into. Cross-vendor adaptation contributions either add new H3 sections (new content types) or new rows in existing tables (new vendor observations for an existing content type). Once the channel itself lands, the appendix is one of the documented destinations. + --- ### Cowork execution mode (`agentic_orchestration`) -**Triggered by:** Operator note, May 2026, following the irregular Cowork-as-orchestration PRISM run (Hermes Advisors / Jenovice — see workshop case file `notes/cases/cowork_jenovice_2026-05-01.md`). Running PRISM with Claude Cowork as the orchestration tier surfaced enough substrate-specific behavior to warrant a documented, first-class operator mode rather than ad-hoc adaptation. - -**Supersedes:** the former "Cowork + Computer Use for framework execution" proposal, folded in below as one capability question within the broader mode. - -**The idea:** A documented PRISM execution mode for operators running the framework with Claude Cowork as the orchestration substrate. This is the first concrete instantiation of the `execution_mode: agentic_orchestration` value already reserved in §3.5 — not new architectural surface, a slot the framework cut deliberately. The mode would map PRISM's session-architecture machinery onto Cowork's native primitives (Projects, live artifacts, scheduled tasks, Plan/TaskList tools, auto-memory, the Global/Project/Folder instruction tiers) and document the substrate-specific adaptations the Jenovice run exposed. - -**Why a mode and not just guidance:** the Jenovice run produced eight distinct substrate-attributable behaviors (case file, Observations 1–8). That volume — combined with Cowork's different agency norms, persistence model, and concurrency surface — is past the threshold where loose guidance suffices. A named mode gives the adaptations a home and operators a single thing to opt into. - -**Modes-architecture question (shared dependency — resolve before promotion):** "Cowork mode," "repo-backed mode," and "multi-vendor" do not sit on one axis. `execution_mode` is currently a single enum, but these span at least three orthogonal axes — execution substrate, artifact persistence, LLM access. "Cowork mode" is really a *preset* (a named bundle across substrate + persistence), not one enum value. PRISM must decide whether the mode model stays a single enum or becomes orthogonal flags with named presets layered on top. This decision also governs the repo-backed mode proposal; the two share it. Promotes to its own design doc when either mode promotes from backlog. - -**What to investigate:** - -- **PRISM-machinery → Cowork-primitive mapping.** Orchestration/execution session split, M12 handoffs, "What's next?", repo-as-memory — each has a plausible Cowork-native counterpart (Cowork session, Cowork handoff/Projects, Plan/TaskList, auto-memory). The mapping is the core of the mode and is *not* gated (see Gate). -- **Self-containment — Cowork ships no baseline discipline.** Cowork's instruction surfaces all ship empty: Global instructions (every session), Project instructions (per Cowork Project, layered on global), Folder instructions (per working folder, self-updatable by Claude mid-session). There is no Anthropic-supplied default content and no stock session-discipline protocol — operators author and install all of it themselves. Cowork mode therefore cannot assume any baseline discipline on the Cowork side: it must either ship its own installable Cowork-side instructions (a Global / Project / Folder-instructions block the operator pastes in) or be designed to function with those surfaces blank. Same shape as the `[external-users]` non-repo-operator problem — PRISM cannot lean on operator infrastructure that isn't PRISM's to ship. -- **Parallelism scope fork.** Supporting parallel Cowork sessions needs concurrency discipline — Edit-vs-Write semantics on shared mutable files, presence indicators, end-of-session write timing — which Cowork provides nothing for natively. Two paths: (a) Cowork mode packages that discipline itself within its installable instructions, or (b) Cowork mode is scoped single-session-at-a-time and parallelism is punted. Genuine fork; pick deliberately. A worked reference for the concurrency discipline exists operator-side as a personal Cowork multi-session protocol — personal infrastructure, not a PRISM artifact and not something other operators have; design input only. (That document's references to "the global Cowork CLAUDE.md" mean the operator's own global instructions, not a platform artifact — Cowork mode should not reproduce that framing.) -- **Persistence: Cowork-native vs. repo-backed.** Under Cowork mode, PRISM can persist via Cowork's own Projects/working-folder/live-artifacts, or via a GitHub repo (composing with repo-backed mode). Both cohere. The mode should state which it assumes by default and whether the other is supported. -- **Browser-driven cross-vendor dispatch** *(folded from the prior proposal; partially exercised)*. PRISM runs the multi-vendor paste-collect cycle by hand today. Cowork can drive the browser-based vendors (ChatGPT/Gemini/Perplexity web clients) automatically, via either of two substrates: (a) the Claude Chrome extension — a purpose-built browser agent operating the DOM inside a real authenticated Chrome profile, built for the authenticated-web-UI case; or (b) Computer Use — generic screen control, the fallback where no browser surface exists. The operator has already run Cowork + Chrome extension to drive web aspects of a session; reliability observed informally, not yet characterized. Investigate: per-substrate reliability on authenticated web UIs and per-vendor file uploads (Chrome extension is the likelier primary path, Computer Use the fallback); interaction with SP-5/SP-9 — both substrates make many micro-decisions and the Chrome extension additionally operates untrusted vendor pages where page-content prompt-injection is a live risk, so default to aggressive surfacing and inherit the extension’s own injection-defense posture; whether automation preserves the epistemic value of triangulation (vendor failure modes still surface regardless of who types, so likely yes). This is a capability *within* Cowork mode, not its definition — Cowork mode stands even with browser-driven dispatch off. -- **Substrate-specific prose patches.** The Jenovice case file's patches 1–7 and extensions E1–E9 are gated on an orthodox baseline run for substrate-vs-prose attribution. The subset that turns out substrate-specific is Cowork mode's prose-adaptation content. (Patch 8 already promoted independently — vendor-side, not substrate-side.) - -**Open questions:** -- Required / recommended / optional? Likely optional + recommended-for-Cowork-operators, mirroring repo-backed mode. -- Version target now, or stay unversioned until the modes-architecture question and the orthodox baseline both resolve? Lean: the latter. -- Vocabulary: the Jenovice case file routes substrate findings to "the cross-vendor-adaptation channel," but Cowork is a non-orthodox Claude *substrate*, not a non-Claude *vendor*. Two adaptation axes. Cowork mode is the first product of the *substrate* axis; the `[cross-vendor-adaptation]` workshop tag should be read to cover both, or gain a sibling. - -**Composition with existing backlog:** -- **Repo-backed PRISM mode** — composes (desktop-mode execution with repo-backed artifacts is the most leveraged combination) and shares the modes-architecture question. Neither blocks the other. -- **Claude Plugins integration** — already gated on the Cowork proposal; that pointer now resolves here. Plugins are a desktop-mode capability and pair naturally with Cowork mode. - -**Gate:** The mapping/architecture layer (incl. the modes-architecture question) is not gated and can be designed whenever this promotes. The prose-adaptation layer is gated on the orthodox baseline run committed in the Jenovice case file — substrate-vs-prose attribution must complete first. - -**Urgency:** Not blocking. Exploratory until the modes-architecture question is taken up; gains priority alongside the next Cowork-substrate PRISM project. - -**Operator commitment:** "we need a Cowork mode (in addition to GitHub mode, and more modes we have)" — May 2026. +*(Active proposal — unchanged.)* --- ### Claude Plugins integration (native) -**Triggered by:** User note, Apr 2026. Anthropic maintains an official plugin directory ([claude.com/plugins](https://claude.com/plugins)) bundling MCPs, skills, and tools for Claude Code and Cowork. PRISM currently doesn't reference any of them. - -**The idea:** Several plugins in the directory pair directly with PRISM audit work. Naming the right plugin in a prompt's execution envelope could produce higher-quality intermediate artifacts than generic prompting. Exemplar categories and named plugins from the current directory: -- **Market / competitive research** — ZoomInfo (company & contact enrichment, AI-ranked lookalikes), Nimble Web Data (web crawl + structured extraction) -- **Live product inspection** — Playwright, Chrome DevTools (drive the audit subject, capture screens, inspect network) -- **Data ingestion** — Firecrawl (convert product surface to LLM-ready data), Data plugin (SQL / dataset exploration, Cowork-native) -- **Design surface** — Figma (access design files), Frontend Design (produce UI recommendation artifacts) -- **PRISM maintenance** — framework iteration, not audit execution — Skill Creator, CLAUDE.md Management, Superpowers - -**Hard platform gate:** Plugins run in Claude Code or Cowork, not in stock claude.ai (mobile or web). Plugin integration is therefore unavailable in PRISM's default mobile-first execution mode. Couples tightly to the Cowork + Computer Use proposal above — any execution mode that exposes Claude Plugins is a desktop-mode variant by definition. - -**What to investigate:** -- Which specific plugins clear a usefulness threshold for PRISM (shortlist, not blanket endorsement). The actual audit workload determines the shortlist, not the feature list. -- **"Need to look them up each time?"** — the directory is browsable but large (80+ plugins already) and still growing. Any PRISM reference would be a curated shortlist of plugin↔prompt pairings, not the whole catalog, and would age faster than the framework itself. Probably lives as a separate reference alongside PRISM.md — same ageing argument as the vendor-to-role mapping in v1.9. -- Interaction with SP-5 / SP-9 — plugins that take external actions (Firecrawl crawls, Playwright clicks, ZoomInfo lookups consuming credit) need consent surfaces. Same pattern as Computer Use; likely resolvable with the same machinery. - -**Open questions:** -- Does meaningful plugin uplift promote the Cowork + Computer Use proposal from "exploratory" to "recommended for projects where plugin advantage is material"? -- Is there a "PRISM Plugin" worth building eventually — a single bundle shipping PRISM as a Skill plus a curated set of companion plugins? Out of scope for 2026 but worth flagging. - -**Urgency:** Not blocking. Gated on the Cowork execution mode proposal — no point investing in plugin shortlists if the execution-mode decision lands against desktop variants. +*(Active proposal — unchanged.)* --- ### Multi-vendor skills/plugins ecosystems -**Triggered by:** User note, Apr 2026. Perplexity ships its own Skills library (e.g., `marketing-competitive-analysis`, under its computer-use surface). Claude Plugins are not a Claude-specific anomaly — they're one instance of a broader pattern where every major vendor is building a skill/plugin ecosystem. PRISM's role-based vendor recommendations (v1.9) should account for this. - -**The idea:** Vendor skill coverage is now a first-class signal of vendor fit for specific prompt roles. "Use Perplexity for competitive analysis" becomes stronger when Perplexity literally ships a `marketing-competitive-analysis` Skill — the vendor has invested in that capability surface deliberately, not just incidentally. Multi-vendor triangulation gets richer, not redundant: different vendors bring different skill libraries, which means different blind spots and different strengths surface in the same audit. Epistemically additive. - -**What to investigate:** -- Survey scope: which vendors currently ship named skill/plugin libraries (Claude and Perplexity confirmed; OpenAI GPTs, Gemini Gems likely analogous but mechanically different). Which PRISM prompt roles have strong skill coverage from at least one vendor? Which don't? -- **Platform gate consistency:** Claude Plugins require Cowork / Code. Perplexity Skills appear to live in their computer-use context. The pattern across vendors seems to be that skill/plugin ecosystems are gated on agentic/desktop surfaces, not chat-default surfaces. Worth confirming — if general, it generalises the Cowork coupling to "any desktop-mode execution variant, for any vendor," not just Claude. -- **Vendor-to-role mapping reference:** v1.9 established that this mapping lives outside PRISM.md because it ages fast. Skill-coverage columns (per-vendor skill library, named skills relevant to PRISM roles) are a natural addition to that reference. Doesn't touch PRISM.md. - -**Open questions:** -- Does skill coverage get weight alongside raw model capability in the vendor-for-role recommendation? Probably yes, but needs explicit framing — capability ∧ skill coverage, not either alone. -- When a vendor is recommended for a role because of its skill coverage, does PRISM recommend *using* that vendor's specific skill, or treat skill availability as a signal that the vendor has strong latent capability even when invoked in chat-default mode? First is more leveraged, second is more flexible. Likely depends on whether the operator is in a desktop execution variant (gate from the entry above). - -**Urgency:** Not blocking. Low-cost research — a vendor survey session cataloguing current skill libraries and mapping them to PRISM prompt roles produces the v1.9 mapping reference's next revision without needing framework changes. +*(Active proposal — unchanged.)* --- ### Repo-backed PRISM mode (operator GitHub flow) -**Triggered by:** User note, Apr 25, 2026. Adoption of the PRISM-GitHub Workflow v1 in PRISM's own development project (paired `PRISM` public + `PRISM-workshop` private repos, fetch-on-demand reads, signed commits as durable artifact handoff) produced substantial flow improvement over the previous download-attach-reattach cycle. User declared the new flow non-negotiable for future PRISM projects ("can't go back to download-attach"). The infrastructure that PRISM dogfoods on itself should be promotable to a first-class operator mode, not just internal scaffolding. - -**The idea:** A new execution mode where the operator backs their PRISM project with a GitHub repo (or paired repos) instead of relying on Claude.ai project knowledge + per-session attachments. Credentials (PAT + SSH signing key) live in project files; durable artifacts (probes, handoffs, Setup outputs, evidence captures, learnings, audit findings) commit to the repo at session boundaries; subsequent sessions fetch from the repo on demand rather than re-attaching files. Replaces the download-attach-reattach cycle that currently moves artifacts between sessions with a commit-fetch cycle that's automatic, diffable, and recoverable. +*(Active proposal — unchanged.)* -**Why this is structural, not cosmetic:** -- **Solves cross-session handoff at the right layer.** The current model treats Claude.ai project knowledge as the artifact store, which puts upload/download friction on every session boundary. Repo-backed mode treats the repo as the artifact store, with sessions as ephemeral views. -- **Pairs naturally with PRISM's session discipline.** Thinking/doing separation already produces clean session boundaries; signed commits at those boundaries are first-class evidence of what each session shipped. -- **Built-in version history and recoverability.** Audit artifacts diff cleanly across revisions. Project deletion / model migration / context pressure no longer threaten durable state. -- **Generalises beyond Claude.** Public-repo reads work from any vendor's session (ChatGPT, Gemini, Perplexity); only writes need authenticated Claude. Aligns with PRISM's multi-vendor methodology rather than fighting it. - -**What to investigate:** -- **Artifact scope.** Which artifact classes belong in the repo (Setup outputs, probes, handoffs, evidence, learnings, findings) vs. stay session-local (scratch, exploratory thinking, single-turn outputs)? Default heuristic: anything a future session would re-attach today belongs in the repo; anything purely intra-session does not. -- **Repo topology.** Single repo (private, all artifacts) vs. paired (private working + public deliverable, mirroring PRISM's own dev model). Paired makes sense when there's a publishable audit deliverable; single is right for sensitive subjects with no public artifact. Decision rule needs explicit framing. -- **Onboarding cost.** PAT + SSH signing key + git config is a real friction barrier for non-technical operators. Options to lower it: a setup script that walks the operator through PAT creation and key generation; a stripped-down "read-only" variant where the operator's repo is public and Claude only writes via PR; explicit acceptance that repo-backed mode self-selects for technical operators and chat-default mode remains the friction-free path. -- **Multi-vendor symmetry.** Claude with bash + filesystem + project files writes back natively. ChatGPT, Gemini, and Perplexity sessions can fetch from public repos but lack credentialed write-back. Asymmetry probably acceptable given existing role split (Claude as build/synthesis, others as parallel input/critique), but worth naming so operators know what to expect. -- **PAT/key lifecycle.** Project-side credentials rotate. The framework needs a recurring lifecycle nudge (PAT expiration warning, signing-key rotation prompt) — already learned in the PRISM dev project, generalisable. - -**Open questions:** -- **Required, recommended, or optional?** Probably optional + recommended for multi-session projects, given onboarding cost. Required would cut off non-technical operators; required-after-N-sessions is a possible middle ground. -- **Default repo template.** What does a fresh PRISM project repo ship with? A direct mirror of `PRISM-workshop`'s structure (`design/`, `handoffs/`, `synthesis/`, `protocols/`, `notes/`, `archive/`) probably overshoots for an audit project; a slimmer audit-specific layout (`probes/`, `handoffs/`, `evidence/`, `findings/`, `learnings.md`) likely fits better. Worth a v0 spec. -- **Interaction with existing Scope Flags.** New orthogonal flag (Execution Mode: chat-default / repo-backed)? Or a sub-option under the LLM access flag? Probably orthogonal — repo-backed mode is independent of multi-vendor access. -- **Setup automation.** Does PRISM ship a Setup-time prompt sequence that, given a repo URL and credentials, scaffolds the layout, drops in canonical placement docs, and configures git? Or does it stop at "here's the recommended structure, set it up yourself"? First is much more leveraged but more to maintain. +--- -**Composition with existing backlog:** -- **Cowork + Computer Use:** Composes well — desktop-mode execution with repo-backed artifacts is the most leveraged combination. Repo-backed mode can ship independent of Cowork, but Cowork without repo-backed mode would re-introduce the artifact-handoff problem this entry exists to solve. -- **Contribution channel for cross-vendor adaptations:** Repo-backed mode produces natural cross-vendor adaptation artifacts (each operator's repo is itself a worked example). Channel design should account for this. +### Tooling-conventions Pattern B Phase B2 — legacy element marking sweep -**Supporting work to produce (operator-facing):** -- **Operator setup guide.** Step-by-step: GitHub account → repo creation → fine-grained PAT (scoping + expiry guidance) → SSH signing key → git config → first commit. Lives in the public repo, probably `docs/PRISM_mode_setup.md`. Calibrated for the operator who's used `git` casually but never set up a signing key — that's the median PRISM user. -- **Default repo template.** A scaffolded layout the operator clones or copies — README, `.gitignore`, placeholder dirs (`probes/`, `handoffs/`, `evidence/`, `findings/`, `learnings.md`), and a `PROJECT.md` operators fill in with audit subject + scope flags. Slimmer than `PRISM-workshop` because audit projects don't need `design/` or `synthesis/` as first-class dirs. -- **System-prompt snippet (operator's project).** A generalized version of `PRISM-workshop/protocols/system_instructions.md` (the dev-project canonical) with personal details stripped — operator name, email, GitHub handle removed; repo names parameterized. Drop-in template the operator pastes into their Claude.ai project settings UI; tells Claude how to operate in repo-backed mode (fetch on demand, commit durable artifacts, treat project files as credentials only). Co-evolves with the canonical: when `system_instructions.md` revises (currently at v1.1), the operator template should mirror the same behaviors generalized, version-tagged in lockstep. -- **PRISM.md updates.** New Execution Mode flag at Setup (`chat-default` / `repo-backed`); mode-specific guidance for Setup outputs (commit at Setup completion) and handoffs (signed commit replaces session-end attachment); credential lifecycle nudges (PAT expiration warning, signing-key rotation prompt) generalised from the dev project's pattern. -- **Worked example.** A published exemplar repo demonstrating repo-backed mode end-to-end — either a synthetic Atlas-style audit run through the new flow, or PRISM's own paired repos (`PRISM` + `PRISM-workshop`) cited as the canonical existence proof. The dev project is itself the strongest demo; using it as the example removes the need to fabricate one. -- **Migration note.** Short guidance for operators mid-project: chat-default projects don't need to migrate; repo-backed mode is opt-in for new projects. Avoid framing it as a forced upgrade. +**Status:** Gated on operator ratification of the proposed legacy markers at `PRISM-workshop/notes/pattern_b_legacy_marker_proposals.md` (produced in the v2.1.0 build session). -**Adoption strategy:** +**Scope.** Pattern B Phase B1 (shipped in v2.1.0) added the strength × polarity vocabulary to the frontmatter `normativity` block and the convention-prose extension in the title block, but did not retroactively mark any existing Standing Principle, Monitor, Gate, or Probe. Phase B2 applies ratified polarity glyphs (and any non-default strength tokens) to all ~35 legacy elements in a single sweep. -The activation energy is real — even at five honest minutes, PAT setup + SSH key generation + git config will deter operators who don't see the payoff first. The leverage points: +**Target release:** v2.2.0. The legacy sweep visibly touches every SP / Monitor / Gate / Probe heading; its own release is the cleanest framing for that surface change (per `design/tooling_conventions_micro_dds_rev1.md` X1). -- **Lead with concrete loss-recovery scenarios, not abstract benefits.** "Your project hits cap and you can't access prior probes" → repo solves it. "You want to bring a second LLM in for synthesis without re-uploading fourteen files" → repo solves it. "You want to diff how your audit findings evolved across three iterations" → repo solves it. Each scenario is a felt pain that operators have already lived; benefits framed in those terms convert better than benefits framed as architecture. -- **Show, don't tell.** A two-minute walkthrough video or a single linked exemplar repo will convert more operators than a 2,000-word setup guide. Setup guide still has to exist for the conversion, but it's not the lead. -- **Front-load the value.** The very first commit (Setup output) is itself a demo of the pattern. Operators see the payoff before they've invested anything substantive — first session ends with `git log` showing what they just produced, and they get it. -- **Frame setup time honestly.** "About five minutes, one-time" is the truth and it's compelling. Hiding the friction backfires; selling the ratio (five minutes once vs. download-attach-reattach forever) is honest and wins. -- **Existence proof beats argument.** "PRISM itself runs on this — here are the repos" is the single strongest sales line, and it's already true. The dev project is the demo. -- **Make it opt-in, not the default.** Chat-default mode stays the friction-free path for operators who don't need durability. Repo-backed mode is recommended-for-multi-session projects and labelled as such — no operator should feel they're using PRISM "wrong" by skipping it. -- **Announcement at ship.** GitHub Discussions Announcement post when ready, framing the why before the how. Optionally a short external writeup (the dogfooding angle is its own story) once the supporting docs land. +**Sequence to Phase B2:** -**Urgency:** Not blocking for v2.0 operators today; current download-attach mode works. Becomes higher priority before the user's next PRISM project starts — already a stated requirement for that project. +1. v2.1.0 ships proposals document (done). +2. Operator reviews each proposed marker; ratifies or amends. +3. Phase B2 handoff written at `handoffs/tooling_conventions_pattern_b_phase_b2_build.md` after ratification. +4. Phase B2 build session applies ratified markers via deterministic Python transformation. +5. `PRISM-LINT-06 / element-marking-completeness` (reserved in catalog v1) may promote from `info` to `warning` after Phase B2 ships. -**User commitment:** "I want to introduce a PRISM mode to support it first-class. As an operator I'd like my next PRISM project to use this flow. Can't go back to download-attach." — Apr 25, 2026. +**Provenance.** `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` decisions B1–B6. Phase B1 build: `PRISM-workshop/handoffs/tooling_conventions_micro_dds_build.md` (rev1 + amendment). --- @@ -290,14 +198,51 @@ Codified as SP-9 in v1.9. ## Shipped -### Named cross-references migration (v2.1.0 candidate) +### Tooling conventions Patterns A + D + B Phase B1 (v2.1.0) + +**Shipped on:** `main` of `Ronkupper/PRISM`, 2026-05-22. Tag `v2.1.0`. + +**What landed.** Three independently-designed patterns bundled into one MINOR release per `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` X1: + +- **Pattern A — machine-readable frontmatter.** `PRISM.md` frontmatter expanded into two comment-grouped sections (skill metadata + framework metadata). New fields: `version`, `released`, `supersedes`, `lens_library_embedded`, `substrate_target`, `normativity`, `lint_catalog_version`. Authoritative schema at `PRISM-workshop/schemas/prism_frontmatter.schema.json` (Python `check-jsonschema` validator). +- **Pattern B Phase B1 — strength × polarity vocabulary.** Frontmatter `normativity` block declares strength vocabulary (`required` / `recommended` / `optional`, default `required`) and polarity glyphs (✅ / ⚠️ / 🚫). Title-block tag-convention paragraph extended (two sentences) to announce the axes; vocabulary source is the frontmatter. New elements use the extended `[durability | review-trigger | strength? | polarity?]` form going forward; legacy element sweep deferred to Phase B2. +- **Pattern D — Appendix H, Vendor parsing observations.** New appendix indexing empirical observations of vendor parsing behaviour on dispatched content. Six-status closed vocabulary (`passthrough` / `stripped` / `mangled` / `error` / `not-tested` / `observed-once`), per-content-type H3 sections with narrow per-vendor tables, observation-driven appends with release-sweep at 12-month staleness. Seed entry: ChatGPT mobile paste = stripped (the empirical observation that drove §4.12 atomic-prompt self-containment in v2.0.2). + +**Pre-shipping ratifications** (per `design/tooling_conventions_micro_dds_rev1.md` rev1 amendment, 2026-05-22): X1 bundle locked; C5 workshop retirement of `lint_named_refs.py` locked; C1 expanded with `PRISM-LINT-07` (description-version-match); X4 review-trigger locked to `review-if: release-sweep`; Step 2b convention-prose location locked to extending the title-block tag-convention paragraph (no new subsection); Step 3a Appendix H seed locked to single ChatGPT-mobile entry. + +**Provenance.** `PRISM-workshop/design/tooling_conventions_survey_dd_rev1.md` (survey); `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` (combined micro-DD A+B+C+D); `PRISM-workshop/handoffs/tooling_conventions_micro_dds_build.md` (build handoff). Sequenced via `design/backlog_sequencing_dd_rev1.md`. + +**Coupling watch-out called out.** Bundling A + D + B Phase B1 into one release silently couples three thinking sessions' delivery dates (per `backlog_sequencing_dd_rev1.md` Watch-out #2). Bundle is justified by review-surface efficiency: all three are independent content additions with no semantic conflict. If any of the three had hit a real blocker, the bundle would have broken rather than waited. + +--- -**Shipped on:** `feat/named-refs-v1` in `Ronkupper/PRISM`, 2026-05-22. Awaiting merge to main and version-bump decision. +### Tooling conventions Pattern C — lint catalog (`lint-v1`) -**What landed.** PRISM.md migrated from numbered `§X.Y` cross-references to named `§{namespace.slug}` form. 171 explicit `` anchors injected. Single deterministic Python transformation (`PRISM-workshop/scripts/migrate_named_refs.py`). Linter (`scripts/lint_named_refs.py`) implements PRISM-REF-01/02/03/04 per the design DD. Lint run on the migrated file: 0 errors, 55 info-level orphan findings. +**Shipped on:** `main` of `Ronkupper/PRISM`, 2026-05-22. Tag `lint-v1`. + +**What landed.** Off-cycle reference artifacts for the public lint catalog. No `PRISM.md` content change. + +- `lint_rules.md` at repo root — contributor-facing catalog with seven entries: two active (`PRISM-LINT-01 / named-refs-resolve` error; `PRISM-LINT-02 / named-refs-orphan-anchor` info), five reserved (`-03` `-04` `-05` `-07` gated on Pattern A; `-06` gated on Pattern B Phase B1, now active as of v2.1.0). +- `scripts/lint/lint_named_refs.py` — Python lint script. NDJSON output by default; `--text` flag for human-readable; `--severities` flag for selective emission. Consolidates broken-ref / slug-collision / mixed-ref-style under `PRISM-LINT-01`; emits `PRISM-LINT-02` for orphan anchors. Self-contained (slug-derivation function inlined; no workshop-script dependency). +- `.github/workflows/lint.yml` — PR-only CI workflow with two jobs: `lint-required` (runs error + warning; translates NDJSON to GitHub `::error` / `::warning` annotations; best-effort frontmatter-schema validation against the workshop-hosted schema) and `lint-info` (runs info; posts NDJSON-rendered summary as a sticky PR comment). +- `CONTRIBUTING.md` — new section "Reviewing PRs — rendered-diff convention" per `design/tooling_conventions_micro_dds_rev1.md` C7. + +**Workshop retirement.** `PRISM-workshop/scripts/lint_named_refs.py` (the working/staging copy under the old `PRISM-REF-NN` rule IDs) is retired immediately on Pattern C ship per C5: single canonical home, no staging duplication. + +**Provenance.** Same DD and handoff as the v2.1.0 bundle. Decisions C1–C8. + +--- + +### Named cross-references migration (v2.0.2) + +**Shipped on:** PRISM v2.0.2, 2026-05-22. + +**What landed.** PRISM.md migrated from numbered `§X.Y` cross-references to named `§{namespace.slug}` form. 171 explicit `` anchors injected. Single deterministic Python transformation (`PRISM-workshop/scripts/migrate_named_refs.py`). Initial linter (workshop's `lint_named_refs.py`) implemented `PRISM-REF-01/02/03/04` per the design DD. Lint run on the migrated file: 0 errors, 55 info-level orphan findings. **Provenance.** `PRISM-workshop/design/named_refs_taxonomy_dd_rev1.md` (settled D1–D7); `handoffs/named_refs_build_v1.md` (build session). Sequenced via `design/backlog_sequencing_dd_rev1.md` Phase A.3. +**Catalog rename.** In `lint-v1` (Pattern C, 2026-05-22), the four `PRISM-REF-NN` rule IDs are consolidated under the public catalog: `REF-01` / `REF-02` / `REF-03` (all error) → `PRISM-LINT-01 / named-refs-resolve`; `REF-04` (info) → `PRISM-LINT-02 / named-refs-orphan-anchor`. Internal sub-mode (`broken-ref` / `slug-collision` / `mixed-ref-style` / `orphan-anchor`) preserved in NDJSON `context` field for diagnosability. + **Deferred to follow-up.** Bidirectional alias normalizer for contributor inputs (issue/PR/chat). Split-mode resolver (when partial decomposition of PRISM.md happens). External `prism-md` CLI. --- diff --git a/PRISM_backlog_v6.md b/PRISM_backlog_v13.md similarity index 55% rename from PRISM_backlog_v6.md rename to PRISM_backlog_v13.md index 6218dec..c0e34af 100644 --- a/PRISM_backlog_v6.md +++ b/PRISM_backlog_v13.md @@ -1,6 +1,6 @@ # PRISM Backlog -**Version:** 6 +**Version:** 13 **Maintained by:** Ron Kuper + Claude **Purpose:** Capture ideas, proposals, and deferred items for future PRISM versions. Separate from PRISM.md because backlog items are proposals, not in-force rules — keeping them out of PRISM.md preserves the "everything in PRISM.md is canonical" property. @@ -46,70 +46,51 @@ When an item is declined, move it to **Declined** with rationale — prevents re **User commitment:** "I would like to do that at some point near future" — v1.10.1 build session, Apr 2026. ---- - -### Cowork + Computer Use for framework execution - -**Triggered by:** User note, Apr 2026. Cowork (Anthropic's desktop file/task automation tool) with Computer Use enabled could automate the multi-vendor orchestration PRISM currently runs manually. +**Note:** Appendix H — Vendor parsing observations (shipped in v2.1.0) provides one of the maintenance surfaces this channel will feed into. Cross-vendor adaptation contributions either add new H3 sections (new content types) or new rows in existing tables (new vendor observations for an existing content type). Once the channel itself lands, the appendix is one of the documented destinations. -**The idea:** Multi-LLM triangulation (Claude / ChatGPT / Gemini / Perplexity) is hand-driven today — open each vendor's interface, paste prompts, collect outputs, hand-off to Convergence. Cowork with Computer Use could in principle drive the browser-based vendors, run prompts in sequence, collect outputs into files, and stage a consolidated set for the synthesis steps. Folds the mechanical cross-vendor work into a single orchestrating session. - -**What to investigate:** -- Whether Cowork + Computer Use handles authenticated web UIs (ChatGPT / Gemini / Perplexity logins, session persistence, file uploads per vendor) reliably enough for a full run, or degrades on the edge cases. -- How this interacts with SP-5 / SP-9 ("flag, don't assume" / "silence is never consent"). Computer Use makes many micro-decisions; the framework has to decide which surface for operator approval vs. run autonomously. Default should be aggressive surfacing until reliability is established. -- Whether automated orchestration preserves the epistemic value of multi-vendor triangulation. Different vendors have different failure modes — those still surface regardless of who types the prompts, so probably yes, but the operator's real-time judgment calls ("that Gemini output went off-rails, re-run") need a place to land in the automated flow. -- Augments the mobile-first workflow with a desktop-mode execution path. If Cowork + Computer Use works reliably, both modes are first-class: mobile-mode retains its advantages (portability, low ceremony, the thinking/doing separation that mobile friction naturally enforces), desktop-mode gains automation of the mechanical cross-vendor work. Neither is the "real" way to run PRISM; the operator picks per project based on what the project needs. +--- -**Open questions:** -- New Execution Mode flag at Setup (alongside the LLM access flag from v1.9), or a separate build path? -- Does this compose with PRISM's existing handoff-artifact pattern (thinking/doing separation), or is the temptation to run everything in one agentic session going to collapse the gap that separation exists to preserve? +### Cowork execution mode (`agentic_orchestration`) -**Urgency:** Not blocking. Exploratory — depends on Cowork's actual capabilities as they mature, and on Computer Use reliability curves generally. +*(Active proposal — unchanged.)* --- ### Claude Plugins integration (native) -**Triggered by:** User note, Apr 2026. Anthropic maintains an official plugin directory ([claude.com/plugins](https://claude.com/plugins)) bundling MCPs, skills, and tools for Claude Code and Cowork. PRISM currently doesn't reference any of them. +*(Active proposal — unchanged.)* -**The idea:** Several plugins in the directory pair directly with PRISM audit work. Naming the right plugin in a prompt's execution envelope could produce higher-quality intermediate artifacts than generic prompting. Exemplar categories and named plugins from the current directory: -- **Market / competitive research** — ZoomInfo (company & contact enrichment, AI-ranked lookalikes), Nimble Web Data (web crawl + structured extraction) -- **Live product inspection** — Playwright, Chrome DevTools (drive the audit subject, capture screens, inspect network) -- **Data ingestion** — Firecrawl (convert product surface to LLM-ready data), Data plugin (SQL / dataset exploration, Cowork-native) -- **Design surface** — Figma (access design files), Frontend Design (produce UI recommendation artifacts) -- **PRISM maintenance** — framework iteration, not audit execution — Skill Creator, CLAUDE.md Management, Superpowers +--- + +### Multi-vendor skills/plugins ecosystems -**Hard platform gate:** Plugins run in Claude Code or Cowork, not in stock claude.ai (mobile or web). Plugin integration is therefore unavailable in PRISM's default mobile-first execution mode. Couples tightly to the Cowork + Computer Use proposal above — any execution mode that exposes Claude Plugins is a desktop-mode variant by definition. +*(Active proposal — unchanged.)* -**What to investigate:** -- Which specific plugins clear a usefulness threshold for PRISM (shortlist, not blanket endorsement). The actual audit workload determines the shortlist, not the feature list. -- **"Need to look them up each time?"** — the directory is browsable but large (80+ plugins already) and still growing. Any PRISM reference would be a curated shortlist of plugin↔prompt pairings, not the whole catalog, and would age faster than the framework itself. Probably lives as a separate reference alongside PRISM.md — same ageing argument as the vendor-to-role mapping in v1.9. -- Interaction with SP-5 / SP-9 — plugins that take external actions (Firecrawl crawls, Playwright clicks, ZoomInfo lookups consuming credit) need consent surfaces. Same pattern as Computer Use; likely resolvable with the same machinery. +--- -**Open questions:** -- Does meaningful plugin uplift promote the Cowork + Computer Use proposal from "exploratory" to "recommended for projects where plugin advantage is material"? -- Is there a "PRISM Plugin" worth building eventually — a single bundle shipping PRISM as a Skill plus a curated set of companion plugins? Out of scope for 2026 but worth flagging. +### Repo-backed PRISM mode (operator GitHub flow) -**Urgency:** Not blocking. Gated on Cowork proposal resolution — no point investing in plugin shortlists if the execution-mode decision lands against desktop variants. +*(Active proposal — unchanged.)* --- -### Multi-vendor skills/plugins ecosystems +### Tooling-conventions Pattern B Phase B2 — legacy element marking sweep + +**Status:** Gated on operator ratification of the proposed legacy markers at `PRISM-workshop/notes/pattern_b_legacy_marker_proposals.md` (produced in the v2.1.0 build session). -**Triggered by:** User note, Apr 2026. Perplexity ships its own Skills library (e.g., `marketing-competitive-analysis`, under its computer-use surface). Claude Plugins are not a Claude-specific anomaly — they're one instance of a broader pattern where every major vendor is building a skill/plugin ecosystem. PRISM's role-based vendor recommendations (v1.9) should account for this. +**Scope.** Pattern B Phase B1 (shipped in v2.1.0) added the strength × polarity vocabulary to the frontmatter `normativity` block and the convention-prose extension in the title block, but did not retroactively mark any existing Standing Principle, Monitor, Gate, or Probe. Phase B2 applies ratified polarity glyphs (and any non-default strength tokens) to all ~35 legacy elements in a single sweep. -**The idea:** Vendor skill coverage is now a first-class signal of vendor fit for specific prompt roles. "Use Perplexity for competitive analysis" becomes stronger when Perplexity literally ships a `marketing-competitive-analysis` Skill — the vendor has invested in that capability surface deliberately, not just incidentally. Multi-vendor triangulation gets richer, not redundant: different vendors bring different skill libraries, which means different blind spots and different strengths surface in the same audit. Epistemically additive. +**Target release:** v2.2.0. The legacy sweep visibly touches every SP / Monitor / Gate / Probe heading; its own release is the cleanest framing for that surface change (per `design/tooling_conventions_micro_dds_rev1.md` X1). -**What to investigate:** -- Survey scope: which vendors currently ship named skill/plugin libraries (Claude and Perplexity confirmed; OpenAI GPTs, Gemini Gems likely analogous but mechanically different). Which PRISM prompt roles have strong skill coverage from at least one vendor? Which don't? -- **Platform gate consistency:** Claude Plugins require Cowork / Code. Perplexity Skills appear to live in their computer-use context. The pattern across vendors seems to be that skill/plugin ecosystems are gated on agentic/desktop surfaces, not chat-default surfaces. Worth confirming — if general, it generalises the Cowork coupling to "any desktop-mode execution variant, for any vendor," not just Claude. -- **Vendor-to-role mapping reference:** v1.9 established that this mapping lives outside PRISM.md because it ages fast. Skill-coverage columns (per-vendor skill library, named skills relevant to PRISM roles) are a natural addition to that reference. Doesn't touch PRISM.md. +**Sequence to Phase B2:** -**Open questions:** -- Does skill coverage get weight alongside raw model capability in the vendor-for-role recommendation? Probably yes, but needs explicit framing — capability ∧ skill coverage, not either alone. -- When a vendor is recommended for a role because of its skill coverage, does PRISM recommend *using* that vendor's specific skill, or treat skill availability as a signal that the vendor has strong latent capability even when invoked in chat-default mode? First is more leveraged, second is more flexible. Likely depends on whether the operator is in a desktop execution variant (gate from the entry above). +1. v2.1.0 ships proposals document (done). +2. Operator reviews each proposed marker; ratifies or amends. +3. Phase B2 handoff written at `handoffs/tooling_conventions_pattern_b_phase_b2_build.md` after ratification. +4. Phase B2 build session applies ratified markers via deterministic Python transformation. +5. `PRISM-LINT-06 / element-marking-completeness` (reserved in catalog v1) may promote from `info` to `warning` after Phase B2 ships. -**Urgency:** Not blocking. Low-cost research — a vendor survey session cataloguing current skill libraries and mapping them to PRISM prompt roles produces the v1.9 mapping reference's next revision without needing framework changes. +**Provenance.** `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` decisions B1–B6. Phase B1 build: `PRISM-workshop/handoffs/tooling_conventions_micro_dds_build.md` (rev1 + amendment). --- @@ -217,7 +198,52 @@ Codified as SP-9 in v1.9. ## Shipped -*(moved here when v1.9 is built and the backlog items ship — structure reserved for future use)* +### Tooling conventions Patterns A + D + B Phase B1 (v2.1.0) + +**Shipped on:** `main` of `Ronkupper/PRISM`, 2026-05-22. Tag `v2.1.0`. + +**What landed.** Three independently-designed patterns bundled into one MINOR release per `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` X1: + +- **Pattern A — machine-readable frontmatter.** `PRISM.md` frontmatter expanded into two comment-grouped sections (skill metadata + framework metadata). New fields: `version`, `released`, `supersedes`, `lens_library_embedded`, `substrate_target`, `normativity`, `lint_catalog_version`. Authoritative schema at `PRISM-workshop/schemas/prism_frontmatter.schema.json` (Python `check-jsonschema` validator). +- **Pattern B Phase B1 — strength × polarity vocabulary.** Frontmatter `normativity` block declares strength vocabulary (`required` / `recommended` / `optional`, default `required`) and polarity glyphs (✅ / ⚠️ / 🚫). Title-block tag-convention paragraph extended (two sentences) to announce the axes; vocabulary source is the frontmatter. New elements use the extended `[durability | review-trigger | strength? | polarity?]` form going forward; legacy element sweep deferred to Phase B2. +- **Pattern D — Appendix H, Vendor parsing observations.** New appendix indexing empirical observations of vendor parsing behaviour on dispatched content. Six-status closed vocabulary (`passthrough` / `stripped` / `mangled` / `error` / `not-tested` / `observed-once`), per-content-type H3 sections with narrow per-vendor tables, observation-driven appends with release-sweep at 12-month staleness. Seed entry: ChatGPT mobile paste = stripped (the empirical observation that drove §4.12 atomic-prompt self-containment in v2.0.2). + +**Pre-shipping ratifications** (per `design/tooling_conventions_micro_dds_rev1.md` rev1 amendment, 2026-05-22): X1 bundle locked; C5 workshop retirement of `lint_named_refs.py` locked; C1 expanded with `PRISM-LINT-07` (description-version-match); X4 review-trigger locked to `review-if: release-sweep`; Step 2b convention-prose location locked to extending the title-block tag-convention paragraph (no new subsection); Step 3a Appendix H seed locked to single ChatGPT-mobile entry. + +**Provenance.** `PRISM-workshop/design/tooling_conventions_survey_dd_rev1.md` (survey); `PRISM-workshop/design/tooling_conventions_micro_dds_rev1.md` (combined micro-DD A+B+C+D); `PRISM-workshop/handoffs/tooling_conventions_micro_dds_build.md` (build handoff). Sequenced via `design/backlog_sequencing_dd_rev1.md`. + +**Coupling watch-out called out.** Bundling A + D + B Phase B1 into one release silently couples three thinking sessions' delivery dates (per `backlog_sequencing_dd_rev1.md` Watch-out #2). Bundle is justified by review-surface efficiency: all three are independent content additions with no semantic conflict. If any of the three had hit a real blocker, the bundle would have broken rather than waited. + +--- + +### Tooling conventions Pattern C — lint catalog (`lint-v1`) + +**Shipped on:** `main` of `Ronkupper/PRISM`, 2026-05-22. Tag `lint-v1`. + +**What landed.** Off-cycle reference artifacts for the public lint catalog. No `PRISM.md` content change. + +- `lint_rules.md` at repo root — contributor-facing catalog with seven entries: two active (`PRISM-LINT-01 / named-refs-resolve` error; `PRISM-LINT-02 / named-refs-orphan-anchor` info), five reserved (`-03` `-04` `-05` `-07` gated on Pattern A; `-06` gated on Pattern B Phase B1, now active as of v2.1.0). +- `scripts/lint/lint_named_refs.py` — Python lint script. NDJSON output by default; `--text` flag for human-readable; `--severities` flag for selective emission. Consolidates broken-ref / slug-collision / mixed-ref-style under `PRISM-LINT-01`; emits `PRISM-LINT-02` for orphan anchors. Self-contained (slug-derivation function inlined; no workshop-script dependency). +- `.github/workflows/lint.yml` — PR-only CI workflow with two jobs: `lint-required` (runs error + warning; translates NDJSON to GitHub `::error` / `::warning` annotations; best-effort frontmatter-schema validation against the workshop-hosted schema) and `lint-info` (runs info; posts NDJSON-rendered summary as a sticky PR comment). +- `CONTRIBUTING.md` — new section "Reviewing PRs — rendered-diff convention" per `design/tooling_conventions_micro_dds_rev1.md` C7. + +**Workshop retirement.** `PRISM-workshop/scripts/lint_named_refs.py` (the working/staging copy under the old `PRISM-REF-NN` rule IDs) is retired immediately on Pattern C ship per C5: single canonical home, no staging duplication. + +**Provenance.** Same DD and handoff as the v2.1.0 bundle. Decisions C1–C8. + +--- + +### Named cross-references migration (v2.0.2) + +**Shipped on:** PRISM v2.0.2, 2026-05-22. + +**What landed.** PRISM.md migrated from numbered `§X.Y` cross-references to named `§{namespace.slug}` form. 171 explicit `` anchors injected. Single deterministic Python transformation (`PRISM-workshop/scripts/migrate_named_refs.py`). Initial linter (workshop's `lint_named_refs.py`) implemented `PRISM-REF-01/02/03/04` per the design DD. Lint run on the migrated file: 0 errors, 55 info-level orphan findings. + +**Provenance.** `PRISM-workshop/design/named_refs_taxonomy_dd_rev1.md` (settled D1–D7); `handoffs/named_refs_build_v1.md` (build session). Sequenced via `design/backlog_sequencing_dd_rev1.md` Phase A.3. + +**Catalog rename.** In `lint-v1` (Pattern C, 2026-05-22), the four `PRISM-REF-NN` rule IDs are consolidated under the public catalog: `REF-01` / `REF-02` / `REF-03` (all error) → `PRISM-LINT-01 / named-refs-resolve`; `REF-04` (info) → `PRISM-LINT-02 / named-refs-orphan-anchor`. Internal sub-mode (`broken-ref` / `slug-collision` / `mixed-ref-style` / `orphan-anchor`) preserved in NDJSON `context` field for diagnosability. + +**Deferred to follow-up.** Bidirectional alias normalizer for contributor inputs (issue/PR/chat). Split-mode resolver (when partial decomposition of PRISM.md happens). External `prism-md` CLI. --- diff --git a/PRISM_v2_0_2.md b/PRISM_v2_1_0.md similarity index 97% rename from PRISM_v2_0_2.md rename to PRISM_v2_1_0.md index 5b451b1..05d5145 100644 --- a/PRISM_v2_0_2.md +++ b/PRISM_v2_1_0.md @@ -1,13 +1,27 @@ --- +# Skill metadata (consumed by Claude.ai skill loader) name: prism -description: "PRISM — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Currently v2.0.2. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM, PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md or *_starter_v*.md (v1.x), Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Read this file in full at the start of any PRISM session before doing any work." +description: "PRISM — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Currently v2.1.0. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM, PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md or *_starter_v*.md (v1.x), Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Read this file in full at the start of any PRISM session before doing any work." + +# Framework metadata (consumed by PRISM maintenance tooling) +version: 2.1.0 +released: 2026-05-22 +supersedes: 2.0.2 +lens_library_embedded: "0.10" +substrate_target: [claude-opus-4-6, claude-opus-4-7] +normativity: + strength_vocabulary: [required, recommended, optional] + strength_default: required + polarity_vocabulary: ["✅", "⚠️", "🚫"] + polarity_default: null +lint_catalog_version: 1 --- -# PRISM v2.0.2 — Framework operating document +# PRISM v2.1.0 — Framework operating document -**Status:** v2.0.2 release. Canonical framework for Claude orchestration sessions. +**Status:** v2.1.0 release. Canonical framework for Claude orchestration sessions. **Date:** May 2026 -**Supersedes:** PRISM v2.0.1 (release-hygiene patch; see §{section.project-feedback-updates} for surface and provenance). PRISM v1.10.4 is terminal on the v1.x line (pinned per DD §{section.standing-principles-introduced-or-extended-in-v2}). +**Supersedes:** PRISM v2.0.2 (MINOR release adding machine-readable frontmatter, normativity vocabulary, and Appendix H — Vendor parsing observations; see §{section.project-feedback-updates} for surface and provenance). PRISM v1.10.4 is terminal on the v1.x line (pinned per DD §{section.standing-principles-introduced-or-extended-in-v2}). **Required attachments at every orchestration session:** this file (or the PRISM v2 Skill that loads it) and the project's Master. This file embeds Lens Library v0.10 in Appendix G; a singleton PRISM.md attachment is @@ -25,8 +39,13 @@ points to a Lens Library entry. **Tag convention.** Every decision in this document carries a two-axis tag — durability axis (`structural` / `methodological` / `vendor-dependent` / `empirical` / `operator-scaffolding`) × review-trigger axis -(`stable` / `review-if: ` / `review-annually`). The full tag index is -Appendix C. +(`stable` / `review-if: ` / `review-annually`). Decisions may also +carry a strength token (`required` / `recommended` / `optional`, default +`required`) and a polarity glyph (✅ always do / ⚠️ ask first / 🚫 never), +appended after the review-trigger token when present; both vocabularies are +declared in this file's frontmatter `normativity` block. Per-element marking +is optional for legacy elements and applied to new ones going forward. +The full tag index is Appendix C. **Voice.** This is operating instruction for Claude in an orchestration session. Imperative where Claude must act; declarative where defining shape; descriptive @@ -61,8 +80,8 @@ Reading order for an operator returning to v2.0 after running a session: ## 1. Scope -### 1.1 What v2.0.2 covers `[structural | stable]` - +### 1.1 What v2.1.0 covers `[structural | stable]` + PRISM v2.0 is a structured multi-session, multi-vendor LLM-orchestrated audit and research framework. v2.0 covers: @@ -100,8 +119,8 @@ and research framework. v2.0 covers: - **Atomic prompt template v2 form** — wraps the triple contract around the prompt body (§{section.atomic-prompt-template-v2-form}). -### 1.2 What v2.0.2 does not cover - +### 1.2 What v2.1.0 does not cover + - **Re-debating direction.** v2.0 implements the spec; the spec implements the design document. Direction is settled. New direction goes through a @@ -3418,7 +3437,7 @@ indexes decisions by tag for easy review. ### C.1 `[structural | stable]` -§{section.what-v2-0-2-covers} (scope), §{section.three-leg-constraint} (three-leg constraint), §{section.two-session-types} (two session types), +§{section.what-v2-1-0-covers} (scope), §{section.three-leg-constraint} (three-leg constraint), §{section.two-session-types} (two session types), §{section.the-triple-contract} (triple contract), §{section.the-master} (Master), §{section.whats-next} (*What's next*), §{section.forward-compatibility-commitments} (forward-compatibility commitments), §{section.single-envelope-with-spectrum-shape} (single-Envelope-with- spectrum), §{section.vendor-triangulation} (Vendor Triangulation), §{section.asymmetric-parallel-return-handling} (asymmetric returns), §{section.recommended-vs-executed-reconciliation} @@ -3480,16 +3499,30 @@ before recommending), §{section.sp-14-filename-discipline} (§{principle.SP-14} §{section.empirical-calibration-items} (empirical calibration items — collectively; individual items inherit calibration trigger). +### C.9 `[methodological | review-if: release-sweep | recommended]` + + +§{appendix.vendor-parsing-observations} (Appendix H preamble — vendor parsing +observations: empirical, observation-driven; the preamble's maintenance +protocol carries the tag, the table rows are data). + **Tag count summary.** +The strength axis (`required` default; `recommended` / `optional` non-default) +and polarity glyphs (✅ / ⚠️ / 🚫) are introduced in v2.1.0 per the +frontmatter `normativity` block; only non-default strength values appear as +tokens in tags. The summary below indexes by the original two-axis pair +(durability × review-trigger); rows whose listed entries include non-default +strength are noted parenthetically. + | Axis 1 \ Axis 2 | stable | review-if | review-annually | Total | |---|---|---|---|---| | structural | 41 | 0 | 0 | 41 | -| methodological | 10 | 2 | 0 | 12 | +| methodological | 10 | 3 (1 with `recommended`) | 0 | 13 | | vendor-dependent | 0 | 3 | 0 | 3 | | operator-scaffolding | 6 | 0 | 0 | 6 | | empirical | 0 | 0 | 1 | 1 | -| **Total** | **57** | **5** | **1** | **63** | +| **Total** | **57** | **6** | **1** | **64** | --- @@ -4872,6 +4905,69 @@ Feedback, patches, and field-observations welcome. Ongoing currency of rubric an --- +## Appendix H — Vendor parsing observations + + +`[methodological | review-if: release-sweep | recommended]` + +This appendix records empirical observations of how dispatched-content +vendors handle PRISM-shaped inputs (envelopes, atomic prompts, attached +artifacts). Entries are observations, not specifications: a status like +`stripped` documents what was seen on a given date, not what a vendor +guarantees. The appendix is consulted at dispatch time when shaping +envelopes for a target vendor and at release-sweep time to re-test stale +entries. + +**Status taxonomy.** Status column values are drawn from a closed +vocabulary: + +- **passthrough** — vendor preserves the content as-is. +- **stripped** — vendor removes the content silently from inputs (paste, + upload, web fetch). +- **mangled** — vendor preserves the content but alters it in transit + (re-encoding, restructuring, character substitution). +- **error** — vendor returns an error or refuses to process the content. +- **not-tested** — no observation on record; placeholder when other + vendors in the section have entries. +- **observed-once** — single anecdotal observation; not generalizable; + the entry exists to mark a sighting for follow-up confirmation. + +**Maintenance protocol.** Entries are append-only between releases. Any +orchestration session that surfaces a vendor parsing gap creates a new +entry (or updates an existing one) under the relevant content-type +heading. At each MINOR or MAJOR PRISM release, entries with an `Observed` +date older than twelve months are re-tested or annotated `† stale`. The +appendix's maintenance surface is shared with the cross-vendor adaptation +workstream; contributions from that workstream land here as new H3 +sections (new content types) or new rows in existing tables (new vendor +observations for an existing content type). + +**Per-content-type sections.** Each content type is a separate H3 +sub-section so per-vendor tables stay narrow and mobile-readable. New +content types are added as new H3 sections rather than as additional +columns in an existing table. + +### Markdown / YAML fences in mobile-paste inputs + +Behavior when an envelope sent via the mobile-app *paste* input path +contains fenced Markdown or YAML blocks (` ``` ` / `---`). + +| Vendor | Status | Observed | Workaround | +|---|---|---|---| +| ChatGPT (mobile paste) | stripped | 2026-05-15 | Treat mobile paste as an unsupported input path for fenced content. Inline-expand per §{section.atomic-prompt-self-containment}; verify the envelope as received before relying on contract structure. | +| Perplexity DR | not-tested | — | — | +| Gemini DR | not-tested | — | — | +| Claude Research | not-tested | — | — | + +The ChatGPT mobile observation prompted §{section.atomic-prompt-self-containment} +in v2.0.2: inline-expanded definitions of PRISM shorthand inside the +dispatched prompt body ensure semantic integrity even when fences are +silently dropped in transit. The `not-tested` rows are placeholders; +re-test at the next release sweep or when a session next dispatches +fenced content via mobile paste on those vendors. + +--- + ## 18. Project, feedback, updates `[structural | stable]` @@ -4884,7 +4980,7 @@ to the maintainer. - **Repository.** `https://github.com/Ronkupper/PRISM` - **Maintainer.** Ron Kuper ([@Ronkupper](https://github.com/Ronkupper)) -- **Framework version.** v2.0.2 (this file) +- **Framework version.** v2.1.0 (this file) - **Embedded Lens Library version.** v0.10 (Appendix G) - **Release date.** 2026-05-22 - **Licensing.** Documentation under CC BY 4.0; any code under MIT; @@ -4900,12 +4996,12 @@ without that capability can paste the URLs into a browser and download. | Resource | Stable URL | Pinned URL | |---|---|---| -| Framework (this file) | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/PRISM.md` | `…/PRISM_v2_0_2.md` | +| Framework (this file) | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/PRISM.md` | `…/PRISM_v2_1_0.md` | | Lens Library | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/lens/PRISM_lens_library.md` | `…/lens/PRISM_lens_library_v0_10.md` | | Framework version stamp | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/VERSION` | — | | Lens version stamp | `https://raw.githubusercontent.com/Ronkupper/PRISM/main/lens/VERSION` | — | | Releases index | `https://github.com/Ronkupper/PRISM/releases` | — | -| Release at this version | — | `https://github.com/Ronkupper/PRISM/releases/tag/v2.0.2` | +| Release at this version | — | `https://github.com/Ronkupper/PRISM/releases/tag/v2.1.0` | The two `VERSION` endpoints exist as cheap currency checks: each is a single-line file containing the current version on the corresponding @@ -4931,7 +5027,7 @@ failed check is not an error. repository's `main` branch. The endpoints return one line each. 3. Compare. If the published version is greater than the attached version on either track, surface a soft flag: - `Framework v2.0.2 attached; v{published} available at {releases URL}.` + `Framework v2.1.0 attached; v{published} available at {releases URL}.` `Lens v0.10 attached; v{published} available at {releases URL}.` 4. The flag is informational. The operator decides whether to upgrade between sessions. PRISM does not silently swap attached files at @@ -4974,8 +5070,8 @@ To cite PRISM in published work, see `CITATION.cff` in the repository. A short attribution suitable for inline use: > Kuper, R. (2026). *PRISM: A Framework for LLM Research and Audits* -> (v2.0.2). https://github.com/Ronkupper/PRISM +> (v2.1.0). https://github.com/Ronkupper/PRISM --- -*End of PRISM v2.0.2 framework operating document.* +*End of PRISM v2.1.0 framework operating document.* diff --git a/README.md b/README.md index 0e5506a..c1558be 100644 --- a/README.md +++ b/README.md @@ -1,63 +1,31 @@ -

- PRISM -

- # PRISM -#### *Prompts · Research · Iteration · Synthesis · Master* - -**A framework for LLM research and audits.** - -*A single-file, plain-text convention for LLM context — inspired by AGENTS.md and design.md, but for research and audit processes rather than coding agents or design systems.* - -PRISM keeps multi-prompt, multi-session LLM work coherent — across prompts, across sessions, and across the context limits of any single chat. It splits a research or audit problem into atomic specialist prompts, runs each one where it works best (Claude, Gemini, Perplexity, ChatGPT), and converges the outputs into a single living document called the **Master**.[^master] - -[^master]: Called the **Starter** in v1.x. Renamed to Master at v2.0; v1.10.4 projects continue using the Starter terminology. - -> *Prefer a 13-slide overview? See [`PRISM_teaser.pdf`](./assets/PRISM_teaser.pdf).* - ---- -## What it does +**PRISM** (Prompts · Research · Iteration · Synthesis · Master) is a structured multi-session, multi-vendor LLM-orchestrated audit and research framework. It splits a research problem into atomic specialist prompts, dispatches each where it runs best across Claude, ChatGPT, Gemini, and Perplexity, and converges their outputs into a single living document called the **Master**. -- **Multi-prompt by design.** One question too big for one prompt becomes a planned set of specialist prompts that add up to a whole. -- **Session-durable.** Project state lives in the Master file. Any fresh session can pick up with *"What's next?"* and resume without memory loss. -- **Context-disciplined.** Monitors and Gates watch for version drift, context pressure, and missing inputs before they compound. -- **Self-driving at Setup.** You bring the subject and the goal; PRISM produces the Prompt Strategy. You approve; you don't author. -- **Foolproof per prompt.** Each prompt arrives as a complete execution package — text, attachments, which LLM to run it on, which mode. You paste and run. -- **Multi-LLM triangulation.** Cross-LLM convergence as a deliberate design feature. -- **Mobile-friendly.** Mobile-first by design, phone-tested down to the markdown. Desktop works too. +The framework ships as a single Markdown file (`PRISM.md`) that can be attached to any LLM chat or installed as a Claude Skill. It carries its own machine-readable frontmatter, lint contract, Lens Library (embedded as Appendix G), and vendor-parsing escape-hatch (Appendix H) so the file self-documents across sessions and vendors. -## When to use +## Quick start -- Product audits (competitive, technical, UX, content, strategy) -- Competitive landscape research -- Market sizing with cross-checked sources -- Investment due diligence -- Any research problem where a single prompt would be too shallow or too long to trust +The fastest path: -## When not to use +1. Attach `PRISM.md` (or `PRISM_v2_1_0.md` for the version-pinned copy) to a fresh Claude chat. +2. Tell Claude the problem you want to audit or research. +3. Follow the Setup probes (P1–P7), iterate against the Lens Library until you clear three-layer readiness, then dispatch atomic prompts per the *What's next* artifact. -- Simple factual lookups -- Analysis that fits comfortably in one prompt -- Creative work (writing, design) where divergent specialist passes don't add value +For a worked example, see §17 of `PRISM.md`. For repository conventions (versioning, contribution channels, lint), see [`CONTRIBUTING.md`](./CONTRIBUTING.md) and [`RELEASING.md`](./RELEASING.md). -## How to use +## What PRISM is for -1. Grab [`PRISM.md`](./PRISM.md) from this repo. Singleton: framework body + Lens Library v0.9 (embedded as Appendix G) + skill frontmatter — one file, mobile-friendly. -2. Either: - - **Attach it to a Claude session**, or - - **Install it as a Claude Skill** (auto-triggers on any `*_master_p*.md` (v2) or `*_starter_v*.md` (v1.x) file) -3. Hand Claude your subject and goal. PRISM takes it from there. - -Optional / advanced layouts: -- **Decoupled loader** — install [`SKILL.md`](./SKILL.md) (skill frontmatter only, no body); attach `PRISM.md` separately. Same v2 skill, looser coupling. -- **Standalone Lens Library** — [`lens/PRISM_lens_library.md`](./lens/PRISM_lens_library.md) is the canonical Library artifact for evolution and Update sessions. Operators on a newer Library version pin explicitly and override Appendix G. +- **Multi-vendor research and audits** where one prompt isn't enough and one vendor isn't enough. +- **Coherence across sessions**: continuous Master + *What's next* state means a session you open next week can pick up exactly where the last one closed, even on a fresh chat. +- **Mobile-first operation**: structured filenames, file-based outputs, operator hints, narrow tables, and a "What's next?" prompt are all designed for someone moving artifacts between vendor chats on a phone. +- **Explicit scope-completeness**: the Lens Library catalogs audit-scope lenses and grades the draft Prompt Strategy against them at Setup, so silent omissions surface before any prompt ships. The framework runs on any capable LLM — Claude is the primary reasoning and build environment, with ChatGPT, Gemini, and Perplexity used in deliberate multi-vendor triangulation sequences. ## Current version -**v2.0.2** — current file: [`PRISM.md`](./PRISM.md). v2 is a major rebuild around the Lens Library (embedded as Appendix G), a triple execution contract (Envelope · Self-check · Output), continuous Master + *What's next* state, and a telemetric context-pressure framework. See [Appendix D](./PRISM.md#appendix-d--v1x--v2-surface-drift) for the v1.x → v2 surface drift map. The version-pinned snapshot at this tag is [`PRISM_v2_0_2.md`](./PRISM_v2_0_2.md) (byte-identical to PRISM.md at the v2.0.2 tag); previous versions are available via git tags per [`RELEASING.md`](./RELEASING.md). +**v2.1.0** — current file: [`PRISM.md`](./PRISM.md). v2.1.0 is a MINOR release over v2.0.2 that adds machine-readable frontmatter (Pattern A: `version`, `released`, `supersedes`, `lens_library_embedded`, `substrate_target`, `normativity`, `lint_catalog_version`), a strength × polarity normativity vocabulary (Pattern B Phase B1), and Appendix H — Vendor parsing observations (Pattern D). The version-pinned snapshot at this tag is [`PRISM_v2_1_0.md`](./PRISM_v2_1_0.md) (byte-identical to PRISM.md at the v2.1.0 tag); previous versions are available via git tags per [`RELEASING.md`](./RELEASING.md). **Previous version:** v1.10.4 ([`PRISM_v1_10_4.md`](./PRISM_v1_10_4.md)) — terminal on the v1.x line. Projects under v1.10.4 remain on v1.10.4; v2 supersedes for new work. @@ -67,7 +35,7 @@ PRISM is distributed primarily as a **file attachment**, not via `git clone`. Th ## Roadmap -Active proposals, deferred items, and declined ideas with rationale live in [`PRISM_backlog.md`](./PRISM_backlog.md) (versioned copy: [`PRISM_backlog_v6.md`](./PRISM_backlog_v6.md)). It's a working document — not canonical, not in force — kept separate from `PRISM.md` so the framework file stays authoritative. Useful if you want to see what's being considered, what's been decided against and why, or what's queued for the next version. +Active proposals, deferred items, and declined ideas with rationale live in [`PRISM_backlog.md`](./PRISM_backlog.md) (versioned copy: [`PRISM_backlog_v13.md`](./PRISM_backlog_v13.md)). It's a working document — not canonical, not in force — kept separate from `PRISM.md` so the framework file stays authoritative. Useful if you want to see what's being considered, what's been decided against and why, or what's queued for the next version. ## Related conventions @@ -83,37 +51,24 @@ What they share: one file, dual-audience (human-readable rationale + machine-par The **PRISM Lens Library** ([`lens/PRISM_lens_library.md`](./lens/PRISM_lens_library.md)) is a reference catalog of audit-scope lenses. As of v2.0 it is required attachment to every orchestration session and is graded against the draft Prompt Strategy by the seven Setup probes. +The **PRISM lint catalog** ([`lint_rules.md`](./lint_rules.md)) is the contributor-facing reference for what's checked mechanically on PRs. Two rules active at `lint-v1`: `PRISM-LINT-01 / named-refs-resolve` (error) and `PRISM-LINT-02 / named-refs-orphan-anchor` (info). Five reserved slots activate as their dependencies ship. + ## Repository contents - `PRISM.md` — current framework version (singleton: framework body + Lens Library embedded as Appendix G + skill frontmatter; stable filename, always up to date). -- `PRISM_v{n}.md` — versioned snapshot of PRISM.md at the corresponding tag (e.g., `PRISM_v2_0_0.md`); for git-tag recovery per [`RELEASING.md`](./RELEASING.md). Not the primary install target. +- `PRISM_v{n}.md` — versioned snapshot of PRISM.md at the corresponding tag (e.g., `PRISM_v2_1_0.md`); for git-tag recovery per [`RELEASING.md`](./RELEASING.md). Not the primary install target. - `PRISM_v1_10_4.md` — terminal v1.x release retained at root for projects pinned to v1.10.4. - `SKILL.md` — standalone skill loader (frontmatter only); use as an alternative to the fused `PRISM.md` when a decoupled skill / body layout is preferred. - `PRISM_backlog.md` — active/deferred/declined roadmap items. Working document, not canonical. -- `PRISM_backlog_v{n}.md` — versioned copy of the backlog (e.g., `PRISM_backlog_v6.md`). +- `PRISM_backlog_v{n}.md` — versioned copy of the backlog (e.g., `PRISM_backlog_v13.md`). - `lens/PRISM_lens_library.md` — canonical reference catalog of audit-scope lenses (stable filename). Authoritative for Library evolution; embedded into `PRISM.md` Appendix G for singleton-attach convenience. - `lens/PRISM_lens_library_v{n}.md` — versioned copy of the Lens Library (e.g., `PRISM_lens_library_v0_9.md`). -- `design/` — design-time artifacts for the current major version (specification + design document). Provenance for the framework as shipped. -- `README.md` — this file. -- `RELEASING.md` — maintainer workflow for tagging releases and bumping versions. -- `CONTRIBUTING.md` — how to contribute (bug reports, proposals, PRs). -- `CODE_OF_CONDUCT.md` — community norms; participation governed by the Contributor Covenant. -- `SECURITY.md` — how to report vulnerabilities privately. -- `CITATION.cff` — citation metadata (powers GitHub's "Cite this repository" button). -- `LICENSE-CC-BY-4.0.txt` — Creative Commons license, covers the framework docs. -- `LICENSE-MIT.txt` — MIT license, covers any code. -- `assets/` — logo, teaser deck (PPTX source + PDF), and other visual assets. - -## Maintainer - -Ron Kuper, with Claude as co-maintainer. Distilled from real-world competitive research and product audit projects, 2026. +- `lint_rules.md` — contributor-facing lint catalog (tag track: `lint-v{N}`). +- `scripts/lint/` — lint scripts executed by the CI workflow. +- `.github/workflows/lint.yml` — PR-only lint workflow. +- `VERSION` — single-line framework-version stamp. +- `CONTRIBUTING.md`, `RELEASING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `CITATION.cff`, `README.md` — repo conventions. ## License -This repository is dual-licensed: - -- **Framework documentation** (`PRISM.md`, any versioned `PRISM_v*.md` copy, and any other `.md` content except this README and `CODE_OF_CONDUCT.md`) is licensed under [Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/). See [`LICENSE-CC-BY-4.0.txt`](./LICENSE-CC-BY-4.0.txt). -- **Code** (scripts, tools, or any source files added in the future) is licensed under the [MIT License](https://opensource.org/licenses/MIT). See [`LICENSE-MIT.txt`](./LICENSE-MIT.txt). -- **`CODE_OF_CONDUCT.md`** is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/) and is licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) per the Covenant's own terms. - -You're free to use, adapt, and build on PRISM — including commercially — as long as you credit the project. +Framework documentation under [CC BY 4.0](./LICENSE-CC-BY-4.0.txt). Any code (lint scripts, transformations) under [MIT](./LICENSE-MIT.txt). The Code of Conduct is under [CC BY-SA 4.0](./CODE_OF_CONDUCT.md). See `LICENSE-*` files for full texts and [`CITATION.cff`](./CITATION.cff) for citation metadata. diff --git a/RELEASING.md b/RELEASING.md index a9f4b64..5e2bb70 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -10,15 +10,16 @@ The repo also keeps a **stable filename** copy (`PRISM.md`, `lens/PRISM_lens_lib ## Release tracks -Three things ship from this repo, on **independent cadences**: +Four things ship from this repo, on **independent cadences**: | Track | Stable filename | Pinned snapshot | Tag pattern | Versioning | |---|---|---|---|---| | Framework | `PRISM.md` | `PRISM_v{X_Y_Z}.md` | `v{X.Y.Z}` | SemVer (MAJOR.MINOR.PATCH) | | Lens Library | `lens/PRISM_lens_library.md` | `lens/PRISM_lens_library_v{X_Y}.md` | `prism-lens-v{X.Y}` | MAJOR.MINOR (no patch) | +| Lint catalog | `lint_rules.md` + `scripts/lint/` + `.github/workflows/lint.yml` | *(no pinned snapshot)* | `lint-v{N}` | Monotonic integer (catalog version) | | Backlog | `PRISM_backlog.md` | `PRISM_backlog_v{n}.md` | *(not tagged)* | Monotonic integer | -The framework and the Lens Library are versioned and released **independently**. A Lens Library bump does not require a framework bump and vice versa. The framework declares its required Lens Library version in its attachment contract; mismatches surface at runtime via M2 (Version Drift), not at release time. +The framework, the Lens Library, and the lint catalog are versioned and released **independently**. A Lens Library bump does not require a framework bump and vice versa. The framework declares its required Lens Library version in its attachment contract; mismatches surface at runtime via M2 (Version Drift), not at release time. The lint catalog releases off-cycle from `PRISM.md`; its tag (`lint-v{N}`) and the `lint_catalog_version` field in `PRISM.md` frontmatter are independent integer counters that may sit at different values. ## Singleton + snapshot pattern @@ -29,11 +30,13 @@ For framework and Lens Library, every release leaves two files on `main`: For backlog, the same pattern applies but without tagging — backlog is not a release artifact, just a persistent working surface. +The lint catalog (`lint_rules.md`, `scripts/lint/`, `.github/workflows/lint.yml`) does not have a pinned snapshot. The `lint-v{N}` tag marks the catalog state at the moment of release; later catalog edits ride on `main` and a new `lint-v{N+1}` tag is cut when the surface changes meaningfully. + ## Framework release (MAJOR / MINOR / PATCH) When `PRISM.md` advances to a new framework version (e.g. `v2.1.0`): -1. **Edit `PRISM.md`** with the new framework content. Update the version string in the document header (`# PRISM v{X.Y} — Framework operating document`) and any in-document version references. +1. **Edit `PRISM.md`** with the new framework content. Update the version string in the document header (`# PRISM v{X.Y} — Framework operating document`), the frontmatter `version`, `released`, `supersedes` fields, the inline `Currently v{X.Y.Z}` substring inside the frontmatter `description`, the EOF marker, and any in-document version references (§18.1 project identity, §18.2 pinned-URL column, §18.3 currency example, §18.5 citation). 2. **Refresh the version-pinned snapshot.** Within the same major line, delete the prior snapshot; at a major boundary, retain the prior major's terminal snapshot (see *Retention*). ```bash rm PRISM_v{old}.md # within same major @@ -42,16 +45,17 @@ When `PRISM.md` advances to a new framework version (e.g. `v2.1.0`): 3. **Update `SKILL.md`** if the loader contract changed — at minimum, update the `name:` field if the major changed (`name: prism-v{N}`), and any references to `PRISM_v{X_Y_Z}.md` in the load instructions. SKILL.md tracks the framework's MAJOR.MINOR; PATCH releases typically don't require SKILL.md changes. 4. **Update `CITATION.cff`** — bump `version`, update `date-released` to today (UTC), and refresh the `abstract` if the surface changed materially (any MAJOR; most MINORs). 5. **Update `README.md`** *Current version* section: new version number, new snapshot filename link, refreshed surface description. -6. **Refresh `design/`** at MAJOR boundaries — check in the design document and specification that produced the release. MINOR/PATCH releases typically don't add to `design/`; if they do (substantial design rationale worth preserving), add but don't restructure. -7. **Commit, tag, push, release.** +6. **Update `VERSION`** — single-line file containing the new framework version on its own line (no trailing whitespace). +7. **Refresh `design/`** at MAJOR boundaries — check in the design document and specification that produced the release. MINOR/PATCH releases typically don't add to `design/`; if they do (substantial design rationale worth preserving), add but don't restructure. +8. **Commit, tag, push, release.** ```bash git add -A git commit -m "Release v{X.Y.Z}" git tag -a v{X.Y.Z} -m "Release v{X.Y.Z}" git push origin main v{X.Y.Z} ``` -8. **Create a GitHub Release** at the tag (`https://github.com/Ronkupper/PRISM/releases/new?tag=v{X.Y.Z}`). Title: `PRISM v{X.Y.Z}`. Body: surface summary + calibration / report-back items + link to design provenance. -9. **Post a Discussions announcement** in *Announcements* category. Title: `PRISM v{X.Y.Z} released`. Body: link to the release tag, surface highlights, calibration items worth reporting back, link to surface-drift map (Appendix D for v2.x; analogous appendix for future majors), link to `design/` artifacts at the tag. See the `v2.0.0` announcement for shape reference. +9. **Create a GitHub Release** at the tag (`https://github.com/Ronkupper/PRISM/releases/new?tag=v{X.Y.Z}`). Title: `PRISM v{X.Y.Z}`. Body: surface summary + calibration / report-back items + link to design provenance. +10. **Post a Discussions announcement** in *Announcements* category. Title: `PRISM v{X.Y.Z} released`. Body: link to the release tag, surface highlights, calibration items worth reporting back, link to surface-drift map (Appendix D for v2.x; analogous appendix for future majors), link to `design/` artifacts at the tag. See the `v2.0.0` announcement for shape reference. ## Lens Library release @@ -77,6 +81,22 @@ When `lens/PRISM_lens_library.md` advances (e.g. `v0.10` or `v1.0`): 6. **Create a GitHub Release** at the lens tag. 7. **Post a Discussions announcement** in *Announcements* if the release is material (new major, significant new lenses, calibration milestone). Patch-grade lens edits don't necessarily warrant an announcement — judgment call. +## Lint catalog release (`lint-v{N}`) + +When `lint_rules.md`, the `scripts/lint/` scripts, or the `.github/workflows/lint.yml` workflow advances in a way that changes the catalog surface (a new active rule, a severity change, a rule retirement, output-format change): + +1. **Edit the relevant files.** If a new rule activates or the catalog gains/loses entries, also bump `lint_catalog_version` in `PRISM.md` frontmatter — and ship that bump as a framework PATCH on the framework track in a separate commit. +2. **Verify locally.** Run `python scripts/lint/lint_named_refs.py PRISM.md` (zero error findings expected) and `yamllint .github/workflows/lint.yml`. +3. **Tag.** + ```bash + git add -A + git commit -m "Lint catalog v{N}" + git tag -a lint-v{N} -m "PRISM lint catalog v{N}" + git push origin main lint-v{N} + ``` +4. **GitHub Release optional.** A Release page on `lint-v{N}` is useful when the catalog surface changes meaningfully (new active rule). Minor-script edits don't warrant a Release. +5. **Discussions announcement** only for material catalog changes. + ## Backlog refresh `PRISM_backlog.md` is a persistent working surface, not a release artifact: @@ -116,12 +136,13 @@ Tags are protected. Past versions are recoverable from any clone of the repo for Before pushing a framework tag: -- [ ] Document version string updated in header and any in-document references +- [ ] Document version string updated in header and any in-document references (frontmatter `version`, frontmatter `released`, frontmatter `supersedes`, frontmatter `description` inline `Currently v{X.Y.Z}`, EOF marker, §18 references) - [ ] Version-pinned snapshot file present and byte-identical to stable file (`diff PRISM.md PRISM_v{X_Y_Z}.md` returns no output) -- [ ] `SKILL.md` reviewed for version drift (loader instructions reference current snapshot filename) +- [ ] `SKILL.md` reviewed for version drift (loader instructions reference current snapshot filename); description prefix matches release - [ ] `CITATION.cff` version + date + abstract current - [ ] `README.md` *Current version* section current -- [ ] Named-refs lint clean — `python PRISM-workshop/scripts/lint_named_refs.py PRISM.md` returns 0 errors (info-level orphan findings acceptable) +- [ ] `VERSION` file matches frontmatter `version` and title-block heading +- [ ] **Lint gate clean** — the CI workflow at `.github/workflows/lint.yml` runs the `scripts/lint/` catalog against `PRISM.md` and reports zero error-severity findings. At v2.1.0, this is `PRISM-LINT-01` (named-refs-resolve). Active rules grow as the catalog evolves: when Pattern A's schema lands, `PRISM-LINT-03`, `-04`, `-05`, and `-07` become active; when Pattern B Phase B2 lands, `PRISM-LINT-06` activates. Info-level findings from `PRISM-LINT-02` (orphan anchors) are acceptable and do not block release. - [ ] `design/` updated if MAJOR - [ ] Commit signed (`gpg.format=ssh`, `commit.gpgsign=true`) - [ ] Discussions announcement drafted (post after tag push and Release creation) diff --git a/SKILL.md b/SKILL.md index 300399c..93c987b 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,16 +1,16 @@ --- name: prism-v2 -description: PRISM v2.0.2 — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md, Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Do NOT trigger for unrelated audit work, generic prompt engineering, or v1.10.4-specific terminology like Starter, GATE-0/1/2, Scope Flags, Runtime Profile, Assumption Register — those are v1.x and v2.0 supersedes them. +description: PRISM v2.1.0 — structured multi-session, multi-vendor LLM-orchestrated audit and research framework. Trigger this skill whenever the user invokes PRISM mechanics by name or by recognizable construct: PRISM audit, PRISM v2, begin a PRISM audit, Master file, any filename matching *_master_p*.md, Prompt Strategy, Lens Library, Vendor Selection, Vendor Triangulation, Setup probes or any of P1-P7 by number, Monitor M* or any of M1-M12 by number, Standing Principle SP-*, Execution Envelope, Execution Self-check, Execution Output, Dispatch register, Dispatch shape (equivalence/split/limitation-named), the What is next artifact, context band or 🟢🟡🟠🔴, migration handoff, P0/P1 boundary, three-layer readiness, Claude Project recommendation, Update session, point refresh, Setup artifacts (Decision brief / Stakeholder register / Claim inventory / Jurisdiction map). Also trigger when the user attaches a Master file or a Lens Library file. Do NOT trigger for unrelated audit work, generic prompt engineering, or v1.10.4-specific terminology like Starter, GATE-0/1/2, Scope Flags, Runtime Profile, Assumption Register — those are v1.x and v2.0 supersedes them. --- -# PRISM v2.0.2 framework loader +# PRISM v2.1.0 framework loader -This Skill loads PRISM v2.0.2 — the canonical framework operating document for +This Skill loads PRISM v2.1.0 — the canonical framework operating document for structured multi-session, multi-vendor LLM-orchestrated audit and research. ## When triggered -1. Read `PRISM_v2_0_2.md` (version-pinned) or `PRISM.md` (always-current) from +1. Read `PRISM_v2_1_0.md` (version-pinned) or `PRISM.md` (always-current) from this Skill's folder, the operator's project, or the attached copy in full before responding to the operator's request. 2. Run SP-13 substrate self-check (§10.1.3): declare your model identity and @@ -34,13 +34,16 @@ structured multi-session, multi-vendor LLM-orchestrated audit and research. - Write Master + *What's next* at every orchestration turn-close per §5.5 continuous-state mechanic, regardless of band. - Apply two-axis tags (`structural | stable` etc.) to any new decision the - framework adds during operation. + framework adds during operation. Per the v2.1.0 normativity vocabulary, + optional strength (`required` / `recommended` / `optional`) and polarity + (✅ / ⚠️ / 🚫) tokens may also appear; defaults are declared in PRISM.md + frontmatter. - Emit operator hints per §13 catalog only when a cue applies to the specific dispatch — routine turns carry no hints. ## Files this Skill expects in the Project or attached -- `PRISM.md` (always-current) or `PRISM_v2_0_2.md` (version-pinned) +- `PRISM.md` (always-current) or `PRISM_v2_1_0.md` (version-pinned) - `PRISM_lens_library.md` v0.10 (canonical catalog; `prism-lens-v0.10` tag) - `[project]_prism2.0_master_*.md` (the Master) - `[project]_brief.md` (subject brief, at Setup) @@ -49,7 +52,7 @@ structured multi-session, multi-vendor LLM-orchestrated audit and research. `PRISM.md` at the repo root carries its own skill frontmatter (`name: prism`, v1.x fused-file pattern). This `SKILL.md` is the v2-native loader pattern -(`name: prism-v2`) — separate loader, body lives in `PRISM_v2_0_2.md`. +(`name: prism-v2`) — separate loader, body lives in `PRISM_v2_1_0.md`. Either pattern works; pick whichever fits your environment. ## What this Skill does NOT do diff --git a/VERSION b/VERSION index e9307ca..7ec1d6d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.0.2 +2.1.0