tau-all-agent 0.1.0

package/skills/sentry/scripts/search-logs.js

@@ -0,0 +1,234 @@
+#!/usr/bin/env node
+
+import { SENTRY_API_BASE, getAuthToken, fetchJson } from "../lib/auth.js";
+
+const LOG_FIELDS = ["sentry.item_id", "trace", "sentry.severity", "timestamp", "message"];
+
+/**
+ * Parse a Sentry logs explorer URL
+ * Examples:
+ *   https://earendil.sentry.io/explore/logs/?project=123&statsPeriod=14d
+ *   https://sentry.io/organizations/myorg/explore/logs/?project=123
+ */
+function parseLogsUrl(urlStr) {
+  try {
+    const url = new URL(urlStr);
+    const params = url.searchParams;
+    const result = {};
+
+    // Extract org from subdomain (earendil.sentry.io) or path (/organizations/myorg/)
+    const subdomainMatch = url.hostname.match(/^([^.]+)\.sentry\.io$/);
+    if (subdomainMatch && subdomainMatch[1] !== "www") {
+      result.org = subdomainMatch[1];
+    } else {
+      const pathMatch = url.pathname.match(/\/organizations\/([^/]+)\//);
+      if (pathMatch) {
+        result.org = pathMatch[1];
+      }
+    }
+
+    // Extract project ID
+    if (params.has("project")) {
+      result.project = params.get("project");
+    }
+
+    // Extract time period
+    if (params.has("statsPeriod")) {
+      result.period = params.get("statsPeriod");
+    }
+
+    // Extract query
+    if (params.has("logsQuery")) {
+      result.query = params.get("logsQuery");
+    }
+
+    return result;
+  } catch {
+    return null;
+  }
+}
+
+function parseArgs(args) {
+  const options = {
+    org: null,
+    project: null,
+    query: null,
+    period: "24h",
+    limit: 100,
+    json: false,
+    help: false,
+  };
+
+  for (let i = 0; i < args.length; i++) {
+    const arg = args[i];
+
+    if (arg === "--help" || arg === "-h") {
+      options.help = true;
+    } else if (arg === "--json") {
+      options.json = true;
+    } else if (arg === "--org" || arg === "-o") {
+      options.org = args[++i];
+    } else if (arg === "--project" || arg === "-p") {
+      options.project = args[++i];
+    } else if (arg === "--period" || arg === "-t") {
+      options.period = args[++i];
+    } else if (arg === "--limit" || arg === "-n") {
+      options.limit = parseInt(args[++i], 10);
+    } else if (!arg.startsWith("-")) {
+      // Check if it's a Sentry URL
+      if (arg.includes("sentry.io/") && arg.includes("/logs")) {
+        const urlOptions = parseLogsUrl(arg);
+        if (urlOptions) {
+          if (urlOptions.org) options.org = urlOptions.org;
+          if (urlOptions.project) options.project = urlOptions.project;
+          if (urlOptions.period) options.period = urlOptions.period;
+          if (urlOptions.query) options.query = urlOptions.query;
+        }
+      } else if (!options.query) {
+        options.query = arg;
+      }
+    }
+  }
+
+  return options;
+}
+
+function showHelp() {
+  console.log(`Usage: search-logs.js [query|url] [options]
+
+Search for logs in Sentry.
+
+Arguments:
+  query              Search query (e.g., "level:error", "user.id:123")
+  url                Sentry logs explorer URL (extracts org, project, period)
+
+Options:
+  --org, -o <org>    Organization slug (required unless URL provided)
+  --project, -p <p>  Project slug or ID to filter by
+  --period, -t <p>   Time period (default: 24h, e.g., 1h, 7d, 90d)
+  --limit, -n <n>    Max results (default: 100, max: 1000)
+  --json             Output raw JSON
+  -h, --help         Show this help
+
+Search Query Syntax:
+  level:error              Filter by log level (trace, debug, info, warn, error, fatal)
+  message:*timeout*        Search message text
+  trace:abc123             Filter by trace ID
+  project:my-project       Filter by project slug
+
+  Combine filters: level:error message:*failed*
+
+Examples:
+  search-logs.js --org myorg
+  search-logs.js "level:error" --org myorg --project backend
+  search-logs.js "message:*timeout*" --org myorg --period 7d
+  search-logs.js --org myorg --limit 50 --json
+
+  # Use a Sentry URL directly:
+  search-logs.js "https://myorg.sentry.io/explore/logs/?project=123&statsPeriod=7d"
+`);
+}
+
+function formatLogEntry(entry) {
+  const lines = [];
+
+  const ts = entry.timestamp || "N/A";
+  const severity = entry["sentry.severity"] || "info";
+  const message = entry.message || "(no message)";
+  const trace = entry.trace || null;
+
+  // Format timestamp for display
+  let displayTs = ts;
+  try {
+    const date = new Date(ts);
+    if (!isNaN(date.getTime())) {
+      displayTs = date.toISOString().replace("T", " ").slice(0, 19);
+    }
+  } catch {}
+
+  // Color-code severity in output
+  const severityDisplay = `[${severity.toUpperCase().padEnd(5)}]`;
+
+  lines.push(`${displayTs} ${severityDisplay} ${message}`);
+
+  if (trace) {
+    lines.push(`  trace: ${trace}`);
+  }
+
+  return lines.join("\n");
+}
+
+function formatOutput(data) {
+  if (!data.data || data.data.length === 0) {
+    return "No logs found matching your query.";
+  }
+
+  const lines = [];
+  lines.push(`Found ${data.data.length} log entries:\n`);
+
+  for (const entry of data.data) {
+    lines.push(formatLogEntry(entry));
+    lines.push("");
+  }
+
+  return lines.join("\n").trimEnd();
+}
+
+async function main() {
+  const args = process.argv.slice(2);
+  const options = parseArgs(args);
+
+  if (options.help) {
+    showHelp();
+    process.exit(0);
+  }
+
+  if (!options.org) {
+    console.error("Error: --org is required");
+    console.error("Run with --help for usage information");
+    process.exit(1);
+  }
+
+  const token = getAuthToken();
+
+  // Build query parameters
+  const params = new URLSearchParams();
+  params.set("dataset", "logs");
+  params.set("statsPeriod", options.period);
+  params.set("per_page", Math.min(options.limit, 1000).toString());
+  params.set("sort", "-timestamp");
+
+  // Add fields
+  for (const field of LOG_FIELDS) {
+    params.append("field", field);
+  }
+
+  // Build search query
+  const queryParts = [];
+  if (options.project) {
+    queryParts.push(`project:${options.project}`);
+  }
+  if (options.query) {
+    queryParts.push(options.query);
+  }
+  if (queryParts.length > 0) {
+    params.set("query", queryParts.join(" "));
+  }
+
+  const url = `${SENTRY_API_BASE}/organizations/${encodeURIComponent(options.org)}/events/?${params.toString()}`;
+
+  try {
+    const data = await fetchJson(url, token);
+
+    if (options.json) {
+      console.log(JSON.stringify(data, null, 2));
+    } else {
+      console.log(formatOutput(data));
+    }
+  } catch (err) {
+    console.error("Error:", err.message);
+    process.exit(1);
+  }
+}
+
+main();

package/skills/update-changelog/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: update-changelog
+description: "Update CHANGELOG.md following Keep a Changelog (https://keepachangelog.com/en/1.1.0/)"
+---
+
+# Update Changelog (Keep a Changelog)
+
+Update the repository changelog with user-facing changes that landed since the last release.
+
+This skill is **explicitly based on** Keep a Changelog v1.1.0:
+https://keepachangelog.com/en/1.1.0/
+
+## Rules (non-negotiable)
+
+- **Do not add installation instructions** to the changelog.
+- Only include **notable, user-visible** changes.
+- **Never add raw commit SHAs**. Prefer PR numbers (e.g. `#123`) and/or issue IDs.
+- Add entries **only under `Unreleased`** (unless you are also cutting a release and moving items into a versioned section).
+- Preserve the project’s existing formatting where possible, but align new content to Keep a Changelog.
+
+## File to edit
+
+- Prefer `CHANGELOG.md`.
+- If missing, use `CHANGELOG`.
+
+## Step-by-step
+
+### 1) Identify the baseline (last released version)
+
+Pick a baseline tag/version to compare against.
+
+- If the project uses git tags:
+
+```bash
+git describe --tags --abbrev=0
+```
+
+- If tags are missing/inconsistent, use the newest release section in the changelog as the baseline.
+
+### 2) Collect candidate changes
+
+Gather commits/PRs since the baseline and identify user-facing changes.
+
+```bash
+git log <baseline>..HEAD --oneline
+```
+
+If you have PR metadata available (e.g., via GitHub), use it to improve wording and include PR numbers.
+
+### 3) Ensure the changelog structure matches Keep a Changelog
+
+At minimum, Keep a Changelog expects:
+
+- A top `Unreleased` section
+- Optional subsections under `Unreleased` (and under each release):
+  - `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`
+
+If `Unreleased` exists but is missing subsections, create only the ones you need for the new entries.
+
+### 4) Add entries under `Unreleased`
+
+Classify each change into one of the standard headings:
+
+- **Added**: new features
+- **Changed**: changes in existing functionality (including behavior changes)
+- **Deprecated**: soon-to-be removed features
+- **Removed**: removed features
+- **Fixed**: bug fixes
+- **Security**: vulnerability fixes
+
+Write entries as **consistent bullet points**:
+
+- Start with the category verb (Added/Changed/Deprecated/Removed/Fixed/Security) _only via the section heading_, not inside each bullet.
+- Each bullet should be a single, past-tense sentence fragment.
+- Prefer: `- Added … (#123)` / `- Fixed … (#456)` style (consistent grammar).
+
+### 5) Keep it user-facing
+
+Include:
+
+- visible behavior changes
+- new CLI flags/API additions
+- bug fixes with clear impact
+- security fixes (without leaking sensitive details)
+
+Exclude (unless they change user-visible behavior):
+
+- pure refactors
+- internal cleanup
+- dependency bumps with no user impact
+- typo-only doc edits
+
+### 6) Links (only if the file already uses them)
+
+Keep a Changelog commonly includes link references at the bottom, e.g.:
+
+- `[Unreleased]: <compare link>`
+- `[1.2.3]: <compare link>`
+
+If the project already uses these, update them accordingly (don’t introduce link refs if the changelog doesn’t use them).
+
+## Example (consistent Keep a Changelog format)
+
+```markdown
+## [Unreleased]
+
+### Added
+
+- Added widget-level caching for faster dashboard loads. (#123)
+
+### Changed
+
+- Changed default retry policy to exponential backoff. (#140)
+
+### Fixed
+
+- Fixed crash when importing a config with empty sections. (#155)
+
+## [1.4.0] - 2026-02-01
+
+### Added
+
+- Added support for exporting reports as CSV. (#110)
+
+### Fixed
+
+- Fixed incorrect timezone handling in scheduled jobs. (#117)
+```
+
+## Quality checklist
+
+- Entries are under **`Unreleased`** and categorized correctly.
+- Wording is consistent (same tense/style across bullets).
+- No installation instructions, no commit SHAs.
+- The changelog remains easy to scan and matches the repo’s established conventions.

package/skills/web-design/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: web-design
+description: "Design and implement distinctive, production-ready web interfaces with strong aesthetic direction. Use when asked to create or restyle web pages, components, or applications (HTML/CSS/JS, React, Vue, etc.)."
+---
+
+# Web Design Skill
+
+Design and implement memorable web interfaces with a clear, intentional aesthetic. The output must be real, working code — not just mood boards. This skill is about **design thinking + execution**: every visual choice should be rooted in purpose and context.
+
+## When to Use
+
+Use this skill when the user wants to:
+
+- Create a new web page, landing page, dashboard, or app UI
+- Design or redesign frontend components or screens
+- Improve typography, layout, color, motion, or overall visual polish
+- Convert a concept or brief into a high‑fidelity, coded interface
+
+## Inputs to Gather (or Assume)
+
+Before coding, identify:
+
+- **Purpose & audience**: What problem does this UI solve? Who uses it?
+- **Brand/voice**: Any reference brands, tone, or visual inspiration?
+- **Technical constraints**: Framework, library, CSS strategy, accessibility, performance
+- **Content constraints**: Required copy, assets, data, features
+
+If the user did not provide this, ask **2–4 targeted questions**, or state reasonable assumptions in a short preface.
+
+## Design Thinking (Required)
+
+Commit to a **single, bold aesthetic direction**. Name it and execute it consistently. Examples:
+
+- Brutalist / raw / utilitarian
+- Editorial / magazine / typographic
+- Luxury / refined / minimal
+- Retro‑futuristic / cyber / neon
+- Art‑deco / geometric / ornamental
+- Handcrafted / organic / textured
+
+**Avoid generic AI aesthetics.** No “default” fonts, color schemes, or stock layouts.
+
+Before writing code, define the system:
+
+1. **Visual direction** — one sentence that describes the vibe
+2. **Differentiator** — what should be memorable about this UI?
+3. **Typography system** — display + body fonts, scale, weight, casing
+4. **Color system** — dominant, accent, neutral; define as CSS variables
+5. **Layout strategy** — grid rhythm, spacing scale, hierarchy plan
+6. **Motion strategy** — 1–2 meaningful interaction moments
+
+If the user wants code only, skip the explanation but still follow this internally.
+
+## Implementation Principles
+
+- **Working code**: HTML/CSS/JS or framework code that runs as‑is
+- **Semantic & accessible**: headings, labels, focus states, keyboard nav
+- **Responsive**: fluid layouts, breakpoints, responsive typography
+- **Tokenized styling**: CSS variables for colors, spacing, radii, shadows
+- **Modern layout**: prefer CSS Grid/Flex, avoid brittle positioning hacks
+
+## Aesthetic Guidelines
+
+### Typography
+
+- Typography should define the voice of the design
+- Avoid default fonts (Inter, Roboto, Arial, system stacks)
+- Use a **distinct display font** + a **refined body font**
+- Implement a clear hierarchy (size, weight, spacing, casing)
+
+### Color & Theme
+
+- Commit to a palette with a strong point‑of‑view
+- Avoid timid, overused gradients (e.g., purple‑to‑pink on white)
+- Use contrast intentionally and check legibility
+
+### Composition & Layout
+
+- Encourage asymmetry, scale contrast, overlap, or grid breaks
+- Use negative space deliberately (or controlled density if maximalist)
+- Create visual rhythm and hierarchy through spacing and alignment
+
+### Detail & Atmosphere
+
+- Add texture or depth when appropriate (noise, grain, subtle patterns)
+- Use shadows/glows only when they serve the concept
+- Consider unique borders, masks, or clip‑paths for distinct shapes
+
+### Motion & Interaction
+
+- Use motion sparingly but meaningfully
+- Favor one standout interaction over many tiny ones
+- Honor `prefers-reduced-motion`
+
+## Avoid
+
+- Cookie‑cutter hero + 3 card layouts
+- Generic gradients and default font choices
+- Unmotivated decorative elements
+- Overly flat, characterless component libraries
+
+## Deliverables
+
+- Provide full code with file names or component boundaries
+- Make customization easy with CSS variables or config objects
+- If assets are needed, provide inline SVGs or generative CSS patterns
+
+## Quality Checklist (Self‑validate)
+
+- Aesthetic direction is unmistakable
+- Typography feels intentional and expressive
+- Layout and spacing are consistent and purposeful
+- Color palette feels cohesive and legible
+- Interactions enhance the experience without clutter
+- Code runs as provided and is production‑ready
+
+**Remember:** a design is only as strong as its commitment. Choose a direction and execute it relentlessly.