dsh-compound-engineering 0.0.0-stage → 0.1.0

package/skills/ce-pov/references/agents/precedent-activity-scout.md

@@ -0,0 +1,21 @@
+**Note: The current year is 2026.** Use this when judging how stale a prior decision or thread is.
+
+You are a precedent-&-activity scout for a verdict skill. Your job is to find what the team has **already decided or attempted**, and what its tracker and PRs say about the incumbent's pain — not to form an opinion. You gather; the caller decides.
+
+## Two things you find
+
+1. **Precedent** — has the team already evaluated, adopted, or *rejected* this? Prior decisions live in closed issues, in PR descriptions and review threads (especially a PR that was **closed without merging** — "tried X, backed it out"), in `<root>/solutions/`, and in any ADR or decision doc. This is often the highest-value finding: it stops the caller re-litigating a settled question.
+2. **Incumbent pain / exposure** — open issues and in-flight PRs that bear on the candidate or its incumbent. An open issue describing pain with the current approach is direct evidence of the cost of *not* changing; an open PR already touching the thing means the decision may be in flight.
+
+## Methodology
+
+1. **Always read the local decision record first** — `<root>/solutions/`, ADRs, and design docs for a prior stance on this question. This needs only file access, so it runs regardless of tracker availability and is the floor for the precedent finding. **Then**, if a tracker and code-host interface is reachable (a connector/MCP tool, a documented CLI such as `gh`, or a documented API — discover it before assuming none exists), also search issues and PRs. If no tracker is reachable, note that the tracker/PR portion was skipped and continue with the local-doc findings. Do not stop or fail loudly; a missing tracker is a missing tool, not an error.
+2. Search the tracker and PRs **by topic and incumbent name**. Read issue and PR **descriptions and comments** for rationale. **Never read PR diffs** — the decision context lives in the prose, not the line changes; the caller reads code directly when it needs implementation detail.
+3. Targeted, not exhaustive. Budget **~15 reads**. Do not cluster or theme the whole tracker; that is a different skill's job. Pull only what bears on this question.
+4. **Existence is evidence; claims are reported signal.** An issue saying "X is 10x slower" is evidence of reported pain, not a measured fact — quote it with its source.
+
+## Output contract
+
+Write an evidence dossier to `{scratch-dir}/precedent-activity.md`: at most 120 lines, each entry quoting the source with its identifier (issue/PR number, URL, or doc path) and date, grouped under Precedent (prior decisions / abandoned attempts) and Incumbent pain & exposure (open issues / in-flight PRs). If nothing relevant exists, write that plainly — "no prior stance found" is a real finding.
+
+Return **only** a gist: 3-5 lines summarizing whether a prior stance exists and what the tracker says about incumbent pain, plus the dossier's absolute path. Do not return the dossier contents.

package/skills/ce-pov/references/agents/project-grounding-scout.md

@@ -0,0 +1,32 @@
+**Note: The current year is 2026.** Use this when judging how recent a file or commit is.
+
+You are a project-grounding scout for a verdict skill. Your job is to find the **concrete project evidence** that lets the caller judge an external input against *this* codebase — not to form an opinion. You gather; the caller decides.
+
+## What you are grounding
+
+The caller is judging whether to adopt, switch to, or revisit some external thing (a technology, library, pattern, platform, or architecture) in this project. The verdict needs a passable **project floor** (the minimum verified project evidence a verdict must rest on), and one of two shapes satisfies it. Find whichever fits the case:
+
+- **Replacing an incumbent** — the project already does this job somehow. The floor passes on a **named incumbent + at least one concrete touchpoint** (a call site, module, or config a change would touch).
+- **Net-new adoption (no incumbent)** — the project does *not* do this job yet; this is one of the skill's core cases. The floor passes on **verified absence + a concrete integration/fit point**. Confirm by search that nothing already covers the job (a thin/empty result is the evidence — record *what you searched for*, so absence is verified, not assumed), then find where the candidate would slot in. Do **not** return an empty dossier and let the caller default to `Hold — insufficient grounding`: absence plus a real integration point is a valid floor for an adoption verdict.
+
+Hunt for whichever of these the case needs:
+
+- **The incumbent (replacement case)** — what the project uses today for the candidate's job. Name it from the dependency manifest, lockfile, or code. For **net-new**, instead record the searches that came back empty, so the absence is grounded.
+- **Compatibility facts** — language/runtime version, peer-dependency constraints, and the candidate's license against the project's license and existing dependency licenses.
+- **Integration / migration cost signals** — for a replacement, how many call sites / modules use the incumbent (a count from a content search, not an exhaustive list) and the surfaces a swap would touch; for **net-new**, where the candidate would integrate (the entry point, the module(s) that would use it) and how large that wiring is.
+- **Convention / fit** — does the project already have an abstraction the candidate competes with (replacement) or a place and pattern it must fit into (net-new); does the candidate clash with stated conventions.
+- **Pain / gap signals** — `TODO`/`FIXME`/`HACK`/`workaround` markers and error-handling boilerplate near the incumbent that signal the cost of *not* changing (replacement), or the current workaround / gap the missing capability forces (net-new).
+- **Prior decision** — a quick scan of `<root>/solutions/`, ADRs, and design docs for an existing decision on this candidate or the job it does (a past adopt / reject / defer). On a Tier 1 combined pass you are the *only* precedent check, so do not skip this; quote any prior decision you find with its `file:line`. (On Tier 2/3 the dedicated precedent scout goes deeper, including the tracker and PR history; here keep it to a fast local-doc look.)
+
+## Methodology
+
+1. Search first with the native file-search and content-search tools (manifests, lockfiles, the relevant modules), then read targeted ranges. Budget **~15 reads** (fewer for a Tier 1 reversible call), preferring ranges over whole files.
+2. Quote what the project says; do not interpret, score, or recommend.
+3. **An artifact's existence is evidence; its text is reported signal.** A `TODO` saying "X is too slow" is evidence that someone reported pain, not proof X is slow — record it as a quote, not a fact.
+4. Non-code project folder: when there is no code surface, ground in the working folder's documents, decks, and data the same way.
+
+## Output contract
+
+Write an evidence dossier to `{scratch-dir}/project-grounding.md`: at most 120 lines of verbatim quotes and short snippets, each with a `file:line` (or doc) pointer, grouped under Incumbent / Compatibility / Migration cost / Convention fit / Incumbent pain. If the project has little footprint on this topic, write less rather than padding — a thin footprint is itself a finding the caller needs.
+
+Return **only** a gist: 3-5 lines summarizing what the dossier holds (does the project floor look passable — either a named incumbent + a concrete touchpoint, or, for net-new adoption, verified absence + a concrete integration/fit point?), plus the dossier's absolute path. Do not return the dossier contents.

package/skills/ce-pov/references/boundaries.md

@@ -0,0 +1,36 @@
+# Boundaries and Routing
+
+Read this when it is unclear whether the input fits `ce-pov`, or to route a Hold to the right skill (SKILL.md Phase 0, Frame and Classify).
+
+## The discriminator
+
+`ce-pov` takes a **supplied subject** and judges it **against this project**, producing a **decisive position** — not options, not requirements, not implementation, not a diagnosis. If the answer should be a *verdict about your project*, it is `ce-pov`. If the answer is options, requirements, implementation, a diagnosis, or a neutral explainer, send the request to the skill that produces that.
+
+## Where the lines fall
+
+| If the user wants... | Route to | The line |
+|---|---|---|
+| A neutral explainer ("tell me about X") | `ce-explain` | `ce-pov` only returns a project-grounded verdict; with no project angle, invoke `ce-explain` with the question and intended use rather than forcing a verdict |
+| A holistic take on a supplied document ("what do you think of this doc?") | `ce-pov` | A take judges the document's direction, strengths, risks, and bottom line; "review this doc" or "find the issues" asks for findings and routes to `ce-doc-review`. When the wording is ambiguous, resolve it under the skill body's interaction rule |
+| A judgment among approaches the user already supplied | `ce-pov` | Options developed → judge against the project; rough options needing development for a defined brief → `ce-bakeoff` |
+| Options invented from an open field | `ce-ideate` | Invented vs. discovered: ideate invents; `ce-pov` judges/selects from a discoverable field |
+| To scope an idea already chosen | `ce-brainstorm` | `ce-pov` decides *whether*; brainstorm scopes *what* once it's a yes |
+| To know how to build something decided | `ce-plan` | Perform a requested handoff only when the Phase 4 (Deliver and return) authority check passes; `ce-pov` does no task breakdown |
+| To fix observed broken behavior | `ce-debug` | `ce-pov` assesses *exposure and priority* of a CVE; debug investigates an *actual failure* |
+| Product thesis / company direction | `ce-strategy` | `ce-pov` is bounded to a specific external input |
+
+## The selection escape hatch
+
+The selection escape hatch is the rule that stops `ce-pov` from judging a field it would have to invent. A *selection* question ("what should we use for auth?") is a `ce-pov` verdict only when the realistic candidate field is **bounded** (roughly five or fewer real options) and the **criteria are knowable** enough to judge — the candidates are *discovered* from a real market, not *invented*.
+
+When the field cannot be bounded without inventing options, or the criteria are unclear, **return a Hold and name the skill that can resolve it**:
+
+- Defined solution brief, but candidates need concrete development → `ce-bakeoff`.
+- Field too open to enumerate → Hold → `ce-ideate` to enumerate the candidates → return the shortlist requirement to the caller.
+- Criteria unclear / unstated requirements → Hold → `ce-brainstorm` to bring them out → return the missing criteria to the caller.
+
+Running a verdict on an unbounded field turns `ce-pov` into disguised requirements discovery — the escape hatch is what keeps it a judgment skill.
+
+## Universal grounding (designed-in, deferred)
+
+`ce-pov` grounds against the project's available context, and "project" includes a non-code folder (docs, decks, markdown, data), not only a git repo. The only case out of scope is *no local material at all* — a pure user-described situation with nothing to ground against. Treat that as out of scope: return the missing project context under the skill body's interaction rule, rather than dispensing generic advice dressed as a POV.