| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
A project script dropped into .ai/scripts/ gets wiped on the next startup, because that dir syncs from the template with rsync --delete. There was no documented home for a project's own scripts, the script-side counterpart to .ai/project-workflows/.
I added .ai/project-scripts/ to the Directory Architecture table and noted in startup.org that it sits outside the synced set, like project-workflows/. A script a workflow imports lives there. Naming: a Python module imported via sys.path needs an importable name (underscores), while a CLI-invoked script can stay kebab-case like the template tooling.
No mechanism change. Startup Phase A only rsyncs protocols.org, workflows/, and scripts/, so project-scripts/ is already sync-safe. This just documents it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
daily-prep task
Walked all 14 open tasks. Re-stamped LAST_REVIEWED to 2026-05-26, dropped the past SCHEDULED dates from the research-writer and Skill-Seekers wait-for-trigger tasks, tagged the Makefile consolidation :quick:solo:, and refreshed the daily-prep delegation task to reflect the triage-intake engine/plugin split.
|
| |
|
|
|
|
| |
I default page notifications to --persist so a page that fires while I'm away from the desk waits for me instead of auto-dismissing after a few seconds.
page-me and status-check already persisted every page. I added --persist to the rest: the alarm, reminder, and meeting-alert examples in protocols.org, the long-running-process completion ping, and the cross-agent-watch message notification. I documented --persist as the default for any page meant to get attention, with a low-value informational ping as the only exception.
|
| |
|
|
|
|
|
|
| |
The triage-intake workflow had every source baked into one file, so adding or changing a source meant editing the workflow itself. I replaced it with a source-agnostic engine plus per-source plugins named triage-intake.<source>.org. The engine carries the anchor/sentinel logic, the four-bucket model, the Phase A-D orchestration, the todo.org persistence convention, and the exit criteria. Each source's scan, classify, render, and action knowledge moved into its own plugin.
Four general plugins ship in the template: personal-gmail, personal-calendar, cmail, and github-prs. Project-specific sources live in the project's .ai/project-workflows/ and are never synced. Phase 0 globs both directories so a project source can't silently drop out of the sweep.
I taught INDEX.org and the startup workflow-discovery drift check the namespace. A file matching <engine>.*.org is a plugin of that engine, not an orphan, and gets no trigger entry of its own. A "run the triage-intake workflow" request routes to the engine, never to a plugin.
|
| |
|
|
|
|
| |
send_file ran filenames through slugify(), which flattens dots to hyphens. That corrupts the engine.plugin.org plugin-namespace convention: triage-intake.personal-gmail.org arrived as triage-intake-personal-gmail.org, which breaks the engine's triage-intake.*.org glob and the routing that depends on the first dot.
I added slugify_filename() for filename stems. It keeps dots, hyphens, underscores, and case, collapses only whitespace runs to hyphens, and truncates on a separator boundary. The prose --text path still uses slugify().
|
| | |
|
| |
|
|
|
|
| |
The PostToolUse hook byte-compiles each saved .el with -L for the project root, modules/, and tests/, but not themes/. A theme file that requires a sibling under themes/ then fails byte-compile with "Cannot open load file", a false VALIDATION FAILED even though the file loads fine at runtime. I added -L themes/ to both the byte-compile and test-runner blocks.
Adding a load-path entry for a directory that doesn't exist is harmless to Emacs, so it stays unconditional, matching how modules/ and tests/ are already added without an existence guard.
|
| | |
|
| |
|
|
|
|
| |
Voice gains pattern #40: strip the "why" from praise on an approve, since the author already knows why their change is good and the justification reads as flattery. Always keep the why on a finding or change-request, delivered gently. Behavior only changes when the reason lands.
review-code now runs a praise/correction gate before posting any summary, and its inline-comment guidance is tightened so the why-it-matters survives the brevity cuts. The reviewer states the stakes (a user hits a 500, a screen reader announces nothing), not just the mechanism.
|
| |
|
|
|
|
| |
The bundle tracked .claude/rules, CLAUDE.md, and githooks/, ignoring only the personal overrides. For a code project, especially a third-party package checkout, the whole Claude footprint should stay local: install and sync deliver it, so it shouldn't land in the project's history. gitignore-add.txt now ignores .claude/, CLAUDE.md, and githooks/ next to the elisp build artifacts.
I also added install-lang.bats, which the bundle had no test for. It covers the landed footprint and the gitignore set.
|
| |
|
|
| |
Re-grade /research-writer to [#C] (deferred until a real research-writing task triggers it) and tag the two MCP tasks :solo:quick:. The rest confirmed as-is.
|
| |
|
|
| |
Both entries were non-actionable: a verbatim-marker false positive in a DONE task body, and a recurring staleness note now resolved by a review pass.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
The claude-memory clone was removed this session, so the todo entry's file: link to it would dangle — switched to plain text.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
I closed the memory-sync task. Memory now lives in a dedicated private claude-memory.git on cjennings.net, with each project's memory dir symlinked into a local clone so new memory lands in the working tree and a push syncs it. I settled on that over stow/dotfiles and over keeping it in rulesets, since rulesets sits on every session's startup-pull path and memory churn would dirty it. The task's dated entries carry the decision and the shipped details.
|
| |
|
|
| |
The .ai/ mirror lagged claude-templates/.ai/ for three workflows (task-audit, task-review, triage-intake) and two scripts (screenshot.py and its test) — earlier commits updated the canonical copies without resyncing the mirror in the same commit. The startup rsync caught it up; this commit tracks the result so the two stay identical.
|
| |
|
|
|
|
|
|
| |
These two workflows form a reviewer side and an author side for taking a design spec to implementation-ready. spec-review judges a spec against a readiness gate, reads the code before critiquing, evaluates across dimensions, assigns a rubric (Ready / Ready-with-caveats / Not-ready / Needs-research), and writes a <spec>-review.org file when it isn't ready. spec-response consumes that file: it decides accept / modify / reject for every recommendation, weaves the accepts into the spec body, records the modifies and rejects with reasons in a "Review dispositions" section, and reconciles tensions when coupled specs get reviewed together. The review file is the contract between them.
Both were validated by a real run on 2026-05-23 before landing here. I then reviewed them against established practice and tightened five things. The readiness gate now covers security/privacy and observability, since a spec shouldn't pass with those undefined. Phase 1 is a fast triage and Phase 3 is the authoritative gate after the code read. Finding severity maps to blocking power. A rejection goes back to the reviewer instead of standing as a unilateral call. And the response loop has an explicit termination condition.
I added both to INDEX.org under a new "Specs and design" section with trigger phrases, cross-linked as a pair, and kept the canonical and mirror copies identical.
|
| |
|
|
|
|
| |
The task-review and task-audit workflows already assess :quick:, an effort estimate. I added :solo: alongside it: a task Claude can finish end-to-end without Craig's input, gated on bounded scope, no design or preference call, and local verifiability.
In task-review.org I added a tagging subsection paralleling :quick:, a mention in the close-out summary, and a common-mistake entry against over-tagging. task-audit.org now re-assesses both tags during content reconciliation, since a resolved dependency can make a stuck task newly solo-able. It points at task-review.org for the definitions rather than restating them.
|
| |
|
|
| |
The mark-read step extracted message paths with mu --fields='p', but 'p' is the priority field (returns "normal"), not the path. Every path came back as "normal" and the flag manager errored on all of them. 'l' is the file-location field. Caught during a live triage on 2026-05-22.
|
| |
|
|
|
|
| |
The Linear/GitHub integration doesn't advance ticket state. Two chores merged today (SE-286, SE-399) sat in Dev Review until I moved them to Done by hand. I made the overlay say that plainly instead of implying the integration keeps tickets in sync.
I added the after-merge step the overlay was missing. A bug or feature with PM-reviewable functionality or UI goes to PM Acceptance, and a chore, test, or infra change the PM can't review goes straight to Done. I also dropped the two claims that the integration auto-cross-links, since the reliable cross-link is the PR-URL comment we already post on create.
|
| |
|
|
| |
Archived the session record. Moved six completed tasks from Open Work to Resolved: the 2026-05-04 audit-pass parent, the two commits.md overlay tasks, the make-remove feature, the mcp/ install-pipeline doc, and the wrap-it-up GitHub-host quick fix. Queued the one lint judgment and the task-review staleness note in the inbox for next-session processing.
|
| |
|
|
| |
Extended the posted-summary voice guidance: a re-review confirming requested changes is just "Approving" plus at most a bare positive. An approve summary must not carry a clause describing what the change does or why it works — that's the banned pattern, since the author already knows the rationale and restating it reads as padding.
|
| |
|
|
| |
Added more clichés to pattern #29 (keep it loose, touch base, circle up, hit the ground running, move the needle, on the same page, no-brainer, win-win, and others) and a note that a casual or conversational register isn't a license to keep one — cut it there too. Prompted by "keep it loose" slipping through as "acceptable casual," which is exactly the miss the note guards against.
|
| |
|
|
| |
A task audit reconciles each open task's recorded content against reality (sessions, email, chat, ticketing, calendar, recordings) and fixes the stale facts. That's distinct from task-review, which grooms relevance and priority. The two compose: review keeps the list lean, and audit keeps the survivors factually honest. Registered it in the workflow INDEX with its trigger phrases.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
mcp/ had install.py, servers.json, and the encrypted secrets bundle but no README, so the structure and the token-rotation flow were a re-discovery every few months. Added mcp/README.org covering the file layout (tracked vs gitignored), the secrets-bundle shape (plain ${VAR} secrets plus base64-bundled OAuth artifacts, AES256 symmetric encryption), the install flow (decrypt, materialize the OAuth keys and the Google Docs token caches at mode 600, expand placeholders, register the unregistered servers idempotently), the http/sse-vs-stdio transport split, the recovery steps when a Google refresh token is revoked, and how to add a server. Written against a read of the actual install.py and servers.json, not from memory.
|
| | |
|
| |
|
|
|
|
| |
make remove is the granular counterpart to make uninstall, which removes everything. remove.sh lists every rulesets-managed symlink under ~/.claude/ — only links whose target resolves into the repo, so foreign symlinks are left alone — pipes them through fzf --multi, and rm's the picked links. The repo's own files stay put, and make install re-creates anything removed.
It's split into --list and --remove-selected modes so the logic is testable without fzf. 5 bats cases cover the listing, the foreign-link exclusion, removal, report-and-continue on a missing target, and the empty no-op. The removal loop runs without set -e and without rm -f, so a vanished target reports visibly and the rest still process. shellcheck clean, make test green.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
screenshot.py
Extends screenshot.py with --launch CMD, which runs a command on a transient headless Hyprland output, captures it, and tears the output down, so a UI can be verified without touching the visible workspace. --layout (tiled/monocle/floating) and --size control placement: output resolution for tiled/monocle, window size plus centering for floating.
Refactors the testable logic (size parsing, geometry strings, window matching, the exec-rule body, centering) into pure helpers and adds test_screenshot.py covering them across normal, boundary, and error cases. The grim/hyprctl wrappers and the capture orchestration stay thin and are verified functionally.
|
| |
|
|
| |
Adds a grim + hyprctl wrapper so a session can capture the screen or a single window and read the resulting PNG, turning "does this look right?" into an inspectable artifact. Modes: --full (all outputs), --active (focused window), --window REGEX (matched against class or title), and --list to enumerate open windows. Output goes to a chosen path (default a timestamped file in /tmp) and the saved path is printed on stdout so the caller can read it back; the parent directory is created if it does not exist. Syncs into every project's .ai/scripts/ via the startup rsync.
|
| | |
|
| | |
|
| |
|
|
| |
Three audit fixes. Phase 1 gains a "Timebox the dialogue" rule, since one-question-at-a-time can run long: aim for the one-sentence restatement in roughly five to eight questions, then move to Phase 2 and park the rest as open questions. Phase 2 gains "Ground high-stakes claims in fresh sources" — check load-bearing claims about markets, regulations, tools, vendors, or current APIs against a current source, and mark what you couldn't verify as an assumption. The design-doc skeleton gains an Assumptions section that separates researched facts (with their source) from assumptions to confirm before building.
|
| | |
|
| |
|
|
|
|
|
|
| |
Two cleanups to the playwright skills, landed together since they overlap the same files.
The skills taught networkidle as the readiness check and leaned on raw page.click/fill/waitForSelector. Playwright discourages networkidle for readiness, so the guidance in both SKILL.md files now waits for a visible app landmark via a web assertion or locator, the login and form examples use getByLabel/getByRole plus expect, the API reference leads with that pattern, and lib/helpers.js defaults waitForPageReady to load (preferring a caller-supplied landmark) and races the success indicator in authenticate instead of waiting on networkidle.
The second cleanup strips emoji console markers across run.js, helpers.js, both SKILL.md files, and the py examples, replacing each with a plain ASCII tag like [ok], [error], or [scan]. node --check and py_compile pass, and an emoji grep comes back clean.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Two audit gaps in the confirmation hooks, plus the test harness they were missing.
The git-commit and gh-pr-create hooks scanned for AI attribution but only saw inline messages. A commit made with -F/--file or a PR made with --body-file slipped through, since the hook stored a placeholder instead of the file's text, and the publish flow uses -F constantly. A new read_referenced_file helper in _common.py reads the referenced local file (missing, oversized, or non-UTF-8 returns None, which means "couldn't inspect" and never "clean"), so attribution scanning now sees the real committed and posted text. An unreadable file falls through to the existing ask-anyway path.
destructive-bash-confirm.py parsed rm flags by splitting on whitespace, which mangled quoted paths and missed flag variants. detect_rm_rf now tokenizes with shlex, so quoted or spaced paths and combined, separate, or reordered flags all parse. It fails toward asking (a sentinel that still fires the modal) on unbalanced quotes, or when a forced recursive rm sits alongside a pipeline, compound command, substitution, or redirect, since target attribution isn't trustworthy there. The supported and unsupported shell constructs are documented in the docstrings.
These hooks had no tests and weren't in make test. Added a pytest harness under hooks/tests (an importlib-by-path loader, since the hook filenames are hyphenated) with 54 tests across the three hooks and the shared helper, and wired hooks/tests into make test. Full suite green.
|
| | |
|
| |
|
|
| |
The README's manual-install and settings-JSON snippets omitted destructive-bash-confirm.py, while the canonical hooks/settings-snippet.json already wires all three. Brought the README in line: added the opt-in symlink step, added the settings entry, and reworded the note so all three read as no-op-safe with the destructive gate flagged as opt-in (make install-hooks excludes it by default).
|
| | |
|
