| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Numbered choice lists put the recommended option at item 1 so the common case collapses to one keystroke. Skip when the question is free-form, when a directive's already been issued, or when no option is clearly better. Say so plainly in that case.
|
| |
|
|
|
|
| |
The no-popup-menus rule in interaction.md was too easy to forget, so the popup kept slipping back into choice prompts. I added a PreToolUse hook on AskUserQuestion that denies the call outright and returns the rule as the reason, which routes choices back to inline numbered lists. Since ~/.claude/settings.json symlinks to this repo's .claude/settings.json, the hook is machine-wide and version-controlled across machines.
I documented it under the rule in interaction.md, including the consequence: the deny is unconditional, so the old "use the popup for this one" exception now needs the hook disabled via /hooks first.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fragments, formatting
The personal voice patterns only ran for commits and PRs, so the emails and documents I author never got my actual writing voice. General mode deliberately skips them. I added a third mode, prose, that applies my voice patterns to prose I write or send without dragging in the publish-artifact mechanics that misfire on free text.
The modes now nest. General (#1-31) handles anyone's prose, prose adds my voice patterns (em-dash zero-tolerance, contractions, semicolons to periods, sentence-split, felt-experience cut, fragment rewrite, terse-cut, no-emphasis-formatting), and personal adds the three artifact-mechanics patterns on top (first-person rewrite, public-artifact scope flag, praise/correction asymmetry). Those three stay personal-only because they assume a commit or PR: a document is legitimately third-person, a journal has no public-scope concern, and praise/correction asymmetry is a PR-review rule.
Three gaps closed along the way. #13 (em-dash) was "use fewer". It's now zero-tolerance in prose and personal modes, and the rule holds inside examples and quoted text, not just running prose. #37 (every prose sentence needs a subject and a verb) was locked to personal mode. It now applies to my prose too. And #41 is new: I make points with words, not bold or italics or underscores, so emphasis markup gets rephrased so the stress lives in the wording.
I updated commits.md to match. The publish flow still uses personal mode, but the pattern count is now 41 and the personal-only set is the three artifact-mechanics patterns.
|
| |
|
|
|
|
| |
Craig's terminal renders Markdown bold and inline-code spans as reverse video, which is hard to read. I added a rule to interaction.md: in conversational output, write command names, paths, and key chords as plain text, and lean on headers, dashes, parentheses, and quotes for structure. It governs chat output only, not the Markdown source of the rule and spec files he reads in an editor.
I also made the keybinding-display example plain text so the convention shows the format the way it should appear in chat, with a pointer to the new rule.
|
| |
|
|
| |
I added a rule for how to present a keymap's bindings when asked to show them. The format is a bulleted list grouped by prefix level: a General header at the top that lists the sub-prefixes leading into each category, then one section per category. Every bullet carries the full chord, the bound command, and the which-key label, so the written view matches what which-key shows on screen.
|
| |
|
|
| |
When a verification gap needs the user's hands or eyes — interactive UI a script can't drive, a live service, visual rendering — describing the steps in prose isn't enough. I added a section to verification.md that says to write them as a "Manual testing and validation" task: one sub-header per test, each with a descriptive title, what we're verifying, the steps as a bullet list, and the expected result. If a test fails, the user writes the actual behavior, flips the header to a TODO, and promotes it, so a failed check becomes a tracked bug in one step.
|
| |
|
|
| |
Adds claude-rules/emacs.md documenting how to push a module edit into the long-running emacs daemon via emacsclient instead of restarting and re-opening files. Covers the reliable case (function redefinition), the caveats that bite (defvar defaults don't re-apply, use-package :config re-runs, faces need re-applying, baked or rendered state like the dashboard buffer must be regenerated), and the reload-and-verify loop. Captured after a long dashboard session where a stale buffer repeatedly masked working code.
|
| |
|
|
| |
The publish flow made the /voice pass mandatory but had no fallback for when the skill isn't installed, which a fresh or partial environment can hit. Added one to the Single-skill gate: when /voice can't run, walk the patterns inline (the flow already names which matter), state the skill was unavailable and the pass was applied by hand, and flag the missing skill for install. The gate is the pattern walk, not the tooling — the skill is just the convenient way to run it. The original audit framed this as a "humanizer unavailable" gap. Humanizer is /voice now, so only the /voice-unavailable case remained.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The global commits.md carried DeepSat-specific publishing steps — Linear ticket-state moves, the Slack notification protocol with its channel ID and engineer names, the deepsat.ghe.com host, the team merge norm. Those are symlinked into every project on the machine, so they sat as dead weight in personal repos and risked misfiring where there's no Linear ticket to move or Slack mpdm to ping.
I split them out. commits.md keeps the universal skeleton (identity, attribution, commit format, the review-and-publish gate, verification) and replaces the team steps with seams: "run the project's publishing overlay here if it defines one," the same pattern startup.org uses for startup-extras. A project with no overlay runs the complete flow, just without ticket and chat integration.
The DeepSat specifics move to teams/deepsat/claude/rules/publishing.md. That file is not a global rule — install-team.sh copies it into one project's .claude/rules/ (make install-team TEAM=deepsat PROJECT=...), keyed on the PROJECT argument, so only the named project gets it. Location decides distribution: claude-rules/ is the global-symlink set, teams/ is targeted-copy, so the overlay reaches DeepSat and nowhere else.
The startup freshness check (sync-language-bundle.sh) now covers team overlays alongside language bundles: a process_bundle function handles both, with a team syncing only its own rule (no generic rules, hooks, or settings — those belong to a language bundle). A drifted overlay rule auto-fixes from canonical at the project's next startup, the same mechanism language bundles already ride.
Tested: 3 new bats cases (team overlay clean / drifted-and-fixed / does-not-pull-generic-rules) on top of the 11 existing; install-team + sync verified end-to-end against a temp project. make test green, shellcheck clean.
|
| |
|
|
| |
subagents.md assumed the Agent tool exists. A new "Pre-Dispatch Checks" section adds two gates before any spawn: Availability (no Agent capability means do the work in the main thread under the same scope and constraints the contract would enforce) and Cost (when writing the full contract costs more than the task, do it inline). Both cross-reference the existing "Don't Subagent At All" guidance rather than duplicating it.
|
| |
|
|
| |
Two additions. An "Escalation Beyond Category and Pairwise" section adds property-based testing (for invariants across a broad input domain) and mutation testing (for when high coverage hides thin assertions), both as escalation paths rather than always-on gates. And the "I need to spike first" excuse is formalized into a disciplined spike protocol: TDD stays the default, but a spike is sanctioned only when timeboxed, not committed, and followed by the first failing test before productionizing.
|
| |
|
|
| |
verification.md required running tests/lint/typecheck/build before claiming done, but said nothing about what to do when a command can't run. A new "When You Cannot Verify" section requires a four-part report (command attempted, why it couldn't run, risk left unverified, and the smallest next command for the user) and states the principle that a check that didn't run is never reported as a pass.
|
| |
|
|
|
|
| |
The .ai/-tracking check used to decide two things at once: which voice patterns ran and whether the approval gate fired. In a team repo that meant losing the 8 personal patterns and the gate together. I split them. Publish artifacts (commit messages, PR titles and bodies, PR review comments) always run /voice personal now, because they go out under my name regardless of the repo. The .ai/ check decides only the gate: applied in my personal repos, skipped for velocity in shared ones.
The gap this closes: a team-repo PR comment used to skip pattern #39, the public-artifact scope flag, which is exactly the check that matters most when teammates can read it.
|
| |
|
|
|
|
| |
review-code was a command with disable-model-invocation set, so the model could never reach for it on its own. Every time a review fit the moment, the agent had to hand back to me to type the slash command. Moving it to a skill makes it model-invocable while it stays slash-invocable as /review-code.
git mv keeps the file history (99% rename). The frontmatter drops disable-model-invocation and gains name: review-code; the body is unchanged. It also drops the discovery-check paragraph in commits.md, which only existed to find the command on disk when it was missing from the skills list, moot now that the skill shows up there.
|
| |
|
|
|
|
|
|
| |
Adds claude-rules/triggers.md as the home for phrases the user says from any cwd to invoke a cross-project action. First entry: "launch project X" → run the ai script in single-project mode targeting the matched basename. Ambiguity handling: list candidates and ask rather than guess.
The trigger phrases already in protocols.org ("Let's run the [X] workflow", "Wrap it up") are project-scoped. They assume an active .ai/ session. Cross-project launchers don't fit that layer; they need to work from any cwd, including outside any project. None of the existing claude-rules files (commits.md, testing.md, verification.md, subagents.md, interaction.md, cross-project.md, todo-format.md) had a clean fit either. A new file is the smallest architectural change.
Makefile picks up new claude-rules/*.md files via wildcard, so no Makefile change needed. make install created the symlink at ~/.claude/rules/triggers.md; make doctor reports 39/0/0.
|
| |
|
|
|
|
| |
I added claude-rules/working-files.md as the canonical convention. In-progress task artifacts live in working/<task-slug>/ under the project root. On task completion the files get renamed individually with a YYYY-MM-DD-<slug>-<descriptor> shape and moved flat into assets/ (or the area-specific assets/). Never rename the directory as a substitute for filing, since that loses the flat-searchable property of assets/.
claude-templates/.ai/protocols.org gained a short reference to the rule so it propagates to every project's .ai/protocols.org on the next startup rsync.
|
| |
|
|
|
|
|
|
| |
Step 1 told the agent to run /review-code but didn't say what to do when the skill exists on disk yet isn't in the session's available-skills list. The list covers plugin-installed skills only. User commands under ~/.claude/commands/ are routable as slash-commands but don't appear in it, so the agent could declare /review-code unavailable and fall through to the trivial-one-liner exception in Step 2.
The new Discovery check tells the agent to verify both ~/.claude/commands/review-code.md and ./.claude/commands/review-code.md on disk before declaring the skill unavailable, and surface the mismatch rather than auto-skipping.
Also drops three absorbed or stale inbox files: the skill-discovery handoff (signal absorbed by this edit), the missing-inbox-dir handoff (already resolved by 470085f), and a stale date-coverage scan output (deferred until the task-review habit lands).
|
| |
|
|
| |
The MCP's `conversations_add_message` tool takes the raw mrkdwn body in `payload`, not a Slack API JSON envelope. Wrapping the body in `{"text": "..."}` posts the literal JSON to the channel — `<@>` mention strips, escaped `\n` renders as a literal `n`, and the `text:` key prefix shows up in the post. Step 8 now documents the format + mrkdwn list so PR-review notifications don't garble.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Todo-format.md gets a "Completion — depth-based" section that
codifies what was implicit before: top-level (* and **) DONE tasks
stay task-shaped (DONE + CLOSED line), sub-tasks (*** and deeper)
flip to dated event-log entries, and VERIFY is the documented
exception (always dated-rewrite regardless of depth). The section
includes worked examples and the rationale for depth-based over
keyword-based.
The cj-comments skill's completion section now references the
canonical rule instead of restating the depth-based rules inline.
The three-bullet recap in the skill stays as a quick scan, but the
details and examples live in one place.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cross-project boundary rule already prescribes dropping a handoff
file in the target project's inbox/ when option 1 ("do it from here")
is chosen. The change adds a paragraph pointing at the new inbox-send
script as the preferred tool for the drop. The script handles project
discovery, source-project provenance in the filename, slug derivation,
and timestamping in one call, replacing the hand-constructed filenames
and guessed project paths the rule used to require.
Filename convention is unchanged
(YYYY-MM-DD-HHMM-from-<source>-<slug>.<ext>); the script just generates
it instead of me typing it out. Fallback to Write/Edit is documented
for cases where the script isn't installed (e.g. a freshly-cloned
project before the first startup-rsync).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rounds of simplification on the cj-comments skill: converged on
source-block-only in org files, dropped the non-org parsing entirely,
factored out the mechanical parts into helper scripts (added separately
in another repo), and codified the VERIFY placement + completion rules
in a canonical rule file so the conventions stop being implicit.
Skill (.claude/commands/respond-to-cj-comments.md):
- Drop the file-type comment-marker table and the non-org multi-line
continuation rule. The skill now recognizes only the org source-block
form (#+begin_src cj: ... #+end_src). Craig's yasnippet keeps typing
cost flat.
- Defensive parsing for legacy inline cj annotations in older org files
(back-compat).
- Prefer the new helper scripts: step 1 calls cj-scan for structured
detection; step 4 sub-step 6 calls cj-remove-block for validated
removal. Both have explicit fallback paths to grep+Read / Edit.
- Completion rules now split by keyword: TODO/DOING at *,** stay
task-shaped (DONE + CLOSED); deeper TODO/DOING flip to dated headings;
VERIFY at any depth flips to a dated heading with body replacement.
- New VERIFY-answer pattern: when a cj's parent_heading_chain ends with
VERIFY, the cj is the answer to that VERIFY. Lift its body into the
dated rewrite (or execute the instruction first if indirect), then
delete the cj.
- New placement rule for new VERIFYs: sibling of the trigger heading,
not a child. Climb to *** when the trigger is buried at ****+. This
is the active force that keeps todo.org flat.
- Rename "cj: comment" to "cj comment" in prose; preserve the literal
cj: token in code examples and grep targets.
Canonical rule (claude-rules/todo-format.md):
- New "VERIFY tasks" section with four subsections: Placement (** or
*** only), Creating a new VERIFY (sibling of trigger), Completion
(dated rewrite + body replacement at any depth), Don't leave stale
placeholders.
- Worked before/after examples for both top-level and first-level
VERIFYs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
New `claude-rules/cross-project.md` codifies the per-project `.ai/` scope
boundary. Stop-and-ask when a request targets another project's files,
inline numbered options, handoff-file convention when the user opts to
do it from here.
`/respond-to-cj-comments` gains a section-0 preflight (boundary check
before reading the target file) and a section-7 handoff step (writes
the carry-forward file in the target project's `inbox/` when the
boundary crossing was approved).
|
| |
|
|
| |
Step 8 of the publish flow referenced C0AM2MWHCJU as the channel for the Slack PR-author ping. That ID is actually a 3-person mpdm (Craig/Vrezh/Kostya), not the intended 4-person PR-review group. Corrected to C0B1B0NH2N5 (Craig/Eric/Vrezh/Kostya) and added a clarifying note that the 3-person mpdm is not an "#ai" channel despite older references calling it that.
|
| |
|
|
|
|
|
|
| |
The publish flow had no fetch step before commit, PR creation, or push. Long sessions or multi-machine work could land local commits on a stale base, producing non-fast-forward push failures that you have to unwind under publish-step pressure.
Step 0 fetches all remotes and checks the current branch against its upstream before Step 1's code review. If the branch is behind, the rule branches on tree state and divergence shape: clean fast-forward, surface dirty-tree behind, or surface a true divergence and ask before rebasing or merging. The Step 0 wording covers the new-branch case (no upstream → skip the divergence check, the first push sets it).
The Pre-push reconcile bullet in Merge Strategy handles the smaller window between Step 0 and the actual push. Reviewing and drafting can take several minutes; another machine or teammate can push during that window. One more fetch immediately before push is cheaper than recovering after a failed push.
|
| |
|
|
|
|
| |
Codify the rule that AskUserQuestion's popup menu obscures the chat text the user needs to read to make the choice. Choice prompts go inline as numbered options instead, with a "pick a number" prompt at the end.
Applies to all three approval gates in commits.md (commit message, PR description, PR review reply).
|
| |
|
|
|
|
|
|
| |
The detection command for personal vs. general voice mode used `git ls-files .ai/`, which returns no matches when run from a subdirectory of the repo, even when `.ai/` is tracked at the root. That silently misclassified projects as personal-voice when they should have been general-voice.
Switching to `git ls-files :/.ai/` anchors the search to the repo root via the `:/` pathspec, so the command works correctly from any cwd.
I hit this myself today: ran the check from `claude-rules/` inside the rulesets repo, got an empty result, and applied `/voice personal` to a commit that should have used `/voice` (general mode).
|
| |
|
|
|
|
|
|
| |
I rewrote the PR review subflow into three explicit shapes. Shape 1 is a single review that bundles the verdict, the summary body, and zero or more inline pins into one `gh api .../reviews` call. Shape 2 is an issue-thread comment with no verdict. Shape 3 is a reply on an existing inline thread. The single-review path replaces the prior pattern where a Request-Changes verdict with line-specific findings needed separate `gh pr review` + `gh pr comment` calls. That fragmented the Slack notification and the review history.
I migrated all `humanizer` references to `/voice personal`. The voice skill replaced humanizer, so the old name was dead. I dropped the two lineage mentions of "humanizer's signs of AI writing" since they pointed at a skill that no longer exists.
I added a Voice mode and approval gate preamble at the top of Step 2. The mode is decided by whether `.ai/` is tracked in the repo. Gitignored or absent means personal-voice with the full approval gate. Tracked means general-voice and the gate is skipped, since the personal-only patterns (first-person rewrite, contractions, semicolon swap) don't fit a shared rules file. I also updated the Single-skill gate wrap-up paragraph at the end of Step 2 to reference both modes.
|
| |
|
|
|
|
|
|
|
|
| |
I switched the three publish subflows in commits.md (commit messages, PR descriptions, PR review comments) from "run humanizer; apply five personal-style passes in order" to a single "run /voice personal" invocation. The new skill walks 39 patterns in one editorial review and absorbs the five passes wholesale, plus four more personal-style additions (felt-experience cut, fragment-in-prose rewrite, terse cut, public-artifact scope flag) and six universal good-writing patterns. The numbered steps in each subflow collapse from 5 to 4 (commits) and 9 to 8 (PRs) since the dedicated personal-style step folds into the voice invocation.
The Multi-pass gate paragraph becomes a Single-skill gate. The mid-flow "all the passes" prompt now means re-run the full 39-pattern walk in personal mode rather than reapplying six discrete steps.
I also updated respond-to-cj-comments.md to invoke /voice personal for public writing and /voice general for the lighter pass on internal notes when wanted, and updated start-work.md's Phase 7 summary to match.
The humanizer skill itself stays in place for now. The next commit removes it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I told Claude that the commit-message draft should sound personal, like it's coming from me. That move wasn't in the documented passes, so the drafts kept landing on impersonal third-person ("Add a test for X", "The change introduces Y"). I had to ask for the rewrite each time.
First person is now the new pass (a) in all three subflows: commit messages, PR descriptions, PR review comments. The subject line and PR title stay imperative per Conventional Commits, and I left an exception for purely mechanical bodies where the subject already carries the message. I bumped the Multi-pass gate counts and the example announcement string to match.
|
| |
|
|
|
|
|
|
| |
Step 8 of the PR review/publish flow now sends a one-line message to channel C0AM2MWHCJU after every approve or changes-requested verdict. The new step skips humanizer and personal-style passes since the message is short and templated.
The approve case sends "Approved on PR #N." with the PR URL on the next line. The changes-requested case sends "Changes Requested on PR #N" with the PR URL on the next line.
I also added an explicit line saying approve doesn't authorize a merge. That keeps the merge decision with the PR author. The team's practice is approve-then-author-merges, not approve-and-merge.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I reworked commits.md with two structural shifts and five smaller rule changes.
Structural:
- Drafts print inline in the terminal. `emacsclient` only opens when asked. Was: editor by default, humanize after.
- Adopted the full Conventional Commits spec. New sections: Structure, Types, Scope, Breaking changes (`!` and `BREAKING CHANGE:` footer), Subject line, Body, Footers, How to write, Examples.
Smaller:
- Personal-tooling files (`claude-rules/*.md`, any `CLAUDE.md`, `.claude/`, `.ai/`, `SKILL.md`) aren't cited as authority in shared messages. State the reason, not the rule. Carve-out for when one of these files IS the change.
- Voice and Focus opens with a colleague-tone framing. Four anti-patterns called out below it: no felt-experience narration, no verb-as-noun ("the ask", "a learn"), no sentence fragments in prose, and no first-person "I" for software behavior — all caught real drafting tics today. "Brief. Terse is fine." also tightened to "Brief. Terse is preferred."
- Future-debugger framing added to message-writing guidance. Imperative summaries beat diary notes, and the body becomes a lightweight decision log of the constraint or tradeoff.
- PR titles end with the ticket ID in parens, e.g. `refactor: drop dead check (SE-289)`.
- Multi-pass gate tightened to match the new mandatory ordering.
|
| |
|
|
|
|
|
|
| |
The original phrasing leaned on Lisp terms (let-bind, defvar) that don't
translate to most other languages. Generalize to two named failure modes
(infinite recursion against the mocked primitive, scope-shadowing that
production callers can't see) with examples across Python, Lisp, Go, and
JavaScript so the rule applies regardless of stack.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
safety
commits.md gets two additions. A new "## Merge Strategy" section makes
squash-merge the default for feature branches and requires explicit
confirmation of the merge approach before pushing or merging. A new
"Multi-pass gate" paragraph in Review and Publish requires every
humanizer-flow pass to run and be named when declaring done, so
silent skips become defects.
testing.md gets a new bullet under "### Determinism": time/clock-mocking
helpers must not recurse against the primitive they're mocking, and must
not let-bind over a defvar — the binding shadows only inside the test
scope, so production code reading the symbol still gets the original
value (silent test miss).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skills
Linear ticket bodies are now Problem + Fix only. PR descriptions keep
the four-section format (Problem, Fix, Why this fixes it, How it was
tested). Linear's GitHub integration handles the cross-link via the
PR body's Linear: line.
Cross-ref to the content-scope rule appended at the end of each Tier 1
skill that produces public artifacts: testing.md, arch-document,
arch-decide, arch-design, review-code, respond-to-review, brainstorm,
codify. Single-source the rule in commits.md, point at it from each
output-producing skill.
|
| |
|
|
|
|
|
|
| |
PR descriptions, Linear ticket bodies, and PR review comments are
visible to the team. New section codifies what not to mention (local
paths, private repos, personal tooling) and a concise four-section
structure for shipped-fix descriptions: Problem, Fix, Why this fixes
it, How it was tested.
|
| |
|
|
|
|
|
|
|
| |
Adds step 7 to the Review-and-Publish PR-description flow: pass
--reviewer at create time or use gh pr edit --add-reviewer right
after. Notes that CODEOWNERS auto-suggestions aren't requests, that
picking reviewers should follow the team's per-repo convention, and
that follow-up PRs benefit from tagging the parent PR's author.
Renumbers the Linear-comment and Dev-Review status steps accordingly.
|
| |
|
|
|
|
|
|
| |
Three new paragraphs under "Voice and Focus": first person where it fits, brief/terse, kind. The section now applies to PR comments (review replies, follow-up notes, thread responses) as well as commit bodies and PR descriptions.
New "For PR review comments and replies" subsection under Step 2 mirrors the commit-message and PR-description flows: draft to /tmp/pr-<N>-comment.md, humanizer skill, plain-English pass, user approval, then post with the right gh command for the comment type.
The trivial-one-liner exception at the bottom of Step 2 now covers acknowledgment-style replies ("thanks for the review") alongside trivial commits.
|
| |
|
|
|
|
| |
Added a new Voice and Focus section between Commit Message Format and Review and Publish. It covers three rules that kept coming up in practice. Write in the user's voice — first person fits, and "This PR introduces X" reads as press-release self-narration. Focus on what was wrong and what was corrected, not the mechanics. Don't stack three or more type signatures or API names in a single sentence.
Also extended the post-humanizer checklist in both the commit-message and PR-description flows. Items (c) "prefer contractions" and (d) "break up long sentences" now sit alongside the existing (a) "rewrite dev-jargon" and (b) "replace semicolons". Uncontracted English reads stiff in short prose, and stacked-clause sentences read easier split on a conjunction.
|
| |
|
|
|
|
|
|
|
|
| |
Three additions to claude-rules/commits.md.
A new conventions section adds two rules. First, do not hard-wrap commit body lines. Let the renderer soft-wrap instead. Hard wraps shrink the visible width in web UIs and cause awkward mid-sentence breaks. Second, do not reference how the change was produced (code review, linting, test runs) in the message. The body is for the what and the why. The how belongs in the PR discussion.
A new Review and Publish section defines a two-step gate for every commit and PR. Step 1 runs /review-code against the change and blocks on Critical or Important findings unless the user overrides. Step 2 drafts the message to /tmp, opens it in the user's editor, runs the humanizer skill, and waits for explicit approval before committing or pushing. PRs also require a Linear cross-link line, a Linear comment with the PR URL after creation, and a status transition to Dev Review.
A short hook-level authorization note clarifies that the review-plus-approval flow is the authorization gate. Tools like git-commit-confirm should not add a second independent prompt once Step 2 has been approved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cross-cutting rule covering subagent hygiene:
- Decision table: parallel-safe (read-only investigation, independent
test failures, multi-domain research) vs sequential-with-review
(plan execution, coupled edits) vs never-parallel (concurrent writes)
vs don't-subagent-at-all (target known, work fits in ~10 tool calls).
- Prompt contract: scope / pasted context / explicit 'do NOT' list /
required output format. Missing any field yields shallow work.
- Context-pollution rule: subagents absorb noise the main thread
shouldn't carry. When one fails, dispatch a fix-agent with the
failure report — do not retry in the orchestrator.
- Review-gate cadence: after each sequential task, or every ~3 in
parallel batches.
- Anti-patterns including parallel implementation on overlapping
files, broad 'fix all the tests' prompts, timeout-tuning to mask
flakes, and letting the agent decide scope.
Added one-line cross-references to subagents.md from debug/,
review-code/, and finish-branch/ SKILL.md — the skills that most
rely on delegation.
Clean-room synthesis from NeoLabHQ/context-engineering-kit's
subagent-driven-development pattern (MIT).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
existing testing skills
Forked verbatim from omkamal/pypict-claude-skill (MIT). LICENSE preserved.
Renamed from `pict-test-designer` to `pairwise-tests` — technique-first
naming so users invoking "pairwise" or "combinatorial" find it; PICT
remains the tool under the hood.
Bundle (skill-runtime only):
pairwise-tests/SKILL.md (renamed, description rewritten)
pairwise-tests/LICENSE (MIT, preserved)
pairwise-tests/references/pict_syntax.md
pairwise-tests/references/examples.md
pairwise-tests/scripts/pict_helper.py (Python CLI for model gen / output fmt)
pairwise-tests/scripts/README.md
Upstream's repo-level docs (README, QUICKSTART, CONTRIBUTING, etc.) and
`examples/` dir (ATM + gearbox walkthroughs — useful as reading, not as
skill-runtime) omitted from the fork. Attribution footer added.
Cross-references so /add-tests naturally routes to /pairwise-tests when
warranted:
- add-tests/SKILL.md Phase 2 step 8: if a function in scope has 3+ parameters
each taking multiple values, surface `/pairwise-tests` to the user before
proposing normal category coverage. Default continues with /add-tests;
user picks pairwise explicitly.
- claude-rules/testing.md: new "Combinatorial Coverage" section after the
Normal/Boundary/Error categories. Explains when pairwise wins, when to
skip (regulated / provably exhaustive contexts, ≤2 parameters, non-
parametric testing), and points at /pairwise-tests.
- languages/python/claude/rules/python-testing.md: new "Pairwise /
Combinatorial for Parameter-Heavy Functions" subsection under the
parametrize guidance. Explains the pytest workflow: /pairwise-tests
generates the matrix, paste into pytest parametrize block, or use
pypict helper directly.
Mechanism note: cross-references are judgment-based — Claude reads the
nudges in add-tests/testing/python-testing and acts on them when appropriate,
not automatic dispatch. Craig can still invoke /pairwise-tests directly when
he already knows he wants combinatorial coverage.
Makefile SKILLS extended; make install symlinks /pairwise-tests globally.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additions to claude-rules/testing.md:
- Testing pyramid proportions (70-80% unit / 15-25% integration / 5-10% e2e)
- Integration Tests section: docstring must name 'Components integrated:'
and mark real vs mocked; when-to-write heuristics
- Signs of Overmocking: 'would the test pass if the function body was
NotImplementedError?' plus three more sharp questions
- Testing Code That Uses Frameworks: test your integration, not the
framework itself
- Test Real Code, Not Copies: never inline prod code into tests
- Error Behavior, Not Error Text: test type + key values, not exact prose
- If Tests Are Hard to Write, Refactor the Code: hard-to-test is a code
signal, not a test signal; extract focused helpers
- Anti-patterns list extended
Addition to languages/elisp/claude/rules/elisp-testing.md:
- Interactive vs Internal split pattern: cj/foo wraps cj/--foo; test the
internal directly, skip UI mocks
Source: ~/.emacs.d/ai-prompts/quality-engineer.org (personal reference,
kept as an extended prompt separate from these rules).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
New generic rule at claude-rules/commits.md covers author identity,
absence of Claude/Anthropic/LLM/AI attribution (messages, PRs,
comments, trailers, emojis), and conventional commit format. Applies
to all repos.
Bundle settings.json now sets attribution.commit: "" and
attribution.pr: "" so Claude Code's default attribution is suppressed
belt-and-suspenders with the written rule.
Elisp CLAUDE.md template trimmed to reference commits.md instead of
inlining the rules.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
claude-rules/testing.md is now language-agnostic (TDD principles, test
categories, coverage targets, anti-patterns). Scope header widened to
**/*. Python-specific content (pytest, fixtures, parametrize, anyio,
Django DB testing) moved to languages/python/claude/rules/python-testing.md.
Added languages/python/ bundle (rules only so far; no CLAUDE.md template
or hooks yet — Python validation tooling differs from Elisp). Added
install-python shortcut to the Makefile.
Updated scripts/install-lang.sh to copy claude-rules/*.md into each
target project's .claude/rules/. Bundles no longer need to carry their
own verification.md copy — deleted languages/elisp/claude/rules/verification.md.
Single source of truth in claude-rules/, fans out via install.
Elisp-testing.md now references testing.md as its base (matches the
python-testing.md pattern).
|
|
|
Skills (adapted from DeepSat, stripped of project-specific references):
- /review-pr: PR review against engineering standards
- /fix-issue: issue-to-merge TDD workflow
- /security-check: secrets, OWASP, and dependency audit
- /debug: systematic 4-phase debugging
- /add-tests: test coverage analysis and generation
- /respond-to-review: evaluate and implement code review feedback
Rules (general-purpose, copied as-is):
- testing.md: universal TDD standards and anti-patterns
- verification.md: proof over assumption
Makefile updated to install both skills and rules via symlinks.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
