devflow-kit 3.11.0 → 3.12.1

package/src/assets/skills/feature-knowledge/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: feature-knowledge
-description: Structures codebase exploration into a feature knowledge base
+description: Use when building a feature knowledge base.
 user-invocable: false
 allowed-tools:
   - Read
@@ -23,61 +23,22 @@ allowed-tools:
 
 ## The Four Phases
 
-Follow these four phases in order. Do not skip ahead.
+Follow these four phases in order.
 
 ### Phase 1: Scan
 
-Map the landscape. Get a high-level understanding before going deep.
+Map where the code of this area lives and how it is structured: directories, languages and frameworks, entry points, configuration and existing documentation.
 
-- Use `Glob` to discover directory structure and file organization
-- Identify language(s), framework(s), and major dependencies
-- Locate key entry points, configuration files, and existing documentation
-- Note how the code is organized — monorepo, modules, layers, etc.
-
-**Goal**: Answer "Where does the code related to this area live, and how is it structured?"
+With your first scan calls, Glob the target `KNOWLEDGE.md` and run `d="${CLAUDE_CONFIG_DIR:-}"; case "$d" in /*) ;; *) d="$HOME/.claude" ;; esac; printf '%s\n' "$d"` in Bash.
+**New KB only** (the Glob finds no file): Read `<that directory>/skills/devflow:feature-knowledge/references/new-kb.md` once, with your next reads. It holds the category table, the category templates and a worked example. If the Read fails, choose the category from the frontmatter list and main sections that fit it.
 
 ### Phase 2: Extract
 
-Go deep. Read the actual code and pull out the real patterns.
-
-- Read key files using `Read`
-- Use `Grep` to find recurring patterns across the codebase
-- Trace data flow: how does information move through the system?
-- Identify naming conventions, structural patterns, error handling approaches
-- Look for implicit rules — things the team clearly follows but never wrote down
-- Pay attention to what's consistent (conventions) vs. what varies (knowledge gaps)
-- Look at how similar things are implemented — find ALL instances and see what they share
-
-**For complex domains, go further:**
-- Map core entities and their relationships
-- Identify decision points — where does business logic branch?
-- Extract implicit knowledge — what's obvious to current developers but invisible to newcomers?
-- Document state transitions, business rules, and edge case handling
-
-**Self-check before moving on:**
-- "Am I understanding the full scope of what's being requested?"
-- "What connections am I seeing that weren't obvious initially?"
-- "Are there patterns I'm missing because I'm too focused on one area?"
+Read the key files and trace how data moves through the area. Find ALL instances of similar things and see what they share: naming, structure, error handling, and the implicit rules the team follows but never wrote down. For a complex domain, also map the core entities, the decision points, the state transitions and the edge cases.
 
 ### Phase 3: Distill
 
-Organize and validate findings. Raw observations become structured knowledge.
-
-**Choose a knowledge category:**
-
-| The knowledge is about... | Category | Language Style |
-|---|---|---|
-| How the overall system is designed | `architecture` | Descriptive — explains what systems are and why they exist |
-| Patterns followed across the whole project | `conventions` | Prescriptive — "Do this," "Avoid that" |
-| How a specific type of component works | `component-patterns` | Prescriptive — enforces conventions |
-| A specific business domain or module | `domain-knowledge` | Descriptive — builds mental models |
-| Hard-won lessons from incidents or edge cases | `lessons-learned` | Narrative — tells the story of discovery |
-
-**Validate each finding:**
-- Is this specific to THIS codebase, or generic advice? (only keep specific)
-- Does this reflect what the code actually does NOW, or is it speculative? (only keep current)
-- Would a developer actually use this to build something? (only keep actionable)
-- Is this obvious from reading one file, or does it require cross-cutting knowledge? (prefer cross-cutting)
+Keep a finding only if it is specific to THIS codebase, true of the code NOW, actionable for a developer, and preferably cross-cutting rather than obvious from one file.
 
 ### Phase 4: Forge
 
@@ -109,7 +70,7 @@ updated: {ISO date}
 ## Overview
 [1-2 paragraphs: what this knowledge covers and why it matters for this codebase]
 
-## [Main Sections — vary by category, see Category Templates below]
+## [Main Sections — vary by category]
 
 ## Anti-Patterns
 [The longer explanation of each anti-pattern, headed by its ID — never a restatement of the Rules bullet]
@@ -141,94 +102,21 @@ Per KB: target 30,000 characters, ceiling 40,000. An index line is at most 300 c
 
 When `EXISTING_KB` is provided, change only the sections the new work touches, and add or update Rules bullets for what changed. Never renumber, and never rewrite untouched sections to meet the budget. A KB still above the ceiling after a refresh is written as it stands, and the final message says so.
 
-### Category Templates
-
-Use the matching template as your main sections. Anti-Patterns, Gotchas, Key Files, and Related are shared across all categories.
+### Description Field
 
-**Architecture:**
-- System Context (purpose, role in larger system, external dependencies)
-- Component Architecture (major building blocks, data stores, APIs)
-- Component Interactions (how pieces communicate, data flow)
-- Integration Patterns (how this connects to external systems)
-- Constraints (security boundaries, performance considerations, scaling limits)
-
-**Conventions:**
-- Code Organization Principles (principle with rationale)
-- Standard Patterns (pattern with annotated code example)
-- Error Handling Standards (approach with code example)
-
-**Component Patterns:**
-- Core Responsibilities (what this component should/should NOT do)
-- Standard Structure (complete annotated code example)
-- Dependency Patterns (how dependencies are managed)
-- Error Handling (component-specific error patterns)
-- Integration Guidelines (how to interact with other component types)
-
-**Domain Knowledge:**
-- Business Context (purpose, business value, compliance constraints)
-- Core Business Rules (rules with examples and edge cases)
-- State Transitions (workflow states and triggers)
-- Technical Implementation Patterns (code patterns specific to this domain)
-- Error Handling and Recovery (domain-specific failure modes)
-
-**Lessons Learned:**
-- Per lesson: Incident Context → Root Cause → Impact → Code showing problem and solution → Prevention Strategy
-
-### Description Field Rules
-
-The `description` field is how this feature knowledge entry gets discovered. It must:
-- Start with "Use when"
-- Name specific scenarios where this knowledge applies
-- Include keywords a developer would search for
-- Stay within 220 characters
-
-Good: `"Use when adding a new vendor integration, implementing API clients, or connecting to external services. Keywords: integration, vendor, API client, webhook."`
-Bad: `"Integration stuff"`
+The `description` field is how this entry gets discovered. It starts with "Use when", names the specific scenarios where the knowledge applies, includes the keywords a developer would search for, and stays within 220 characters. Example: `"Use when adding a new vendor integration, implementing API clients, or connecting to external services. Keywords: integration, vendor, API client, webhook."`
 
 ### Cross-References
 
-Knowledge files must not exist in isolation. The **Related** section must link to:
-- Other feature knowledge entries that cover related topics
-- Key source files referenced in the knowledge
+The **Related** section links the other feature knowledge entries that cover related topics and the key source files the knowledge references. When a new entry relates to an existing one, note the connection in both.
 
 A decision or pitfall from DECISIONS_CONTEXT that shapes this area is stated in words in the section it governs, never by its ADR/PF ID: KNOWLEDGE.md is git-tracked and shared with every clone, and ledger IDs resolve only on the machine that recorded them.
 
-References should be bidirectional — when creating a new feature knowledge entry that relates to an existing one, note the connection.
-
 ---
 
 ## Rules for Code Examples
 
-Every code example must have three parts:
-1. **Description before**: what it demonstrates and why
-2. **Inline comments**: explaining the important lines
-3. **Takeaways after**: key points
-
-Before including an example, verify it adds **significant unique value** beyond what descriptive text alone provides. If the pattern can be fully explained in a sentence, skip the code block. Only show codebase-specific patterns — never generic language features.
-
-Never include bare code snippets without context.
-
----
-
-## What to Avoid
-
-- **Generic advice**: "Use dependency injection" without showing how THIS project does it
-- **Speculation**: "We might want to add caching later" — only document what exists
-- **Bare examples**: Code without explanation of what it shows and why it matters
-- **Low-value examples**: Code that restates generic language features. If it doesn't show something unique to THIS project, cut it.
-- **Everything-bagel files**: Covering too many topics in one file — stay focused
-- **Obvious things**: If reading one file makes it clear, it doesn't need a feature knowledge entry
-- **Testing knowledge**: Don't include test patterns unless explicitly requested
-- **Isolated knowledge islands**: Every feature knowledge entry must reference related files and source code
-
-| Red Flag | What It Indicates |
-|----------|-------------------|
-| "Always follow best practices" | Generic, not codebase-specific |
-| No code examples at all | Insufficient actionable guidance |
-| Examples without inline comments | Missing required context |
-| "In the future, we might..." | Speculative — remove it |
-| Over 40,000 characters, or volatile numbers in Rules | Curate it; name the pinning test or constant instead of a count |
-| No cross-references in Related | Isolated knowledge island |
+Include a code example only when it adds significant unique value beyond a sentence, and only for a codebase-specific pattern, never a generic language feature. Every example has a description before it (what it shows and why), inline comments on the important lines, and takeaways after it.
 
 ---
 
@@ -237,10 +125,11 @@ Never include bare code snippets without context.
 Run through this before writing. If any check fails, go back and fix it.
 
 **Content:**
-- [ ] Knowledge provides codebase-specific insights (not generic guidance)
-- [ ] All content reflects current patterns (no speculation)
+- [ ] Knowledge provides codebase-specific insights, not generic advice ("use dependency injection" without how THIS project does it)
+- [ ] All content reflects current code; no speculation ("we might add caching later")
 - [ ] Business context and domain constraints captured where relevant
 - [ ] Every claim is verifiable in actual code
+- [ ] One focused topic, not an everything-bagel file; no test patterns unless requested
 
 **Examples:**
 - [ ] Every code example has description before, inline comments, and takeaways after
@@ -248,26 +137,21 @@ Run through this before writing. If any check fails, go back and fix it.
 - [ ] Anti-patterns documented with explanation of consequences
 
 **Structure:**
-- [ ] Category is correct and main sections follow the matching template
+- [ ] Category is correct; a new KB follows its category template, and a refresh keeps the existing sections
 - [ ] Description field starts with "Use when" and includes keywords
 - [ ] `## Rules` comes first: one-line bullets with `KB-AP-n` / `KB-INV-n` IDs, about 3–5K characters, no volatile numbers
 - [ ] File within the 40,000-character ceiling (curate, never truncate); description at most 220 characters
 
 **Connections:**
 - [ ] Cross-references to related feature knowledge entries in Related section; decisions and pitfalls stated in words, with no ADR/PF ID anywhere in the file
-- [ ] No isolated knowledge islands — file connects to the broader knowledge network
 - [ ] Key source files listed in Key Files section
 
 ---
 
 ## Index Registration
 
-After writing KNOWLEDGE.md, update the index cache directly:
-
-**File**: `{worktree}/.devflow/features/index.md`
-**Operation**: Read-modify-write — replace the existing line for this slug if present, or append.
+After writing KNOWLEDGE.md, register it in `{worktree}/.devflow/features/index.md` with this line:
 
-**Line format**:
 ```
 - **{slug}** — {areas} — {Use-when description}
 ```
@@ -277,97 +161,10 @@ The whole line is at most 300 characters; reword a longer one, never cut it. Whe
 - `{areas}` is a comma-separated summary of the `directories:` frontmatter field
 - `{Use-when description}` is the `description:` frontmatter field value (the full "Use when..." sentence, at most 220 characters)
 
-If `index.md` does not exist, create it with just this line. If the file already has an entry for this slug, replace that line in-place. This is the discoverable cache read by `knowledge_load()` — the KNOWLEDGE.md frontmatter is always authoritative.
-
----
-
-## Worked Example
-
-This is what a complete, well-structured feature knowledge entry looks like. Use it as a reference for quality and format.
-
-````markdown
----
-feature: integrations
-name: Third-Party Integrations
-description: "Use when adding a new vendor integration, implementing API clients, or connecting to external services. Keywords: integration, vendor, API client, webhook, spawn, config."
-category: component-patterns
-directories: [src/lib/]
-created: 2026-04-30
-updated: 2026-04-30
----
-
-# Third-Party Integrations
-
-## Rules
-
-- **KB-AP-1** Fetch logic never lives in a command file: it breaks the lib/command split and cannot be tested alone.
-- **KB-AP-2** URLs never live in lib modules: they go through `config.ts`.
-- **KB-AP-3** A lib module never calls `showError()`: lib modules throw, commands catch and display.
-- **KB-AP-4** `spawn` needs the binary on PATH: detect `ENOENT` and give an install URL.
-- **KB-INV-1** Every external constant lives in `src/lib/config.ts`.
-
-## Overview
-
-This project integrates with external systems by spawning CLI processes, fetching files from remote registries, and writing to directories that AI editors watch. Each integration lives in its own module under `src/lib/` and is wired into a command in `src/commands/`. All external constants are centralized in `src/lib/config.ts`.
-
-The key cross-cutting pattern is the separation between lib modules (which integrate) and commands (which orchestrate). Violating this creates coupling that breaks the error handling model.
-
-## Core Responsibilities
-
-- Lib modules: integrate with external systems, export async functions, throw on failure
-- Commands: orchestrate lib modules, catch errors, route to UI via `showError()`
-- Config: centralize all external constants, expose env var overrides
-
-## Standard Structure
-
-Every integration follows the same file organization. This example shows the pattern that every existing integration (Claude CLI, GitHub, AI editors) follows:
-
-```
-src/lib/
-  claude.ts          # Claude Code CLI (spawn + stream JSON)
-  skill-installer.ts # GitHub (git clone, sparse checkout)
-  deploy.ts          # AI editors (.claude/, .cursor/ dirs)
-  config.ts          # All constants for the above
-```
-
-A new integration means a new file here. The module exports async functions, imports from `config.ts`, and never imports from `src/ui/` or `src/commands/`.
-
-### Config Centralization
-
-URLs, subpaths, install directories — these change together. One file to update when an upstream moves:
-
-All constants use `SCREAMING_SNAKE_CASE` with a descriptive prefix. If a value can be overridden by the user, expose an env var with a sensible default.
-
-## Anti-Patterns
-
-- **KB-AP-1, putting fetch logic in a command file** — breaks the lib/command separation and makes the integration untestable in isolation.
-- **KB-AP-2, hardcoding URLs in lib modules** — always use `config.ts`. Scattered strings become stale and hard to find.
-- **KB-AP-3, calling `showError()` from a lib module** — lib modules throw; commands catch and display.
-
-## Gotchas
-
-- **KB-AP-4**: `spawn` requires the binary on PATH. If integrating a tool that may not be globally installed, detect `ENOENT` and provide an install URL.
-- Temp files use `Date.now()`. If two processes run simultaneously, add a random suffix to avoid collisions.
-
-## Key Files
-
-- `src/lib/config.ts` — add constants here before writing integration code
-- `src/lib/claude.ts` — reference implementation for spawn-and-stream pattern
-- `src/lib/skill-installer.ts` — reference implementation for fetch-from-remote pattern
-
-## Related
-
-- `.devflow/features/cli-commands/KNOWLEDGE.md` — the command side of the lib/command split: catching errors and routing them to `showError()`
-- `src/commands/` — where each integration is wired into a command
-````
+If `index.md` does not exist, create it with just this line. The KNOWLEDGE.md frontmatter is always authoritative; the index line is a cache.
 
 ---
 
 ## Scope and Limitations
 
-Only document what you can verify in the codebase. When you encounter:
-- Knowledge outside the provided codebase
-- External systems without accessible documentation
-- Information that requires context you don't have
-
-Acknowledge the limitation clearly and focus on what IS extractable. Never fill gaps with generic knowledge or speculation.
+Only document what you can verify in the codebase. Where knowledge lies outside it, or needs context you do not have, say so and focus on what IS extractable. Never fill gaps with generic knowledge or speculation.

package/src/assets/skills/feature-knowledge/references/new-kb.md

@@ -0,0 +1,128 @@
+# New Knowledge Base
+
+Read this file only when you create a knowledge base. A refresh keeps the category and the sections of the existing file.
+
+## Category
+
+Choose the category of the new knowledge base:
+
+| The knowledge is about... | Category | Language Style |
+|---|---|---|
+| How the overall system is designed | `architecture` | Descriptive — explains what systems are and why they exist |
+| Patterns followed across the whole project | `conventions` | Prescriptive — "Do this," "Avoid that" |
+| How a specific type of component works | `component-patterns` | Prescriptive — enforces conventions |
+| A specific business domain or module | `domain-knowledge` | Descriptive — builds mental models |
+| Hard-won lessons from incidents or edge cases | `lessons-learned` | Narrative — tells the story of discovery |
+
+## Category Templates
+
+Use the matching template as your main sections. Anti-Patterns, Gotchas, Key Files, and Related are shared across all categories.
+
+**Architecture:**
+- System Context (purpose, role in larger system, external dependencies)
+- Component Architecture (major building blocks, data stores, APIs)
+- Component Interactions (how pieces communicate, data flow)
+- Integration Patterns (how this connects to external systems)
+- Constraints (security boundaries, performance considerations, scaling limits)
+
+**Conventions:**
+- Code Organization Principles (principle with rationale)
+- Standard Patterns (pattern with annotated code example)
+- Error Handling Standards (approach with code example)
+
+**Component Patterns:**
+- Core Responsibilities (what this component should/should NOT do)
+- Standard Structure (complete annotated code example)
+- Dependency Patterns (how dependencies are managed)
+- Error Handling (component-specific error patterns)
+- Integration Guidelines (how to interact with other component types)
+
+**Domain Knowledge:**
+- Business Context (purpose, business value, compliance constraints)
+- Core Business Rules (rules with examples and edge cases)
+- State Transitions (workflow states and triggers)
+- Technical Implementation Patterns (code patterns specific to this domain)
+- Error Handling and Recovery (domain-specific failure modes)
+
+**Lessons Learned:**
+- Per lesson: Incident Context → Root Cause → Impact → Code showing problem and solution → Prevention Strategy
+
+## Worked Example
+
+This is what a complete, well-structured feature knowledge entry looks like. Use it as a reference for quality and format.
+
+````markdown
+---
+feature: integrations
+name: Third-Party Integrations
+description: "Use when adding a new vendor integration, implementing API clients, or connecting to external services. Keywords: integration, vendor, API client, webhook, spawn, config."
+category: component-patterns
+directories: [src/lib/]
+created: 2026-04-30
+updated: 2026-04-30
+---
+
+# Third-Party Integrations
+
+## Rules
+
+- **KB-AP-1** Fetch logic never lives in a command file: it breaks the lib/command split and cannot be tested alone.
+- **KB-AP-2** URLs never live in lib modules: they go through `config.ts`.
+- **KB-AP-3** A lib module never calls `showError()`: lib modules throw, commands catch and display.
+- **KB-AP-4** `spawn` needs the binary on PATH: detect `ENOENT` and give an install URL.
+- **KB-INV-1** Every external constant lives in `src/lib/config.ts`.
+
+## Overview
+
+This project integrates with external systems by spawning CLI processes, fetching files from remote registries, and writing to directories that AI editors watch. Each integration lives in its own module under `src/lib/` and is wired into a command in `src/commands/`. All external constants are centralized in `src/lib/config.ts`.
+
+The key cross-cutting pattern is the separation between lib modules (which integrate) and commands (which orchestrate). Violating this creates coupling that breaks the error handling model.
+
+## Core Responsibilities
+
+- Lib modules: integrate with external systems, export async functions, throw on failure
+- Commands: orchestrate lib modules, catch errors, route to UI via `showError()`
+- Config: centralize all external constants, expose env var overrides
+
+## Standard Structure
+
+Every integration follows the same file organization. This example shows the pattern that every existing integration (Claude CLI, GitHub, AI editors) follows:
+
+```
+src/lib/
+  claude.ts          # Claude Code CLI (spawn + stream JSON)
+  skill-installer.ts # GitHub (git clone, sparse checkout)
+  deploy.ts          # AI editors (.claude/, .cursor/ dirs)
+  config.ts          # All constants for the above
+```
+
+A new integration means a new file here. The module exports async functions, imports from `config.ts`, and never imports from `src/ui/` or `src/commands/`.
+
+### Config Centralization
+
+URLs, subpaths, install directories — these change together. One file to update when an upstream moves:
+
+All constants use `SCREAMING_SNAKE_CASE` with a descriptive prefix. If a value can be overridden by the user, expose an env var with a sensible default.
+
+## Anti-Patterns
+
+- **KB-AP-1, putting fetch logic in a command file** — breaks the lib/command separation and makes the integration untestable in isolation.
+- **KB-AP-2, hardcoding URLs in lib modules** — always use `config.ts`. Scattered strings become stale and hard to find.
+- **KB-AP-3, calling `showError()` from a lib module** — lib modules throw; commands catch and display.
+
+## Gotchas
+
+- **KB-AP-4**: `spawn` requires the binary on PATH. If integrating a tool that may not be globally installed, detect `ENOENT` and provide an install URL.
+- Temp files use `Date.now()`. If two processes run simultaneously, add a random suffix to avoid collisions.
+
+## Key Files
+
+- `src/lib/config.ts` — add constants here before writing integration code
+- `src/lib/claude.ts` — reference implementation for spawn-and-stream pattern
+- `src/lib/skill-installer.ts` — reference implementation for fetch-from-remote pattern
+
+## Related
+
+- `.devflow/features/cli-commands/KNOWLEDGE.md` — the command side of the lib/command split: catching errors and routing them to `showError()`
+- `src/commands/` — where each integration is wired into a command
+````

package/src/assets/skills/gap-analysis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gap-analysis
-description: This skill should be used when analyzing specs or plans for completeness gaps.
+description: Use when analyzing specs or plans for completeness gaps.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---
@@ -17,14 +17,10 @@ Domain expertise for detecting gaps in design documents, specifications, and pla
 > waiting to be written. Catch gaps in the plan so the implementation reflects reality,
 > not assumption. Evidence-required: every gap must cite specific text from the artifact.
 
----
-
 ## Focus Areas
 
 ### 1. Completeness
 
-Detect missing pieces that will block or break implementation.
-
 **Detection patterns:**
 - Missing acceptance criteria — requirements without testable success conditions
 - Undefined error states — happy path described, failure paths absent
@@ -37,8 +33,6 @@ Detect missing pieces that will block or break implementation.
 
 ### 2. Architecture
 
-Detect design decisions that conflict with existing patterns or create structural problems.
-
 **Detection patterns:**
 - Implied patterns violating existing conventions — new module structure that contradicts codebase layout
 - Missing integration points — feature touches shared state but integration method unspecified
@@ -51,8 +45,6 @@ Detect design decisions that conflict with existing patterns or create structura
 
 ### 3. Security
 
-Detect authentication, authorization, and data protection gaps.
-
 **Detection patterns:**
 - Auth gaps — feature creates new endpoints or data access without specifying auth requirements
 - Input validation missing — user-provided data consumed without specifying sanitization
@@ -65,8 +57,6 @@ Detect authentication, authorization, and data protection gaps.
 
 ### 4. Performance
 
-Detect design decisions that will cause performance problems at scale.
-
 **Detection patterns:**
 - N+1 patterns implied — loop-based data fetching without batch operation specified
 - Missing caching strategy — repeated expensive operations (DB queries, API calls) without cache layer
@@ -79,8 +69,6 @@ Detect design decisions that will cause performance problems at scale.
 
 ### 5. Consistency (multi-issue only)
 
-Detect contradictions and duplications across multiple issue specifications.
-
 **Detection patterns:**
 - Cross-issue contradictions — Issue A says feature X works one way, Issue B implies another
 - Duplicate requirements — same functionality specified in multiple issues without coordination
@@ -92,8 +80,6 @@ Detect contradictions and duplications across multiple issue specifications.
 
 ### 6. Dependencies (multi-issue only)
 
-Detect ordering constraints and shared resource conflicts across issues.
-
 **Detection patterns:**
 - Inter-issue ordering — Issue B depends on data/schema/interface created by Issue A
 - Shared resources — multiple issues modify the same file, table, or API without coordination
@@ -103,8 +89,6 @@ Detect ordering constraints and shared resource conflicts across issues.
 
 **Evidence trigger:** Any issue that references state, contracts, or resources that may be in flux due to another issue in the batch.
 
----
-
 ## Extended References
 
 | Reference | Content |
@@ -119,17 +103,3 @@ Detect ordering constraints and shared resource conflicts across issues.
 | **HIGH** | Gap that will cause incorrect behavior or significant technical debt | Missing pagination on unbounded list, undefined race condition in concurrent update |
 | **MEDIUM** | Gap that will require rework if unaddressed | Vague acceptance criteria, missing caching strategy for frequently-read data |
 | **LOW** | Gap that is an improvement opportunity | Naming inconsistency, minor UX ambiguity with obvious resolution |
-
-## Confidence Calibration
-
-- **Report at 80%+**: Gap is clearly present, evidence directly cited
-- **Suggest at 60-79%**: Plausible gap, depends on context not visible in artifact
-- **Drop below 60%**: Speculation without textual evidence
-
-Output format per gap:
-```
-**[FOCUS] Gap: {title}** — Severity: {CRITICAL/HIGH/MEDIUM/LOW} | Confidence: {n}%
-Evidence: "{quoted text from artifact}"
-Issue: {what is missing or contradictory}
-Resolution: {concrete action to address the gap}
-```

package/src/assets/skills/git/SKILL.md

@@ -7,24 +7,16 @@ allowed-tools: Bash, Read, Grep, Glob
 
 # Git & GitHub Patterns
 
-Unified skill for safe git operations, atomic commits, honest PR descriptions, and GitHub API interactions. Used by the Code agent and Git agent.
+Safe git operations, atomic commits, honest PR descriptions, and GitHub API calls.
 
 ## Iron Law
 
-> **EVERY COMMIT TELLS AN HONEST, ATOMIC STORY** [1][3]
+> **Every commit tells an honest, atomic story.**
 >
 > Each commit captures one logical change with a message that explains *what* changed
 > and *why*, not just *how*. Atomic commits make history reviewable, bisectable, and
 > revertable. Never bundle unrelated changes. Never write vague messages.
 
----
-
-## When This Skill Activates
-
-Any `git` or `gh` operation: staging, commits, branches, pull requests, rebases, issues, releases.
-
----
-
 ## Safety
 
 ### Lock File Handling
@@ -79,12 +71,8 @@ git reset HEAD~1         # Undo commit, keep unstaged
 
 See `references/patterns.md` for extended recovery and stash workflows.
 
----
-
 ## Commits
 
-> **ONE LOGICAL CHANGE PER COMMIT, HONESTLY DESCRIBED**
-
 ### Message Format
 
 ```
@@ -131,8 +119,6 @@ EOF
 2. **By Type**: Source code, tests, docs, config separately
 3. **By Relationship**: Files that change together for single logical purpose
 
----
-
 ## Pull Requests
 
 ### Title Format
@@ -158,8 +144,6 @@ EOF
 | Large | 500-1000 | Recommend splitting |
 | Very Large | > 1000 | **WARN**: Split into smaller PRs |
 
----
-
 ## Sensitive File Detection
 
 ### Never Commit These Patterns
@@ -181,16 +165,12 @@ Block commits containing:
 
 See `references/detection.md` for full `check_for_secrets()` function.
 
----
-
 ## GitHub API
 
 > **RESPECT RATE LIMITS OR FAIL GRACEFULLY** — at `X-RateLimit-Remaining` < 10 STOP the fan-out and report `THROTTLED` (D4); 1-2s between calls. Throttling and releases: `references/github-api.md`; posting steps, where installed: `references/github-posting.md`.
 
 Naming conventions: `learn-conventions` writes `.devflow/conventions.md` from a bounded scan (≤50 branches, ≤20 tags, ≤30 PR titles) and is its single authority; delete that file to re-learn.
 
----
-
 ## Extended References
 
 | Reference | Contents |