claude-dev-env 1.38.0 → 1.39.0

package/skills/resume-review/SKILL.md

@@ -1,261 +0,0 @@
----
-name: resume-review
-description: >-
-  Audit a resume for nitty-gritty offenses that bury signal. Resumes are
-  overviews scanned in 6-30 seconds, not detailed proof artifacts. This skill
-  identifies bullets that drift into workflow internals, multi-item technical
-  lists, library names, mechanism narration, or implementation detail, and
-  proposes tighter rewrites that keep the proof points (numbers, scope,
-  outcomes) while dropping the granular how-it-works text. Triggers:
-  "/resume-review", "review my resume", "audit this resume", "is my resume too
-  detailed", "tighten my resume bullets".
----
-
-# Resume Review
-
-A resume is an **overview**. Hiring managers scan a resume in 6-30 seconds on
-first pass. Granular technical detail buries the signal. Stats, scope, and
-quantified outcomes belong on the resume; workflow internals, multi-item
-technical lists, and how-it-works narration belong in the interview.
-
-## Source authority
-
-Three established sources govern this skill. When a bullet violates one of
-these principles, cite the source in the review comment.
-
-- **Laszlo Bock**, *Work Rules!* (2015), Twelve Books, p. 71 (Bock served as
-  SVP People Operations at Google, 2006-2016): bullets describe "what you
-  accomplished, not what you did." Quantified outcomes beat task descriptions.
-- **Steve Dalton**, *The 2-Hour Job Search* (2012), Ten Speed Press, Ch. 3:
-  hiring managers initially scan a resume in 6-30 seconds. Granular technical
-  detail buries the signal in that scan.
-- **Lou Adler**, *Hire With Your Head* (4th ed., 2021), Wiley: bullets convey
-  **scope and impact**, not tools and tasks.
-
-## The principle
-
-Every bullet earns its place by carrying one of three things:
-
-1. **Scope** — what surface area of work this covered (catalog size, team
-   size, user count, transaction volume, geographic reach).
-2. **Impact** — the outcome the work produced (revenue, time saved, error
-   rate reduced, problem prevented, capability unlocked).
-3. **Quantified proof** — a single number that anchors scope or impact and
-   makes the bullet harder to dismiss as boilerplate.
-
-Bullets that describe the **mechanism** of how the work was done (workflow
-steps, internal architecture, library choices, sequencing of operations) fail
-the overview test. Move that content to the interview.
-
-## Offense categories
-
-The audit walks every bullet and flags any of these patterns. Each pattern
-has a fix template.
-
-### 1. Multi-item parenthetical lists
-
-A parenthetical that enumerates 3+ named items (tools, systems, features,
-sub-tasks).
-
-> **Offender:** "Built and maintain three production Python automation
-> systems (theme submission, theme exports, certification failure
-> processing) backed by a shared utility library."
-
-> **Fix:** Drop the parenthetical. Keep the count. "Built and maintain three
-> production Python automations handling [scope]."
-
-### 2. Workflow-step narration
-
-The bullet describes the sequence of operations the work performs.
-
-> **Offender:** "Manage Samsung's annual catalog-update cycle when 2,800+
-> themes must each be updated, exported, and resubmitted one by one within a
-> 1-2 month window."
-
-> **Fix:** Drop the workflow steps. Keep the scope numbers. "Manage Samsung's
-> annual catalog-update cycle: 2,800+ themes refreshed within a 1-2 month
-> window."
-
-### 3. Engineering-pattern jargon for non-engineering audience
-
-Multiple named technical patterns in one bullet, written for an audience
-that does not share the domain (e.g., infrastructure terms in an operations
-or trust-and-safety resume).
-
-> **Offender:** "Turn recurring failures into stronger error classification
-> (transient vs. permanent), circuit breakers, and checkpoint/resume
-> recovery."
-
-> **Fix:** Replace the pattern enumeration with a single capability noun.
-> "Turn recurring failures into reusable error-handling patterns so the same
-> failure does not happen twice."
-
-### 4. Mechanism narration
-
-The bullet explains how a tool or system internally works.
-
-> **Offender:** "Author and maintain pr-converge, a Claude Code skill that
-> automates the pull request review-and-fix loop until reviewers converge on
-> ready, with three open pull requests (11,000+ lines) actively extending
-> it."
-
-> **Fix:** State the outcome the skill produces. Drop the loop description.
-> "Author and maintain pr-converge, an open-source Claude Code skill that
-> drives draft pull requests to merge-ready autonomously."
-
-### 5. Library or tool names embedded mid-bullet
-
-A library, framework, or tool name appears inside a sentence about
-capability. Library names belong in the dedicated Tools section, not in
-capability bullets.
-
-> **Offender:** "Implemented authenticated workflows end-to-end: account
-> creation, token handling, local-first data with IndexedDB/Dexie, and
-> conflict-aware sync between client and server."
-
-> **Fix:** Drop the library names. State the capabilities. "Implemented
-> authentication, local-first data persistence, and conflict-aware
-> client-server sync end-to-end."
-
-### 6. Redundant statistics
-
-Two numbers in the same bullet that express the same quantity at different
-granularities.
-
-> **Offender:** "Roughly 30 new theme submissions per day (150 per week)."
-
-> **Fix:** Pick one. The daily number is usually the strongest scan signal.
-
-### 7. Implementation detail
-
-Phrases that describe how the work was built rather than what it does.
-
-> **Offender:** "Backed by a shared utility library, with zero manual
-> intervention beyond starting the script."
-
-> **Fix:** Drop the implementation phrase entirely. The capability statement
-> should stand on its own.
-
-### 8. Two-sentence bullets
-
-A bullet that requires two sentences usually carries one bullet of scope and
-one bullet of mechanism. The mechanism sentence should be removed, not
-combined.
-
-> **Offender:** "Author and maintain pr-converge, a Claude Code skill
-> that... [first sentence describes what]. Recent work adds mergeability
-> gates, GitHub Copilot reviewer integration, and post-convergence Copilot
-> follow-up across three open pull requests (11,000+ lines)."
-
-> **Fix:** Keep the capability sentence. Move the second sentence to a cover
-> letter or interview talking point.
-
-## Review protocol
-
-Walk this protocol against every bullet on the resume. Mark each bullet
-PASS, MINOR, or MAJOR.
-
-### Step 1: Scope check
-
-Read the bullet aloud in 4 seconds or less. If you cannot finish in 4
-seconds, the bullet is too long. **Action:** trim to one sentence under 25
-words unless the bullet carries a justified centerpiece (and centerpiece
-bullets stay under 40 words).
-
-### Step 2: Offense scan
-
-For each bullet, scan for the eight offense categories above. Record any
-hits with the category number.
-
-### Step 3: Verify proof points
-
-Every numeric claim in a bullet must be verifiable. If a number cannot be
-sourced, drop it. Hedging numbers ("roughly", "around", "approximately")
-are acceptable when the underlying number is verifiable but variable.
-
-### Step 4: Audience alignment
-
-For each bullet, ask: would the hiring manager for **this specific role**
-recognize the terms used? If the bullet uses domain language outside the
-target role's vocabulary (engineering jargon on a trust-and-safety resume,
-finance acronyms on an engineering resume), rewrite using domain-neutral
-capability nouns.
-
-### Step 5: Mechanism removal pass
-
-For each bullet that survived steps 1-4, ask: does this bullet describe
-**what** the work accomplished, or **how** the work was done? If it
-describes **how**, rewrite to describe **what** and move the **how** to
-interview prep notes.
-
-### Step 6: Section-level coherence
-
-After per-bullet review, scan each section. Check for:
-
-- **Bullet count consistency** — sections with similar weight should have
-  similar bullet counts. A 5-bullet section next to a 1-bullet section
-  signals imbalance.
-- **Voice consistency** — verb tense, sentence structure, and bullet length
-  should match across sections.
-- **Relevance ordering** — the most-relevant-to-the-target-role section
-  should appear first within its time band (Steve Dalton, *The 2-Hour Job
-  Search* §6: relevance over strict chronology when chronology does not
-  conflict).
-
-## Output format
-
-The audit produces a markdown report with this structure:
-
-```markdown
-# Resume Audit Report
-
-## Top offenders (worst first)
-
-### #1 — [Section] bullet [N]. [Severity]
-
-[Quote of current bullet]
-
-**Offenses:** [comma-separated category numbers]
-
-**Proposed rewrite:** [tighter version]
-
-**Words saved:** [N words → M words]
-
-(repeat for each offender)
-
-## Sections that pass
-
-- [Section name]: [bullet count] bullets, all PASS
-- (repeat)
-
-## Section-level findings
-
-[Coherence issues from Step 6, if any]
-
-## Sources cited
-
-- Bock, *Work Rules!* (2015), p. 71 — for offenses [N]
-- Dalton, *2-Hour Job Search* (2012), Ch. 3 — for offenses [N]
-- Adler, *Hire With Your Head* (2021) — for offenses [N]
-```
-
-## When this skill applies
-
-- User asks to review or audit a resume
-- User asks "is my resume too detailed"
-- User asks for tighter resume bullets
-- A resume document is shared and the user wants feedback
-- Before submitting a resume to a target role
-
-## When this skill does not apply
-
-- Cover letter review (use a separate cover-letter-review skill if needed)
-- Resume formatting fixes (font, spacing, layout) — this skill audits
-  content only
-- Resume creation from scratch — this skill assumes a draft exists
-
-## Triggers
-
-`/resume-review`, "review my resume", "audit this resume", "is my resume
-too detailed", "tighten my resume bullets", "what offenses do you see in my
-resume", "are my bullets too granular".

package/skills/rule-audit/SKILL.md

@@ -1,307 +0,0 @@
----
-name: rule-audit
-description: Audit AGENTS.md, rules, hooks, and docs across user and project layers for enforcement gaps, duplication, and compliance
-user-invocable: true
-disable-model-invocation: true
----
-
-# Rule Audit
-
-Full enforcement audit of AGENTS.md, `.Codex/rules/`, hooks (settings.json), and referenced docs.
-
-Works across **two layers** — user-global (`~/.Codex/`) and project-local (cwd). Detects cross-layer duplication where project rules restate user rules, wasting instruction budget.
-
-Produces a scored report with corrective actions.
-
-## Phase 0: Layer Detection
-
-Before launching agents, detect which layers exist:
-
-```
-User layer (always present):
-  ~/.Codex/AGENTS.md
-  ~/.Codex/rules/*.md
-  ~/.Codex/settings.json (hooks)
-  ~/.Codex/docs/*.md
-
-Project layer (check cwd):
-  <cwd>/AGENTS.md
-  <cwd>/.Codex/AGENTS.md
-  <cwd>/.Codex/rules/*.md
-  <cwd>/.Codex/settings.json (project hooks)
-
-If cwd == ~ (home directory), skip project layer (same as user layer).
-If no project-layer files exist, report "single-layer audit (user only)".
-If project-layer files exist, report "dual-layer audit (user + project)".
-```
-
-## Phase 1: Inventory (Parallel Discovery)
-
-Launch 3 agents in parallel to inventory the full enforcement landscape.
-
-If dual-layer: each agent inventories BOTH layers, tagging each file with its layer (`user` or `project`).
-
-### Agent 1: Rules & AGENTS.md Inventory
-
-Read and catalog every advisory-layer file:
-
-```
-User layer:
-  ~/.Codex/AGENTS.md
-  ~/.Codex/rules/*.md
-
-Project layer (if exists):
-  <cwd>/AGENTS.md
-  <cwd>/.Codex/AGENTS.md
-  <cwd>/.Codex/rules/*.md
-
-For EACH file, extract:
-  - file_path
-  - layer (user | project)
-  - line_count
-  - purpose (1-sentence summary of what this file tries to enforce)
-  - rules (list of individual rules/instructions, one per line)
-  - framing (count of negative rules using "never/don't/do not/no" vs positive rules)
-  - has_rationale (does each rule explain WHY?)
-  - has_code_examples (are commands in code fences?)
-  - duplicates (rules that appear in multiple files -- list which files AND which layers)
-```
-
-Output as structured markdown to the conversation.
-
-### Agent 2: Hook Inventory
-
-Read settings.json hooks config and each referenced hook script:
-
-```
-User hooks:
-  ~/.Codex/settings.json
-  ~/.Codex/hooks/**/*.py
-
-Project hooks (if <cwd>/.Codex/settings.json exists):
-  <cwd>/.Codex/settings.json
-  <cwd>/.Codex/hooks/**/*.py
-
-For EACH hook entry in settings.json (both layers):
-  - layer (user | project)
-  - event (PreToolUse, PostToolUse, SessionStart, etc.)
-  - matcher
-  - hook_script_path (extract from the command string after the last quote)
-  - Read the actual script file
-  - purpose (what rule does this hook enforce?)
-  - enforcement_type: "blocking" (exit 2 stderr, or PreToolUse exit 0 + JSON deny) | "advisory" (stdout message) | "validation" (post-check)
-  - method: "exit_code_2_stderr" | "pretooluse_json_stdout" (hookSpecificOutput.permissionDecision; see https://code.claude.com/docs/en/hooks) | "stdout" | "other"
-  - which_rule_file (which .Codex/rules/*.md or AGENTS.md rule does this correspond to?)
-  - orphaned (hook exists on disk but NOT in settings.json?)
-```
-
-Also check for hook scripts on disk that are NOT referenced in settings.json (orphaned hooks).
-
-### Agent 3: Docs Inventory
-
-Read referenced documentation files:
-
-```
-User docs:
-  ~/.Codex/docs/*.md (glob to discover all)
-
-Project docs (if exists):
-  <cwd>/.Codex/docs/*.md
-
-For EACH file:
-  - file_path
-  - layer (user | project)
-  - line_count
-  - purpose
-  - loaded_when (is this always loaded, or on-demand via reference?)
-  - overlaps_with (which rules/*.md files cover the same topics?)
-  - hook_enforced (which rules in this doc are enforced by hooks vs purely advisory?)
-```
-
-## Phase 2: Cross-Reference Analysis
-
-After all 3 agents return, analyze the combined inventory:
-
-### 2A: Duplication Map
-
-Build a matrix of where each concept appears:
-
-```
-| Rule/Concept | AGENTS.md | rules/*.md | docs/*.md | hooks | Count |
-|---|---|---|---|---|---|
-| BDD first | line 52, 92 | bdd.md | - | tdd_enforcer.py | 3 advisory + 1 hook |
-| No magic values | - | code-standards.md | CODE_RULES.md:49 | code_rules_enforcer.py | 2 advisory + 1 hook |
-| ... | ... | ... | ... | ... | ... |
-```
-
-Flag any concept appearing 3+ times across advisory files (duplication tax on instruction budget).
-
-### 2B: Enforcement Gap Analysis
-
-For each rule/concept, classify its enforcement level:
-
-```
-| Level | Description | Example |
-|---|---|---|
-| ENFORCED | Hook blocks the action deterministically | destructive_command_blocker.py |
-| VALIDATED | PostToolUse checks after the fact | mypy_validator.py, auto_formatter.py |
-| ADVISORY | In AGENTS.md/rules but no hook backs it | most rules |
-| REDUNDANT | Codex already does this by default | "write clean code" |
-| ORPHANED | Hook exists but no corresponding rule | hook with no rule backing |
-```
-
-### 2C: Formatting Compliance Score
-
-Score each rule file against research-backed criteria:
-
-```
-| Criterion | Weight | Description |
-|---|---|---|
-| Positive framing | 25% | % of rules using positive "do X" vs negative "don't X" |
-| Rationale included | 20% | % of rules with WHY explanation |
-| Actionable | 20% | % of rules an agent could execute without interpretation |
-| Concise | 15% | Line count relative to unique rule count (lower = better) |
-| Code fences | 10% | Commands in code fences vs prose |
-| No duplication | 10% | % of rules NOT duplicated elsewhere |
-```
-
-Score: 0-100 per file. Weight by instruction count contribution.
-
-### 2D: Cross-Layer Duplication (dual-layer only)
-
-If both user and project layers exist, compare them:
-
-```
-| Rule/Concept | User Layer File | Project Layer File | Verdict |
-|---|---|---|---|
-| BDD first | code-standards.md | AGENTS.md line 5 | DUPLICATE — remove from project |
-| No magic values | code-standards.md | rules/code-quality.md | DUPLICATE — remove from project |
-| Use pytest fixtures | (not present) | rules/testing.md | PROJECT-ONLY — keep |
-| Django migrations | docs/DJANGO_PATTERNS.md | AGENTS.md line 22 | DUPLICATE — remove from project |
-```
-
-Verdicts:
-- **DUPLICATE**: Rule exists in both layers. Project copy wastes budget. Remove from project unless it narrows/overrides the user rule.
-- **OVERRIDE**: Project rule intentionally changes a user rule (e.g., user says "use pytest", project says "use unittest"). Keep and document.
-- **PROJECT-ONLY**: Rule exists only in project layer. Keep — it's project-specific.
-- **USER-ONLY**: Rule exists only in user layer. Expected for cross-cutting rules.
-
-### 2E: Combined Budget Analysis
-
-Calculate the total instruction count across all loaded files from BOTH layers:
-
-```
-User layer:
-  ~/.Codex/AGENTS.md:         ~X instructions
-  ~/.Codex/rules/*.md total:  ~Y instructions
-  ~/.Codex/docs (if loaded):  ~Z instructions
-
-Project layer (if exists):
-  <cwd>/AGENTS.md:             ~A instructions
-  <cwd>/.Codex/AGENTS.md:     ~B instructions
-  <cwd>/.Codex/rules/*.md:    ~C instructions
-
-COMBINED TOTAL:                ~N instructions
-Cross-layer duplicates:        ~D instructions (wasted)
-Effective total:               ~(N - D) instructions
-
-Research ceiling:  150 instructions (compliance degrades beyond this) [Source 1]
-Budget remaining:  150 - (N - D) = deficit/surplus
-```
-
-## Phase 3: Corrective Action Plan
-
-Generate a priority-ordered action plan:
-
-### Priority 1: Cut (Remove or Merge)
-
-Items that waste instruction budget:
-- Rules Codex already follows by default (REDUNDANT)
-- Rules duplicated 3+ times across files (consolidate to ONE location)
-- Rules in AGENTS.md that belong in scoped rules/*.md files
-- Docs content that duplicates rules content
-
-### Priority 2: Rewrite (Improve Formatting)
-
-Items scored below 60/100 in formatting compliance:
-- Flip negative rules to positive framing
-- Add rationale where missing
-- Put commands in code fences
-- Make vague rules actionable
-
-### Priority 3: Promote (Advisory -> Enforced)
-
-Rules that SHOULD have hook enforcement but don't:
-- High-violation rules that Codex repeatedly ignores
-- Rules with deterministic criteria (can be pattern-matched)
-- Safety-critical rules where violation has real cost
-
-For each, specify:
-- Which hook event (PreToolUse, PostToolUse, Stop)
-- Blocking vs advisory
-- Pattern to match
-- Estimated implementation effort
-
-### Priority 4: Demote (Enforced -> Removed)
-
-Hooks that add latency without value:
-- Hooks that never fire (check if the pattern is too narrow)
-- Advisory hooks that could be rules instead
-- Hooks using deprecated methods (exit code 2 instead of permissionDecision)
-
-### Priority 5: Deduplicate Across Layers (dual-layer only)
-
-For each DUPLICATE from 2D:
-- If project rule is identical to user rule: delete from project
-- If project rule narrows user rule: keep in project, add comment referencing user rule
-- If project rule conflicts with user rule: flag for user decision (OVERRIDE vs mistake)
-
-### Priority 6: Restructure
-
-Optimal placement recommendations:
-- What stays in AGENTS.md (critical, cross-cutting, <50 lines target)
-- What moves to rules/*.md (domain-specific, scopable)
-- What moves to skills (on-demand workflows, not always relevant)
-- What becomes a hook (deterministic enforcement)
-
-## Phase 4: Output
-
-Write the audit report to the Obsidian vault:
-
-**Path:** `sessions/[Project] Rule Audit [date].md`
-
-**Format:**
-
-```markdown
----
-tags: [audit, rules, enforcement, Codex]
-date: YYYY-MM-DD
-type: rule-audit
----
-
-## Rule Audit Report -- [Date]
-
-### Inventory Summary
-[File counts, total instruction count, budget analysis]
-
-### Duplication Map
-[Table from 2A]
-
-### Enforcement Gaps
-[Table from 2B -- sorted by risk level]
-
-### Formatting Scores
-[Table from 2C -- sorted by score ascending]
-
-### Corrective Actions
-[Numbered list from Phase 3, grouped by priority]
-
-### Implementation Checklist
-[ ] Priority 1 items (with specific file edits)
-[ ] Priority 2 items (with before/after examples)
-[ ] Priority 3 items (with hook specifications)
-[ ] Priority 4 items (with removal justification)
-[ ] Priority 5 items (with move-from/move-to)
-```
-
-Present the report to the user and ask which priorities to tackle first.