@zcy2nn/agent-forge 1.1.3 → 1.1.5

package/src/skills/simplify/SKILL.md

@@ -1,138 +0,0 @@
----
-name: simplify
-description: Simplifies code for clarity without changing behavior. Use for readability, maintainability, and complexity reduction after behavior is understood.
----
-
-# Code Simplification
-
-## Overview
-
-Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines — it's code that is easier to read, understand, modify, and debug. Every simplification must pass a simple test: "Would a new team member understand this faster than the original?"
-
-## When to Use
-
-- After a feature is working and tests pass, but the implementation feels heavier than it needs to be
-- During code review when readability or complexity issues are flagged
-- When you encounter deeply nested logic, long functions, or unclear names
-- When refactoring code written under time pressure
-- When consolidating related logic scattered across files
-- After merging changes that introduced duplication or inconsistency
-
-**When NOT to use:**
-
-- Code is already clean and readable — don't simplify for the sake of it
-- You don't understand what the code does yet — comprehend before you simplify
-- The code is performance-critical and the "simpler" version would be measurably slower
-- You're about to rewrite the module entirely — simplifying throwaway code wastes effort
-
-## The Five Principles
-
-### 1. Preserve Behavior Exactly
-
-Don't change what the code does — only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.
-
-Before every change, ask:
-
-- Does this produce the same output for every input?
-- Does this maintain the same error behavior?
-- Does this preserve the same side effects and ordering?
-- Do all existing tests still pass without modification?
-
-### 2. Follow Project Conventions
-
-Simplification means making code more consistent with the codebase, not imposing external preferences.
-
-Before simplifying:
-
-1. Read `AGENTS.md` / project conventions
-2. Study how neighboring code handles similar patterns
-3. Match the project's style for imports, naming, function style, error handling, and type annotations
-
-Simplification that breaks project consistency is not simplification — it's churn.
-
-### 3. Prefer Clarity Over Cleverness
-
-Explicit code is better than compact code when the compact version requires a mental pause to parse.
-
-- Replace nested ternaries with readable control flow
-- Replace dense inline transforms with named intermediate steps when they clarify intent
-- Keep helpful names even if they cost a few extra lines
-
-### 4. Maintain Balance
-
-Watch for over-simplification:
-
-- Don't inline away names that carry meaning
-- Don't merge unrelated logic into one larger function
-- Don't remove abstractions that serve testability or extensibility
-- Don't optimize for line count over comprehension
-
-### 5. Scope to What Changed
-
-Default to simplifying recently modified code. Avoid unrelated drive-by refactors unless explicitly asked.
-
-## Process
-
-### Step 1: Understand Before Touching
-
-Before changing or removing anything, understand why it exists.
-
-Answer:
-
-- What is this code's responsibility?
-- What calls it? What does it call?
-- What are the edge cases and error paths?
-- Are there tests that define expected behavior?
-- Why might it have been written this way?
-
-If you can't answer these, read more context first.
-
-### Step 2: Look for Simplification Opportunities
-
-Signals:
-
-- Deep nesting
-- Long functions with mixed responsibilities
-- Nested ternaries
-- Boolean flag arguments
-- Repeated conditionals
-- Generic or misleading names
-- Duplicated logic
-- Dead code
-- Wrappers or abstractions that add no value
-
-### Step 3: Apply Changes Incrementally
-
-Make one simplification at a time.
-
-For each simplification:
-
-1. Make the change
-2. Run relevant tests
-3. Keep it only if behavior is preserved
-
-Separate refactoring from feature work whenever possible.
-
-### Step 4: Verify the Result
-
-After simplifying, confirm:
-
-- The code is genuinely easier to understand
-- The diff is clean and reviewable
-- Project conventions still match
-- No behavior, error handling, or side effects changed
-
-## Guidance for This Repository
-
-- Prefer straightforward TypeScript over clever compression
-- Preserve existing runtime behavior, tests, and hooks
-- Favor explicit names and smaller focused helpers when they improve readability
-- Keep refactors tightly scoped to the task or review feedback
-
-## Verification Checklist
-
-- [ ] Existing tests pass without modification
-- [ ] Build/typecheck/lint still pass
-- [ ] No unrelated files were refactored
-- [ ] No error handling was weakened or removed
-- [ ] The result is simpler to review than the original

package/src/skills/simplify/codemap.md

@@ -1,36 +0,0 @@
-# src/skills/simplify/
-
-## Responsibility
-
-- Provide a behavior-preserving refactoring skill contract that constrains code cleanup to clarity-focused,
-  low-risk changes.
-- Define explicit quality gates (understand-before-edit, behavior parity, incremental simplification, rollback-friendly diffs)
-  for any simplification task.
-- Ship only metadata; no local runtime state machine is kept in this directory.
-
-## Design
-
-- Contract layer: `SKILL.md` is the executable prompt specification with explicit phases:
-  - pre-change understanding
-  - simplification candidate selection
-  - incremental transformation and verification
-  - final review checklist.
-- Documentation layer: `README.md` explains intent, source provenance, and plugin install behavior.
-- Policy model is declarative (`description`, allowed usage, checklist) consumed by the OpenCode skill executor,
-  without helper scripts or plugin code dependencies.
-
-## Flow
-
-- Agent discovery resolves `src/skills/simplify` as a custom skill entrypoint, then reads `SKILL.md` at runtime.
-- Runtime behavior is gated by `src/cli/custom-skills.ts` (`allowedAgents: ['reviewer']`) and by skill permissions
-  computed in `getSkillPermissionsForAgent()`.
-- In practice the workflow is read-only and context-driven: simplify instructions require understanding of callers,
-  edge cases, and tests before mutation, then apply local, scoped refactors with validation.
-- Consumers (Implementer/Reviewer tasks) rely on this contract as operational constraints, not as executable TypeScript.
-
-## Integration
-
-- Installed by plugin installer (`installCustomSkills`) using `src/cli/install.ts` via `installCustomSkill()`.
-- Permission surface is enforced by hook layer in `src/hooks/filter-available-skills/index.ts` (`permissionRules`).
-- Release integrity: `scripts/verify-release-artifact.ts` checks for `src/skills/simplify/SKILL.md` in package tarballs.
-- Operationally paired with codemap/implementer flows in `src/index.ts` orchestrations for post-feature readability hardening.

package/src/skills/using-git-worktrees/SKILL.md

@@ -1,226 +0,0 @@
----
-name: using-git-worktrees
-description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
----
-
-# Using Git Worktrees
-
-## Overview
-
-Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
-
-**Core principle:** Systematic directory selection + safety verification = reliable isolation.
-
-**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
-
-## Directory Selection Process
-
-Follow this priority order:
-
-### 1. Check Existing Directories
-
-```bash
-# Check in priority order
-ls -d .worktrees 2>/dev/null     # Preferred (hidden)
-ls -d worktrees 2>/dev/null      # Alternative
-```
-
-**If found:** Use that directory. If both exist, `.worktrees` wins.
-
-### 2. Check CLAUDE.md
-
-```bash
-grep -i "worktree.*director" CLAUDE.md 2>/dev/null
-```
-
-**If preference specified:** Use it without asking.
-
-### 3. Ask User
-
-If no directory exists and no CLAUDE.md preference:
-
-```
-No worktree directory found. Where should I create worktrees?
-
-1. .worktrees/ (project-local, hidden)
-2. ~/.config/superpowers/worktrees/<project-name>/ (global location)
-
-Which would you prefer?
-```
-
-## Safety Verification
-
-### For Project-Local Directories (.worktrees or worktrees)
-
-**MUST verify directory is ignored before creating worktree:**
-
-```bash
-# Check if directory is ignored (respects local, global, and system gitignore)
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-**If NOT ignored:**
-
-Per Jesse's rule "Fix broken things immediately":
-1. Add appropriate line to .gitignore
-2. Commit the change
-3. Proceed with worktree creation
-
-**Why critical:** Prevents accidentally committing worktree contents to repository.
-
-### For Global Directory (~/.config/superpowers/worktrees)
-
-No .gitignore verification needed - outside project entirely.
-
-## Creation Steps
-
-### 1. Detect Project Name
-
-```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
-```
-
-### 2. Create Worktree
-
-```bash
-# Determine full path
-case $LOCATION in
-  .worktrees|worktrees)
-    path="$LOCATION/$BRANCH_NAME"
-    ;;
-  ~/.config/superpowers/worktrees/*)
-    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
-    ;;
-esac
-
-# Create worktree with new branch
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-### 3. Run Project Setup
-
-Auto-detect and run appropriate setup:
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-```
-
-### 4. Verify Clean Baseline
-
-Run tests to ensure worktree starts clean:
-
-```bash
-# Examples - use project-appropriate command
-npm test
-cargo test
-pytest
-go test ./...
-```
-
-**If tests fail:** Report failures, ask whether to proceed or investigate.
-
-**If tests pass:** Report ready.
-
-### 5. Report Location
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Quick Reference
-
-| Situation | Action |
-|-----------|--------|
-| `.worktrees/` exists | Use it (verify ignored) |
-| `worktrees/` exists | Use it (verify ignored) |
-| Both exist | Use `.worktrees/` |
-| Neither exists | Check CLAUDE.md → Ask user |
-| Directory not ignored | Add to .gitignore + commit |
-| Tests fail during baseline | Report failures + ask |
-| No package.json/Cargo.toml | Skip dependency install |
-
-## Common Mistakes
-
-### Skipping ignore verification
-
-- **Problem:** Worktree contents get tracked, pollute git status
-- **Fix:** Always use `git check-ignore` before creating project-local worktree
-
-### Assuming directory location
-
-- **Problem:** Creates inconsistency, violates project conventions
-- **Fix:** Follow priority: existing > CLAUDE.md > ask
-
-### Proceeding with failing tests
-
-- **Problem:** Can't distinguish new bugs from pre-existing issues
-- **Fix:** Report failures, get explicit permission to proceed
-
-### Hardcoding setup commands
-
-- **Problem:** Breaks on projects using different tools
-- **Fix:** Auto-detect from project files (package.json, etc.)
-
-## Example Workflow
-
-```
-You: I'm using the using-git-worktrees skill to set up an isolated workspace.
-
-[Check .worktrees/ - exists]
-[Verify ignored - git check-ignore confirms .worktrees/ is ignored]
-[Create worktree: git worktree add .worktrees/auth -b feature/auth]
-[Run npm install]
-[Run npm test - 47 passing]
-
-Worktree ready at /Users/jesse/myproject/.worktrees/auth
-Tests passing (47 tests, 0 failures)
-Ready to implement auth feature
-```
-
-## Red Flags
-
-**Never:**
-- Create worktree without verifying it's ignored (project-local)
-- Skip baseline test verification
-- Proceed with failing tests without asking
-- Assume directory location when ambiguous
-- Skip CLAUDE.md check
-
-**Always:**
-- Follow directory priority: existing > CLAUDE.md > ask
-- Verify directory is ignored for project-local
-- Auto-detect and run project setup
-- Verify clean test baseline
-
-## Complexity Assessment
-
-**Lightweight usage:**
-- Create worktree in default directory, skip safety verification
-
-**Standard usage:**
-- Directory selection → safety verification → create → project setup → verify baseline
-
-## Integration
-
-**Called by:**
-- **brainstorming** (Phase 4) - REQUIRED when design is approved and implementation follows
-- **subagent-driven-development** - REQUIRED before executing any tasks
-- **executing-plans** - REQUIRED before executing any tasks
-- Any skill needing isolated workspace
-
-**Pairs with:**
-- **finishing-a-development-branch** - REQUIRED for cleanup after work complete