agents-md-kit 0.0.0-stage → 0.1.0

package/core/files/.claude/skills/project-management-workflow/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: project-management-workflow
+description: Lightweight project management workflow for AI-assisted development. Use when planning features, breaking down tasks, tracking progress, recording architectural decisions (ADRs), defining done, handing work between sessions or agents, or reporting status.
+---
+
+# Project Management Workflow for Agents and Humans
+
+Goal: ship small, verified increments with minimal ceremony, and keep the project's state understandable to anyone (or any agent) joining mid-way.
+
+## 1. Task Lifecycle
+
+```
+Clarify → Plan → Implement → Verify → Document → Hand off
+```
+
+1. **Clarify:** restate the goal and the acceptance criteria. Identify unknowns, constraints and what is *out of scope*. Ask when requirements are ambiguous or the change is destructive/irreversible. Otherwise state assumptions and proceed.
+2. **Plan:** read `AGENTS.md` and `MEMORY.md`. Inspect relevant code. Write a short plan (section 3).
+3. **Implement:** small steps, one concern at a time, tests alongside. Commit atomically (`git-commit-and-workflow`).
+4. **Verify:** run tests, lint, type checks and the feature itself. Don't claim "done" on code that hasn't been run. Check the relevant skill checklists.
+5. **Document:** write the commit/PR title as a release note and update the changelog per the `changelog-and-versioning` skill; update docs/OpenAPI, ADRs and `MEMORY.md` (`agent-memory-protocol`).
+6. **Hand off:** summarize what changed, how it was verified, what's left and any risks or open questions.
+
+## 2. Work Breakdown
+
+- Break work into tasks that can be completed and verified in **about half a day or less**, each with a clear outcome.
+- Slice **vertically** (a thin end-to-end behavior: UI + API + DB) rather than horizontally (all DB first, all UI later), so each slice is shippable and testable.
+- Order tasks by risk and dependency: tackle unknowns and riskiest assumptions first, using spikes (time-boxed investigations) for unknowns.
+- A good task states: goal, acceptance criteria, scope boundaries, dependencies and how to verify.
+- Track tasks in the team's tracker (GitHub Issues, Linear, Jira). For solo/agent work without one, use a `TASKS.md` checklist at the repo root. Keep one source of truth.
+
+Task template:
+
+```markdown
+## Goal
+<one sentence outcome>
+
+## Acceptance Criteria
+- [ ] Given/When/Then or observable behavior
+- [ ] Error and edge cases handled
+- [ ] Tests added
+
+## Out of Scope
+-
+
+## Notes / Dependencies
+-
+```
+
+## 3. Planning Non-Trivial Changes
+
+For anything touching more than a few files, a data model, an API contract or security, write a short plan before coding (in the PR description, issue, or `docs/plans/<topic>.md`):
+
+```markdown
+# Plan: <title>
+## Problem and goal
+## Approach (and alternatives considered)
+## Steps (ordered, each independently verifiable)
+## Data/API/contract changes (and migration/rollback)
+## Risks and mitigations
+## Test strategy
+## Open questions
+```
+
+Keep it to about a page. Update it if the approach changes. Delete or archive when merged if it has no lasting value (decisions go to an ADR).
+
+## 4. Architecture Decision Records (ADRs)
+
+Record decisions that are hard to reverse or that future contributors will question (framework choice, data model, auth approach, major dependency, API style).
+
+- Location: `docs/adr/NNNN-short-title.md` (numbered, immutable once accepted. Supersede with a new ADR instead of editing history).
+- Keep each to one page.
+
+```markdown
+# ADR-0004: Store money as integer minor units
+
+- Status: Accepted (2026-11-11)   <!-- Proposed | Accepted | Deprecated | Superseded by ADR-00XX -->
+- Deciders: <names>
+
+## Context
+What forces and constraints led to this decision?
+
+## Decision
+What we will do.
+
+## Consequences
+Positive, negative and follow-up work.
+
+## Alternatives considered
+Option A: ... rejected because ...
+```
+
+Add a one-line pointer in `MEMORY.md` for quick recall.
+
+## 5. Definition of Ready and Done
+
+**Ready to start** (don't begin until true, or state assumptions):
+- [ ] Goal and acceptance criteria are clear
+- [ ] Dependencies and access are known
+- [ ] Scope is small enough to finish and verify in one go
+
+**Done** (see also `AGENTS.md`):
+- [ ] Acceptance criteria met and demonstrated (tests and/or manual check)
+- [ ] Code reviewed (self-review at minimum), lint/types/tests green in CI
+- [ ] Security, accessibility, SEO and performance checks applied where relevant (see the skills listed in `AGENTS.md`)
+- [ ] Migrations safe and reversible. API changes non-breaking or versioned
+- [ ] Commit/PR title reads as a release note; changelog updated per the `changelog-and-versioning` skill; docs and `MEMORY.md` updated as needed
+- [ ] Merged, and deployed or ready to deploy
+
+## 6. Scope and Change Control
+
+- Do what was asked, no more. Note related improvements as follow-up tasks instead of expanding the change silently.
+- If scope grows or the approach must change significantly, stop and report it, since the person deciding needs the new trade-offs.
+- Never make destructive or irreversible changes (data deletion, schema drops, force pushes, production config) without explicit confirmation.
+- Record deferred work as issues/TODOs with context. Don't leave anonymous `TODO` comments. Use `TODO(#123): ...`.
+
+## 7. Risk and Quality Management
+
+- State assumptions explicitly, and flag any that are unverified.
+- Prefer reversible changes: feature flags, small PRs, backward-compatible migrations, easy rollback.
+- Identify blast radius before changing shared code, public APIs, auth, payments or data.
+- Keep the build green. If you break `main`, fix forward or revert immediately.
+- Treat flaky tests as bugs. Don't retry-until-green or disable without a tracked issue.
+- Track technical debt visibly (issues labeled `tech-debt`) with impact and a proposed fix. Reserve regular capacity to pay it down.
+
+## 8. Communication and Status Reporting
+
+Status updates should be short, factual and actionable:
+
+```markdown
+**Done:** what is complete and verified
+**In progress:** what's underway, and the next step
+**Blocked / needs decision:** what, who, and by when
+**Risks:** anything that could change scope, schedule or quality
+```
+
+- Report outcomes and evidence ("tests pass: 142/142; checkout flow verified locally"), not just activity.
+- Be honest about what was *not* verified or not completed. Never claim success you haven't confirmed.
+- Surface blockers early and propose options with a recommendation.
+
+## 9. Handoffs Between Sessions and Agents
+
+At the end of a session, leave the project so that a stranger could continue:
+1. Working tree clean or committed in meaningful commits. Branch pushed if requested.
+2. `MEMORY.md` → **Current State** shows what's done, what's next and blockers.
+3. Issues/`TASKS.md` reflect the real status.
+4. A final summary message with links to the PR/branch, how to run and verify, and open questions.
+
+## 10. Recommended Repository Layout
+
+```
+/
+├── AGENTS.md              # Rules for agents (stable, human-owned)
+├── MEMORY.md              # Learned facts and current state (agent-maintained)
+├── CHANGELOG.md           # User-facing release history
+├── TASKS.md               # Optional: task list when no external tracker
+├── README.md              # Humans: what it is, how to run it
+├── .github/
+│   ├── pull_request_template.md
+│   └── ISSUE_TEMPLATE/
+├── .claude/skills/        # Skill folders (each contains SKILL.md)
+└── docs/
+    ├── adr/               # Architecture Decision Records
+    ├── plans/             # Optional: short implementation plans
+    └── memory/            # Optional: area-specific memory when MEMORY.md grows
+```
+
+## 11. Cadence (Optional, for Teams)
+
+- **Daily:** keep the board current. Surface blockers.
+- **Weekly:** review the backlog, re-prioritize, prune stale issues and `MEMORY.md`.
+- **Per release:** update the changelog and version per the `changelog-and-versioning` skill, verify the release checklist, and run a short retro (what worked, what didn't, one improvement to try).
+
+## Review Checklist
+
+- [ ] Goal, acceptance criteria and scope are written down before implementation
+- [ ] Work is split into small, verifiable, vertical slices
+- [ ] Significant decisions recorded in an ADR; plan written for non-trivial changes
+- [ ] Verified by running tests and the feature; Definition of Done satisfied
+- [ ] Scope respected; follow-ups tracked as issues; destructive actions confirmed
+- [ ] Status report is factual, with blockers and risks surfaced
+- [ ] Handoff state is in `MEMORY.md`, tracker and PR description

package/core/files/CLAUDE.md

@@ -0,0 +1 @@
+@AGENTS.md

package/core/files/MEMORY.md

@@ -0,0 +1,77 @@
+# MEMORY.md
+
+Persistent working memory for AI agents and contributors. Maintained under the rules in the `agent-memory-protocol` skill.
+
+**Rules of thumb:** short, dated, verified when possible. No secrets. Prune obsolete entries. Under about 200 lines. Rules belong in `AGENTS.md`, history in git/`CHANGELOG.md`. If memory disagrees with the code, trust the code and fix this file.
+
+_Last pruned: YYYY-MM-DD_
+
+---
+
+## Project Snapshot
+
+<!-- What this is, who uses it, stack, key constraints. 3-6 lines. -->
+
+- **Purpose:**
+- **Stack:** (frontend / backend / DB / infra)
+- **Environments:** (local / staging / production, how they differ)
+- **Key constraints:** (compliance, performance targets, supported browsers/runtimes)
+
+## Commands (verified)
+
+<!-- Exact commands that work. Mark with date. -->
+
+| Task             | Command | Notes |
+| ---------------- | ------- | ----- |
+| Install          | ``      |       |
+| Dev server       | ``      |       |
+| Run tests        | ``      |       |
+| Lint / typecheck | ``      |       |
+| Build            | ``      |       |
+| DB migrate       | ``      |       |
+
+## Architecture Notes
+
+<!-- Non-obvious structure: where logic lives, data flow, module boundaries. Link to docs/ADRs. -->
+
+-
+
+## Decisions
+
+<!-- [date] Decision: what, why, rejected alternatives. Pointer to ADR/issue. -->
+
+-
+
+## Conventions Learned
+
+<!-- Preferences or patterns not (yet) in AGENTS.md. Promote stable ones to AGENTS.md. -->
+
+-
+
+## Gotchas and Pitfalls
+
+<!-- [date] What goes wrong, why, and the workaround. Delete when fixed in code. -->
+
+-
+
+## Current State / In Progress
+
+<!-- Single owner at a time. Update at the end of every session. -->
+
+- **Working on:**
+- **Branch / PR:**
+- **Done so far:**
+- **Next step (exact):**
+- **Blockers:**
+
+## Open Questions (for a human)
+
+<!-- Question, context, who can answer, date asked. -->
+
+-
+
+## Session Log (last ~5, one line each)
+
+<!-- [date] What was achieved; link to commit/PR. Remove older entries. -->
+
+-

package/core/files/docs/adr/0000-template.md

@@ -0,0 +1,21 @@
+# ADR-NNNN: <short decision title>
+
+- Status: Proposed <!-- Proposed | Accepted | Deprecated | Superseded by ADR-NNNN -->
+- Date: YYYY-MM-DD
+- Deciders: <names>
+
+## Context
+
+What forces and constraints led to this decision?
+
+## Decision
+
+What we will do.
+
+## Consequences
+
+Positive, negative and follow-up work.
+
+## Alternatives considered
+
+Option A: ... rejected because ...

package/core/fragments/agents-core.md

@@ -0,0 +1,61 @@
+This file is the entry point for AI coding agents working in this repository. Load the relevant skill(s) before writing or reviewing code in that area. If rules conflict, security beats everything, then correctness, then simplicity (KISS/YAGNI), then everything else.
+
+## Session Start (always)
+
+1. Read this file, then `MEMORY.md` (learned facts and current state). Verify remembered facts against the code before relying on them.
+2. Run `git status` and `git log -10 --oneline` to see recent changes.
+3. Load the skills relevant to the task from the skill index below (and any additional skill sections further down this file).
+
+## Skill Index
+
+Skills live at `.claude/skills/<name>/SKILL.md`.
+
+| Area | Skill | Load when |
+|---|---|---|
+| Backend architecture | `backend-architecture-principles` | Structuring services, errors, config, logging, jobs, testing |
+| API design | `api-design-rest` | Endpoints, payloads, status codes, pagination, versioning |
+| Security | `backend-security` | Auth, authorization, input handling, uploads, headers, secrets |
+| Database | `database-best-practices` | Schemas, queries, indexes, migrations, transactions |
+| Git & commits | `git-commit-and-workflow` | Committing, branching, PRs, releases, tags |
+| Agent memory | `agent-memory-protocol` | Start/end of every task; whenever you learn something durable |
+| Changelog & versions | `changelog-and-versioning` | Any user-facing change, deprecation, release, version bump |
+| Project management | `project-management-workflow` | Planning, task breakdown, ADRs, status reports, handoffs |
+
+## Project Files and Who Owns Them
+
+| File | Purpose | Owner |
+|---|---|---|
+| `AGENTS.md` | Stable rules and conventions | Humans |
+| `MEMORY.md` | Learned facts, decisions, gotchas, current state | Agents (humans may edit) |
+| `CHANGELOG.md` | User-facing release history | release-please if configured, otherwise agents + humans |
+| `docs/adr/` | Architecture Decision Records | Humans + agents |
+| Git history | Exact record of every change and why | Everyone |
+
+## Universal Rules
+
+1. **Understand before changing.** Read the surrounding code and follow existing conventions unless they violate a rule here.
+2. **Keep changes small and focused.** One concern per change. Don't refactor unrelated code in a feature change.
+3. **Simplest thing that works** (KISS/YAGNI). No speculative abstractions, flags or optimizations without a concrete need.
+4. **Validate at boundaries.** Never trust client input. Validate on the server regardless of client-side checks.
+5. **Security is not optional.** Apply `backend-security` to every feature touching users, data or external input.
+6. **Write tests** for new behavior and bug fixes (including error paths and permission checks). Don't merge with failing tests, lint or type errors.
+7. **No secrets in code, logs, memory files or client bundles.**
+8. **User-facing quality is part of "done":** accessibility, performance and discoverability for anything users see.
+9. **Document decisions**: update README/OpenAPI/ADRs when behavior or contracts change.
+10. **When requirements are ambiguous, ask** rather than guess, especially for data model, auth and destructive operations.
+11. **Commit with Conventional Commits**, atomically, and only when asked or when the workflow says so. Never force-push shared branches, and never skip or work around configured hooks and checks (`--no-verify`, disabling rules to make a check pass). Fix the underlying issue.
+12. **Write commit/PR titles for the reader of the changelog.** If release-please is configured, don't hand-edit `CHANGELOG.md` or version fields.
+13. **Keep memory current and small.** Record durable learnings, prune obsolete ones, and leave exact next steps in `MEMORY.md` at the end of each session (see `agent-memory-protocol`).
+14. **Never claim done without verifying.** Run the tests and the feature. Report honestly what was and wasn't verified.
+
+## Definition of Done
+
+- [ ] Meets the requirement, with tests passing (locally and in CI, if there is CI)
+- [ ] Lint, formatting and type checks configured for this repository pass
+- [ ] Relevant skill checklists reviewed
+- [ ] No new vulnerabilities, secrets or unnecessary dependencies
+- [ ] Migrations backward compatible; API changes non-breaking or versioned
+- [ ] Commits follow Conventional Commits; PR small, described, and titled as a release note
+- [ ] Changelog updated per `changelog-and-versioning`
+- [ ] `MEMORY.md` updated (learnings pruned/added, Current State accurate)
+- [ ] Docs/OpenAPI/ADRs updated

package/core/manifest.txt

@@ -0,0 +1,21 @@
+# description: Always installed. AGENTS.md core block, MEMORY.md, permissions, process and engineering skills, ADR template.
+#
+# Format (one entry per line, fields split on whitespace, paths must not contain spaces):
+#   copy       <path> [requires=<pack>] [from=<unit-relative source>]
+#   copy-once  <path> [requires=<pack>] [from=<unit-relative source>]
+#   block      <id> <dest> <fragment> [style=html|hash] [requires=<pack>]
+#   implies    <pack>     (presets and packs only: selecting the unit also selects that pack)
+
+block      core  AGENTS.md  agents-core.md
+copy       CLAUDE.md
+copy-once  MEMORY.md
+copy       .claude/settings.json
+copy       .claude/skills/agent-memory-protocol/SKILL.md
+copy       .claude/skills/git-commit-and-workflow/SKILL.md
+copy       .claude/skills/changelog-and-versioning/SKILL.md
+copy       .claude/skills/project-management-workflow/SKILL.md
+copy       .claude/skills/backend-security/SKILL.md
+copy       .claude/skills/api-design-rest/SKILL.md
+copy       .claude/skills/database-best-practices/SKILL.md
+copy       .claude/skills/backend-architecture-principles/SKILL.md
+copy-once  docs/adr/0000-template.md

package/docs/monorepo.md

@@ -0,0 +1,72 @@
+# Using agent-kit in a monorepo
+
+This is a guide only. agent-kit ships no monorepo configs, and the installer installs one preset per target directory. In a monorepo, install core (and packs) at the root, then add per-package pieces by hand or by running the installer per package with care.
+
+## Layout
+
+```
+/
+├── AGENTS.md                 # root rules: core block (+ web block), repo-wide tooling
+├── CLAUDE.md                 # @AGENTS.md
+├── MEMORY.md                 # one memory file, with a section per package
+├── .claude/
+│   ├── settings.json
+│   └── skills/               # shared skills (core, packs)
+├── packages/
+│   ├── web/
+│   │   ├── AGENTS.md         # package rules: stack, commands, package-only skills
+│   │   ├── CLAUDE.md         # @AGENTS.md (needed for Claude Code, see below)
+│   │   └── .claude/skills/   # optional: skills scoped to this package
+│   └── api/
+│       ├── AGENTS.md
+│       └── CLAUDE.md         # @AGENTS.md
+├── release-please-config.json
+└── .release-please-manifest.json
+```
+
+## Root vs nested AGENTS.md
+
+- Install core at the root: `install --target . --pack web --pack github`. The root `AGENTS.md` holds the universal rules and the shared skill index.
+- Give each package its own `AGENTS.md` with what differs there: the stack, exact commands (`npm test -w packages/web`, `pytest packages/api`), and package-only conventions. Say in the nested file that the root rules still apply.
+- **Claude Code: add a `CLAUDE.md` containing `@AGENTS.md` next to every nested `AGENTS.md`.** Because the kit installs a root `CLAUDE.md`, Claude Code by default reads `CLAUDE.md` files only and does not pick up `AGENTS.md` files directly, nested ones included. Subdirectory `CLAUDE.md` files load on demand, when Claude reads a file in that package. (Checked against the Claude Code memory docs, 2026-11-11. The alternative is the **Project instructions** setting `claude-md-and-agents-md`.)
+- Keep nested files short. Rules that apply everywhere belong at the root, and on-demand files over Claude Code's per-file size limit are truncated.
+
+## Presets per package
+
+Presets assume they own the repository root (for example `eslint.config.mjs`, `.husky/`, `.pre-commit-config.yaml`), and the installer refuses to combine presets that ship different versions of the same file. Options:
+
+- **One stack at the root.** If every package shares a stack (say, all TypeScript), install that preset at the root and use workspace-aware commands.
+- **Mixed stacks.** Install the dominant preset at the root, then port the other stack's configs into its package by hand, using the preset's `files/` folder as the reference (for example `ruff.toml` and `pytest.ini` into `packages/api/`). Git hooks are per repository, so pick one hook runner (husky or pre-commit) and call the other stack's checks from it.
+- Running `install --target packages/api --preset python` writes core files (skills, `MEMORY.md`, `AGENTS.md`) into the package too. That is usually not what you want. If you do it, delete the duplicated core files and keep only the preset's tooling and a nested `AGENTS.md`.
+
+## Skills
+
+- Shared skills live in the root `.claude/skills/`.
+- Package-specific skills (for example `react-principles` used only by `packages/web`) can live in `packages/web/.claude/skills/`, if your agent loads skills from nested folders. Otherwise keep them at the root, and list them in the root index with "Load when: working in packages/web".
+- `validate` checks the root `.claude/skills/` against the root `AGENTS.md`. It does not check nested skill folders.
+
+## One MEMORY.md, sections per package
+
+Keep a single root `MEMORY.md`, so agents read one file at session start. Add a short section per package (commands, gotchas, current state) and keep the 200-line budget. When a package's notes grow, move them to `docs/memory/<package>.md` and leave a one-line pointer (see the `agent-memory-protocol` skill, "Optional Scaling Pattern").
+
+## Releases per package
+
+release-please supports monorepos through `packages` in `release-please-config.json`:
+
+```json
+{
+  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
+  "include-component-in-tag": true,
+  "packages": {
+    "packages/web": { "release-type": "node", "component": "web" },
+    "packages/api": { "release-type": "python", "component": "api" }
+  }
+}
+```
+
+The `.release-please-manifest.json` then holds one version per path. Set `include-component-in-tag: true` (the presets use `false` for single-package repos), so tags become `web-v1.2.0`. Each package gets its own `CHANGELOG.md`. Use commit scopes or paths so release-please attributes changes to the right package: it decides by the files a commit touches. This is untested in this kit; check the release-please docs for your version.
+
+## Where managed blocks help
+
+- Use your own block ids in the root `AGENTS.md`, `.gitignore` or `.prettierignore` (for example `<!-- BEGIN agent-kit:pkg-web -->`), and keep a fragment per package in your repo. The markers keep generated sections apart from hand-written text, and `validate` checks that they stay paired and unique.
+- The installer manages only the block ids its manifests define. Your own ids are left alone, so re-running `install` at the root never touches them.

package/package.json

@@ -1,6 +1,52 @@
 {
   "name": "agents-md-kit",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0",
+  "description": "Installs AI-agent configuration (AGENTS.md, skills, memory, presets) into a repository. Dry run by default, never overwrites.",
+  "keywords": [
+    "agents-md",
+    "agents.md",
+    "claude-code",
+    "ai-agents",
+    "coding-agents",
+    "skills",
+    "scaffold",
+    "installer",
+    "conventional-commits"
+  ],
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "agents-md-kit": "bin/agent-kit.js"
+  },
+  "files": [
+    "bin/",
+    "src/",
+    "core/",
+    "packs/",
+    "presets/",
+    "docs/monorepo.md",
+    "README.md"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "scripts": {
+    "test": "node --test",
+    "validate:template": "node bin/agent-kit.js validate --template",
+    "typecheck": "tsc -p .",
+    "check": "npm run typecheck && npm test && npm run validate:template"
+  },
+  "devDependencies": {
+    "@types/node": "^26.6.6",
+    "typescript": "^7.0.2"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Rumpz/agents-md-kit.git"
+  },
+  "homepage": "https://github.com/Rumpz/agents-md-kit#readme",
+  "bugs": {
+    "url": "https://github.com/Rumpz/agents-md-kit/issues"
+  },
+  "author": "Rumpz"
+}

package/packs/github/files/.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,22 @@
+---
+name: Bug report
+about: Something is broken or behaves unexpectedly
+title: 'bug: '
+labels: bug
+---
+
+## What happened
+<!-- Describe the problem -->
+
+## Expected behavior
+
+## Steps to reproduce
+1.
+2.
+3.
+
+## Environment
+<!-- Browser / OS / app version / commit -->
+
+## Logs, screenshots, trace ID
+<!-- Remove any secrets or personal data -->

package/packs/github/files/.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Propose a new capability or improvement
+title: 'feat: '
+labels: enhancement
+---
+
+## Goal
+<!-- One sentence: the outcome for the user -->
+
+## Acceptance criteria
+- [ ]
+- [ ] Error and edge cases handled
+- [ ] Tests added
+
+## Out of scope
+-
+
+## Notes / dependencies
+-

package/packs/github/files/.github/pull_request_template.md

@@ -0,0 +1,24 @@
+<!--
+PR title must be a Conventional Commit, e.g. `feat(checkout): add idempotency key to payments`.
+With squash merges it becomes the commit message (and the release note if release-please is configured),
+so write it for the person reading the changelog.
+-->
+
+## Summary
+<!-- What changed and why -->
+
+## Changes
+-
+
+## Testing
+<!-- How you verified it: tests added, manual steps -->
+
+## Risks / Rollback
+<!-- Migrations, flags, breaking changes, how to revert -->
+
+## Checklist
+- [ ] PR title is a Conventional Commit written for the changelog reader
+- [ ] Tests added/updated and passing
+- [ ] Docs / OpenAPI / ADR / changelog updated (if needed)
+- [ ] Accessibility and SEO checked (user-facing pages, if applicable)
+- [ ] `MEMORY.md` updated (if new lasting knowledge)

package/packs/github/files/.github/workflows/pr-title.yml

@@ -0,0 +1,37 @@
+name: PR title
+
+# With squash merges the PR title becomes the commit message (and the release note
+# if release-please is configured), so it must be a valid Conventional Commit.
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened]
+
+permissions:
+  pull-requests: read
+
+jobs:
+  pr-title:
+    name: pr-title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          types: |
+            feat
+            fix
+            perf
+            refactor
+            docs
+            test
+            build
+            ci
+            style
+            chore
+            revert
+          requireScope: false
+          subjectPattern: ^(?![A-Z]).+$
+          subjectPatternError: |
+            The subject "{subject}" must start with a lowercase letter
+            (for example: "add passkey login", not "Add passkey login").

package/packs/github/manifest.txt

@@ -0,0 +1,6 @@
+# description: GitHub pack. PR and issue templates and the PR-title check. Also enables presets' GitHub CI (requires=github).
+
+copy  .github/pull_request_template.md
+copy  .github/ISSUE_TEMPLATE/bug_report.md
+copy  .github/ISSUE_TEMPLATE/feature_request.md
+copy  .github/workflows/pr-title.yml