Small, local-first browser utilities published at https://tools.treble.dev.

• 100% client-side tools
• no accounts, tracking, or uploads
• simple static files that run on GitHub Pages
• useful pages that are easy to find via search
• prioritize broad non-technical tasks users are often forced to pay for
• avoid low-level developer-only utilities unless mainstream demand is clearly validated

• tools/print-without-black.html — convert PDF blacks to printable color when a black cartridge is empty
• tools/pdf-redactor.html — permanently redact PDF regions in the browser
• tools/video-trimmer-gif-exporter.html — trim local videos and export GIF/WebP/MP4 clips

• tools/index.html — landing page for the tool collection
• tools/common.css — shared tokens and UI primitives used by tool pages
• tools/template.html — starter template for new tool pages
• tools/print-without-black.html — print-without-black tool entry page
• tools/print-without-black/style.css — print-without-black styles
• tools/pdf-redactor.html — PDF redaction tool entry page
• tools/video-trimmer-gif-exporter.html — video trimmer tool entry page
• tools/pdf-redactor/main.js — PDF redactor logic
• tools/pdf-redactor/style.css — PDF redactor styles
• specs — feature notes and planning docs that are still useful to keep in-repo

There is no build step. Open files in /tools/*.html directly in a browser or serve the folder as a static site.

Third-party browser libraries are loaded from committed files in tools/vendor, not external CDNs.

This repository uses a multi-stage workflow to move from idea discovery to shipped tools.

• Workflow: .github/workflows/researcher.md
• Purpose: find browser-first, paywall-replacement opportunities for broad audiences that are not duplicates of existing specs/issues.
• Output: proposal issues with evidence, scope rationale, and browser API feasibility.

• Workflow: .github/workflows/product-architect.md
• Trigger: approved issue labels.
• Purpose: generate/update planning artifacts under specs, including spec.md and tasks.md.
• Output: planning PRs that define what should be built.

• Workflow: .github/workflows/lead-developer.md
• Trigger: changes to specs/**/spec.md or specs/**/tasks.md on main.
• Purpose: implement approved scope into tool pages and assets under tools.
• Output: implementation PRs for human review (not direct merge automation).

• If spec or task files change, the Lead Developer workflow runs again to update implementation accordingly.
• PR guard: .github/workflows/spec-tool-alignment.yml checks that spec/task changes are accompanied by relevant tool/vendor/package updates.
• Intentional planning-only PRs can use [spec-only] in PR title or body to bypass the alignment check.

• Keep runtime dependencies in tools/vendor so tools remain portable and reusable across workflows.
• Use npm only as a development-time dependency management workflow.
• After updating dependency versions, run the vendor sync workflow and commit the resulting changes in package.json, package-lock.json, and tools/vendor.

When adding tools:

• keep processing in the browser
• prefer vanilla HTML, CSS, and JavaScript
• start from tools/template.html
• include tools/common.css and keep only tool-specific styles in /tools/[feature-slug]/style.css
• load third-party runtime assets from the shared /tools/vendor/ directory
• avoid duplicating vendor runtime files inside tool-specific folders when shared copies already exist
• prioritize mainstream tasks with clear paid-tool friction (paywall, watermark, export lock, subscription cap)
• avoid niche developer helpers (for example Base64/JWT/cron tools) unless evidence shows broad non-technical demand
• use descriptive titles, meta descriptions, and clear how-to content
• include practical controls such as undo, reset, preview, color selection, or quality settings when relevant