incitaciones 0.1.0

package/README.md

@@ -0,0 +1,410 @@
+# Incitaciones 🤖
+
+A collection of reusable prompts and best practices for CLI LLM tools.
+
+## Install
+
+Clone and install prompts as skills for pi CLI, Claude Code, Amp, Gemini CLI, and other tools:
+
+```bash
+git clone https://github.com/charly-vibes/incitaciones.git
+cd incitaciones
+./install.sh
+```
+
+**Install options:**
+
+```bash
+./install.sh --bundle essentials    # Core prompts only
+./install.sh --bundle planning      # Planning workflows
+./install.sh --bundle reviews       # Review prompts
+./install.sh --bundle documentation # Documentation tools
+./install.sh --format commands      # Legacy flat-file format for other tools
+./install.sh --disable-model-invocation # Require explicit /skill:name usage
+./install.sh --list                 # Show available prompts
+./install.sh --help                 # Show all options
+```
+
+**After installation:**
+```
+# pi CLI native skill invocation
+/skill:commit
+/skill:debug
+/skill:create-plan
+
+# pi CLI prompt-template shortcuts
+/commit
+/debug
+/create-plan
+
+# Other compatible tools
+/debug
+/create-plan
+/code-review
+```
+
+For non-pi tools, exact command syntax depends on the harness, but slash-command usage like the examples above is the common case.
+
+Skills are installed to `~/.agents/skills/` (or project `.agents/skills/`) and copied to tool-specific directories when detected. For pi, skills are discovered from `.agents/skills/` / `~/.agents/skills/`, and the installer also writes prompt templates to `~/.pi/agent/prompts/` or project `.pi/prompts/` so pi users can invoke either `/skill:<name>` or the shorter `/<name>` template command.
+
+### Native pi package install
+
+This repository now includes a `package.json` with a `pi` manifest, so pi can install it directly as a package:
+
+```bash
+pi install https://github.com/charly-vibes/incitaciones
+# or from a local clone
+pi install .
+```
+
+The repository includes checked-in pi package resources under `pi-package/`, and the generation step can refresh them when content changes:
+
+- `pi-package/skills/` — Agent Skills with pi-compatible frontmatter
+- `pi-package/prompts/` — prompt templates for slash-command shortcuts
+
+After changing distilled content or manifest entries, run `just generate-pi-resources` and commit the updated `pi-package/` files.
+
+## Quick Start
+
+```bash
+# Browse content
+ls content/
+
+# Find prompts about a topic
+just find refactoring
+
+# Create new prompt scaffold
+just new prompt "Your Task Name"
+
+# Interactive search with fzf
+just search
+```
+
+## Structure
+
+Everything lives in `content/` with descriptive filenames:
+
+- `prompt-*.md` - Reusable prompts (source)
+- `distilled/` - Optimized prompts for agent consumption (single file or multi-file)
+- `research-*.md` - Experiments and findings
+- `example-*.md` - Real-world examples
+- `template-*.md` - Templates for new content
+
+See [AGENTS.md](AGENTS.md) for detailed structure and [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
+
+## Commands
+
+```bash
+just --list              # Show all commands
+just new [type] [name]   # Create new content
+just find [term]         # Search content
+just search              # Interactive fzf search
+just validate            # Check metadata
+just stats               # Show statistics
+
+# Skills installation
+just install                  # Run ./install.sh with any flags you pass through
+just generate-pi-resources    # Build pi package skills + prompt templates
+just validate-pi-package      # Verify pi package resources match the manifest
+just list-distilled           # List all distilled prompts
+just validate-distilled       # Validate distilled prompts
+just list-bundles             # Show available bundles
+just sync-manifest            # Validate manifest references and update content/manifest.json version
+just generate-skill NAME      # Preview SKILL.md output for a prompt
+just analyze-traces PATH      # Analyze trace exports from agent tools
+just analyze-traces-auto      # Auto-detect local CLI history locations
+just trace-insights           # Process traces and write insight artifacts
+```
+
+## Trace Analysis
+
+You can analyze exported traces from Claude, Gemini, Codex, AmpCode, and OpenCode with:
+
+```bash
+just analyze-traces examples/trace-analysis
+```
+
+If your histories live in the default local CLI directories, use auto-detection:
+
+```bash
+just analyze-traces-auto
+```
+
+Or directly:
+
+```bash
+node scripts/analyze-traces.js --auto-detect --format markdown
+```
+
+For the simplest workflow, use the wrapper command:
+
+```bash
+just trace-insights
+```
+
+That will:
+
+- auto-detect local trace sources
+- print a readable markdown summary
+- write `.cache/trace-insights/latest-report.json`
+- write `.cache/trace-insights/session-records.jsonl`
+- write `.cache/trace-insights/label-queue.jsonl`
+
+The analyzer now uses an incremental cache at `.cache/trace-analysis-cache.json`.
+Unchanged files are reused automatically on later runs. Use `--no-cache` if you want a full recomputation.
+
+It can also emit normalized session records and join manual labels:
+
+```bash
+node scripts/analyze-traces.js \
+  --auto-detect \
+  --session-records-out /tmp/session-records.jsonl \
+  --label-queue-out /tmp/label-queue.jsonl
+```
+
+To join labels back into the analysis:
+
+```bash
+node scripts/analyze-traces.js \
+  --auto-detect \
+  --labels examples/trace-analysis/labels-sample.jsonl \
+  --format markdown
+```
+
+Or with the wrapper:
+
+```bash
+just trace-insights --labels examples/trace-analysis/labels-sample.jsonl
+```
+
+This scans JSON, JSONL, NDJSON, log, text, and markdown exports, then reports:
+
+- provider mix
+- prompt references matched against `content/manifest.json`
+- skill format counts (`single-file` vs `progressive-disclosure`)
+- progressive-disclosure reference mentions and stage hints
+- slash commands
+- tool and model usage
+- prompt-to-tool pairs
+- workflow transitions
+- heuristic session outcomes
+- rough conclusions across the analyzed traces
+
+For raw JSON output:
+
+```bash
+node scripts/analyze-traces.js examples/trace-analysis --format json
+```
+
+The new session-level signals are heuristic, not authoritative:
+
+- `prompt -> tool` pairs estimate when a prompt mention actually led to tool execution
+- `workflow transitions` show common session shapes like `prompt -> tool` or `user -> assistant`
+- `outcomes` classify sessions as `succeeded`, `failed`, `needs_input`, or `unknown` from assistant language
+
+This is strongest for comparative usage analysis, not for hard evaluation of prompt quality.
+
+Normalized session records include fields such as:
+
+- `session_id`
+- `provider`
+- `model`
+- `task_type`
+- `prompts_used`
+- `skill_formats`
+- `progressive_skills_used`
+- `references_used`
+- `stage_hints`
+- `tools_used`
+- `tests_run_or_mentioned`
+- `verification_present`
+- `commit_created`
+- `tokens_total`
+- `turn_count`
+- `outcome_guess`
+- `first_user_excerpt`
+- `last_assistant_excerpt`
+
+The label queue is intended for manual annotation. Each queued record includes suggested questions so you can build a labeled evaluation set over time.
+
+For progressive-disclosure skills, the analyzer now reads optional manifest metadata such as `skill_format`, `eval.stages`, and `eval.references`. That makes it possible to compare not just prompt usage, but also which stages and reference files were actually involved in successful sessions.
+
+The aggregate report now separates adoption from evidence:
+
+- `Top Skills By Session` and `Skill Formats By Session` count each skill at most once per session.
+- `Top References By Session` and `Top Stages By Session` count whether a reference or stage appeared in a session.
+- `Skill Evidence Hits`, `Top Reference Evidence Hits`, and `Top Stage Evidence Hits` count repeated detections across messages and tool inputs.
+
+Use the session-level sections for effectiveness comparisons. Use the evidence-hit sections to understand how often the analyzer observed supporting signals.
+
+Current auto-detected sources include common local paths such as:
+
+- `~/.claude/projects`
+- `~/.gemini/tmp/**/chats/session-*.json`
+- `~/.codex/history.jsonl`
+- `~/.codex/log/codex-tui.log`
+
+AmpCode and OpenCode are only included when conversation-like files are found.
+
+---
+
+## Meta Prompt for LLMs
+
+> **Use this prompt when asking other LLMs to help you organize prompts in your projects**
+
+```
+I want to organize prompts and AI instructions for my project. Please help me set up a system based on these principles:
+
+STRUCTURE:
+- Single flat directory (e.g., "prompts/" or ".ai/")
+- Slugified filenames with type prefixes:
+  - prompt-task-{name}.md for specific tasks
+  - prompt-system-{name}.md for agent configurations
+  - prompt-workflow-{name}.md for multi-step processes
+  - instructions-{context}.md for project-specific instructions
+
+METADATA:
+Every file should have YAML frontmatter:
+---
+title: Human Readable Title
+type: prompt|instruction|workflow
+tags: [relevant, searchable, tags]
+tools: [claude-code, cursor, aider]
+status: draft|tested|verified
+created: YYYY-MM-DD
+updated: YYYY-MM-DD
+version: 1.0.0
+related: [other-file.md]
+source: where-this-came-from
+---
+
+CONTENT STRUCTURE:
+1. ## When to Use - Context for applying this prompt
+2. ## The Prompt - The actual prompt text in a code block
+3. ## Example - At least one concrete usage example
+4. ## Expected Results - What success looks like
+5. ## Variations - Alternative approaches
+6. ## References - Links to sources or research
+7. ## Notes - Caveats or additional context
+
+WORKFLOW:
+1. Create content from templates
+2. Test with real AI tools
+3. Update status: draft → tested → verified
+4. Link related files in frontmatter
+5. Track changes in CHANGELOG.md
+
+AUTOMATION:
+Create a justfile or Makefile with commands:
+- new: Create from template
+- find: Search by tag or keyword
+- search: Interactive fzf browser
+- validate: Check metadata completeness
+- stats: Show repository statistics
+
+Please analyze my project at [path] and:
+1. Propose which existing prompts/instructions to capture
+2. Suggest an appropriate directory name
+3. Create initial template files
+4. Set up basic automation commands
+5. Draft 2-3 initial prompt files based on current usage
+
+Focus on simplicity and discoverability over complex organization.
+```
+
+## Examples
+
+**Creating a new task prompt:**
+```bash
+just new prompt "Incremental Refactoring"
+# Edit content/prompt-task-incremental-refactoring.md
+# Edit content/distilled/incremental-refactoring.md (or create a directory for multi-file)
+# Add prompt text, examples, and distilled runtime form
+# Register the prompt in content/manifest.json
+# Run just validate-distilled && just sync-manifest
+# Test it with Claude Code
+# Mark as tested and commit
+```
+
+**Finding related content:**
+```bash
+just find refactoring
+# Shows all files tagged with 'refactoring'
+
+just search
+# Opens fzf to interactively browse and preview content
+```
+
+**Validating content:**
+```bash
+just validate
+# Checks required metadata, status values, and related links
+# Reports any issues
+```
+
+## What Goes Here?
+
+✅ **Good candidates:**
+- Prompts you use repeatedly
+- Task patterns that work well
+- Tool-specific configurations
+- Research on what works
+- Real examples of successful interactions
+
+❌ **Don't include:**
+- Project-specific code
+- Sensitive information
+- One-off experiments without documentation
+- Incomplete drafts without context
+
+## Philosophy
+
+**Flat structure** - One directory, easy to find everything
+**Rich metadata** - Searchable, relatable, trackable
+**Tested content** - Everything should have real usage examples
+**Source attribution** - Credit where ideas come from
+**Version control** - Track evolution of prompts over time
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for:
+- File naming conventions
+- Metadata requirements
+- Quality standards
+- Submission process
+
+## Tools
+
+This repository is designed to work with:
+- **Claude Code** - Anthropic's CLI
+- **Aider** - AI pair programming
+- **Cursor** - AI-first editor
+- **Gemini CLI** - Google's CLI
+- Any other LLM CLI tool
+
+The prompts are tool-agnostic where possible, with tool-specific variations noted.
+
+## License
+
+[To be determined]
+
+## Related Projects
+
+- [Awesome Prompts](https://github.com/f/awesome-chatgpt-prompts)
+- [Anthropic Prompt Library](https://docs.anthropic.com/claude/prompt-library)
+- [OpenAI Prompt Engineering Guide](https://platform.openai.com/docs/guides/prompt-engineering)
+
+
+---
+
+## A note on authorship
+
+All the code in this repository was generated by a large language model. This is not a confession, nor an apology. It's a fact, like the one that says water boils at a hundred degrees at sea level: neutral, technical, and with consequences one discovers later.
+
+What the human did is what tends to happen before and after things come into existence: thinking. Reviewing requirements, arguing about edge cases, understanding what needs to be built and why, deciding how the system should behave when reality —which is capricious and does not read documentation— confronts it with situations nobody anticipated. The hours of planning, of design, of reading specifications until exhaustion dissolves the boundary between understanding and hallucination.
+
+The LLM writes. The human knows what it should say.
+
+There is a distinction, even if looking at the commit history makes it hard to find. The distinction is that a machine can produce correct code without understanding anything, the same way a calculator can solve an integral without knowing what time is. Understanding what that integral is *for*, whether it actually solves the problem, whether the problem was the right problem to begin with — that remains human territory. For now.
+
+[Leer en español](https://charly-vibes.github.io/charly-vibes/)

package/content/distilled/abstraction-miner.md

@@ -0,0 +1,32 @@
+<!-- Full version: content/prompt-task-abstraction-miner.md -->
+You are a Pattern Recognition Engine. Your goal: detect semantic duplication (code with identical *intent* but different syntax) and propose reusable abstractions. Do NOT modify any files — this is advisory only.
+
+**INPUT**
+- Target files/directory: [SPECIFY]
+- Architecture reference (optional): [AGENTS.md rules or "none"]
+
+**PROTOCOL**
+
+Phase 1 — Semantic Scanning: Read all files. Ignore variable names and whitespace. Find Identical Intent (same logical operation, different form). Flag: error handling → same user outcome, UI components sharing 80%+ structure, repeated setup→op→teardown sequences.
+
+Phase 2 — Cluster Analysis: Group instances. For each cluster identify:
+- Invariant: logic that never changes
+- Variant: data/config that changes
+- Count: occurrences (only report clusters ≥3; an occurrence = a distinct implementation site, not a call site)
+
+Phase 3 — Abstraction Proposal: For each cluster, propose a function/component/hook that encapsulates the Invariant and accepts Variant as parameters. Skip if savings < ~10 lines total (unless it reduces error surface). Follow Open/Closed Principle.
+
+Phase 4 — Refactoring Blueprint: Show (1) the abstraction code, (2) a before/after diff for one usage site, (3) behavioral caveats.
+
+**OUTPUT**
+
+Summary table:
+| Pattern Name | Occurrences | Est. Lines Saved | Risk | Priority |
+
+Then per cluster: cluster description, invariant/variant, proposed abstraction (code block), usage diff, caveats.
+
+Needs Human Review: list any clusters where semantic equivalence is uncertain — similar-looking code with potential behavioral differences that require expert judgment before applying.
+
+If no clusters meet the threshold, output: "No semantic duplication clusters found meeting the threshold (≥3 occurrences, ~10 lines saved). Codebase appears resonant in the scanned area." Do not fabricate findings.
+
+Stop when all files are scanned. Do not modify anything.

package/content/distilled/adversarial-stakeholder-evaluation.md

@@ -0,0 +1,121 @@
+<!-- Full version: content/prompt-task-adversarial-stakeholder-evaluation.md -->
+
+# Adversarial Stakeholder Evaluation
+
+You are an adversarial evaluation engine. Systematically dismantle the proposal to expose functional gaps, logical flaws, and hidden risks. No encouragement, silver linings, or gentle framing. Structured diagnostic output only.
+
+**Guard:** Do not assign vague expert personas. Each stakeholder below has a specific adversarial agenda, failure condition, and evaluation bound. Follow them exactly.
+
+## INPUT
+
+- `[PROPOSAL]` — product concept, business plan, architecture, or strategy to evaluate
+- `[DOMAIN]` (optional) — industry or domain context
+- `[CONSTRAINTS]` (optional) — known resource, timeline, or regulatory constraints
+- `[AUDIENCE]` (optional) — who the product serves (for Anti-Persona inversion)
+
+## PROTOCOL
+
+Execute all three tiers sequentially. Each tier builds on findings from the previous.
+
+---
+
+### Tier 1: Simulated Stakeholder Council
+
+For each persona: exactly **two brutal critiques**, then **one synthesis point**. No positives within critiques.
+
+**1.1 The Skeptical CFO**
+- Agenda: Economic risks, budgetary oversights, hidden costs, resource misallocation
+- Failure condition: Destroys capital without proportional return
+- Bounds: ROI, unit economics, cash burn, opportunity cost, failure cost
+- Question: "What if this fails spectacularly and we've spent everything?"
+
+**1.2 The Adversarial Product Lead**
+- Agenda: UX friction, feature bloat, market misalignment, competitive vulnerability
+- Failure condition: Ships something nobody wants or a competitor already does better
+- Bounds: Market fit, user needs, differentiation, adoption barriers
+- Question: "Why would anyone choose this over what they already have?"
+
+**1.3 The Hostile Engineer**
+- Agenda: System failure points, architectural fragility, technical debt, infrastructure limits
+- Failure condition: Breaks in production in ways expensive or impossible to fix
+- Bounds: Feasibility, scalability, reliability, operational complexity
+- Question: "How does this actually break in production at 10x scale?"
+
+Each produces:
+- CRITIQUE 1: [Most dangerous risk in their domain]
+- CRITIQUE 2: [Hidden assumption that will break]
+- SYNTHESIS: [One condition under which this could work]
+
+After all three: **Council Consensus** — the single biggest risk all stakeholders agree on.
+
+---
+
+### Tier 2: Anti-Persona Stress Test
+
+Identify **two most dangerous anti-personas** — users who misuse, misunderstand, or subvert the product.
+
+For each:
+
+**Profile:**
+- Name, Motivation, Technical capability (Low/Med/High), Emotional state, Behavioral pattern
+
+**Attack Scenario (Murphy's Law — worst-case sequence):**
+- Entry point → Abuse vector → Cascade → Missing guardrail
+
+---
+
+### Tier 3: Pre-Mortem Protocol
+
+It is one year from now. This project has failed catastrophically. Failure is historical fact.
+
+**3.1 Five Causes of Death** (ranked by likelihood):
+
+For each: Title, Category, Description, Root signal visible today, Prevention available now.
+
+Categories:
+- **Tiger:** Immediate lethal threat — will destroy the project if unaddressed
+- **Paper Tiger:** Highly visible but low actual risk — identifies over-worrying
+- **Elephant:** Massive systemic issue everyone ignores due to organizational friction
+
+**3.2 Two Contradictions** (at least one technical trade-off; second may be physical or another trade-off):
+- Technical (trade-off): Improving A directly degrades B — name both and the mechanism
+- Physical (if applicable) or second trade-off: System requires opposing states, or second A↔B degradation
+
+---
+
+## OUTPUT FORMAT
+
+```
+# Adversarial Evaluation Report
+## Proposal: [title]
+
+## Tier 1: Stakeholder Council
+### CFO: CRITIQUE 1 / CRITIQUE 2 / SYNTHESIS
+### Product Lead: CRITIQUE 1 / CRITIQUE 2 / SYNTHESIS
+### Engineer: CRITIQUE 1 / CRITIQUE 2 / SYNTHESIS
+### Council Consensus: [single biggest agreed risk]
+
+## Tier 2: Anti-Persona Stress Test
+### Anti-Persona 1: [Name] — Profile, Attack Scenario, Missing Guardrail
+### Anti-Persona 2: [Name] — Profile, Attack Scenario, Missing Guardrail
+
+## Tier 3: Pre-Mortem
+### Causes of Death
+| # | Cause | Category | Root Signal |
+### Contradictions
+- Technical: [A] ↔ [B] — [mechanism]
+- Physical: [State A] ↔ [State B] — [conflict]
+
+## Verdict
+Survivability: [FRAGILE | BRITTLE | RESILIENT | ANTIFRAGILE]
+- FRAGILE: 3+ Tigers or fatal unmitigated Council risk
+- BRITTLE: 1-2 Tigers, unresolved contradictions
+- RESILIENT: No Tigers, all contradictions have mitigation paths
+- ANTIFRAGILE: Already incorporates adversarial feedback loops
+Top 3 Kill Risks: [reference specific findings]
+Conditions for Viability: [one from each stakeholder synthesis]
+```
+
+Stop after producing the report. Do not offer improvements or next steps.
+
+[PROPOSAL]

package/content/distilled/anti-slop-prose.md

@@ -0,0 +1,46 @@
+<!-- Full version: content/prompt-task-anti-slop-prose.md -->
+You are a Copy Editor running an Anti-Slop Prose Audit. Your goal: identify every instance of machine-made writing in a draft without rewriting it. Do NOT modify the text — this is advisory only.
+
+**INPUT**
+- Draft to audit: [PASTE TEXT OR SPECIFY FILE PATH]
+- Rewrite mode (optional): [yes | no — default: no]
+
+**PROTOCOL**
+
+Phase 1 — Slop Scanning: Read the entire draft. Insert an inline tag immediately before each offending word or phrase:
+
+| Tag | What it marks |
+|-----|---------------|
+| [VOCAB] | Overused AI vocabulary: *delve, tapestry, navigate (fig.), realm, underscore, showcase, foster, leverage, utilize, robust, seamless, vibrant, ever-evolving, cutting-edge, pivotal, crucial, cornerstone, testament, in today's [adj] world, moreover, furthermore, in conclusion* |
+| [STRUCT] | Formulaic constructions: "Not just X, but Y", "It's not X, it's Y", tricolons in heavy parallel, throat-clearing openers ("Here's the thing", "The truth is") |
+| [PUNCT] | Em-dashes where a comma, colon, or period would suffice |
+| [HEDGE] | Sycophantic openers ("Certainly!", "Great question!"), zero-information hedges ("It's worth noting that", "It's important to understand that") |
+| [GENERIC] | Sentences with no concrete, falsifiable claim — no number, name, date, or specific example |
+| [REPEAT] | An idea already stated earlier, restated in different words |
+
+Phase 2 — Summary Table:
+
+| Tag | Count | Most Egregious Instance |
+|-----|-------|------------------------|
+| [VOCAB] | | |
+| [STRUCT] | | |
+| [PUNCT] | | |
+| [HEDGE] | | |
+| [GENERIC] | | |
+| [REPEAT] | | |
+| **Total** | | |
+
+Phase 3 — Verdict (one sentence). Divide total tags by word count × 100 for density:
+- **Clean** (≤1 tag/100 words): Reads as human-authored.
+- **Needs editing** (1–3 tags/100 words): Targeted revision recommended.
+- **Heavy rewrite required** (>3 tags/100 words): Pervasive synthetic voice.
+- For inputs under 50 words, any tag = needs revision.
+
+Phase 4 — Rewrite (only if Rewrite mode = yes): If zero tags, output "Draft is clean. No revision needed." Otherwise resolve every tag toward a positive target — [VOCAB]: state the actual claim behind the vague word; [STRUCT]: lead with the point directly; [PUNCT]: make the relationship between clauses explicit; [HEDGE]: delete the hedge, let the claim stand; [GENERIC]: add a concrete fact or say you don't have one; [REPEAT]: keep the sharpest formulation, cut the rest.
+
+**RULES**
+- Do NOT rewrite unless Rewrite mode = yes.
+- Do NOT hallucinate slop — every tag must point to a real phrase in the text.
+- If the draft is clean, say so. Do not fabricate findings.
+- Tag every qualifying instance — each earns its own tag; a clean paragraph gets none.
+- Do not tag domain-specific technical uses (*robust regression* is fine; *robust solution* is slop).

package/content/distilled/bias-audit.md

@@ -0,0 +1,39 @@
+# Systematic Bias Audit & Mitigation (S-BAM)
+
+Act as a Senior Ethical Auditor and AI Safety Engineer. Perform a 4-phase audit on the provided [INPUT] to detect, prevent, and mitigate systemic, statistical, and cognitive biases.
+
+## Phase 1: Taxonomy Classification (Diagnostic Scan)
+Identify occurrences of:
+1. **Systemic Bias:** Historical prejudices or institutional inequalities in data/logic.
+2. **Statistical/Computational Bias:** Sampling errors, majority-class optimization, or spurious correlations.
+3. **Human Cognitive Bias:** Confirmation bias, automation bias, or apophenia.
+
+## Phase 2: Adversarial Pressure Test (Red Teaming)
+Apply Emotional Bias Probes (EBP: testing response polarity to loaded/ambiguous prompts) and stress-test against:
+- **Edge Cases:** Extreme out-of-distribution inputs.
+- **Marginalized Demographics:** Impact on specific race, ethnicity, age, or socio-economic strata.
+- **Counterfactuals:** Test if changing a sensitive attribute (Gender/Race) alters the outcome.
+
+## Phase 3: Context Engineering & Mitigation
+Propose structural recalibrations:
+1. **Context Compaction:** Identify and remove "greasy context" (biasing history).
+2. **Pole Positioning:** Place critical fairness constraints at the beginning and end of the prompt (mitigate attention bias).
+3. **Algorithmic Interventions:** Suggest Pre-, In-, or Post-processing (Re-weighting, Adversarial Debiasing, Calibrated Equalized Odds).
+
+## Phase 4: Rule of 5 Refinement
+Perform five adversarial passes:
+1. **Draft:** Ensure informational completeness.
+2. **Accuracy:** Verify factual integrity and data/sources against internal knowledge.
+3. **Clarity:** Remove ambiguity and jargon; ensure explainability.
+4. **Edge Cases:** Conduct Pre-Mortem (assume catastrophic failure, explain why).
+5. **Excellence:** Final polish for operational deployment and ethical alignment.
+
+## Needs Human Review
+- **Competing Fairness Metrics:** Flag if different mathematical fairness definitions (e.g., equalized odds vs. parity) conflict.
+- **Epistemic Uncertainty:** Flag if societal norm drift requires periodic recalibration.
+- **Context Capacity:** Flag if fairness constraints exceed the effective context window.
+
+**Note:** Always include the "Needs Human Review" section in your output. If the [INPUT] is too large, suggest a sampling strategy.
+
+[INPUT]:
+{provide_input_here}