@iceinvein/agent-skills 0.1.19 → 0.1.21

package/skills/index.json

@@ -3,13 +3,17 @@
     "name": "design-review",
     "description": "Brooks-inspired design integrity review — tests conceptual integrity, constraint exploitation, removal discipline, and scope control",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "codebase-architecture",
     "description": "Architecture review for existing codebases or structured design for new projects, with patterns reference",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any", "architecture"],
+    "quick": false
   },
   {
     "name": "code-intelligence",
@@ -21,150 +25,234 @@
     "name": "contract-enforcer",
     "description": "Meyer-inspired Design by Contract — preconditions, postconditions, invariants, and failure contracts for non-trivial functions",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "complexity-accountant",
     "description": "Ousterhout-inspired complexity analysis — deep vs shallow modules, complexity budget, justified abstractions",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "module-secret-auditor",
     "description": "Parnas-inspired information hiding analysis — module boundaries drawn by change-reason, not by noun or technical layer",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "seam-finder",
     "description": "Feathers-inspired legacy code modification — find seams, make minimal incisions, preserve existing behavior",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["legacy"],
+    "quick": true
   },
   {
     "name": "simplicity-razor",
     "description": "Hickey-inspired simplicity analysis — simple vs easy, complecting detection, strand decomposition",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "coupling-auditor",
     "description": "Constantine & Yourdon-inspired coupling analysis — classify, measure, and reduce interdependence between modules",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "evolution-analyzer",
     "description": "Lehman-inspired software evolution analysis — trajectory assessment, debt visibility, and change impact on system health",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "error-strategist",
     "description": "Duffy & Abrahams-inspired error handling — classify errors (bug/recoverable/fatal), assign safety guarantees, design recovery boundaries",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["errors"],
+    "quick": false
   },
   {
     "name": "rams-design-audit",
     "description": "Dieter Rams-inspired design audit — every visual element must earn its presence, less but better, clarity through restraint",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["ui"],
+    "quick": true
   },
   {
     "name": "cognitive-load-auditor",
     "description": "Jeff Johnson-inspired cognitive load analysis — evaluate UI against Miller's Law, Hick's Law, Fitts's Law, and working memory limits",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["ui"],
+    "quick": false
   },
   {
     "name": "gestalt-reviewer",
     "description": "Gestalt-inspired visual perception audit — proximity, similarity, closure, continuity, and figure-ground analysis for UI layouts",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["ui"],
+    "quick": true
   },
   {
     "name": "integration-pattern-auditor",
     "description": "Hohpe & Woolf-inspired messaging analysis — name the integration pattern, verify delivery guarantees, identify missing infrastructure",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["integration"],
+    "quick": false
   },
   {
     "name": "unidirectional-flow-enforcer",
     "description": "Elm Architecture-inspired data flow analysis — enforce unidirectional state flow, detect bidirectional mutations, trace state lifecycle in UI applications",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["ui"],
+    "quick": false
   },
   {
     "name": "event-design-reviewer",
     "description": "Evans/Vernon/Dahan-inspired event design — domain-meaningful naming, fat payloads, schema evolution, and the domain expert test",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["integration", "domain"],
+    "quick": false
   },
   {
     "name": "dependency-direction-auditor",
     "description": "Martin-inspired dependency direction analysis — trace imports across layers, classify violations by severity, recommend inversion",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "cohesion-analyzer",
     "description": "Constantine & Yourdon-inspired cohesion analysis — classify module focus on the 7-level spectrum, find split lines, reduce mixed responsibilities",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "demeter-enforcer",
     "description": "Lieberherr-inspired Law of Demeter analysis — detect chain violations, parameter drilling, and hidden traversal; fix with tell-don't-ask or parameter narrowing",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "bounded-context-auditor",
     "description": "Evans-inspired bounded context analysis — detect linguistic fractures, draw context maps, identify leaking language and shared model pollution",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["domain"],
+    "quick": false
   },
   {
     "name": "port-adapter-auditor",
     "description": "Cockburn-inspired hexagonal architecture analysis — identify ports and adapters, classify boundary health, ensure core testability and swappability",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": false
   },
   {
     "name": "idempotency-guardian",
     "description": "Helland-inspired idempotency analysis — classify mutation points, check protection mechanisms, evaluate side effect safety for retry-safe systems",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["integration"],
+    "quick": false
   },
   {
     "name": "type-driven-designer",
     "description": "Wlaschin & Minsky-inspired type design — make illegal states unrepresentable through branded types, discriminated unions, and domain-encoded constraints",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "cqs-auditor",
     "description": "Meyer-inspired Command-Query Separation — classify functions as commands or queries, detect mixed violations, separate side effects from return values",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["architecture"],
+    "quick": true
   },
   {
     "name": "composability-auditor",
     "description": "Unix Philosophy-inspired composability analysis — identify reuse blockers, decompose self-sufficient units into composable pieces with standard interfaces",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": false
   },
   {
     "name": "temporal-coupling-detector",
     "description": "Hidden ordering dependency analysis — detect two-phase init, method order dependencies, invisible preconditions, and resource lifecycle violations; fix with types, parameters, and factory patterns",
     "type": "prompt",
-    "version": "1.0.0"
+    "version": "1.0.0",
+    "applies": ["any"],
+    "quick": true
   },
   {
     "name": "terse",
     "description": "Professional output compression — proper grammar, no fluff, ~50-60% fewer tokens. Three levels: clean, tight, sharp.",
     "type": "prompt",
     "version": "1.1.0"
+  },
+  {
+    "name": "cover-letter",
+    "description": "Cover letter suite router. Routes to write, audit, rewrite, or persona subcommands; shares conventions for file I/O, output formats, and writing principles.",
+    "type": "prompt",
+    "version": "1.0.0"
+  },
+  {
+    "name": "cover-letter-write",
+    "description": "Generate a cover letter from resume + job description (PDF, DOCX, markdown, URL). Outputs markdown, DOCX, and PDF. Enforces human prose, evidence alignment, and JD coverage without keyword stuffing.",
+    "type": "prompt",
+    "version": "1.0.0"
+  },
+  {
+    "name": "cover-letter-audit",
+    "description": "Score a cover letter on 100 points across content, structure, voice, and correctness. Detects AI-generated-content signals (burstiness, AI phrases, TTR, em-dashes) and produces prioritized fixes.",
+    "type": "prompt",
+    "version": "1.0.0"
+  },
+  {
+    "name": "cover-letter-rewrite",
+    "description": "Revise an existing cover letter with audit-driven targeted fixes. Focus modes: humanize, align, tighten, structure, tone. Preserves voice where it already works.",
+    "type": "prompt",
+    "version": "1.0.0"
+  },
+  {
+    "name": "cover-letter-persona",
+    "description": "Manage reusable writing personas for cover letters using the NNGroup 4-dimension tone framework. Locks in tone, sentence style, and vocabulary across applications.",
+    "type": "prompt",
+    "version": "1.0.0"
+  },
+  {
+    "name": "improve-my-codebase",
+    "description": "Orchestrator skill that runs every applicable audit skill in parallel and produces a prioritized, convergence-ranked improvement report",
+    "type": "prompt",
+    "version": "1.0.0"
   }
 ]

package/skills/terse/SKILL.md

@@ -1,14 +1,23 @@
 ---
 name: terse
 description: >
-  Professional output compression — cuts ~50-60% of output tokens while keeping proper grammar
-  and readable prose. Three intensity levels: clean, tight (default), sharp.
+  Professional output compression. Cuts ~20-30% of output tokens while keeping proper grammar,
+  readable prose, and semantic accuracy. Three intensity levels: clean, tight (default), sharp.
   Always-on from session start. Switch with /terse clean|tight|sharp.
   Off with "stop terse" or "normal mode".
 argument-hint: "[clean|tight|sharp]"
 ---
 
-Respond direct and concise. All technical substance stays. Grammar stays. Only waste dies.
+First, answer correctly. Then edit: cut filler, hedging, and waste. Conclusions, recommendations, and technical substance must survive compression unchanged. Grammar stays. Only waste dies.
+
+## Semantic Preservation
+
+Terse compresses HOW the answer is delivered. It must never change WHAT the answer says.
+
+- If the uncompressed answer would recommend X, the terse answer must also recommend X. Compression must not shift conclusions, flip recommendations, or reorder priorities.
+- For opinion/tradeoff questions ("Should I use X or Y?", or any prompt containing "should I", "would you recommend", "which is better", "X vs Y", "pros and cons", "which should"): use your thinking to reason through the recommendation at full depth WITHOUT compression. Decide your answer in thinking. Then write the compressed visible response, ensuring the recommendation matches your thinking. If they diverge, your thinking is correct; fix the visible output.
+- State your recommendation in the FIRST sentence of the visible response. This locks it in before compression pressure accumulates on the supporting reasoning.
+- If a caveat is load-bearing (changes what the reader would do), keep it. Only drop caveats that are generic hedging ("your mileage may vary", "it depends on your use case") with no specific content.
 
 ## Persistence
 
@@ -20,32 +29,32 @@ Active level: **$ARGUMENTS[0]** (default to **tight** if no argument provided).
 
 Every response, cut these patterns:
 
-**Preambles** — never open with pleasantries or throat-clearing.
+**Preambles**: never open with pleasantries or throat-clearing.
 - Kill: "Sure! I'd be happy to help you with that. The issue is..."
 - Write: "The issue is..."
 
-**Question restating** — never echo what the user just said.
+**Question restating**: never echo what the user just said.
 - Kill: "You're asking about why your database connection is timing out. This is a common issue that..."
 - Write: "The connection times out because..."
 
-**Hedge stacking** — state things directly. Qualify only when genuinely uncertain.
+**Hedge stacking**: state things directly. Qualify only when genuinely uncertain.
 - Kill: "It's likely that you might want to possibly consider using a connection pool, which could potentially help..."
 - Write: "Use a connection pool."
 
-**Trailing summaries** — the explanation is the explanation. Don't summarize it again at the end.
+**Trailing summaries**: the explanation is the explanation. Don't summarize it again at the end.
 - Kill: [explanation] "So in summary, what we did was update the middleware to validate tokens correctly, which should fix the authentication issue."
 - Write: [explanation ends]
 
-**Narrating actions** — don't announce what you're about to do. Just do it. The tool call is the communication. Never preface a tool call with text explaining that you're about to make it.
+**Narrating actions**: don't announce what you're about to do. Just do it. The tool call is the communication. Never preface a tool call with text explaining that you're about to make it.
 - Kill: "Let me take a look at the file for you. I'll read it now and analyze what's going on."
 - Kill: "Now let me fix that issue."
 - Kill: "Let me check the tests."
 - Kill: "I'll update the config next."
 - Kill: "We need to update the schema first."
 - Kill: "First, I'll read the file to understand the structure."
-- Write: [tool call — no preamble]
+- Write: [tool call, no preamble]
 
-**Banned action-narration openers** — these phrases before a tool call are always filler. Cut them 100% of the time:
+**Banned action-narration openers**: these phrases before a tool call are always filler. Cut them 100% of the time:
 - "Let me..." / "Now let me..." / "Now I'll..."
 - "I'll..." / "I need to..." / "We need to..."
 - "First, let me..." / "Next, I'll..."
@@ -58,15 +67,19 @@ If context is needed between tool calls, state the *finding* or *decision*, not
 - Kill: "Let me run the tests to verify."
 - Write: [runs tests]
 
-**Over-explaining the obvious** — don't describe trivial operations.
+**Over-explaining the obvious**: don't describe trivial operations.
 - Kill: "I'll create a new file called `utils.ts`. This file will contain utility functions that we can reuse across the project."
 - Write: [creates the file]
 
-**Excessive caveats** — if there's a real trade-off, name it specifically. Don't hedge generically.
+**Inflating short answers**: if the correct answer is one sentence, deliver one sentence. Terse must never make a response longer than it would be without terse. Do not add examples, elaboration, or context that the uncompressed response would not have included.
+- Kill: "O(log n). This is because each comparison halves the remaining search space. To illustrate, consider a sorted array of 1 million elements..."
+- Write: "O(log n). Each step halves the search space."
+
+**Excessive caveats**: if there's a real trade-off, name it specifically. Don't hedge generically.
 - Kill: "This approach has some trade-offs. Depending on your use case, you might want to consider other options. That said, for most situations, this should work well, though your mileage may vary."
 - Write: "Trade-off: [specific thing]. For most cases this works."
 
-## Filler Words — Always Drop
+## Filler Words: Always Drop
 
 These add no information. Remove on sight regardless of level:
 
@@ -85,47 +98,63 @@ Drop filler, hedging, and pleasantries. Keep full sentences with natural flow.
 
 ### `tight` (default)
 
-Everything in `clean`, plus shorter synonyms and shorter sentences.
+Everything in `clean`, plus shorter synonyms, shorter sentences, and targeted cuts.
 
+Word cuts:
 - Shorter synonyms: big not extensive, fix not implement, use not utilize, show not demonstrate, check not investigate, need not requirement, start not initialize, end not terminate, send not transmit
-- One idea per sentence. No compound sentences where two short ones work.
+- Strip transition phrases on sight: "however", "additionally", "furthermore", "moreover", "that said", "in other words", "it's also worth mentioning", "on the other hand", "as a result", "with that in mind". Just start the next sentence.
+- Replace "this means that" with a dash or colon. Replace "the reason is that" with "because".
+- One idea per sentence. Split compound sentences.
+
+Content cuts:
 - Direct answer first, then explanation if needed.
+- One example per point. Two examples illustrating the same concept: keep the clearer one, drop the other.
+- If the answer would work without the last paragraph, drop the last paragraph.
+- Do not restructure or add formatting that wasn't in the uncompressed answer. Only cut.
 
 ### `sharp`
 
-Everything in `tight`, plus abbreviations and telegraphic structure.
+Everything in `tight`, plus abbreviations, telegraphic structure, and structural compression.
 
+Word-level:
 - Abbreviations where widely recognized: DB, auth, config, req, res, fn, impl, env, deps, repo, dir, and any the audience would recognize without thinking
 - Arrows for causality (X → Y)
 - Sentences as short as grammatically correct allows
 
+Structure-level (only apply if the response is longer than ~100 tokens; never restructure short answers or content that is already a list):
+- Prose paragraphs become dash-lists where the content is a set of independent points. If the content is already a list or table, leave the structure alone.
+- Drop "For example" / "For instance" asides. State the rule or fact directly.
+- If a response has intro + body + recap, keep only the body.
+- If two paragraphs make the same point from different angles, merge into one.
+- Limit long lists to the 3-5 most important items. If the list is already 5 or fewer items, keep all of them.
+
 ## Examples
 
 **"Why is my React component re-rendering?"**
 
 - clean: "You're creating a new object reference on each render. When you pass an inline object as a prop, React's shallow comparison sees a different object every time, triggering a re-render. Wrap it in `useMemo`."
-- tight: "Inline object props create a new reference each render. React's shallow comparison sees a new object, triggers re-render. Use `useMemo`."
+- tight: "Inline object props create a new reference each render. React sees a new object, triggers re-render. Use `useMemo`."
 - sharp: "Inline obj prop → new ref each render → re-render. `useMemo` to memoize."
 
 **"Explain database connection pooling"**
 
-- clean: "Connection pooling reuses open database connections instead of creating new ones per request. This avoids the overhead of repeated TCP handshakes and authentication. Most frameworks have a pool built in — configure the pool size and idle timeout."
-- tight: "Connection pooling reuses open connections instead of creating new ones per request. Skips repeated handshake overhead. Configure pool size and idle timeout in your framework."
-- sharp: "Pool reuses DB connections. No new conn per req → no handshake overhead. Configure pool size + idle timeout."
+- clean: "Connection pooling reuses open database connections instead of creating new ones per request. This avoids the overhead of repeated TCP handshakes and authentication. Most frameworks have a pool built in; configure the pool size and idle timeout."
+- tight: "Pooling reuses open connections instead of creating new ones per request. Skips handshake overhead. Configure pool size and idle timeout."
+- sharp: "Pool reuses DB conns instead of new conn per req → no handshake overhead. Set pool size + idle timeout."
 
-**"Fix the auth middleware bug"**
+**"Should I use X or Y?" (tradeoff question)**
 
-- clean: "The token expiry check uses `<` instead of `<=`. A token expiring at the exact current timestamp passes validation when it shouldn't."
-- tight: "Token expiry check uses `<` not `<=`. Tokens expiring at exact current timestamp pass when they shouldn't."
-- sharp: "Bug: expiry check uses `<` not `<=`. Token at exact expiry time passes validation."
+- clean: [Full recommendation with reasoning. Same conclusion as without terse. Generic hedges removed, specific tradeoffs kept.]
+- tight: [Same conclusion. Answer first, reasoning below. One example per point. Transition phrases stripped.]
+- sharp: [Same conclusion. Dash-list of pros/cons. No intro or recap. Top 3-5 points only.]
 
 ## Auto-Clarity
 
 Drop terse for:
 - Security warnings and irreversible action confirmations
 - Multi-step sequences where compression could cause misread ordering
-- User asks to clarify or repeats a question — they need more, not less
-- Error messages — quote exact, never paraphrase
+- User asks to clarify or repeats a question; they need more, not less
+- Error messages: quote exact, never paraphrase
 
 Resume terse immediately after the clear section.
 

package/skills/terse/skill.json

@@ -1,7 +1,7 @@
 {
   "name": "terse",
-  "version": "1.1.0",
-  "description": "Professional output compression — proper grammar, no fluff, ~50-60% fewer tokens. Three levels: clean, tight, sharp.",
+  "version": "1.2.0",
+  "description": "Professional output compression. Cuts ~20-30% of output tokens with proper grammar and semantic accuracy. Three levels: clean, tight, sharp.",
   "author": "iceinvein",
   "type": "prompt",
   "tools": [
@@ -29,7 +29,10 @@
     }
   },
   "activation": {
-    "modes": ["session", "global"],
+    "modes": [
+      "session",
+      "global"
+    ],
     "default": "session",
     "claudeHookDirective": "Activate terse skill at tight level for this session."
   }