@baselane/packs 0.1.5 → 0.1.7

package/packs/full-harness/rendered/.claude/skills/santa-method/SKILL.md

@@ -0,0 +1,305 @@
+---
+name: santa-method
+description: Multi-agent adversarial verification with convergence loop. Two independent review agents must both pass before output ships.
+---
+
+# Santa Method
+
+Multi-agent adversarial verification framework. Make a list, check it twice. If it's naughty, fix it until it's nice.
+
+The core insight: a single agent reviewing its own output shares the same biases, knowledge gaps, and systematic errors that produced the output. Two independent reviewers with no shared context break this failure mode.
+
+## When to Activate
+
+Invoke this skill when:
+- Output will be published, deployed, or consumed by end users
+- Compliance, regulatory, or brand constraints must be enforced
+- Code ships to production without human review
+- Content accuracy matters (technical docs, educational material, customer-facing copy)
+- Batch generation at scale where spot-checking misses systemic patterns
+- Hallucination risk is elevated (claims, statistics, API references, legal language)
+
+Do NOT use for internal drafts, exploratory research, or tasks with deterministic verification (use build/test/lint pipelines for those).
+
+## Architecture
+
+```
+┌─────────────┐
+│  GENERATOR   │  Phase 1: Make a List
+│  (Agent A)   │  Produce the deliverable
+└──────┬───────┘
+       │ output
+       ▼
+┌──────────────────────────────┐
+│     DUAL INDEPENDENT REVIEW   │  Phase 2: Check It Twice
+│                                │
+│  ┌───────────┐ ┌───────────┐  │  Two agents, same rubric,
+│  │ Reviewer B │ │ Reviewer C │  │  no shared context
+│  └─────┬─────┘ └─────┬─────┘  │
+│        │              │        │
+└────────┼──────────────┼────────┘
+         │              │
+         ▼              ▼
+┌──────────────────────────────┐
+│        VERDICT GATE           │  Phase 3: Naughty or Nice
+│                                │
+│  B passes AND C passes → NICE  │  Both must pass.
+│  Otherwise → NAUGHTY           │  No exceptions.
+└──────┬──────────────┬─────────┘
+       │              │
+    NICE           NAUGHTY
+       │              │
+       ▼              ▼
+   [ SHIP ]    ┌─────────────┐
+               │  FIX CYCLE   │  Phase 4: Fix Until Nice
+               │              │
+               │ iteration++  │  Collect all flags.
+               │ if i > MAX:  │  Fix all issues.
+               │   escalate   │  Re-run both reviewers.
+               │ else:        │  Loop until convergence.
+               │   goto Ph.2  │
+               └──────────────┘
+```
+
+## Phase Details
+
+### Phase 1: Make a List (Generate)
+
+Execute the primary task. No changes to your normal generation workflow. Santa Method is a post-generation verification layer, not a generation strategy.
+
+```python
+# The generator runs as normal
+output = generate(task_spec)
+```
+
+### Phase 2: Check It Twice (Independent Dual Review)
+
+Spawn two review agents in parallel. Critical invariants:
+
+1. **Context isolation** — neither reviewer sees the other's assessment
+2. **Identical rubric** — both receive the same evaluation criteria
+3. **Same inputs** — both receive the original spec AND the generated output
+4. **Structured output** — each returns a typed verdict, not prose
+
+```python
+REVIEWER_PROMPT = """
+You are an independent quality reviewer. You have NOT seen any other review of this output.
+
+## Task Specification
+{task_spec}
+
+## Output Under Review
+{output}
+
+## Evaluation Rubric
+{rubric}
+
+## Instructions
+Evaluate the output against EACH rubric criterion. For each:
+- PASS: criterion fully met, no issues
+- FAIL: specific issue found (cite the exact problem)
+
+Return your assessment as structured JSON:
+{
+  "verdict": "PASS" | "FAIL",
+  "checks": [
+    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
+  ],
+  "critical_issues": ["..."],   // blockers that must be fixed
+  "suggestions": ["..."]         // non-blocking improvements
+}
+
+Be rigorous. Your job is to find problems, not to approve.
+"""
+```
+
+```python
+# Spawn reviewers in parallel (Claude Code subagents)
+review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
+review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")
+
+# Both run concurrently — neither sees the other
+```
+
+### Rubric Design
+
+The rubric is the most important input. Vague rubrics produce vague reviews. Every criterion must have an objective pass/fail condition.
+
+| Criterion | Pass Condition | Failure Signal |
+|-----------|---------------|----------------|
+| Factual accuracy | All claims verifiable against source material or common knowledge | Invented statistics, wrong version numbers, nonexistent APIs |
+| Hallucination-free | No fabricated entities, quotes, URLs, or references | Links to pages that don't exist, attributed quotes with no source |
+| Completeness | Every requirement in the spec is addressed | Missing sections, skipped edge cases, incomplete coverage |
+| Compliance | Passes all project-specific constraints | Banned terms used, tone violations, regulatory non-compliance |
+| Internal consistency | No contradictions within the output | Section A says X, section B says not-X |
+| Technical correctness | Code compiles/runs, algorithms are sound | Syntax errors, logic bugs, wrong complexity claims |
+
+#### Domain-Specific Rubric Extensions
+
+**Content/Marketing:**
+- Brand voice adherence
+- SEO requirements met (keyword density, meta tags, structure)
+- No competitor trademark misuse
+- CTA present and correctly linked
+
+**Code:**
+- Type safety (no `any` leaks, proper null handling)
+- Error handling coverage
+- Security (no secrets in code, input validation, injection prevention)
+- Test coverage for new paths
+
+**Compliance-Sensitive (regulated, legal, financial):**
+- No outcome guarantees or unsubstantiated claims
+- Required disclaimers present
+- Approved terminology only
+- Jurisdiction-appropriate language
+
+### Phase 3: Naughty or Nice (Verdict Gate)
+
+```python
+def santa_verdict(review_b, review_c):
+    """Both reviewers must pass. No partial credit."""
+    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
+        return "NICE"  # Ship it
+
+    # Merge flags from both reviewers, deduplicate
+    all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
+    all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
+
+    return "NAUGHTY", all_issues, all_suggestions
+```
+
+Why both must pass: if only one reviewer catches an issue, that issue is real. The other reviewer's blind spot is exactly the failure mode Santa Method exists to eliminate.
+
+### Phase 4: Fix Until Nice (Convergence Loop)
+
+```python
+MAX_ITERATIONS = 3
+
+for iteration in range(MAX_ITERATIONS):
+    verdict, issues, suggestions = santa_verdict(review_b, review_c)
+
+    if verdict == "NICE":
+        log_santa_result(output, iteration, "passed")
+        return ship(output)
+
+    # Fix all critical issues (suggestions are optional)
+    output = fix_agent.execute(
+        output=output,
+        issues=issues,
+        instruction="Fix ONLY the flagged issues. Do not refactor or add unrequested changes."
+    )
+
+    # Re-run BOTH reviewers on fixed output (fresh agents, no memory of previous round)
+    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
+    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
+
+# Exhausted iterations — escalate
+log_santa_result(output, MAX_ITERATIONS, "escalated")
+escalate_to_human(output, issues)
+```
+
+Critical: each review round uses **fresh agents**. Reviewers must not carry memory from previous rounds, as prior context creates anchoring bias.
+
+## Implementation Patterns
+
+### Pattern A: Claude Code Subagents (Recommended)
+
+Subagents provide true context isolation. Each reviewer is a separate process with no shared state.
+
+```bash
+# In a Claude Code session, use the Agent tool to spawn reviewers
+# Both agents run in parallel for speed
+```
+
+```python
+# Pseudocode for Agent tool invocation
+reviewer_b = Agent(
+    description="Santa Review B",
+    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
+)
+reviewer_c = Agent(
+    description="Santa Review C",
+    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
+)
+```
+
+### Pattern B: Sequential Inline (Fallback)
+
+When subagents aren't available, simulate isolation with explicit context resets:
+
+1. Generate output
+2. New context: "You are Reviewer 1. Evaluate ONLY against this rubric. Find problems."
+3. Record findings verbatim
+4. Clear context completely
+5. New context: "You are Reviewer 2. Evaluate ONLY against this rubric. Find problems."
+6. Compare both reviews, fix, repeat
+
+The subagent pattern is strictly superior — inline simulation risks context bleed between reviewers.
+
+### Pattern C: Batch Sampling
+
+For large batches (100+ items), full Santa on every item is cost-prohibitive. Use stratified sampling:
+
+1. Run Santa on a random sample (10-15% of batch, minimum 5 items)
+2. Categorize failures by type (hallucination, compliance, completeness, etc.)
+3. If systematic patterns emerge, apply targeted fixes to the entire batch
+4. Re-sample and re-verify the fixed batch
+5. Continue until a clean sample passes
+
+```python
+import random
+
+def santa_batch(items, rubric, sample_rate=0.15):
+    sample = random.sample(items, max(5, int(len(items) * sample_rate)))
+
+    for item in sample:
+        result = santa_full(item, rubric)
+        if result.verdict == "NAUGHTY":
+            pattern = classify_failure(result.issues)
+            items = batch_fix(items, pattern)  # Fix all items matching pattern
+            return santa_batch(items, rubric)   # Re-sample
+
+    return items  # Clean sample → ship batch
+```
+
+## Failure Modes and Mitigations
+
+| Failure Mode | Symptom | Mitigation |
+|-------------|---------|------------|
+| Infinite loop | Reviewers keep finding new issues after fixes | Max iteration cap (3). Escalate. |
+| Rubber stamping | Both reviewers pass everything | Adversarial prompt: "Your job is to find problems, not approve." |
+| Subjective drift | Reviewers flag style preferences, not errors | Tight rubric with objective pass/fail criteria only |
+| Fix regression | Fixing issue A introduces issue B | Fresh reviewers each round catch regressions |
+| Reviewer agreement bias | Both reviewers miss the same thing | Mitigated by independence, not eliminated. For critical output, add a third reviewer or human spot-check. |
+| Cost explosion | Too many iterations on large outputs | Batch sampling pattern. Budget caps per verification cycle. |
+
+## Integration with Other Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| Verification Loop | Use for deterministic checks (build, lint, test). Santa for semantic checks (accuracy, hallucinations). Run verification-loop first, Santa second. |
+| Eval Harness | Santa Method results feed eval metrics. Track pass@k across Santa runs to measure generator quality over time. |
+| Continuous Learning v2 | Santa findings become instincts. Repeated failures on the same criterion → learned behavior to avoid the pattern. |
+| Strategic Compact | Run Santa BEFORE compacting. Don't lose review context mid-verification. |
+
+## Metrics
+
+Track these to measure Santa Method effectiveness:
+
+- **First-pass rate**: % of outputs that pass Santa on round 1 (target: >70%)
+- **Mean iterations to convergence**: average rounds to NICE (target: <1.5)
+- **Issue taxonomy**: distribution of failure types (hallucination vs. completeness vs. compliance)
+- **Reviewer agreement**: % of issues flagged by both reviewers vs. only one (low agreement = rubric needs tightening)
+- **Escape rate**: issues found post-ship that Santa should have caught (target: 0)
+
+## Cost Analysis
+
+Santa Method costs approximately 2-3x the token cost of generation alone per verification cycle. For most high-stakes output, this is a bargain:
+
+```
+Cost of Santa = (generation tokens) + 2×(review tokens per round) × (avg rounds)
+Cost of NOT Santa = (reputation damage) + (correction effort) + (trust erosion)
+```
+
+For batch operations, the sampling pattern reduces cost to ~15-20% of full verification while catching >90% of systematic issues.

package/packs/full-harness/rendered/.claude/skills/scholar-evaluation/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: scholar-evaluation
+description: Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.
+---
+
+# Scholar Evaluation
+
+Use this skill to evaluate academic or scientific work with a repeatable rubric.
+
+## When to Use
+
+- Reviewing a research paper, proposal, thesis chapter, or literature review.
+- Checking whether claims are supported by cited evidence.
+- Evaluating methodology, study design, analysis, or limitations.
+- Comparing two or more papers for quality or relevance.
+- Producing structured feedback for revision.
+
+## Evaluation Scope
+
+Start by identifying the artifact:
+
+- empirical research paper
+- theoretical paper
+- technical report
+- systematic or narrative literature review
+- research proposal
+- thesis or dissertation chapter
+- conference abstract or short paper
+
+Then choose scope:
+
+- **comprehensive**: all rubric dimensions
+- **targeted**: one or two dimensions, such as method or citations
+- **comparative**: rank multiple works against the same rubric
+
+## Rubric
+
+Score each applicable dimension from 1 to 5:
+
+- 5: excellent; clear, rigorous, and publication-ready
+- 4: good; minor improvements needed
+- 3: adequate; meaningful gaps but usable
+- 2: weak; substantial revision needed
+- 1: poor; major validity or clarity problems
+
+Use `N/A` for dimensions that do not apply.
+
+### 1. Problem and Research Question
+
+- Is the problem clear and specific?
+- Is the contribution meaningful?
+- Are scope and assumptions explicit?
+- Does the question match the claimed contribution?
+
+### 2. Literature and Context
+
+- Is relevant prior work covered?
+- Does the work synthesize rather than merely list sources?
+- Are gaps accurately identified?
+- Are recent and foundational sources balanced?
+
+### 3. Methodology
+
+- Does the method answer the research question?
+- Are design choices justified?
+- Are variables, datasets, participants, or materials described clearly?
+- Could another researcher reproduce the work?
+- Are ethical and practical constraints acknowledged?
+
+### 4. Data and Evidence
+
+- Are data sources credible and appropriate?
+- Is sample size or corpus coverage adequate?
+- Are inclusion, exclusion, and preprocessing decisions documented?
+- Are missing data and bias risks discussed?
+
+### 5. Analysis
+
+- Are statistical, qualitative, or computational methods appropriate?
+- Are baselines and controls fair?
+- Are uncertainty, sensitivity, or robustness checks included when needed?
+- Are alternative explanations considered?
+
+### 6. Results and Interpretation
+
+- Are results clearly presented?
+- Do claims stay within the evidence?
+- Are figures, tables, and metrics understandable?
+- Are negative or null results handled honestly?
+
+### 7. Limitations and Threats to Validity
+
+- Are limitations specific rather than generic?
+- Are internal, external, construct, and conclusion-validity risks addressed?
+- Does the paper distinguish speculation from demonstrated results?
+
+### 8. Writing and Structure
+
+- Is the argument easy to follow?
+- Are sections organized around the research question?
+- Are definitions and notation clear?
+- Is the tone precise and scholarly?
+
+### 9. Citations
+
+- Do cited papers support the claims attached to them?
+- Are primary sources used where possible?
+- Are reviews labeled as reviews?
+- Are preprints labeled as preprints?
+- Are citation metadata and links correct?
+
+## Review Process
+
+1. Read the abstract, introduction, figures, and conclusion for claimed
+   contribution.
+2. Read methods and results for evidence quality.
+3. Check the strongest claims against cited sources.
+4. Score each applicable dimension.
+5. Separate critical blockers from revision suggestions.
+6. End with concrete next edits.
+
+## Output Template
+
+```markdown
+# Scholar Evaluation: <Artifact>
+
+## Overall Assessment
+
+- Overall score: <1-5 or N/A>
+- Confidence: <high | medium | low>
+- Summary: <3-5 sentences>
+
+## Dimension Scores
+
+| Dimension | Score | Evidence | Revision priority |
+| --- | ---: | --- | --- |
+| Problem and question |  |  |  |
+| Literature and context |  |  |  |
+| Methodology |  |  |  |
+| Data and evidence |  |  |  |
+| Analysis |  |  |  |
+| Results and interpretation |  |  |  |
+| Limitations |  |  |  |
+| Writing and structure |  |  |  |
+| Citations |  |  |  |
+
+## Critical Issues
+
+## Recommended Revisions
+
+## Evidence Checks Needed
+```
+
+## Pitfalls
+
+- Do not use the score as a substitute for concrete feedback.
+- Do not penalize a paper for omitting a dimension outside its scope.
+- Do not treat citation count, venue, or author reputation as proof of quality.
+- Do not accept unsupported claims just because they appear in the abstract.

package/packs/full-harness/rendered/.claude/skills/search-first/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: search-first
+description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
+---
+
+# /search-first — Research Before You Code
+
+Systematizes the "search for existing solutions before implementing" workflow.
+
+## Trigger
+
+Use this skill when:
+- Starting a new feature that likely has existing solutions
+- Adding a dependency or integration
+- The user asks "add X functionality" and you're about to write code
+- Before creating a new utility, helper, or abstraction
+
+## Workflow
+
+```
+┌─────────────────────────────────────────────┐
+│  0. TOOL AVAILABILITY PREFLIGHT             │
+│     Check search channels before relying on │
+│     them; report skipped channels honestly   │
+├─────────────────────────────────────────────┤
+│  1. NEED ANALYSIS                           │
+│     Define what functionality is needed      │
+│     Identify language/framework constraints  │
+├─────────────────────────────────────────────┤
+│  2. PARALLEL SEARCH (researcher agent)      │
+│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
+│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
+│     │  PyPI    │ │  Skills  │ │  Web      │  │
+│     └──────────┘ └──────────┘ └──────────┘  │
+├─────────────────────────────────────────────┤
+│  3. EVALUATE                                │
+│     Score candidates (functionality, maint, │
+│     community, docs, license, deps)         │
+├─────────────────────────────────────────────┤
+│  4. DECIDE                                  │
+│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
+│     │  Adopt  │  │  Extend  │  │  Build   │  │
+│     │ as-is   │  │  /Wrap   │  │  Custom  │  │
+│     └─────────┘  └──────────┘  └─────────┘  │
+├─────────────────────────────────────────────┤
+│  5. IMPLEMENT                               │
+│     Install package / Configure MCP /       │
+│     Write minimal custom code               │
+└─────────────────────────────────────────────┘
+```
+
+## Decision Matrix
+
+| Signal | Action |
+|--------|--------|
+| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
+| Partial match, good foundation | **Extend** — install + write thin wrapper |
+| Multiple weak matches | **Compose** — combine 2-3 small packages |
+| Nothing suitable found | **Build** — write custom, but informed by research |
+
+## How to Use
+
+### Step 0: Tool Availability Preflight
+
+This is agent guidance, not an executable setup script. Check only the channels
+that are relevant to the task and project in front of you.
+
+| Channel | Check | If missing |
+|---------|-------|------------|
+| Repository search | `rg --files` and targeted `rg` queries | State that only visible files were inspected |
+| Package registry | `npm --version`, `python -m pip --version`, or project package manager | Use web/docs search and avoid claiming registry coverage |
+| GitHub CLI | `gh auth status` | Use public web or local git history only |
+| MCP/docs tools | Available tool list or local MCP config | Fall back to official docs/web search |
+| Skills directory | `ls ~/.claude/skills ~/.codex/skills` where applicable | Say no local skill catalog was available |
+
+### Quick Mode (inline)
+
+Before writing a utility or adding functionality, mentally run through:
+
+0. Does this already exist in the repo? → `rg` through relevant modules/tests first
+1. Is this a common problem? → Search npm/PyPI
+2. Is there an MCP for this? → Check `~/.claude/settings.json` and search
+3. Is there a skill for this? → Check `~/.claude/skills/`
+4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code
+
+### Full Mode (agent)
+
+For non-trivial functionality, launch the researcher agent:
+
+```
+Agent(subagent_type="general-purpose", prompt="
+  Research existing tools for: [DESCRIPTION]
+  Language/framework: [LANG]
+  Constraints: [ANY]
+
+  Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
+  Return: Structured comparison with recommendation
+")
+```
+
+Older Claude Code docs may call this `Task(...)`; use the current agent/subagent
+tool name exposed by the active harness.
+
+## Search Shortcuts by Category
+
+### Development Tooling
+- Linting → `eslint`, `ruff`, `textlint`, `markdownlint`
+- Formatting → `prettier`, `black`, `gofmt`
+- Testing → `jest`, `pytest`, `go test`
+- Pre-commit → `husky`, `lint-staged`, `pre-commit`
+
+### AI/LLM Integration
+- Claude SDK → Context7 for latest docs
+- Prompt management → Check MCP servers
+- Document processing → `unstructured`, `pdfplumber`, `mammoth`
+
+### Data & APIs
+- HTTP clients → `httpx` (Python), `ky`/`undici` (Node)
+- Validation → `zod` (TS), `pydantic` (Python)
+- Database → Check for MCP servers first
+
+### Content & Publishing
+- Markdown processing → `remark`, `unified`, `markdown-it`
+- Image optimization → `sharp`, `imagemin`
+
+## Integration Points
+
+### With planner agent
+The planner should invoke researcher before Phase 1 (Architecture Review):
+- Researcher identifies available tools
+- Planner incorporates them into the implementation plan
+- Avoids "reinventing the wheel" in the plan
+
+### With architect agent
+The architect should consult researcher for:
+- Technology stack decisions
+- Integration pattern discovery
+- Existing reference architectures
+
+### With iterative-retrieval skill
+Combine for progressive discovery:
+- Cycle 1: Broad search (npm, PyPI, MCP)
+- Cycle 2: Evaluate top candidates in detail
+- Cycle 3: Test compatibility with project constraints
+
+## Examples
+
+### Example 1: "Add dead link checking"
+```
+Need: Check markdown files for broken links
+Search: npm "markdown dead link checker"
+Found: textlint-rule-no-dead-link (score: 9/10)
+Action: ADOPT — npm install textlint-rule-no-dead-link
+Result: Zero custom code, battle-tested solution
+```
+
+### Example 2: "Add HTTP client wrapper"
+```
+Need: Resilient HTTP client with retries and timeout handling
+Search: npm "http client retry", PyPI "httpx retry"
+Found: got (Node) with retry plugin, httpx (Python) with built-in retry
+Action: ADOPT — use got/httpx directly with retry config
+Result: Zero custom code, production-proven libraries
+```
+
+### Example 3: "Add config file linter"
+```
+Need: Validate project config files against a schema
+Search: npm "config linter schema", "json schema validator cli"
+Found: ajv-cli (score: 8/10)
+Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
+Result: 1 package + 1 schema file, no custom validation logic
+```
+
+## Anti-Patterns
+
+- **Jumping to code**: Writing a utility without checking if one exists
+- **Ignoring MCP**: Not checking if an MCP server already provides the capability
+- **Silent skipping**: Reporting "nothing found" when a search channel was unavailable
+- **Over-customizing**: Wrapping a library so heavily it loses its benefits
+- **Dependency bloat**: Installing a massive package for one small feature