mandrel 2.58.0 → 2.60.0

package/.agents/scripts/lib/templates/spec-author-prompts.js

@@ -1,76 +0,0 @@
-/**
- * spec-author-prompts.js — Story-scoped Spec / Acceptance authoring prompts.
- *
- * v2 keeps a single executable document per Story. These prompts used to
- * author a separate Epic Tech Spec + Acceptance Spec that were folded into
- * the Epic body and then restated on Stories — a duplication source. They
- * now author only Story `## Spec` approach prose and remind authors that
- * acceptance lives once on the Story (`acceptance[]` / `## Acceptance`).
- */
-
-/**
- * @returns {string}
- */
-export function renderTechSpecSystemPrompt() {
-  return TECH_SPEC_SYSTEM_PROMPT;
-}
-
-/**
- * @returns {string}
- */
-export function renderAcceptanceSpecSystemPrompt() {
-  return ACCEPTANCE_SPEC_SYSTEM_PROMPT;
-}
-
-const TECH_SPEC_SYSTEM_PROMPT = `You are an expert Engineering Architect.
-Your job is to author the Story's \`## Spec\` approach section — the technical
-how for one cohesive, executable Story. There is no separate Epic Tech Spec
-document and no spill-to-docs path.
-
-The Spec should outline only what an implementing agent needs beyond Goal /
-Changes / Acceptance:
-1. Architecture & Design (approach, seams, reuse)
-2. Data Models (if any)
-3. API Changes (if any)
-4. Core Components
-5. Security & Privacy Considerations
-
-CRITICAL REQUIREMENTS:
-- Respond ONLY with valid Markdown suitable to paste into a Story \`## Spec\`.
-- Do not use top-level <h1> (# ) tags. Prefer \`##\` / \`###\` under Spec.
-- Do NOT restate the Story's Goal, Acceptance, Verify, Changes, or Non-Goals —
-  those sections already live on the same Story body. Restatement is
-  duplication and a drift risk. If a brief orientation helps, keep a
-  \`## Technical Overview\` to 2–3 sentences naming the technical approach only.
-- Do NOT author a Delivery Slicing / fan-out table. If the work needs multiple
-  independent Stories, say so in one short note and stop — oversized Specs
-  mean the Story should be split, not documented elsewhere.
-- Format architectural decisions clearly with bullet points.
-- Keep the Spec lean enough to stay inline on the Story (persist rejects
-  over-budget Specs; they are never written under docs/).`;
-
-const ACCEPTANCE_SPEC_SYSTEM_PROMPT = `You are an expert Acceptance Engineer.
-Your job is to help author the Story's binding acceptance contract — not a
-separate Acceptance Spec document.
-
-v2 rule: acceptance lives **once**, on the Story:
-- Machine contract: top-level \`acceptance[]\` (and \`verify[]\`) on the ticket JSON
-- Human document: the same items rendered under \`## Acceptance\` / \`## Verify\`
-  on the Story body (persist syncs top-level into the body)
-
-Do **not** author an Epic Acceptance Table, PRD restatement, or a second
-criteria list inside \`## Spec\`.
-
-CRITICAL REQUIREMENTS:
-- Respond ONLY with guidance or a draft \`acceptance[]\` / \`verify[]\` list for
-  one Story — never a parallel "Acceptance Spec" markdown artifact.
-- Every acceptance item MUST be observable from outside the agent (command
-  exits 0, file exists, selector resolves, fixture count matches). Reject
-  vague "matches the spec" / "looks good" items.
-- Every verify entry MUST name a tier in parentheses: unit | contract | e2e |
-  validate (or \`manual:<reason>\` when genuinely unverifiable in isolation).
-- Do NOT re-elaborate Goal or Spec prose inside acceptance items — bind the
-  outcome, not the approach.
-- Acceptance Outcomes MUST NOT prescribe a commit subject that begins with a
-  non-Conventional-Commits prefix (allowed leading types: feat|fix|chore|
-  refactor|perf|docs|style|test|build|ci|revert).`;

package/.agents/skills/core/scope-triage/SKILL.md

@@ -1,48 +0,0 @@
----
-name: scope-triage
-description:
-  Optional split-advisory for `/mandrel-plan`. Under v2 there is no epic|story routing
-  verdict — `/mandrel-plan` always authors Stories. Use this skill only when judging
-  whether a draft should stay one Story or legitimately split (near-zero
-  overlap or an architectural seam).
----
-
-# scope-triage (split advisory)
-
-## Policy Capsule
-
-- There is **no** `epic | story | borderline` routing verdict in v2. `/mandrel-plan`
-  is a single path that emits **one Story by default**.
-- This skill is an optional **split advisory**: should the author keep one
-  Story, or does the seed clear the default-single split policy?
-- Anchor sizing judgment to `DELIVERABLE_GRANULARITY_GUIDANCE` in
-  [`ticket-validator-sizing.js`](../../../scripts/lib/orchestration/ticket-validator-sizing.js).
-  There is no numeric threshold to restate — Story #5312 deleted the
-  plan-time capacity ceilings.
-- Lead with **cohesion**: one Story is one coherent change with one reason
-  to exist. Coupled work stays one Story and uses `## Slicing` for
-  intra-session checkpoints.
-- Emit an **advisory only** — `keep-single` (the default) or `split` with its
-  seam/overlap rationale. **Never auto-route**: the operator decides, and
-  `--yes` defaults to `keep-single`.
-
-## Split policy (when N>1 is allowed)
-
-Split into sibling Stories **only** when:
-
-1. **Near-zero overlap** — genuinely independent capabilities that happen to
-   share a seed idea, or
-2. **Architectural seam** — different deployables, or a migration vs the
-   feature that consumes it.
-
-Otherwise keep one Story. Persist refuses coupled splits via
-`assertAcceptancePartition` (identical AC text across Stories).
-
-## Advisory output
-
-Emit one of:
-
-- `keep-single` — default; fold complexity into `## Spec` / `## Slicing`
-- `split` — list the proposed Stories and the seam/overlap rationale
-
-Never auto-route. The operator (or `--yes` default = `keep-single`) decides.