bytesagain3

---
name: "arrow"
version: "1.0.0"
description: "Apache Arrow in-memory columnar format reference. Zero-copy data exchange, columnar memory layout with validity bitmaps, pyarrow Table/RecordBatch/compute, Arrow Flight RPC for high-performance transfer, Dataset API with predicate pushdown, pandas/DuckDB/Polars/Spark integration, Gandiva LLVM compiler, and ADBC database connectivity."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [arrow, columnar, memory, ipc, flight, data, analytics]
category: "data"
---

# Apache Arrow

Apache Arrow in-memory columnar format reference — zero-copy, cross-language.

## Commands

| Command | Description |
|---------|-------------|
| `intro` | Arrow overview, zero-copy, architecture |
| `format` | Columnar layout, buffers, record batches |
| `python` | pyarrow arrays, tables, compute functions |
| `flight` | Arrow Flight RPC server/client |
| `dataset` | Dataset API, partitioning, pushdown |
| `integration` | pandas/DuckDB/Polars/Spark/R interop |
| `gandiva` | LLVM expression compiler |
| `ecosystem` | Implementations, ADBC, projects |

FILE:scripts/script.sh
#!/usr/bin/env bash
# arrow — Apache Arrow columnar memory format reference
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail
VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
arrow v1.0.0 — Apache Arrow Columnar Memory Format Reference

Usage: arrow <command>

Commands:
  intro         Arrow overview, zero-copy IPC
  format        Record batches, buffers, validity
  python        pyarrow Table, RecordBatch, compute
  flight        Arrow Flight RPC protocol
  dataset       Dataset API, partitioning, filtering
  integration   pandas/spark/duckdb/polars interop
  gandiva       LLVM expression compiler
  ecosystem     Implementations across languages

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Apache Arrow — In-Memory Columnar Format

## What is Arrow?
Apache Arrow is a cross-language development platform for in-memory
columnar data. It specifies a standardized memory format that eliminates
serialization overhead when sharing data between systems.

## Key Innovation: Zero-Copy
Traditional data exchange:
```
System A (pandas) → serialize to CSV/JSON → deserialize → System B (Spark)
                    ~seconds for 1GB                        ~seconds
```

Arrow data exchange:
```
System A (pandas) → shared Arrow memory → System B (Spark)
                    ~zero overhead
```

## Core Features
- **Columnar memory layout**: CPU-cache friendly, SIMD vectorization
- **Zero-copy reads**: Memory-map files, no deserialization
- **Cross-language**: Same memory format in C++/Java/Rust/Python/Go/JS/R
- **Rich type system**: Primitives, nested (struct/list/map), temporal, decimal
- **IPC**: Streaming and file formats for inter-process communication
- **Flight**: High-performance RPC for Arrow data transfer
- **Compute kernels**: Built-in functions (filter, sort, aggregate)

## Architecture
```
Applications:  pandas  Spark  DuckDB  Polars  R  Julia
                  │       │      │       │    │    │
                  └───────┴──────┴───────┴────┴────┘
                              Arrow Memory Format
                              (shared standard)
                  ┌───────┬──────┬───────┬────┬────┐
                  │       │      │       │    │    │
Formats:       Parquet  ORC   CSV    JSON  IPC  Flight
```

## Install
```bash
pip install pyarrow          # Python
install.packages("arrow")   # R
cargo add arrow              # Rust
go get github.com/apache/arrow/go  # Go
```
EOF
}

cmd_format() {
    cat << 'EOF'
# Arrow Memory Format

## Columnar Layout
```
Row-oriented (CSV/JSON):
  Row 0: {id: 1, name: "Alice", age: 30}
  Row 1: {id: 2, name: "Bob",   age: 25}
  Row 2: {id: 3, name: "Carol", age: 35}

Column-oriented (Arrow):
  id:   [1, 2, 3]           ← contiguous int64 buffer
  name: ["Alice","Bob","Carol"] ← offsets + char buffer
  age:  [30, 25, 35]        ← contiguous int64 buffer
```

## Buffer Structure
Each column (Array) has:
1. **Validity bitmap**: 1 bit per value (null tracking)
2. **Data buffer**: Actual values (fixed-width) or offsets + chars (variable)

```
Int64 Array [1, null, 3]:
  Validity:  [1, 0, 1]          (bitmap: 0b101)
  Data:      [1, undefined, 3]  (64 bits each)

String Array ["hi", "bye"]:
  Validity:  [1, 1]
  Offsets:   [0, 2, 5]          (int32)
  Chars:     "hibye"            (UTF-8 bytes)
```

## Record Batch
A collection of equal-length arrays with a schema:
```python
import pyarrow as pa

schema = pa.schema([
    ('id', pa.int64()),
    ('name', pa.string()),
    ('score', pa.float64()),
])

batch = pa.record_batch([
    pa.array([1, 2, 3]),
    pa.array(["a", "b", "c"]),
    pa.array([0.1, 0.2, 0.3]),
], schema=schema)

print(batch.num_rows)     # 3
print(batch.num_columns)  # 3
print(batch.nbytes)       # bytes in memory
```

## Table (Collection of Batches)
```python
table = pa.table({
    'id': [1, 2, 3, 4, 5],
    'name': ['a', 'b', 'c', 'd', 'e'],
})

# Table can span multiple record batches
# Useful for streaming/chunked processing
print(table.num_rows)
print(table.column_names)
print(table.schema)
```

## Type System
| Category | Types |
|----------|-------|
| Integer | int8/16/32/64, uint8/16/32/64 |
| Float | float16/32/64 |
| String | utf8, large_utf8, binary |
| Temporal | date32, timestamp, time32/64, duration |
| Nested | struct, list, large_list, map |
| Other | bool, decimal128, null, dictionary |
EOF
}

cmd_python() {
    cat << 'EOF'
# Python — pyarrow

## Arrays
```python
import pyarrow as pa

# Create arrays
arr = pa.array([1, 2, 3, None, 5])
print(arr.type)       # int64
print(arr.null_count)  # 1
print(arr[0].as_py())  # 1

# Typed arrays
f = pa.array([1.1, 2.2], type=pa.float32())
s = pa.array(["hello", "world"])
b = pa.array([True, False, None])
```

## Tables
```python
# Create table
table = pa.table({
    'id': pa.array([1, 2, 3]),
    'name': pa.array(['Alice', 'Bob', 'Carol']),
    'score': pa.array([85.5, 92.0, 78.3]),
})

# Access columns
print(table.column('name'))
print(table['score'])

# Filter
mask = pa.compute.greater(table['score'], 80)
filtered = table.filter(mask)

# Sort
sorted_t = table.sort_by([('score', 'descending')])

# Select columns
subset = table.select(['id', 'name'])

# Add column
table = table.append_column('rank', pa.array([2, 1, 3]))

# Drop column
table = table.drop(['rank'])
```

## Compute Functions
```python
import pyarrow.compute as pc

# Aggregations
pc.sum(table['score'])        # 255.8
pc.mean(table['score'])       # 85.27
pc.min_max(table['score'])    # {'min': 78.3, 'max': 92.0}
pc.count(table['score'])      # 3

# String operations
pc.utf8_upper(table['name'])
pc.utf8_length(table['name'])
pc.match_substring(table['name'], 'li')

# Arithmetic
pc.add(table['score'], 10)
pc.multiply(table['score'], 1.1)

# Filtering
pc.filter(table['name'], pc.greater(table['score'], 80))

# Sorting
pc.sort_indices(table['score'], sort_keys=[('score', 'ascending')])
```

## Pandas Conversion
```python
# Arrow → Pandas
df = table.to_pandas()

# Pandas → Arrow
table = pa.Table.from_pandas(df)

# Zero-copy (when possible)
table = pa.Table.from_pandas(df, preserve_index=False)

# Use Arrow-backed pandas dtypes (less memory)
df = table.to_pandas(types_mapper=pd.ArrowDtype)
```

## I/O
```python
import pyarrow.parquet as pq
import pyarrow.feather as feather
import pyarrow.csv as csv

# Parquet
pq.write_table(table, 'data.parquet')
table = pq.read_table('data.parquet')

# Feather/IPC
feather.write_feather(table, 'data.feather')
table = feather.read_table('data.feather')

# CSV
csv.write_csv(table, 'data.csv')
table = csv.read_csv('data.csv')

# IPC Stream
with pa.ipc.new_file('data.arrow', table.schema) as writer:
    writer.write_table(table)
reader = pa.ipc.open_file('data.arrow')
table = reader.read_all()
```
EOF
}

cmd_flight() {
    cat << 'EOF'
# Arrow Flight — High-Performance Data RPC

## What is Flight?
Arrow Flight is a RPC framework for high-performance data transfer
built on gRPC. It transfers Arrow record batches with zero serialization
overhead — data stays in Arrow format end-to-end.

## Architecture
```
Client                        Server
  │                              │
  ├── GetFlightInfo() ────────→  │  "What data do you have?"
  │                              │
  ├── DoGet(ticket) ──────────→  │  "Give me this dataset"
  │  ←── RecordBatch stream ──   │   (Arrow format, zero-copy)
  │                              │
  ├── DoPut(stream) ──────────→  │  "Here's data to store"
  │   ── RecordBatch stream ──→  │
  │                              │
  ├── DoAction(action) ───────→  │  "Run this command"
  │                              │
  └── ListFlights() ──────────→  │  "List available datasets"
```

## Server Example
```python
import pyarrow.flight as flight

class MyFlightServer(flight.FlightServerBase):
    def __init__(self):
        super().__init__("grpc://0.0.0.0:8815")
        self.tables = {}

    def do_put(self, context, descriptor, reader, writer):
        key = descriptor.path[0].decode()
        self.tables[key] = reader.read_all()

    def do_get(self, context, ticket):
        key = ticket.ticket.decode()
        table = self.tables[key]
        return flight.RecordBatchStream(table)

    def list_flights(self, context, criteria):
        for key, table in self.tables.items():
            descriptor = flight.FlightDescriptor.for_path(key)
            info = flight.FlightInfo(
                table.schema, descriptor, [], table.num_rows, -1)
            yield info

server = MyFlightServer()
server.serve()
```

## Client Example
```python
client = flight.connect("grpc://localhost:8815")

# Upload data
table = pa.table({'x': [1, 2, 3]})
descriptor = flight.FlightDescriptor.for_path("my_data")
writer, _ = client.do_put(descriptor, table.schema)
writer.write_table(table)
writer.close()

# Download data
ticket = flight.Ticket(b"my_data")
reader = client.do_get(ticket)
result = reader.read_all()
```

## Performance
- **10-100x faster** than REST/JSON for large datasets
- Zero serialization (Arrow format on wire = Arrow format in memory)
- Parallel streams for multi-partition datasets
- Built-in authentication and encryption (TLS)

## Use Cases
- Database query results (DuckDB, Dremio, InfluxDB use Flight)
- Distributed ML feature serving
- Real-time analytics pipelines
- Cross-language data transfer
EOF
}

cmd_dataset() {
    cat << 'EOF'
# Dataset API — Large-Scale Data Access

## What is the Dataset API?
The Dataset API provides uniform access to large, potentially multi-file
datasets. It handles partitioning, predicate pushdown, and column projection
across Parquet, ORC, CSV, and IPC files.

## Read Dataset
```python
import pyarrow.dataset as ds

# Single file
dataset = ds.dataset('data.parquet')

# Directory of files
dataset = ds.dataset('data/', format='parquet')

# Partitioned directory
# data/year=2025/month=01/part-0.parquet
# data/year=2025/month=02/part-0.parquet
dataset = ds.dataset('data/', format='parquet', partitioning='hive')

# Multiple formats
dataset = ds.dataset([
    ds.dataset('parquet_files/', format='parquet'),
    ds.dataset('csv_files/', format='csv'),
])
```

## Filter (Predicate Pushdown)
```python
# Filter pushes down to file reader (skips irrelevant row groups)
table = dataset.to_table(
    filter=(ds.field('year') == 2026) & (ds.field('amount') > 100),
    columns=['id', 'name', 'amount']
)

# Scanner for fine-grained control
scanner = dataset.scanner(
    filter=ds.field('status') == 'active',
    columns=['id', 'name'],
    batch_size=10000,
)
for batch in scanner.to_batches():
    process(batch)
```

## Write Partitioned Dataset
```python
import pyarrow.dataset as ds

ds.write_dataset(
    table,
    'output/',
    format='parquet',
    partitioning=ds.partitioning(
        pa.schema([('year', pa.int32()), ('month', pa.int32())]),
        flavor='hive',
    ),
    existing_data_behavior='overwrite_or_ignore',
)
```

## Partitioning Schemes
```python
# Hive-style: data/year=2026/month=03/
hive = ds.HivePartitioning(schema)

# Directory-style: data/2026/03/
dir_part = ds.DirectoryPartitioning(schema)

# Custom
ds.partitioning(
    field_names=['date', 'region'],
    flavor='hive',
)
```
EOF
}

cmd_integration() {
    cat << 'EOF'
# Arrow Integration with Other Tools

## Pandas
```python
import pyarrow as pa
import pandas as pd

# Pandas → Arrow (zero-copy when possible)
table = pa.Table.from_pandas(df)

# Arrow → Pandas
df = table.to_pandas()

# Arrow-backed pandas (2.0+, less memory)
df = table.to_pandas(types_mapper=pd.ArrowDtype)
```

## DuckDB
```python
import duckdb

# DuckDB reads Arrow tables directly (zero-copy)
table = pa.table({'x': [1, 2, 3], 'y': ['a', 'b', 'c']})

result = duckdb.sql("SELECT * FROM table WHERE x > 1")
arrow_result = result.arrow()  # Returns Arrow table

# DuckDB + Arrow + Parquet
result = duckdb.sql("""
    SELECT year, SUM(amount)
    FROM read_parquet('data/*.parquet')
    GROUP BY year
""").arrow()
```

## Polars
```python
import polars as pl

# Polars uses Arrow internally
df = pl.DataFrame({'x': [1, 2, 3]})
arrow_table = df.to_arrow()

# Arrow → Polars
df = pl.from_arrow(arrow_table)
```

## Spark
```python
# PySpark ↔ Arrow (for UDFs and toPandas)
spark.conf.set("spark.sql.execution.arrow.pyspark.enabled", "true")

# Fast toPandas (uses Arrow transfer)
df = spark_df.toPandas()  # Uses Arrow behind the scenes

# Arrow-based UDF
@pandas_udf("double")
def multiply(s: pd.Series) -> pd.Series:
    return s * 2

spark_df.select(multiply(col("value")))
```

## R
```r
library(arrow)

# Read Arrow IPC file
table <- read_ipc_file("data.arrow")
df <- as.data.frame(table)

# Write
write_ipc_file(table, "output.arrow")

# Shared with Python (same format, no conversion)
```

## Rust
```rust
use arrow::array::*;
use arrow::datatypes::*;
use arrow::record_batch::RecordBatch;

let id = Int64Array::from(vec![1, 2, 3]);
let name = StringArray::from(vec!["a", "b", "c"]);

let schema = Schema::new(vec![
    Field::new("id", DataType::Int64, false),
    Field::new("name", DataType::Utf8, false),
]);

let batch = RecordBatch::try_new(
    Arc::new(schema), vec![Arc::new(id), Arc::new(name)]
)?;
```
EOF
}

cmd_gandiva() {
    cat << 'EOF'
# Gandiva — LLVM Expression Compiler

## What is Gandiva?
Gandiva compiles Arrow compute expressions to native machine code
using LLVM. It provides 10-100x speedup over interpreted evaluation
for filter and project operations.

## How It Works
```
Expression: (score > 80) AND (status = 'active')
    │
    ▼ Gandiva compiles to
    │
LLVM IR → Native Machine Code (x86/ARM)
    │
    ▼ Executes directly on
    │
Arrow Record Batches (columnar, SIMD-friendly)
```

## Python Usage
```python
import pyarrow.gandiva as gandiva

# Create schema
schema = pa.schema([
    ('score', pa.float64()),
    ('name', pa.string()),
    ('active', pa.bool_()),
])

# Build filter expression
builder = gandiva.TreeExprBuilder()
score_field = builder.make_field(schema.field('score'))
threshold = builder.make_literal(80.0, pa.float64())
condition = builder.make_function("greater_than",
    [score_field, threshold], pa.bool_())

# Compile filter
filter_ = gandiva.make_filter(schema, condition)

# Apply to record batch
batch = pa.record_batch(...)
result = filter_.evaluate(batch.num_rows, batch)
# result contains indices where condition is true
```

## Supported Operations
| Category | Operations |
|----------|-----------|
| Comparison | =, !=, <, >, <=, >= |
| Arithmetic | +, -, *, /, % |
| Logical | AND, OR, NOT |
| String | like, length, upper, lower, substr |
| Temporal | extract(year/month/day), timestampdiff |
| Math | abs, ceil, floor, round, power, log |
| Null | isnull, isnotnull, nvl, if_null |
| Cast | cast(expr, type) |

## When to Use
- Large batch processing (>100K rows)
- Complex filter expressions
- Repeated evaluation on same schema
- CPU-bound workloads where vectorization matters
- NOT for small datasets (compilation overhead)
EOF
}

cmd_ecosystem() {
    cat << 'EOF'
# Arrow Ecosystem

## Language Implementations
| Language | Library | Maturity |
|----------|---------|----------|
| C++ | libarrow | Reference impl |
| Java | arrow-java | Production |
| Rust | arrow-rs | Production |
| Python | pyarrow (C++ bindings) | Production |
| Go | arrow/go | Production |
| JavaScript | arrow-js | Stable |
| R | arrow (C++ bindings) | Production |
| Julia | Arrow.jl | Stable |
| C# | Apache.Arrow | Stable |
| Ruby | red-arrow | Beta |
| MATLAB | arrow (C++ bindings) | Beta |

## Projects Using Arrow
| Project | How |
|---------|-----|
| pandas | Arrow backend for dtypes (2.0+) |
| Polars | Built entirely on Arrow |
| DuckDB | Native Arrow integration |
| Spark | Arrow for pandas UDFs, toPandas |
| Dremio | Arrow Flight for queries |
| InfluxDB IOx | Arrow + Flight for time-series |
| DataFusion | Arrow-native query engine |
| Ballista | Distributed SQL on Arrow |
| Velox | Meta's Arrow-compatible engine |
| ADBC | Arrow Database Connectivity |

## ADBC (Arrow Database Connectivity)
```python
import adbc_driver_postgresql.dbapi

# Connect to PostgreSQL
conn = adbc_driver_postgresql.dbapi.connect(
    "postgresql://user:pass@localhost/mydb"
)
cursor = conn.cursor()
cursor.execute("SELECT * FROM users")

# Results come as Arrow tables (zero-copy from DB)
table = cursor.fetch_arrow_table()
```

ADBC is the Arrow-native successor to JDBC/ODBC.
Supported databases: PostgreSQL, SQLite, Snowflake, Flight SQL.

## Key Specifications
| Spec | Purpose |
|------|---------|
| Columnar Format | Memory layout |
| IPC Format | File and streaming serialization |
| Flight | RPC data transfer |
| Flight SQL | SQL queries over Flight |
| ADBC | Database connectivity |
| C Data Interface | Zero-copy across FFI |
| C Stream Interface | Streaming across FFI |
EOF
}

case "-help" in
    intro)       cmd_intro ;;
    format)      cmd_format ;;
    python)      cmd_python ;;
    flight)      cmd_flight ;;
    dataset)     cmd_dataset ;;
    integration) cmd_integration ;;
    gandiva)     cmd_gandiva ;;
    ecosystem)   cmd_ecosystem ;;
    help|-h)     show_help ;;
    version|-v)  echo "arrow v$VERSION" ;;
    *)           echo "Unknown: $1"; show_help ;;
esac

---
name: "auditd"
version: "1.0.0"
description: "Linux Audit Framework reference. auditctl rules for file watches and syscall auditing, auditd.conf configuration, ausearch log queries, aureport summaries, audit.log format, CIS/PCI-DSS compliance rules, and audit tools."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [auditd, audit, security, linux, compliance, logging]
category: "sysops"
---

# auditd

Linux Audit Framework reference — kernel-level security auditing.

## Commands

| Command | Description |
|---------|-------------|
| `intro` | What is auditd, architecture, quick start |
| `rules` | auditctl watches, syscall rules, filters |
| `config` | auditd.conf settings, rotation, disk actions |
| `search` | ausearch by key, time, user, file |
| `report` | aureport summaries, login, auth, file |
| `logs` | audit.log format, field meanings |
| `compliance` | CIS benchmark and PCI-DSS rules |
| `tools` | auditctl, audit2allow, aulast, autrace |

FILE:scripts/script.sh
#!/usr/bin/env bash
# auditd — Linux Audit Framework reference
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail
VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
auditd v1.0.0 — Linux Audit Framework Reference

Usage: auditd <command>

Commands:
  intro       What is auditd, kernel audit system
  rules       auditctl rules, watches, syscalls
  config      auditd.conf reference
  search      ausearch queries
  report      aureport summaries
  logs        audit.log format
  compliance  PCI-DSS, HIPAA, CIS rules
  tools       auditctl, audit2allow, aulast

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Linux Audit Framework (auditd)

## What is auditd?
The Linux Audit system provides a way to track security-relevant events
on a system. It records who did what, when, and the outcome — essential
for compliance (PCI-DSS, HIPAA, SOX) and forensic analysis.

## Architecture
```
Kernel ──audit subsystem──→ kauditd ──→ auditd daemon
                                          │
                    ┌─────────────────────┤
                    ▼                     ▼
              audit.log            audisp (dispatcher)
                                    │
                              ┌─────┼─────┐
                              ▼     ▼     ▼
                          syslog  plugin  remote
```

## Components
- **auditd**: Daemon that writes audit records to disk
- **auditctl**: Control utility to manage rules and status
- **ausearch**: Search audit logs by criteria
- **aureport**: Generate summary reports
- **augenrules**: Merge rule files from /etc/audit/rules.d/
- **aulast**: Similar to `last` but from audit logs
- **auvirt**: Report VM-related events

## Quick Start
```bash
# Check if running
systemctl status auditd

# Check audit status
auditctl -s

# List current rules
auditctl -l

# Watch a file
auditctl -w /etc/passwd -p wa -k identity

# Search for events
ausearch -k identity

# Generate report
aureport --summary
```
EOF
}

cmd_rules() {
    cat << 'EOF'
# Audit Rules

## Rule Types

### File/Directory Watch (-w)
```bash
# Watch file for writes and attribute changes
auditctl -w /etc/passwd -p wa -k identity

# Watch directory recursively
auditctl -w /etc/ssh/ -p wa -k sshd_config

# Permission filters: r=read, w=write, x=execute, a=attribute
auditctl -w /etc/shadow -p rwxa -k shadow_access
```

### System Call Rules (-a)
```bash
# Log all execve calls (every command execution)
auditctl -a always,exit -F arch=b64 -S execve -k exec_commands

# Log file deletions
auditctl -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename \
  -S renameat -k file_deletion

# Log all mount operations
auditctl -a always,exit -F arch=b64 -S mount -k mounts

# Log time changes
auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday \
  -S clock_settime -k time_change

# Log by specific user
auditctl -a always,exit -F arch=b64 -S open -F auid=1000 -k user_files
```

### Filter Fields (-F)
| Field | Example | Meaning |
|-------|---------|---------|
| arch | b64, b32 | Architecture |
| auid | 1000 | Audit UID (login user) |
| uid | 0 | Effective UID |
| euid | 0 | Effective UID |
| pid | 1234 | Process ID |
| path | /etc/passwd | File path |
| perm | wa | Permission filter |
| key | -k mykey | Search key |
| success | 0 or 1 | Syscall succeeded? |
| exit | -EACCES | Exit value |

## Persistent Rules
```bash
# Rules in /etc/audit/rules.d/*.rules survive reboot
# File: /etc/audit/rules.d/10-identity.rules
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity

# Load rules
augenrules --load

# Or directly
auditctl -R /etc/audit/rules.d/10-identity.rules
```

## Delete Rules
```bash
# Delete all rules
auditctl -D

# Delete specific watch
auditctl -W /etc/passwd -p wa -k identity

# Lock rules (prevent changes until reboot)
auditctl -e 2
```
EOF
}

cmd_config() {
    cat << 'EOF'
# auditd.conf Configuration

## File Location
```
/etc/audit/auditd.conf
```

## Key Settings
```ini
# Where to write logs
log_file = /var/log/audit/audit.log
log_format = ENRICHED

# Log rotation
max_log_file = 50        # MB per log file
num_logs = 5             # Number of rotated logs
max_log_file_action = ROTATE

# Disk space management
space_left = 75          # MB remaining threshold
space_left_action = SYSLOG
admin_space_left = 50    # Critical threshold
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Flush policy
flush = INCREMENTAL_ASYNC
freq = 50                # Flush every 50 records

# Network (receive from remote)
tcp_listen_port = 60     # Uncomment to receive remote logs
tcp_max_per_addr = 1
```

## Log Format Options
| Format | Description |
|--------|-------------|
| RAW | UID/GID as numbers |
| ENRICHED | UID/GID resolved to names |

## Space Actions
| Action | Effect |
|--------|--------|
| IGNORE | Do nothing |
| SYSLOG | Send warning to syslog |
| SUSPEND | Stop writing audit records |
| ROTATE | Rotate log file |
| HALT | Shut down the system |

## Restart After Changes
```bash
# auditd doesn't respond to systemctl restart normally
service auditd restart    # Use service command
# Or
kill -HUP $(pidof auditd)
```
EOF
}

cmd_search() {
    cat << 'EOF'
# ausearch — Search Audit Logs

## Search by Key
```bash
# Events tagged with a key
ausearch -k identity
ausearch -k sshd_config
ausearch -k exec_commands
```

## Search by Time
```bash
# Today's events
ausearch -ts today

# Last hour
ausearch -ts recent

# Specific time range
ausearch -ts 03/24/2026 08:00:00 -te 03/24/2026 12:00:00

# Relative
ausearch -ts this-week
ausearch -ts this-month
```

## Search by User
```bash
# By login UID (who originally logged in)
ausearch -ua 1000

# By effective UID
ausearch -ue 0     # Actions done as root

# By specific user
ausearch -ua root
```

## Search by Event Type
```bash
# Login events
ausearch -m USER_LOGIN

# Authentication
ausearch -m USER_AUTH

# File access
ausearch -m PATH

# System calls
ausearch -m SYSCALL

# Configuration changes
ausearch -m CONFIG_CHANGE
```

## Search by File
```bash
ausearch -f /etc/passwd
ausearch -f /etc/shadow
```

## Output Formats
```bash
# Interpreted (human-readable)
ausearch -i -k identity

# CSV format
ausearch -k identity --format csv

# Just the raw text
ausearch -k identity --raw
```

## Combine Filters
```bash
# Root actions on /etc/passwd today
ausearch -ua 0 -f /etc/passwd -ts today -i
```
EOF
}

cmd_report() {
    cat << 'EOF'
# aureport — Audit Report Summaries

## Summary Report
```bash
aureport --summary
```

Output:
```
Range of time in logs: 03/01/2026 00:00:00 - 03/24/2026 12:00:00
Selected time for report: 03/01/2026 00:00:00 - 03/24/2026 12:00:00
Number of changes in configuration: 15
Number of changes to accounts: 3
Number of logins: 142
Number of failed logins: 7
Number of authentications: 285
Number of failed authentications: 12
Number of anomalies: 0
Number of responses to anomalies: 0
Number of keys: 8
```

## Specific Reports
```bash
# Login report
aureport --login
aureport --login --failed    # Failed logins only

# Authentication
aureport --auth
aureport --auth --failed

# File access
aureport --file

# Executable report
aureport --executable

# System call report
aureport --syscall

# User report
aureport --user

# Terminal report (which TTY)
aureport --terminal

# Anomaly report
aureport --anomaly
```

## Time-Filtered Reports
```bash
# Today only
aureport --login -ts today

# This week
aureport --auth -ts this-week

# Specific range
aureport --file -ts 03/20/2026 -te 03/24/2026
```

## Key Report
```bash
# Events by audit key
aureport --key

# Output:
# Key            Count
# identity       15
# sshd_config    3
# exec_commands  892
```
EOF
}

cmd_logs() {
    cat << 'EOF'
# Audit Log Format

## Log Location
```
/var/log/audit/audit.log
```

## Log Entry Format
```
type=SYSCALL msg=audit(1711267200.123:456): arch=c000003e syscall=2
success=yes exit=3 a0=7ffd1234 a1=0 a2=0 a3=0 items=1 ppid=1234
pid=5678 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=1 comm="cat" exe="/usr/bin/cat"
key="shadow_access"

type=PATH msg=audit(1711267200.123:456): item=0 name="/etc/shadow"
inode=12345 dev=fd:01 mode=0100000 ouid=0 ogid=0 rdev=00:00
nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
```

## Key Fields
| Field | Meaning |
|-------|---------|
| type | Record type (SYSCALL, PATH, USER_AUTH...) |
| msg | Timestamp(epoch:serial) |
| arch | System architecture |
| syscall | Syscall number (2=open, 59=execve) |
| success | yes/no |
| auid | Audit UID (original login user) |
| uid | Effective UID at time of event |
| pid | Process ID |
| comm | Command name |
| exe | Full executable path |
| key | Matching audit rule key |
| tty | Terminal |
| ses | Session ID |

## Common Record Types
| Type | Meaning |
|------|---------|
| SYSCALL | System call event |
| PATH | File path in syscall |
| CWD | Current working directory |
| EXECVE | Command + arguments |
| USER_AUTH | Authentication attempt |
| USER_LOGIN | Login event |
| USER_LOGOUT | Logout event |
| CONFIG_CHANGE | Audit config changed |
| ANOM_PROMISCUOUS | Interface in promisc mode |

## Parse with Python
```python
import re
with open('/var/log/audit/audit.log') as f:
    for line in f:
        m = re.search(r'comm="([^"]+)".*key="([^"]+)"', line)
        if m:
            print(f'{m.group(2)}: {m.group(1)}')
```
EOF
}

cmd_compliance() {
    cat << 'EOF'
# Compliance Audit Rules

## CIS Benchmark (RHEL 7/8/9)
```bash
# /etc/audit/rules.d/50-cis.rules

# 4.1.3 Record events that modify date/time
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
-a always,exit -F arch=b64 -S clock_settime -k time-change
-w /etc/localtime -p wa -k time-change

# 4.1.4 Record events that modify user/group info
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# 4.1.5 Record events that modify network
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/sysconfig/network -p wa -k system-locale

# 4.1.6 Record login and logout events
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins

# 4.1.7 Record session initiation
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k logins
-w /var/log/btmp -p wa -k logins

# 4.1.8 Record permission changes
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -k perm_mod
-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -k perm_mod
-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -k perm_mod
-a always,exit -F arch=b64 -S removexattr -S lremovexattr -S fremovexattr -k perm_mod

# 4.1.11 Record use of privileged commands
# Generate with: find / -xdev -perm /6000 -type f
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

# 4.1.17 Make rules immutable
-e 2
```

## PCI-DSS Requirements
```bash
# Req 10.2.1: All individual user access to cardholder data
# Req 10.2.2: All actions by root/admin
# Req 10.2.3: All access to audit trails
# Req 10.2.4: Invalid logical access attempts
# Req 10.2.5: Use of identification/authentication mechanisms
# Req 10.2.6: Initialization/stopping of audit logs
# Req 10.2.7: Creation/deletion of system-level objects
```
EOF
}

cmd_tools() {
    cat << 'EOF'
# Audit Tools Reference

## auditctl — Runtime Rule Management
```bash
auditctl -s              # Show status
auditctl -l              # List rules
auditctl -D              # Delete all rules
auditctl -e 1            # Enable auditing
auditctl -e 0            # Disable auditing
auditctl -e 2            # Lock rules (immutable)
auditctl -b 8192         # Set backlog buffer
auditctl -f 1            # Set failure flag (0=silent, 1=printk, 2=panic)
auditctl -r 100          # Rate limit (messages/sec, 0=unlimited)
```

## aulast — Login History from Audit
```bash
aulast              # Like 'last' but from audit logs
aulast --bad        # Failed logins
aulast -f /var/log/audit/audit.log.1  # From specific file
```

## auvirt — Virtual Machine Events
```bash
auvirt --summary    # VM event summary
auvirt --all-events # All VM events
```

## audit2allow — SELinux Policy from Denials
```bash
# Generate SELinux policy from audit denials
audit2allow -a              # From all audit logs
ausearch -m AVC | audit2allow -M mypolicy
semodule -i mypolicy.pp
```

## autrace — Trace Process
```bash
# Trace a command (like strace but via audit)
autrace /bin/ls /tmp
ausearch -p <pid_from_autrace>
```

## Useful One-Liners
```bash
# Top 10 most executed commands
ausearch -m EXECVE -ts today -i | grep 'comm=' | \
  sed 's/.*comm="\([^"]*\)".*/\1/' | sort | uniq -c | sort -rn | head

# Failed logins today
aureport --login --failed -ts today

# Who used sudo
ausearch -k privileged -ts today -i | grep 'auid='

# Files accessed by specific user
ausearch -ua 1000 -ts today -i | grep name=
```
EOF
}

case "-help" in
    intro)      cmd_intro ;;
    rules)      cmd_rules ;;
    config)     cmd_config ;;
    search)     cmd_search ;;
    report)     cmd_report ;;
    logs)       cmd_logs ;;
    compliance) cmd_compliance ;;
    tools)      cmd_tools ;;
    help|-h)    show_help ;;
    version|-v) echo "auditd v$VERSION" ;;
    *)          echo "Unknown: $1"; show_help ;;
esac

---
name: "rkhunter"
version: "1.0.0"
description: "Rkhunter reference tool. Use when working with rkhunter in sysops contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [rkhunter, sysops, dev, reference, cli]
category: "sysops"
---

# Rkhunter

Rkhunter reference tool. Use when working with rkhunter in sysops contexts.

## When to Use

- Working with rkhunter and need quick reference
- Looking up sysops standards or best practices for rkhunter
- Troubleshooting rkhunter issues
- Need a checklist or guide for rkhunter tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# rkhunter — Rkhunter reference tool. Use when working with rkhunter in sysops contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
rkhunter v$VERSION — Rkhunter Reference Tool

Usage: rkhunter <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Rkhunter — Overview

## What is Rkhunter?
Rkhunter (rkhunter) is a specialized tool/concept in the sysops domain.
It provides essential capabilities for professionals working with rkhunter.

## Key Concepts
- Core rkhunter principles and fundamentals
- How rkhunter fits into the broader sysops ecosystem  
- Essential terminology every practitioner should know

## Why Rkhunter Matters
Understanding rkhunter is critical for:
- Improving efficiency in sysops workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic rkhunter concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Rkhunter — Quick Start Guide

## Prerequisites
- Basic understanding of sysops concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the rkhunter package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Rkhunter — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for rkhunter
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Rkhunter — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Rkhunter — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Rkhunter — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Rkhunter — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Rkhunter — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "rkhunter v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: rkhunter help"; exit 1 ;;
esac

---
name: "iptables"
version: "1.0.0"
description: "Iptables reference tool. Use when working with iptables in sysops contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [iptables, sysops, dev, reference, cli]
category: "sysops"
---

# Iptables

Iptables reference tool. Use when working with iptables in sysops contexts.

## When to Use

- Working with iptables and need quick reference
- Looking up sysops standards or best practices for iptables
- Troubleshooting iptables issues
- Need a checklist or guide for iptables tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# iptables — Iptables reference tool. Use when working with iptables in sysops contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
iptables v$VERSION — Iptables Reference Tool

Usage: iptables <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Iptables — Overview

## What is Iptables?
Iptables (iptables) is a specialized tool/concept in the sysops domain.
It provides essential capabilities for professionals working with iptables.

## Key Concepts
- Core iptables principles and fundamentals
- How iptables fits into the broader sysops ecosystem  
- Essential terminology every practitioner should know

## Why Iptables Matters
Understanding iptables is critical for:
- Improving efficiency in sysops workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic iptables concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Iptables — Quick Start Guide

## Prerequisites
- Basic understanding of sysops concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the iptables package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Iptables — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for iptables
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Iptables — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Iptables — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Iptables — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Iptables — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Iptables — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "iptables v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: iptables help"; exit 1 ;;
esac

---
name: "namespace"
version: "1.0.0"
description: "Namespace reference tool. Use when working with namespace in sysops contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [namespace, sysops, dev, reference, cli]
category: "sysops"
---

# Namespace

Namespace reference tool. Use when working with namespace in sysops contexts.

## When to Use

- Working with namespace and need quick reference
- Looking up sysops standards or best practices for namespace
- Troubleshooting namespace issues
- Need a checklist or guide for namespace tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# namespace — Namespace reference tool. Use when working with namespace in sysops contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
namespace v$VERSION — Namespace Reference Tool

Usage: namespace <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Namespace — Overview

## What is Namespace?
Namespace (namespace) is a specialized tool/concept in the sysops domain.
It provides essential capabilities for professionals working with namespace.

## Key Concepts
- Core namespace principles and fundamentals
- How namespace fits into the broader sysops ecosystem  
- Essential terminology every practitioner should know

## Why Namespace Matters
Understanding namespace is critical for:
- Improving efficiency in sysops workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic namespace concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Namespace — Quick Start Guide

## Prerequisites
- Basic understanding of sysops concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the namespace package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Namespace — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for namespace
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Namespace — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Namespace — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Namespace — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Namespace — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Namespace — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "namespace v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: namespace help"; exit 1 ;;
esac

---
name: "gdb"
version: "1.0.0"
description: "Gdb reference tool. Use when working with gdb in devtools contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [gdb, devtools, dev, reference, cli]
category: "devtools"
---

# Gdb

Gdb reference tool. Use when working with gdb in devtools contexts.

## When to Use

- Working with gdb and need quick reference
- Looking up devtools standards or best practices for gdb
- Troubleshooting gdb issues
- Need a checklist or guide for gdb tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# gdb — Gdb reference tool. Use when working with gdb in devtools contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
gdb v$VERSION — Gdb Reference Tool

Usage: gdb <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Gdb — Overview

## What is Gdb?
Gdb (gdb) is a specialized tool/concept in the devtools domain.
It provides essential capabilities for professionals working with gdb.

## Key Concepts
- Core gdb principles and fundamentals
- How gdb fits into the broader devtools ecosystem  
- Essential terminology every practitioner should know

## Why Gdb Matters
Understanding gdb is critical for:
- Improving efficiency in devtools workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic gdb concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Gdb — Quick Start Guide

## Prerequisites
- Basic understanding of devtools concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the gdb package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Gdb — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for gdb
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Gdb — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Gdb — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Gdb — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Gdb — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Gdb — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "gdb v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: gdb help"; exit 1 ;;
esac

---
name: "nmap"
version: "1.0.0"
description: "Nmap reference tool. Use when working with nmap in devtools contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [nmap, devtools, dev, reference, cli]
category: "devtools"
---

# Nmap

Nmap reference tool. Use when working with nmap in devtools contexts.

## When to Use

- Working with nmap and need quick reference
- Looking up devtools standards or best practices for nmap
- Troubleshooting nmap issues
- Need a checklist or guide for nmap tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# nmap — Nmap reference tool. Use when working with nmap in devtools contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
nmap v$VERSION — Nmap Reference Tool

Usage: nmap <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Nmap — Overview

## What is Nmap?
Nmap (nmap) is a specialized tool/concept in the devtools domain.
It provides essential capabilities for professionals working with nmap.

## Key Concepts
- Core nmap principles and fundamentals
- How nmap fits into the broader devtools ecosystem  
- Essential terminology every practitioner should know

## Why Nmap Matters
Understanding nmap is critical for:
- Improving efficiency in devtools workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic nmap concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Nmap — Quick Start Guide

## Prerequisites
- Basic understanding of devtools concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the nmap package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Nmap — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for nmap
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Nmap — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Nmap — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Nmap — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Nmap — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Nmap — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "nmap v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: nmap help"; exit 1 ;;
esac

---
name: "monte-carlo"
version: "1.0.0"
description: "Monte Carlo reference tool. Use when working with monte carlo in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [monte-carlo, finance, finance, reference, cli]
category: "finance"
---

# Monte Carlo

Monte Carlo reference tool. Use when working with monte carlo in finance contexts.

## When to Use

- Working with monte carlo and need quick reference
- Looking up finance standards or best practices for monte carlo
- Troubleshooting monte carlo issues
- Need a checklist or guide for monte carlo tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# monte-carlo — Monte Carlo reference tool. Use when working with monte carlo in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
monte-carlo v$VERSION — Monte Carlo Reference Tool

Usage: monte-carlo <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Monte Carlo — Overview

## What is Monte Carlo?
Monte Carlo (monte-carlo) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with monte carlo.

## Key Concepts
- Core monte carlo principles and fundamentals
- How monte carlo fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Monte Carlo Matters
Understanding monte carlo is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic monte carlo concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Monte Carlo — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Monte Carlo — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Monte Carlo — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Monte Carlo — Instruments & Tools Overview

## Primary Instruments
- Core tools used in monte carlo operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Monte Carlo — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Monte Carlo — Key Terms & Definitions

## Core Terminology
- **Monte Carlo**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Monte Carlo — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "monte-carlo v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: monte-carlo help"; exit 1 ;;
esac

---
name: "theta"
version: "1.0.0"
description: "Theta reference tool. Use when working with theta in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [theta, finance, finance, reference, cli]
category: "finance"
---

# Theta

Theta reference tool. Use when working with theta in finance contexts.

## When to Use

- Working with theta and need quick reference
- Looking up finance standards or best practices for theta
- Troubleshooting theta issues
- Need a checklist or guide for theta tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# theta — Theta reference tool. Use when working with theta in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
theta v$VERSION — Theta Reference Tool

Usage: theta <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Theta — Overview

## What is Theta?
Theta (theta) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with theta.

## Key Concepts
- Core theta principles and fundamentals
- How theta fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Theta Matters
Understanding theta is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic theta concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Theta — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Theta — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Theta — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Theta — Instruments & Tools Overview

## Primary Instruments
- Core tools used in theta operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Theta — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Theta — Key Terms & Definitions

## Core Terminology
- **Theta**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Theta — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "theta v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: theta help"; exit 1 ;;
esac

---
name: "sortino"
version: "1.0.0"
description: "Sortino reference tool. Use when working with sortino in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [sortino, finance, finance, reference, cli]
category: "finance"
---

# Sortino

Sortino reference tool. Use when working with sortino in finance contexts.

## When to Use

- Working with sortino and need quick reference
- Looking up finance standards or best practices for sortino
- Troubleshooting sortino issues
- Need a checklist or guide for sortino tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# sortino — Sortino reference tool. Use when working with sortino in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
sortino v$VERSION — Sortino Reference Tool

Usage: sortino <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Sortino — Overview

## What is Sortino?
Sortino (sortino) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with sortino.

## Key Concepts
- Core sortino principles and fundamentals
- How sortino fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Sortino Matters
Understanding sortino is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic sortino concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Sortino — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Sortino — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Sortino — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Sortino — Instruments & Tools Overview

## Primary Instruments
- Core tools used in sortino operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Sortino — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Sortino — Key Terms & Definitions

## Core Terminology
- **Sortino**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Sortino — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "sortino v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: sortino help"; exit 1 ;;
esac

---
name: "seedphrase"
version: "1.0.0"
description: "Seedphrase reference tool. Use when working with seedphrase in blockchain contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [seedphrase, blockchain, finance, reference, cli]
category: "blockchain"
---

# Seedphrase

Seedphrase reference tool. Use when working with seedphrase in blockchain contexts.

## When to Use

- Working with seedphrase and need quick reference
- Looking up blockchain standards or best practices for seedphrase
- Troubleshooting seedphrase issues
- Need a checklist or guide for seedphrase tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# seedphrase — Seedphrase reference tool. Use when working with seedphrase in blockchain contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
seedphrase v$VERSION — Seedphrase Reference Tool

Usage: seedphrase <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Seedphrase — Overview

## What is Seedphrase?
Seedphrase (seedphrase) is a specialized tool/concept in the blockchain domain.
It provides essential capabilities for professionals working with seedphrase.

## Key Concepts
- Core seedphrase principles and fundamentals
- How seedphrase fits into the broader blockchain ecosystem  
- Essential terminology every practitioner should know

## Why Seedphrase Matters
Understanding seedphrase is critical for:
- Improving efficiency in blockchain workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic seedphrase concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Seedphrase — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Seedphrase — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Seedphrase — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Seedphrase — Instruments & Tools Overview

## Primary Instruments
- Core tools used in seedphrase operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Seedphrase — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Seedphrase — Key Terms & Definitions

## Core Terminology
- **Seedphrase**: The primary subject of this reference
- **blockchain**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Seedphrase — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "seedphrase v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: seedphrase help"; exit 1 ;;
esac

---
name: "utxo"
version: "1.0.0"
description: "Utxo reference tool. Use when working with utxo in blockchain contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [utxo, blockchain, finance, reference, cli]
category: "blockchain"
---

# Utxo

Utxo reference tool. Use when working with utxo in blockchain contexts.

## When to Use

- Working with utxo and need quick reference
- Looking up blockchain standards or best practices for utxo
- Troubleshooting utxo issues
- Need a checklist or guide for utxo tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# utxo — Utxo reference tool. Use when working with utxo in blockchain contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
utxo v$VERSION — Utxo Reference Tool

Usage: utxo <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Utxo — Overview

## What is Utxo?
Utxo (utxo) is a specialized tool/concept in the blockchain domain.
It provides essential capabilities for professionals working with utxo.

## Key Concepts
- Core utxo principles and fundamentals
- How utxo fits into the broader blockchain ecosystem  
- Essential terminology every practitioner should know

## Why Utxo Matters
Understanding utxo is critical for:
- Improving efficiency in blockchain workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic utxo concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Utxo — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Utxo — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Utxo — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Utxo — Instruments & Tools Overview

## Primary Instruments
- Core tools used in utxo operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Utxo — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Utxo — Key Terms & Definitions

## Core Terminology
- **Utxo**: The primary subject of this reference
- **blockchain**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Utxo — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "utxo v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: utxo help"; exit 1 ;;
esac

---
name: "Bitcoin Halving Countdown & Impact Analyzer"
description: "Use when checking next Bitcoin halving countdown, reviewing historical halving price impacts, analyzing mining economics, or studying BTC 4-year market cycles."
version: "2.0.0"
author: "BytesAgain"
homepage: https://bytesagain.com
source: https://github.com/bytesagain/ai-skills
tags: ["bitcoin", "halving", "crypto", "mining", "blockchain", "market-cycles", "btc"]
---

# Bitcoin Halving Countdown & Impact Analyzer

Track the next Bitcoin halving countdown, review historical price impacts, analyze mining economics shifts, and understand BTC's 4-year market cycle patterns.

## Commands

### countdown
Estimate time remaining until the next Bitcoin halving.
```bash
bash scripts/script.sh countdown
```

### history
Complete history of all Bitcoin halvings with dates, blocks, and prices.
```bash
bash scripts/script.sh history
```

### impact
Analyze price impact before and after each halving event.
```bash
bash scripts/script.sh impact
```

### mining
Mining reward economics and miner profitability after halvings.
```bash
bash scripts/script.sh mining
```

### cycles
Bitcoin's 4-year market cycle theory and phase analysis.
```bash
bash scripts/script.sh cycles
```

### help
Show all commands.
```bash
bash scripts/script.sh help
```

## Output
- Estimated halving date and block countdown
- Historical halving data with price performance
- Mining reward and hash rate analysis
- Cycle phase identification

## Feedback
https://bytesagain.com/feedback/
Powered by BytesAgain | bytesagain.com

FILE:scripts/script.sh
#!/usr/bin/env bash
# halving — Bitcoin Halving Countdown & Impact Analyzer
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="2.0.0"

cmd_countdown() {
    python3 -u <<'PYEOF'
from datetime import datetime, timezone

# Bitcoin halving occurs every 210,000 blocks
HALVING_INTERVAL = 210_000

# Known halving data
halvings = [
    {"number": 0, "block": 0,       "date": "2009-01-03", "reward": 50.0},
    {"number": 1, "block": 210000,   "date": "2012-11-28", "reward": 25.0},
    {"number": 2, "block": 420000,   "date": "2016-07-09", "reward": 12.5},
    {"number": 3, "block": 630000,   "date": "2020-05-11", "reward": 6.25},
    {"number": 4, "block": 840000,   "date": "2024-04-20", "reward": 3.125},
]

# Next halving
next_halving_num = 5
next_halving_block = 1_050_000
next_reward = 1.5625  # BTC per block

# Estimation: ~10 minutes per block average
# Halving 4 was at block 840,000 on April 20, 2024
halving4_date = datetime(2024, 4, 20, tzinfo=timezone.utc)
halving4_block = 840_000

now = datetime.now(timezone.utc)
seconds_since_h4 = (now - halving4_date).total_seconds()
avg_block_time = 600  # 10 minutes in seconds

# Estimated current block
est_blocks_since_h4 = int(seconds_since_h4 / avg_block_time)
est_current_block = halving4_block + est_blocks_since_h4
blocks_remaining = next_halving_block - est_current_block

if blocks_remaining < 0:
    blocks_remaining = 0

# Estimated time remaining
seconds_remaining = blocks_remaining * avg_block_time
days_remaining = seconds_remaining / 86400
hours_remaining = (seconds_remaining % 86400) / 3600

# Estimated halving date
from datetime import timedelta
est_halving_date = now + timedelta(seconds=seconds_remaining)

print("═" * 55)
print("  ₿ Bitcoin Halving Countdown")
print("═" * 55)
print()
print(f"  Next Halving:     #{next_halving_num}")
print(f"  Target Block:     {next_halving_block:,}")
print(f"  Est. Current:     ~{est_current_block:,}")
print(f"  Blocks Left:      ~{blocks_remaining:,}")
print()
print(f"  ┌──────────────────────────────────────┐")
print(f"  │  ⏰ ~{int(days_remaining)} days {int(hours_remaining)} hours remaining      │")
print(f"  │  📅 Est. date: {est_halving_date.strftime('%Y-%m-%d')}              │")
print(f"  └──────────────────────────────────────┘")
print()
print(f"  Current Reward:   3.125 BTC/block")
print(f"  After Halving:    {next_reward} BTC/block")
print(f"  Reward Cut:       50% reduction")
print()

# Progress bar
total_blocks = HALVING_INTERVAL
done_blocks = HALVING_INTERVAL - blocks_remaining
pct = (done_blocks / total_blocks) * 100 if total_blocks > 0 else 100
bar_len = 30
filled = int(bar_len * pct / 100)
bar = "▓" * filled + "░" * (bar_len - filled)
print(f"  Progress: [{bar}] {pct:.1f}%")
print(f"            Block {halving4_block:,} → {next_halving_block:,}")
print()
print(f"  ⚠️  Estimate based on ~10 min/block average.")
print(f"     Actual block time varies (8-12 min).")
print(f"     Check a block explorer for real-time data.")
print()
print("📖 More skills: bytesagain.com")
PYEOF
}

cmd_history() {
    cat <<'EOF'
═══════════════════════════════════════════════════════
  ₿ Bitcoin Halving History — Complete Record
═══════════════════════════════════════════════════════

【Genesis — Block 0 (January 3, 2009)】
  Block Reward:    50 BTC
  BTC Price:       $0 (no market yet)
  Daily Issuance:  ~7,200 BTC (144 blocks/day)
  Annual Supply:   ~2,628,000 BTC
  Notes:           Satoshi Nakamoto mines the genesis block.
                   "Chancellor on brink of second bailout for banks"

【Halving #1 — Block 210,000 (November 28, 2012)】
  Block Reward:    50 → 25 BTC
  BTC Price:       ~$12.35
  Market Cap:      ~$134M
  Daily Issuance:  7,200 → 3,600 BTC
  Annual Inflation: 25% → 12.5%
  Pre-halving low: ~$2.01 (Nov 2011, 12 months prior)
  Peak after:      ~$1,163 (Nov 2013, 12 months later)
  ROI halving→peak: ~9,300%

【Halving #2 — Block 420,000 (July 9, 2016)】
  Block Reward:    25 → 12.5 BTC
  BTC Price:       ~$650
  Market Cap:      ~$10.1B
  Daily Issuance:  3,600 → 1,800 BTC
  Annual Inflation: 8.3% → 4.17%
  Pre-halving low: ~$200 (Jan 2015, 18 months prior)
  Peak after:      ~$19,783 (Dec 2017, 17 months later)
  ROI halving→peak: ~2,943%

【Halving #3 — Block 630,000 (May 11, 2020)】
  Block Reward:    12.5 → 6.25 BTC
  BTC Price:       ~$8,572
  Market Cap:      ~$158B
  Daily Issuance:  1,800 → 900 BTC
  Annual Inflation: 3.57% → 1.79%
  Pre-halving low: ~$3,850 (Mar 2020, COVID crash)
  Peak after:      ~$69,000 (Nov 2021, 18 months later)
  ROI halving→peak: ~705%

【Halving #4 — Block 840,000 (April 20, 2024)】
  Block Reward:    6.25 → 3.125 BTC
  BTC Price:       ~$63,800
  Market Cap:      ~$1.25T
  Daily Issuance:  900 → 450 BTC
  Annual Inflation: 1.79% → 0.85%
  Context:         First halving with spot Bitcoin ETFs approved
  Notable:         BTC hit ATH before halving (unusual)

【Halving #5 — Block 1,050,000 (Est. ~2028)】
  Block Reward:    3.125 → 1.5625 BTC
  Daily Issuance:  450 → 225 BTC
  Annual Inflation: 0.85% → ~0.40%
  Annual New BTC:  ~82,125 BTC
  Note:            Inflation rate below gold (~1.5%)

【Supply Milestones】
  Total supply cap:     21,000,000 BTC
  Currently mined:      ~19,600,000+ BTC (~93.3%)
  Remaining to mine:    ~1,400,000 BTC
  Last BTC mined:       ~Year 2140
  Total halvings:       32 (until reward < 1 satoshi)

📖 More skills: bytesagain.com
EOF
}

cmd_impact() {
    cat <<'EOF'
═══════════════════════════════════════════════════════
  ₿ Bitcoin Halving — Price Impact Analysis
═══════════════════════════════════════════════════════

【Price Performance Summary】

  Halving   Price@Halving   Cycle Peak    ROI      Time to Peak
  ──────────────────────────────────────────────────────────────
  #1 2012   $12.35          $1,163        9,300%   ~12 months
  #2 2016   $650            $19,783       2,943%   ~17 months
  #3 2020   $8,572          $69,000       705%     ~18 months
  #4 2024   $63,800         TBD           TBD      TBD

  Pattern: Diminishing returns each cycle (still massive)

【Pre-Halving Price Behavior】

  12-18 months before halving:
  → Market typically bottoms (cycle low)
  → Smart money accumulation begins

  6-12 months before halving:
  → Gradual price recovery
  → Media coverage increases
  → "Halving narrative" builds anticipation

  3-6 months before halving:
  → Acceleration phase
  → FOMO begins
  → Some pre-halving rally

  0-3 months before halving:
  → Often a "sell the news" dip around the event itself
  → Short-term traders take profits
  → Not always — 2024 broke this pattern

【Post-Halving Price Behavior】

  0-3 months after halving:
  → Usually consolidation / mild disappointment
  → "Nothing happened" narrative
  → Smart money continues accumulating

  3-6 months after halving:
  → Supply squeeze begins to bite
  → Miners sell less (less to sell)
  → Price starts trending up

  6-12 months after halving:
  → Acceleration phase
  → New ATH typically achieved
  → Mainstream media attention

  12-18 months after halving:
  → Parabolic blow-off top
  → Extreme euphoria
  → Cycle peak usually in this window

  18-24 months after halving:
  → Bear market begins
  → 70-80% drawdown from peak (historically)

【Supply Shock Mechanics】
  Why does price go up after halving?

  Before halving:
    Miners produce X BTC/day → sell most to cover costs
    Market absorbs X BTC/day of sell pressure

  After halving:
    Miners produce X/2 BTC/day
    Same (or growing) demand
    Less new supply hitting market
    → Supply/demand imbalance → price rises

  It's not magic — it's basic economics:
    Demand constant + Supply cut 50% = Price increase

【Diminishing Returns Theory】
  Each halving has smaller supply impact:
  #1: 50→25 BTC (3,600 fewer BTC/day)
  #2: 25→12.5 (1,800 fewer BTC/day)
  #3: 12.5→6.25 (900 fewer BTC/day)
  #4: 6.25→3.125 (450 fewer BTC/day)

  The absolute supply reduction shrinks each cycle.
  New supply becomes less significant vs. total float.
  Other factors (ETFs, regulation, macro) increasingly matter.

【Is "This Time Different"?】
  Arguments FOR continued pattern:
  ✅ Supply mechanics are mathematically guaranteed
  ✅ Growing institutional demand (ETFs)
  ✅ Global adoption still early (<5% world population)
  ✅ Macro environment (money printing, inflation)

  Arguments AGAINST:
  ❌ Market is more efficient (priced in?)
  ❌ Diminishing supply impact each cycle
  ❌ Regulatory uncertainty
  ❌ Past performance ≠ future results

📖 More skills: bytesagain.com
EOF
}

cmd_mining() {
    cat <<'EOF'
═══════════════════════════════════════════════════════
  ₿ Bitcoin Mining Economics & Halving Impact
═══════════════════════════════════════════════════════

【Block Reward History】
  Era    Blocks           Reward     Daily BTC    Annual BTC
  ──────────────────────────────────────────────────────────
  1      0-209,999        50.0       7,200        2,628,000
  2      210k-419,999     25.0       3,600        1,314,000
  3      420k-629,999     12.5       1,800        657,000
  4      630k-839,999     6.25       900          328,500
  5      840k-1,049,999   3.125      450          164,250
  6      1,050k-1,259,999 1.5625     225          82,125

【Miner Revenue Components】
  Total Miner Revenue = Block Reward + Transaction Fees

  Block Reward:
  → Fixed BTC amount per block (halves every 210k blocks)
  → Currently: 3.125 BTC/block
  → Predictable and decreasing over time

  Transaction Fees:
  → Variable, depends on network demand
  → Typically 2-10% of block reward in normal times
  → Can spike to 50%+ during congestion (Ordinals, BRC-20)
  → Becoming more important as block reward shrinks

【Revenue Impact of Each Halving】
  At constant BTC price, halving cuts miner revenue ~50%.

  Example at $65,000/BTC:
  Before halving #4: 6.25 BTC × $65,000 = $406,250/block
  After halving #4:  3.125 BTC × $65,000 = $203,125/block

  Daily revenue (144 blocks):
  Before: $58.5M/day
  After:  $29.3M/day  (-50%)

  For miners to maintain the same $ revenue post-halving,
  BTC price must approximately double.

【Miner Break-Even Analysis】
  Miner costs (simplified):
  → Electricity: 60-80% of total costs
  → Hardware depreciation: 15-25%
  → Facility, cooling, staff: 5-15%

  Break-even price = Total Costs / BTC Mined

  If a miner's cost to produce 1 BTC = $40,000:
    Before halving: profitable at any price > $40,000
    After halving: cost doubles to ~$80,000 per BTC
    If BTC < $80,000: that miner is unprofitable

  Result: Inefficient miners get squeezed out after each halving.
  → Hash rate temporarily drops
  → Difficulty adjusts downward
  → Surviving miners become more profitable
  → Network finds new equilibrium

【Hash Rate & Difficulty Post-Halving】
  Typical pattern after halving:

  Week 1-4:   Hash rate may dip 5-15%
              (unprofitable miners shut down)
  Month 1-3:  Difficulty adjusts down to compensate
              Surviving miners see improved margins
  Month 3-6:  If price rises, new miners come online
              Hash rate recovers and exceeds pre-halving
  Month 6-12: Hash rate reaches new all-time highs
              (higher price justifies new hardware investment)

【Mining Hardware Generations】
  Halving #1 (2012): CPU/GPU mining era ending, FPGAs emerging
  Halving #2 (2016): ASIC-dominated (Antminer S9 era)
  Halving #3 (2020): Efficient ASICs (S19 series, ~30 J/TH)
  Halving #4 (2024): Ultra-efficient (S21, ~17 J/TH)
  Halving #5 (2028): Next-gen (<10 J/TH expected?)

  Each halving forces efficiency improvements.
  Miners that don't upgrade get eliminated.

【Fee Revenue Becoming Critical】
  As block reward → 0, transaction fees must sustain mining.

  Current fee % of total reward:
  2012-2016: ~0.5-2%
  2016-2020: ~2-5%
  2020-2024: ~3-15% (higher with Ordinals)
  2024-2028: Expected ~10-25%
  Long-term:  Must reach ~100% by 2140

  This is Bitcoin's security budget question:
  Will fees alone be enough to incentivize mining
  and secure the network after all BTC is mined?

【Miner Behavior Around Halving】
  Pre-halving (3-6 months before):
  → Miners stockpile BTC (reduce selling)
  → Upgrade hardware aggressively
  → Lock in electricity contracts

  Post-halving (0-6 months after):
  → Weak miners capitulate (forced to sell reserves)
  → Short-term sell pressure from struggling miners
  → Consolidation in mining industry
  → Mergers and acquisitions

📖 More skills: bytesagain.com
EOF
}

cmd_cycles() {
    cat <<'EOF'
═══════════════════════════════════════════════════════
  ₿ Bitcoin 4-Year Market Cycle Analysis
═══════════════════════════════════════════════════════

【The 4-Year Cycle Theory】
  Bitcoin follows a roughly 4-year cycle driven by:
  1. Halving event (supply shock catalyst)
  2. Market psychology (greed → fear → greed)
  3. Liquidity cycles (global macro)
  4. Adoption waves (technology S-curve)

  Each cycle has 4 distinct phases:

【Phase 1: Accumulation (Bear Market Bottom)】
  Duration: ~12-14 months
  Typical timing: 12-24 months after previous cycle peak

  Characteristics:
  → Price 70-85% below previous ATH
  → Extreme fear and apathy
  → Media declares "Bitcoin is dead" (again)
  → Smart money quietly accumulates
  → Low volume, low volatility
  → Many retail investors have capitulated

  Historical examples:
    2011: $2 bottom (from $32 peak) → -94%
    2015: $200 bottom (from $1,163 peak) → -83%
    2018: $3,200 bottom (from $19,783 peak) → -84%
    2022: $15,500 bottom (from $69,000 peak) → -77%

  Strategy: DCA aggressively. Maximum opportunity zone.

【Phase 2: Mark-Up (Recovery & Pre-Halving)】
  Duration: ~12-18 months
  Typical timing: 6-18 months before halving

  Characteristics:
  → Steady price recovery from bottom
  → Halving narrative builds excitement
  → Gradually increasing volume
  → Still below previous ATH
  → Early adopters and institutions enter
  → Mining difficulty starts recovering

  Strategy: Continue accumulating. Build position before halving.

【Phase 3: Parabolic (Bull Run)】
  Duration: ~12-18 months
  Typical timing: 6-18 months after halving

  Characteristics:
  → New all-time highs
  → Exponential price growth
  → Mainstream media frenzy
  → "Everyone" talking about Bitcoin
  → Extreme greed on Fear & Greed Index
  → Altcoin season typically follows BTC peak
  → Blow-off top with massive volume

  Historical peaks:
    Cycle 1: $1,163 (Nov 2013)  — 12 months post-halving
    Cycle 2: $19,783 (Dec 2017) — 17 months post-halving
    Cycle 3: $69,000 (Nov 2021) — 18 months post-halving
    Cycle 4: TBD

  Strategy: Take profits gradually. Don't try to time exact top.

【Phase 4: Distribution & Crash (Bear Market)】
  Duration: ~12-14 months
  Typical timing: peak to bottom

  Characteristics:
  → Sharp initial crash (30-50% in weeks)
  → Dead cat bounces that trap buyers
  → Grinding lower prices over months
  → Leverage liquidation cascades
  → Projects and exchanges fail
  → Capitulation event near bottom

  Strategy: Preserve capital. Start DCA plan near bottom signals.

【Cycle Length Comparison】
  Cycle   Bottom      Halving     Peak        Bottom
  ────────────────────────────────────────────────────
  1       2011-11     2012-11     2013-11     2015-01
  2       2015-01     2016-07     2017-12     2018-12
  3       2018-12     2020-05     2021-11     2022-11
  4       2022-11     2024-04     TBD         TBD

  Average cycle: ~47-48 months (bottom to bottom)

【Lengthening Cycles Theory】
  Some analysts observe:
  → Each cycle peak takes slightly longer to reach
  → Each cycle correction is slightly less severe
  → Returns diminish but remain substantial

  If pattern holds for Cycle 4:
  → Peak: Late 2025 to Mid 2026 (19-20 months post-halving)
  → Correction: -60 to -75% (less severe)

  Counter-argument: Cycles may compress or break entirely
  as Bitcoin matures and becomes more institutional.

【Cycle Indicators to Watch】
  At the BOTTOM (buy signals):
  ✅ MVRV Z-Score < 0 (historically never fails)
  ✅ Puell Multiple < 0.5
  ✅ 200-week MA holding as support
  ✅ Long-term holder supply at ATH
  ✅ Mayer Multiple < 0.8

  At the TOP (sell signals):
  🔴 MVRV Z-Score > 7
  🔴 Puell Multiple > 4
  🔴 Pi Cycle Top indicator cross
  🔴 Exchange inflow spike (dumping)
  🔴 Google Trends "Bitcoin" at 100

【Stock-to-Flow Model (S2F)】
  S2F = Existing Supply / Annual New Supply

  Pre-halving 4:  S2F ≈ 57 (comparable to gold at ~62)
  Post-halving 4: S2F ≈ 120 (2x gold scarcity)
  Post-halving 5: S2F ≈ 240 (approaching infinity)

  Controversial model by PlanB:
  → Accurately predicted cycles 1-3 price range
  → Increasingly debated for future accuracy
  → Critics: sample size too small, correlation ≠ causation

【The Big Question: Will Cycles Continue?】
  Arguments for continued cycles:
  ✅ Halving is hard-coded, supply shocks are guaranteed
  ✅ Human psychology doesn't change (greed/fear)
  ✅ 4-year cycle aligns with broader liquidity cycles

  Arguments against:
  ❌ Institutional participation dampens volatility
  ❌ Market efficiency increases with size
  ❌ Eventually, halving supply impact becomes negligible
  ❌ Regulation could alter market dynamics

📖 More skills: bytesagain.com
EOF
}

cmd_help() {
    cat <<EOF
Halving vVERSION — Bitcoin Halving Countdown & Impact Analyzer

Commands:
  countdown    Estimate time until next Bitcoin halving
  history      Complete halving history (dates, blocks, prices)
  impact       Price impact analysis before and after halvings
  mining       Mining economics and profitability changes
  cycles       Bitcoin 4-year market cycle theory
  help         Show this help
  version      Show version

Usage:
  bash scripts/script.sh countdown
  bash scripts/script.sh history
  bash scripts/script.sh impact

Related skills:
  clawhub install rsi        — RSI overbought/oversold analysis
  clawhub install macd       — MACD trend & momentum signals
  clawhub install atr        — ATR volatility & position sizing
Browse all: bytesagain.com

Powered by BytesAgain | bytesagain.com
EOF
}

case "-help" in
    countdown)   cmd_countdown ;;
    history)     cmd_history ;;
    impact)      cmd_impact ;;
    mining)      cmd_mining ;;
    cycles)      cmd_cycles ;;
    version)     echo "halving vVERSION" ;;
    help|*)      cmd_help ;;
esac

FILE:skills/halving/SKILL.md
---
name: "halving"
version: "1.0.0"
description: "Halving reference tool. Use when working with halving in blockchain contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [halving, blockchain, finance, reference, cli]
category: "blockchain"
---

# Halving

Halving reference tool. Use when working with halving in blockchain contexts.

## When to Use

- Working with halving and need quick reference
- Looking up blockchain standards or best practices for halving
- Troubleshooting halving issues
- Need a checklist or guide for halving tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:skills/halving/scripts/script.sh
#!/usr/bin/env bash
# halving — Halving reference tool. Use when working with halving in blockchain contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
halving v$VERSION — Halving Reference Tool

Usage: halving <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Halving — Overview

## What is Halving?
Halving (halving) is a specialized tool/concept in the blockchain domain.
It provides essential capabilities for professionals working with halving.

## Key Concepts
- Core halving principles and fundamentals
- How halving fits into the broader blockchain ecosystem  
- Essential terminology every practitioner should know

## Why Halving Matters
Understanding halving is critical for:
- Improving efficiency in blockchain workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic halving concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Halving — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Halving — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Halving — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Halving — Instruments & Tools Overview

## Primary Instruments
- Core tools used in halving operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Halving — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Halving — Key Terms & Definitions

## Core Terminology
- **Halving**: The primary subject of this reference
- **blockchain**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Halving — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "halving v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: halving help"; exit 1 ;;
esac

---
name: "move"
version: "1.0.0"
description: "Move reference tool. Use when working with move in blockchain contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [move, blockchain, finance, reference, cli]
category: "blockchain"
---

# Move

Move reference tool. Use when working with move in blockchain contexts.

## When to Use

- Working with move and need quick reference
- Looking up blockchain standards or best practices for move
- Troubleshooting move issues
- Need a checklist or guide for move tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# move — Move reference tool. Use when working with move in blockchain contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
move v$VERSION — Move Reference Tool

Usage: move <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Move — Overview

## What is Move?
Move (move) is a specialized tool/concept in the blockchain domain.
It provides essential capabilities for professionals working with move.

## Key Concepts
- Core move principles and fundamentals
- How move fits into the broader blockchain ecosystem  
- Essential terminology every practitioner should know

## Why Move Matters
Understanding move is critical for:
- Improving efficiency in blockchain workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic move concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Move — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Move — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Move — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Move — Instruments & Tools Overview

## Primary Instruments
- Core tools used in move operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Move — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Move — Key Terms & Definitions

## Core Terminology
- **Move**: The primary subject of this reference
- **blockchain**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Move — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "move v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: move help"; exit 1 ;;
esac

---
name: "stochastic"
version: "1.0.0"
description: "Stochastic reference tool. Use when working with stochastic in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [stochastic, finance, finance, reference, cli]
category: "finance"
---

# Stochastic

Stochastic reference tool. Use when working with stochastic in finance contexts.

## When to Use

- Working with stochastic and need quick reference
- Looking up finance standards or best practices for stochastic
- Troubleshooting stochastic issues
- Need a checklist or guide for stochastic tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# stochastic — Stochastic reference tool. Use when working with stochastic in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
stochastic v$VERSION — Stochastic Reference Tool

Usage: stochastic <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Stochastic — Overview

## What is Stochastic?
Stochastic (stochastic) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with stochastic.

## Key Concepts
- Core stochastic principles and fundamentals
- How stochastic fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Stochastic Matters
Understanding stochastic is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic stochastic concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Stochastic — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Stochastic — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Stochastic — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Stochastic — Instruments & Tools Overview

## Primary Instruments
- Core tools used in stochastic operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Stochastic — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Stochastic — Key Terms & Definitions

## Core Terminology
- **Stochastic**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Stochastic — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "stochastic v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: stochastic help"; exit 1 ;;
esac

---
name: "heikinashi"
version: "1.0.0"
description: "Heikinashi reference tool. Use when working with heikinashi in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [heikinashi, finance, finance, reference, cli]
category: "finance"
---

# Heikinashi

Heikinashi reference tool. Use when working with heikinashi in finance contexts.

## When to Use

- Working with heikinashi and need quick reference
- Looking up finance standards or best practices for heikinashi
- Troubleshooting heikinashi issues
- Need a checklist or guide for heikinashi tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# heikinashi — Heikinashi reference tool. Use when working with heikinashi in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
heikinashi v$VERSION — Heikinashi Reference Tool

Usage: heikinashi <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Heikinashi — Overview

## What is Heikinashi?
Heikinashi (heikinashi) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with heikinashi.

## Key Concepts
- Core heikinashi principles and fundamentals
- How heikinashi fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Heikinashi Matters
Understanding heikinashi is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic heikinashi concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Heikinashi — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Heikinashi — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Heikinashi — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Heikinashi — Instruments & Tools Overview

## Primary Instruments
- Core tools used in heikinashi operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Heikinashi — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Heikinashi — Key Terms & Definitions

## Core Terminology
- **Heikinashi**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Heikinashi — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "heikinashi v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: heikinashi help"; exit 1 ;;
esac

---
name: "bollinger"
version: "1.0.0"
description: "Bollinger reference tool. Use when working with bollinger in finance contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [bollinger, finance, finance, reference, cli]
category: "finance"
---

# Bollinger

Bollinger reference tool. Use when working with bollinger in finance contexts.

## When to Use

- Working with bollinger and need quick reference
- Looking up finance standards or best practices for bollinger
- Troubleshooting bollinger issues
- Need a checklist or guide for bollinger tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and fundamentals

### `formulas`

```bash
scripts/script.sh formulas
```

Key formulas and calculations

### `regulations`

```bash
scripts/script.sh regulations
```

Regulatory framework and compliance

### `risks`

```bash
scripts/script.sh risks
```

Risk factors and mitigation

### `instruments`

```bash
scripts/script.sh instruments
```

Instruments and tools overview

### `strategies`

```bash
scripts/script.sh strategies
```

Common strategies and approaches

### `glossary`

```bash
scripts/script.sh glossary
```

Key terms and definitions

### `checklist`

```bash
scripts/script.sh checklist
```

Due diligence checklist

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# bollinger — Bollinger reference tool. Use when working with bollinger in finance contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
bollinger v$VERSION — Bollinger Reference Tool

Usage: bollinger <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Bollinger — Overview

## What is Bollinger?
Bollinger (bollinger) is a specialized tool/concept in the finance domain.
It provides essential capabilities for professionals working with bollinger.

## Key Concepts
- Core bollinger principles and fundamentals
- How bollinger fits into the broader finance ecosystem  
- Essential terminology every practitioner should know

## Why Bollinger Matters
Understanding bollinger is critical for:
- Improving efficiency in finance workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic bollinger concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Bollinger — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Bollinger — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Bollinger — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Bollinger — Instruments & Tools Overview

## Primary Instruments
- Core tools used in bollinger operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Bollinger — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Bollinger — Key Terms & Definitions

## Core Terminology
- **Bollinger**: The primary subject of this reference
- **finance**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Bollinger — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "bollinger v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: bollinger help"; exit 1 ;;
esac

---
name: "webpack"
version: "1.0.0"
description: "Webpack reference tool. Use when working with webpack in frontend contexts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [webpack, frontend, dev, reference, cli]
category: "frontend"
---

# Webpack

Webpack reference tool. Use when working with webpack in frontend contexts.

## When to Use

- Working with webpack and need quick reference
- Looking up frontend standards or best practices for webpack
- Troubleshooting webpack issues
- Need a checklist or guide for webpack tasks

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview and core concepts

### `quickstart`

```bash
scripts/script.sh quickstart
```

Getting started guide

### `patterns`

```bash
scripts/script.sh patterns
```

Common patterns and best practices

### `debugging`

```bash
scripts/script.sh debugging
```

Debugging and troubleshooting

### `performance`

```bash
scripts/script.sh performance
```

Performance optimization tips

### `security`

```bash
scripts/script.sh security
```

Security considerations

### `migration`

```bash
scripts/script.sh migration
```

Migration and upgrade guide

### `cheatsheet`

```bash
scripts/script.sh cheatsheet
```

Quick reference cheat sheet

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# webpack — Webpack reference tool. Use when working with webpack in frontend contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

show_help() {
    cat << 'HELPEOF'
webpack v$VERSION — Webpack Reference Tool

Usage: webpack <command>

Commands:
  intro           Overview and core concepts
  quickstart      Getting started guide
  patterns        Common patterns and best practices
  debugging       Debugging and troubleshooting
  performance     Performance optimization tips
  security        Security considerations
  migration       Migration and upgrade guide
  cheatsheet      Quick reference cheat sheet
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Webpack — Overview

## What is Webpack?
Webpack (webpack) is a specialized tool/concept in the frontend domain.
It provides essential capabilities for professionals working with webpack.

## Key Concepts
- Core webpack principles and fundamentals
- How webpack fits into the broader frontend ecosystem  
- Essential terminology every practitioner should know

## Why Webpack Matters
Understanding webpack is critical for:
- Improving efficiency in frontend workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic webpack concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_quickstart() {
    cat << 'EOF'
# Webpack — Quick Start Guide

## Prerequisites
- Basic understanding of frontend concepts
- Required tools and access credentials
- System meeting minimum requirements

## Installation
1. Download or clone the webpack package
2. Install dependencies
3. Configure initial settings
4. Verify installation

## First Steps
1. Run the hello-world example
2. Review the default configuration
3. Try a simple real-world task
4. Explore available commands and options

## Next Steps
- Read the full documentation
- Join the community forum
- Try advanced features
- Set up automated workflows
EOF
}

cmd_patterns() {
    cat << 'EOF'
# Webpack — Common Patterns & Best Practices

## Design Patterns
1. **Standard Pattern**: The most common approach for webpack
2. **Scalable Pattern**: For high-volume or distributed scenarios
3. **Resilient Pattern**: For fault-tolerant implementations

## Best Practices
- Follow the principle of least privilege
- Use version control for all configurations
- Implement comprehensive logging
- Test changes in staging before production
- Document all custom configurations

## Anti-Patterns to Avoid
- Hardcoding credentials or configuration
- Skipping validation and error handling
- Ignoring monitoring and alerting
- Making changes without documentation
- Over-engineering simple solutions
EOF
}

cmd_debugging() {
    cat << 'EOF'
# Webpack — Debugging Guide

## Common Errors
1. **Connection refused**: Check service status and network
2. **Permission denied**: Verify credentials and access rights
3. **Timeout**: Check network, increase limits, optimize queries
4. **Invalid input**: Validate data format and encoding

## Debugging Tools
- Built-in logging and diagnostics
- Network analysis tools (tcpdump, wireshark)
- System monitoring (top, htop, iostat)
- Application-specific debug modes

## Debug Workflow
1. Reproduce the issue consistently
2. Check logs for error messages
3. Isolate the failing component
4. Test with minimal configuration
5. Apply fix and verify
EOF
}

cmd_performance() {
    cat << 'EOF'
# Webpack — Performance Optimization

## Key Metrics
- Response time / latency
- Throughput / operations per second
- Resource utilization (CPU, memory, I/O)
- Error rate and retry frequency

## Optimization Strategies
1. **Caching**: Reduce redundant operations
2. **Batching**: Group small operations
3. **Indexing**: Speed up data lookups
4. **Compression**: Reduce data transfer size
5. **Parallel Processing**: Utilize multiple cores

## Monitoring
- Set up baseline performance metrics
- Configure alerts for anomalies
- Track trends over time
- Regular capacity planning reviews
EOF
}

cmd_security() {
    cat << 'EOF'
# Webpack — Security Considerations

## Authentication & Authorization
- Use strong, unique credentials
- Implement role-based access control
- Enable multi-factor authentication where possible
- Regularly review and rotate credentials

## Data Protection
- Encrypt data at rest and in transit
- Implement proper backup procedures
- Follow data retention policies
- Sanitize inputs to prevent injection

## Network Security
- Use firewalls and network segmentation
- Monitor for suspicious activity
- Keep all software patched and updated
- Disable unnecessary services and ports
EOF
}

cmd_migration() {
    cat << 'EOF'
# Webpack — Migration & Upgrade Guide

## Pre-Migration Checklist
- [ ] Current system fully documented
- [ ] Complete backup taken and verified
- [ ] Target environment prepared
- [ ] Rollback plan documented
- [ ] Stakeholders notified

## Migration Steps
1. Prepare target environment
2. Export data from source
3. Transform data if needed
4. Import to target
5. Verify data integrity
6. Update configurations
7. Test all functionality
8. Switch traffic / go live

## Post-Migration
- Monitor for errors and performance
- Verify all integrations working
- Update documentation
- Decommission old system after confirmation
EOF
}

cmd_cheatsheet() {
    cat << 'EOF'
# Webpack — Quick Reference

## Essential Commands
| Command | Description |
|---------|-------------|
| help | Show available commands |
| version | Display version info |
| intro | Overview and fundamentals |
| troubleshooting | Common problems and fixes |

## Common Workflows
1. **Setup**: install → configure → verify → test
2. **Daily**: check → monitor → report → review
3. **Issue**: diagnose → isolate → fix → verify → document

## Key Shortcuts
- Use tab completion for commands
- Check logs first when troubleshooting
- Always backup before making changes
- Document everything you change
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    quickstart) cmd_quickstart "$@" ;;
    patterns) cmd_patterns "$@" ;;
    debugging) cmd_debugging "$@" ;;
    performance) cmd_performance "$@" ;;
    security) cmd_security "$@" ;;
    migration) cmd_migration "$@" ;;
    cheatsheet) cmd_cheatsheet "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "webpack v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: webpack help"; exit 1 ;;
esac

---
name: "gasless"
version: "1.0.0"
description: "Analyze gasless operations. Use when you need to understand gasless mechanisms, evaluate protocol security, or reference on-chain concepts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [gasless, blockchain, cli, tool]
category: "blockchain"
---

# Gasless

Analyze gasless operations. Use when you need to understand gasless mechanisms, evaluate protocol security, or reference on-chain concepts.

## When to Use

- **status**: Show current status
- **add**: Add new entry
- **list**: List all entries
- **search**: Search entries
- **remove**: Remove entry by number
- **export**: Export data to file
- **stats**: Show statistics
- **config**: View or set config

## Commands

### `status`

```bash
scripts/script.sh status
```

Show current status

### `add`

```bash
scripts/script.sh add
```

Add new entry

### `list`

```bash
scripts/script.sh list
```

List all entries

### `search`

```bash
scripts/script.sh search
```

Search entries

### `remove`

```bash
scripts/script.sh remove
```

Remove entry by number

### `export`

```bash
scripts/script.sh export
```

Export data to file

### `stats`

```bash
scripts/script.sh stats
```

Show statistics

### `config`

```bash
scripts/script.sh config
```

View or set config

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

## Configuration

Use `scripts/script.sh config <key> <value>` to customize behavior.

| Variable | Description |
|----------|-------------|
| `GASLESS_DIR` | Data directory (default: ~/.gasless/) |

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# gasless -- Analyze gasless operations. Use when you need to understand gasless mechanisms, evaluate protocol security, or reference on-chain concepts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"
DATA_DIR="-$HOME/.gasless"

_ensure_dirs() { mkdir -p "$DATA_DIR"; }

_save_entry() {
    _ensure_dirs
    local cmd="$1" val="$2"
    local ts=$(date '+%Y-%m-%d %H:%M:%S')
    printf '{"ts":"%s","cmd":"%s","val":"%s"}\n' "$ts" "$cmd" "$val" >> "$DATA_DIR/data.jsonl"
}

show_help() {
    cat << EOF
gasless v$VERSION -- Analyze gasless operations. Use when you need to understand gasless mechanisms, evaluate protocol security, or reference on-chain concepts.

Usage: gasless <command> [args]

Commands:
  status          Show current status
  add             Add new entry
  list            List all entries
  search          Search entries
  remove          Remove entry by number
  export          Export data to file
  stats           Show statistics
  config          View or set config
  help              Show this help
  version           Show version

Data: $DATA_DIR
Powered by BytesAgain | bytesagain.com
EOF
}

cmd_status() {
    echo "=== gasless Status ==="
    echo "  Version: $VERSION"
    echo "  Data dir: $DATA_DIR"
    local entries=$(cat "$DATA_DIR"/*.jsonl 2>/dev/null | wc -l || echo 0)
    echo "  Entries: $entries"
    echo "  Disk: $(du -sh "$DATA_DIR" 2>/dev/null | cut -f1 || echo empty)"
}

cmd_add() {
    local value="?Usage: gasless add <entry>"
    shift || true
    _save_entry "add" "$value $*"
    local count=$(wc -l < "$DATA_DIR/data.jsonl" 2>/dev/null || echo 0)
    echo "Added: $value (entry #$count)"
}

cmd_list() {
    echo "=== Gasless Entries ==="
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local count=$(wc -l < "$DATA_DIR/data.jsonl")
        echo "Total: $count"
        echo "---"
        tail -20 "$DATA_DIR/data.jsonl" | while IFS= read -r line; do
            local ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
            local cmd=$(echo "$line" | grep -o '"cmd":"[^"]*' | cut -d'"' -f4)
            local val=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
            echo "  [$ts] $cmd: $val"
        done
    else
        echo "No entries yet."
    fi
}

cmd_search() {
    local term="?Usage: gasless search <term>"
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local matches=$(grep -ic "$term" "$DATA_DIR/data.jsonl" 2>/dev/null || echo 0)
        echo "Found: $matches matches"
        grep -i "$term" "$DATA_DIR/data.jsonl" 2>/dev/null | head -20 | while IFS= read -r line; do
            local val=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
            local ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
            echo "  [$ts] $val"
        done
    else
        echo "No data to search."
    fi
}

cmd_remove() {
    local num="?Usage: gasless remove <line-number>"
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local total=$(wc -l < "$DATA_DIR/data.jsonl")
        if [ "$num" -ge 1 ] 2>/dev/null && [ "$num" -le "$total" ] 2>/dev/null; then
            sed -i "numd" "$DATA_DIR/data.jsonl"
            echo "Removed #$num ($((total-1)) remaining)"
        else echo "Invalid: $num (total: $total)"; fi
    else echo "No data."; fi
}

cmd_export() {
    local fmt="-json"
    local out="gasless-export.$fmt"
    if [ ! -f "$DATA_DIR/data.jsonl" ]; then echo "No data."; return 0; fi
    case "$fmt" in
        json) cp "$DATA_DIR/data.jsonl" "$out" ;;
        csv)
            echo "timestamp,command,value" > "$out"
            while IFS= read -r line; do
                ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
                c2=$(echo "$line" | grep -o '"cmd":"[^"]*' | cut -d'"' -f4)
                vl=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
                echo "$ts,$c2,$vl" >> "$out"
            done < "$DATA_DIR/data.jsonl"
            ;;
        *) echo "Formats: json, csv"; return 1 ;;
    esac
    echo "Exported: $out ($(wc -c < "$out") bytes)"
}

cmd_stats() {
    echo "=== Gasless Stats ==="
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local total=$(wc -l < "$DATA_DIR/data.jsonl")
        local bytes=$(wc -c < "$DATA_DIR/data.jsonl")
        echo "  Entries: $total"
        echo "  Size: $bytes bytes"
        echo "  Disk: $(du -sh "$DATA_DIR" 2>/dev/null | cut -f1)"
    else echo "  No data yet."; fi
}

cmd_config() {
    local key="-" val="-"
    local cfg="$DATA_DIR/config.txt"
    if [ -z "$key" ]; then
        echo "=== Config ==="
        if [ -f "$cfg" ]; then
            while IFS="=" read -r k v; do echo "  $k=$v"; done < "$cfg"
        else echo "  (empty — use config <key> <value>)"; fi
    elif [ -z "$val" ]; then
        grep "^key=" "$cfg" 2>/dev/null | cut -d= -f2- || echo "(not set)"
    else
        if [ -f "$cfg" ] && grep -q "^key=" "$cfg" 2>/dev/null; then
            sed -i "s|^key=.*|key=val|" "$cfg"
        else
            echo "key=val" >> "$cfg"
        fi
        echo "Set: $key=$val"
    fi
}

CMD="-help"
shift 2>/dev/null || true
_ensure_dirs

case "$CMD" in
    status) cmd_status "$@" ;;
    add) cmd_add "$@" ;;
    list) cmd_list "$@" ;;
    search) cmd_search "$@" ;;
    remove) cmd_remove "$@" ;;
    export) cmd_export "$@" ;;
    stats) cmd_stats "$@" ;;
    config) cmd_config "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "gasless v$VERSION -- Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: gasless help"; exit 1 ;;
esac

---
name: "liquidity"
version: "2.0.1"
description: "Reference tool for blockchain and crypto — covers intro, formulas, regulations and more. Quick lookup for Liquidity concepts, best practices, and implementat..."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [liquidity, reference]
category: "blockchain"
---

# Liquidity

Reference tool for blockchain and crypto — covers intro, formulas, regulations and more. Quick lookup for Liquidity concepts, best practices, and implementat... No API keys or credentials required.

## Commands

| Command | Description |
|---------|-------------|
| `intro` | intro reference |
| `formulas` | formulas reference |
| `regulations` | regulations reference |
| `risks` | risks reference |
| `instruments` | instruments reference |
| `strategies` | strategies reference |
| `glossary` | glossary reference |
| `checklist` | checklist reference |

## Output Format

All commands output plain-text reference documentation via heredoc. No external API calls, no credentials needed, no network access.

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# liquidity — Liquidity reference tool. Use when working with liquidity in blockchain contexts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="2.0.0"

show_help() {
    cat << 'HELPEOF'
liquidity v$VERSION — Liquidity Reference Tool

Usage: liquidity <command>

Commands:
  intro           Overview and fundamentals
  formulas        Key formulas and calculations
  regulations     Regulatory framework and compliance
  risks           Risk factors and mitigation
  instruments     Instruments and tools overview
  strategies      Common strategies and approaches
  glossary        Key terms and definitions
  checklist       Due diligence checklist
  help              Show this help
  version           Show version

Powered by BytesAgain | bytesagain.com
HELPEOF
}

cmd_intro() {
    cat << 'EOF'
# Liquidity — Overview

## What is Liquidity?
Liquidity (liquidity) is a specialized tool/concept in the blockchain domain.
It provides essential capabilities for professionals working with liquidity.

## Key Concepts
- Core liquidity principles and fundamentals
- How liquidity fits into the broader blockchain ecosystem  
- Essential terminology every practitioner should know

## Why Liquidity Matters
Understanding liquidity is critical for:
- Improving efficiency in blockchain workflows
- Reducing errors and downtime
- Meeting industry standards and compliance requirements
- Enabling better decision-making with accurate data

## Getting Started
1. Understand the basic liquidity concepts
2. Learn the standard tools and interfaces
3. Practice with common scenarios
4. Review safety and compliance requirements
EOF
}

cmd_formulas() {
    cat << 'EOF'
# Liquidity — Key Formulas & Calculations

## Core Formulas
- **Basic ratio**: Value = Input / Reference × 100
- **Growth rate**: (Current - Previous) / Previous × 100%
- **Weighted average**: Sum(Value × Weight) / Sum(Weight)

## Common Calculations
1. Risk-adjusted return
2. Break-even analysis
3. Compound growth
4. Present/future value
5. Standard deviation

## Quick Reference
| Metric | Formula | Use Case |
|--------|---------|----------|
| ROI | (Gain - Cost) / Cost | Investment evaluation |
| CAGR | (End/Start)^(1/n) - 1 | Growth measurement |
| Sharpe | (Return - RiskFree) / StdDev | Risk-adjusted performance |
EOF
}

cmd_regulations() {
    cat << 'EOF'
# Liquidity — Regulatory Framework

## Key Regulations
- Primary governing laws and statutes
- Industry-specific compliance requirements
- International standards and agreements

## Compliance Requirements
- Registration and licensing
- Reporting obligations
- Record-keeping requirements
- Audit and inspection readiness

## Enforcement
- Regulatory bodies and their jurisdiction
- Penalty structures for non-compliance
- Appeal and dispute resolution processes
EOF
}

cmd_risks() {
    cat << 'EOF'
# Liquidity — Risk Analysis

## Risk Categories
1. **Market Risk**: Price volatility and liquidity
2. **Operational Risk**: System failures and human error
3. **Regulatory Risk**: Changing laws and compliance
4. **Credit Risk**: Counterparty default

## Risk Mitigation
- Diversification strategies
- Hedging instruments
- Insurance and guarantees
- Contingency planning

## Risk Assessment Framework
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| High | Likely | Severe | Immediate action |
| Medium | Possible | Moderate | Monitor closely |
| Low | Unlikely | Minor | Accept or transfer |
EOF
}

cmd_instruments() {
    cat << 'EOF'
# Liquidity — Instruments & Tools Overview

## Primary Instruments
- Core tools used in liquidity operations
- Measurement and monitoring equipment
- Software platforms and applications

## Selection Guide
1. Define requirements and constraints
2. Evaluate available options
3. Consider total cost of ownership
4. Assess vendor support and community
5. Test before committing
EOF
}

cmd_strategies() {
    cat << 'EOF'
# Liquidity — Common Strategies

## Fundamental Strategies
1. **Conservative**: Low risk, steady returns
2. **Balanced**: Moderate risk, diversified approach
3. **Aggressive**: Higher risk, growth-focused

## Implementation Steps
1. Define objectives and constraints
2. Select appropriate strategy
3. Execute with discipline
4. Monitor and adjust
5. Review periodically
EOF
}

cmd_glossary() {
    cat << 'EOF'
# Liquidity — Key Terms & Definitions

## Core Terminology
- **Liquidity**: The primary subject of this reference
- **blockchain**: The broader domain category
- **Baseline**: A reference point for comparison
- **Benchmark**: A standard for measuring performance
- **Compliance**: Adherence to rules and standards
- **Configuration**: System settings and parameters
- **Diagnostics**: Tools and procedures for identifying issues
- **Integration**: Connecting multiple systems together
- **Protocol**: A set of rules governing communication
- **Specification**: Detailed requirements document
EOF
}

cmd_checklist() {
    cat << 'EOF'
# Liquidity — Inspection Checklist

## Pre-Operation Checklist
- [ ] Visual inspection completed
- [ ] All connections secure
- [ ] Safety systems functional
- [ ] Operating parameters within range
- [ ] Documentation current

## Daily Checks
- [ ] System startup normal
- [ ] No error indicators or alarms
- [ ] Performance within expected range
- [ ] Environmental conditions acceptable
- [ ] Log entries reviewed

## Periodic Inspection
- [ ] Comprehensive system test
- [ ] Calibration verification
- [ ] Wear component inspection
- [ ] Firmware/software version check
- [ ] Backup systems tested

## Shutdown Checklist
- [ ] Proper shutdown sequence followed
- [ ] All data saved and backed up
- [ ] System secured
- [ ] Maintenance items logged
- [ ] Next startup requirements noted
EOF
}

CMD="-help"
shift 2>/dev/null || true

case "$CMD" in
    intro) cmd_intro "$@" ;;
    formulas) cmd_formulas "$@" ;;
    regulations) cmd_regulations "$@" ;;
    risks) cmd_risks "$@" ;;
    instruments) cmd_instruments "$@" ;;
    strategies) cmd_strategies "$@" ;;
    glossary) cmd_glossary "$@" ;;
    checklist) cmd_checklist "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "liquidity v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: liquidity help"; exit 1 ;;
esac

---
name: "slashing"
version: "1.0.0"
description: "Analyze slashing operations. Use when you need to understand slashing mechanisms, evaluate protocol security, or reference on-chain concepts."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [slashing, blockchain, cli, tool]
category: "blockchain"
---

# Slashing

Analyze slashing operations. Use when you need to understand slashing mechanisms, evaluate protocol security, or reference on-chain concepts.

## When to Use

- **status**: Show current status
- **add**: Add new entry
- **list**: List all entries
- **search**: Search entries
- **remove**: Remove entry by number
- **export**: Export data to file
- **stats**: Show statistics
- **config**: View or set config

## Commands

### `status`

```bash
scripts/script.sh status
```

Show current status

### `add`

```bash
scripts/script.sh add
```

Add new entry

### `list`

```bash
scripts/script.sh list
```

List all entries

### `search`

```bash
scripts/script.sh search
```

Search entries

### `remove`

```bash
scripts/script.sh remove
```

Remove entry by number

### `export`

```bash
scripts/script.sh export
```

Export data to file

### `stats`

```bash
scripts/script.sh stats
```

Show statistics

### `config`

```bash
scripts/script.sh config
```

View or set config

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

## Configuration

Use `scripts/script.sh config <key> <value>` to customize behavior.

| Variable | Description |
|----------|-------------|
| `SLASHING_DIR` | Data directory (default: ~/.slashing/) |

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# slashing -- Analyze slashing operations. Use when you need to understand slashing mechanisms, evaluate protocol security, or reference on-chain concepts.
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"
DATA_DIR="-$HOME/.slashing"

_ensure_dirs() { mkdir -p "$DATA_DIR"; }

_save_entry() {
    _ensure_dirs
    local cmd="$1" val="$2"
    local ts=$(date '+%Y-%m-%d %H:%M:%S')
    printf '{"ts":"%s","cmd":"%s","val":"%s"}\n' "$ts" "$cmd" "$val" >> "$DATA_DIR/data.jsonl"
}

show_help() {
    cat << EOF
slashing v$VERSION -- Analyze slashing operations. Use when you need to understand slashing mechanisms, evaluate protocol security, or reference on-chain concepts.

Usage: slashing <command> [args]

Commands:
  status          Show current status
  add             Add new entry
  list            List all entries
  search          Search entries
  remove          Remove entry by number
  export          Export data to file
  stats           Show statistics
  config          View or set config
  help              Show this help
  version           Show version

Data: $DATA_DIR
Powered by BytesAgain | bytesagain.com
EOF
}

cmd_status() {
    echo "=== slashing Status ==="
    echo "  Version: $VERSION"
    echo "  Data dir: $DATA_DIR"
    local entries=$(cat "$DATA_DIR"/*.jsonl 2>/dev/null | wc -l || echo 0)
    echo "  Entries: $entries"
    echo "  Disk: $(du -sh "$DATA_DIR" 2>/dev/null | cut -f1 || echo empty)"
}

cmd_add() {
    local value="?Usage: slashing add <entry>"
    shift || true
    _save_entry "add" "$value $*"
    local count=$(wc -l < "$DATA_DIR/data.jsonl" 2>/dev/null || echo 0)
    echo "Added: $value (entry #$count)"
}

cmd_list() {
    echo "=== Slashing Entries ==="
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local count=$(wc -l < "$DATA_DIR/data.jsonl")
        echo "Total: $count"
        echo "---"
        tail -20 "$DATA_DIR/data.jsonl" | while IFS= read -r line; do
            local ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
            local cmd=$(echo "$line" | grep -o '"cmd":"[^"]*' | cut -d'"' -f4)
            local val=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
            echo "  [$ts] $cmd: $val"
        done
    else
        echo "No entries yet."
    fi
}

cmd_search() {
    local term="?Usage: slashing search <term>"
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local matches=$(grep -ic "$term" "$DATA_DIR/data.jsonl" 2>/dev/null || echo 0)
        echo "Found: $matches matches"
        grep -i "$term" "$DATA_DIR/data.jsonl" 2>/dev/null | head -20 | while IFS= read -r line; do
            local val=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
            local ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
            echo "  [$ts] $val"
        done
    else
        echo "No data to search."
    fi
}

cmd_remove() {
    local num="?Usage: slashing remove <line-number>"
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local total=$(wc -l < "$DATA_DIR/data.jsonl")
        if [ "$num" -ge 1 ] 2>/dev/null && [ "$num" -le "$total" ] 2>/dev/null; then
            sed -i "numd" "$DATA_DIR/data.jsonl"
            echo "Removed #$num ($((total-1)) remaining)"
        else echo "Invalid: $num (total: $total)"; fi
    else echo "No data."; fi
}

cmd_export() {
    local fmt="-json"
    local out="slashing-export.$fmt"
    if [ ! -f "$DATA_DIR/data.jsonl" ]; then echo "No data."; return 0; fi
    case "$fmt" in
        json) cp "$DATA_DIR/data.jsonl" "$out" ;;
        csv)
            echo "timestamp,command,value" > "$out"
            while IFS= read -r line; do
                ts=$(echo "$line" | grep -o '"ts":"[^"]*' | cut -d'"' -f4)
                c2=$(echo "$line" | grep -o '"cmd":"[^"]*' | cut -d'"' -f4)
                vl=$(echo "$line" | grep -o '"val":"[^"]*' | cut -d'"' -f4)
                echo "$ts,$c2,$vl" >> "$out"
            done < "$DATA_DIR/data.jsonl"
            ;;
        *) echo "Formats: json, csv"; return 1 ;;
    esac
    echo "Exported: $out ($(wc -c < "$out") bytes)"
}

cmd_stats() {
    echo "=== Slashing Stats ==="
    if [ -f "$DATA_DIR/data.jsonl" ]; then
        local total=$(wc -l < "$DATA_DIR/data.jsonl")
        local bytes=$(wc -c < "$DATA_DIR/data.jsonl")
        echo "  Entries: $total"
        echo "  Size: $bytes bytes"
        echo "  Disk: $(du -sh "$DATA_DIR" 2>/dev/null | cut -f1)"
    else echo "  No data yet."; fi
}

cmd_config() {
    local key="-" val="-"
    local cfg="$DATA_DIR/config.txt"
    if [ -z "$key" ]; then
        echo "=== Config ==="
        if [ -f "$cfg" ]; then
            while IFS="=" read -r k v; do echo "  $k=$v"; done < "$cfg"
        else echo "  (empty — use config <key> <value>)"; fi
    elif [ -z "$val" ]; then
        grep "^key=" "$cfg" 2>/dev/null | cut -d= -f2- || echo "(not set)"
    else
        if [ -f "$cfg" ] && grep -q "^key=" "$cfg" 2>/dev/null; then
            sed -i "s|^key=.*|key=val|" "$cfg"
        else
            echo "key=val" >> "$cfg"
        fi
        echo "Set: $key=$val"
    fi
}

CMD="-help"
shift 2>/dev/null || true
_ensure_dirs

case "$CMD" in
    status) cmd_status "$@" ;;
    add) cmd_add "$@" ;;
    list) cmd_list "$@" ;;
    search) cmd_search "$@" ;;
    remove) cmd_remove "$@" ;;
    export) cmd_export "$@" ;;
    stats) cmd_stats "$@" ;;
    config) cmd_config "$@" ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "slashing v$VERSION -- Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: slashing help"; exit 1 ;;
esac

---
name: "assert"
version: "1.0.0"
description: "Assertion patterns reference — guard clauses, preconditions, invariants, and contract programming. Use when writing defensive code, validating inputs, or implementing design-by-contract."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [assert, assertion, precondition, invariant, contract, defensive, testing]
category: "devtools"
---

# Assert — Assertion Patterns Reference

Quick-reference skill for assertion techniques, design-by-contract, and defensive programming patterns.

## When to Use

- Writing precondition checks for function inputs
- Implementing class invariants and postconditions
- Choosing between assertions and exceptions
- Applying design-by-contract methodology
- Understanding assertion behavior across languages

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview of assertions — purpose, philosophy, and when to use them vs exceptions.

### `preconditions`

```bash
scripts/script.sh preconditions
```

Precondition patterns: validating inputs, guard clauses, and fail-fast design.

### `postconditions`

```bash
scripts/script.sh postconditions
```

Postcondition patterns: validating outputs and return value contracts.

### `invariants`

```bash
scripts/script.sh invariants
```

Class and loop invariants — maintaining consistent state throughout execution.

### `languages`

```bash
scripts/script.sh languages
```

Assertion syntax and behavior in Python, Java, C, JavaScript, Rust, Go.

### `contracts`

```bash
scripts/script.sh contracts
```

Design-by-contract methodology — Bertrand Meyer's approach and modern implementations.

### `antipatterns`

```bash
scripts/script.sh antipatterns
```

Common assertion mistakes: side effects, catching AssertionError, using in production flow.

### `strategies`

```bash
scripts/script.sh strategies
```

Assertion strategies for different contexts: unit tests, production code, APIs, libraries.

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# assert — Assertion Patterns Reference
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

cmd_intro() {
    cat << 'EOF'
=== Assertions: Defensive Programming ===

An assertion is a boolean expression that must be true at a specific
point in the program. If false, the program halts immediately with
a diagnostic message.

Purpose:
  - Catch bugs early (fail-fast principle)
  - Document assumptions in executable form
  - Distinguish programmer errors from runtime errors
  - Make implicit assumptions explicit

Assertions vs Exceptions:
  Assertions          Exceptions
  ──────────          ──────────
  Programmer errors   User/environment errors
  Should never fail   Expected to happen sometimes
  Disabled in prod    Always active
  Bug indicators      Flow control
  "This can't happen" "This might happen"

When to Assert:
  ✓ Internal function preconditions
  ✓ Loop invariants
  ✓ Unreachable code paths (default: in switch)
  ✓ Assumptions after complex logic
  ✓ Post-conditions of algorithms

When NOT to Assert:
  ✗ User input validation (use exceptions)
  ✗ File/network errors (use error handling)
  ✗ Security checks (never disable in prod)
  ✗ Side effects inside assert expressions
  ✗ Public API boundary validation

Golden Rule:
  Assertions catch BUGS. Exceptions handle ERRORS.
  A bug is something that should never happen if the code is correct.
  An error is something that can happen even when the code is correct.
EOF
}

cmd_preconditions() {
    cat << 'EOF'
=== Precondition Patterns ===

Preconditions validate that inputs meet requirements BEFORE
the function body executes. They define the function's contract.

Guard Clause Pattern:
  Check → fail early → avoid deep nesting
  
  # Instead of:
  def process(data):
      if data is not None:
          if len(data) > 0:
              if data.is_valid():
                  # actual logic deeply nested
  
  # Use guard clauses:
  def process(data):
      assert data is not None, "data must not be None"
      assert len(data) > 0, "data must not be empty"
      assert data.is_valid(), "data must be valid"
      # actual logic at top level

Common Precondition Categories:

  Nullity:      assert x is not None
  Type:         assert isinstance(x, int)
  Range:        assert 0 <= x <= 100
  Length:        assert len(items) > 0
  State:        assert self._initialized
  Relationship: assert start < end
  Format:       assert re.match(r'^\d{4}-\d{2}', date)

Multiple Parameters:
  def transfer(from_acct, to_acct, amount):
      assert from_acct != to_acct, "cannot transfer to self"
      assert amount > 0, "amount must be positive"
      assert from_acct.balance >= amount, "insufficient funds"

Descriptive Messages:
  # Bad:  assert x > 0
  # Good: assert x > 0, f"expected positive x, got {x}"
  
  Always include the actual value in the message.
  Future-you debugging at 3 AM will thank present-you.

Precondition Levels:
  Cheap    Type checks, null checks      → always on
  Medium   Range checks, state checks    → on in dev/test
  Expensive Collection invariants, deep   → on in test only
            graph validation
EOF
}

cmd_postconditions() {
    cat << 'EOF'
=== Postcondition Patterns ===

Postconditions verify that a function's output satisfies its
contract AFTER execution. They catch logic errors in your own code.

Basic Pattern:
  def sqrt(x):
      assert x >= 0, "precondition: x must be non-negative"
      result = math.sqrt(x)
      assert abs(result * result - x) < 1e-10, "postcondition failed"
      return result

Return Value Contracts:
  def binary_search(arr, target):
      # ... implementation ...
      assert result == -1 or arr[result] == target
      assert result == -1 or (result == 0 or arr[result-1] < target)
      return result

State Transition Postconditions:
  def push(self, item):
      old_size = len(self._stack)
      self._stack.append(item)
      assert len(self._stack) == old_size + 1
      assert self._stack[-1] == item

Sorting Postconditions:
  def sort(items):
      result = _merge_sort(items)
      assert len(result) == len(items), "lost elements"
      assert all(result[i] <= result[i+1] for i in range(len(result)-1))
      assert sorted(items) == result, "permutation check"
      return result

Conservation Postconditions:
  Verify quantities are preserved:
  def redistribute(buckets):
      total_before = sum(buckets)
      # ... redistribution logic ...
      assert sum(buckets) == total_before, "total must be conserved"

Idempotency Postconditions:
  def normalize(text):
      result = _do_normalize(text)
      assert _do_normalize(result) == result, "must be idempotent"
      return result

Postcondition Cost:
  Simple value checks     → nearly free, always use
  Collection properties   → O(n), use in testing
  Full contract verify    → O(n²)+, test-only
EOF
}

cmd_invariants() {
    cat << 'EOF'
=== Invariants ===

An invariant is a condition that remains true throughout a scope.
Three types: class invariants, loop invariants, data invariants.

Class Invariants:
  Properties that must hold for every instance at every observable point.
  Check after construction and after every public method.

  class BankAccount:
      def _check_invariants(self):
          assert self.balance >= 0, "balance cannot be negative"
          assert self.owner is not None, "must have owner"
          assert len(self.transactions) >= 0
      
      def __init__(self, owner, initial):
          self.owner = owner
          self.balance = initial
          self.transactions = []
          self._check_invariants()
      
      def withdraw(self, amount):
          assert amount > 0             # precondition
          assert amount <= self.balance  # precondition
          self.balance -= amount
          self.transactions.append(-amount)
          self._check_invariants()       # invariant check

Loop Invariants:
  Conditions that hold before and after every iteration.
  Critical for proving loop correctness.

  # Binary search loop invariant:
  # arr[lo] <= target <= arr[hi]  (if target exists)
  def binary_search(arr, target):
      lo, hi = 0, len(arr) - 1
      while lo <= hi:
          assert lo >= 0 and hi < len(arr)  # bounds invariant
          mid = (lo + hi) // 2
          if arr[mid] == target: return mid
          elif arr[mid] < target: lo = mid + 1
          else: hi = mid - 1
      return -1

Data Structure Invariants:
  BST:    left.val < node.val < right.val for all nodes
  Heap:   parent.val <= child.val for all parent-child pairs
  RBTree: black-height equal on all paths, no red-red pairs
  Queue:  head <= tail, size = tail - head

Invariant Verification Timing:
  Always: after construction, after public mutations
  Debug:  after every internal mutation
  Never:  during mutation (state may be temporarily invalid)
EOF
}

cmd_languages() {
    cat << 'EOF'
=== Assertions Across Languages ===

Python:
  assert condition, "message"
  assert x > 0, f"expected positive, got {x}"
  # Disabled with: python -O (optimized mode)
  # __debug__ is False when optimized
  # NEVER use for input validation — can be disabled!

Java:
  assert condition : "message";
  assert index >= 0 : "Index: " + index;
  // Disabled by default! Enable: java -ea (enable assertions)
  // -ea:com.mypackage...  enable for specific package
  // Use Objects.requireNonNull() for production null checks

C / C++:
  #include <assert.h>
  assert(ptr != NULL);
  assert(size > 0 && "size must be positive");
  // Disabled with: #define NDEBUG (before include)
  // static_assert(sizeof(int) == 4, "need 32-bit int");  // compile-time!

JavaScript / TypeScript:
  console.assert(x > 0, "x must be positive");  // doesn't throw!
  // Node.js:
  const assert = require('assert');
  assert.strictEqual(a, b);
  assert.deepStrictEqual(obj1, obj2);
  // TypeScript: asserts keyword
  function assertString(val: any): asserts val is string {
    if (typeof val !== "string") throw new Error("not string");
  }

Rust:
  assert!(condition, "message with {}", value);
  assert_eq!(a, b, "a and b must be equal");
  assert_ne!(a, b);
  debug_assert!(condition);  // only in debug builds
  // assert! panics in both debug and release
  // debug_assert! only panics in debug builds

Go:
  // No built-in assert! By design.
  // Use explicit if + panic or testing.T
  if x <= 0 {
      panic(fmt.Sprintf("expected positive, got %d", x))
  }
  // In tests:
  if got != want {
      t.Errorf("got %v, want %v", got, want)
  }

Swift:
  assert(x > 0, "must be positive")       // debug only
  precondition(x > 0, "must be positive")  // debug AND release
  fatalError("unreachable")                // always crashes
EOF
}

cmd_contracts() {
    cat << 'EOF'
=== Design by Contract ===

Formalized by Bertrand Meyer (Eiffel language, 1986).
Every function has a contract: preconditions, postconditions,
and class invariants.

The Contract Metaphor:
  Supplier (callee):  "If you meet my preconditions,
                       I guarantee my postconditions."
  Client (caller):    "I'll meet your preconditions,
                       and I expect your postconditions."

  Like a legal contract — obligations and benefits for both sides.

Eiffel Syntax (the original):
  deposit (amount: REAL)
    require            -- preconditions
      positive: amount > 0
      account_open: is_open
    do
      balance := balance + amount
    ensure             -- postconditions
      increased: balance = old balance + amount
      still_open: is_open
    end

  class BANK_ACCOUNT
    invariant
      non_negative: balance >= 0
      consistent: transactions.count >= 0
    end

Liskov Substitution & Contracts:
  Subclass contracts must be compatible with parent:
    Preconditions:   may be WEAKER (accept more)
    Postconditions:  may be STRONGER (guarantee more)
    Invariants:      must be MAINTAINED
  
  Violation = broken substitutability

Modern Contract Libraries:
  Python:  icontract, deal, dpcontracts
  Java:    Cofoja, valid4j, Bean Validation (@NotNull, @Min)
  C++:     Boost.Contract, C++20 [[expects]], [[ensures]]
  C#:      Code Contracts (System.Diagnostics.Contracts)
  Kotlin:  require(), check(), requireNotNull()

Kotlin Built-in Contracts:
  fun process(name: String, age: Int) {
      require(name.isNotBlank()) { "name required" }  // IllegalArgument
      require(age >= 0) { "age must be non-negative" } // IllegalArgument
      check(isInitialized) { "not initialized" }       // IllegalState
  }

Contract Strength Levels:
  Level 1: Preconditions only (most common)
  Level 2: Pre + postconditions (recommended)
  Level 3: Pre + post + invariants (full DbC)
  Level 4: + formal verification (research/safety-critical)
EOF
}

cmd_antipatterns() {
    cat << 'EOF'
=== Assertion Anti-Patterns ===

1. Side Effects in Assertions
   # DANGEROUS — behavior changes when assertions disabled!
   assert users.pop() is not None     # modifies list!
   assert file.read() != ""           # advances file pointer!
   assert db.delete(id) == True        # deletes data!
   
   # Correct: separate the action from the check
   user = users.pop()
   assert user is not None

2. Catching AssertionError
   # WRONG — defeats the purpose
   try:
       assert x > 0
   except AssertionError:
       x = 1  # silently "fixing" a bug
   
   # If you need to handle it, use an exception:
   if x <= 0:
       raise ValueError("x must be positive")

3. Assertions for User Input
   # WRONG — can be disabled in production!
   assert len(password) >= 8, "password too short"
   assert email.contains("@"), "invalid email"
   
   # Correct: use validation + exceptions
   if len(password) < 8:
       raise ValidationError("password too short")

4. Assertions for Security
   # CATASTROPHIC — attacker runs with -O flag
   assert user.is_admin(), "unauthorized"
   assert token.is_valid(), "bad token"
   
   # Correct: always-on checks
   if not user.is_admin():
       raise PermissionError("unauthorized")

5. Empty Assert Messages
   assert x > 0           # what failed? why? what was x?
   assert x > 0, f"x must be positive, got {x}"  # much better

6. Asserting on Mutable Default State
   assert cache == {}     # brittle, depends on test order
   
7. Over-Asserting (assertion clutter)
   def add(a, b):
       assert isinstance(a, (int, float))
       assert isinstance(b, (int, float))
       result = a + b
       assert isinstance(result, (int, float))
       assert result == a + b  # tautology!
       return result

8. Asserting Implementation, Not Contract
   # Bad: testing HOW, not WHAT
   assert self._internal_list[3] == x
   # Good: testing the contract
   assert x in self  # behavior, not implementation
EOF
}

cmd_strategies() {
    cat << 'EOF'
=== Assertion Strategies ===

Unit Test Assertions:
  Use the testing framework's assertion methods — richer messages.
  
  Python unittest:
    assertEqual(a, b)
    assertRaises(TypeError, func, arg)
    assertAlmostEqual(a, b, places=5)
    assertIn(item, collection)
    assertIsInstance(obj, cls)
  
  Python pytest:
    assert a == b              # plain assert, pytest rewrites for info
    with pytest.raises(ValueError, match="positive"):
        func(-1)
  
  Java JUnit:
    assertEquals(expected, actual);
    assertThrows(Exception.class, () -> func());
    assertAll("group", () -> assertEquals(...), () -> assertTrue(...));
  
  JavaScript Jest:
    expect(value).toBe(expected);
    expect(func).toThrow(/message/);
    expect(array).toContain(item);
    expect(obj).toMatchObject(partial);

Production Code Strategy:
  Layer 1 — Always on:
    - Null checks at public API boundaries
    - Security & authorization checks
    - Data integrity checks
    Use: if/throw, require(), Objects.requireNonNull()
  
  Layer 2 — Debug/staging:
    - Internal state consistency
    - Algorithm correctness
    - Performance assumptions
    Use: assert, debug_assert!(), assert with -ea
  
  Layer 3 — Test only:
    - Expensive invariant verification
    - Exhaustive property checks
    - Fuzzing & property-based testing
    Use: test frameworks, hypothesis, QuickCheck

Library vs Application:
  Libraries: strict preconditions (fail loud on misuse)
  Applications: graceful degradation (recover when possible)
  APIs: validation errors with structured responses (400, 422)

Assertion Density Guidelines:
  Safety-critical code:  1 assert per 5-10 lines
  Business logic:        1 assert per 20-30 lines
  Utility code:          preconditions only
  Glue/UI code:          minimal (input validation instead)
EOF
}

show_help() {
    cat << EOF
assert v$VERSION — Assertion Patterns Reference

Usage: script.sh <command>

Commands:
  intro          Assertion philosophy and when to use
  preconditions  Input validation and guard clauses
  postconditions Output verification and return contracts
  invariants     Class, loop, and data invariants
  languages      Assert syntax in Python, Java, C, JS, Rust, Go
  contracts      Design-by-contract methodology
  antipatterns   Common assertion mistakes to avoid
  strategies     Assertion approaches for tests, prod, libraries
  help           Show this help
  version        Show version

Powered by BytesAgain | bytesagain.com
EOF
}

CMD="-help"

case "$CMD" in
    intro)          cmd_intro ;;
    preconditions)  cmd_preconditions ;;
    postconditions) cmd_postconditions ;;
    invariants)     cmd_invariants ;;
    languages|langs) cmd_languages ;;
    contracts|dbc)  cmd_contracts ;;
    antipatterns)   cmd_antipatterns ;;
    strategies)     cmd_strategies ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "assert v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: script.sh help"; exit 1 ;;
esac

---
name: "align"
version: "1.0.0"
description: "Data and text alignment reference — sequence alignment, text formatting, memory alignment, and CSS/layout alignment. Use when aligning sequences, formatting columnar output, or understanding byte alignment."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [align, alignment, formatting, layout, memory, sequence, css]
category: "atomic"
---

# Align — Alignment Reference

Quick-reference skill for alignment concepts across domains: text formatting, memory, CSS layout, and sequence alignment.

## When to Use

- Formatting text into aligned columns for terminal output
- Understanding memory alignment and struct padding
- Using CSS alignment properties (flexbox, grid, text)
- Sequence alignment algorithms (bioinformatics)
- Aligning data for SIMD operations

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview of alignment concepts across domains.

### `text`

```bash
scripts/script.sh text
```

Text alignment — printf formatting, column alignment, padding, and tabulation.

### `css`

```bash
scripts/script.sh css
```

CSS alignment — flexbox, grid, text-align, vertical centering techniques.

### `memory`

```bash
scripts/script.sh memory
```

Memory alignment — struct padding, cache lines, SIMD requirements, and alignment attributes.

### `sequence`

```bash
scripts/script.sh sequence
```

Sequence alignment — Needleman-Wunsch, Smith-Waterman, BLAST overview.

### `columns`

```bash
scripts/script.sh columns
```

Column formatting — CLI table output, fixed-width, and dynamic column sizing.

### `typographic`

```bash
scripts/script.sh typographic
```

Typographic alignment — left, right, center, justified, and baseline alignment.

### `tools`

```bash
scripts/script.sh tools
```

Alignment tools — column, printf, fmt, CSS debuggers, and struct analyzers.

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

## Configuration

| Variable | Description |
|----------|-------------|
| `ALIGN_DIR` | Data directory (default: ~/.align/) |

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# align — Alignment Reference
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

cmd_intro() {
    cat << 'EOF'
=== Alignment Concepts ===

Alignment means arranging elements along a common reference line or
boundary. The concept spans multiple domains:

  Text Alignment:     Formatting text in columns, tables, padding
  CSS/Layout:         Positioning elements in flexbox, grid, or flow
  Memory Alignment:   Placing data at addresses divisible by N bytes
  Sequence Alignment: Matching biological sequences (DNA, protein)
  Data Alignment:     Ensuring fields match across datasets

Each domain has its own rules, tools, and trade-offs, but the
core idea is the same: arranging things relative to a reference.
EOF
}

cmd_text() {
    cat << 'EOF'
=== Text Alignment ===

--- printf/sprintf Formatting ---
  %10s     Right-align in 10-char field   "     hello"
  %-10s    Left-align in 10-char field    "hello     "
  %10d     Right-align integer            "        42"
  %-10d    Left-align integer             "42        "
  %010d    Zero-pad integer               "0000000042"
  %10.2f   Right-align float, 2 decimals  "     42.50"

  printf "%-20s %8s %10s\n" "Product" "Qty" "Price"
  printf "%-20s %8d %10.2f\n" "Widget" 42 9.99
  printf "%-20s %8d %10.2f\n" "Gizmo" 7 149.95

  Output:
  Product              Qty      Price
  Widget                 42       9.99
  Gizmo                   7     149.95

--- Python String Formatting ---
  f"{'hello':>10}"     Right-align    "     hello"
  f"{'hello':<10}"     Left-align     "hello     "
  f"{'hello':^10}"     Center         "  hello   "
  f"{'hello':*^10}"    Center, fill   "**hello***"
  f"{42:08d}"          Zero-pad       "00000042"
  f"{3.14:.4f}"        Decimal places "3.1400"

--- Column Alignment (CLI) ---
  column -t:
    echo -e "Name\tAge\tCity\nAlice\t30\tNYC\nBob\t25\tLA" | column -t
    Name   Age  City
    Alice  30   NYC
    Bob    25   LA

  pr -tT -w80 -3:  Three-column layout

--- Padding Strategies ---
  Left pad:   "   42" — numeric values (right-aligned)
  Right pad:  "hello   " — text labels (left-aligned)
  Zero pad:   "00042" — IDs, codes, timestamps
  Center pad: " hello " — headers, titles

--- Tab Stops ---
  Default: every 8 characters
  Expand tabs: expand -t4 file.txt (convert to 4-space tabs)
  Unexpand: unexpand -t4 (convert spaces back to tabs)
  Be consistent: tabs OR spaces, never mix
EOF
}

cmd_css() {
    cat << 'EOF'
=== CSS Alignment ===

--- Flexbox Alignment ---

  Container properties:
    justify-content: flex-start | center | flex-end | space-between | space-around
      → Aligns items along MAIN axis (horizontal by default)

    align-items: stretch | flex-start | center | flex-end | baseline
      → Aligns items along CROSS axis (vertical by default)

    align-content: (same values as justify-content)
      → Aligns wrapped LINES (only with flex-wrap)

  Item properties:
    align-self: auto | flex-start | center | flex-end | stretch
      → Override align-items for single item

  Center anything (holy grail):
    .container {
      display: flex;
      justify-content: center;
      align-items: center;
    }

--- Grid Alignment ---
    justify-items: start | center | end | stretch
      → Aligns items within their cell (inline/horizontal)

    align-items: start | center | end | stretch
      → Aligns items within their cell (block/vertical)

    place-items: center center;
      → Shorthand for align-items + justify-items

    justify-content / align-content:
      → Aligns the GRID within its container

--- Text Alignment ---
    text-align: left | right | center | justify
    text-align-last: auto | left | center | right | justify
    vertical-align: baseline | top | middle | bottom | sub | super
      → For inline/table-cell elements only

--- Vertical Centering Methods ---
  1. Flexbox (recommended):
     display: flex; align-items: center;

  2. Grid:
     display: grid; place-items: center;

  3. Transform:
     position: absolute; top: 50%; transform: translateY(-50%);

  4. Line-height (single line text only):
     line-height: 60px; height: 60px;

  5. Table-cell:
     display: table-cell; vertical-align: middle;
EOF
}

cmd_memory() {
    cat << 'EOF'
=== Memory Alignment ===

Data alignment means placing values at memory addresses that are
multiples of their size. Critical for performance and correctness.

--- Why Alignment Matters ---
  CPU fetches data in chunks (4 or 8 bytes on modern CPUs).
  Misaligned data may require two fetches instead of one.

  Aligned:    Address 0x1000 for int32 → one fetch (4 bytes)
  Misaligned: Address 0x1001 for int32 → TWO fetches + combine

  Performance penalty: 2-10× slower for misaligned access (varies by arch)
  Some architectures (ARM, MIPS) CRASH on misaligned access

--- Natural Alignment Rules ---
  Type        Size    Alignment
  char        1       1 (any address)
  short       2       2 (even address)
  int         4       4 (divisible by 4)
  long/ptr    8       8 (divisible by 8)
  float       4       4
  double      8       8
  __m128      16      16 (SSE)
  __m256      32      32 (AVX)
  __m512      64      64 (AVX-512)

--- Struct Padding ---
  struct Bad {       //  Size: 24 bytes (with padding)
    char  a;         //  offset 0, size 1
                     //  3 bytes padding
    int   b;         //  offset 4, size 4
    char  c;         //  offset 8, size 1
                     //  7 bytes padding
    double d;        //  offset 16, size 8
  };

  struct Good {      //  Size: 16 bytes (reordered)
    double d;        //  offset 0, size 8
    int    b;        //  offset 8, size 4
    char   a;        //  offset 12, size 1
    char   c;        //  offset 13, size 1
                     //  2 bytes padding
  };

  Rule: order fields from largest to smallest

--- Compiler Controls ---
  GCC/Clang:
    __attribute__((aligned(16)))    Force alignment
    __attribute__((packed))         Remove padding (misaligned!)
    #pragma pack(push, 1)          Pack following structs

  MSVC:
    __declspec(align(16))          Force alignment
    #pragma pack(1)                Pack structs

  C11: _Alignas(16) int x;
  C++11: alignas(16) int x;

--- Cache Line Alignment ---
  Cache line: 64 bytes on most modern CPUs
  False sharing: two threads writing to same cache line
  Fix: align per-thread data to cache line boundaries
    alignas(64) struct ThreadData { ... };
  Critical in: lock-free data structures, thread pools
EOF
}

cmd_sequence() {
    cat << 'EOF'
=== Sequence Alignment ===

Sequence alignment identifies regions of similarity between biological
sequences (DNA, RNA, protein) that may indicate functional, structural,
or evolutionary relationships.

--- Types ---
  Global Alignment:  Aligns sequences end-to-end
    Algorithm: Needleman-Wunsch (dynamic programming)
    Use: comparing two closely related sequences of similar length
    Time: O(m × n), Space: O(m × n)

  Local Alignment:   Finds best matching subsequences
    Algorithm: Smith-Waterman (dynamic programming)
    Use: finding conserved regions in divergent sequences
    Time: O(m × n), Space: O(m × n)

  Semi-global:       One sequence end-to-end, other partial
    Use: aligning short reads to a reference genome

--- Scoring ---
  Match:    +1 to +5 (reward for identical characters)
  Mismatch: -1 to -3 (penalty for substitution)
  Gap open:  -10 to -12 (penalty for starting a gap)
  Gap extend: -1 to -2 (penalty for continuing a gap)

  Substitution matrices (protein):
    BLOSUM62: most common default for protein alignment
    PAM250: for distantly related sequences
    Higher number = more closely related sequences

--- BLAST (Basic Local Alignment Search Tool) ---
  Heuristic algorithm — much faster than Smith-Waterman
  Not guaranteed to find optimal alignment

  Steps:
    1. Break query into short words (k-mers, typically k=3 for protein)
    2. Find exact matches in database (seeds)
    3. Extend seeds in both directions (HSP — High Scoring Pairs)
    4. Evaluate statistical significance (E-value)

  E-value interpretation:
    E < 1e-50:  Almost certainly homologous
    E < 1e-10:  Very likely homologous
    E < 0.01:   Probably homologous
    E > 1:      Likely random match

  BLAST variants:
    blastn:  nucleotide vs nucleotide
    blastp:  protein vs protein
    blastx:  translated nucleotide vs protein
    tblastn: protein vs translated nucleotide

--- Multiple Sequence Alignment (MSA) ---
  Aligning 3+ sequences simultaneously
  Tools: MUSCLE, MAFFT, ClustalW, T-Coffee
  NP-hard problem — all tools use heuristics
  Used for: phylogenetic trees, conserved region identification
EOF
}

cmd_columns() {
    cat << 'EOF'
=== Column Formatting ===

--- CLI Table Output ---

  Simple column alignment:
    printf "%-15s %-10s %10s\n" "Name" "Status" "Count"
    printf "%-15s %-10s %10d\n" "production" "active" 1542
    printf "%-15s %-10s %10d\n" "staging" "paused" 38
    printf "%s\n" "$(printf '=%.0s' {1..37})"
    printf "%-15s %-10s %10d\n" "TOTAL" "" 1580

  Output:
    Name            Status          Count
    production      active           1542
    staging         paused             38
    =====================================
    TOTAL                            1580

--- Dynamic Column Width ---
  Calculate widths from data:
    # Find max width of each column
    max_name=0
    for name in "names[@]"; do
      (( #name > max_name )) && max_name=#name
    done
    # Use in printf
    printf "%-max_names ...\n" "$name"

--- Box Drawing Characters ---
  Unicode box drawing for nicer tables:
    ┌──────────┬────────┬──────┐
    │ Name     │ Status │ Size │
    ├──────────┼────────┼──────┤
    │ server-1 │ up     │ 4GB  │
    │ server-2 │ down   │ 8GB  │
    └──────────┴────────┴──────┘

  Characters: ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼ ─ │

--- Tools ---
  column -t -s','    Auto-align CSV with tabs
  pr -t -w80         Format for printing
  expand -t4         Convert tabs to spaces
  fold -w80          Wrap long lines at width
  fmt -w72           Reflow text to width
  rs -t              Reshape data (transpose, etc.)
  csvlook            Pretty-print CSV as table (csvkit)
  tabulate (Python)  Generate ASCII/Unicode tables from data
EOF
}

cmd_typographic() {
    cat << 'EOF'
=== Typographic Alignment ===

--- Text Alignment Types ---

  Left-Aligned (Ragged Right):
    Most readable for body text in left-to-right languages
    Natural word spacing, no awkward gaps
    Default for web, documents, and code
    Use for: body text, lists, code

  Right-Aligned (Ragged Left):
    Harder to read for long text
    Use for: numbers in tables, dates, prices
    Aligns decimal points in numeric columns
    Use for: captions on left side of images

  Center-Aligned:
    Symmetrical appearance
    Hard to read for more than 2-3 lines
    Use for: headings, invitations, poetry, short labels
    Never for: body text, paragraphs

  Justified:
    Both edges aligned (flush left and right)
    Creates uneven word spacing (rivers of white space)
    Requires: good hyphenation to avoid huge gaps
    Use for: newspapers, books, formal documents
    Avoid for: narrow columns (too many gaps)

--- Baseline Alignment ---
  Aligning text of different sizes along the baseline
  (the invisible line text sits on)

  Important for:
    Mixed font sizes on same line
    Inline images with text
    Form labels next to inputs

  CSS: vertical-align: baseline (default for inline elements)

--- Optical Alignment ---
  Mathematically centered ≠ visually centered
  Round shapes (O, C) need to extend slightly beyond the line
  Triangles (A, V) need to extend slightly to look aligned
  This is why fonts have overshoot — characters extend past metrics

  For icons:
    A play button (▶) centered in a circle needs to shift RIGHT
    because the visual center of a triangle is right of geometric center

  For text in buttons:
    Often needs 1-2px more padding on top than bottom
    Because descenders (g, y, p) make text look low

--- Vertical Rhythm ---
  Maintaining consistent spacing throughout a page
  All text and spacing based on a base unit (e.g., 8px)
  Line heights: multiples of the base (16px, 24px, 32px)
  Margins and padding: multiples of the base
  Creates visual harmony and readability
EOF
}

cmd_tools() {
    cat << 'EOF'
=== Alignment Tools ===

--- CLI Tools ---
  column       Align columns in text
    echo "a 1\nbb 22\nccc 333" | column -t
    a    1
    bb   22
    ccc  333

  printf       Formatted output with field widths
    printf "%-10s %5d\n" "Alice" 42

  fmt          Reflow text to specified width
    fmt -w72 essay.txt

  fold         Wrap lines at specified width
    fold -w80 -s file.txt    (-s = break at spaces)

  expand/unexpand  Convert between tabs and spaces
  rev          Reverse each line (for right-alignment tricks)

--- Python Tools ---
  tabulate:  pip install tabulate
    from tabulate import tabulate
    print(tabulate(data, headers=["Name","Age"], tablefmt="grid"))

  textwrap:  Standard library text wrapping
    textwrap.fill(text, width=72)
    textwrap.indent(text, prefix="  ")

  str methods:
    "hello".ljust(10)    "hello     "
    "hello".rjust(10)    "     hello"
    "hello".center(10)   "  hello   "
    "42".zfill(8)        "00000042"

--- CSS Debugging ---
  * { outline: 1px solid red; }  — show all element boxes
  Flexbox Inspector: Firefox DevTools > Layout > Flex
  Grid Inspector: Firefox DevTools > Layout > Grid
  Chrome DevTools: overlay flex/grid alignment guides

--- Memory Alignment Tools ---
  pahole (Linux):  Analyze struct padding
    pahole -C MyStruct my_binary
  offsetof() macro: Check field offsets at compile time
  alignof() operator: Query alignment requirement (C++11)
  -Wpadded (GCC):  Warn about struct padding
EOF
}

show_help() {
    cat << EOF
align v$VERSION — Alignment Reference

Usage: script.sh <command>

Commands:
  intro        Alignment concepts overview
  text         printf formatting, padding, column alignment
  css          CSS flexbox, grid, text, and vertical centering
  memory       Struct padding, cache lines, SIMD alignment
  sequence     Biological sequence alignment algorithms
  columns      CLI table output and dynamic column sizing
  typographic  Left, right, center, justified, baseline alignment
  tools        CLI, Python, CSS, and memory alignment tools
  help         Show this help
  version      Show version

Powered by BytesAgain | bytesagain.com
EOF
}

CMD="-help"

case "$CMD" in
    intro)       cmd_intro ;;
    text)        cmd_text ;;
    css)         cmd_css ;;
    memory)      cmd_memory ;;
    sequence)    cmd_sequence ;;
    columns)     cmd_columns ;;
    typographic) cmd_typographic ;;
    tools)       cmd_tools ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "align v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: script.sh help"; exit 1 ;;
esac

---
name: "urea"
version: "1.0.0"
description: "Urea fertilizer reference — nitrogen management, application methods, volatilization loss, soil chemistry, and crop-specific rates. Use when planning nitrogen fertilization, calculating urea rates, or managing ammonia loss."
author: "BytesAgain"
homepage: "https://bytesagain.com"
source: "https://github.com/bytesagain/ai-skills"
tags: [urea, nitrogen, fertilizer, agriculture, soil, crop-nutrition, ammonia]
category: "agriculture"
---

# Urea — Urea Fertilizer Reference

Quick-reference skill for urea fertilizer management, application, and nitrogen chemistry.

## When to Use

- Calculating urea application rates for crops
- Managing ammonia volatilization losses
- Understanding nitrogen cycle in soil
- Comparing nitrogen fertilizer sources
- Timing nitrogen applications for maximum efficiency

## Commands

### `intro`

```bash
scripts/script.sh intro
```

Overview of urea — chemistry, production, and role in agriculture.

### `chemistry`

```bash
scripts/script.sh chemistry
```

Urea chemistry — hydrolysis, nitrification, nitrogen cycle in soil.

### `application`

```bash
scripts/script.sh application
```

Application methods — broadcast, banded, foliar, fertigation.

### `rates`

```bash
scripts/script.sh rates
```

Crop-specific nitrogen rates and urea calculation.

### `losses`

```bash
scripts/script.sh losses
```

Nitrogen loss pathways — volatilization, leaching, denitrification.

### `comparison`

```bash
scripts/script.sh comparison
```

Comparing nitrogen sources — urea, UAN, ammonium nitrate, anhydrous ammonia.

### `examples`

```bash
scripts/script.sh examples
```

Practical urea application scenarios and calculations.

### `checklist`

```bash
scripts/script.sh checklist
```

Urea application planning checklist.

### `help`

```bash
scripts/script.sh help
```

### `version`

```bash
scripts/script.sh version
```

## Configuration

| Variable | Description |
|----------|-------------|
| `UREA_DIR` | Data directory (default: ~/.urea/) |

---

*Powered by BytesAgain | bytesagain.com | [email protected]*

FILE:scripts/script.sh
#!/usr/bin/env bash
# urea — Urea Fertilizer Reference
# Powered by BytesAgain | bytesagain.com | [email protected]
set -euo pipefail

VERSION="1.0.0"

cmd_intro() {
    cat << 'EOF'
=== Urea Fertilizer — Overview ===

Urea (CO(NH₂)₂) is the world's most widely used nitrogen fertilizer,
providing 46% nitrogen by weight — the highest of any solid N fertilizer.

Key Facts:
  Chemical formula:   CO(NH₂)₂ (carbamide)
  Nitrogen content:   46-0-0 (46% N, 0% P₂O₅, 0% K₂O)
  Molecular weight:   60.06 g/mol
  Appearance:         White crystalline granules or prills
  Solubility:         1,080 g/L water at 20°C (very soluble)
  pH in solution:     ~7.0 (neutral)
  Melting point:      133°C (271°F)
  Bulk density:       720-780 kg/m³ (45-49 lb/ft³)

Production:
  Haber-Bosch process (ammonia) + carbon dioxide
  CO₂ + 2NH₃ → CO(NH₂)₂ + H₂O
  Global production: ~180 million tons/year
  Major producers: China, India, Russia, Indonesia
  Energy intensive: ~1.5 tons CO₂ per ton of urea produced
  Price typically: $300-600/ton (varies with natural gas prices)

Forms:
  Granular:    2-4mm particles, most common for field application
  Prilled:     1-2mm spheres, older process, more dusty
  Coated:      Polymer/sulfur coated for slow release
  Solution:    UAN (urea + ammonium nitrate in water, 28-32% N)
  SuperU:      Urea + urease/nitrification inhibitors

Advantages:
  - Highest N concentration of solid fertilizers (low transport cost)
  - Safe to handle and store (non-explosive)
  - Versatile application methods
  - Good compatibility with other fertilizers
  - Can be applied to most crops and soils

Disadvantages:
  - Ammonia volatilization loss (up to 30% if surface-applied)
  - Requires urease enzyme to convert to plant-available N
  - Biuret content can damage seed and foliage (if >1.5%)
  - Hygroscopic (absorbs moisture, cakes in storage)
  - Temporary soil pH increase around granule (NH₃ release)
EOF
}

cmd_chemistry() {
    cat << 'EOF'
=== Urea Chemistry in Soil ===

Step 1: Hydrolysis (Urea → Ammonium)
  CO(NH₂)₂ + H₂O → 2NH₃ + CO₂
  NH₃ + H₂O → NH₄⁺ + OH⁻ (ammonium)
  
  Catalyst: Urease enzyme (present in all soils)
  Speed: Complete in 2-7 days (faster in warm, moist soil)
  pH effect: Temporarily raises soil pH around granule to 9+
  This is when volatilization risk is highest

Step 2: Nitrification (Ammonium → Nitrate)
  NH₄⁺ → NO₂⁻ → NO₃⁻
  
  Stage 1: NH₄⁺ → NO₂⁻ (Nitrosomonas bacteria)
  Stage 2: NO₂⁻ → NO₃⁻ (Nitrobacter bacteria)
  
  Speed: Days to weeks depending on:
    - Temperature: Optimal 25-35°C, slow <10°C, stops <5°C
    - Moisture: Optimal 50-70% WFPS
    - pH: Optimal 6.0-8.0, inhibited below 5.5
    - Aeration: Requires oxygen (aerobic process)
  
  pH effect: Produces H⁺ (acidifying)
  Net effect of urea: Slight soil acidification over time

Plant Uptake Forms:
  NH₄⁺ (ammonium):  Taken up directly, held on soil particles (CEC)
  NO₃⁻ (nitrate):   Primary uptake form, mobile in soil water
  
  Preference: Most crops prefer mixed NH₄⁺/NO₃⁻
  Rice exception: Prefers NH₄⁺ (flooded conditions inhibit nitrification)

Nitrogen Cycle Summary:
  Urea → [hydrolysis] → NH₄⁺ → [nitrification] → NO₃⁻
                          ↑                           ↓
                   Soil fixation              Plant uptake
                   (clay, OM)                 Leaching loss
                          ↓                   Denitrification
                   Volatilization
                   (NH₃ gas loss)

Inhibitors:
  Urease inhibitors (slow hydrolysis):
    NBPT (N-(n-butyl)thiophosphoric triamide)
    Delays conversion to NH₃ by 7-14 days
    Reduces volatilization 30-70%
    Brand names: Agrotain, Limus
  
  Nitrification inhibitors (slow NO₃⁻ formation):
    DCD (dicyandiamide)
    Nitrapyrin (N-Serve)
    Keep N as NH₄⁺ longer → less leaching, less denitrification
    Duration: 4-8 weeks depending on temperature

  Enhanced efficiency fertilizers:
    SuperU = Urea + NBPT + DCD
    ESN (polymer-coated urea) = controlled release over 50-80 days
    Sulfur-coated urea (SCU) = slow release
EOF
}

cmd_application() {
    cat << 'EOF'
=== Urea Application Methods ===

Surface Broadcast:
  Method: Spread urea granules uniformly on soil surface
  Equipment: Spinner spreader, air boom, aircraft
  
  Pros:
    - Fast, covers large areas quickly
    - Low equipment cost
    - Can apply on growing crop (top-dress)
  
  Cons:
    - Highest volatilization risk (10-30% N loss)
    - Must incorporate within 48 hours if possible
    - Uneven distribution with spinner spreaders
  
  Reduce losses:
    - Apply before rain (0.25-0.5" rainfall incorporates)
    - Apply to moist soil (not dry, hot surfaces)
    - Use urease inhibitor (NBPT)
    - Avoid surface application when >50°F and windy
    - Irrigate after application if possible

Incorporation (Soil-Mixed):
  Method: Broadcast then disc/cultivate into soil (2-4")
  Or: Apply with tillage equipment
  
  Pros:
    - Virtually eliminates volatilization
    - Places N in root zone
  
  Cons:
    - Requires additional field pass
    - Not possible in no-till or growing crops
    - Additional fuel and time cost

Band Application:
  Method: Place urea in concentrated band below or beside seed
  Equipment: Fertilizer drill, strip-till applicator
  
  Types:
    Side-band:  2" to side, 2" below seed (safe)
    Mid-row:    Between every other row
    Deep band:  4-6" deep (injection)
  
  Pros:
    - Reduces volatilization (soil-covered)
    - Higher efficiency (closer to roots)
    - Less fertilizer needed (20-30% rate reduction possible)
  
  Seed placement warning:
    Never place urea IN the seed row!
    NH₃ from hydrolysis burns seedlings
    Safe distance: ≥2" from seed for most crops
    Maximum safe rate in-furrow: 5-10 lbs N/acre

Foliar Application:
  Method: Spray dissolved urea on crop leaves
  Concentration: 2-5% urea solution (20-50 g/L)
  
  Pros:
    - Rapid N uptake (hours)
    - Useful for correcting mid-season deficiency
    - Bypasses soil issues
  
  Cons:
    - Small amounts per application (5-15 lbs N/acre)
    - Leaf burn risk above 5% concentration
    - Multiple applications needed
    - Weather dependent (avoid hot, sunny conditions)
  
  Best practice: Apply early morning or late afternoon
  Max concentration: 3% for most broadleaf crops

Fertigation:
  Method: Dissolve urea in irrigation water
  Systems: Drip, sprinkler, pivot
  
  Advantage: Spoon-feeding N through season
  Rate: Match to crop growth stage needs
  Solubility: No issue (urea very water-soluble)
  Uniformity: Depends on irrigation system uniformity
  Caution: Don't mix with calcium-containing solutions (precipitation)
EOF
}

cmd_rates() {
    cat << 'EOF'
=== Crop Nitrogen Rates & Urea Calculation ===

Conversion:
  Urea is 46% N
  To calculate urea needed:
  Urea (lbs) = N needed (lbs) ÷ 0.46

  Example: Need 150 lbs N/acre
  Urea = 150 ÷ 0.46 = 326 lbs urea/acre

Crop Nitrogen Recommendations (typical ranges):

  Corn (Maize):
    Rate: 0.8-1.2 lbs N per bushel yield goal
    Example: 200 bu/acre goal × 1.0 = 200 lbs N/acre
    Urea: 200 ÷ 0.46 = 435 lbs/acre
    Timing: 1/3 at planting, 2/3 side-dress at V6-V8
    Credit: Soybeans previous crop = -40 to -50 lbs N

  Wheat (Winter):
    Rate: 1.0-1.4 lbs N per bushel yield goal
    Example: 80 bu/acre × 1.2 = 96 lbs N/acre
    Urea: 96 ÷ 0.46 = 209 lbs/acre
    Timing: 20-30 lbs N fall, remainder topdress in spring (Feekes 3-5)

  Rice (Paddy):
    Rate: 100-180 lbs N/acre (variety dependent)
    Urea: 220-390 lbs/acre
    Timing: 2/3 preflood, 1/3 at panicle initiation
    Key: Apply to dry soil, flood within 5 days (reduce loss)

  Soybeans:
    Generally: No N fertilizer needed (nitrogen fixation)
    Exception: Starter N 10-20 lbs/acre in some systems
    Inoculation more important than N fertilizer

  Cotton:
    Rate: 60-100 lbs N/acre
    Urea: 130-220 lbs/acre
    Timing: Split — 1/3 at planting, 2/3 at first square
    Over-fertilization → excessive vegetative growth

  Pasture/Hay:
    Rate: 40-80 lbs N/acre per cutting
    Urea: 87-174 lbs/acre per application
    Timing: After each harvest cut
    Annual total: 150-300 lbs N/acre

Soil Test Credit:
  Soil nitrate test (0-24"): Subtract ppm × conversion factor
  Organic matter credit: ~20 lbs N per 1% OM
  Previous crop residual N:
    After soybeans: -40 lbs N
    After alfalfa (1st year): -150 lbs N
    After alfalfa (2nd year): -75 lbs N
  Manure credit: Calculate available N from application records

Economic Optimum:
  Maximum return to N (MRTN) approach
  Diminishing returns: Last 50 lbs N contributes less yield
  Optimal rate balances: N cost vs grain price
  When corn price high and N cheap → apply more
  When corn price low and N expensive → apply less
EOF
}

cmd_losses() {
    cat << 'EOF'
=== Nitrogen Loss Pathways ===

1. Ammonia Volatilization:
   Urea → NH₃ gas escapes to atmosphere
   
   Conditions that increase volatilization:
     High temperature:     >50°F (10°C), rapid above 70°F
     High pH:              Alkaline soils (pH >7.5) worse
     Low moisture:         Dry soil surface, no rain to incorporate
     High wind:            Removes NH₃ from soil surface
     Heavy residue:        Urease enzyme concentrated in residue
     Surface application:  Not incorporated into soil
   
   Loss magnitude:
     Best case: <5% (cold, wet, incorporated)
     Typical: 10-15% (surface-applied, incorporated by rain)
     Worst case: 25-40% (hot, dry, high pH, no incorporation)
   
   Mitigation:
     - Incorporate within 48 hours (rain or tillage)
     - Use NBPT urease inhibitor (reduces loss 30-70%)
     - Apply before forecasted rain (0.25"+ within 2 days)
     - Band or inject instead of broadcast
     - Apply when temp <50°F if possible

2. Nitrate Leaching:
   NO₃⁻ moves below root zone with excess water
   
   Risk factors:
     - Sandy soils (low water-holding capacity)
     - High rainfall or over-irrigation
     - Fall/winter application (crop not actively growing)
     - Excessive N rates
   
   Environmental impact:
     - Groundwater contamination (drinking water >10 ppm NO₃-N)
     - Contributes to hypoxic zones (Gulf of Mexico dead zone)
   
   Mitigation:
     - Split applications (don't apply all N at once)
     - Nitrification inhibitors (keep N as NH₄⁺ longer)
     - Match rate to crop uptake timing
     - Avoid fall application on sandy soils

3. Denitrification:
   NO₃⁻ → N₂O → N₂ (gaseous loss)
   Occurs in waterlogged (anaerobic) conditions
   
   Risk factors:
     - Saturated soils (after heavy rain)
     - Warm temperatures (>50°F)
     - High organic matter (energy for bacteria)
     - Fine-textured soils (poor drainage)
   
   Loss: 5-25% of applied N in wet years
   N₂O: Potent greenhouse gas (298× CO₂)
   
   Mitigation:
     - Improve drainage
     - Delay N application until soil dries
     - Nitrification inhibitors

4. Crop Removal:
   Not a "loss" but important for N balance
   Corn grain: ~0.65 lbs N per bushel removed
   Wheat grain: ~1.0 lbs N per bushel removed
   Soybean grain: ~3.3 lbs N per bushel removed
   Hay: ~50 lbs N per ton removed
EOF
}

cmd_comparison() {
    cat << 'EOF'
=== Nitrogen Fertilizer Comparison ===

Product              N%    Form           Cost Index
Urea                 46    Granular       1.0×
UAN-28              28    Liquid         1.2×
UAN-32              32    Liquid         1.1×
Ammonium Nitrate    34    Granular       1.3×
Ammonium Sulfate    21    Granular       1.5×
Anhydrous Ammonia   82    Pressurized    0.7×
DAP (18-46-0)       18    Granular       N/A (P source)
MAP (11-52-0)       11    Granular       N/A (P source)

Urea (46-0-0):
  Most popular globally, easy to handle
  Main risk: volatilization when surface-applied
  Best for: broadcast, fertigation, foliar
  Storage: Keep dry (hygroscopic)

Anhydrous Ammonia (82-0-0):
  Cheapest N per pound
  Must be injected 6-8" deep under pressure
  Dangerous: toxic gas, requires certified applicators
  Best for: pre-plant, side-dress (injection)
  Equipment: Nurse tanks, applicator with knife injectors

UAN Solution (28-32%):
  Liquid blend of urea + ammonium nitrate + water
  Easy to handle and apply (sprayer or dribble)
  Can mix with herbicides (check compatibility)
  Volatilization risk moderate (half is urea-based)
  Best for: top-dress, sidedress, with herbicide

Ammonium Nitrate (34-0-0):
  Fast-acting, low volatilization risk
  Regulated: explosive potential (ANFO)
  Banned for retail sale in some regions post-Oklahoma City
  Best for: top-dress, immediate availability
  Acidifying: produces H⁺ during nitrification

Ammonium Sulfate (21-0-0-24S):
  Provides both nitrogen AND sulfur
  Low volatilization risk (acidic reaction)
  Good for S-deficient soils
  Lower N content → more product to haul
  Best for: crops needing sulfur (canola, alfalfa, corn)

Controlled-Release Products:
  ESN (polymer-coated urea): 44% N, releases over 50-80 days
  SCU (sulfur-coated urea): 36-38% N, releases over 30-60 days
  Cost: 1.5-2.0× urea, but reduce losses significantly
  Best for: single-application systems, high-loss environments

Cost Comparison (per lb of N):
  Calculate: Price per ton ÷ (2000 × %N)
  Example: Urea at $500/ton = $500 ÷ (2000 × 0.46) = $0.54/lb N
  Example: NH₃ at $600/ton = $600 ÷ (2000 × 0.82) = $0.37/lb N
  Always compare cost per pound of actual nitrogen!
EOF
}

cmd_examples() {
    cat << 'EOF'
=== Urea Application Scenarios ===

--- Corn Side-Dress Calculation ---
Goal: 180 lbs N/acre total for 180 bu/acre corn
Already applied: 50 lbs N/acre as starter (DAP at planting)
Remaining: 180 - 50 = 130 lbs N/acre needed
Urea: 130 ÷ 0.46 = 283 lbs urea/acre
Application: Side-dress at V6 stage, band 3" deep
Timing: When corn is 18-24 inches tall
Equipment: Coulter applicator or hopper side-dress rig

--- Winter Wheat Top-Dress ---
Goal: 100 lbs N/acre for 75 bu/acre wheat
Fall-applied: 25 lbs N/acre (at planting)
Spring top-dress: 75 lbs N/acre
Urea: 75 ÷ 0.46 = 163 lbs urea/acre
Timing: Late February/early March (Feekes 3-4, greenup)
Method: Broadcast with spinner spreader
Risk: Surface volatilization — apply before rain forecast
Tip: Use NBPT-treated urea if rain unlikely within 48 hours
Cost of NBPT: ~$3-5/acre (cheap insurance vs 15% N loss)

--- Pasture Application ---
Goal: 50 lbs N/acre per application, 4 cuttings/year
Per application: 50 ÷ 0.46 = 109 lbs urea/acre
Annual total: 436 lbs urea/acre (200 lbs N/acre)
Timing: After each hay cutting, when regrowth starts
Method: Broadcast after hay removal
Important: Don't apply to wet foliage (leaf burn)
Water: Need 0.5"+ rain within 3 days for incorporation

--- Rice Paddy Urea Management ---
Goal: 150 lbs N/acre
Pre-flood application: 100 lbs N/acre = 217 lbs urea/acre
  1. Drain paddy to dry soil surface
  2. Broadcast urea onto dry soil
  3. Flood within 3-5 days (critical — reduces volatilization 80%)
  4. Maintain 2-4" flood depth

Panicle initiation: 50 lbs N/acre = 109 lbs urea/acre
  Apply into floodwater at panicle differentiation stage

--- Volatilization Loss Estimate ---
Scenario: 200 lbs N/acre surface-broadcast on warm day
Conditions: 80°F, pH 7.8, dry, no rain for 5 days
Estimated loss: 25% of applied N
N lost: 200 × 0.25 = 50 lbs N/acre
Dollar impact: 50 × $0.55/lb N = $27.50/acre
On 1,000 acres = $27,500 lost

With NBPT inhibitor:
Cost: $4.00/acre
Loss reduced to: 8% = 16 lbs N/acre lost
Savings: (50 - 16) × $0.55 = $18.70/acre saved
Net benefit: $18.70 - $4.00 = $14.70/acre profit
ROI: 367% — always use inhibitor for surface application!
EOF
}

cmd_checklist() {
    cat << 'EOF'
=== Urea Application Planning Checklist ===

Rate Determination:
  [ ] Soil test reviewed (residual N, OM, pH)
  [ ] Yield goal established for the field
  [ ] Crop N recommendation looked up
  [ ] Previous crop N credit applied
  [ ] Manure N credit calculated (if applicable)
  [ ] Irrigation water N credit (if applicable)
  [ ] Final N rate determined
  [ ] Urea amount calculated (N ÷ 0.46)

Timing:
  [ ] Crop growth stage appropriate for application
  [ ] Weather forecast checked (rain within 48 hours?)
  [ ] Soil temperature considered (<50°F reduces volatilization)
  [ ] Wind conditions acceptable (low wind preferred)
  [ ] Split application schedule planned (if applicable)
  [ ] Avoid applying before extended dry period

Application Method:
  [ ] Method selected (broadcast, band, inject, foliar)
  [ ] Equipment calibrated for correct rate
  [ ] Spreader pattern checked (overlap, uniformity)
  [ ] Incorporation plan in place (if surface broadcast)
  [ ] NBPT urease inhibitor considered (surface application)
  [ ] Seed-safe distance maintained (if banding)

Product Quality:
  [ ] Urea stored dry and covered
  [ ] No caking or excessive moisture
  [ ] Biuret content <1.0% (especially for foliar/seed-placed)
  [ ] Granule size uniform (spreading pattern)
  [ ] Not mixed with incompatible products

Environmental:
  [ ] Buffer from waterways maintained (state regulations)
  [ ] No application to frozen or saturated soil
  [ ] Nitrate leaching risk assessed (sandy soils, high water table)
  [ ] Application rate within agronomic recommendation
  [ ] Records maintained for nutrient management plan
  [ ] 4R Stewardship: Right source, rate, time, place

Post-Application:
  [ ] Confirm incorporation occurred (rain, irrigation, tillage)
  [ ] Monitor crop for N deficiency symptoms (yellowing)
  [ ] Tissue test at appropriate growth stage
  [ ] Document application (date, rate, method, conditions)
  [ ] Evaluate results at harvest (yield vs N applied)
EOF
}

show_help() {
    cat << EOF
urea v$VERSION — Urea Fertilizer Reference

Usage: script.sh <command>

Commands:
  intro        Urea overview — chemistry, production, forms
  chemistry    Soil chemistry — hydrolysis, nitrification, N cycle
  application  Application methods — broadcast, band, foliar
  rates        Crop-specific N rates and urea calculation
  losses       N loss pathways — volatilization, leaching
  comparison   Nitrogen fertilizer source comparison
  examples     Application scenarios and calculations
  checklist    Application planning checklist
  help         Show this help
  version      Show version

Powered by BytesAgain | bytesagain.com
EOF
}

CMD="-help"

case "$CMD" in
    intro)      cmd_intro ;;
    chemistry)  cmd_chemistry ;;
    application) cmd_application ;;
    rates)      cmd_rates ;;
    losses)     cmd_losses ;;
    comparison) cmd_comparison ;;
    examples)   cmd_examples ;;
    checklist)  cmd_checklist ;;
    help|--help|-h) show_help ;;
    version|--version|-v) echo "urea v$VERSION — Powered by BytesAgain" ;;
    *) echo "Unknown: $CMD"; echo "Run: script.sh help"; exit 1 ;;
esac