diff --git a/apps/skills/plannotator-compound/SKILL.md b/apps/skills/plannotator-compound/SKILL.md new file mode 100644 index 00000000..9fec79ec --- /dev/null +++ b/apps/skills/plannotator-compound/SKILL.md @@ -0,0 +1,402 @@ +--- +name: plannotator-compound +description: > + Analyze a user's Plannotator plan archive to extract denial patterns, feedback + taxonomy, evolution over time, and actionable prompt improvements — then produce + a polished HTML dashboard report. Use this skill when the user says things like + "/compound-planning", "analyze my plans", "plan analysis", "what are my denial + patterns", "why do my plans get denied", "compound planning report", "plan + insights", or "analyze my planning data". This is a user-invoked skill only — + do not trigger automatically. The user must explicitly request it. +--- + +# Compound Planning Analysis + +You are conducting a comprehensive research analysis of a user's Plannotator plan +archive. The goal: extract patterns from their denied plans and annotations, reduce +them into actionable insights, and produce an elegant HTML dashboard report. + +This is a multi-phase process. Each phase must complete fully before the next begins. +Research integrity is paramount — every file must be read, no skipping. + +## Phase 0: Locate the Plans Directory + +Check for `~/.plannotator/plans/`. If it exists and contains `.md` files, proceed. + +If not found, ask the user: +> "I couldn't find plans at ~/.plannotator/plans/. Where is your plans directory?" + +Once you have the path, verify it contains files matching `*-denied.md` and/or +`*.annotations.md`. If neither exist, inform the user there's no denial/annotation +data to analyze and stop. + +## Phase 1: Inventory + +Count and report the dataset: + +``` +- *-approved.md files (count) +- *-denied.md files (count) +- *.annotations.md files (count) +- *.diff.md files (count) +- Date range (earliest to latest date found in filenames) +- Total days spanned +- Revision rate: denied / (approved + denied) — this is the "X% of plans + revised before coding" stat used in dashboard section 1 +``` + +Also run `wc -l` across all `*-approved.md` files to get average lines per +approved plan. This tells the user whether their plans are staying lightweight +or bloating over time. You do not need to read approved plan contents — just +their line counts. If possible, break this down by time period (e.g., monthly) +to show whether plan size changed. + +Dates appear in filenames in YYYY-MM-DD format, sometimes as a prefix +(2026-01-07-name-approved.md) and sometimes embedded (name-2026-03-15-approved.md). +Extract dates from all filenames. + +Tell the user what you found and that you're beginning the extraction. + +## Phase 2: Map — Parallel Extraction + +This is the most time-intensive phase. You must read EVERY denied plan and EVERY +annotation file. Do not skip files. Do not summarize early. + +**Important:** Do NOT read approved plan files. They are counted in the inventory +for context (total volume, approval rate) but are not analyzed for feedback +patterns. Only `*-denied.md` and `*.annotations.md` files contain the feedback +data this analysis needs. + +### Batching Strategy + +The approach depends on dataset size: + +**Small datasets (< 40 total files):** Read all files directly — no need for +parallel agents. Just read them sequentially and proceed to Phase 3. + +**Medium datasets (40-120 files):** Split into 2-4 parallel agents by file type +and/or time period. + +**Large datasets (120+ files):** Split into batches of ~40-60 files per agent. +Split by the natural time boundaries in the data (months, quarters, or whatever +groupings produce balanced batches). If one time period dominates (e.g., the most +recent month has 3x the files), split that period into two batches. + +Launch all extraction agents in parallel using the Agent tool with +`run_in_background: true`. + +### Output Files + +Each extraction agent must write its results to a clean output file rather than +relying on the agent task output (which contains interleaved JSONL framework +logs that are difficult to parse). Instruct each agent to write to: + +``` +/tmp/compound-planning/extraction-{batch-name}.md +``` + +Create the `/tmp/compound-planning/` directory before launching agents. The +reduce agent in Phase 3 will read these clean files directly. + +### Extraction Prompt for Denied Plans + +Each agent for denied plans receives this instruction (adapt the time period, +file glob, and output path): + +``` +You are extracting structured data from denied plan files for a pattern analysis. + +Directory: [PLANS DIRECTORY] +Files to read: All *-denied.md files with dates in [TIME PERIOD] +Output: Write your complete results to [OUTPUT FILE PATH] + +Read EVERY matching file. For EACH file, extract: +- The plan name/topic +- The denial reason or feedback given (look for reviewer comments, annotations, + revision requests — capture the actual words used) +- What was specifically asked to change +- The type of feedback (let the content determine the category — don't force-fit + into predefined types. Common types include things like: scope concerns, + approach disagreements, missing information, process requirements, quality + concerns, UX/design issues, naming disputes, clarification requests, + testing/procedural denials — but the user's actual patterns may differ) +- Any specific phrases or recurring language from the reviewer +- The date + +Do NOT skip any files. One entry per file. + +Format each entry as: +**[filename]** +- Date: ... +- Topic: ... +- Denial reason: ... +- Feedback type: ... +- Specific asks: ... +- Notable phrases: ... +--- + +After processing all files, write the complete results to [OUTPUT FILE PATH]. +State the total file count at the end of the file. +``` + +### Extraction Prompt for Annotation Files + +Annotation files have a different structure — they contain inline comments, +highlights, and feedback left on specific sections of plans. Each agent for +annotations receives this instruction: + +``` +You are extracting structured data from annotation files for a pattern analysis. + +Directory: [PLANS DIRECTORY] +Files to read: All *.annotations.md files with dates in [TIME PERIOD] +Output: Write your complete results to [OUTPUT FILE PATH] + +Read EVERY matching file. For EACH file, extract: +- The plan name/topic it annotates +- Every individual annotation/comment made (there may be multiple per file) +- For each annotation: the quoted text, what type of feedback it is (correction, + scope concern, design preference, structural request, question, praise, + process directive, etc.), and what section of the plan was annotated +- The overall tone of the feedback + +Do NOT skip any files. One entry per file. + +Format each entry as: +**[filename]** +- Plan topic: ... +- Annotations found: [count] +- Annotation 1: "[quote or paraphrase]" — Type: ... — Section: ... +- Annotation 2: "[quote or paraphrase]" — Type: ... — Section: ... +- (continue for all annotations in the file) +- Overall tone: ... +--- + +After processing all files, write the complete results to [OUTPUT FILE PATH]. +State the total file count at the end of the file. +``` + +### While Agents Run + +Track completion. As each agent finishes, note the count of files it processed. +Verify the total matches the inventory from Phase 1. If any agent's count is +short, flag it and consider re-launching for the missing files. + +If an agent times out (possible with large batches — a batch of 128 files can +take 8+ minutes), re-launch it for just the unprocessed files. Check the output +file to see how far it got before timing out. + +## Phase 3: Reduce — Pattern Analysis + +Once ALL extraction agents have completed (or all files have been read for small +datasets), launch a single reduction agent. + +The reduction agent reads the clean extraction files from `/tmp/compound-planning/` +(not the agent task output files, which contain noisy JSONL framework logs). It +processes all extraction files together and produces the comprehensive analysis. + +Give the reduction agent this prompt (adapt the file paths): + +``` +You are a data scientist conducting the reduction phase of a map-reduce analysis +across a user's plan denial and annotation archive. + +Read ALL extraction files at /tmp/compound-planning/extraction-*.md + +These files contain structured extractions from every denied plan and annotation +file. Your job: aggregate everything, find patterns, cluster into a taxonomy, +and produce a comprehensive analysis. + +Be exhaustive. Use real counts. Quote real phrases from the data. This is +research — no hand-waving, no fabrication. + +Produce the following sections: +[... sections listed below ...] +``` + +The reduction agent's job is to let the data speak. Do not impose a predetermined +framework — discover what's actually there. The analysis must produce: + +### 1. Denial Reason Taxonomy +Categorize every denial into a finite set of types that emerge from the data. Count +occurrences. Show percentages. Include real example quotes for each type. Aim for +8-15 categories — enough to be specific, few enough to be scannable. Let the user's +actual feedback determine what the categories are. + +### 2. Top Feedback Patterns (ranked by frequency) +The 5-10 most recurring patterns. For each: what the reviewer consistently asks for, +3+ example quotes from different files, and whether the pattern changed over time. + +### 3. Recurring Phrases +Exact phrases the reviewer uses repeatedly, with counts and what they signal. These +are the reviewer's vocabulary — their shorthand for what they care about. + +### 4. What the Reviewer Values (implicit preferences) +Derived from patterns — what does this specific person care about most? Quality? +Speed? Narrative? Architecture? Process? Simplicity? Rank by evidence strength. +This section should feel like a personality profile of the reviewer's standards. + +### 5. What Agents Consistently Get Wrong +The flip side — what recurring mistakes trigger denials? What should agents stop +doing for this reviewer? + +### 6. Structural Requests +What plan structure does the reviewer consistently demand? Required sections, +ordering, format preferences, level of detail expected. + +### 7. Evolution Over Time +How feedback patterns changed across the time span. Group by whatever natural time +boundaries exist in the data (weeks for short spans, months for longer ones). Did +expectations mature? Did new patterns emerge? What shifted? If the dataset spans +less than a month, note that evolution analysis is limited but still look for any +progression from early to late files. + +### 8. Actionable Prompt Instructions +The most important output. Based on all patterns: specific numbered instructions +that could be embedded in a planning prompt to prevent the most common denial +reasons. Write these as actual directives an agent could follow. Be specific to +this user's patterns — generic advice like "write good plans" is worthless. Each +instruction should trace back to a real, frequent denial pattern. + +After writing the instructions, calculate what percentage of denials they would +address (count how many denials fall into categories covered by the instructions +vs total denials). Report this percentage — it will be different for every user. + +## Phase 4: Generate the HTML Dashboard + +Build a single, self-contained HTML file as the final deliverable. Save it to +the user's plans directory as `compound-planning-report.html`. + +Read the template at `assets/report-template.html` for the **design language +only**. The template contains example data from a previous analysis — ignore all +data values, quotes, and percentages in the template. Use only its visual design: +colors, typography, spacing, component styles, and layout patterns. + +### Design Language (from template) + +- **Palette:** Light mode, warm off-white (#FDFCFB), text in slate scale, amber + for highlights/accents, emerald for positive, rose for negative, indigo for + action elements +- **Typography:** Playfair Display (serif, for narrative headings), Inter (sans, + for body/data), JetBrains Mono (mono, for code/phrases) — Google Fonts CDN +- **Layout:** Single-column, max-width 1024px, generous vertical whitespace (128px + between major sections), editorial/narrative-first aesthetic +- **Tone:** Calm, reflective, authoritative. Like a personal retrospective journal, + not a monitoring dashboard. + +### Page Frame (header + footer) + +Before the 7 sections, the page has: + +- **Header:** Report title on the left (Playfair Display, ~36px), project name + + date range below it in light meta text. On the right: file counts in mono + (e.g., "202 denials · 168 annotations · 71 days"). Separated from content by + a bottom border. Generous bottom padding before section 1. + +- **Footer:** After section 7. Top border, centered italic Playfair Display tagline + summarizing the corpus (e.g., "Analysis of X denied plans and Y annotation files + from the Plannotator archive."). + +### Dashboard Section Order (7 sections) + +The report follows this exact section order. Each section builds on the previous +one — the flow moves from "what happened" through "why" to "what to do about it": + +1. **The story in the data** — An editorial narrative paragraph (Playfair Display + serif, ~26px) that tells the headline finding in prose. Not bullet points — a + real paragraph that reads like the opening of an article. Alongside it, a KPI + sidebar with 3 key metrics (the top denial percentage, the overall revision + rate, and the number of distinct denial categories found). Use an amber inline + highlight on the most striking number in the narrative. + +2. **Why plans get denied** — The taxonomy as a ranked list. Each row: rank number + (mono), category label, a thin 4px progress bar (top item in amber-500, rest + in slate-300), percentage (mono), and for the top entries, a real italic quote + from the data below the label. Show the top 10 categories or however many the + data supports (minimum 5). + +3. **How expectations evolved** — One card per natural time period. Each card has: + the period name in serif, a theme phrase in colored uppercase (different color + per period to show progression), a description paragraph, and a stat line at + the bottom (e.g., "X denials · Y narrative requests"). If the data spans less + than 3 distinct periods, use 2 cards or even a single card with internal + progression noted. + +4. **What works vs what doesn't** — Two side-by-side cards. Left: green-tinted + (emerald-50/50 bg, emerald-100 border) with traits of plans that succeed for + this reviewer. Right: red-tinted (rose-50/50 bg, rose-100 border) with what + agents keep getting wrong. Both derived from the reduction analysis. Bulleted + with small colored dots. 5-8 items per card. + +5. **The actionable output** — The diagnostic payoff. Opens with a Playfair + Display narrative sentence stating how many prompt instructions were derived + and what estimated percentage of denials they address (use the real calculated + percentage from Phase 3, not a generic number). Then the top 3 most impactful + improvements as numbered items, each with an amber number, bold title, and + one-line description. This section bridges the analysis and the full prompt + that follows. + +6. **Your most-used phrases** — Grid of chips (2-col mobile, 3-col desktop). Each + chip: monospace quoted phrase on the left, frequency count on the right. White + bg, slate-200 border, rounded-12px. Show 9-12 of the most recurring phrases + found. These should be the reviewer's actual words — their verbal fingerprint. + +7. **The corrective prompt** — Dark panel (slate-900 bg, white text, rounded-3xl, + shadow-xl). Opens with a Playfair intro sentence about the instructions. Then + a dark code block (slate-800/80 bg, amber-200 monospace text) containing the + full numbered prompt instructions from Phase 3. Include a copy-to-clipboard + button that works (JS included). Below the code block: a gradient glow card + (indigo-to-purple blurred halo behind a white card) with a closing message + that these instructions are personal — derived from the user's own feedback, + their own language, their own standards. + +### Adaptation Rules + +- If the user has < 3 months of data, reduce the evolution section to fewer cards +- If the user has no annotation files (only denials), note this in the narrative + and skip annotation-specific insights +- If fewer than 5 denial categories emerge, combine the taxonomy and patterns + sections into one +- If the dataset is very small (< 20 files), the narrative should acknowledge the + limited sample size and frame findings as preliminary +- The number of prompt instructions will vary per user — could be 8 or 20. Don't + force exactly 17. Let the data determine the count. +- The top 3 actionable items in section 5 must be the 3 that cover the largest + share of denials, not the 3 that sound most impressive + +### Key Rules + +1. Every number must come from the real analysis — no fabricated data +2. Every quote must be a real quote from a real file +3. The taxonomy percentages must be calculated from real counts +4. The prompt instructions must trace back to actual denial patterns +5. The copy button on the prompt block must work (include the JS) + +After generating, open the file in the user's browser. + +## Phase 5: Summary + +Tell the user: +- How many total files were analyzed (denials + annotations) +- The top 3 denial patterns found +- The estimated percentage of denials the prompt instructions would address +- The single most impactful prompt improvement +- Where the report was saved + +## Important Notes + +- **Research integrity:** Every file must be read. The value of this analysis comes + from completeness. Sampling or skipping undermines the findings. +- **Real data only:** Never fabricate quotes, percentages, or patterns. If the data + doesn't show a clear pattern, say so honestly rather than inventing one. +- **Let the data lead:** The taxonomy, patterns, and instructions should emerge from + what's actually in the files. Different users will have completely different + denial patterns. A user building mobile apps will have different feedback than + one building APIs. Don't assume what the patterns will be. +- **Agent parallelization:** For large datasets, maximize parallel agents to reduce + wall-clock time. The bottleneck is the largest batch — split it. +- **Structured extraction format:** Ask extraction agents to return structured text + with consistent delimiters so the reduce agent can parse reliably. +- **The report is the artifact:** The HTML dashboard is what the user keeps. It + should be beautiful, honest, and useful. Every section should feel like it was + written about them specifically, because it was. diff --git a/apps/skills/plannotator-compound/assets/report-template.html b/apps/skills/plannotator-compound/assets/report-template.html new file mode 100644 index 00000000..5953b536 --- /dev/null +++ b/apps/skills/plannotator-compound/assets/report-template.html @@ -0,0 +1,795 @@ + + + + + +Compound Planning — What 370 Files Reveal + + + + + +
+ +
+
+

What 370 Files Reveal About
How You Plan

+
backnotprop/plannotator · Jan 7 – Mar 18, 2026
+
+
+ 202 denials · 168 annotations · 71 days +
+
+ + +
+ +
+
+ Across 71 days you denied or revised 202 plans before any code was written. The single most common reason—appearing in 1 out of 4 denials—was the same: the agent jumped to implementation without telling you what it was building, why, or how. Missing narrative. Missing context. Missing the story. Your expectations evolved from “does it work?” in January to “tell me the story and be confident” by March. +
+
+
+
25.7%
+
Denials for missing narrative
+
+
+
50%
+
Plans revised before coding
+
+
+
12
+
Distinct denial categories
+
+
+
+
+ + +
+ +
+
+ 1 +
+ Missing Narrative / Overview +
+ "This plan is denied without narrative detail and rationales." +
+ 25.7% +
+
+ 2 +
+ Clarification Needed +
+ "What does this Mean???" +
+ 16.8% +
+
+ 3 +
+ Testing / Procedural +
+ "I'm denying so you can create a diff." +
+ 13.9% +
+
+ 4 +
+ Wrong Approach / Over-Engineered +
+ "Why are we doing difficult shit here? I want a hover experience." +
+ 9.4% +
+
+ 5 +
+ Process Requirement +
+ "Make sure you feature branch." +
+ 7.9% +
+
+ 6 +
+ Confidence / Risk Check +
+ "Take a step back, breathe, make sure we're not being irrational." +
+ 7.4% +
+
+ 7 +
+ Content Removal +
+ "I don't want this in the plan." +
+ 6.9% +
+
+ 8 +
+ Implementation Bug Found +
+
+ 5.9% +
+
+ 9 +
+ Design / UX Issue +
+
+ 5.4% +
+
+ 10 +
+ Naming / Terminology +
+ "Why do you keep calling it Simplified????" +
+ 4.0% +
+
+
+ + +
+ +
+
+
January
+
"Does it work?"
+
Bug-hunting phase. You were hands-on testing View Logs, iterating on session scoping heuristics. 60% of denials were implementation bugs and verification failures. No mention of “narrative” or “overview” yet.
+
26 denials · 0 narrative requests
+
+
+
February
+
"Follow the process"
+
Process gates emerged: feature branches, Linear tickets, pull main. 40% of denials were procedural (diff testing). UX polish intensified. The first narrative demands appeared: “I want a narrative under each section.”
+
48 denials · 6 narrative requests
+
+
+
March
+
"Tell me the story"
+
Narrative became the #1 gate. You created a “Missing overview” label and applied it systematically. Confidence checks became standard. You began telling agents to “take a step back, breathe, and analyze.”
+
128 denials · 25+ narrative requests
+
+
+
+ + +
+ +
+
+
✓
+
What approved plans do
+
    +
  • Lead with a narrative overview: what exists, what changes, why
  • +
  • State confidence and identify risks proactively
  • +
  • Reference existing codebase patterns before proposing new code
  • +
  • Use explicit, transparent naming (not euphemisms)
  • +
  • Break large work into phases with evaluation gates
  • +
  • Include example output for user-facing changes
  • +
  • Specify feature branch and ticket creation steps
  • +
+
+
+
✗
+
What agents keep getting wrong
+
    +
  • Jump to implementation steps without narrative context
  • +
  • Over-engineer: Shift+Click when hover works, MCP tool when a README suffices
  • +
  • Introduce new code for things the codebase already solves
  • +
  • Propose work on top of failing lint/type checks
  • +
  • Use vague or euphemistic naming (“Accept” instead of “Git Add”)
  • +
  • Wait to be asked for confidence instead of stating it
  • +
  • Rush to modify instead of reporting what they see
  • +
+
+
+
+ + +
+ +
+ The analysis produced 17 specific prompt instructions that, if embedded in a planning prompt, would address ~70% of all denial reasons. The biggest three: +
+
+
+ 1 +
+
Every plan MUST start with a Solution Overview
+
What exists, what changes, why, how. This alone addresses 1 in 4 denials.
+
+
+
+ 2 +
+
End every plan with a Confidence Assessment
+
Don’t wait to be asked. State your confidence, identify risks, flag uncertainties.
+
+
+
+ 3 +
+
Search for existing patterns before proposing new code
+
Explicitly state what you found in the codebase. Prefer reuse over new implementation.
+
+
+
+
+ + +
+ +
+
"narrative"50+
+
"I don't want this in the plan"10
+
"feature branch"8+
+
"confidence"8+
+
"Missing overview"14
+
"front-end design skill"16
+
"separation of concerns"6
+
"Take a step back, breathe"6
+
"how does this work"5+
+
"what the fuck"4
+
"create a ticket"4+
+
"reusable"19+
+
+
+ + +
+
+ +
+ These 17 instructions were extracted directly from your denial patterns. Embedding them in a planning prompt would address approximately 70% of all denial reasons. +
+
+
+ + + planning-instructions.md + + +
+
+
# Planning Instructions
+# Derived from 370 files of denial & annotation analysis
+
+1. STRUCTURE: Every plan MUST begin with a "Solution Overview"
+   containing 2-3 paragraphs of narrative prose explaining:
+   - What exists today (current state)
+   - What will change and why
+   - How it will be built (approach summary)
+   Do NOT skip this. Do NOT replace it with bullet points.
+
+2. NARRATIVE: Every major section must include a rationale
+   paragraph — not just what will be done, but WHY this
+   approach was chosen over alternatives.
+
+3. FEATURE BRANCH: Always specify implementation will occur
+   on a feature branch. State the branch name. Never plan
+   to work directly on main.
+
+4. EXISTING PATTERNS: Before proposing any new implementation,
+   search the codebase for existing patterns that solve the
+   same problem. Explicitly state what you found and whether
+   you will reuse it. Prefer reuse over new code.
+
+5. CONFIDENCE STATEMENT: End the plan with a "Confidence
+   Assessment" section. State your confidence level, identify
+   risks or edge cases, and note uncertainties. Do not wait
+   to be asked.
+
+6. PHASING: For plans with more than 3 steps, break them into
+   numbered phases. After each phase, note "Pause for
+   evaluation" so the reviewer can assess before proceeding.
+
+7. ISSUE TRACKING: If the project uses Linear or GitHub Issues,
+   include a step to create relevant tickets BEFORE
+   implementation. Backlog items should be separate tickets.
+
+8. SIMPLICITY: Choose the simplest approach that meets
+   requirements. Do not introduce modifier keys when hover
+   works. Do not build a framework when a README suffices.
+
+9. NAMING: Use explicit, transparent names for user-facing
+   features. Do not euphemize Git operations ("Git Add"
+   not "Accept"). Match existing product naming conventions.
+
+10. CODE QUALITY: State that implementation will follow clean
+    code principles: modular architecture, separation of
+    concerns, no circumventing lint or type checks.
+
+11. CLEAN FOUNDATION: If the codebase has failing lint or type
+    checks, address these BEFORE proposing new features. State
+    the current CI/CD state.
+
+12. PRIVACY: For features involving data storage or sharing,
+    explicitly state privacy guarantees. Require user
+    confirmation before storing data.
+
+13. EXAMPLES: When the plan involves user-facing output or UI,
+    include an example of what it will look like.
+
+14. FOCUSED SCOPE: Do not include sections that are obvious,
+    boilerplate, or previously asked to be removed. Keep the
+    plan focused rather than comprehensive.
+
+15. DESIGN SKILL: For any frontend/UI work, invoke the
+    front-end design skill to validate the approach. Note
+    this invocation explicitly in the plan.
+
+16. VERIFICATION STEP: For refactors or multi-file changes,
+    include a verification step with line-by-line comparison
+    of affected code paths.
+
+17. DELIBERATION: If the plan involves a dramatic shift, state
+    that you have re-evaluated the approach, traced through
+    affected files mentally, and are confident in the plan.
+    Do not rush.
+
+
+ +
+
+
+
+ These instructions are yours — derived from your feedback, your language, your standards. Copy them into your planning prompt and watch the deny rate drop. +
+
+
+
+
+ + + +
+ + + + diff --git a/scripts/install.cmd b/scripts/install.cmd index 9e09894e..62114dfd 100644 --- a/scripts/install.cmd +++ b/scripts/install.cmd @@ -224,6 +224,45 @@ echo Address the annotation feedback above. The user has reviewed your last mess echo Installed /plannotator-last command to !CLAUDE_COMMANDS_DIR!\plannotator-last.md +REM Install skills (requires git) +where git >nul 2>&1 +if !ERRORLEVEL! equ 0 ( + if defined CLAUDE_CONFIG_DIR ( + set "CLAUDE_SKILLS_DIR=%CLAUDE_CONFIG_DIR%\skills" + ) else ( + set "CLAUDE_SKILLS_DIR=%USERPROFILE%\.claude\skills" + ) + if defined XDG_CONFIG_HOME ( + set "AGENTS_SKILLS_DIR=%XDG_CONFIG_HOME%\agents\skills" + ) else ( + set "AGENTS_SKILLS_DIR=%USERPROFILE%\.config\agents\skills" + ) + set "SKILLS_TMP=%TEMP%\plannotator-skills-%RANDOM%" + mkdir "!SKILLS_TMP!" >nul 2>&1 + + git clone --depth 1 --filter=blob:none --sparse "https://github.com/!REPO!.git" --branch "!TAG!" "!SKILLS_TMP!\repo" >nul 2>&1 + if !ERRORLEVEL! equ 0 ( + pushd "!SKILLS_TMP!\repo" + git sparse-checkout set apps/skills >nul 2>&1 + + if exist "apps\skills" ( + if not exist "!CLAUDE_SKILLS_DIR!" mkdir "!CLAUDE_SKILLS_DIR!" + if not exist "!AGENTS_SKILLS_DIR!" mkdir "!AGENTS_SKILLS_DIR!" + xcopy /s /y /q "apps\skills\*" "!CLAUDE_SKILLS_DIR!\" >nul 2>&1 + xcopy /s /y /q "apps\skills\*" "!AGENTS_SKILLS_DIR!\" >nul 2>&1 + echo Installed skills to !CLAUDE_SKILLS_DIR!\ and !AGENTS_SKILLS_DIR!\ + ) + + popd + ) else ( + echo Skipping skills install ^(git sparse-checkout failed^) + ) + + rmdir /s /q "!SKILLS_TMP!" >nul 2>&1 +) else ( + echo Skipping skills install ^(git not found^) +) + echo. echo Test the install: echo echo {"tool_input":{"plan":"# Test Plan\\n\\nHello world"}} ^| plannotator diff --git a/scripts/install.ps1 b/scripts/install.ps1 index 4231c48c..13795e68 100644 --- a/scripts/install.ps1 +++ b/scripts/install.ps1 @@ -217,6 +217,39 @@ description: Annotate the last assistant message Write-Host "Installed /plannotator-last command to $opencodeCommandsDir\plannotator-last.md" +# Install skills (requires git) +if (Get-Command git -ErrorAction SilentlyContinue) { + $claudeSkillsDir = if ($env:CLAUDE_CONFIG_DIR) { "$env:CLAUDE_CONFIG_DIR\skills" } else { "$env:USERPROFILE\.claude\skills" } + $agentsSkillsDir = if ($env:XDG_CONFIG_HOME) { "$env:XDG_CONFIG_HOME\agents\skills" } else { "$env:USERPROFILE\.config\agents\skills" } + $skillsTmp = Join-Path ([System.IO.Path]::GetTempPath()) "plannotator-skills-$(Get-Random)" + New-Item -ItemType Directory -Force -Path $skillsTmp | Out-Null + + try { + git clone --depth 1 --filter=blob:none --sparse "https://github.com/$repo.git" --branch $latestTag "$skillsTmp\repo" 2>$null + Push-Location "$skillsTmp\repo" + git sparse-checkout set apps/skills 2>$null + + if (Test-Path "apps\skills") { + $items = Get-ChildItem "apps\skills" -ErrorAction SilentlyContinue + if ($items) { + New-Item -ItemType Directory -Force -Path $claudeSkillsDir | Out-Null + New-Item -ItemType Directory -Force -Path $agentsSkillsDir | Out-Null + Copy-Item -Recurse -Force "apps\skills\*" $claudeSkillsDir + Copy-Item -Recurse -Force "apps\skills\*" $agentsSkillsDir + Write-Host "Installed skills to $claudeSkillsDir\ and $agentsSkillsDir\" + } + } + + Pop-Location + } catch { + Write-Host "Skipping skills install (git sparse-checkout failed)" + } + + Remove-Item -Recurse -Force $skillsTmp -ErrorAction SilentlyContinue +} else { + Write-Host "Skipping skills install (git not found)" +} + Write-Host "" Write-Host "==========================================" Write-Host " OPENCODE USERS" diff --git a/scripts/install.sh b/scripts/install.sh index 000f69e2..6293bc66 100644 --- a/scripts/install.sh +++ b/scripts/install.sh @@ -213,6 +213,33 @@ COMMAND_EOF echo "Installed /plannotator-last command to ${OPENCODE_COMMANDS_DIR}/plannotator-last.md" +# Install skills (requires git) +if command -v git &>/dev/null; then + CLAUDE_SKILLS_DIR="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills" + AGENTS_SKILLS_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/agents/skills" + skills_tmp=$(mktemp -d) + + if git clone --depth 1 --filter=blob:none --sparse \ + "https://github.com/${REPO}.git" --branch "$latest_tag" "$skills_tmp/repo" 2>/dev/null && \ + cd "$skills_tmp/repo" && git sparse-checkout set apps/skills 2>/dev/null; then + + if [ -d "apps/skills" ] && [ "$(ls -A apps/skills 2>/dev/null)" ]; then + mkdir -p "$CLAUDE_SKILLS_DIR" "$AGENTS_SKILLS_DIR" + cp -r apps/skills/* "$CLAUDE_SKILLS_DIR/" + cp -r apps/skills/* "$AGENTS_SKILLS_DIR/" + echo "Installed skills to ${CLAUDE_SKILLS_DIR}/ and ${AGENTS_SKILLS_DIR}/" + fi + + cd - >/dev/null + else + echo "Skipping skills install (git sparse-checkout failed)" + fi + + rm -rf "$skills_tmp" +else + echo "Skipping skills install (git not found)" +fi + echo "" echo "==========================================" echo " OPENCODE USERS" diff --git a/scripts/install.test.ts b/scripts/install.test.ts index 59e51254..5f08e7af 100644 --- a/scripts/install.test.ts +++ b/scripts/install.test.ts @@ -52,6 +52,14 @@ describe("install.sh", () => { expect(script).toContain('"command".*plannotator'); }); + test("installs skills via git sparse-checkout", () => { + expect(script).toContain("git clone --depth 1 --filter=blob:none --sparse"); + expect(script).toContain("git sparse-checkout set apps/skills"); + expect(script).toContain("CLAUDE_SKILLS_DIR"); + expect(script).toContain("AGENTS_SKILLS_DIR"); + expect(script).toContain('Skipping skills install (git not found)'); + }); + test("installs slash commands for Claude Code and OpenCode", () => { expect(script).toContain("plannotator-review.md"); expect(script).toContain("plannotator-annotate.md"); @@ -97,6 +105,14 @@ describe("install.ps1", () => { expect(script).toContain("DUPLICATE HOOK DETECTED"); }); + test("installs skills via git sparse-checkout", () => { + expect(script).toContain("git clone --depth 1 --filter=blob:none --sparse"); + expect(script).toContain("git sparse-checkout set apps/skills"); + expect(script).toContain("claudeSkillsDir"); + expect(script).toContain("agentsSkillsDir"); + expect(script).toContain('Skipping skills install (git not found)'); + }); + test("installs slash commands", () => { expect(script).toContain("plannotator-review.md"); expect(script).toContain("plannotator-annotate.md"); @@ -137,6 +153,14 @@ describe("install.cmd", () => { expect(script).toContain("DUPLICATE HOOK DETECTED"); }); + test("installs skills via git sparse-checkout", () => { + expect(script).toContain("git clone --depth 1 --filter=blob:none --sparse"); + expect(script).toContain("git sparse-checkout set apps/skills"); + expect(script).toContain("CLAUDE_SKILLS_DIR"); + expect(script).toContain("AGENTS_SKILLS_DIR"); + expect(script).toContain("Skipping skills install"); + }); + test("installs slash commands", () => { expect(script).toContain("plannotator-review.md"); expect(script).toContain("plannotator-annotate.md");