@turri-dev/cli 0.1.25-next.d0c7575 → 0.1.25-next.fb3566e

package/genome/skills/break-down-func-spec/SKILL.md

@@ -2,17 +2,17 @@
 name: break-down-func-spec
 description: >-
   Break down a functional spec that is too complex into smaller specs that
-  each imply ≤ 200 lines of code. Use when analyze-if-func-spec-too-complex
-  flags a spec as TOO COMPLEX, or when a spec is suspected of being too large.
-allowed-tools: [read, write, edit, bash, ls, grep, find]
+  each imply ≤ 200 lines of code. Use when a spec is judged too large against
+  the complexity limit (`func-specs.md`), before or after it is written in.
+allowed-tools: [read, write, edit, ls, grep, find]
 ---
 
 # Break Down Functional Spec
 
 ## When to Use
 
-- `analyze-if-func-spec-too-complex` flagged a spec as TOO COMPLEX.
-- A spec is suspected of exceeding the 200 LOC limit and needs to be split preemptively.
+- A spec is judged to exceed the 200 LOC limit (`func-specs.md`, *Complexity limit*) and needs to be split before it is written in.
+- A spec already written in turns out too large - its pulse could not get its unit tests to pass.
 - A spec bundles multiple behaviors, constructs, or concerns that should be separated.
 
 ## Input
@@ -23,7 +23,7 @@ The functional spec to break down, plus the full `.plain` file it belongs to.
 
 1. **Read the full `.plain` file** — definitions, implementation reqs, and all functional specs (including `requires` modules) to understand context.
 2. **Identify the spec to break down** — the one flagged as too complex or pointed to by the user.
-3. **Analyze why it is too complex** — use the indicators from `analyze-if-func-spec-too-complex`:
+3. **Analyze why it is too complex** — use the signs in `func-specs.md` (*Complexity limit*):
    - Multiple distinct behaviors bundled together?
    - Too many new constructs introduced at once?
    - Complex branching logic or conditional paths?
@@ -37,7 +37,7 @@ The functional spec to break down, plus the full `.plain` file it belongs to.
    - Within the 200 LOC limit
 5. **Draft the replacement specs** — write the smaller specs in chronological order. The first replacement spec typically sets up the foundation, and subsequent ones layer behavior on top.
 6. **Verify functional completeness** — this is critical. The replacement specs taken together must cover **100% of the functionality** described in the original spec. Walk through every behavior, condition, and detail in the original and confirm it appears in exactly one of the replacement specs. Nothing may be lost, weakened, or left implicit. If any functionality from the original is missing, add it to the appropriate replacement spec or create an additional one.
-7. **Verify each replacement spec** — run `analyze-if-func-spec-too-complex` on each to confirm it fits within the limit.
+7. **Verify each replacement spec** — judge each against the complexity limit, and split again any that is still too large.
 8. **Check for conflicts** — run `analyze-func-specs` **once** with the full set of replacement specs plus every existing spec in the file and its `requires` chain. The batched analyzer reports every conflicting pair (replacement × existing and replacement × replacement) in one call — do not loop over pairs. Resolve each reported pair with `resolve-spec-conflict`, then re-run `analyze-func-specs` over the touched set until the verdict is `COMPATIBLE`.
 9. **Replace in the file** — remove the original spec and insert the replacement specs in its position, preserving chronological order.
 10. **Read the file again** to confirm correct placement and syntax.
@@ -192,7 +192,7 @@ If the original spec had acceptance tests, redistribute them to the most appropr
 
 - [ ] Original spec has been removed from the file
 - [ ] Replacement specs together cover 100% of the original spec's functionality — nothing lost
-- [ ] Each replacement spec implies ≤ 200 LOC (verified via `analyze-if-func-spec-too-complex`)
+- [ ] Each replacement spec implies ≤ 200 LOC (judged against the complexity limit)
 - [ ] No conflicts between replacement specs and existing specs (verified via one batched `analyze-func-specs` call)
 - [ ] No conflicts between the replacement specs themselves (covered by the same batched call)
 - [ ] Replacement specs are in correct chronological order

package/genome/skills/consolidate-concepts/SKILL.md

@@ -5,7 +5,7 @@ description: >-
   shared import module in template/. Removes the moved definitions from the
   original modules and adds the new import to their frontmatter. Use when
   concepts are duplicated or spread across modules and should be centralized.
-allowed-tools: [read, write, edit, bash, ls, grep, find]
+allowed-tools: [read, write, edit, ls, grep, find]
 ---
 
 # Consolidate Concepts

package/genome/skills/resolve-section-ownership/SKILL.md

@@ -2,7 +2,7 @@
 name: resolve-section-ownership
 description: >-
   Route every fact in a .plain bullet, section, or file to the section that owns it — splitting a bullet that carries several kinds of fact, and moving a misplaced one to where the renderer will read it. Use when a bullet answers more than one of what it is / what it does / how it is built / how it is tested, when a requirement looks like it is in the wrong section, or when auditing a file for section ownership. Not for a spec that is merely too large (use break-down-func-spec) or for two specs that contradict each other (use resolve-spec-conflict).
-allowed-tools: [read, write, edit, bash, ls, grep, find]
+allowed-tools: [read, write, edit, ls, grep, find]
 ---
 
 # Resolve Section Ownership
@@ -19,7 +19,7 @@ This is the ownership counterpart to `break-down-func-spec`. That skill splits o
 
 ## When Not to Use
 
-- The spec is correctly placed but too large → `analyze-if-func-spec-too-complex`, then `break-down-func-spec`.
+- The spec is correctly placed but too large → `break-down-func-spec`.
 - Two specs contradict each other → `analyze-func-specs`, then `resolve-spec-conflict`.
 - The wording is merely verbose → trim per `concise-specs.md`; no fact changes section.
 

package/genome/skills/resolve-spec-conflict/SKILL.md

@@ -5,7 +5,7 @@ description: >-
   when conformance tests for a previously passing spec start failing after a new
   spec is rendered, or when a potential conflict is detected while adding a new
   functional spec (the conflict check of `func-specs.md`).
-allowed-tools: [read, write, edit, bash, ls, grep, find]
+allowed-tools: [read, write, edit, ls, grep, find]
 ---
 
 # Resolve Spec Conflict

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.25-next.d0c7575",
+  "version": "0.1.25-next.fb3566e",
   "license": "MIT",
   "type": "module",
   "repository": {

package/dist/mature-tools.d.ts

@@ -1,53 +0,0 @@
-import { type ToolDefinition } from "@earendil-works/pi-coding-agent";
-import { type Job, type JobRegistry } from "./regenerate/jobs.ts";
-/**
- * The tools a skill that matures a spec works with, besides the conversation's regenerate, drift and halt: wait for
- * the builds, and read back where the spec left the agents to decide.
- *
- * A render that passes can still have been built on a guess: where the spec is silent, the agent
- * decides, and says so in the working notes' assumptions. Those, the pitfalls, a failed job's
- * diagnosis and a spec that contradicts itself are what the spec should have said - and a skill
- * reading them can write it in, so the next build does not have to guess.
- */
-type AnyTool = ToolDefinition<any, any, any>;
-/** What a maturing skill found: where it came from, and what it says. */
-export interface SpecFinding {
-    id: string;
-    kind: "assumption" | "pitfall" | "diagnosis" | "conflict";
-    /** The module whose codebase it came from, or the job it came from. */
-    where: string;
-    text: string;
-}
-/** A time as the notes stamp their lines: "2026-09-28 17:40". */
-export declare function noteStamp(date: Date): string;
-/**
- * What the agents and the harness recorded since `since`: the assumptions and pitfalls in every
- * codebase's working notes, the diagnosis of every job that failed for good, and every spec that
- * contradicts itself.
- */
-export declare function collectFindings(options: {
-    project: string;
-    jobs: Job[];
-    since: Date;
-}): Omit<SpecFinding, "id">[];
-/** Why a build is struggling: a key for what kind of struggle it is - handed out once each - and what it says. */
-export interface Struggle {
-    key: string;
-    why: string;
-}
-/** How long a build may run before it counts as struggling on its length alone. */
-export declare const LONG_BUILD_MS: number;
-/**
- * Whether a running build is struggling, and how: sent back four times or more in one loop, five
- * setbacks or more, a spec conflict raised, a failure being run again, or running far longer than a
- * build should. Each kind comes once per build - a round count again only every four rounds more.
- */
-export declare function struggling(job: Job, now?: number): Struggle | undefined;
-export declare function createMatureTools(options: {
-    jobs: JobRegistry;
-    cwd: string;
-    startedAt?: Date;
-}): AnyTool[];
-/** The names of the maturing tools, as a skill's allowed-tools names them: its own - it regenerates, halts and reads drift with the conversation's (loop-tools.ts). */
-export declare const MATURE_TOOLS: string[];
-export {};

package/dist/mature-tools.js

@@ -1,193 +0,0 @@
-import { existsSync, readdirSync } from "node:fs";
-import { dirname, join, resolve } from "node:path";
-import { defineTool } from "@earendil-works/pi-coding-agent";
-import { Type } from "typebox";
-import { formatDuration } from "./regenerate/jobs.js";
-import { readNotes } from "./regenerate/notes.js";
-import { modulesRoot, projectDirOf } from "./regenerate/paths.js";
-/** A time as the notes stamp their lines: "2026-09-28 17:40". */
-export function noteStamp(date) {
-    const two = (n) => String(n).padStart(2, "0");
-    return `${date.getFullYear()}-${two(date.getMonth() + 1)}-${two(date.getDate())} ${two(date.getHours())}:${two(date.getMinutes())}`;
-}
-/** Every module codebase of a project that has working notes. */
-function codebasesOf(project) {
-    const root = modulesRoot(project);
-    if (!existsSync(root))
-        return [];
-    return readdirSync(root, { withFileTypes: true })
-        .filter((entry) => entry.isDirectory() && !entry.name.startsWith("."))
-        .map((entry) => ({ module: entry.name, buildDir: join(root, entry.name, "code") }))
-        .filter((codebase) => existsSync(codebase.buildDir));
-}
-/** A notes line's stamp, and what it says: "[2026-09-28 17:40 · app 3] text". */
-function stamped(line) {
-    const match = /^\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}) · ([^\]]*)\]\s*(.*)$/.exec(line);
-    return match === null ? undefined : { stamp: match[1], source: match[2], text: match[3] };
-}
-/**
- * What the agents and the harness recorded since `since`: the assumptions and pitfalls in every
- * codebase's working notes, the diagnosis of every job that failed for good, and every spec that
- * contradicts itself.
- */
-export function collectFindings(options) {
-    const since = noteStamp(options.since);
-    const found = [];
-    for (const { module, buildDir } of codebasesOf(options.project)) {
-        // The code's notes, and its conformance tests' beside them.
-        for (const notes of [readNotes(buildDir), readNotes(join(dirname(buildDir), "tests"))]) {
-            for (const [section, kind] of [["assumptions", "assumption"], ["pitfalls", "pitfall"]]) {
-                for (const line of notes[section]) {
-                    const item = stamped(line);
-                    if (item === undefined || item.stamp < since)
-                        continue;
-                    found.push({ kind, where: `${module} (${item.source})`, text: item.text });
-                }
-            }
-        }
-    }
-    for (const job of options.jobs) {
-        if (job.queuedAt < options.since.getTime())
-            continue;
-        if (job.specConflict !== undefined) {
-            const specs = job.specConflict.specs.map((spec) => `${spec.module} ${spec.frid}: ${spec.text.trim()}`).join("\n");
-            found.push({ kind: "conflict", where: `job ${job.id} (${job.summary})`, text: `${job.specConflict.reasons.at(-1) ?? ""}\n${specs}`.trim() });
-        }
-        if (job.diagnosis !== undefined)
-            found.push({ kind: "diagnosis", where: `job ${job.id} (${job.summary})`, text: job.diagnosis.trim() });
-    }
-    return found;
-}
-/** How a job stands, in a line: what it is, how it ended, and the first line of what it said. */
-function jobLine(job) {
-    const said = (job.status === "succeeded" ? job.report : job.error ?? job.report)?.trim().split("\n")[0] ?? "";
-    const flags = [job.diagnosis !== undefined ? "diagnosed" : "", job.specConflict !== undefined ? "spec conflict" : ""].filter(Boolean).join(", ");
-    return `- job ${job.id} · ${job.summary} · ${job.status}${job.status === "running" || job.status === "queued" ? "" : ` after ${formatDuration(job)}`}${flags ? ` · ${flags}` : ""}${said ? ` - ${said.slice(0, 200)}` : ""}`;
-}
-/** Setbacks a build reports as it goes: its stages that say a run failed, a review sent tests back, a judge found something wrong. */
-const SETBACK = /not passing|NOT passing|the review found|is wrong|found the|failed|a spec conflict|contradicts|stuck|cannot|still leave|trying it once more/;
-/** How long a build may run before it counts as struggling on its length alone. */
-export const LONG_BUILD_MS = 30 * 60_000;
-/**
- * Whether a running build is struggling, and how: sent back four times or more in one loop, five
- * setbacks or more, a spec conflict raised, a failure being run again, or running far longer than a
- * build should. Each kind comes once per build - a round count again only every four rounds more.
- */
-export function struggling(job, now = Date.now()) {
-    if (job.status !== "running")
-        return undefined;
-    const stages = job.transcript.filter((entry) => entry.kind === "stage").map((entry) => entry.text);
-    if (stages.some((stage) => /a spec conflict|contradicts itself/.test(stage)))
-        return { key: "conflict", why: "a spec conflict was raised: two functional specs that may not both hold" };
-    if (stages.some((stage) => /trying it once more/.test(stage)))
-        return { key: "retry", why: "it failed once and is being run again" };
-    const round = /round (\d+) of (\d+)/.exec(job.stage ?? "");
-    if (round !== null && Number(round[1]) >= 4) {
-        const bucket = Math.floor((Number(round[1]) - 4) / 4);
-        return { key: `rounds-${bucket}`, why: `sent back ${round[1]} times of at most ${round[2]}: ${job.stage}` };
-    }
-    const setbacks = stages.filter((stage) => SETBACK.test(stage));
-    if (setbacks.length >= 5)
-        return { key: `setbacks-${Math.floor(setbacks.length / 5)}`, why: `${setbacks.length} setbacks so far - the last: ${setbacks.at(-1)}` };
-    if (now - job.startedAt > LONG_BUILD_MS)
-        return { key: `long-${Math.floor((now - job.startedAt) / LONG_BUILD_MS)}`, why: `running for ${formatDuration(job)}` };
-    return undefined;
-}
-/** A struggling build, for the skill to judge: why, its last stages, and the end of what it printed. */
-function describeStruggle(job, struggle) {
-    const stages = job.transcript.filter((entry) => entry.kind === "stage").map((entry) => entry.text).slice(-12);
-    return [
-        `job ${job.id} · ${job.summary} · ${struggle.why}`,
-        job.diff !== undefined ? `<its change>\n${job.diff.trim().slice(0, 3000)}\n</its change>` : "",
-        `<its last stages>\n${stages.map((stage) => `- ${stage}`).join("\n")}\n</its last stages>`,
-        job.tail.trim() !== "" ? `<the end of its output>\n${job.tail.trim().slice(-2500)}\n</the end of its output>` : "",
-    ]
-        .filter((part) => part !== "")
-        .join("\n");
-}
-export function createMatureTools(options) {
-    const startedAt = options.startedAt ?? new Date();
-    const mine = () => options.jobs.list().filter((job) => job.queuedAt >= startedAt.getTime());
-    /** Findings already handed out, by what they say: each is reported once. */
-    const reported = new Set();
-    let counter = 0;
-    /** The struggles already handed out, by job and what they were - each reported once, again only when it gets longer. */
-    const flagged = new Set();
-    const watchJobs = defineTool({
-        name: "watch_jobs",
-        label: "Watch the builds",
-        description: "Watch the builds queued since this run started, and come back as soon as one is struggling - sent back again and " +
-            "again, setback after setback, a spec conflict raised, a failure being run again, running far too long - or when " +
-            "every one has finished, or when `minutes` have passed. For a struggling build it gives what it has been through: its " +
-            "last stages and the end of its output. Says how every build stands.",
-        promptSnippet: "watch the builds, and come back when one struggles or all are done",
-        parameters: Type.Object({
-            minutes: Type.Optional(Type.Number({ description: "The longest to watch, in minutes. Default 20" })),
-        }),
-        async execute(_id, params, signal) {
-            const limit = Math.max(1, Math.min(120, params.minutes ?? 20)) * 60_000;
-            const deadline = Date.now() + limit;
-            const pending = () => mine().filter((job) => job.status === "running" || job.status === "queued");
-            const newStruggles = () => mine()
-                .map((job) => ({ job, struggle: struggling(job) }))
-                .filter((item) => item.struggle !== undefined && !flagged.has(`${item.job.id}|${item.struggle.key}`));
-            let found = newStruggles();
-            while (found.length === 0 && pending().length > 0 && Date.now() < deadline && signal?.aborted !== true) {
-                await new Promise((resolve) => setTimeout(resolve, 2000));
-                found = newStruggles();
-            }
-            for (const item of found)
-                flagged.add(`${item.job.id}|${item.struggle.key}`);
-            const all = mine().sort((a, b) => a.sequence - b.sequence);
-            const left = pending();
-            const text = [
-                found.length > 0
-                    ? `${found.length} build${found.length === 1 ? " is" : "s are"} struggling:`
-                    : left.length === 0
-                        ? `Every build queued since this run started has finished (${all.length}).`
-                        : `No build is struggling; ${left.length} of ${all.length} are still running or queued - call watch_jobs again.`,
-                ...found.flatMap(({ job, struggle }) => ["", describeStruggle(job, struggle)]),
-                "",
-                "Every build:",
-                ...all.map(jobLine),
-                "",
-                "Read what the builds had to decide themselves with spec_findings; see how far the spec is regenerated with drift.",
-            ].join("\n");
-            return { content: [{ type: "text", text }], details: { pending: left.length, struggling: found.map((item) => item.job.id) } };
-        },
-    });
-    const specFindings = defineTool({
-        name: "spec_findings",
-        label: "What the spec left open",
-        description: "What the builds since this run started recorded where the spec left them to decide or went wrong: every " +
-            "assumption and pitfall in the codebases' working notes, the diagnosis of every job that failed for good, and every " +
-            "spec that contradicts itself - each numbered, and each given once: a finding already handed out is not repeated.",
-        promptSnippet: "where the builds had to guess, or failed on the spec",
-        parameters: Type.Object({
-            plain_file: Type.Optional(Type.String({ description: "A .plain file of the project to read; default the session's folder" })),
-            all: Type.Optional(Type.Boolean({ description: "Every finding since the run started, not only the new ones" })),
-        }),
-        async execute(_id, params) {
-            // The project a spec is built in; with none named, the one the session's folder is.
-            const project = projectDirOf(params.plain_file !== undefined ? resolve(options.cwd, params.plain_file) : join(options.cwd, "session.plain"));
-            const found = collectFindings({ project, jobs: mine(), since: startedAt });
-            const fresh = found.filter((finding) => params.all === true || !reported.has(`${finding.kind}|${finding.where}|${finding.text}`));
-            const numbered = fresh.map((finding) => {
-                reported.add(`${finding.kind}|${finding.where}|${finding.text}`);
-                counter += 1;
-                return { ...finding, id: `f${counter}` };
-            });
-            const text = numbered.length === 0
-                ? "No new findings: the builds since the last look recorded no assumption, no pitfall, no diagnosis and no spec conflict."
-                : [
-                    `${numbered.length} finding${numbered.length === 1 ? "" : "s"}:`,
-                    "",
-                    ...numbered.map((finding) => `${finding.id} · ${finding.kind} · ${finding.where}\n${finding.text}`),
-                ].join("\n\n");
-            return { content: [{ type: "text", text }], details: { findings: numbered } };
-        },
-    });
-    return [watchJobs, specFindings];
-}
-/** The names of the maturing tools, as a skill's allowed-tools names them: its own - it regenerates, halts and reads drift with the conversation's (loop-tools.ts). */
-export const MATURE_TOOLS = ["watch_jobs", "spec_findings"];

package/genome/skills/analyze-if-func-spec-too-complex/SKILL.md

@@ -1,206 +0,0 @@
----
-name: analyze-if-func-spec-too-complex
-description: >-
-  Analyze a functional spec to determine if it is too complex for the renderer.
-  A spec is too complex if it would produce more than 200 lines of code changes.
-  Use after drafting a new functional spec (per `func-specs.md`, *Adding a
-  functional spec*) to verify it fits within the complexity limit before
-  inserting it.
-allowed-tools: [read, ls, grep, find]
----
-
-# Analyze If Functional Spec Is Too Complex
-
-## Why This Matters
-
-The renderer enforces a hard complexity limit: each functional spec must imply a **maximum of 200 changed lines of code**. If a spec exceeds this, the renderer rejects it with "Functional spec too complex!" and the spec must be broken down. Catching this before insertion saves a failed render cycle.
-
-## Input
-
-A drafted functional spec (not yet inserted into the file), plus the full context of the `.plain` file it will be added to — definitions, implementation reqs, and existing functional specs.
-
-## Workflow
-
-1. **Read the full `.plain` file** (and any `requires`/`import` modules) to understand the current codebase context — what already exists and what the new spec builds on.
-2. **Read the drafted functional spec** carefully.
-3. **Run the complexity analysis** using the checklist below.
-4. **Output the verdict and nothing else** — either `ACCEPTABLE` or `TOO COMPLEX`. No reasoning, no LOC estimate, no breakdown.
-
-## Complexity Analysis Checklist
-
-Work through each indicator. A single "yes" does not automatically mean the spec is too complex, but multiple "yes" answers are a strong signal.
-
-### 0. First-Spec Bootstrap Cost
-
-Is this the first functional spec in a new root module with no implementation baseline supplied by `requires`? If so, include the implicit cost of creating the project structure, package metadata, framework configuration, entry point, initial source files, and unit-test infrastructure.
-
-The first spec must be substantially simpler than a later spec. It should expose one minimal, deterministic capability that can be invoked and tested. Setup without an observable result is not acceptable, but combining bootstrap work with persistence, integrations, multiple interfaces, branching workflows, or cross-cutting behavior is a strong `TOO COMPLEX` signal.
-
-### 1. Number of Distinct Behaviors
-
-Does the spec describe more than one independently testable behavior?
-
-Too complex:
-```plain
-***functional specs***
-
-- A :User: can create, edit, delete, and archive :Task: items, with validation on all fields and confirmation dialogs for destructive actions.
-```
-
-Acceptable (one behavior each):
-```plain
-***functional specs***
-
-- A :User: can create :Task:. Only valid :Task: items can be added.
-
-- A :User: can edit :Task:.
-
-- A :User: can delete :Task:.
-
-- A :User: can archive :Task:.
-
-```
-
-### 2. Number of Concepts Introduced or Modified
-
-Does the spec require introducing new data structures, UI components, API endpoints, or other constructs that don't already exist? Count them.
-
-- 0–1 new constructs → likely fine
-- 2–3 new constructs → borderline, examine closely
-- 4+ new constructs → almost certainly too complex
-
-### 3. Branching Logic and Conditions
-
-Does the spec describe multiple conditional paths, modes, or special cases?
-
-
-Too complex:
-```plain
-***functional specs***
-
-- :Order: processing depends on :OrderType:. Standard orders are validated and stored. Express orders skip validation and are queued for immediate dispatch. Bulk orders are split into sub-orders of 100 items each, validated individually, and processed in parallel with progress tracking.
-```
-
-Acceptable (separate the modes):
-```plain
-***functional specs***
-
-- A standard :Order: is validated and stored.
-
-- An express :Order: is queued for immediate dispatch without validation.
-
-- A bulk :Order: is split into sub-orders of 100 items each.
-  - Each sub-order is processed individually.
-```
-
-### 4. Cross-Cutting Concerns
-
-Does the spec bundle core functionality with cross-cutting concerns like error handling, logging, retry logic, pagination, or caching?
-
-Too complex:
-```plain
-***functional specs***
-
-- :Resource: items are fetched from the external API with pagination support, retry on transient errors with exponential backoff, caching for 5 minutes, and logging of all API calls.
-```
-
-Acceptable (separate concerns):
-```plain
-***functional specs***
-- :Resource: items are fetched from the external API.
-
-- :Resource: items are fetched from the external API in pages.
-
-- Fetching :Resource: items is retried on transient errors using exponential backoff.
-```
-
-### 5. UI Complexity
-
-Does the spec describe a complete screen or page with multiple interactive elements, layouts, and state transitions?
-
-Too complex:
-```plain
-***functional specs***
-
-- The dashboard shows :User: profile, recent :Task: items in a sortable table, a notification bell with unread count, and a sidebar with navigation links that highlights the active page.
-```
-
-Acceptable (build incrementally):
-```plain
-***functional specs***
-
-- A dashboard page is shown for :User:.
-
-- Recent :Task: items are shown in a sortable table on the dashboard.
-
-- A notification indicator with the unread count is shown on the dashboard.
-```
-
-### 6. Data Transformation Complexity
-
-Does the spec involve complex data mapping, aggregation, or transformation across multiple entities?
-
-- Simple field mapping or filtering → likely fine
-- Multi-step transformations, joins across entities, or aggregations → likely too complex
-
-### 7. Implied Technical Component
-
-Does the spec imply building a substantial technical component — an engine, parser, scheduler, layout algorithm, state machine, or sync mechanism — **in addition to** the behavior it describes? A component is not a free primitive: code must be generated for it too, so it counts toward the 200-LOC budget and must be evaluated as part of the estimate. A spec that needs a component **and** wires up behavior on top of it is really two bodies of code in one spec — a strong "too complex" signal. Count the component's implementation, not just the glue that calls it.
-
-Too complex (builds the component and uses it in one spec):
-```plain
-***functional specs***
-
-- A :Report: is exported to PDF, laying out multi-page tables with repeating headers and page numbers, and charts rendered from :Report: data.
-```
-
-Acceptable (component in its own spec, then referenced):
-```plain
-***functional specs***
-
-- :PdfRenderer: lays out multi-page tables from structured content.
-  - Table headers repeat at the top of each page.
-  - Each page shows its page number.
-
-- A :Report: is exported to PDF using :PdfRenderer:, embedding charts rendered from :Report: data.
-```
-
-When this indicator fires, the fix is `break-down-func-spec` Strategy 6 — extract the component into its own earlier spec and reference it.
-
-### 8. Rough LOC Estimation
-
-Mentally estimate the implementation. Consider:
-- New files that need to be created
-- New functions/methods
-- Code for any implied technical component (engine, parser, algorithm), not just the glue that uses it
-- Data model changes (schema, migrations, types)
-- UI components (if applicable)
-- Test setup and assertions (unit tests are auto-generated alongside)
-- For the first spec in a new root module, all project and test scaffold implied by implementation requirements
-- Error handling paths
-- Import statements and boilerplate
-
-If the estimate exceeds ~150 LOC, the spec is at high risk of being too complex (leave headroom for the renderer to add necessary boilerplate).
-
-## Output Format
-
-The skill emits exactly one of these two strings, with no surrounding text, explanation, estimate, or breakdown:
-
-```
-ACCEPTABLE
-```
-
-or
-
-```
-TOO COMPLEX
-```
-
-The internal analysis (checklist, LOC estimation, reasoning) informs the verdict but must not appear in the output. The caller decides what to do with the result.
-
-## Where it is called
-
-This skill is step 2 of adding a functional spec (`func-specs.md`, *Adding a functional spec*) - for each spec of a batch, in order - after drafting a spec but **before** inserting it into the file. The caller acts on the one-word verdict:
-
-- **ACCEPTABLE** — proceed to insert the spec.
-- **TOO COMPLEX** — invoke `break-down-func-spec` to produce smaller specs, then insert each one individually (running conflict checks on each).