agentic-sdd-framework 1.4.0

package/.agents/skills/auditor-executor-protocol/references/autonomous-mode.md

@@ -0,0 +1,144 @@
+# Autonomous Mode
+
+Part of the `auditor-executor-protocol` skill. Load when the run is in Autonomous mode or you are writing the Auditor brief. Section names in
+quotes ("Rules of engagement", "Auditing", ...) refer to `SKILL.md` unless they are in
+this file.
+
+## Autonomous mode (Auditor)
+
+The Auditor runs the whole run: launches Executors, audits each delivery by re-running
+it, gives verdicts, answers questions, expands later phases when the previous gate is
+`APPROVED`, and writes annexes and remediations. The owner does not relay messages.
+
+### The autonomy charter
+
+Write it into the execution guide (a "Coordination and autonomy" section) and point to
+it from a governance decision in the plan of record. It has four parts:
+
+1. **What the Auditor decides alone.** Anything the documents leave open. `BLOCKED`
+   entries are answered with a **decision entry** in the log — question, evidence (pasted
+   command), decision, reason — or with an annex, and the task resumes. The Auditor may
+   amend a decided item by annex when evidence justifies it.
+2. **What the Auditor may never change.** The acceptance criteria and the stated scope.
+   Splitting work into more phases is allowed; shrinking the goal is not. A plan that
+   covers less than the owner asked for is a scope change, and only the owner makes those.
+3. **The critical-risk list** — the only reasons to interrupt the owner. Write it per
+   project, concretely, and number it. The categories that almost always belong:
+   - reducing or reinterpreting the acceptance criteria;
+   - irreversible loss of production data (a destructive step without a verified,
+     restorable backup, or a failed production migration that left data inconsistent);
+   - someone losing access to production, or a message sent to anyone but the owner;
+   - real money (charging, refunding, cancelling a real customer; billing changes the
+     tests cannot prove equivalent);
+   - production down or degraded after a deploy, not restored by the pipeline's rollback;
+   - a secret exposed or needing rotation (the Auditor never handles secret values);
+   - actions the project's own rules reserve for the owner (typical: force-push,
+     disabling CI or checks, hand-edited server config outside version control, copy
+     shown to every user such as release notes);
+   - a harness block the Auditor cannot resolve within its authority.
+
+   Everything not on the list is decided, recorded and the run continues. "Should I
+   continue?" is never on the list.
+4. **How the owner hears about progress.** One short report per closed phase, no
+   questions unless they are on the list:
+
+   ```
+   <PHASE> — <APPROVED | CONDITIONAL>. Shipped: <version/commit, or "nothing">. Decisions
+   made: <decision-entry IDs, or "none">. Next: <phase/task already launched>.
+   ```
+
+   Harness permission prompts that need the owner go in **one batched request**, not one
+   at a time. When every phase is `APPROVED` and the plan of record declares no further
+   phase, say so as its own line — see "Closing the run" in `SKILL.md`.
+
+### Executor model assignment
+
+Pick the Executor's model per task, in a table in the execution guide, and name it in
+each handoff. The shape that has worked here:
+
+| Tier | Use for |
+|---|---|
+| Small/fast tier | Mechanical, fully specified, low blast radius: run listed commands, bump/gate/commit/push, small isolated files |
+| Mid tier | Anything with judgement or risk: security, migrations, production data, transports, moving code, cross-file wiring, UI, user-facing copy |
+| Top tier, usually the Auditor's own | Not used for Executors unless the owner says otherwise. If unsure, the mid tier |
+
+- **Pass the model explicitly on every launch.** A subagent launched without an explicit
+  model parameter **inherits the Auditor's model**, which silently breaks the rule.
+  Require the same of any subagent the Executor spawns, in the handoff text.
+- **Escalation goes one tier up, from the start.** A small-model task that hits anything
+  outside its script (failing gate, unexpected diff, a `BLOCKED` condition) stops and
+  logs what it saw; the Auditor relaunches the whole task on the mid tier. Never a retry
+  on the top tier. A small-model Executor that "solved" the surprise itself is a process
+  finding, even if the fix is right.
+- Every task added when later phases are expanded gets a row in the table before it is
+  launched.
+- A model-rule violation is a **process finding** in the verdict, recorded separately
+  from the code findings.
+- **A recurring sandbox/permission block goes in the reserved-to-Auditor steps list**
+  (see "The document set" in `SKILL.md`) the first time it turns out predictable, not in a
+  per-task Observations note nobody reads again.
+
+### The per-task cycle
+
+1. Fetch and check the remote hasn't moved; read the task's log section.
+2. Launch the Executor subagent with the model from the table and the full handoff
+   template as the prompt, not a pointer to the guide.
+3. When it returns: re-run every Verify and negative control yourself ("Auditing" in `SKILL.md`).
+4. Write the verdict in the log, process findings separate from code findings.
+5. Not clean: write the remediation and relaunch. Clean: launch the next task in the same
+   turn. Gate `APPROVED`: send the owner the phase report and, if the next phase is not
+   yet expanded, expand it (tasks, gate, model per task, log sections) before launching
+   its first task.
+
+Do not end a turn between a verdict and the next launch unless something on the
+critical-risk list is open. A run that stops to report a `PASS` and wait is Guided
+mode by accident.
+
+### Starting the Auditor (the Auditor brief)
+
+An autonomous run is started by giving a fresh Auditor session a brief, the same way an
+Executor gets a handoff. The owner (or whoever planned the run) writes it once. Fill
+every section; the Auditor starts cold too.
+
+```
+ROLE: Auditor of plan "<name>" in <repo>. Model: <model>. You do not write feature code.
+You run the whole thing autonomously: launch Executors as subagents, audit each delivery
+by re-running it, give the verdicts, resolve their questions, expand <pending phases>
+once the previous gate is APPROVED, and write annexes and remediations. Follow the
+auditor-executor-protocol skill to the letter.
+
+AUTONOMY (<governance decision>, "<charter>" section of the guide):
+- What you decide alone; what you can never amend (<acceptance criteria>, scope).
+- Executors are your subagents; the owner does not paste handoffs.
+- BLOCKED → decision entry or annex; the task continues.
+- Harness permissions needing the owner: one batched request.
+- Short report per closed phase, no questions except the list.
+- ONLY reasons to interrupt the owner: <numbered critical-risk list>.
+
+EXECUTOR MODEL ASSIGNMENT: <per-task table, escalation rule, model always explicit,
+using the forbidden tier = process finding>.
+
+DOCUMENTS: <plan of record, guide, log — what each contains and who writes where>.
+
+STATE: <local/pushed commits, clean tree or not, first task and its model>.
+
+GOAL (non-negotiable): <the owner's objective, in their own words>. Splitting into
+phases, yes; shrinking it, no. RUN COMPLETE only with <final gate> APPROVED.
+
+WHAT'S VERIFIED AND WHAT ISN'T: <facts with their evidence command / open questions some
+task must measure — never mixed together>.
+
+TRAPS TO WATCH FOR WHILE AUDITING: <the concrete shortcuts an Executor on this run would
+take by reflex>.
+
+YOUR PER-TASK CYCLE: <the 5 steps of "The per-task cycle">.
+
+REPO RULES THAT APPLY TO EVERYONE: <citations by section, not copied in>.
+
+FIRST STEP: <read the documents, confirm the log's state, launch <task> with <model>>.
+```
+
+`WHAT'S VERIFIED AND WHAT ISN'T` and `TRAPS` do for the Auditor what `Key finding` and
+`Failure to avoid` do for the Executor: they carry the planning session's knowledge
+across the cold start. A filled-in, fictional brief is in `references/failure-modes-and-example.md`; it shows
+the shape, not a default to paste.

package/.agents/skills/auditor-executor-protocol/references/failure-modes-and-example.md

@@ -0,0 +1,103 @@
+# Failure Modes and Worked Example
+
+Part of the `auditor-executor-protocol` skill. Load when auditing a delivery or looking for a filled-in run. Section names in
+quotes ("Rules of engagement", "Auditing", ...) refer to `SKILL.md` unless they are in
+this file.
+
+## Failure modes seen in practice
+
+- **Self-expansion.** The Executor implements phases marked "do not start." Work
+  arrives with no checkpoints between phases; a defect in an early one gets built on
+  before anyone looks.
+- **Zero stops.** An empty "Blocked" section across dozens of tasks means ambiguities
+  were resolved silently, not that none existed.
+- **Letter over intent.** The task says "add a check for case X"; a check appears, it
+  passes, and the condition X exists to detect is routed around by fixture ordering or
+  test isolation. Anticipate this by naming the expected failure in the task itself.
+- **Evidence-free `DONE`.** Treat as `FAILED`. Say so in the reporting rules up front.
+- **The Auditor shrinks the goal.** Asked for a whole outcome, the plan delivers a
+  slice of it and calls the rest "follow-up," backed by a risk/ROI argument. Shrinking
+  the goal is never authorized; splitting it into phases is fine, as long as the goal
+  is met. Big goals get more phases, never a smaller goal — later phases are part of
+  the run, not a follow-up.
+- **Silent model inheritance.** A subagent launched without an explicit model runs on
+  the Auditor's own model. Nothing fails; the rule is just broken on every task. Pass
+  it every time.
+- **Guided by habit.** In Autonomous mode, the Auditor ends a turn after a `PASS` to
+  "report," or asks the owner a question the charter already lets it decide. Each one
+  costs the owner a message and adds nothing.
+- **A defect ships and nobody owns re-checking its blast radius.** A task changes what
+  an existing field means; every other reader of that field is now a latent bug, and
+  the person who finds it is usually a different, unrelated task that happens to hit
+  it — not a re-audit of the original task. Grep for every reader before signing off,
+  not after something breaks.
+- **A change primes something to fire on its own before anyone can see or stop it.** A
+  migration or config change that alters what triggers an automated write can leave
+  the system armed to act — at scale, on real data — the moment its ordinary trigger
+  next runs, with no one having pressed a button and no UI yet built to see or cancel
+  it. Check the state the change leaves behind, not only the correctness of the new
+  code path.
+
+## Worked example
+
+Everything below is fictional and sanitized. It shows the shape of each artifact, not
+content to copy. Names, commands and risks in a real run come from that project.
+
+**Plan:** "Notifications as a standalone service" in a web shop. Goal set by the owner:
+every notification leaves the monolith. Acceptance criteria AC1-AC4. Phases P0-P5, with
+P0-P2 expanded into tasks and P3-P5 fixed in scope, expanded by the Auditor at each gate.
+Mode: Autonomous (governance decision D9 in the plan of record).
+
+**Rules-of-engagement block (item 8)**, as it would appear in each handoff:
+
+```
+- One task at a time.
+- Verification = run the command and the negative controls, not read the code.
+- Fetch and compare against the remote branch before starting and before pushing.
+- <project's quality-gate command> exits 0 before any push.
+- Every commit to the main branch bumps the version with <project's version script>.
+- No AI tool co-authorship on commits.
+```
+
+**Auditor brief (abridged):**
+
+```
+ROLE: Auditor of plan "Notifications as a standalone service". You do not write feature
+code. You run this in Autonomous mode: launch Executors as subagents, audit each
+delivery by re-running it, resolve their questions, expand P3-P5 once the previous gate
+is APPROVED. Follow the auditor-executor-protocol skill.
+
+AUTONOMY (D9; "Coordination and autonomy" section of the guide):
+- You decide anything the documents leave open; amend decisions by annex with evidence.
+  You never amend AC1-AC4 or reduce scope.
+- BLOCKED → decision entry in the log; the task continues.
+- Permissions needing the owner: one batched request. Short report per closed phase.
+- ONLY reasons to interrupt the owner:
+  1. Reducing or reinterpreting AC1-AC4.
+  2. Deleting production data without a verified, restorable backup.
+  3. A real email or SMS sent to a customer.
+  4. Charges, refunds, or billing changes not proven equivalent.
+  5. Production down after a deploy with no successful rollback.
+  6. An exposed secret.
+  7. Force-push or disabling CI.
+
+EXECUTOR MODEL ASSIGNMENT: small/fast tier for P0-T1, P1-T3, P2-T4 (listed commands,
+bump, gate, push). Mid tier for the rest. Top tier never. Model explicit on every
+launch; if a small-tier task goes off-script, relaunch the whole task on the mid tier.
+
+STATE: clean tree, plan committed and pushed. First task: P0-T1 on the small/fast tier.
+
+GOAL (non-negotiable): no notification leaves the monolith. RUN COMPLETE only with
+P5-G1 APPROVED, which proves AC1-AC4.
+
+WHAT'S VERIFIED AND WHAT ISN'T:
+- Verified (command in the plan): all 14 send sites in the inventory.
+- Not verified: whether the SMS provider accepts idempotency keys (P2-T2 measures it).
+
+TRAPS: "doesn't send" checks that pass because the mock was never registered; negative
+controls restored with a command that wipes other uncommitted work; a small-tier task
+that patches an unexpected surprise itself instead of escalating.
+
+FIRST STEP: read the three documents, confirm the log is empty, launch P0-T1 on the
+small/fast tier.
+```

package/.agents/skills/auditor-executor-protocol/references/handoffs.md

@@ -0,0 +1,133 @@
+# Handoffs
+
+Part of the `auditor-executor-protocol` skill. Load when handing a task to an Executor or writing a remediation order. Section names in
+quotes ("Rules of engagement", "Auditing", ...) refer to `SKILL.md` unless they are in
+this file.
+
+## Handing off a task (Auditor)
+
+Writing the execution guide is not the handoff. The Executor's session starts cold — it
+has none of the investigation behind the guide, and "read the execution guide, task
+`<ID>`" is a pointer to an instruction, not the instruction itself. Producing the actual,
+paste-ready message for a fresh Executor session is Auditor work, not something left for
+whoever is relaying the plan to assemble by hand.
+
+**The rules-of-engagement block in the template below is item 8, settled when the run
+started** ("Rules of engagement" in `SKILL.md`) — not re-derived here, and not re-asked per
+task. If you're about to write a handoff and item 8 is still blank, that's the actual
+problem: go settle it before drafting the message, don't paste a rule set from a
+different project or a different run to fill the gap. A rule copied in from elsewhere
+either asserts something false about this codebase or hands the Executor a stop it has
+no way to satisfy.
+
+### Handoff template
+
+One task per message, addressed to a fresh Executor session with no shared context. Fill
+every section — do not leave "see the execution guide" where a fact belongs.
+
+```
+ROLE: Executor. Work from <EXECUTION_GUIDE> (Phase <n>, `<TASK-ID>`) only; report in
+<COMPLIANCE_LOG>, section `<TASK-ID>` (already exists, empty).
+
+[Autonomous mode only:] You are the Auditor's subagent. Questions go as BLOCKED in the
+log and in your final report; you do not address the owner.
+
+REPORTED STATE: <what is already DONE in the log, and whether it was audited or only
+self-reported — do not conflate the two>. Do not reopen <prior tasks>.
+
+TASK: <TASK-ID> — <imperative title>
+Source: <EXECUTION_GUIDE>, section "<TASK-ID>" in full.
+
+Goal: <one sentence — what is true after this that was not before>.
+
+Key finding (already verified, do not re-check it): <the concrete fact driving this
+task, with the file/line/command that established it>.
+
+Decided points, not reopenable without evidence that contradicts them:
+1. <decision>
+2. <decision>
+...
+
+Failure to avoid explicitly: <the specific mistake a context-free Executor would make by
+reflex — copying a neighboring task's filter that doesn't apply here, re-deriving a
+fact that was already established and getting it wrong, etc.>.
+
+Verify (literal):
+<exact command>
+
+Success, minimum: <what the check(s) must prove, in terms of cases — not "it passes">.
+
+Report: <TASK-ID>, in <COMPLIANCE_LOG>, section already created.
+
+RULES OF ENGAGEMENT (this run's — confirmed at the start, not a default):
+<the block settled above>
+```
+
+`Key finding` and `Failure to avoid` exist because a fresh Executor has no memory of the
+investigation behind the task — it will make exactly the mistake full context would have
+prevented. Naming the specific reflex to avoid is cheaper than an Executor discovering it
+mid-task.
+
+Do not paste a rules-of-engagement block from one project's run into another's handoff
+without re-confirming it applies. It is a per-run artifact, not part of this skill.
+
+## Remediation handoff (Auditor)
+
+A verdict is not the deliverable — a well-evidenced `CONDITIONAL` or `REJECTED` that
+ends in prose still leaves the Executor with nothing to act on. This is the
+`Remediation order (annex)` from "The document set": write it, and hand it off the same
+way the first task was handed off, not as a narrative the reader has to translate into
+next steps themselves.
+
+```
+ROLE: Executor. Work from this remediation only; the rest of <EXECUTION_GUIDE> is
+unaffected unless named below. Report in <COMPLIANCE_LOG>, appended under <GATE-ID> —
+do not overwrite the original entry.
+
+MODEL: <the original task's, or the next tier up if this is an escalation>.
+
+AUDIT RESULT: <Phase/Task> — <CONDITIONAL | REJECTED>. <one line: what was
+independently re-verified and passed, so the Executor knows what not to touch>.
+
+BLOCKED: <GATE-ID> — <what's actually wrong, in the Auditor's own re-run terms, not a
+restatement of what the original delivery claimed>.
+
+Root cause (verified — carries the command that established it, not reasoned from the
+code): <the mechanism, with file/line and the falsifying probe or command that proved
+it wrong>.
+
+Candidate fix — a recommendation, not a decided point; the Auditor has not run it:
+<the shape of a fix. Mark explicitly as unverified — the Executor confirms it, and may
+find a better one, per "a factual claim always is reopenable">.
+
+Do not touch: <what already passed and must not be disturbed by this fix — the other
+approved gates or tasks in this delivery>.
+
+Verify (literal): <the exact re-run command(s), including re-running the falsifying
+probe that caught this — it must now pass>.
+
+Success, minimum: <what must be true afterward — the probe that failed now passes, the
+original suite stays green, nothing named under "Do not touch" moved>.
+
+Report: <GATE-ID>, in <COMPLIANCE_LOG>, as a remediation entry.
+
+RULES OF ENGAGEMENT: <this run's block>
+```
+
+The "candidate fix, not a decided point" framing matters — the Auditor found the defect
+by running a probe, not by running the fix. Presenting it as settled would violate the
+Auditor's own rule 4 ("The Auditor is bound by rule 4 too" in `SKILL.md`).
+
+**No verdict ends the loop by itself if anything is left to run — and "anything left to
+run" is not only "a phase remains" or "a remediation order is needed."** It also covers
+the most common case of all: a plain `PASS` on one task, mid-phase, with something else
+already outstanding — an earlier remediation, the next task in line. That case has no
+name of its own in the Verdicts table of `SKILL.md`, which is exactly why it's the easiest one
+to ship without a handoff: closing with a status sentence that *describes* what's still
+pending, instead of resending the pasteable block for it. Only a genuine "nothing left"
+closes without a handoff. Otherwise: send the outstanding remediation, or the next
+phase's first task, or the handoff already sent and not yet acted on — with the literal
+template from "Remediation handoff" or "Handing off a task" above, in the same message
+as the verdict, never as a sentence describing it. The Executor's next session starts
+cold no matter which verdict just landed; a one-line summary of what's still owed is
+exactly the kind of pointer-not-an-instruction this whole document exists to close.

package/.agents/skills/auditor-executor-protocol/references/tasks-and-gates.md

@@ -0,0 +1,81 @@
+# Writing Tasks and Gates
+
+Part of the `auditor-executor-protocol` skill. Load when writing a task or a gate. Section names in
+quotes ("Rules of engagement", "Auditing", ...) refer to `SKILL.md` unless they are in
+this file.
+
+## Writing a task (Auditor)
+
+```
+### <TASK-ID> — <imperative, one line>
+
+**Goal:** one sentence. What is true after this that was not before.
+**Files:** every path the Executor should read or change.
+**Blast radius:** every caller or reader of anything a step renames, empties, deletes, or
+  redefines — including a later task's planned work. Empty if genuinely none; never left
+  blank.
+**Steps:** numbered. Exact enough that two Executors produce the same thing.
+**Verify:** the literal command, and the output that counts as success.
+**Report:** the task ID.
+```
+
+Rules for the steps:
+
+- Encode decisions, do not re-open them. "Polling, not a push channel — this is
+  decided, believing otherwise is a stop, not a choice to make while implementing."
+- **Name the failure you expect.** If a field might get overwritten, if a type behaves
+  differently across two environments, if a cap is a layout decision and not a data
+  one — say so in the task. Most bad output comes from an ambiguity the task's author
+  already saw and didn't write down.
+- State what must *not* change alongside what must.
+- **The Blast radius field is not optional decoration — write it before the step, not
+  after something breaks.** When a task renames or redefines what an existing field or
+  column means, the task text must include the command to find every other reader of
+  it, and the Executor must run it and account for every hit, not only the call sites
+  the task's file list happened to name. When a step would empty, delete, or replace
+  shared code, check whether a *later* task in the same phase was planned to still call
+  it — if so, the step is "leave a delegating stub," not "empty it," until the task that
+  owns that caller lands. A task's file list is a lower bound on its blast radius,
+  discovered by the person who wrote the task before the work started — not the whole
+  of it, discovered later by whoever happens to hit the stale or broken reader next.
+- **When a task changes what triggers an automatic action** (a scheduler, a background
+  job, a materializer, anything that can fire without a human pressing a button), the
+  task must require checking — before shipping — what state the change leaves the
+  system in and whether anything is now primed to fire destructively on its next
+  ordinary trigger. Passing tests prove the new code path is correct; they do not
+  prove nothing is about to run against real data the moment it gets the chance.
+
+## Writing a gate (Auditor)
+
+A gate is a claim that can be proven false. "Tests pass" is not a gate. "The
+visibility check was observed failing with the filter removed" is.
+
+Every gate names how it is proven. Include, whenever the phase produces a security,
+privacy, or financial-integrity boundary, a **negative control**: the Executor must
+remove the protection, observe the check fail, restore it, and observe it pass. A
+check never seen failing has not been verified. `auditkit negcontrol` runs this
+sequence and produces a paste-ready transcript.
+
+**A gate defined by more than one command must be re-run in full, not cited from
+whichever half was last checked.** A compound gate closed in one phase by running only
+one of its checks, then cited as "already satisfied" in later phase gates without ever
+re-running the rest, can let real violations accumulate for phases before anyone
+notices. If a gate's own definition lists multiple checks, every phase that claims it as
+satisfied re-runs all of them — a partial citation from an earlier phase does not close
+a compound gate.
+
+**A shared test fixture that always uses a simplified shape hides bugs that only appear
+with a realistic one.** A helper that builds request URLs, headers, or IDs for tests
+should default to a realistic shape (a base URL with its own path prefix, a populated
+auth header, a non-empty ID) rather than the minimal shape that's easiest to write —
+otherwise every test built on it passes for the wrong reason. When gating a feature that
+touches an external contract, prove it against at least one realistically-shaped
+fixture, not only the simplified one most unit tests use.
+
+**When a decision restricts what one channel may carry, check every other channel
+available for the same call.** A rule like "this value travels only via the field
+scoped for it, never the generic payload" is not proven by testing the transport where
+that rule was enforced — check whether the same data can leak through a sibling channel
+on a transport the restriction was never applied to, especially one that leaves your own
+infrastructure for a third party. A restriction proven on one channel or transport is
+not proven on all of them.

package/.agents/skills/no-ai-slop/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2024 Peter Yang
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/.agents/skills/no-ai-slop/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: no-ai-slop
+description: "MANDATORY for user-facing copy, documentation, and agent communication. Removes common AI-generated writing cliches, binary contrasts ('it is not X, it is Y'), empty buzzwords, throat-clearing openers, colon reveals, importance puffery, and em-dash overuse. Source: https://github.com/petergyang/no-ai-slop (MIT License)."
+---
+
+# No AI Slop: Clear, Factual Technical Communication
+
+## Objective
+Ensure every document, user-facing string, and technical report sounds factual, concise, and grounded in engineering reality, eliminating predictable AI writing patterns.
+
+---
+
+## ⛔ Banned Buzzwords & Empty Modifiers
+
+Do not use decorative buzzwords that inflate importance without adding technical substance:
+
+* **Verbs:** delve, foster, leverage, utilize, facilitate, empower, streamline, supercharge, elevate, embark, harness, revolutionize.
+* **Adjectives:** robust, cutting-edge, game-changing, transformative, multifaceted, meticulous, paramount, ever-evolving, world-class, seamless, groundbreaking.
+* **Nouns:** tapestry, realm, beacon, paradigm shift.
+* **Empty adverbs and filler phrases:** crucially, fundamentally, literally, honestly, simply, actually, at the end of the day, it is worth noting that.
+
+---
+
+## ⛔ Banned Structural Patterns
+
+| Pattern | Example | Required Fix |
+| :--- | :--- | :--- |
+| **Binary contrast** | "It is not a tool, it is an operating system." | State what it is directly: "It is an operating system." |
+| **Throat-clearing** | "Here is the thing:", "It is important to remember that" | Remove opening filler; start directly with the fact. |
+| **Colon reveal** | "The best part: it runs in memory." | Write as a plain sentence: "It runs in memory." |
+| **Faux-insight** | "What nobody tells you about state management..." | State the technical constraint directly. |
+| **Importance puffery** | "Marks a pivotal moment in our architecture." | State the empirical metric or change. |
+| **Fake-profound ending** | "The future of coding has arrived." | End on the last concrete technical deliverable. |
+| **Em dash as rhythm crutch** | "We built this — with speed — to scale." | Use commas or split into clear sentences. Max 1 em-dash per long document. |
+
+---
+
+## 📋 Technical Writing Principles
+
+1. **Active Voice & Factual Density:** Explain what the code does, what parameters it receives, and what command validates it.
+2. **State Measurable Facts:** Replace "ultra-fast performance" with measured latency or memory consumption (for example: "< 30MB RAM, < 50ms startup").
+3. **No Unverifiable Claims:** If a metric has not been empirically benchmarked, do not state it as fact.
+
+---
+
+## 🔧 Automated Enforcement
+
+`scripts/check-copy-slop.js` enforces the high-precision subset of these rules on `.md`, `.mdx`, and `.txt` files, using the pattern list in `scripts/lib/slop-patterns.js`. Keep that file and this skill in sync.
+
+* **Enforced:** every banned verb, adjective, and noun above; binary contrast; throat-clearing; colon reveal; faux-insight; fake-profound endings; em dashes above `capabilities.noAiSlop.maxEmDashes` per file (default 1).
+* **Guidance only:** the empty adverbs (simply, actually, literally, honestly) and importance puffery. They have legitimate technical uses, so automated checks would produce false positives.
+* **Not checked:** fenced code blocks, inline code, and table rows.

package/.agents/skills/strategic-cto/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: strategic-cto
+description: "MANDATORY for architectural decisions, technology stack selection, and greenfield discovery. Enforces a Strategic CTO / Principal Engineer posture: strictly forbids premature assumptions, mandates an intake interview across 4 core dimensions (scale, hardware, workloads, modularity), executes live web research, enforces the anti-bloat matrix, and leads with clear strategic verdicts (NO, YES, DEFER) based on risk and ROI."
+---
+
+# Strategic CTO & Architectural Governance Protocol
+
+This skill governs how AI agents must act when evaluating architectures, bootstrapping new systems, or reviewing optimization requests. It enforces a **Senior Principal Engineer / CTO posture**, preventing sycophancy, academic optimization dumping, and premature assumptions.
+
+---
+
+## 🚨 Core Directives
+
+### 1. No Premature Assumptions (Mandatory Discovery First)
+* **NEVER** prescribe a stack, select a database, or draft an Architectural Decision Record (ADR) on Turn 1 of a new project pitch.
+* **NEVER** assume concurrency, deployment targets, or scaling constraints.
+* Before suggesting any technology, the agent **MUST** conduct the **4-Pillar Discovery Interview**:
+  1. **Scale & Concurrency:** Personal/internal use versus public service? Current expected load versus 6 to 12 month projection (e.g. 1–5, 100–1,000, 50,000+ concurrent users/streams)?
+  2. **Hardware & Deployment Target:** Local developer machine, self-hosted mini-PC/NAS, low-cost VPS ($5/month), or cloud infrastructure? Memory/CPU constraints?
+  3. **Data & Compute Workloads:** Raw I/O versus heavy compute (for example: live video transcoding, image processing)? Expected data volume (GBs versus TBs)? Storage target (local filesystem, S3/R2 object storage)?
+  4. **Scope & Modularity:** Multi-language localization (i18n) needed or single language? Authentication and role-based access control (RBAC) needed? Progressive Web App (PWA) or offline support needed?
+
+### 2. Live Web Research (No Training Cutoff Stagnation)
+* Never rely exclusively on static training weights when recommending libraries, versions, or frameworks.
+* Always perform live web queries to verify:
+  * Current LTS releases and framework stability.
+  * Active maintenance status and recent critical CVEs.
+  * Ecosystem consensus and benchmarks for the specific workload.
+
+### 3. Anti-Bloat & Right-Sizing Matrix
+* Avoid default bias toward heavy full-stack frameworks (for example: Next.js SSR, Django, heavy ORMs).
+* Evaluate across three architectural tiers:
+  * **Tier 1 (Ultra-Lightweight / High I/O):** Go, Rust, C++ with static Vite SPA or vanilla frontend. (< 30MB RAM, sub-50ms boot).
+  * **Tier 2 (Balanced / High Velocity):** FastAPI, Hono, Express with Vite SPA. (< 150MB RAM, fast iteration).
+  * **Tier 3 (Heavy Full-Stack Batteries):** Next.js SSR, Django, Ruby on Rails.
+* **Burden of Proof Rule:** Tier 3 frameworks are **FORBIDDEN** unless the user demonstrates a technical requirement that Tiers 1 and 2 cannot solve (for example: public dynamic SEO indexing across tens of thousands of pages).
+
+### 4. Strategic Verdict First (`NO`, `YES`, `DEFER`)
+* When asked "Can this be improved?", evaluate risk and ROI before listing options.
+* If a system is stable, within acceptable operational bounds, and guarded by past post-mortems, lead with **`NO, keep it as is`**.
+* Defend stability over novelty. A "No" backed by engineering risk is standard senior leadership.
+
+### 5. Zero AI Slop Communication
+* Follow the `no-ai-slop` skill. No theatrical persona announcements (for example `[CTO MODE ACTIVATED]`) or decorative emoji.
+
+---
+
+## 🛠️ Step-by-Step Workflow
+
+1. **Step 1 (Discovery):** Ask probing questions about scale, hardware, compute, and modularity.
+2. **Step 2 (Research):** Search current documentation and benchmarks for the validated constraints.
+3. **Step 3 (Architecture Record):** Complete `docs/decisions/ADR-0001-stack-and-architecture.md` (seeded by `sdd-init` with the discovery answers) with pros, cons, and alternatives considered.
+4. **Step 4 (Provisioning):** Set up repo via `gh`, 3-tier secrets vault, and `.gitignore`.
+5. **Step 5 (Execution):** Hand off tasks to the Auditor / Executor protocol with verifiable exit gates.