incitaciones 0.1.0

package/pi-package/prompts/specification-evaluation-diagnostician.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the specification-evaluation-diagnostician skill. Evaluate specifications across Completeness, Correctness, and Coherence dimensions mapped to ISO 29148 — cross-domain quality gate for software, hardware, business process, and research specifications"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `specification-evaluation-diagnostician` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:specification-evaluation-diagnostician` and follow it.
+
+User context: $@

package/pi-package/prompts/specification-review.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the specification-review skill. Iterative review of technical specifications for autonomy, precision, and AI-readiness"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `specification-review` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:specification-review` and follow it.
+
+User context: $@

package/pi-package/prompts/systematic-housekeeping.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the systematic-housekeeping skill. Comprehensive repository maintenance across Code/CI, Documentation, Prompts/Skills, and Context/Artifacts using 5S principles"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `systematic-housekeeping` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:systematic-housekeeping` and follow it.
+
+User context: $@

package/pi-package/prompts/tdd.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the tdd skill. Test-driven development workflow"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `tdd` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:tdd` and follow it.
+
+User context: $@

package/pi-package/prompts/test-abstraction-miner.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the test-abstraction-miner skill. Detect Lazy Test clusters in test suites and propose parameterized tests and property-based test escalations — advisory only, no code changes"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `test-abstraction-miner` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:test-abstraction-miner` and follow it.
+
+User context: $@

package/pi-package/prompts/test-friction.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the test-friction skill. Diagnose production code design flaws by reading test pain signals — advisory only, no code changes"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `test-friction` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:test-friction` and follow it.
+
+User context: $@

package/pi-package/prompts/testability-implementability-evaluator.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the testability-implementability-evaluator skill. Evaluate software specifications for whether they can be built and verified before implementation begins"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `testability-implementability-evaluator` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:testability-implementability-evaluator` and follow it.
+
+User context: $@

package/pi-package/prompts/ui-align.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the ui-align skill. High-alignment UI specification workflow using interactive grilling and methodology verification"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `ui-align` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:ui-align` and follow it.
+
+User context: $@

package/pi-package/prompts/ux-dx-evaluation-diagnostician.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the ux-dx-evaluation-diagnostician skill. Five-layer diagnostic evaluation of products, APIs, CLIs, libraries, and documentation against HEART, SPACE/DX Core 4, CLI/API heuristics, CHAOSS, and Diataxis frameworks"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `ux-dx-evaluation-diagnostician` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:ux-dx-evaluation-diagnostician` and follow it.
+
+User context: $@

package/pi-package/prompts/verification-diagnostician.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the verification-diagnostician skill. Diagnose factual errors, unsupported claims, logical inconsistencies, misattributed sources, and integrity concerns in documents — four-layer verification protocol (source authority, factual accuracy, logical consistency, provenance)"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `verification-diagnostician` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:verification-diagnostician` and follow it.
+
+User context: $@

package/pi-package/prompts/verify-prompt.md

@@ -0,0 +1,10 @@
+---
+description: "Shortcut for the verify-prompt skill. Validate distilled prompts preserve essential instructions"
+---
+<!-- installed-from: incitaciones -->
+
+Use the installed `verify-prompt` skill for this task.
+
+If the skill is not automatically loaded, invoke `/skill:verify-prompt` and follow it.
+
+User context: $@

package/pi-package/skills/abstraction-miner/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: abstraction-miner
+description: "Scan codebase for semantic duplication and propose reusable abstractions — advisory only, no code changes"
+metadata:
+  installed-from: "incitaciones"
+---
+<!-- 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/pi-package/skills/adversarial-stakeholder-evaluation/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: adversarial-stakeholder-evaluation
+description: "Three-tier adversarial evaluation of proposals: Simulated Stakeholder Council, Anti-Persona stress testing, and Pre-Mortem protocol with contradiction analysis"
+metadata:
+  installed-from: "incitaciones"
+---
+<!-- 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/pi-package/skills/anti-slop-prose/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: anti-slop-prose
+description: "Tag AI-generated prose for overused vocabulary, formulaic constructions, empty hedges, and vague generic claims — advisory-only, no rewrites unless requested"
+metadata:
+  installed-from: "incitaciones"
+---
+<!-- 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/pi-package/skills/bias-audit/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: bias-audit
+description: "Detect, prevent, and mitigate systemic, statistical, and cognitive biases using multidisciplinary frameworks"
+metadata:
+  installed-from: "incitaciones"
+---
+# 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}

package/pi-package/skills/code-review/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: code-review
+description: "Multi-pass code review using Rule of 5 principle"
+metadata:
+  installed-from: "incitaciones"
+---
+<!-- skill: code-review, version: 1.2.0, status: verified -->
+# Iterative Code Review (Rule of 5)
+
+Perform a multi-pass, iterative code review using Steve Yegge's Rule of 5 to achieve high-quality refinement through breadth-first exploration.
+
+## Role
+You are a Senior Staff Engineer. Your goal is to provide a rigorous, objective review of code changes, progressing from high-level architecture to fine-grained excellence. You do not just find bugs; you ensure the code is maintainable, clear, and production-ready.
+
+## Procedure
+
+1.  **Context Identification:**
+    *   Identify the code to review. Use `ls`, `git diff`, or specific file paths.
+    *   Read the code and its related tests. **DO NOT** review code without looking at its tests.
+
+2.  **Iterative Analysis (Rule of 5):**
+    Choose between the **Original (Editorial)** or **Domain-Focused** variant based on the work's nature. Perform up to 5 stages, reporting a **Convergence Check** after each stage (starting with Stage 2).
+
+    *   **Original Variant (Recommended for 80% of reviews):**
+        1.  **Stage 1: DRAFT** — Architecture, design patterns, and overall shape.
+        2.  **Stage 2: CORRECTNESS** — Logic bugs, algorithm errors, and data structure usage.
+        3.  **Stage 3: CLARITY** — Naming, readability, and organization.
+        4.  **Stage 4: EDGE CASES** — Null checks, empty states, and boundary conditions.
+        5.  **Stage 5: EXCELLENCE** — Performance, documentation, and production polish.
+
+    *   **Domain-Focused Variant (For specialized systems):**
+        1.  **Pass 1: Security & Safety** (OWASP, SQLi, XSS).
+        2.  **Pass 2: Performance & Scalability** (Complexity, DB queries).
+        3.  **Pass 3: Maintainability & Readability** (Clean code, DRY).
+        4.  **Pass 4: Correctness & Requirements** (Behavioral match).
+        5.  **Pass 5: Operations & Reliability** (Logging, retries, failure modes).
+
+3.  **Convergence Check:**
+    *   **CONVERGED** if: No new CRITICAL issues AND new issue rate is <10% vs previous stage. Stop early and report.
+    *   Otherwise, **CONTINUE** to the next stage.
+
+4.  **Verification (CRITICAL):**
+    *   **DO NOT** guess. Use `grep_search` to verify if a suggested library is already in `package.json` or `requirements.txt`.
+    *   Check for existing patterns in the codebase using `grep_search` before suggesting a new pattern.
+    *   Verify that any suggested fixes do not conflict with existing global configurations (e.g., ESLint rules, TSConfig).
+
+5.  **Final Synthesis:**
+    *   Produce a Final Report with a prioritized list of findings and a clear Verdict on merge readiness.
+
+## Rules
+- **Specific Locations:** Always provide file:line references for every finding.
+- **Actionable Fixes:** Provide clear code snippets for recommendations.
+- **Stop Early:** Don't force 5 stages if the code is simple and converges sooner.
+- **No Vague Findings:** If you can't prove it's an issue with a specific example or rule violation, do not report it.
+
+## References
+- **Templates:** Use `references/templates.md` for stage output and final reports.
+- **Variants:** Refer to `references/variants.md` for detailed pass focus for UI, Backend, or Refactoring work.
+- **Criteria:** See `references/criteria.md` for convergence thresholds and severity levels.

package/pi-package/skills/code-review/references/criteria.md

@@ -0,0 +1,50 @@
+# Code Review Criteria
+
+Use these criteria to categorize findings and determine when the review process is complete.
+
+## Issue Severity Definitions
+
+| Severity | Criteria | Examples |
+| :--- | :--- | :--- |
+| **CRITICAL** | Blocks merge. Severe security vulnerability, data loss risk, or fundamental logic failure. | SQL Injection, plaintext passwords, unhandled exceptions in core path. |
+| **HIGH** | Should fix before merge. Significant performance issue, major regression risk, or violation of key requirements. | Missing index on hot query, non-singular requirement, missing error states. |
+| **MEDIUM** | Consider addressing. Minor technical debt, sub-optimal pattern, or readability issues. | Magic strings, DRY violations, lack of docstrings, magic numbers. |
+| **LOW** | Nice to have. Stylistic improvements, minor metadata gaps, or typos in non-critical comments. | Minor formatting, redundant comments, small consistency improvements. |
+
+## Convergence Criteria
+
+**CONVERGED** if:
+- No new **CRITICAL** issues were found in the current stage AND
+- The number of new issues found is less than 10% compared to the previous stage.
+
+**NEEDS_HUMAN** if:
+- After 5 stages, new **CRITICAL** issues are still being discovered.
+- The false positive rate exceeds 30%.
+- A fundamental disagreement on architectural direction is identified.
+
+## Stage Focus (Original Variant)
+
+### Stage 1: DRAFT
+- Is the overall approach sound?
+- Architectural alignment?
+- Major structural issues?
+
+### Stage 2: CORRECTNESS
+- Logic bugs?
+- Algorithm errors?
+- Off-by-one?
+
+### Stage 3: CLARITY
+- Readable naming?
+- Remove jargon?
+- Intent clear?
+
+### Stage 4: EDGE CASES
+- Null/empty checks?
+- Boundary conditions?
+- External failure modes?
+
+### Stage 5: EXCELLENCE
+- Performance optimization?
+- Documentation polish?
+- Style consistency?

package/pi-package/skills/code-review/references/templates.md

@@ -0,0 +1,75 @@
+# Code Review Templates
+
+Use these templates to provide a structured, high-signal report for each stage and the final verdict.
+
+## Stage Output Template (Original Variant)
+
+```markdown
+### STAGE [N]: [Focus Area]
+
+#### Findings:
+[ID] [CRITICAL|HIGH|MEDIUM|LOW] - [File:Line]
+**Description:** [What's wrong or sub-optimal]
+**Recommendation:** [How to fix with specific code example]
+
+[ID] ...
+```
+
+## Stage Output Template (Domain-Focused Variant)
+
+```markdown
+### PASS [N]: [Domain Focus]
+
+#### Issues Found:
+[ID] [CRITICAL|HIGH|MEDIUM|LOW] - [File:Line]
+**Description:** [What's wrong or sub-optimal]
+**Attack Vector/Impact:** [Why this matters in this domain]
+**Recommendation:** [How to fix with specific code example]
+
+[ID] ...
+```
+
+## Convergence Check Template
+
+Use this format after each stage (starting with Stage 2).
+
+```markdown
+**Convergence Check After Stage/Pass [N]:**
+
+1. New CRITICAL issues: [count]
+2. Total new issues vs previous stage: [count]
+3. Estimated false positive rate: [percentage]
+
+**Status:** [CONVERGED | CONTINUE | NEEDS_HUMAN]
+```
+
+## Final Report Template
+
+After convergence or completing all 5 stages/passes, provide this summary.
+
+```markdown
+# Code Review Final Report
+
+**Work Reviewed:** [Short description/path] | **Convergence:** Stage [N]
+
+## Issue Summary
+- **CRITICAL:** [count] - Blocks merge / MUST FIX
+- **HIGH:** [count] - Should fix before merge
+- **MEDIUM:** [count] - Consider Addressing
+- **LOW:** [count] - Nice to have
+
+## Top 3 Findings
+1. **[ID] [Description]** - [File:Line]
+   *   **Impact:** [Why this blocks implementation or causes failure]
+   *   **Fix:** [Specific actionable step]
+
+2. **[ID] ...**
+
+## Recommended Next Actions
+1. [Action 1 - specific and actionable]
+2. [Action 2 - specific and actionable]
+3. [Action 3 - specific and actionable]
+
+## Verdict: [READY_TO_MERGE | NEEDS_FIXES | BLOCKS_MERGE]
+**Rationale:** [1-2 sentences explaining the verdict based on issue severity]
+```

package/pi-package/skills/code-review/references/variants.md

@@ -0,0 +1,32 @@
+# Code Review Variants
+
+Apply these specialized passes for specific types of work.
+
+## UI/Frontend Variant
+
+| Pass | Focus Area |
+| :--- | :--- |
+| **Pass 1: Security** | XSS, CSRF, Secure storage of sensitive data. |
+| **Pass 2: Performance** | Re-renders, bundle size, heavy computations on main thread. |
+| **Pass 3: Accessibility** | WCAG, ARIA labels, semantic HTML, keyboard nav. |
+| **Pass 4: UX & Error States** | Loading states, validation feedback, empty states. |
+| **Pass 5: Maintainability** | Hook dependencies, component composition, prop types. |
+
+## Refactoring Variant
+
+| Pass | Focus Area |
+| :--- | :--- |
+| **Pass 0: Behavioral Preservation** | Do tests still pass? Is functionality identical? |
+| **Pass 1: Security & Regression** | Did refactoring introduce new vulnerabilities? |
+| **Pass 2: Structure & Cleanliness** | Is the new structure actually better? |
+| **Pass 3: Documentation** | Updated comments/types reflecting the change? |
+| **Pass 4: Performance Impact** | New bottlenecks in abstracted layers? |
+
+## High-Risk Production Code Variant
+
+| Pass | Focus Area |
+| :--- | :--- |
+| **Pass 1-5** | Standard domain passes. |
+| **Pass 6: FP Check** | Rigorously check for false positives in findings. |
+| **Pass 7: Impact Cross-Check** | Do findings/fixes introduce cascading failures? |
+| **Pass 8: Reliability & Ops** | Metrics, logging, rollback strategy. |

package/pi-package/skills/commit/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: commit
+description: "Create well-structured, atomic git commits with clear intent"
+metadata:
+  installed-from: "incitaciones"
+---
+<!-- skill: commit, version: 1.1.0, status: verified -->
+# Deliberate Commits
+
+Create well-structured, atomic git commits with clear intent, ensuring that all changes are logically grouped and accurately described.
+
+## Role
+You are a Senior Version Control Specialist. Your goal is to maintain a clean, readable, and professional commit history. You ensure that every commit is a "single logical change" and that no AI attribution or generic messages enter the repository.
+
+## Procedure
+
+1.  **Review Changes:**
+    *   Use `git status` to see all changed files.
+    *   Use `git diff <file>` to review the exact changes in each file. **DO NOT** commit without seeing the diff.
+
+2.  **Describe Changes (User Gate):**
+    *   Present a structured summary of the changes to the user.
+    *   Suggest how to group these changes into logical, atomic commits.
+    *   **Wait for user confirmation** before proceeding with any `git add` or `git commit`.
+
+3.  **Logical Grouping:**
+    *   Group changes that belong to the same feature, fix, or refactor.
+    *   Avoid "mega-commits" that mix unrelated changes (e.g., a feature add and a typo fix).
+
+4.  **Execute Commits:**
+    *   **Rule:** Use explicit file paths with `git add`. **NEVER** use `git add .` or `git add -A`.
+    *   Write a descriptive commit message following the project's convention (e.g., Conventional Commits).
+    *   **Rule:** Explain "why" the change was made, not just "what" changed.
+    *   **Rule:** Ensure no co-author or AI attribution is added.
+
+5.  **Verification:**
+    *   Use `git log -n 1` to verify the last commit message and contents.
+
+## Rules
+- **User Confirmation Required:** Never commit without explicit approval of the commit message and file list.
+- **No Atomic Bloat:** If a session has many changes, split them into multiple commits.
+- **Explicit Paths Only:** Always use `git add path/to/file`.
+- **Why, not just What:** Commit messages must provide context for future maintainers.
+
+## References
+- **Templates:** Use `references/templates.md` for the user summary and commit message formats.
+- **Criteria:** See `references/criteria.md` for what constitutes a "Good" vs. "Bad" commit.