@codeam/shared 2.61.25 → 2.61.27

package/dist/index.mjs

@@ -1022,7 +1022,7 @@ function getIntegrationBranding(id) {
   return INTEGRATION_BRANDING[id] ?? null;
 }
 
-// src/skills/registry.ts
+// src/skills/code-review.ts
 var CODE_REVIEW_BODY = `Use this skill when reviewing a pull request. It defines what a high-signal
 review looks like so your inline comments are worth the author's time.
 
@@ -1055,6 +1055,18 @@ line, each led by a severity tag (blocker/should-fix/nit) and a concrete reason
 (the failure scenario or risk), not a restatement of the diff. If the change is
 correct and well-tested, approve and say so \u2014 finding nothing is a valid outcome.
 Review only the diff and its direct blast radius; do not demand unrelated refactors.`;
+var codeReviewSkill = {
+  id: "code-review",
+  name: "Code Review",
+  description: `High-signal PR review: prioritize correctness \u2192 security \u2192 tests \u2192 clarity, one anchored finding per comment.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: CODE_REVIEW_BODY },
+    instruction: { body: CODE_REVIEW_INSTRUCTION }
+  }
+};
+
+// src/skills/resolve-conflicts.ts
 var RESOLVE_CONFLICTS_BODY = `Use this skill when resolving merge conflicts on a pull request. The goal is a
 merge that preserves BOTH sides' intent, not one that just makes the file compile.
 
@@ -1078,28 +1090,134 @@ and prefer a union of intents; drop a side only when the two are mutually exclus
 keeping the side that matches the PR's purpose. Leave no conflict markers behind
 (grep for them). Regenerate lockfiles rather than hand-merging them. The result must
 build and pass tests \u2014 run them \u2014 before you commit and push.`;
-var SKILL_REGISTRY = {
-  "code-review": {
-    id: "code-review",
-    name: "Code Review",
-    description: `High-signal PR review: prioritize correctness \u2192 security \u2192 tests \u2192 clarity, one anchored finding per comment.`,
-    source: "curated",
-    delivery: {
-      skillFile: { body: CODE_REVIEW_BODY },
-      instruction: { body: CODE_REVIEW_INSTRUCTION }
-    }
-  },
-  "resolve-conflicts": {
-    id: "resolve-conflicts",
-    name: "Resolve Conflicts",
-    description: `Merge-conflict resolution that preserves both sides' intent, leaves no markers, and keeps the build green.`,
-    source: "curated",
-    delivery: {
-      skillFile: { body: RESOLVE_CONFLICTS_BODY },
-      instruction: { body: RESOLVE_CONFLICTS_INSTRUCTION }
-    }
+var resolveConflictsSkill = {
+  id: "resolve-conflicts",
+  name: "Resolve Conflicts",
+  description: `Merge-conflict resolution that preserves both sides' intent, leaves no markers, and keeps the build green.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: RESOLVE_CONFLICTS_BODY },
+    instruction: { body: RESOLVE_CONFLICTS_INSTRUCTION }
   }
 };
+
+// src/skills/spec-driven-development.ts
+var SPEC_DRIVEN_BODY = `Use this skill for any coding task that isn't a trivial one-liner. Build the right
+thing, provably, with the least ceremony the task warrants \u2014 specification before
+code, but its depth scales to the work. Skipping it yields code that looks right yet
+solves the wrong problem or breaks something you never checked.
+
+## Step 0 \u2014 Right-size the work (always first)
+- **Quick** \u2014 a typo, copy tweak, one-line fix, a single file with no unknowns.
+  No ceremony: make the change, run the relevant test/build, confirm it. Do NOT
+  write a spec for a typo.
+- **Standard** \u2014 a feature or fix across a few files, some unknowns, a testable
+  outcome. A light inline pass (a 2-3 sentence spec + a short plan), then build
+  test-first, then verify. No scaffolding files.
+- **Deep** \u2014 large, ambiguous, risky, or touching many files / shared contracts /
+  data / auth. The full flow below, tracking the work in beads (\`bd\`), not scratch
+  files.
+When unsure, start one level lighter and escalate the moment real ambiguity or risk
+appears. State which level you picked in one line.
+
+## Step 1 \u2014 Ground in the real codebase (before specifying anything non-trivial)
+You are almost never in a greenfield. Before you spec or plan, survey the real code:
+the existing patterns for this kind of change, the files you'll touch, the test
+setup, prior art, and the constraints (auth, data, shared types, CLAUDE.md
+conventions). A spec written in a vacuum produces a plan that fights the codebase.
+Read first; never assume.
+
+## Step 2 \u2014 Specify: the WHAT and WHY (not the HOW)
+State the user-visible outcome and why it matters, then the acceptance criteria \u2014
+each concrete and testable ("tapping X shows Y", "the endpoint returns 409 when Z"),
+never vague ("works well"). List what is out of scope. Put NO implementation detail
+here (no file names, no libraries). If a requirement is ambiguous, mark it rather
+than guess.
+
+## Step 3 \u2014 Clarify: resolve ambiguity, but don't stall
+Gather the ambiguities that would actually change what you build. Ask the
+highest-leverage ones \u2014 batched, at most ~3, phrased as concrete choices. For
+low-stakes unknowns, pick a sensible default and SAY so ("assuming X unless you tell
+me otherwise") instead of asking. On a conversational/mobile client every round-trip
+is expensive \u2014 don't pester; decide what you safely can.
+
+## Step 4 \u2014 Plan: the HOW, grounded and simple
+Design against the real code. Apply the simplicity gates before committing:
+- **Fewest moving parts** that satisfy the criteria. If you add a layer or
+  abstraction, justify it or drop it.
+- **Use the framework/library directly** \u2014 don't wrap it for flexibility you don't
+  need yet.
+- **Minimal blast radius** \u2014 touch what the change needs, nothing more.
+State the test strategy (what proves each criterion) and name the real risks. Keep
+the plan short.
+
+## Step 5 \u2014 Tasks: small, verifiable, ordered
+Split the plan into tasks that each end in something you can run and check. Mark
+independent ones as parallelizable. Each task is the smallest unit worth its own
+check. Sequence by dependency.
+
+## Step 6 \u2014 Implement: test-first by default
+For each task: write the test that would fail without the change, watch it fail, make
+it pass, keep it green. Follow the patterns you found in Step 1. Commit in logical
+units. Escape hatch: for a genuine spike or exploratory UI where test-first is
+impractical, say so explicitly and add the test right after \u2014 never skip it silently.
+
+## Step 7 \u2014 Verify + self-review (what separates "done" from "looks done")
+Return to the acceptance criteria and prove EACH one is met \u2014 run the tests, diff the
+behavior, look at the real output. Then review your own work adversarially:
+- What did I NOT test?
+- What did I change that I didn't need to?
+- What could this have broken (the blast radius)?
+- Does anything contradict the spec?
+Fix what you find before declaring done. "The tests I wrote pass" is not "it works".
+
+## Step 8 \u2014 Done + handoff
+Done means acceptance criteria met, tests green, no known regressions. Summarize what
+changed in plain terms. File any deferred work or follow-ups to beads (\`bd\`) so
+nothing is lost. Never claim done on unverified work.
+
+## Principles (the constitution)
+- Clarify before you build; verify before you call it done.
+- Testable beats descriptive \u2014 a criterion you can't check isn't one.
+- Grounded beats greenfield \u2014 fit the codebase that exists.
+- Simple beats clever \u2014 the least structure that works.
+- Scale the process to the task \u2014 ceremony on a typo is a bug.
+- Real work goes to beads, not throwaway files in someone's repo.`;
+var SPEC_DRIVEN_INSTRUCTION = `Follow spec-driven development, scaled to the task:
+1. Right-size first. A trivial change (typo, one file, no unknowns) \u2192 just make it
+   well and verify, no ceremony. A feature/ambiguous/risky change \u2192 spec \u2192 plan \u2192
+   build \u2192 verify.
+2. Ground in the real codebase before planning \u2014 read the existing patterns, tests,
+   and constraints. Never assume; read first.
+3. Specify the WHAT and WHY as testable acceptance criteria, not the HOW. Mark
+   ambiguities instead of guessing.
+4. Clarify only the highest-leverage unknowns (batch <=3, concrete choices); default
+   the low-stakes ones and say so. Don't stall on round-trips.
+5. Plan the simplest approach that fits the code: fewest moving parts, use libraries
+   directly, minimal blast radius. State how each criterion will be tested.
+6. Implement test-first by default; follow existing patterns; commit in logical units.
+7. Verify EACH acceptance criterion (run tests, diff behavior), then self-review
+   adversarially: what's untested? what did I change needlessly? what could I have
+   broken? what contradicts the spec? Fix before declaring done.
+8. Track deferred work in beads (bd), not scratch files. Simple beats clever; verify
+   before done.`;
+var specDrivenDevelopmentSkill = {
+  id: "spec-driven-development",
+  name: "Spec-Driven Development",
+  description: `Spec-driven development scaled to the task: right-size, ground in the code, write testable acceptance criteria, plan simply, build test-first, and verify every criterion before done.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: SPEC_DRIVEN_BODY },
+    instruction: { body: SPEC_DRIVEN_INSTRUCTION }
+  }
+};
+
+// src/skills/registry.ts
+var SKILL_REGISTRY = {
+  "code-review": codeReviewSkill,
+  "resolve-conflicts": resolveConflictsSkill,
+  "spec-driven-development": specDrivenDevelopmentSkill
+};
 function isSkillId(id) {
   return Object.prototype.hasOwnProperty.call(SKILL_REGISTRY, id);
 }
@@ -1247,7 +1365,12 @@ var USER_EVENTS = {
   // VCS / PR Command Center — the backend publishes this after an agent finishes
   // reviewing a PR (verdict + comment count + findings), driving the mobile
   // completion screen + push. Mirrored in repo A's app-shared events.ts.
-  VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete"
+  VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete",
+  /** PR-review launch progress toast — the "Review with an agent" flow shows a
+   *  toast when the review runs server-side (Inngest). Mobile-only surface,
+   *  produced by api-v2 (the CLI neither produces nor consumes it). Mirrored in
+   *  repo A. */
+  PR_REVIEW_LAUNCH: "pr_review_launch"
 };
 
 // src/preview-prompts.ts