@korallis/k-pi 0.1.0

package/dist/kpi/kstack/generated/skills/why/references/synthesizer-prompt.md

@@ -0,0 +1,135 @@
+# Synthesizer Prompt Template
+
+Build the synthesizer's prompt from this template; fill in the placeholders.
+
+---
+
+You are answering a "why" question about a piece of code by synthesizing findings from multiple investigators who searched different historical sources (source control, issue / ticket tracker, long-form documents, real-time team chat, infrastructure observability, error / exception tracking, product analytics warehouse, and code comments). Produce a confidence-weighted, evidence-cited narrative that honestly communicates what the evidence supports and what it doesn't.
+
+## The Question
+
+> {QUESTION}
+
+## The Code Anchor
+
+**Target files:** {FILES_WITH_LINE_RANGES}
+
+**Key symbols:** {SYMBOLS}
+
+## Investigator Findings
+
+{ALL_INVESTIGATOR_FINDINGS}
+
+## Sources That Weren't Searched
+
+{SKIPPED_SOURCES_WITH_REASONS}
+
+## Epistemics Framework
+
+You MUST follow the framework in `references/epistemics.md`. Read it in full before writing the output. The key rules:
+
+1. Every claim sits in one of these tiers: **Direct**, **Supported**, **Inferred**, **Speculative**, **Unknown**. The tier determines what section the claim goes in and how it's phrased.
+2. Every Direct/Supported claim must have a citation (PR #, ticket ID, doc URL, chat permalink, commit hash, or file:line).
+3. Inferred and Speculative claims must use hedged language ("appears to", "likely", "suggests", "one possibility is").
+4. Never cite code as evidence for its own intent.
+5. Gaps in the evidence must be documented. Don't fill them with plausible-sounding guesses.
+6. If the user's question embedded a hypothesis, treat it as a candidate, not a conclusion. Check the evidence independently.
+
+## Instructions
+
+1. **Read all investigator findings.** They gathered raw evidence, not conclusions. You weigh it.
+2. **Reconcile overlapping findings.** Multiple investigators may have cited the same PR, ticket, or doc. Merge into a single, authoritative reference.
+3. **Identify contradictions.** If two items of evidence disagree, don't pick one. Surface both.
+4. **Calibrate confidence.** For each claim, identify the evidence and the tier. State Direct claims plainly with a citation. Hedge Inferred claims and explain the inference. Mark Speculative claims explicitly. Put claims with no evidence in the gaps section.
+5. **Verify citations by spot-checking.** You can read the codebase and call MCP tools to verify citations; do not write files, commit, or modify external state. If you're uncertain a cited item exists or says what's claimed, check it. Don't propagate errors.
+6. **Don't overreach.** The user will act on your output. Better to leave an open question open than to fill it with a confident-sounding guess.
+
+## Output Format
+
+Write the output for the user. Use this exact structure:
+
+---
+
+### The Question
+
+Restate the user's question in one or two sentences so the answer is anchored.
+
+### The Code in Question
+
+File paths, line ranges, key symbols. Two or three lines to orient a reader who lands here cold.
+
+### What We Found
+
+**Claims with direct evidence**, one per bullet. Quote or paraphrase the source and cite precisely. Format each finding like:
+
+- **[Direct]** {Claim}. Source: [PR #123](url) / ticket ID / file:line. {Brief quote or paraphrase.}
+- **[Supported]** {Claim}. Evidence: {list of items and what each contributes}.
+
+Use `[Direct]` for single-source, explicit evidence. Use `[Supported]` when multiple indirect items converge on a conclusion.
+
+### What We Can Reasonably Infer
+
+**Claims that aren't explicitly stated anywhere but are well-supported by indirect evidence.** Make the inference chain visible: "Given A and B, it's likely that C." Use hedged language ("appears to", "likely", "suggests", "is consistent with"). Format:
+
+- **[Inferred]** {Hedged claim}. Reasoning: {the specific evidence and the inference step}.
+
+If there's nothing to infer, skip this section.
+
+### Competing Hypotheses
+
+**If the evidence fits multiple stories, present them.** Don't force a winner when the record doesn't support one. For each hypothesis:
+
+- **Hypothesis:** {one-sentence statement}
+- **Evidence for:** {specific items}
+- **Evidence against or missing:** {what would need to be true but isn't, or what counter-signals exist}
+
+Skip this section if there's a single clear answer.
+
+### What We Don't Know
+
+**Explicit gaps.** Things the user asked that the evidence didn't answer. Sources searched that came up empty. Sources that weren't searchable at all, such as a missing real-time team chat MCP.
+
+Be specific. "We searched the issue tracker for [query1], [query2], [query3] and found no issue discussing the rate-limit threshold" is useful. "We don't know why" is not. Include:
+
+- Specific questions that went unanswered
+- Searches that returned nothing
+- Sources that were unavailable (and why)
+- People who would likely know but who you can't ask
+
+### Sources Consulted
+
+Bulleted list of what was actually searched, so the user can judge coverage and redirect. Format:
+
+- **Source control history**: {file paths}, {number of commits reviewed}, PRs #{numbers}, and code comments searched. Or "Not searched. This should not happen because git and `gh` are always expected."
+- **Issue / ticket tracker**: {ticket IDs and keyword searches}. Or "Not searched. No matching MCP available in this environment."
+- **Long-form documents**: {page titles and search queries}. Or "Not searched. No matching MCP available in this environment."
+- **Real-time team chat**: {channels searched, date ranges, queries}. Or "Not searched. No matching MCP available in this environment."
+- **Infrastructure observability**: {dashboards, monitors, metrics, logs, traces, or incidents searched}. Or "Not searched. No matching MCP available in this environment."
+- **Error / exception tracking**: {issues, events, or releases searched}. Or "Not searched. No matching MCP available in this environment."
+- **Product analytics warehouse**: {fully-qualified tables queried, the time windows, and the numeric summaries (counts, percentiles, first/last-seen timestamps) that bore on the question}. Or "Not searched. No matching MCP available in this environment."
+
+### Confidence Summary
+
+One or two sentences summarizing your overall confidence. E.g.:
+
+> "The core rationale (A) is well-supported by direct PR and ticket evidence. The specific threshold value (100) is inferred from the surrounding context but not explicitly documented. The question of whether this was driven by a customer request could not be answered. No relevant issue tracker or long-form doc content surfaced, and real-time team chat search was unavailable."
+
+---
+
+## Quality Check Before Returning
+
+Before finalizing, review your output against this checklist:
+
+1. Does every claim in "What We Found" have a citation? If not, add one or move the claim to "Inferred" or "Hypotheses."
+2. Is the phrasing tier-appropriate? (Direct claims can use "because"; Inferred claims cannot.)
+3. Did you surface any contradictions you noticed, or did you quietly pick one?
+4. Does the "What We Don't Know" section exist and name specific gaps? If it's empty or missing, be suspicious. Historical investigations almost always have gaps.
+5. If the user embedded a hypothesis in their question, did you check it against the evidence rather than rubber-stamping it?
+6. Did you cite any code as evidence for its own intent? Remove those. Code is mechanics, not motivation.
+7. Is the overall tone calibrated? A confident-sounding answer with weak evidence is the exact failure mode this skill exists to prevent.
+
+If any item fails, revise before returning.
+
+## A Final Note
+
+The value of this output comes from its honesty, not its authority. A reader who takes your answer to the original author, an engineering lead, or a product manager should be well-positioned to ask the right follow-up questions. Be clear about what's known, what's inferred, and what's missing. Don't optimize for looking decisive. Optimize for being useful.

package/dist/kpi/kstack/model-ladder.md

@@ -0,0 +1,50 @@
+# K-stack model ladder
+
+Used by `/setup-kstack` to **suggest** a mapping. Operator applies or edits. Never
+written as a required default.
+
+Cut date: 2026-08-31.
+
+The order below is a starting point for this harness, not a benchmark result and
+not a claim about any model. `/setup-kstack` intersects it with the live registry
+and the operator's own configured pools, so an entry that is not available is
+simply skipped.
+
+## Role suggest lists
+
+First live slug that matches a pattern wins. Patterns are substring match on `provider/id` after `getAvailable()` ∩ healthy pools.
+
+| Role | Prefer, in order | Why | Confidence |
+|---|---|---|---|
+| implementer | `gpt-5.6-sol`, `glm-5.3` (not flash), `opus-5`, `kimi-k3`, `grok-4.6`, `glm-5.2` | General implementation. Second and third entries are value and UI-heavy alternates. | Medium |
+| frontend | `kimi-k3`, `fable-5`, `opus-5`, `glm-5.3` | Frontend and design work. | Medium-high |
+| judgment | `opus-5`, `fable-5`, `gpt-5.6-terra`, `gpt-5.6-sol`, `kimi-k3` | Review and judgment. | Medium |
+| precise | `gpt-5.6-sol`, `gpt-5.6-terra`, `opus-5`, `glm-5.3` | Exact contracts. | Medium |
+| fast | `gpt-5.6-luna`, `glm-5.3-flash`, `grok-4.6`, any local | Cheap movers, including any configured local pool. | Medium |
+| review_panel | Prefer `opus-5` + `gpt-5.6-sol`. If the job is UI, `kimi-k3` + `fable-5`. Cap 3. | Cross-family review; capped at three. | Medium |
+
+If a role has no match: `inherit-parent`.
+
+Do not suggest Cursor Cloud slugs. Do not require a named id that is not in the live registry.
+
+## Overall working order
+
+Use only as a tie-break when two candidates match the same role pattern.
+
+1. GPT-5.6 Sol — general implementation
+2. GLM-5.3 — general implementation
+3. Claude Opus 5 — review and judgment
+4. Kimi K3 — frontend, official pool `kimi-coding`
+5. Claude Fable 5 — review and frontend
+6. GPT-5.6 Terra — exploration and long review
+7. Grok 4.6 — fast movers
+8. GLM-5.3 Flash — fast movers
+9. Claude Opus 4.8 — review and judgment
+10. GLM-5.2 — general implementation
+11. GPT-5.6 Luna — fast movers
+12. Grok 4.5 — fast movers
+13. GLM-5.1 — general implementation
+
+## Refresh rule
+
+Bump this file in a dated commit. `/setup-kstack` reads the committed lists. No network scrape at setup time.

package/dist/kpi/kstack/provenance.json

@@ -0,0 +1,17 @@
+{
+	"origin": {
+		"repository": "https://github.com/cursor/plugins.git",
+		"path": "pstack/",
+		"commit": "efa2a531985e0a8084d36ff3cf87233be8a9f34b",
+		"treeOid": "1c625329e71538629f087374daa71293a498089f"
+	},
+	"transformVersion": "1b86ea71f862661208be21916b5a12aa9024b96253890da40dd8e1ff677aa1c2",
+	"patches": [],
+	"license": {
+		"path": "LICENSE",
+		"spdx": "MIT",
+		"holder": "Lauren Tan",
+		"sha256": "bc957ca6bee02792566a1a028d105e02e247c6e77cf057061674273da77b200e"
+	},
+	"overlayVersion": 1
+}

package/dist/kpi/prompts/implement.md

@@ -0,0 +1,6 @@
+---
+description: Implement the current frozen task with TDD
+argument-hint: "[task-or-slice]"
+---
+
+Implement `$ARGUMENTS` or the current run task. Apply the `tdd-cycle` skill: capture red evidence before non-trivial production changes, stay inside frozen write bounds, and make the smallest complete change. Never write `verdict.json`, `release.approved`, or broaden acceptance criteria.

package/dist/kpi/prompts/plan.md

@@ -0,0 +1,6 @@
+---
+description: Plan a frozen task without implementing it
+argument-hint: "<goal-or-spec-path>"
+---
+
+Plan `$ARGUMENTS` from repository evidence and the frozen task or specification. Research first. Define ordered vertical slices, exact paths, acceptance checks, write bounds, risks, and `stack.json` module boundaries. Keep planner tools read-only and do not implement.

package/dist/kpi/prompts/review.md

@@ -0,0 +1,6 @@
+---
+description: Review the current candidate in an isolated read-only context
+argument-hint: "[job-id]"
+---
+
+Apply the `isolated-review` skill to `$ARGUMENTS` or the active run. Read the frozen task, diff, candidate, and fresh evidence. Check every required criterion and bound. Do not modify files. Return only JSON matching `schemas/verdict.schema.json`.

package/dist/kpi/prompts/ship.md

@@ -0,0 +1,6 @@
+---
+description: Commit an approved gated run without pushing
+argument-hint: "[job-id]"
+---
+
+Ship `$ARGUMENTS` or the active run only after human approval. Apply the `conventional-commit` skill and create exactly one local commit whose subject matches `^(feat|fix|docs|refactor|test|chore)(\(.+\))?: `. Include only the approved candidate. Never push, deploy, or amend unrelated history.

package/dist/kpi/prompts/specify.md

@@ -0,0 +1,6 @@
+---
+description: Specify a task without implementing it
+argument-hint: "<goal>"
+---
+
+Apply the `spec-first` skill to `$ARGUMENTS`. Research existing behavior and conventions first. Produce requirements, design, ordered vertical tasks, executable acceptance criteria, constraints, non-goals, and `stack.json` boundaries. Do not implement production code or claim narrative criteria are executable.

package/dist/kpi/prompts/verify.md

@@ -0,0 +1,6 @@
+---
+description: Run acceptance checks and project quality gates
+argument-hint: "[job-id]"
+---
+
+Apply the `quality-gates` skill to `$ARGUMENTS` or the active run. Execute every required acceptance check and each exact command in `task.json.quality_gates`. Bind receipts to current HEAD and report red for any failure or stale evidence. Do not substitute proxy commands.