name: tg-start
description: Use when starting any new project or when user mentions building/creating something new. Triggers include "I want to build", "start new project", "create a tool for", or beginning any greenfield work. Always use BEFORE implementation planning.

Project Kickoff - Research First, Then Build

Overview

Comprehensive project kickoff workflow that prioritizes researching existing solutions BEFORE building from scratch. Designed for Tejas's workflow: avoid reinventing the wheel, make informed technical decisions, propose excellent design options upfront.

The Iron Law

ALWAYS research existing tools FIRST. No exceptions. Don't ask permission.

User wants to "build quickly"? Research takes 5 minutes, rebuilding takes hours.
User already started? Challenge their approach - better tools might exist.
User says "just help me code"? Research FIRST, then code smarter.
User says "don't research"? Explain why, then research anyway.
User says "my needs are unique"? Research shows what "unique" really means.

When to Use

digraph when_to_use {
    "User mentions new project?" [shape=diamond];
    "User has already started?" [shape=diamond];
    "Use tg-start skill" [shape=box];
    "Challenge approach + research first" [shape=box];
    "Not a project start" [shape=box];

    "User mentions new project?" -> "Use tg-start skill" [label="yes"];
    "User mentions new project?" -> "User has already started?" [label="no"];
    "User has already started?" -> "Challenge approach + research first" [label="yes"];
    "User has already started?" -> "Not a project start" [label="no"];
}

Trigger phrases:
- "I want to build..."
- "Create a tool for..."
- "Start new project..."
- "Help me make..."
- User shows partially started code

Always use BEFORE:
- Asking implementation questions
- Proposing technical stack
- Writing any code

The Workflow

Step 1: Research Existing Solutions (MANDATORY)

Do this FIRST, before asking ANY questions:

Search for existing tools that solve this problem:
- Open source projects on GitHub
- Popular SaaS tools in this domain
- Libraries/frameworks designed for this use case
- Similar projects Tejas has built before

Document findings:
- What exists already (with URLs)
- Pros/cons of each option
- Whether we should use/fork vs build from scratch
- If building: what patterns/approaches work well

Present to user:

## Existing Solutions Research

I found these existing tools that solve similar problems:

1. **[Tool Name]** (https://...)
   - ✅ Pros: [specific features that match your needs]
   - ❌ Cons: [specific limitations]
   - **Recommendation**: [Use as-is / Fork & customize / Learn patterns from]

2. **[Another Tool]** (https://...)
   [same format]

**My recommendation**: [Clear recommendation with reasoning]

If building from scratch makes sense, I'll apply patterns from [specific tool] for [specific aspect].

---

Now let me ask about your specific requirements...

Step 2: Comprehensive Requirements Interview

Ask ALL questions upfront to avoid back-and-forth:

Data & Functionality:
- Where does data come from? (file upload, API, manual entry, static)
- What data points matter most?
- What actions can users take?
- Any existing data format to work with?

Platform & Constraints:
- Desktop only or mobile-responsive?
- Any performance concerns? (large datasets, real-time updates)
- Privacy needs? (can data be client-side only?)
- Hosting preference? (default: GitHub Pages)

Design & UX:
- Any aesthetic inspiration or preferences?
- Information density preference? (show everything vs progressive disclosure)
- Must-have vs nice-to-have features for MVP?

Technical:
- Any existing codebase/tech decisions already made?
- Should we use existing tools/libraries found in research?
- Export/sharing needs? (JSON, PNG, PDF, URLs)

Step 3: Propose Architecture Options

Based on research + requirements, present 2-3 architectural approaches:

## Architecture Options

**Option A: [Descriptive Name]** (Recommended)
- **Approach**: [High-level description]
- **Stack**: [Specific technologies]
- **Pros**: [Outcome-focused benefits with analogies]
  - Fast: "Loads in 50ms vs 200ms with framework"
  - Simple: "One HTML file, no build tools, easy to maintain"
  - Works for this use case: [Why it fits THIS project]
- **Cons**: [Tradeoffs with real implications]
  - Limited: "Manual data entry only, not scalable to APIs later"
- **Example**: Like your [past project] which loads fast and is easy to update

**Option B: [Alternative]**
- **Approach**: [Different approach]
- **Stack**: [Different technologies]
- **Pros**: [Why you'd choose this instead]
- **Cons**: [What you'd sacrifice]
- **When to choose**: [Specific scenarios where B beats A]

**My recommendation**: Option A because [outcome-focused reasoning for THIS project].

Use analogies + outcomes (not just tech specs):
- ❌ "React has virtual DOM and component lifecycle"
- ✅ "React loads 200ms, needs build tools (5min setup + commands). Vanilla JS loads 50ms, edit one file. For your GitHub Pages projects, vanilla is simpler unless you have 10+ interactive components."

Step 4: Invoke Theme Research Skill

REQUIRED: Call /tg:themes skill to research and propose design options.

Never propose themes yourself - the themes skill researches 2026 best practices and creates comprehensive proposals with:
- 4-6 distinct theme options
- Color palettes for light/dark mode
- Typography choices
- Layout approaches
- Real examples/references

Step 5: Setup & Next Steps

Once user picks architecture + theme:

1. Initialize project structure
2. Create directory: ~/Claude/[project-name]
3. Init git repository

4. Create README.md and CLAUDE.md skeletons

5. Set up GitHub Pages (if applicable)

6. Create repo, enable Pages

7. Provide deployment URL

8. Create implementation plan

9. MVP features first
10. Phase-by-phase approach

11. Clear success criteria

12. Start building

13. Begin with MVP
14. Use patterns from researched tools
15. Apply chosen theme

Common Rationalizations (STOP SIGNS)

Red Flags - STOP and Research First

If you're thinking ANY of these, STOP and go to Step 1:

• "Let me ask what data source..."
• "What tech stack do you want..."
• "Should I help you continue with..."
• "Let me propose some options..."

ALL of these mean: You skipped research. Go to Step 1.

Success Criteria

✅ Research completed - User sees what exists, makes informed decision
✅ Requirements clear - All questions answered upfront, no back-and-forth later
✅ Tradeoffs explained - User understands implications with analogies + outcomes
✅ Theme research done - /tg:themes invoked, user picks from 4-6 options
✅ Setup complete - Project initialized, GitHub Pages ready, ready to build

Example: Good vs Bad Start

❌ BAD (No Research)

User: "I want to build a flight tracker"

Claude: "Great! Let me ask some questions:
1. Where does data come from?
2. What visualizations do you want?
3. Desktop or mobile?"

Problem: Jumped straight to questions, didn't research existing flight trackers first.

✅ GOOD (Research First)

User: "I want to build a flight tracker"

Claude: "Let me research existing flight tracking tools first to understand what's already out there and what patterns work well...

Existing Solutions Research

I found these relevant tools:

1. App in the Air (https://...)
2. ✅ Beautiful route maps, stats dashboard, works offline
3. ❌ Mobile-only, no web version, can't export data

4. Pattern: Card-based flight history with visual timeline

5. FlightDiary (GitHub - MIT license)

6. ✅ Open source, privacy-first, CSV import/export
7. ❌ Basic UI, limited visualizations
8. We could fork this as a starting point

Recommendation: Build from scratch using FlightDiary's CSV format (compatibility) + App in the Air's visual design patterns.

Now let me ask about your specific needs:

Data & Functionality:
- Do you have existing flight history data? (airline CSV export, manual entry, other?)
- What insights matter most? (route map, stats over time, airline breakdown?)
- Should data stay 100% client-side for privacy?

[...continue comprehensive interview...]"

Why better: User sees what exists, Claude learned UX patterns, informed questions.

Real-World Impact

Before this skill: Claude asked generic questions, missed existing tools, proposed suboptimal architectures, multiple rounds of "actually I meant..."

After this skill: Research discovers better approaches, comprehensive upfront questions, informed technical decisions, build right thing first time.

Time saved per project: 2-4 hours of rework avoided.