pi-skill-search 0.1.0

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

@@ -0,0 +1,103 @@
+---
+name: receiving-code-review
+description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
+---
+
+# Code Review Reception
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (explicit CLAUDE.md violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```

package/skills/release/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: release
+description: Generic release assistant — analyzes repo release rules, caches them in .omc/RELEASE_RULE.md, then guides the release
+---
+
+# Release Skill
+
+A thin, repo-aware release assistant. On first run it inspects the project and CI to derive release rules, stores them in `.omc/RELEASE_RULE.md` for future use, then walks you through a release using those rules.
+
+## Usage
+
+```
+release [version]
+```
+
+- `version` is optional. If omitted the skill will ask. Accepts `patch`, `minor`, `major`, or an explicit semver like `2.4.0`.
+- Add `--refresh` to force re-analysis of the repo even when a cached rule file exists.
+
+## Execution Flow
+
+### Step 0 — Load or Build Release Rules
+
+Check whether `.omc/RELEASE_RULE.md` exists.
+
+**If it does NOT exist (or `--refresh` was passed):** Run the full repo analysis below and write the file.
+
+**If it DOES exist:** Read the file. Then do a quick delta check — scan `.github/workflows/` (or equivalent CI dirs: `.circleci/`, `.travis.yml`, `Jenkinsfile`, `bitbucket-pipelines.yml`, `gitlab-ci.yml`) for any modifications newer than the `last-analyzed` timestamp in the rule file. If relevant workflow files changed, re-run the analysis for those sections and update the file. Report what changed.
+
+---
+
+### Step 1 — Repo Analysis (first run or --refresh)
+
+Inspect the repo and answer the following. Write answers into `.omc/RELEASE_RULE.md`.
+
+#### 1a. Version Sources
+
+- Locate all files that contain a version string matching the current version in `package.json` / `pyproject.toml` / `Cargo.toml` / `build.gradle` / `VERSION` file / etc.
+- List each file and the field or regex pattern used to find the version.
+- Detect whether there is a release automation script (e.g. `scripts/release.*`, `Makefile release` target, `bump2version`, `release-it`, `semantic-release`, `changesets`, `goreleaser`).
+
+#### 1b. Registry / Distribution
+
+- npm (`package.json` with `publishConfig` or `npm publish` in CI), PyPI (`pyproject.toml` + `twine`/`flit`), Cargo (`Cargo.toml`), Docker (`Dockerfile` + push step), GitHub Packages, other.
+- Is there a CI step that publishes automatically on tag push? Which workflow file and job?
+
+### Step 2 — Write `.omc/RELEASE_RULE.md`
+
+Create or overwrite the file with this structure:
+
+```markdown
+# Release Rules
+<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
+
+## Version Sources
+<!-- list of files + patterns -->
+
+## Release Trigger
+<!-- what kicks off the release -->
+
+## Test Gate
+<!-- command + CI job name -->
+
+## Registry / Distribution
+<!-- npm, PyPI, Docker, etc. + CI job that publishes -->
+
+## Release Notes Strategy
+<!-- convention + files -->
+
+## CI Workflow Files
+<!-- paths to relevant workflow files -->
+
+## First-Time Setup Gaps
+<!-- any missing pieces found during analysis, or "none" -->
+```
+
+---
+
+### Step 3 — Determine Version
+
+If the user provided a version argument, use it. Otherwise:
+
+1. Show the current version (from the primary version file).
+2. Show what `patch`, `minor`, and `major` would produce.
+3. Ask the user which to use.
+
+Validate the chosen version is a valid semver string.
+
+---
+
+### Step 4 — Pre-Release Checklist
+
+Present a checklist derived from the release rules. At minimum:
+
+- [ ] All changes intended for this release are committed and pushed
+- [ ] CI is green on the target branch
+- [ ] Tests pass locally (run the test gate command)
+- [ ] Version bump applied to all version source files
+- [ ] Release notes / changelog prepared (see Step 5)
+
+Ask the user to confirm before proceeding, or run each step if they say "go ahead".
+
+---
+
+### Step 5 — Release Notes Guidance
+
+Help the user write good release notes. Apply whichever convention the repo uses. Default guidance when no convention is detected:
+
+**What makes a good release note:**
+- Lead with **what changed for users**, not internal implementation details.
+- Group by type: `New Features`, `Bug Fixes`, `Breaking Changes`, `Deprecations`, `Internal / Chores`.
+- For each item: one sentence, link to the PR or issue, credit the author if external.
+- **Breaking changes** go first and must include a migration path.
+- Omit changes users never see (refactors, CI tweaks, test-only changes) unless they affect build reproducibility.
+
+**Example entry format:**
+
+

package/skills/remember/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: remember
+description: Review reusable project knowledge and decide what belongs in project memory, notepad, or durable docs
+---
+
+
+# Remember
+
+Use this skill when the user wants to preserve or organize useful knowledge discovered during a session.
+
+## Goal
+Promote durable, reusable knowledge into the right memory surface instead of leaving it buried in chat history.
+
+## Memory surfaces
+- **Project memory** — durable team/project knowledge
+- **Notepad priority** — short high-signal context for the next turns
+- **Notepad working** — temporary active-session notes
+- **Docs / AGENTS / CLAUDE files** — durable instructions and conventions when they truly belong there
+
+## Workflow
+1. Gather the relevant session findings.
+2. Classify each item:
+   - durable project fact
+   - temporary working note
+   - operator preference or instruction
+   - duplicate / stale / conflicting information
+3. Propose the best destination for each item.
+4. Write or update only the appropriate memory surface.
+5. Call out duplicates or conflicts that should be cleaned up.
+
+## Rules
+- Do not dump everything into one store.
+- Prefer project memory for durable team knowledge.
+- Prefer notepad for short-lived working context.
+- Keep entries concise and actionable.
+- If something is uncertain, mark it as uncertain rather than storing it as fact.
+
+## Output
+

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

@@ -0,0 +1,85 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
+---
+
+# Requesting Code Review
+
+Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code reviewer subagent:**
+
+Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
+
+**Placeholders:**
+- `{DESCRIPTION}` - Brief summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code reviewer subagent]
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each task or at natural checkpoints
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md
+```

package/skills/requirements-to-task-packet/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: requirements-to-task-packet
+description: Use when a goal, issue, roadmap item, review finding, or user request must become actionable worker tasks.
+---
+
+
+# requirements-to-task-packet
+
+Core principle: workers need explicit task packets, not inherited ambiguity. Ask only when ambiguity changes architecture, safety, public behavior, or data loss risk; otherwise record assumptions.
+
+Distilled from detailed reads of clarification, spec-to-implementation, subagent-driven development, and skill-authoring patterns.
+
+## Clarify or Proceed
+
+Ask before implementation when ambiguity affects:
+
+- security boundary, permissions, ownership, or secret handling;
+- destructive operations, migrations, publishing, or public API behavior;
+- architecture or data model;
+- acceptance criteria or rollback expectations.
+
+Proceed with explicit assumptions when ambiguity is local, reversible, and testable.
+
+## Task Packet Template
+
+```text
+Objective:
+Scope/paths:
+Allowed edits:
+Forbidden edits/non-goals:
+Inputs/dependencies:
+Relevant context/artifacts:
+Assumptions:
+Risks:
+Acceptance criteria:
+Verification commands:
+Expected output artifacts:
+Escalation conditions:
+```
+
+## Subagent Context Rules
+
+- Give each worker fresh, curated context; do not rely on hidden parent history.
+- Include exact upstream artifact paths and summaries when needed.
+- Keep implementation tasks independent or explicitly sequenced.
+- Require workers to report one of: DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED.
+- For BLOCKED/NEEDS_CONTEXT, change context/model/scope before retrying.
+
+## Acceptance Criteria
+
+Use observable checks:
+
+- command output, state transition, UI/status text, artifact contents;
+- regression tests or named test files;
+- security properties such as containment/ownership/no secrets;
+- compatibility requirements such as Windows paths or Pi CLI flags;
+- rollback notes.
+
+## Anti-patterns
+
+- Broad “fix everything” prompts.
+- Buried assumptions.
+- Expanding scope because context remains.
+- Treating tests as proof when the requirement was never asserted.
+

package/skills/research-grants/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: research-grants
+description: Write competitive research proposals for NSF, NIH, DOE, DARPA, and Taiwan NSTC. Agency-specific formatting, review criteria, budget preparation, broader impacts, significance statements, innovation narratives, and compliance with submission requirements.
+---
+
+# Research Grant Writing
+
+## Overview
+
+Research grant writing is the process of developing competitive funding proposals for federal agencies and foundations. Master agency-specific requirements, review criteria, narrative structure, budget preparation, and compliance for NSF (National Science Foundation), NIH (National Institutes of Health), DOE (Department of Energy), DARPA (Defense Advanced Research Projects Agency), and Taiwan's NSTC (National Science and Technology Council) submissions.
+
+**Critical Principle: Grants are persuasive documents that must simultaneously demonstrate scientific rigor, innovation, feasibility, and broader impact.** Each agency has distinct priorities, review criteria, formatting requirements, and strategic goals that must be addressed.
+
+## When to Use This Skill
+
+This skill should be used when:
+- Writing research proposals for NSF, NIH, DOE, DARPA, or NSTC programs
+- Preparing project descriptions, specific aims, or technical narratives
+- Developing broader impacts or significance statements
+- Creating research timelines and milestone plans
+- Preparing budget justifications and personnel allocation plans
+- Responding to program solicitations or funding announcements
+- Addressing reviewer comments in resubmissions
+- Planning multi-institutional collaborative proposals
+- Writing preliminary data or feasibility sections
+- Preparing biosketches, CVs, or facilities descriptions
+
+## Visual Enhancement with Scientific Schematics
+
+**⚠️ MANDATORY: Every research grant proposal MUST include at least 1-2 AI-generated figures using the scientific-schematics skill.**
+
+This is not optional. Grant proposals without visual elements are incomplete and less competitive. Before finalizing any document:
+1. Generate at minimum ONE schematic or diagram (e.g., project timeline, methodology flowchart, or conceptual framework)
+2. Prefer 2-3 figures for comprehensive proposals (research workflow, Gantt chart, preliminary data visualization)
+
+**How to generate figures:**
+- Use the **scientific-schematics** skill to generate AI-powered publication-quality diagrams
+- Simply describe your desired diagram in natural language
+- Nano Banana Pro will automatically generate, review, and refine the schematic
+
+**How to generate schematics:**
+
+## Agency-Specific Overview
+
+### NSF (National Science Foundation)
+**Mission**: Promote the progress of science and advance national health, prosperity, and welfare
+
+**Key Features**:
+- Intellectual Merit + Broader Impacts (equally weighted)
+- 15-page project description limit (most programs)
+- Emphasis on education, diversity, and societal benefit
+- Collaborative research encouraged
+- Open data and open science emphasis
+- Merit review process with panel + ad hoc reviewers
+
+### NIH (National Institutes of Health)
+**Mission**: Enhance health, lengthen life, and reduce illness and disability
+
+**Key Features**:
+- Specific Aims (1 page) + Research Strategy (12 pages for R01)
+- Significance, Innovation, Approach as core review criteria
+- Preliminary data typically required for R01s
+- Emphasis on rigor, reproducibility, and clinical relevance
+- Modular budgets ($250K increments) for most R01s
+- Multiple resubmission opportunities
+
+### DOE (Department of Energy)
+**Mission**: Ensure America's security and prosperity through energy, environmental, and nuclear challenges
+
+**Key Features**:
+- Focus on energy, climate, computational science, basic energy sciences
+- Often requires cost sharing or industry partnerships
+- Emphasis on national laboratory collaboration
+- Strong computational and experimental integration
+- Energy innovation and commercialization pathways
+- Varies by office (ARPA-E, Office of Science, EERE, etc.)
+
+### DARPA (Defense Advanced Research Projects Agency)
+**Mission**: Make pivotal investments in breakthrough technologies for national security
+
+**Key Features**:
+- High-risk, high-reward transformative research
+- Focus on "DARPA-hard" problems (what if true, who cares)
+- Emphasis on prototypes, demonstrations, and transition paths
+- Often requires multiple phases (feasibility, development, demonstration)
+- Strong project management and milestone tracking
+- Teaming and collaboration often required
+- Varies dramatically by program manager and BAA (Broad Agency Announcement)
+
+### NSTC (National Science and Technology Council - Taiwan)
+**Mission**: Advance scientific breakthrough, industrial application, and societal impact in Taiwan.
+
+**Key Features**:
+- **CM03 Form**: The core technical proposal format.
+- **Bilingual**: Abstract required in both Chinese and English.
+- **Innovation & Feasibility**: Primary review focus.
+- **Preliminary Data**: Highly critical for credibility.
+- **Research Architecture Diagram**: A mandatory visual element for clarity.
+
+## Core Components of Research Proposals
+
+### 1. Executive Summary / Project Summary / Abstract
+
+Every proposal needs a concise overview that communicates the essential elements of the research to both technical reviewers and program officers.
+
+**Purpose**: Provide a standalone summary that captures the research vision, significance, and approach
+
+**Length**: 
+- NSF: 1 page (Project Summary with separate Overview, Intellectual Merit, Broader Impacts)
+- NIH: 30 lines (Project Summary/Abstract)
+- DOE: Varies (typically 1 page)
+- DARPA: Varies (often 1-2 pages)
+
+**Essential Elements**:
+- Clear statement of the problem or research question
+- Why this problem matters (significance, urgency, impact)
+
+

package/skills/research-lookup/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: research-lookup
+description: Look up current research information using parallel-cli search (primary, fast web search), the Parallel Chat API (deep research), or Perplexity sonar-pro-search (academic paper searches). Automatically routes queries to the best backend. Use for finding papers, gathering research data, and verifying scientific information. Note: query text is transmitted to api.parallel.ai (PARALLEL_API_KEY) and, for academic searches, to openrouter.ai (OPENROUTER_API_KEY).
+---
+
+## Overview
+
+This skill provides real-time research information lookup with **intelligent backend routing**:
+
+- **parallel-cli search** (parallel-web skill): **Primary and default backend** for all research queries. Fast, cost-effective web search with academic source prioritization. Uses `parallel-cli search` with `--include-domains` for scholarly sources.
+- **Parallel Chat API** (`core` model): Secondary backend for complex, multi-source deep research requiring extended synthesis (60s-5min latency). Use only when explicitly needed.
+- **Perplexity sonar-pro-search** (via OpenRouter): Used only for academic-specific paper searches where scholarly database access is critical.
+
+The skill automatically detects query type and routes to the optimal backend.
+
+## When to Use This Skill
+
+Use this skill when you need:
+
+- **Current Research Information**: Latest studies, papers, and findings
+- **Literature Verification**: Check facts, statistics, or claims against current research
+- **Background Research**: Gather context and supporting evidence for scientific writing
+- **Citation Sources**: Find relevant papers and studies to cite
+- **Technical Documentation**: Look up specifications, protocols, or methodologies
+- **Market/Industry Data**: Current statistics, trends, competitive intelligence
+- **Recent Developments**: Emerging trends, breakthroughs, announcements
+
+## Visual Enhancement with Scientific Schematics
+
+**When creating documents with this skill, always consider adding scientific diagrams and schematics to enhance visual communication.**
+
+If your document does not already contain schematics or diagrams:
+- Use the **scientific-schematics** skill to generate AI-powered publication-quality diagrams
+- Simply describe your desired diagram in natural language
+
+```bash
+python scripts/generate_schematic.py "your diagram description" -o figures/output.png
+```
+
+---
+
+## Automatic Backend Selection
+
+The skill automatically routes queries to the best backend based on content:
+
+### Routing Logic
+
+```
+Query arrives
+    |
+    +-- Contains academic keywords? (papers, DOI, journal, peer-reviewed, etc.)
+    |       YES --> Perplexity sonar-pro-search (academic search mode)
+    |
+    +-- Needs deep multi-source synthesis? (user says "deep research", "exhaustive")
+    |       YES --> Parallel Chat API (core model, 60s-5min)
+    |
+    +-- Everything else (general research, market data, technical info, analysis)
+            --> parallel-cli search (fast, default)
+```
+
+### Default: parallel-cli search (parallel-web skill)
+
+**Primary backend for all standard research queries.** Fast, cost-effective, and supports academic source prioritization.
+
+For scientific/technical queries, run two searches to ensure academic coverage:
+
+```bash
+# 1. Academic-focused search
+parallel-cli search "your research query" -q "keyword1" -q "keyword2" \
+  --json --max-results 10 --excerpt-max-chars-total 27000 \
+  --include-domains "scholar.google.com,arxiv.org,pubmed.ncbi.nlm.nih.gov,semanticscholar.org,biorxiv.org,medrxiv.org,ncbi.nlm.nih.gov,nature.com,science.org,ieee.org,acm.org,springer.com,wiley.com,cell.com,pnas.org,nih.gov" \
+  -o sources/research_<topic>-academic.json
+
+# 2. General search (catches non-academic sources)
+parallel-cli search "your research query" -q "keyword1" -q "keyword2" \
+  --json --max-results 10 --excerpt-max-chars-total 27000 \
+  -o sources/research_<topic>-general.json
+```
+
+Options:
+- `--after-date YYYY-MM-DD` for time-sensitive queries
+- `--include-domains domain1.com,domain2.com` to limit to specific sources
+
+Merge results, leading with academic sources. For non-scientific queries, a single general search is sufficient.
+
+All other queries route here by default, including:
+
+- General research questions
+
+### Academic Keywords (Routes to Perplexity)
+
+Queries containing these terms are routed to Perplexity for academic-focused search:
+
+- Paper finding: `find papers`, `find articles`, `research papers on`, `published studies`
+- Citations: `cite`, `citation`, `doi`, `pubmed`, `pmid`
+- Academic sources: `peer-reviewed`, `journal article`, `scholarly`, `arxiv`, `preprint`
+- Review types: `systematic review`, `meta-analysis`, `literature search`
+- Paper quality: `foundational papers`, `seminal papers`, `landmark papers`, `highly cited`
+
+### Deep Research (Routes to Parallel Chat API)
+
+Only used when the user explicitly requests deep, exhaustive, or comprehensive research. Much slower and more expensive than parallel-cli search.
+
+### Manual Override
+
+You can force a specific backend:
+
+```bash
+# Force parallel-cli search (fast web search)
+parallel-cli search "your query" -q "keyword" --json --max-results 10 -o sources/research_<topic>.json
+
+# Force Parallel Deep Research (slow, exhaustive)
+python research_lookup.py "your query" --force-backend parallel
+
+# Force Perplexity academic search
+python research_lookup.py "your query" --force-backend perplexity
+```

package/skills/research-reproducibility/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: research-reproducibility
+description: Research methodology and experiment reproducibility. Use when setting up experiment tracking, managing computational notebooks, versioning datasets, or ensuring reproducible research workflows. Trigger on imports of mlflow, dvc, papermill, or mentions of reproducibility, experiment tracking, version control for data, notebook parameterization.
+---
+# research-reproducibility
+
+Use this skill for reproducible research and experiment tracking.
+
+## Core patterns
+
+- **Experiment tracking**: `mlflow.start_run()` → `mlflow.log_param()`, `mlflow.log_metric()`.
+- **Data versioning**: `dvc run -n stage -d data.csv -o processed.csv python process.py`.
+- **Notebooks**: `papermill.execute_notebook('template.ipynb', 'output.ipynb', parameters={})`.
+- **Seeds**: Set all random seeds (`random`, `numpy`, `torch`, `tensorflow`).
+
+## Rules
+
+- Always pin dependency versions: `pip freeze > requirements.txt`.
+- Set seeds at experiment start — `np.random.seed(42)`, `torch.manual_seed(42)`.
+- Log all hyperparameters, not just the final ones.
+
+## Anti-patterns
+
+- Don't use `random.seed()` alone — set numpy and torch seeds too.
+- Don't hardcode paths in notebooks — use configuration files.
+- Don't skip logging negative results — they are equally valuable.
+
+