@friedbotstudio/create-baseline 0.1.0

package/obj/template/.claude/skills/brd/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: brd
+owner: baseline
+description: Draft a Business Requirements Document (BRD) for cross-functional or stakeholder-heavy work that needs more structure than an intake. Use after `/intake` when the request spans multiple systems/teams, carries regulatory weight, or needs formal sign-off. Output lives at `docs/brd/<slug>.md`.
+---
+
+# BRD — Business Requirements Document
+
+You are drafting a BRD. BRDs are heavier than intakes — they exist when a request needs explicit sign-off from named business stakeholders, and when the **why** and the **what** must survive independently of the **how** (the spec).
+
+**Use a BRD when:**
+- Multiple teams or external stakeholders need to align.
+- Regulatory, legal, or compliance concerns shape the requirements.
+- Business milestones or contractual dates are tied to the work.
+- Budget or headcount implications warrant an approved scope.
+
+**Don't use a BRD for:** single-team feature work, quickfixes, or internal refactors. Those need an intake + spec, nothing more.
+
+## Prerequisite
+
+Either `/intake` has completed (there's a corresponding `docs/intake/<slug>.md`), OR the user is starting directly at BRD because the intake exists upstream (e.g., in Linear/Jira) and they want to formalize it here.
+
+## Inputs
+
+- The intake document (if any) — it supplies **Problem** and **Goal**.
+- The user's additional context about stakeholders, timelines, and compliance.
+- `template.md` in this skill directory.
+
+## Steps
+
+1. If a corresponding intake exists at `docs/intake/<slug>.md`, read it. Map **Problem → Business objective** and **Goal → Executive summary**.
+2. Read `template.md`. Every heading must appear in the output.
+3. For each section, write content that answers the questions in the template comments. If unknown, list the gap under **Open questions** — never fabricate stakeholder names, dates, or dollar amounts.
+4. Name every requirement with an ID: `BR-001`, `BR-002`, … for business reqs; `FR-001`, … for functional; `NFR-001`, … for non-functional. Downstream spec AC will reference these IDs.
+5. Write to `docs/brd/<slug>.md` (same slug as the intake, if one exists).
+6. Tell the user: "BRD drafted at `docs/brd/<slug>.md`. Sign-offs required from: <list>. Open questions: N. Next: `/scout` (or get sign-offs first if you want to freeze scope)."
+
+## Drafting rules
+
+- **Requirements are testable, not aspirational.** "The system shall support peak traffic" is aspirational. "The system shall sustain 500 RPS with P95 < 200ms" is testable.
+- **Separate business from functional from non-functional.** A mixed list becomes unactionable.
+- **Risks must have owners.** "Risk: the vendor API could change" with no owner is noise. Either name who monitors it or delete it.
+- **Sign-offs are names, not titles.** "Head of Compliance" can't sign — their replacement, who is a specific person, can.
+- **Do not write the solution.** The BRD says what must be true; the spec says how. If you catch yourself writing "we'll use Kafka", stop — that belongs in `/spec`.

package/obj/template/.claude/skills/brd/template.md

@@ -0,0 +1,83 @@
+# <BRD title — business outcome, not implementation>
+
+<!--
+Business Requirements Document. Produced by the `brd` skill.
+Required sections (enforced by artifact_template_guard): Business objective,
+Scope, Business requirements.
+-->
+
+## Executive summary
+
+<Two to four sentences. What business problem are we solving, why now, and
+what changes when we're done? A reader who sees only this paragraph should
+know whether to care.>
+
+## Business objective
+
+<The outcome in business terms: revenue, cost, risk, compliance, customer
+satisfaction. Tie to a specific metric where possible.>
+
+## Scope
+
+### In scope
+- <item>
+- <item>
+
+### Out of scope
+- <item — explicit exclusions that the spec cannot later quietly include>
+
+## Business requirements
+
+<The "what must be true for this to succeed" statements. Each has an ID so
+the spec and tests can reference it.>
+
+- **BR-001** — <requirement statement>. Rationale: <why>.
+- **BR-002** — <requirement statement>. Rationale: <why>.
+
+## Functional requirements
+
+<How the system must behave to satisfy the business requirements. Each ties
+back to a BR.>
+
+- **FR-001** — <behaviour>. Satisfies: BR-001.
+- **FR-002** — <behaviour>. Satisfies: BR-001, BR-002.
+
+## Non-functional requirements
+
+<Performance, security, availability, observability, compliance. Must be
+measurable.>
+
+- **NFR-001** — <e.g., P95 latency < 200ms at 500 RPS>. Rationale: BR-00X.
+- **NFR-002** — <e.g., data at rest encrypted with AES-256-GCM>. Rationale:
+  regulatory (specify regulation).
+
+## Stakeholders and sign-offs
+
+| Name | Role | Sign-off required | Status |
+|------|------|-------------------|--------|
+| <name> | <business owner> | yes | pending |
+| <name> | <eng lead>       | yes | pending |
+| <name> | <compliance>     | yes | pending |
+
+## Dependencies
+
+<External systems, teams, vendors, or pre-existing work this BRD depends on.>
+
+- <dependency — owner — blocking? yes/no>
+
+## Risks
+
+<Named risks, each with owner and mitigation.>
+
+- **R-01** — <description>. Owner: <name>. Mitigation: <what we'll do>.
+
+## Timeline / milestones
+
+<Dates tied to named deliverables. Avoid false precision — if the date is a
+target, mark it "target"; if it's a commitment, mark it "committed".>
+
+- <date> — <milestone> — target | committed
+
+## Open questions
+
+- <question>

package/obj/template/.claude/skills/chore/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: chore
+owner: baseline
+description: Workflow track for tasks that need no TDD — documentation edits, governance count bumps, vendored-skill content updates, configuration tweaks, formatting, typo fixes, dependency bumps where no project code changes. Skips `/scenario` and `/implement` (no failing test to drive) and runs the work directly. `verify`, `archive`, `/grant-commit`, and `/commit` remain mandatory. `simplify`, `integrate`, and `document` are conditional — required when the diff hits one of the listed triggers, optional otherwise. Chore is a stripped-down pipeline, not a bypass; never silently skip a conditional phase whose triggers apply.
+argument-hint: "<one-line description of the chore>"
+---
+
+# chore — workflow for tasks that don't need TDD
+
+This skill runs a stripped-down workflow for tasks where nothing is meaningfully driven by a failing test. The full `/tdd` RALPH cycle is theatre when the change is "fix a typo", "update a count", "remap a vendored path", or "tighten a description" — there is no test that catches a typo, and the project audit (or a downstream lint) serves as the regression check.
+
+The chore workflow exists so this class of work can move with the **right** ceremony — real verification of "did I break anything" without the scenario+implement loop, and conditional simplify/integrate/document passes when the diff actually warrants them.
+
+## Definition: when is a task a chore?
+
+A task is a **chore** if and only if **it has no code changes that need TDD**. Concretely, a chore is anything from this list:
+
+- Documentation edits — `README.md`, `CLAUDE.md` prose, `docs/init/seed.md` prose, governance count refreshes, skill SKILL.md descriptions, reference docs.
+- Vendored-skill content updates — path remaps (e.g. `.agents/` → `.claude/skills/`), count refreshes, "Related Skills" annotations, license-required modification notices.
+- Configuration tweaks — `project.json`, `.mcp.json`, `settings.json` edits whose behavioural effect is config-driven (a new declaration, a flipped flag) rather than code-driven.
+- Formatting / typo fixes anywhere in the repo.
+- Dependency bumps where no project code changes alongside.
+- Skill consolidation moves — collapsing a single-consumer skill into its consumer's `references/` directory.
+- File renames or path remaps with no behavioural change.
+
+A task is **not a chore** if any of:
+
+- New runtime behaviour is being added — the failing test is the only way to drive it correctly.
+- A bug is being fixed and regressing to that bug would be undetectable without a test — the fix SHALL come with a test.
+- A refactor changes behaviour under specific inputs — TDD captures the boundary.
+
+The classification rule is: *if there is no failing test that should exist for this work, it is a chore. Otherwise it is `/tdd` (or higher).*
+
+`/triage` decides the classification; this skill confirms it on entry.
+
+## Prereq
+
+`.claude/state/workflow.json` exists with `entry_phase: "chore"` (written by `/triage`). If the prereq is not met, refuse and surface the mismatch.
+
+## Phase shape
+
+### Mandatory phases (always run)
+
+1. **Edit** — apply the change directly. No `/scenario`, no `/implement` — there is no failing test to drive.
+2. **`verify`** — run the project test command and stamp `.claude/state/last_test_result`. FAIL means stop, surface, and route the user to `/triage` for a proper bugfix track. The verdict is binding (the `verify_pass_guard` hook reads this file).
+3. **`archive`** — empty bundle is fine; `/commit`'s prereq requires `archive` in `completed`.
+4. **`/grant-commit` then `/commit`** — user-required consent + commit. Same as every other workflow.
+
+### Conditional phases (required when triggers apply, optional otherwise)
+
+5. **`simplify`** — required when **any** of:
+   - Diff exceeds ~30 lines OR touches more than 3 files.
+   - The change includes refactor-like moves (renames, restructuring, file relocations).
+   - The chore creates duplication that future cleanup will need to consolidate.
+   - More than one file in the diff would benefit from a reuse / structure pass.
+   Otherwise skip — and say so in your end-of-chore summary so the choice is auditable.
+
+6. **`integrate`** — required when **any** of:
+   - The diff touches the test surface — test command, fixtures, hook scripts, `settings.json` hook wiring, `project.json → test/lint` keys.
+   - The diff alters MCP server declarations or runtime config that affects how the harness behaves.
+   - The diff could plausibly break unrelated downstream phases (e.g. editing an audit script's `EXPECTED_*` set).
+   Otherwise the mandatory `verify` stamp is sufficient — note the skip in the summary.
+
+7. **`document`** — required when **any** of:
+   - User-facing prose changes — `README.md`, `CLAUDE.md` prose, `docs/init/seed.md` prose, skill `SKILL.md` `description:` lines, public-facing reference docs.
+   - Counts or inventories change — skill count, hook count, command count, MCP server count, alternate-track count.
+   - New conventions are introduced — a new helper file, a new reference doc, a new directory.
+   - The `seed.md §16` follow-ups list needs an entry resolved or added.
+   - The chore touches `src/` templates (the templates are user-facing once `npx @friedbotstudio/create-baseline` runs).
+   Otherwise skip — note in the summary.
+
+If a conditional phase is required, run it **before** `/grant-commit`. If you skip one, the end-of-chore summary SHALL state which conditional phases were skipped and why. Silent skips are not allowed.
+
+## Steps
+
+1. Read `.claude/state/workflow.json`. Confirm `entry_phase == "chore"`. If not, stop and surface the mismatch — the user reached this skill without the correct triage classification.
+2. Restate the intended edits inline: file paths, brief description per file, estimated total diff size. Confirm with the user if anything is ambiguous.
+3. Apply the edits via `Edit` / `MultiEdit` / `Write`. Honour the engineering rules from CLAUDE.md Article VI (no stubs, no commented-out code, no `TODO` / `FIXME` / `HACK` / `XXX`).
+4. **Run the binding test command and stamp the verdict (inlined verify).** Per `.claude/skills/verify/SKILL.md` (the contract doc): read `.claude/project.json → test.cmd`; run via Bash from project root (capture stdout, stderr, exit code; no retry); apply verdict rules (`PASS` iff exit 0 AND at least one test executed AND no failed/errored test; otherwise `FAIL`); atomically write `.claude/state/last_test_result` with the canonical four-line format. The `verify_pass_guard` hook reads line 1 as the binding verdict. If the verdict is `FAIL`, stop — the user investigates; chore does not loop. Write `.claude/state/harness_state` with `state: "yielded"` and `reason: "chore verify FAIL"` so the Stop hook stays silent.
+5. Walk the conditional triggers in order. For each:
+   - **Required** → invoke the phase skill and append it to `workflow.json → completed`.
+   - **Skipped** → record the rationale in your end-of-chore summary; do not append to `completed`.
+6. Invoke `Skill(archive)` — mandatory.
+7. Append `"chore"`, `"archive"`, and any conditional phases that ran to `workflow.json → completed`. Update `updated_at` to the current epoch.
+8. **Marker op FIRST, then write `harness_state`, then emit end-of-chore summary.** On `state: "continue"` (more phases follow, e.g. archive is still pending): `echo "<slug>" > .claude/state/.harness_active` to refresh the active marker, then write `.claude/state/harness_state` with `{state: "continue", slug, reason}`. On `state: "done"` (archive just appended and no further phases remain): `rm -f .claude/state/.harness_active`, then write `harness_state` with `{state: "done", slug, reason}`. The state file carries exactly three keys; no `written_at`, no `tick_count`. Then tell the user:
+   - "Chore green."
+   - Files changed.
+   - Conditional phases run (and why).
+   - Conditional phases skipped (and why).
+   - "Run `/grant-commit`, then `/commit` to finalize." *(omit this line on non-git projects where commit is excepted; instead say "Workflow ends after `/archive` on this non-git project.")*
+
+## Constraints
+
+- The `verify` stamp is binding. `verify_pass_guard` reads `.claude/state/last_test_result`; that file is the truth.
+- No subagent delegation — Article II applies to chore the same as every other phase skill.
+- A `FAIL` from `verify` is non-recoverable inside this skill — chore does not loop. If the audit reveals a real bug, the user runs `/triage` for a proper bugfix track.
+- Conditional phases are *conditional*, not *forbidden*. **If in doubt, run them.** The cost of running a `simplify` or `document` pass that turned out unnecessary is small; the cost of skipping one whose triggers actually applied is shipping drift.
+- The end-of-chore summary SHALL document every conditional-phase skip. Silent skips defeat the auditability the chore workflow is designed for.
+- Chore is **not** a bypass for the canonical workflow's quality gates. It is a stripped-down ordering of the same gates, with the test-first phases removed because there is nothing to test-first.

package/obj/template/.claude/skills/claude-automation-recommender/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/obj/template/.claude/skills/claude-automation-recommender/NOTICE

@@ -0,0 +1,69 @@
+claude-automation-recommender
+==============================
+
+This skill is vendored from the `claude-code-setup` plugin published by
+Anthropic and is redistributed here under the terms of the Apache License,
+Version 2.0 (see LICENSE in this directory).
+
+Upstream:
+  Plugin name:    claude-code-setup
+  Upstream version: 1.0.0
+  Author:         Anthropic <support@anthropic.com>
+  Vendored into:  .claude/skills/claude-automation-recommender/
+  Vendored on:    2026-04-25
+
+Modifications:
+  See "Local changes" below.
+
+Local changes:
+  - 2026-04-25: Added "Working with the baseline" section to SKILL.md.
+    Lists the 14 hooks / 8 subagents / 26 skills / 4 commands / 2 MCPs the
+    baseline already provides, instructing the recommender to surface
+    *gaps* and project-specific tailoring rather than duplicate baseline
+    components. Also added a JSON output schema for /init-project to
+    consume the recommender's findings programmatically.
+  - 2026-04-28: Refreshed "Working with the baseline" counts in SKILL.md
+    to match the current shape: 14 → 17 hooks (the 3 lifecycle hooks
+    `memory_session_start`, `memory_stop`, `memory_pre_compact` were
+    added between 2026-04-25 and now), 34 → 36 skills (the `chore`
+    alternate track and `memory-flush` memory-curation skill were added).
+    The historical 2026-04-25 entry above is preserved verbatim as a
+    record of the snapshot at that date.
+  - 2026-04-28 (later): 36 → 37 skills — the user added a vendored
+    `developer-audience-context` skill that `technical-tutorials` now
+    references as its audience-loader. Updated SKILL.md skill count and
+    breakdown; added the new mandatory-sub-skill chain
+    (`technical-tutorials` → `developer-audience-context`) to the
+    bullet's "Several skills mandatorily invoke another skill" list.
+  - 2026-04-28 (final): 37 → 36 skills — consolidated the standalone
+    `developer-audience-context` skill into `technical-tutorials` per the
+    user's call ("not generic enough; exists solely for technical-tutorials").
+    Audience-context content moved into `technical-tutorials/references/`
+    as `audience-context.md`, `audience-template.md`, `audience-example.md`,
+    and `audience-context-README.md`. Apache 2.0 attribution preserved via
+    the consolidated README in that references directory. Updated SKILL.md
+    skill count + breakdown; removed the mandatory-sub-skill chain
+    (`technical-tutorials` no longer invokes a separate skill — the
+    audience reference is local).
+  - 2026-05-12: Refreshed the "Working with the baseline" hook count in
+    SKILL.md to match the current shape: 17 → 22 hooks. The breakdown is
+    now "17 write/run-boundary guards plus 4 lifecycle hooks plus 1
+    input-boundary hook". The list of write/run-boundary guards was
+    completed (previously omitted `swarm_approval_guard`,
+    `spec_design_calls_guard`, and `process_lifecycle_guard`); the
+    lifecycle list now includes `harness_continuation` (the workflow
+    auto-continuation Stop hook added by the `harness-auto-continuation`
+    workflow at `docs/archive/2026-05-12/harness-auto-continuation/`);
+    `consent_gate_grant` is named as the input-boundary hook. Skill count
+    unchanged at 36. No upstream behavior was modified; only the local
+    baseline-inventory paragraph was updated.
+  - References/ directory unchanged from upstream.
+
+License:
+  Apache License 2.0. Full text in ./LICENSE.
+
+Why vendored:
+  The recommender is a mandatory first step in this baseline (see
+  docs/init/seed.md §0). Vendoring removes the runtime dependency on
+  having the `claude-code-setup` plugin installed and ensures the
+  capability travels with the repository.