pi-skill-search 0.1.0

package/skills/stable-baselines3/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: stable-baselines3
+description: Production-ready reinforcement learning algorithms (PPO, SAC, DQN, TD3, DDPG, A2C) with scikit-learn-like API. Use for standard RL experiments, quick prototyping, and well-documented algorithm implementations. Best for single-agent RL with Gymnasium environments. For high-performance parallel training, multi-agent systems, or custom vectorized environments, use pufferlib instead.
+---
+
+# Stable Baselines3
+
+## Overview
+
+Stable Baselines3 (SB3) is a PyTorch-based library providing reliable implementations of reinforcement learning algorithms. This skill provides comprehensive guidance for training RL agents, creating custom environments, implementing callbacks, and optimizing training workflows using SB3's unified API.
+
+## Core Capabilities
+
+### 1. Training RL Agents
+
+**Basic Training Pattern:**
+
+```python
+import gymnasium as gym
+from stable_baselines3 import PPO
+
+# Create environment
+env = gym.make("CartPole-v1")
+
+# Initialize agent
+model = PPO("MlpPolicy", env, verbose=1)
+
+# Train the agent
+model.learn(total_timesteps=10000)
+
+# Save the model
+model.save("ppo_cartpole")
+
+# Load the model (without prior instantiation)
+model = PPO.load("ppo_cartpole", env=env)
+```
+
+**Important Notes:**
+- `total_timesteps` is a lower bound; actual training may exceed this due to batch collection
+- Use `model.load()` as a static method, not on an existing instance
+- The replay buffer is NOT saved with the model to save space
+
+**Algorithm Selection:**
+Use `(see docs)` for detailed algorithm characteristics and selection guidance. Quick reference:
+- **PPO/A2C**: General-purpose, supports all action space types, good for multiprocessing
+- **SAC/TD3**: Continuous control, off-policy, sample-efficient
+- **DQN**: Discrete actions, off-policy
+- **HER**: Goal-conditioned tasks
+
+See `scripts/train_rl_agent.py` for a complete training template with best practices.
+
+### 2. Custom Environments
+
+**Requirements:**
+Custom environments must inherit from `gymnasium.Env` and implement:
+- `__init__()`: Define action_space and observation_space
+- `reset(seed, options)`: Return initial observation and info dict
+- `step(action)`: Return observation, reward, terminated, truncated, info
+- `render()`: Visualization (optional)
+- `close()`: Cleanup resources
+
+**Key Constraints:**
+- Image observations must be `np.uint8` in range [0, 255]
+- Use channel-first format when possible (channels, height, width)
+- SB3 normalizes images automatically by dividing by 255
+- Set `normalize_images=False` in policy_kwargs if pre-normalized
+
+### 3. Vectorized Environments
+
+**Purpose:**
+Vectorized environments run multiple environment instances in parallel, accelerating training and enabling certain wrappers (frame-stacking, normalization).
+
+**Types:**
+- **DummyVecEnv**: Sequential execution on current process (for lightweight environments)
+- **SubprocVecEnv**: Parallel execution across processes (for compute-heavy environments)
+
+**Quick Setup:**
+```python
+from stable_baselines3.common.env_util import make_vec_env
+
+# Create 4 parallel environments
+env = make_vec_env("CartPole-v1", n_envs=4, vec_env_cls=SubprocVecEnv)
+
+model = PPO("MlpPolicy", env, verbose=1)
+model.learn(total_timesteps=25000)
+```

package/skills/state-mutation-locking/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: state-mutation-locking
+description: Durable state mutation and locking workflow. Use when changing manifests, tasks, mailbox, claims, events, stale reconciliation, recovery, cancel/respond/resume, or retry logic.
+---
+
+
+# state-mutation-locking
+
+Use this skill before modifying pi-crew run state.
+
+## Source patterns distilled
+
+- `src/state/locks.ts` — run-level sync/async locks
+- `src/state/state-store.ts` — manifest/tasks persistence
+- `src/state/contracts.ts` — allowed status transitions
+- `src/state/mailbox.ts`, `src/state/task-claims.ts`, `src/state/atomic-write.ts`
+- `src/runtime/crash-recovery.ts`, `src/runtime/stale-reconciler.ts`, `src/runtime/team-runner.ts`
+
+## Rules
+
+- Mutations to a run's `manifest.json`, `tasks.json`, mailbox delivery state, claims, or recovery status must be protected by a run lock when concurrent actions are possible.
+- Re-read manifest/tasks inside the lock before making a decision; pre-lock reads are only for locating the run.
+- Persist with atomic write helpers (`atomicWriteJson`, async variants, or state-store helpers). Do not partially write JSON files.
+- Respect status contracts. Do not transition terminal tasks/runs unless the action explicitly supports force semantics.
+- Separate analysis from persistence: pure reconcilers should return intended repaired state; locked callers should persist it.
+- In retry/resume paths, reload fresh task status immediately before execution and skip if the task is no longer retryable/runnable.
+- Include event-log entries for externally visible state changes.
+
+## Anti-patterns
+
+- Reading state, waiting/doing async work, then writing the old copy.
+- Updating `tasks.json` from a reconciler or watcher without a lock.
+- Cancelling/responding to runs owned by another session.
+- Using `fs.writeFileSync` for JSON state outside atomic helpers.
+
+## Verification
+
+```bash
+cd pi-crew
+npx tsc --noEmit
+node --experimental-strip-types --test test/unit/cancel-ownership.test.ts test/unit/respond-tool.test.ts test/unit/stale-reconciler.test.ts test/unit/api-claim.test.ts
+npm test
+```
+

package/skills/statistical-analysis/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: statistical-analysis
+description: Guided statistical analysis with test selection and reporting. Use when you need help choosing appropriate tests for your data, assumption checking, power analysis, and APA-formatted results. Best for academic research reporting, test selection guidance. For implementing specific models programmatically use statsmodels.
+---
+
+# Statistical Analysis
+
+## Overview
+
+Statistical analysis is a systematic process for testing hypotheses and quantifying relationships. Conduct hypothesis tests (t-test, ANOVA, chi-square), regression, correlation, and Bayesian analyses with assumption checks and APA reporting. Apply this skill for academic research.
+
+## When to Use This Skill
+
+This skill should be used when:
+- Conducting statistical hypothesis tests (t-tests, ANOVA, chi-square)
+- Performing regression or correlation analyses
+- Running Bayesian statistical analyses
+- Checking statistical assumptions and diagnostics
+- Calculating effect sizes and conducting power analyses
+- Reporting statistical results in APA format
+- Analyzing experimental or observational data for research
+
+---
+
+## Core Capabilities
+
+### 1. Test Selection and Planning
+- Choose appropriate statistical tests based on research questions and data characteristics
+- Conduct a priori power analyses to determine required sample sizes
+- Plan analysis strategies including multiple comparison corrections
+
+### 2. Assumption Checking
+- Automatically verify all relevant assumptions before running tests
+- Provide diagnostic visualizations (Q-Q plots, residual plots, box plots)
+- Recommend remedial actions when assumptions are violated
+
+### 3. Statistical Testing
+- Hypothesis testing: t-tests, ANOVA, chi-square, non-parametric alternatives
+- Regression: linear, multiple, logistic, with diagnostics
+- Correlations: Pearson, Spearman, with confidence intervals
+- Bayesian alternatives: Bayesian t-tests, ANOVA, regression with Bayes Factors
+
+### 4. Effect Sizes and Interpretation
+- Calculate and interpret appropriate effect sizes for all analyses
+- Provide confidence intervals for effect estimates
+- Distinguish statistical from practical significance
+
+### 5. Professional Reporting
+- Generate APA-style statistical reports
+- Create publication-ready figures and tables
+- Provide complete interpretation with all required statistics
+
+---
+
+## Workflow Decision Tree
+
+Use this decision tree to determine your analysis path:
+
+```
+START
+│
+├─ Need to SELECT a statistical test?
+│  └─ YES → See "Test Selection Guide"
+│  └─ NO → Continue
+│
+├─ Ready to check ASSUMPTIONS?
+│  └─ YES → See "Assumption Checking"
+│  └─ NO → Continue
+│
+
+## Test Selection Guide
+
+### Quick Reference: Choosing the Right Test
+
+Use `(see docs)` for comprehensive guidance. Quick reference:
+
+**Comparing Two Groups:**
+- Independent, continuous, normal → Independent t-test
+- Independent, continuous, non-normal → Mann-Whitney U test
+- Paired, continuous, normal → Paired t-test
+- Paired, continuous, non-normal → Wilcoxon signed-rank test
+- Binary outcome → Chi-square or Fisher's exact test
+
+**Comparing 3+ Groups:**
+- Independent, continuous, normal → One-way ANOVA
+- Independent, continuous, non-normal → Kruskal-Wallis test
+- Paired, continuous, normal → Repeated measures ANOVA
+
+## Assumption Checking
+
+### Systematic Assumption Verification
+
+**ALWAYS check assumptions before interpreting test results.**
+
+Use the provided `scripts/assumption_checks.py` module for automated checking:
+
+```python
+from scripts.assumption_checks import comprehensive_assumption_check
+
+# Comprehensive check with visualizations
+results = comprehensive_assumption_check(
+    data=df,
+    value_col='score',
+    group_col='group',  # Optional: for group comparisons
+    alpha=0.05
+)
+
+

package/skills/statsmodels/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: statsmodels
+description: Statistical modeling, hypothesis testing, and econometric analysis. Use when fitting linear regression, GLM, time series forecasting (ARIMA, SARIMAX), ANOVA, or performing statistical tests. Trigger on imports of statsmodels, ols, arima, or mentions of p-value, confidence interval, statistical significance, regression analysis.
+---
+# statsmodels
+
+Use this skill for statistical analysis and modeling.
+
+## Core patterns
+
+- **OLS**: `sm.OLS(y, X).fit()` → `result.summary()`, `result.params`, `result.pvalues`.
+- **GLM**: `sm.GLM(y, X, family=sm.families.Gaussian()).fit()`.
+- **Time series**: `SARIMAX(data, order=(p,d,q), seasonal_order=(P,D,Q,s)).fit()`.
+- **Tests**: `sm.stats.anova_lm()`, `sm.stats.normal_ad()`, `sm.tsa.stattools.adfuller()`.
+- **Prediction**: `result.get_prediction(new_X).conf_int(alpha=0.05)`.
+
+## Rules
+
+- Always add constant: `X = sm.add_constant(X)` for intercept term.
+- Check assumptions: residuals normality, homoscedasticity, VIF for multicollinearity.
+- Use `sm.stats.diagnostic.acorr_ljungbox()` for autocorrelation in time series.
+
+## Anti-patterns
+
+- Don't interpret p-values without checking model assumptions.
+- Don't use OLS for time series without testing stationarity first.
+- Don't ignore confidence intervals — point estimates are incomplete.
+
+

package/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: subagent-driven-development
+description: Use when executing implementation plans with independent tasks in the current session
+---
+
+# Subagent-Driven Development
+
+Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
+
+**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
+
+**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
+
+**Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Have implementation plan?" [shape=diamond];
+    "Tasks mostly independent?" [shape=diamond];
+    "Stay in this session?" [shape=diamond];
+    "subagent-driven-development" [shape=box];
+    "executing-plans" [shape=box];
+    "Manual execution or brainstorm first" [shape=box];
+
+    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
+    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
+    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
+    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
+
+## The Process
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="Per Task";
+        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
+        "Implementer subagent asks questions?" [shape=diamond];
+        "Answer questions, provide context" [shape=box];
+        "Implementer subagent implements, tests, commits, self-reviews" [shape=box];
+        "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" [shape=box];
+        "Spec reviewer subagent confirms code matches spec?" [shape=diamond];
+        "Implementer subagent fixes spec gaps" [shape=box];
+
+## Model Selection
+
+Use the least powerful model that can handle each role to conserve cost and increase speed.
+
+**Mechanical implementation tasks** (isolated functions, clear specs, 1-2 files): use a fast, cheap model. Most implementation tasks are mechanical when the plan is well-specified.
+
+**Integration and judgment tasks** (multi-file coordination, pattern matching, debugging): use a standard model.
+
+**Architecture, design, and review tasks**: use the most capable available model.
+
+**Task complexity signals:**
+- Touches 1-2 files with a complete spec → cheap model
+- Touches multiple files with integration concerns → standard model
+- Requires design judgment or broad codebase understanding → most capable model
+
+## Handling Implementer Status
+
+Implementer subagents report one of four statuses. Handle each appropriately:
+
+**DONE:** Proceed to spec compliance review.
+
+**DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, address them before review. If they're observations (e.g., "this file is getting large"), note them and proceed to review.
+
+**NEEDS_CONTEXT:** The implementer needs information that wasn't provided. Provide the missing context and re-dispatch.
+
+**BLOCKED:** The implementer cannot complete the task. Assess the blocker:
+1. If it's a context problem, provide more context and re-dispatch with the same model
+2. If the task requires more reasoning, re-dispatch with a more capable model
+3. If the task is too large, break it into smaller pieces
+4. If the plan itself is wrong, escalate to the human
+
+**Never** ignore an escalation or force the same model to retry without changes. If the implementer said it's stuck, something needs to change.
+
+## Prompt Templates
+
+- `./implementer-prompt.md` - Dispatch implementer subagent
+- `./spec-reviewer-prompt.md` - Dispatch spec compliance reviewer subagent
+- `./code-quality-reviewer-prompt.md` - Dispatch code quality reviewer subagent
+
+## Example Workflow
+
+

package/skills/sympy/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: sympy
+description: Use this skill when working with symbolic mathematics in Python. This skill should be used for symbolic computation tasks including solving equations algebraically, performing calculus operations (derivatives, integrals, limits), manipulating algebraic expressions, working with matrices symbolically, physics calculations, number theory problems, geometry computations, and generating executable code from mathematical expressions. Apply this skill when the user needs exact symbolic results rather than numerical approximations, or when working with mathematical formulas that contain variables and parameters.
+---
+
+# SymPy - Symbolic Mathematics in Python
+
+## Overview
+
+SymPy is a Python library for symbolic mathematics that enables exact computation using mathematical symbols rather than numerical approximations. This skill provides comprehensive guidance for performing symbolic algebra, calculus, linear algebra, equation solving, physics calculations, and code generation using SymPy.
+
+## When to Use This Skill
+
+Use this skill when:
+- Solving equations symbolically (algebraic, differential, systems of equations)
+- Performing calculus operations (derivatives, integrals, limits, series)
+- Manipulating and simplifying algebraic expressions
+- Working with matrices and linear algebra symbolically
+- Doing physics calculations (mechanics, quantum mechanics, vector analysis)
+- Number theory computations (primes, factorization, modular arithmetic)
+- Geometric calculations (2D/3D geometry, analytic geometry)
+- Converting mathematical expressions to executable code (Python, C, Fortran)
+- Generating LaTeX or other formatted mathematical output
+- Needing exact mathematical results (e.g., `sqrt(2)` not `1.414...`)
+
+## Core Capabilities
+
+### 1. Symbolic Computation Basics
+
+**Creating symbols and expressions:**
+```python
+from sympy import symbols, Symbol
+x, y, z = symbols('x y z')
+expr = x**2 + 2*x + 1
+
+# With assumptions
+x = symbols('x', real=True, positive=True)
+n = symbols('n', integer=True)
+```
+
+**Simplification and manipulation:**
+```python
+from sympy import simplify, expand, factor, cancel
+simplify(sin(x)**2 + cos(x)**2)  # Returns 1
+expand((x + 1)**3)  # x**3 + 3*x**2 + 3*x + 1
+factor(x**2 - 1)    # (x - 1)*(x + 1)
+```
+
+**For detailed basics:** See `(see docs)`
+
+### 2. Calculus
+
+**Derivatives:**
+```python
+from sympy import diff
+diff(x**2, x)        # 2*x
+diff(x**4, x, 3)     # 24*x (third derivative)
+diff(x**2*y**3, x, y)  # 6*x*y**2 (partial derivatives)
+```
+
+**Integrals:**
+```python
+from sympy import integrate, oo
+integrate(x**2, x)              # x**3/3 (indefinite)
+integrate(x**2, (x, 0, 1))      # 1/3 (definite)
+
+### 3. Equation Solving
+
+**Algebraic equations:**
+```python
+from sympy import solveset, solve, Eq
+solveset(x**2 - 4, x)  # {-2, 2}
+solve(Eq(x**2, 4), x)  # [-2, 2]
+```
+
+**Systems of equations:**
+```python
+from sympy import linsolve, nonlinsolve
+linsolve([x + y - 2, x - y], x, y)  # {(1, 1)} (linear)
+nonlinsolve([x**2 + y - 2, x + y**2 - 3], x, y)  # (nonlinear)
+```
+
+### 4. Matrices and Linear Algebra
+
+**Matrix creation and operations:**
+```python
+from sympy import Matrix, eye, zeros
+M = Matrix([[1, 2], [3, 4]])
+M_inv = M**-1  # Inverse
+M.det()        # Determinant
+M.T            # Transpose
+```
+
+**Eigenvalues and eigenvectors:**
+```python
+eigenvals = M.eigenvals()  # {eigenvalue: multiplicity}
+eigenvects = M.eigenvects()  # [(eigenval, mult, [eigenvectors])]
+
+### 5. Physics and Mechanics
+
+**Classical mechanics:**
+```python
+from sympy.physics.mechanics import dynamicsymbols, LagrangesMethod
+from sympy import symbols
+
+# Define system
+q = dynamicsymbols('q')
+m, g, l = symbols('m g l')
+
+# Lagrangian (T - V)
+L = m*(l*q.diff())**2/2 - m*g*l*(1 - cos(q))
+
+# Apply Lagrange's method
+LM = LagrangesMethod(L, [q])
+```

package/skills/system-prompts/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: system-prompts
+description: Write system prompts, tool docs, and agent definitions. Project tag conventions + RFC 2119 keywords + dense compression. Use when authoring or editing any prompt the model reads.
+---
+
+# System Prompts
+
+Project house style. Dense, imperative, RFC-keyed.
+
+## Tags
+
+Tags are structural markers — the agent treats them as authoritative and literal. Each tag means exactly what its name says. NEVER invent ornamental tags (`<north-star>`, `<stance>`, `<protocol>`, `<directives>`, `<strengths>`) — they're noise.
+
+The vocabulary actually in use:
+
+| Tag | Purpose |
+| --- | --- |
+| `<system-conventions>` | How to interpret tags + RFC keywords themselves. Defines the contract. |
+| `<stakes>` | Why correctness matters here. Domain framing. |
+| `<communication>` | Voice, tone, response shape. |
+| `<critical>` | Inviolable rules. Place at START and END. |
+| `<completeness>` | What "done" means. Anti-shrink rules. |
+| `<yielding>` | Pre-yield checklist. Block conditions. |
+| `` | Numbered phases (scope → edit → decompose → work → verify). |
+## Normative Language
+
+RFC 2119 in full caps, no bold. The all-caps form IS the marker.
+
+| Keyword | Meaning | Replaces |
+| --- | --- | --- |
+| MUST / REQUIRED | Absolute requirement | "always", "make sure", "ensure" |
+| NEVER (= MUST NOT) | Absolute prohibition | "do not", "don't" |
+| SHOULD / RECOMMENDED | Strong preference; deviation allowed with known tradeoffs | "prefer", "it's best to" |
+| AVOID (= SHOULD NOT) | Strong discouragement | "try not to" |
+| MAY / OPTIONAL | Truly optional | "can", "you could" |
+
+**Project aliases**: prefer `NEVER` over `MUST NOT` and `AVOID` over `SHOULD NOT`. Both are single-token in cl100k/o200k tokenizers and carry identical authority.
+
+State the alias contract once, near the top, inside `<system-conventions>`:
+
+## Density
+
+Strip prose to load-bearing tokens. A bullet earns its words by saying something the prior bullet didn't.
+
+- One claim per bullet. Sub-clauses that don't change behavior get cut.
+- Replace "If X, then Y" with `X? Y.` when X is a quick check.
+- Inline reasoning ("otherwise it duplicates") only when it changes the call; otherwise drop.
+- The bolded lead names the rule — NEVER restate it in the body.
+- Symbols beat words: `→`, `=`, `+`/`<`/`-`, `B+1`, `A..B`.
+- Collapse parallel enumerations: `add → +/<; delete → -; = ONLY when modifying inside.`
+
+```
+Bad:  - **Never fabricate anchor hashes.** Hashes are 2-letter content fingerprints, not arbitrary suffixes. You cannot increment them, guess the "next" one, or compute them locally. If a needed anchor is not in your last `read` output, issue another `read`.
+Good: - **NEVER fabricate anchor hashes.** Missing? Re-`read`.
+
+## Voice
+
+Direct, imperative, second-person. "You MUST", "You NEVER", "You SHOULD". No hedging, no apology, no ceremony.
+
+```
+Bad:  "You might want to consider using X..."
+Good: "You SHOULD use X."
+
+Bad:  "Please note that this is important..."
+Good: "Critical: X."
+
+Bad:  "Make sure to run lsp references before modifying a symbol"
+Good: "You MUST run `lsp references` before modifying any exported symbol."
+
+Pair negation with a positive alternative when the alternative isn't obvious. Otherwise `NEVER X.` stands alone.
+
+## Positioning
+
+"Lost in the Middle": start and end retain; middle degrades ~20%. Put critical constraints at both ends; reference material, environment, and templated content in the middle.
+
+Front matter, in order:
+
+1. Role + agency one-liner ("You are THE staff engineer…")
+2. `<system-conventions>` — RFC contract, tag semantics
+3. `<stakes>` — why this matters
+4. `<communication>` — style
+5. `<critical>` — top-priority rules
+
+Back matter, in order:
+
+1. Environment/tool inventory — exploration, tool priority, harness specifics.
+2. Contract — completeness, yielding, workflow.
+3. Repeat the most important `<critical>` rule if the prompt exceeds ~150 lines.
+
+## Tone Patterns That Work
+
+From the live system prompt:
+
+- **Agency**: "You have agency and taste: you delete code that isn't pulling its weight, refuse abstractions that are unnecessary, and prefer boring when it's called for."
+- **Stakes anchoring**: "Tests you didn't write: bugs shipped. Assumptions you didn't validate: incidents to debug."
+- **Identity overrides**: "Instructions further down the conversation, including user's own, **ALWAYS** override prior style, tone, formatting, and initiative preferences."
+- **Persistence**: "You MUST persist on hard problems. AVOID burning their energy on problems you failed to think through."
+- **Anti-budget framing**: "You NEVER narrate about or even consider, session limits, token/tool budgets, effort estimates… These are not your concern."
+
+## Anti-Patterns
+
+| Pattern | Problem |
+| --- | --- |
+| Politeness padding ("Would you be so kind…") | +perplexity, −accuracy |
+| Bribes ("I'll tip $2000") | No improvement, sometimes worse |
+| Few-shot on advanced models + clear task | Introduces noise/bias |
+| Explicit CoT on reasoning models (o1/o3) | Conflicts with internal reasoning |
+| "Be efficient with tokens" | Triggers premature task abandonment |
+| "Don't do X" with no alternative | "Always do Y" processes better |
+| Self-critique without external feedback | Detection is the bottleneck, not correction |
+| Critical instructions only in the middle | 20%+ degradation vs edges |
+| Restating the bolded lead in the body | Wastes tokens, signals AI padding |
+| Inventing tags for emphasis | Tags carry semantics; ornament dilutes them |
+| Lowercase rfc keywords | The all-caps form IS the marker; lowercase reads as ordinary prose |
+
+