npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

to-the-t

v0.1.0

Published

The PM you never hired. Get the right spec before you code.

Downloads

54

Readme

TTT (TO THE T)

Get the right spec the first time. Then build it reliably.

You know the feeling. You have an idea, you open Cursor, and three weeks later you realize you built the wrong thing. The market has 50 competitors, your user was wrong, or you shipped 12 features when you needed 3.

TTT fixes that. It's the product manager you never hired — for solo vibecoders who ship fast and want to ship right.

npx to-the-t@latest

"I had the idea on Monday, TTT killed it by Tuesday, suggested something better by Wednesday, and I was coding by Thursday."


The Problem

The beginning is easy. The end is hard.

Every vibecoder knows this. You describe what you want, AI generates code, and the first few prompts create something that looks real. Then you hit production. Authentication breaks. The database schema is wrong. You realize nobody actually wants what you built.

Tools like GSD solve the "how do I build reliably" problem. GSD is your program manager — it keeps Claude on track, prevents context rot, and makes sure your code doesn't fall apart.

But nothing solves the "should I build this at all" problem.

TTT is your product manager. It answers the questions you skip: Is this idea good? Who's the user? What's the smallest thing I can ship that people actually want?

Use TTT to figure out what to build. Use GSD to build it reliably.

Your idea
    │
    ▼
  TTT → Validated spec (13 files)
    │
    ▼
  GSD → Reliable execution
    │
    ▼
  You → Ship something people actually want

How It Works

One command. Five phases. You talk, TTT thinks, argues back, researches, and hands you files your coding agent can build from.

1. Clarify

You describe your idea. TTT narrows it until it's actually specific.

You:  "AI tool for creators"
TTT:  "That's vague. There are 50+ creator tools. YouTube? Instagram? 
       What kind of creators? What's their actual pain?"
You:  "YouTube creators who want to make Shorts from long videos"
TTT:  "Better. Indie creators under 10K subs, or established ones?"

Most vibecoders skip this. They jump straight to building. Three weeks later they realize they built for the wrong person.

2. Validate

TTT spawns two research agents in parallel:

Market Researcher — Analyzes competitors, finds whitespace, checks timing. Uses real frameworks (Porter's Five Forces, SWOT, Business Model Canvas), not vibes.

User Researcher — Maps user needs, identifies core desires, builds Jobs To Be Done with functional + emotional layers.

Then TTT gives you a straight answer:

TTT:  "The space has 4 direct competitors. Two are bloated. One is 
       expensive. Nobody is targeting indie creators under 10K subs. 
       Timing is good — YouTube Shorts API just opened up.

       Your call:
       1. Build as-is
       2. Narrow to creators in education niche (strongest whitespace)
       3. Pivot to thumbnail generation (highest-pain job)
       4. Your own direction"

If the idea is bad, TTT says so. It won't carry a flawed premise into a spec just to be nice.

3. Define

Lock in exactly who, exactly what problem, and exactly what solution.

TTT enforces a scope guard here. Maximum 5 features for v1. Every feature must map to a real user job. Everything else gets parked for v2.

TTT:  "That's 7 features. For a solo vibecoder shipping in 2 weeks, 
       5 is the ceiling. Which 2 are we parking for v2?"

This is where most weekend projects die — not from lack of skill, but from trying to build everything at once. TTT won't let you do that.

4. Specify

TTT spawns 4 agents in two waves:

Wave 1: Product Detailer maps every user journey, specifies every feature with edge cases, builds a screen inventory, defines all states (empty, loading, error, success).

Wave 2 (parallel): Tech Architect picks the exact stack with rationale. Design Advisor creates UX philosophy and component system. Test Generator writes acceptance tests for every feature.

Then TTT runs a completeness check. Every feature has tests? Every screen has design guidance? No scope leak? It catches drift before you see the output.

5. Launch Plan (optional)

Distribution, metrics, v2 triggers. Skip it if you just want to ship.


Vibe It

Don't want the full process? Say "Vibe it!!" after the first phase (or anytime) and TTT makes all remaining decisions for you.

It picks the most attractive market angle, the most specific user, the sharpest problem, and the smallest viable solution. States every assumption upfront. Generates all spec files immediately.

Speed over depth. You can always revise after.


What You Get

TTT generates a directory of markdown files. Every file is human-readable and coding-agent-ready.

ttt-spec/
  ttt_state.json           # Session state, decisions, pivot history
  clarification.md         # Product thesis, user, platform, constraints
  market_research.md       # Porter's, SWOT, BMC, whitespace, timing
  user_research.md         # Maslow's, Reiss, JTBD, behavior patterns  
  definition.md            # Exact user, problem, solution, scope guard
  solution.md              # User journeys, feature specs, edge cases
  tech_architecture.md     # Stack, data models, API routes
  design_guideline.md      # UX philosophy, references, components
  test_eval.md             # Acceptance tests, benchmarks, success criteria
  coding_agent_prompt.md   # Copy-paste into Cursor/Claude Code. Day 0.
  blueprint.md             # File manifest and reading order
  versions.md              # Changelog, V2 parking lot, scope changes
  launch.md                # Distribution and metrics (optional)

Hand coding_agent_prompt.md to your coding agent. It references everything else. Start building.


TTT + GSD

They're complementary. TTT is the product manager. GSD is the program manager.

| | TTT | GSD | |---|---|---| | Answers | What should I build? | How do I build it reliably? | | When | Before you write code | While you write code | | Output | Validated spec | Working software | | Prevents | Building the wrong thing | Code falling apart at scale |

Workflow:

/ttt-new-idea           → Figure out what to build
                        → Get spec files

/gsd-new-project        → Initialize GSD with your spec
/gsd-plan-phase 1       → Plan the work
/gsd-execute-phase 1    → Build it reliably

You can use TTT without GSD, or GSD without TTT. But together? You get the right spec and reliable execution.


Why TTT Is Different

It says no. If your idea doesn't hold up against market reality, TTT tells you before you waste a month building it. Most tools validate everything. TTT has opinions.

Real PM frameworks. Not "analyze the market." Porter's Five Forces. SWOT per competitor. Business Model Canvas. Jobs To Be Done with three layers. The same frameworks a senior PM would use — without you needing to know them.

Scope guard with teeth. Maximum 5 features for v1. Every feature must map to a real user job. TTT pushes back if you try to add more. Deferred features go to a V2 parking lot, not into the void.

State that survives crashes. ttt_state.json tracks every decision, every assumption, every pivot. Close the session, come back tomorrow, TTT picks up exactly where you left off.

Pivots without starting over. Change direction and TTT evaluates what's still valid. Same market, different angle? Keep the research, redo the definition. New market entirely? Re-research only what changed.


Getting Started

npx to-the-t@latest

The installer prompts you to choose:

  1. Runtime — Claude Code, Cursor, Windsurf, etc.
  2. Location — Global (all projects) or local (current project only)

Then:

/ttt-new-idea

Describe your idea. TTT takes it from there.


Commands

| Command | What it does | |---------|-------------| | /ttt-new-idea | Full 5-phase flow: clarify → validate → define → specify → launch | | /ttt-vibe-it | Fast mode. TTT makes all decisions. Get spec files immediately. | | /ttt-resume | Pick up where you left off | | /ttt-progress | Where am I? What's next? | | /ttt-help | Show all commands |


Who This Is For

Solo vibecoders who:

  • Have ideas but keep building the wrong thing
  • Ship fast but want to ship right
  • Don't want to play enterprise PM theater
  • Want honest feedback, not validation

If you're the kind of person who opens Cursor before thinking through whether the idea is good — TTT is for you.


Status

Under active development. Architecture designed. Agent prompts being built.


Philosophy

Respect the builder's momentum. Every question must earn its place. Done and useful beats complete and bloated.

Be honest. If the data is weak, say so. If the idea is bad, say so. If an assumption was made, state it.

Be opinionated. TTT has a point of view. It recommends one option, explains why, and lets you override.

Protect v1. Solo builders overbuild. TTT aggressively recommends the smallest viable version. Good ideas that aren't essential get parked, not lost.


License

MIT


Your coding agent is powerful. TTT makes sure it builds the right thing.