@ervis/skills 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Ervis Zyka
+
+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/README.md

@@ -0,0 +1,335 @@
+# Ervis Zyka's Skills
+
+Agent skills I use day to day - engineering, productivity and research.
+
+Runtime-neutral: plain `SKILL.md` files with no harness-specific tool names, so
+they work on Claude Code, Codex, and anything else that speaks Agent Skills.
+The exception is the `incubator/` bucket: those skills require specific
+subagents and skills, and stop if one is missing (see [Incubator](#incubator)).
+
+## Skills
+
+### Engineering
+
+| Skill | What it does |
+|---|---|
+| [`commit`](./skills/engineering/commit) | Groups the session's changes into focused commits with clear messages, shows the plan, and commits only after you approve. Adds no agent attribution. |
+| [`ticket-grooming`](./skills/engineering/ticket-grooming) | Challenges a ticket until a coding agent could build it with zero open questions. Verifies the ticket's claims against the real code, then writes ranked blocking questions plus a rewritten dev-ready ticket. |
+
+### Productivity
+
+| Skill | What it does |
+|---|---|
+| [`brainstorm`](./skills/productivity/brainstorm) | Runs a structured brainstorm with a framework picked to fit: starbursting, QFT, question burst, pre-mortem, assumption mapping, 5 whys or six thinking hats. For scoping research it chains starbursting, pre-mortem and assumption mapping, then QFT. Saves the result to the vault under `brainstorm/`. |
+| [`caveman`](./skills/productivity/caveman) | Ultra-terse reply mode that cuts about 75% of tokens by dropping filler while keeping full technical accuracy. Stays on until you say "stop caveman" or "normal mode". |
+| [`simple-english`](./skills/productivity/simple-english) | Writes responses in ASD-STE100 Simplified Technical English: short sentences, active voice, one idea per sentence, simple words. |
+
+### Research
+
+Nothing here yet.
+
+### Incubator
+
+Skills being reworked. The QRSPI workflow lives here: eight skills, run one
+after the other on a task directory that holds all the files of one task.
+
+```
+task.md -> qrspi-question -> qrspi-research -> qrspi-research-resolve
+        -> qrspi-design -> qrspi-structure -> qrspi-plan -> qrspi-test-plan
+        -> qrspi-implement
+```
+
+The flow only moves forward. Each skill takes the task directory as its first
+argument, for example `qrspi-question ~/wiki/rate-limit`, and names the next
+skill when it is done. You write `task.md`; the skills write the rest.
+
+| Skill | What it does |
+|---|---|
+| [`qrspi-question`](./skills/incubator/qrspi-question) | Turns `task.md` into neutral research questions with the clean room method: it knows the goal, the researcher must not. Finds the affected areas and blind spots (same-shape features, producers and consumers, cascades), asks a fixed set of facets per area, and leak-tests the result. The number of questions comes from coverage, not a quota. |
+| [`qrspi-research`](./skills/incubator/qrspi-research) | Answers `questions.md` blind, with facts only: every finding cites `file:line` or a URL. Writes `research-draft.md`. You can add a missing question before it hands off. |
+| [`qrspi-research-resolve`](./skills/incubator/qrspi-research-resolve) | Grades each answer. Only when an answer is weak, contradictory or open does it interview you; you answer or skip each gap. Writes the final `research.md`. Research is done after this step. |
+| [`qrspi-design`](./skills/incubator/qrspi-design) | Interviews you on the design decisions with the research as evidence, and writes `design.md`. Prefers patterns the code already uses and marks each decision as existing (with the `file:line` that already does it) or new (with the reason). Groups the current state into invariants, assumptions, cascades, dependents and lifecycle. |
+| [`qrspi-structure`](./skills/incubator/qrspi-structure) | Breaks the design into vertical slices, each with its files, key signatures and a check, plus the invariants and dependents it touches. Writes `structure.md`. |
+| [`qrspi-plan`](./skills/incubator/qrspi-plan) | Expands each slice into exact changes, code snippets where they are not obvious, and checks with checkboxes. Writes `plan.md`, which an agent can work from alone. |
+| [`qrspi-test-plan`](./skills/incubator/qrspi-test-plan) | Writes the black-box test cases, in plain words, that guard the scope and the design: one goal case per slice, and exhaustive Given / When / Then cases at each public interface (anything a client depends on, behavior and data). Reads the design and the slices, not `plan.md`, so the tests check the code independently. Lists the expected contract changes, so implement can tell an expected failure from a bug. Writes `test-plan.md`; implement writes the tests from it. |
+| [`qrspi-implement`](./skills/incubator/qrspi-implement) | Works through `plan.md` one slice at a time, and writes the code and the tests for the test cases of `test-plan.md`: a slice is done when its checks and its tests pass. Ticks checkboxes, makes one commit per slice, and changes an existing test only for a listed contract change. Asks you only for the checks by hand. |
+
+These skills require:
+
+- `simple-english` from this package.
+- The subagents `codebase-locator`, `codebase-analyzer`, `codebase-pattern-finder`
+  and `web-search-researcher` from [`agents/`](./agents). They are Claude Code
+  only and are not in the npm package: install them with
+  `./scripts/link-skills.sh` (see [Local dev](#local-dev)).
+- `grilling` from [Matt Pocock's skills](#complementary-skills), for the
+  interviews in `qrspi-research-resolve` and `qrspi-design`.
+
+## Install
+
+For a new laptop. One command, no clone, no npm account.
+
+### Prerequisites
+
+- Node.js 18 or newer and npm (`node --version`, `npm --version`). Any current
+  Node install includes `npx`.
+- No npm account or login: the package is public.
+
+### Install the skills
+
+```bash
+npx @ervis/skills@latest
+```
+
+`@latest` makes npx fetch the newest release instead of reusing an old cached
+one. The installer copies every skill into two places:
+
+| Directory | Read by |
+|---|---|
+| `~/.claude/skills` | Claude Code |
+| `~/.agents/skills` | Codex and other Agent Skills harnesses |
+
+Each skill lands as a plain directory named after the skill, for example
+`~/.claude/skills/ticket-grooming`, with a `.ervis-skills` marker file inside.
+The marker is how a later run knows the copy is its own.
+
+To see what it would do first, without touching anything:
+
+```bash
+npx @ervis/skills@latest --dry-run
+```
+
+### Complementary skills
+
+[Matt Pocock's skills](https://github.com/mattpocock/skills) cover engineering
+workflows this package does not - TDD, diagnosing bugs, resolving merge
+conflicts, domain modelling - and are worth installing alongside this package
+rather than instead of it:
+
+```bash
+npx skills@latest add mattpocock/skills
+```
+
+The installer lets you pick which skills to take and which agents to install
+them on. This writes them into your repo as plain files, the same way
+`@ervis/skills` does, so both sets stay editable and neither manages the other.
+
+### Flags
+
+| Flag | Effect |
+|---|---|
+| `--dry-run` | Print what would be installed or updated, change nothing. |
+| `--target <dir>` | Install into `<dir>` instead of the two defaults. Repeatable. |
+| `--force` | Also replace a skill that was not installed by this tool. |
+| `-h`, `--help` | Show usage. |
+
+Overwrite behavior is deliberately conservative:
+
+- A skill this tool installed earlier (it has the marker) is replaced in place.
+  The new copy is built next to the old one and swapped in, so a failed update
+  leaves the old skill intact.
+- A skill directory or symlink that already exists without the marker - your own
+  skill of the same name, or a link from the local dev path below - is skipped,
+  with a message. Pass `--force` to replace it.
+- Other skills in the target directories are never touched.
+
+### Verify it worked
+
+```bash
+ls ~/.claude/skills ~/.agents/skills
+find ~/.claude/skills ~/.agents/skills -maxdepth 2 -name .ervis-skills
+```
+
+The first lists the installed skills, the second lists the marker of every copy
+managed by this tool. Then start a new agent session: skills are read at session
+start, so an already-running session will not see them.
+
+### Update
+
+Run the same command again:
+
+```bash
+npx @ervis/skills@latest
+```
+
+Managed copies are reported as `updated`. Nothing updates in the background.
+
+### Uninstall
+
+There is no uninstall flag. Remove the managed copies, which are exactly the
+directories that contain the marker:
+
+```bash
+find ~/.claude/skills ~/.agents/skills -maxdepth 2 -name .ervis-skills -exec dirname {} \; | while read -r d; do rm -r "$d"; done
+```
+
+Run it without `rm -r "$d"` (use `echo "$d"`) first if you want to review the
+list. Skills you installed some other way have no marker and are left alone.
+
+### Troubleshooting
+
+- **A skill says `skipped ... not installed by ervis-skills`.** A directory or
+  symlink with that name already exists and was not put there by this tool.
+  Move it away, or re-run with `--force` to replace it.
+- **Permission denied.** The target directory is not writable by your user.
+  Check ownership with `ls -ld ~/.claude/skills ~/.agents/skills`, fix it, or
+  install somewhere you own with `--target`. Do not use `sudo`: it would leave
+  root-owned files in your home directory.
+- **You keep getting an old version.** npx caches packages. Always use
+  `@latest`; if it still looks stale, clear the cache with
+  `npm cache clean --force` and run again.
+- **Errors mentioning `node:fs`, `cpSync` or a syntax error.** Your Node is too
+  old. Upgrade to 18 or newer (`node --version` to check).
+- **Duplicate skill name error.** Two skills in the package share a directory
+  name. That is a packaging bug; report it rather than working around it.
+- **`404` or `E404` for `@ervis/skills`.** The package has not been published
+  yet, or the name is mistyped.
+
+### Local dev
+
+For working on this repo itself. Symlinks instead of copies, so `git pull` is all
+it takes to stay current:
+
+```bash
+./scripts/link-skills.sh
+```
+
+It links every skill into `~/.claude/skills` and `~/.agents/skills`, and every
+subagent (`agents/<name>/AGENT.md`) into `~/.claude/agents/<name>.md`. Agents
+are Claude Code only and are not part of the npm package. Do not
+combine it with the npm install for the same skills: the installer skips the
+links unless you pass `--force`, and `--force` replaces them with copies. To go
+back, delete the links (`rm ~/.claude/skills/<skill-name>`).
+
+## Layout
+
+```
+skills/<bucket>/<skill-name>/SKILL.md
+```
+
+Buckets are `engineering/`, `productivity/`, `research/` and `incubator/` - see
+[`skills/README.md`](./skills/README.md) for what belongs where. They are for
+humans reading the repo and appear nowhere in how a skill is addressed: the
+skill name comes from its own directory.
+
+Subagents live beside `skills/` at `agents/<name>/AGENT.md`.
+
+## Working on the skills
+
+```bash
+./scripts/list-skills.sh    # every SKILL.md in the repo
+./scripts/check-skills.sh   # frontmatter and name/dir match
+./scripts/link-skills.sh    # install locally as symlinks
+./scripts/setup-skills.sh    # install Matt's and these skills with npm
+```
+
+`setup-skills.sh` installs Matt Pocock's published skills (with
+`npx skills add mattpocock/skills`) and the skills of this checkout (with
+`bin/install.js`, the `@ervis/skills` installer). `--agent=` picks where:
+`claude` (the default) installs into `~/.claude/skills`, `codex` (or
+`chatgpt`) into `~/.agents/skills`, and `--agent=claude,codex` does both. For
+`claude` it first uninstalls the `mattpocock-skills` Claude Code plugin, so the
+same skills do not load twice. Matt's skills that are already there are left alone. The
+`@ervis/skills` installer updates its own earlier copies and skips anything
+else. `--force` installs everything again over what is there.
+
+Run `check-skills.sh` before pushing. It catches the failures that are silent
+and annoying to debug later: a skill whose frontmatter `name` drifted from its
+directory, or a skill with missing frontmatter.
+
+### Adding a skill to the package
+
+1. Create `skills/<bucket>/<name>/SKILL.md` (the name must match the directory,
+   and be unique across buckets).
+2. `./scripts/check-skills.sh`
+3. `npm pack --dry-run` and confirm the new `SKILL.md` is in the list. There is
+   no manifest to edit: the package ships everything under `skills/` except
+   `deprecated/`, `in-progress/` and `draft/`.
+4. Add a row to the skills table above, then release (see Publish).
+
+## Publish
+
+For the maintainer. The package is `@ervis/skills`, public, published to
+npmjs.com. Agents and CI never run `npm login` or `npm publish`.
+
+> **Publishing is public and hard to undo.** Every shipped skill becomes
+> world-readable on the npm registry, even while the GitHub repo is private.
+> npm restricts unpublishing (as a rule only a recent release with no
+> dependents can be removed) and a published version number can never be
+> reused. Treat every publish as permanent: inspect the tarball first.
+
+### One-time setup
+
+1. Create or confirm the npm account `ervis` at npmjs.com and verify its email.
+2. Turn on two-factor authentication in the account settings on npmjs.com. Use
+   the "authorization and writes" level so publishing asks for a code.
+3. Log in from your terminal and confirm who you are:
+
+   ```bash
+   npm login
+   npm whoami    # should print: ervis
+   ```
+
+4. The scope `@ervis` is your username, so it is yours automatically. Access is
+   already `public` via `publishConfig` in `package.json`; scoped packages
+   default to private without it, and the first publish would otherwise fail.
+
+### Release a version
+
+1. Get on a clean, up-to-date branch with the changes merged.
+2. Bump the version. npm refuses to republish a version, so every release needs
+   a new one:
+
+   ```bash
+   npm version patch --no-git-tag-version   # or minor / major
+   ```
+
+   Commit the `package.json` change with a message that says what changed.
+   `CHANGELOG.md` is generated, so do not edit it by hand: the commit messages
+   and PR title are the release note.
+3. Inspect what will ship:
+
+   ```bash
+   npm pack --dry-run                         # file list and sizes
+   npm pack && tar tzf ervis-skills-*.tgz     # the actual tarball contents
+   ```
+
+   It should hold only `bin/`, `skills/` (no `deprecated/`, `in-progress/` or `draft/`),
+   `package.json`, `README.md` and `LICENSE`. Delete the `.tgz` afterwards.
+4. Try the tarball the way a new laptop would, in a throwaway home:
+
+   ```bash
+   HOME=$(mktemp -d) npx ./ervis-skills-<version>.tgz
+   ```
+
+5. Run the release script:
+
+   ```bash
+   ./scripts/release.sh --dry-run   # stops after the checks and pack
+   ./scripts/release.sh             # same, then asks y/N before publishing
+   ```
+
+   It runs, in order: `./scripts/check-skills.sh`, `npm pack --dry-run`, a
+   `Publish @ervis/skills@<version>? [y/N]` prompt, then `npm publish`.
+   Anything but `y` aborts.
+
+### Verify after publishing
+
+```bash
+npm view @ervis/skills version
+HOME=$(mktemp -d) npx @ervis/skills@latest
+```
+
+The first should print the version you just released; the second installs into
+an empty home, exactly like a new laptop. Registry caches can lag by a minute or
+two, so retry before assuming it failed.
+
+### Publish a fix
+
+A published version is frozen. Fix the problem on a branch, merge it, bump the
+version again (`npm version patch --no-git-tag-version`), and run the release
+script. If a release is actively harmful, `npm deprecate @ervis/skills@<version>
+"<reason>"` warns everyone who installs it without removing it.
+
+## Licence
+
+MIT

package/bin/install.js

@@ -0,0 +1,135 @@
+#!/usr/bin/env node
+'use strict';
+
+// Copies every published skill into the skill directories each agent harness
+// reads. Dependency-free on purpose: `npx @ervis/skills` has to work on a fresh
+// laptop with nothing but Node.
+
+const fs = require('node:fs');
+const os = require('node:os');
+const path = require('node:path');
+
+const PKG_ROOT = path.resolve(__dirname, '..');
+const SKILLS_ROOT = path.join(PKG_ROOT, 'skills');
+const MARKER = '.ervis-skills';
+const SKIP_BUCKETS = new Set(['deprecated', 'in-progress', 'draft']);
+const DEFAULT_TARGETS = [
+  path.join(os.homedir(), '.claude', 'skills'),
+  path.join(os.homedir(), '.agents', 'skills'),
+];
+
+const USAGE = `Usage: ervis-skills [options]
+
+Installs Ervis Zyka's agent skills into ~/.claude/skills and ~/.agents/skills.
+Re-run it any time to update; copies it made earlier are replaced in place.
+
+Options:
+  --target <dir>  Install into <dir> instead of the defaults (repeatable)
+  --dry-run       Print what would happen and change nothing
+  --force         Also replace skills it did not install (real dirs, symlinks)
+  -h, --help      Show this help
+`;
+
+function parseArgs(argv) {
+  const opts = { targets: [], dryRun: false, force: false };
+  for (let i = 0; i < argv.length; i++) {
+    const a = argv[i];
+    if (a === '--dry-run') opts.dryRun = true;
+    else if (a === '--force') opts.force = true;
+    else if (a === '-h' || a === '--help') opts.help = true;
+    else if (a === '--target') {
+      const v = argv[++i];
+      if (!v) throw new Error('--target needs a directory');
+      opts.targets.push(path.resolve(v));
+    } else if (a.startsWith('--target=')) {
+      opts.targets.push(path.resolve(a.slice('--target='.length)));
+    } else throw new Error(`unknown option: ${a}`);
+  }
+  if (opts.targets.length === 0) opts.targets = DEFAULT_TARGETS;
+  return opts;
+}
+
+function findSkills(dir, out = []) {
+  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
+    if (!entry.isDirectory() || entry.name === 'node_modules') continue;
+    if (SKIP_BUCKETS.has(entry.name)) continue;
+    const full = path.join(dir, entry.name);
+    if (fs.existsSync(path.join(full, 'SKILL.md'))) out.push({ name: entry.name, src: full });
+    else findSkills(full, out);
+  }
+  return out;
+}
+
+function lstatOrNull(p) {
+  try {
+    return fs.lstatSync(p);
+  } catch (e) {
+    if (e.code === 'ENOENT') return null;
+    throw e;
+  }
+}
+
+function install(skill, targetDir, opts) {
+  const dest = path.join(targetDir, skill.name);
+  const st = lstatOrNull(dest);
+  let action = 'install';
+  if (st) {
+    const ours = st.isDirectory() && fs.existsSync(path.join(dest, MARKER));
+    if (!ours && !opts.force) {
+      return `skipped   ${dest} (not installed by ervis-skills; use --force to replace)`;
+    }
+    action = 'update';
+  }
+  if (opts.dryRun) return `would ${action}   ${dest}`;
+  fs.mkdirSync(targetDir, { recursive: true });
+  const staging = fs.mkdtempSync(path.join(targetDir, `.${skill.name}-`));
+  const backup = `${staging}.old`;
+  try {
+    fs.cpSync(skill.src, staging, { recursive: true });
+    fs.writeFileSync(path.join(staging, MARKER), 'Managed by @ervis/skills; re-run the installer to update.\n');
+    if (st) fs.renameSync(dest, backup);
+    try {
+      fs.renameSync(staging, dest);
+    } catch (e) {
+      if (st) fs.renameSync(backup, dest);
+      throw e;
+    }
+    if (st) fs.rmSync(backup, { recursive: true, force: true });
+  } finally {
+    fs.rmSync(staging, { recursive: true, force: true });
+  }
+  return `${action === 'install' ? 'installed' : 'updated'}`.padEnd(10) + dest;
+}
+
+function main() {
+  let opts;
+  try {
+    opts = parseArgs(process.argv.slice(2));
+  } catch (e) {
+    process.stderr.write(`error: ${e.message}\n\n${USAGE}`);
+    return 2;
+  }
+  if (opts.help) {
+    process.stdout.write(USAGE);
+    return 0;
+  }
+  const skills = findSkills(SKILLS_ROOT);
+  if (skills.length === 0) {
+    process.stderr.write(`error: no skills found under ${SKILLS_ROOT}\n`);
+    return 1;
+  }
+  const seen = new Map();
+  for (const skill of skills) {
+    if (seen.has(skill.name)) {
+      process.stderr.write(`error: duplicate skill name "${skill.name}": ${seen.get(skill.name)} and ${skill.src}\n`);
+      return 1;
+    }
+    seen.set(skill.name, skill.src);
+  }
+  for (const targetDir of opts.targets) {
+    for (const skill of skills) console.log(install(skill, targetDir, opts));
+  }
+  return 0;
+}
+
+process.exitCode = main();

package/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "@ervis/skills",
+  "version": "0.1.0",
+  "description": "Ervis Zyka's agent skills - engineering, productivity and research. Runtime-neutral: Claude Code, Codex and any Agent Skills harness.",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/ervis/skills.git"
+  },
+  "license": "MIT",
+  "keywords": [
+    "agent-skills",
+    "claude-code",
+    "codex",
+    "skills"
+  ],
+  "bin": {
+    "ervis-skills": "bin/install.js"
+  },
+  "files": [
+    "bin/",
+    "skills/",
+    "!skills/**/deprecated/",
+    "!skills/**/in-progress/",
+    "!skills/draft/",
+    "!skills/**/node_modules/"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "link": "./scripts/link-skills.sh",
+    "list": "./scripts/list-skills.sh",
+    "check": "./scripts/check-skills.sh",
+    "release": "./scripts/release.sh"
+  }
+}

package/skills/README.md

@@ -0,0 +1,18 @@
+# Skills
+
+One directory per skill, grouped into buckets.
+
+| Bucket | What belongs here |
+|---|---|
+| `engineering/` | Working on code and the artefacts around it: specs, tickets, reviews, debugging, design, tests. |
+| `productivity/` | Working on your own thinking and output: writing, planning, handoffs, learning, communication. |
+| `research/` | Finding things out and recording them: investigating sources, exploring unfamiliar codebases, capturing what was found. |
+| `incubator/` | Skills being reworked, such as the QRSPI workflow. Validated and published like any other bucket. |
+| `draft/` | Unfinished imports, not validated and not published. See `AGENTS.md` for how to graduate one. |
+
+Buckets are for humans reading the repo. They do not appear in how a skill is
+addressed - a skill is addressed by its name, which comes from its own
+directory.
+
+If a skill genuinely fits two buckets, put it where you would go looking for it,
+not where it is most technically correct.

package/skills/engineering/commit/SKILL.md

@@ -0,0 +1,47 @@
+---
+description: Create git commits with user approval and no Claude attribution
+name: commit
+---
+
+# Commit Changes
+
+If the `simple-english` skill is available, follow it for everything you write for the user.
+
+You are tasked with creating git commits for the changes made during this session.
+
+## Process:
+
+1. **Think about what changed:**
+   - Review the conversation history and understand what was accomplished
+   - Run `git status` to see current changes
+   - Run `git diff` to understand the modifications
+   - Consider whether changes should be one commit or multiple logical commits
+
+2. **Plan your commit(s):**
+   - Identify which files belong together
+   - Draft clear, descriptive commit messages
+   - Use imperative mood in commit messages
+   - Focus on why the changes were made, not just what
+
+3. **Present your plan to the user:**
+   - List the files you plan to add for each commit
+   - Show the commit message(s) you'll use
+   - Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
+
+4. **Execute upon confirmation:**
+   - Use `git add` with specific files (never use `-A` or `.`)
+   - Create commits with your planned messages
+   - Show the result with `git log --oneline -n [number]`
+
+## Important:
+- **NEVER add co-author information or Claude attribution**
+- Commits should be authored solely by the user
+- Do not include any "Generated with Claude" messages
+- Do not add "Co-Authored-By" lines
+- Write commit messages as if the user wrote them
+
+## Remember:
+- You have the full context of what was done in this session
+- Group related changes together
+- Keep commits focused and atomic when possible
+- The user trusts your judgment - they asked you to commit

package/skills/engineering/implement-ruby/template.md

@@ -0,0 +1,75 @@
+# Implementer agent template
+
+Use this shape for any agent that takes a finished design and writes code.
+Copy it and replace every `<placeholder>`.
+
+Keep the agent file short. It holds the role, precedence, boundaries and handback.
+Long style rules and exemplar files live in separate files it links to, so they
+can change without rewriting the agent.
+
+---
+
+```markdown
+---
+name: <role-name>
+description: <what it does and when to use it, in one or two sentences, including the phrasings a user would type>
+tools: <only what it needs>
+model: <model>
+---
+
+# Role
+
+<One paragraph. Who the agent is and what it does.>
+It implements the design it is given. It does not design.
+
+# Input contract
+
+- Accepts: <design doc path, ticket, or spec with class and method sketches>.
+- If the input is missing, ambiguous or incomplete, list the gaps and stop.
+  Do not invent design.
+
+# Precedence
+
+When rules conflict, follow them in this order:
+
+1. The repo's own conventions (linter config, AGENTS.md, existing code).
+2. The global house style below.
+3. Language and framework defaults.
+
+# Style
+
+- Enforced by tools: <linter config that is the source of truth>.
+- Judgment rules the linter cannot check: <naming, method shape, structure>.
+  One line each.
+- Exemplars to imitate: <paths to 5 to 10 real files>.
+
+# Working loop
+
+1. Read the whole design.
+2. Detect the project type and read the repo's conventions.
+3. List gaps. Stop if any of them block the work.
+4. Implement in small steps, writing tests with the code.
+5. Run tests and linter. Fix until both are green.
+
+# Boundaries
+
+- Never design, widen scope, or refactor code the design does not mention.
+- Never open a PR or merge.
+- Never silence a linter rule to make it pass.
+
+# Handback
+
+Report back with:
+
+- Files changed, one line each.
+- Commands run and their results.
+- Style conflicts flagged (design vs style, repo vs global).
+- Gaps and assumptions.
+- Anything left undone, and why.
+
+# Stop and ask when
+
+- The design is ambiguous about behavior.
+- A change would touch code outside the design.
+- Tests or linter cannot go green without changing the design.
+```