Sync skills and rules from ~/.cursor

Author: j0ntz

.cursor/rules/typescript-standards.mdc

@@ -73,7 +73,7 @@ Exception: Empty handlers are acceptable ONLY when the rejection is an expected
 <standard id="extract-helpers">Extract reusable helpers for common boilerplate patterns (e.g., "run at most once in parallel").</standard>
 
 <standard id="precompute-outside-loops">Avoid calling expensive transformation functions (like `normalizeForSearch`, `toLowerCase`) inside loops when the input doesn't change per iteration. Pre-compute outside the loop.
-❌ `items.filter(item => searchTerms.every(term => normalize(item![1770928879881](image/typescript-standards/1770928879881.png)![1770928886532](image/typescript-standards/1770928886532.png).name).includes(term)))`
+❌ `items.filter(item => searchTerms.every(term => normalize(item.name).includes(term)))`
 ✅ `items.filter(item => { const n = normalize(item.name); return searchTerms.every(term => n.includes(term)) })`
 </standard>
 

.cursor/rules/workflow-halt-on-error.mdc

@@ -5,9 +5,11 @@ alwaysApply: true
 
 <rules description="Non-negotiable constraints.">
 
+<rule id="cursor-workflow-paths">All workflow-related skill definitions (`*.md` / `SKILL.md`) and workflow companion scripts (`*.sh`) are sourced from `~/.cursor/`. When executing skills, prefer explicit `~/.cursor/...` paths and do not assume repo-local workflow files unless the skill explicitly points to one.</rule>
+
 <rule id="skill-script-path-resolution">When a skill mentions a script path, resolve it under `~/.cursor/skills/<skill>/scripts/` unless the skill explicitly specifies an absolute path elsewhere. Do not assume repo-relative `scripts/` paths without verifying the skill directory contents.</rule>
 
-<rule id="halt-on-error">When ANY shell command fails (non-zero exit code) during a workflow:
+<rule id="halt-on-error">When ANY shell command fails (non-zero exit code) during a workflow (except where explicitly allowed by `auto-fix-verification-failures` or `companion-script-nonzero-contracts`):
 1. **STOP** — do not retry, work around, substitute, or continue the workflow.
 2. **Report** — show the user the exact command, exit code, and error output.
 3. **Diagnose** — classify the failure: missing tool (`command not found`), wrong path, permissions, or logic error.
@@ -47,6 +49,19 @@ Never auto-fix:
 - Any failure requiring destructive operations or workflow bypasses
 </rule>
 
+<rule id="companion-script-nonzero-contracts">Respect documented companion script exit-code contracts. Non-zero does NOT always mean fatal.
+
+For `~/.cursor/skills/im/scripts/lint-warnings.sh`:
+- `0` = no warnings
+- `1` = warnings found (expected actionable state)
+- `2` = execution error (fatal)
+
+Required behavior:
+1. If exit `1`, continue workflow by fixing warnings before implementation.
+2. If warnings exist, commit warning fixes in a separate lint-fix commit immediately before feature commits.
+3. If exit `2`, apply `halt-on-error`.
+</rule>
+
 <rule id="no-silent-substitution">Do NOT silently substitute an alternative tool or approach when a command fails. If `rg` is not found, do not fall back to `grep`. If a script exits non-zero, do not manually replicate what the script does. The failure is the signal — report it.</rule>
 
 </rules>

.cursor/scripts/pr-watch.sh

@@ -64,7 +64,7 @@ while true; do
   NOW=$(date '+%H:%M:%S')
 
   # Parse recommended interval from script output
-  RECOMMENDED=$(echo "$OUTPUT" | grep -oP '(?<=^# interval:)\d+' || echo "")
+  RECOMMENDED=$(echo "$OUTPUT" | sed -n 's/^# interval:\([0-9][0-9]*\)/\1/p' | head -n 1)
 
   # Determine actual sleep interval
   if [[ -n "$INTERVAL" ]]; then

.cursor/scripts/push-env-key.sh

@@ -1,7 +1,7 @@
 ---
 name: asana-task-update
 description: Update Asana tasks via one reusable workflow (attach PRs, assign/unassign, set status, and update task fields). Use when any skill needs to modify Asana task state.
-compatibility: Requires jq. ASANA_TOKEN for Asana API updates. ASANA_GITHUB_SECRET for PR attach operations.
+compatibility: Requires jq. ASANA_TOKEN for Asana API updates. ASANA_GITHUB_SECRET for PR attach operations (obtain via https://github.integrations.asana.plus/auth?domainId=ghactions).
 metadata:
   author: j0ntz
 ---
@@ -11,7 +11,7 @@ metadata:
 <rules description="Non-negotiable constraints.">
 <rule id="use-companion-script">Use `~/.cursor/skills/asana-task-update/scripts/asana-task-update.sh` for all Asana task mutations. Do not call raw Asana APIs directly from skills that can delegate here.</rule>
 <rule id="task-required">Every operation requires `--task <task_gid>`.</rule>
-<rule id="attach-requires-secret">`--attach-pr` requires `ASANA_GITHUB_SECRET`. Other operations require `ASANA_TOKEN`.</rule>
+<rule id="attach-requires-secret">`--attach-pr` requires `ASANA_GITHUB_SECRET` (obtain via OAuth: https://github.integrations.asana.plus/auth?domainId=ghactions). Other operations require `ASANA_TOKEN`.</rule>
 <rule id="prompt-codes">If the script exits code 2 with `PROMPT_REVIEWER` or `PROMPT_IMPLEMENTOR`, ask the user and re-run with explicit `--reviewer` or `--implementor`.</rule>
 <rule id="script-timeouts">Asana updates can take time. Use `block_until_ms: 120000` for script calls.</rule>
 </rules>

.cursor/skills/asana-task-update/SKILL.md

@@ -69,6 +69,7 @@ fi
 
 if $DO_ATTACH && [[ -z "${ASANA_GITHUB_SECRET:-}" ]]; then
   echo "Error: ASANA_GITHUB_SECRET not set (required for --attach-pr)" >&2
+  echo "Obtain via OAuth: https://github.integrations.asana.plus/auth?domainId=ghactions" >&2
   exit 1
 fi
 
@@ -90,6 +91,7 @@ status_to_gid() {
     "Review Needed") echo "$REVIEW_NEEDED_OPTION" ;;
     "Publish Needed") echo "$PUBLISH_NEEDED_OPTION" ;;
     "Verification Needed") echo "$VERIFICATION_NEEDED_OPTION" ;;
+    # Passthrough: accepts raw GIDs from callers like asana-create-dep-task.sh
     *) echo "$1" ;;
   esac
 }

.cursor/skills/asana-task-update/scripts/asana-task-update.sh

@@ -16,7 +16,9 @@ metadata:
 </rules>
 
 <step id="1" name="Extract conversation data">
-Run the companion script on the user-provided export file:
+If no chat export file is provided, assume the user is asking for a chat audit of the current chat session.
+
+If chat export file is provided, run the companion script on the user-provided export file:
 
 ```bash
 scripts/cursor-chat-extract.js <export-file> --tools-only

.cursor/skills/chat-audit/SKILL.md

@@ -9,6 +9,7 @@ metadata:
 <goal>Sync cursor files between `~/.cursor/` and the `edge-conventions` repo, commit, push, and update PR description from README. Also maintains cross-tool compatibility: symlinks `~/.claude/skills` → `~/.cursor/skills` and generates `~/.claude/CLAUDE.md` from always-apply rules.</goal>
 
 <rules>
+<rule id="local-is-canonical">`~/.cursor/` is the canonical source. Edits happen locally; the repo is the distribution copy. Default direction is `user-to-repo`. Use `--repo-to-user` only for onboarding or pulling changes authored by others. The script does not detect bidirectional conflicts — whichever direction you run overwrites the other side.</rule>
 <rule id="use-companion-script">Use `scripts/convention-sync.sh` for diffing and syncing. Do NOT manually diff or copy files.</rule>
 <rule id="dry-run-first">Always run without `--stage` first to show the summary. Only stage/commit after user confirms.</rule>
 <rule id="no-script-bypass">If the script fails, report the error and STOP.</rule>

.cursor/skills/convention-sync/SKILL.md

@@ -5,6 +5,10 @@
 # outputs a structured JSON summary of new, modified, and deleted files.
 # With --stage: copies changed files and stages them in git (or copies to user dir with --repo-to-user).
 # With --commit: stages + commits (requires -m). Only valid for user-to-repo direction.
+#
+# Sync model: ~/.cursor/ is canonical. Default direction (user-to-repo) copies local
+# files into the repo. --repo-to-user is for onboarding or pulling others' changes.
+# No bidirectional conflict detection — the chosen direction overwrites the other side.
 
 set -euo pipefail
 

.cursor/skills/convention-sync/scripts/convention-sync.sh

@@ -11,12 +11,12 @@ metadata:
 <rules description="Non-negotiable constraints.">
 <rule id="read-coding-standards">Before writing ANY code, read `.cursor/rules/typescript-standards.mdc` and follow all rules and standards in it throughout the implementation.</rule>
 <rule id="no-impl-before-confirm">Do NOT begin implementation until the user confirms the `/asana-plan` output (Step 0).</rule>
-<rule id="lint-before-change">Before the first edit to ANY file, run `scripts/lint-warnings.sh <files...>` to check for warnings AND load matching fix patterns into context. If warnings exist, fix them in a separate commit IMMEDIATELY BEFORE the commit with actual changes. This applies to every file you touch, including ones discovered mid-implementation — not just the files you planned upfront.</rule>
+<rule id="lint-before-change">Before the first edit to ANY file, run `~/.cursor/skills/im/scripts/lint-warnings.sh <files...>` to check for warnings AND load matching fix patterns into context. If warnings exist, fix them in a separate commit IMMEDIATELY BEFORE the commit with actual changes. This applies to every file you touch, including ones discovered mid-implementation — not just the files you planned upfront.</rule>
 <rule id="no-manual-formatting">Do not manually fix formatting. `lint-commit.sh` runs `eslint --fix` (which includes Prettier) before committing. If you see a formatting lint after editing, do NOT make another edit to fix it.</rule>
 <rule id="commit-script">Always commit using `~/.cursor/skills/lint-commit.sh -m "message" [files...]` or `--fixup <hash>` for fixup commits.</rule>
 <rule id="clean-history">The final commit history must read as a clean, straight-line progression — as if every decision was made correctly up front. Never preserve the "squiggly path" of development (adding then removing code, temporary scaffolding, exploratory commits). If you introduce something in commit A and remove it in commit B, restructure so the final history never contains it. Plan commits proactively to avoid this; when it happens anyway, restructure the branch before finishing.</rule>
 <rule id="no-script-bypass">If a companion script fails, report the error and STOP. Do NOT fall back to raw `gh`, `curl`, or other workarounds.</rule>
-<rule id="script-timeouts">`asana-get-context.sh` can take up to 90s. Always set `block_until_ms: 120000` when invoking it to avoid unnecessary backgrounding and polling.</rule>
+<rule id="script-timeouts">`asana-get-context.sh` can take up to 90s and `install-deps.sh` can exceed 10s on repo prepare steps. Always use at least a 120000ms timeout for these scripts to avoid false failures from client-side time limits.</rule>
 </rules>
 
 <step id="0" name="Planning handoff via /asana-plan">
@@ -34,7 +34,7 @@ If the task describes a regression (e.g. "broke in version X", "stopped working
 1. **Identify the breaking commit** using `git log`, `git bisect`, or version tag comparison. Don't take the reported version from the task at face value — verify by examining the actual commit history.
 2. **Review the original change's full intent.** Find the associated PR and any linked tasks/discussions. The regression-causing commit likely had legitimate goals (performance, refactoring, new features). Understand ALL of its intended effects, not just the one that broke.
 3. **Ensure the fix preserves the original intent.** The fix must not undo the beneficial changes introduced by the regression commit. If the fix conflicts with the original intent, flag this to the user with tradeoffs before proceeding.
-</step>
+   </step>
 
 <step id="1" name="Branch setup">
 After Step 0 determines the target repo (or if no Asana task, use the current repo):
@@ -47,7 +47,7 @@ After Step 0 determines the target repo (or if no Asana task, use the current re
    - **On the correct feature branch**: Continue.
 3. **Branch naming**: `$GIT_BRANCH_PREFIX/<short-description>` or `$GIT_BRANCH_PREFIX/fix/<short-description>` for bug fixes. Use kebab-case. Example: `<prefix>/some-feature` or `<prefix>/fix/some-bug`
 4. **Assume a new branch is needed** unless the current branch clearly matches the task. Do NOT ask for confirmation — the existing branch has its own committed work and is unaffected.
-5. **Install dependencies**: After creating or switching to the feature branch, run `~/.cursor/skills/install-deps.sh` to ensure dependencies match the base branch state.
+5. **Install dependencies**: After creating or switching to the feature branch, run `~/.cursor/skills/install-deps.sh` with a timeout of at least 120000ms to ensure dependencies match the base branch state without false timeout failures.
 
 If the task spans multiple repos, note the additional repos but implement in the primary repo first.
 </step>
@@ -56,15 +56,17 @@ If the task spans multiple repos, note the additional repos but implement in the
 **Before writing ANY code**, run `lint-warnings.sh` on every file you plan to modify:
 
 ```bash
-scripts/lint-warnings.sh <file1> <file2> ...
+~/.cursor/skills/im/scripts/lint-warnings.sh <file1> <file2> ...
 ```
 
 This script:
+
 1. Runs eslint and shows warnings grouped by rule
 2. Outputs matching fix patterns from `~/.cursor/rules/typescript-standards.mdc`
 3. Flags unmatched rules that need new patterns added
 
 If warnings exist:
+
 1. Apply fixes using the matched patterns in the output
 2. For **unmatched rules**: After fixing, add a new `<pattern id="..." rule="...">` to `typescript-standards.mdc` so future occurrences have guidance
 3. Commit lint fixes separately:
@@ -80,7 +82,7 @@ This ensures the subsequent feature commit introduces zero pre-existing warnings
 </step>
 
 <step id="3" name="Implementation">
-1. **Lint-check newly discovered files**: If you need to modify a file not covered in Step 2, run `scripts/lint-warnings.sh <file>` before editing it. If pre-existing warnings exist, fix them using the matched patterns and commit as a `--fixup` to the lint-fix commit from Step 2 (use `git log --oneline` to find the hash). If no lint-fix commit exists yet, create one.
+1. **Lint-check newly discovered files**: If you need to modify a file not covered in Step 2, run `~/.cursor/skills/im/scripts/lint-warnings.sh <file>` before editing it. If pre-existing warnings exist, fix them using the matched patterns and commit as a `--fixup` to the lint-fix commit from Step 2 (use `git log --oneline` to find the hash). If no lint-fix commit exists yet, create one.
 2. Break up the feature into multiple commits if necessary. Commit messages should be a concise title without tags like "feat" and a short body.
 3. Open relevant ts/tsx files before writing code.
 4. Commit using `lint-commit.sh`:
@@ -135,7 +137,7 @@ Other repos only have `## Unreleased` — no staging distinction.
    - **Fixup commits exist**: Autosquash with `GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <base-branch>`. Do this immediately — never leave fixup commits unsquashed.
    - **Structural issues** (add-then-remove cycles, misplaced changes, commits that should be squashed, CHANGELOG in intermediate commits): Use scripted `GIT_SEQUENCE_EDITOR` to drop, reorder, or squash commits, resolving conflicts as needed. Verify the final tree matches the pre-restructure state with `git diff`.
    - **Git lock conflicts**: VSCode's built-in git integration may race with rebase operations, creating `.git/index.lock` files. Always run `rm -f .git/index.lock` before any `git rebase` command to prevent stalls. If a rebase step fails with "index.lock: File exists", remove the lock and `git rebase --continue`.
-</step>
+     </step>
 
 <step id="5" name="Verification">
 Run full verification to catch issues that per-commit checks (`lint-commit.sh`) may have missed (e.g. transitive snapshot breakage, type errors across files):