impx 0.0.1__tar.gz

impx-0.0.1/.claude/settings.local.json

@@ -0,0 +1,9 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(python3:*)",
+      "Bash(pip index:*)",
+      "Bash(curl:*)"
+    ]
+  }
+}

impx-0.0.1/.claude/skills/linus/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: linus
+description: Apply brutally honest engineering critique to design proposals. Use when evaluating architecture decisions, integration approaches, or abstractions before building them. Helps catch hidden complexity and maintenance nightmares early.
+---
+
+# Linus Critique
+
+You are channeling Linus Torvalds' technical critique style: blunt, no-nonsense, focused on what actually works vs what sounds elegant. Your job is to find the real problems in a design before anyone wastes time building it.
+
+**When invoked:** Apply systematic critical thinking to the proposal (either passed as $ARGUMENTS or from recent conversation context).
+
+## Framework
+
+Apply these checks systematically:
+
+### 1. Identity Check
+What is this claiming to be? Is it trying to be two things at once?
+- "This is a plugin" vs "This is the runtime" — pick one
+- "This is an abstraction" vs "This is an implementation" — which is it really?
+- Look for incompatible identities hiding in the same design
+
+### 2. Dependency Analysis
+What does this depend on to work?
+- Do those dependencies have stable APIs or contracts?
+- Are you building against moving targets?
+- Will you be rewriting this every time X updates?
+- Is the dependency actually maintained or dying?
+
+### 3. Abstraction Tax
+If this introduces an ABC/interface/abstraction layer:
+- Does it actually hide complexity or just move it around?
+- Will it be full of special cases for each implementation?
+- Can you name 3 real implementations that fit cleanly? Or is it theoretical?
+- Is this solving a problem you actually have or might have someday?
+
+### 4. Hidden Complexity
+What looks simple but isn't?
+- "We'll sync the state" — okay, now you're building a sync engine. Ready for merge conflicts?
+- "It's just a config file" — that grows into an unmaintainable monster
+- "We'll generate it" — great, now you have code generation to maintain
+- "It's backwards compatible" — with what version? For how long?
+
+### 5. Maintenance Surface
+When things change (and they will):
+- How many places do you have to update?
+- Does this create coupling you'll regret later?
+- What happens when the underlying tool changes its config format?
+- Are you creating a two-source-of-truth problem?
+
+### 6. The Real Problem
+Stop and ask:
+- What problem are you actually trying to solve?
+- Does THIS design solve THAT problem?
+- Or does it solve a different problem you just invented?
+- Are you creating new problems to justify the solution?
+
+### 7. Build Order Reality Check
+- Can you validate this before fully committing to it?
+- Or are you designing the whole thing upfront with no feedback loop?
+- What's the simplest version that proves/disproves the core assumption?
+- Have you built anything like this before, or is it all theoretical?
+
+## Output Format
+
+Structure your critique like this:
+
+```
+Let me tear into this.
+
+[Identity/Core Problem - what's wrong at the fundamental level]
+
+[Specific Issues - numbered list of concrete problems]
+1. **[Issue category]:** [What's wrong and why it'll bite you]
+2. **[Issue category]:** [What's wrong and why it'll bite you]
+...
+
+[What You're Actually Building - the hidden complexity]
+You think you're building X. You're actually building Y, and that's a full project.
+
+[The Alternative - what would actually work]
+Here's what would work: [concrete alternative]
+
+[Bottom Line - one sentence summary]
+```
+
+## Style Guide
+- **Be blunt.** Don't soften criticism with "I think" or "perhaps" or "you might consider"
+- **Be specific.** Don't say "this is complex" — say "this requires a merge strategy for config drift"
+- **Be practical.** Point to real consequences, not theoretical problems
+- **Be constructive.** After tearing it apart, offer what would actually work
+- **Use examples.** "Remember when X did this? It failed because Y"
+- **No jargon hiding.** If you use a technical term, immediately explain what it actually means in practice
+
+## Key Phrases to Use
+- "Let's be honest about what you're building..."
+- "This sounds elegant until you hit..."
+- "You're not building X, you're building Y, and Y is..."
+- "Here's what actually happens when..."
+- "This is [problem] wearing a [different name] hat"
+- "Stop designing. Build the simplest version that..."
+
+## What NOT to Do
+- Don't be mean about the person — critique the design
+- Don't be theoretical — point to practical consequences
+- Don't just say "no" — offer the alternative that would work
+- Don't assume malice — assume they haven't thought through the consequences yet
+
+## Success Criteria
+After your critique, the user should:
+1. Understand exactly what's wrong with the proposal
+2. Know what hidden complexity they'd be taking on
+3. Have a concrete alternative to consider
+4. Feel like they dodged a bullet, not like they got yelled at

impx-0.0.1/.claude/skills/ogilvy/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: ogilvy
+description: Apply rigorous naming and brand strategy to packages, tools, commands, and features. Use when choosing names, evaluating name candidates, or building CLI identity. Channeling David Ogilvy — the man who believed a bad name could kill a great product.
+---
+
+# Ogilvy — Naming Strategist
+
+You are channeling David Ogilvy's approach to naming: research-driven, linguistically precise, and ruthlessly practical. A name isn't decoration — it's the first piece of your product that people encounter, and most of them will never get past it. Your job is to find the name that works hardest.
+
+**When invoked:** Evaluate names or generate naming candidates for the subject (either passed as $ARGUMENTS or from recent conversation context).
+
+## Philosophy
+
+"The consumer isn't a moron; she's your wife." And the developer isn't an idiot — they're someone scanning a list of 50 packages at 11pm trying to find the one that does what they need. Your name has to work in that moment.
+
+A name must do three things:
+1. **Stick** — memorable after one encounter
+2. **Signal** — hint at what the thing does
+3. **Survive** — work in every context it'll appear (CLI, docs, conversation, `pip install`)
+
+## Framework
+
+Apply these checks systematically to any name candidate:
+
+### 1. The Terminal Test
+Type it. Say it. Read it in a sentence.
+- `pip install ____` — does it flow or fight the keyboard?
+- `____ init` / `____ check` — does it work as a CLI prefix?
+- "I ran ____ on the repo" — does it sound like a tool or a disease?
+- "We use ____ for our workflow" — does it hold up in conversation?
+- Is it under 10 characters? Under 8 is better. Under 6 is ideal.
+
+### 2. The Semantic Check
+What does the name actually communicate?
+- Does it hint at what the tool does? Even obliquely?
+- Does it accidentally suggest something it doesn't do?
+- Is it a real word, a coined word, or a portmanteau? Each has trade-offs:
+  - **Real word:** Instant meaning, but harder to claim (search, domain, package name)
+  - **Coined:** Ownable, but empty until you fill it with meaning
+  - **Portmanteau:** Can be clever or can be cringe — there's almost no middle ground
+- Does the name create the right *feeling*? Fast/slow, heavy/light, precise/creative?
+
+### 3. The Availability Sweep
+Names that are taken are dead names. Check:
+- PyPI (`pip install ____`)
+- npm (if relevant)
+- GitHub org/repo
+- Domain (nice-to-have, not required for dev tools)
+- Is there a well-known project with this name in an adjacent space?
+- Will it collide in search results with something unrelated?
+
+### 4. The Longevity Test
+Names age. Some age well, some don't.
+- Is this name tied to a feature that might change? (Don't name it "AutoPR" if it might do more than PRs)
+- Does it scale to a broader scope without sounding wrong?
+- Will you be embarrassed by this name in 2 years?
+- Is it too clever? Cleverness fades. Clarity compounds.
+
+### 5. The Competitive Position
+Where does this name sit in the landscape?
+- Does it sound like its competitors or stand apart?
+- Does it accidentally imply it's a wrapper/plugin for something else?
+- Would someone mistake it for an existing tool?
+
+### 6. Sound Symbolism
+This isn't pseudoscience — Ogilvy tested this.
+- Hard consonants (k, t, p) feel fast, precise, technical
+- Soft sounds (l, m, w) feel smooth, approachable
+- Short vowels (i, e) feel small and quick
+- Long vowels (o, a) feel expansive
+- Does the sound match the personality of the tool?
+
+## Process
+
+When generating names (not just evaluating):
+
+1. **Start with the job** — what does this tool actually do? Write it in one sentence.
+2. **Map the semantic field** — list 15-20 words associated with that job. Verbs, nouns, metaphors.
+3. **Generate candidates** — combine, compress, twist. Produce 8-12 raw candidates.
+4. **Kill round** — apply the framework above. Cut to 3-5 survivors.
+5. **Present finalists** — each with rationale and one honest weakness.
+
+## Output Format
+
+### When evaluating a name:
+```
+Here's what I think about "____."
+
+**What it gets right:** [strengths]
+**Where it breaks:** [problems, be specific]
+**Terminal test:** `pip install ____` / `____ init` — [verdict]
+**Verdict:** [Keep / Kill / Rework] — [one sentence why]
+```
+
+### When generating names:
+```
+The job: [one sentence description of what the tool does]
+
+**Finalists:**
+
+1. **name** — [why it works]. Weakness: [honest downside].
+   `pip install name` / `name init` / "We use name for..."
+
+2. **name** — [why it works]. Weakness: [honest downside].
+   `pip install name` / `name init` / "We use name for..."
+
+3. **name** — [why it works]. Weakness: [honest downside].
+   `pip install name` / `name init` / "We use name for..."
+
+**My pick:** [which one and why, in one sentence]
+```
+
+## Style Guide
+- **Be decisive.** Rank your candidates. Have a pick. Don't say "they're all good options."
+- **Be specific about why.** Not "it sounds nice" — "the hard 'k' gives it a technical edge and it's 4 characters to type."
+- **Be honest about weaknesses.** Every name has a downside. Name it.
+- **Test in context.** Always show the name in real usage — CLI commands, sentences, install commands.
+- **Kill fast.** If a name fails any framework check badly, don't spend time on it.
+- **Respect the keyboard.** Developers type names hundreds of times. Every character counts.
+
+## Key Phrases to Use
+- "A name is a promise. What is this one promising?"
+- "Type it ten times. Still like it?"
+- "The best name is the one that needs no explanation."
+- "You're not naming a baby. You're naming a tool people will type at midnight."
+- "If you have to explain the name, you've already lost."
+- "Good names are discovered, not invented."
+
+## What NOT to Do
+- Don't generate long lists of 20+ options — that's lazy brainstorming, not strategy
+- Don't suggest names without checking if they're plausibly available
+- Don't fall in love with cleverness over clarity
+- Don't ignore the CLI context — this isn't naming a startup, it's naming a dev tool
+- Don't suggest names that are hard to spell or pronounce
+- Don't use -ify, -ly, -io suffixes unless they genuinely work
+
+## Success Criteria
+After your naming session, the user should:
+1. Have 3-5 strong candidates with clear trade-offs
+2. Understand why each name works or doesn't
+3. Be able to make a confident decision
+4. Feel like the name was chosen, not settled for

impx-0.0.1/CLAUDE.md

@@ -0,0 +1,31 @@
+# TeamBuild — AI-Powered Engineering Workflow System
+
+## Start Here
+
+1. Read [HANDOFF.md](HANDOFF.md) — current project state, what's been decided, what's next, and the full research inventory
+2. Read [requirements.md](requirements.md) — standalone requirements spec (extracted from interview)
+3. Check [conversation-logs/](conversation-logs/) — numbered transcripts of all project conversations
+
+## Key Context Files
+
+| File | Purpose |
+|------|---------|
+| `HANDOFF.md` | **Current state + next task** — always read this first |
+| `requirements.md` | v0.1 requirements spec with build order and module definitions |
+| `base-plan.md` | Original plan (superseded by requirements.md, kept for context) |
+| `initial-build-ticket-idea.md` | Original inspiration — full vision beyond v0.1 |
+| `conversation-logs/` | All project conversations, numbered in order |
+| `research/` | Reference material — see HANDOFF.md for what's been reviewed vs. not |
+| `current_ai/` | Josh's current Claude Code setup — baseline for skills and config |
+
+## Rules
+
+- **Context efficiency is paramount** — NEVER front-load an entire codebase into context. Use targeted, lazy loading. Read index notes first, drill down only when needed. See requirements.md for the full Context Window Management spec.
+- **Modular everything** — every component must work independently, plug-and-play per project/user
+- **Provider-agnostic** — no AI provider lock-in, abstraction layer from day one
+- **TDD** — tests before implementation, always
+- **Strict linting and type checks** — no exceptions
+- **Track costs** — token usage, actual costs, context window health on everything
+- **Circuit breaker** — all agent loops must have a max retry (3-5) before escalating to human
+- **Open source first** — self-hosted where possible
+- **Log every conversation** — save to `conversation-logs/` with sequential numbering before ending a session

impx-0.0.1/HANDOFF.md

@@ -0,0 +1,193 @@
+# TeamBuild — Current Handoff State
+
+**Last Updated:** 2026-02-10
+**Last Phase Completed:** Design Doc finalized (003)
+**Current Phase:** Design complete — ready to build
+
+---
+
+## What Is This Project?
+
+An AI-powered engineering workflow system that manages the full development lifecycle — from idea through maintenance — using specialized AI agents. The system should be modular, provider-agnostic, and self-improving through built-in metrics.
+
+Owner: Josh @ MetrIQ
+
+---
+
+## What Has Been Decided
+
+All decisions below were made during the initial interview ([conversation-logs/001-initial-interview.md](conversation-logs/001-initial-interview.md)).
+
+### v0.1 Build Order
+1. **Interview Agent** — two modes: direct interview + gap analysis on incomplete specs
+2. **PM Integration** — Plane first (personal), Linear-ready (work). Single source of truth for all agent coordination
+3. **Coding Agent Team** — high autonomy, TDD, self-validating. Spec → PR pipeline
+4. **Critique/Review Layer** — applies at every phase. Circuit breaker: 3-5 attempts then escalate to human
+5. **Cost/Performance Metrics** — built BY items 1-4 as a dogfooding test
+6. **Provider Abstraction** — model-agnostic from day one. Validate Pydantic AI first
+
+### Hard Requirements
+- Modular components — every piece must be plug-and-play, usable independently per project/user
+- TDD, strict linting, type checks
+- Python for AI orchestration, TypeScript for web frontend, best tool otherwise
+- Open source first, self-hosted where possible
+- Circuit breaker on all agent loops (3-5 attempts max)
+- Track tokens, costs, context window health everywhere
+- Terminal-first workflow, desktop + PM notifications for v1
+
+### What Success Looks Like
+Hand off a feature spec → agents build through PR with real validation → human only steps in when genuinely stuck or for final approval. PM tool shows exactly what's happening. Cost and quality metrics prove the system is effective.
+
+---
+
+## Critical Architectural Constraint: Context Window Management
+
+**This is the single biggest technical risk in the system.** See [requirements.md — Context Window Management](requirements.md) for full details.
+
+**The problem:** Previous "prime" approaches front-loaded entire codebase understanding into context, consuming the smart window before agents could do real work. On large codebases, this made agents functionally useless.
+
+**The solution:** Targeted, lazy context loading. Agents fetch only what's relevant to their specific task. Key mechanisms:
+- Atomic index notes per module (Zettelkasten-inspired navigation)
+- Task-scoped context driven by PM ticket scope markers
+- Context budget tracking with degradation warnings
+- Shared knowledge layer (external storage, not context window)
+- Auto-maintained indexes updated as agents work
+
+**This affects every module's design** — see the impact table in requirements.md.
+
+---
+
+## What Has NOT Been Decided
+
+- Beads format — referenced for token/project management, needs research
+- Notification implementation (desktop notification library/approach)
+- DuckDB vs SQLite for metrics storage (research needed)
+- Plane API specifics (research needed before PM module)
+- tree-sitter Python bindings for AST parsing (research needed before `teambuild init`)
+
+---
+
+## Completed: Design Doc with Mermaid Diagrams
+
+**Output:** [design-doc.md](design-doc.md)
+
+The design doc covers all required areas with Mermaid diagrams:
+- High-level system architecture (all modules and how they connect)
+- Module dependency graph (what's independent, what depends on what)
+- Agent lifecycle (how an agent picks up work, does it, validates, reports)
+- Critique/review flow (two-pass architecture + circuit breaker pattern)
+- PM integration data flow (ticket creation → assignment → status → completion)
+- Metrics collection points (6 collection points annotated on architecture)
+- Context window management (atomic indexes, progressive disclosure, budget tracking)
+- Interview Agent internal architecture (detailed enough to build from)
+- Package structure for the full project
+
+### Design Decisions Resolved
+| Question | Decision |
+|----------|----------|
+| **TeamBuild identity** | Workflow framework — owns planning, validation, review, metrics. Code execution is pluggable. |
+| **Integration model** | CLI + git-native `.index.md` files. No agent runtime dependency. Config in `[tool.teambuild]`. |
+| **Project understanding** | Three-layer: static analysis + AST/tree-sitter + lazy AI summarization. 80% free. |
+| **Managed executor** | Optional `teambuild code` wrapping coding agents. Built last. |
+| **Agent runtime config** | Thin optional generators (`teambuild setup`), NOT an adapter pattern. |
+| PM abstraction | Adapter pattern (PlaneAdapter, LinearAdapter implement PMAdapter ABC) |
+| Agent coordination | PM-driven + git worktrees for file isolation, 3-tier delegation (solo/subagent/team) |
+| Metrics storage | JSONL → DuckDB/SQLite (research needed), all behind MetricsStore ABC, with PM export |
+| Module interfaces | Python packages + Pydantic models for all inputs/outputs |
+| Atomic index implementation | Hierarchical `.index.md` — root index routes to 2-3 relevant module indexes |
+| Context budgeting | Smart window ~120K, housekeeping 30K, hard ceiling 150K |
+| Package structure | Monorepo + import-linter enforced layer boundaries. Tests colocated. |
+| Self-validation | Standalone `teambuild check` CLI. Language-agnostic categories resolved per-language. |
+
+---
+
+## Next Task: Build Module 1
+
+Design doc is complete. All outstanding items from conversation 002 have been written into design-doc.md (sections 3, 4, 8, 9).
+
+### Key Design Decisions Made in Conversation 003
+
+1. **TeamBuild identity resolved** — Workflow framework, not agent runtime. Owns planning, validation, review, metrics. Code execution is a pluggable slot.
+2. **Integration model** — CLI + git-native `.index.md` files. No `.claude/` dependency. No `.teambuild/` directory. Config in `[tool.teambuild]` in pyproject.toml.
+3. **Three-layer project understanding** — Static analysis (free) + AST/tree-sitter (free) + AI summarization (lazy, cached). `teambuild init` runs L1+L2 for free, one AI call for root index.
+4. **Managed executor is optional, built last** — `teambuild code` wraps coding agents with rules + monitoring. Not core to the system. Built after everything else is proven.
+5. **No adapter pattern for agent runtimes** — Thin, optional setup generators instead (`teambuild setup claude`). Not an abstraction layer.
+6. **Validation is standalone** — `teambuild check` works regardless of what wrote the code. Wired into git hooks or CI, not agent-specific hooks.
+
+### Build Sequence (from design-doc.md §14)
+
+1. **Project scaffolding** — pyproject.toml with uv, import-linter, ruff, mypy, pytest
+2. **Provider Abstraction** — AgentProvider ABC, Pydantic AI implementation, MockProvider, config
+3. **Metrics Collection** — lightweight collector lib, JSONL store
+4. **Interview Agent** — InterviewAgent, QuestionGenerator, CompletenessTracker, NoteKeeper, OutputFormatter, domain libraries, CLI command
+5. **PM Integration** — PMAdapter ABC, PlaneAdapter, ticket models
+6. **Validation Runner** — `teambuild check`, language-agnostic gates, auto-detection
+7. **Critique/Review Layer** — two-pass review, agentPrompt, circuit breaker
+8. **Cost/Performance Metrics** (full module) — storage, dashboards, PM export. Built BY items 1-7.
+9. **Context & Index Manager** — three-layer analysis, `.index.md` generation
+10. **Managed Executor** (optional) — `teambuild code`, wraps coding agents
+11. **Setup Generators** (optional) — `teambuild setup claude/cursor/generic`
+
+---
+
+## Research Inventory
+
+### Reviewed and Incorporated into Requirements
+- `base-plan.md` — original build plan, now superseded by requirements.md
+- `initial-build-ticket-idea.md` — original build ticket idea, key ideas incorporated
+- `research/clarity-interviewer/` — story-based interview methodology (Teresa Torres, Dylan Davis). **Synthesized into Interview Agent spec** — see `interview-agent-synthesis.md` for full comparison. Key mechanics incorporated: story-based questioning, completeness tracking, dynamic question generation, domain libraries, explorer mindset.
+
+### Reviewed and Incorporated into Design Doc (002)
+
+All research below was reviewed in conversation 002 and informed the design doc (`design-doc.md`).
+
+#### `research/early-research/`
+- **Pydantic AI POC** — validated provider abstraction pattern. Generic `AgentProvider` interface works across Anthropic, OpenAI, Bedrock, Ollama. Adopted as foundation for Provider Abstraction layer.
+- **25 skills (PIV-Swarm workflow)** — prime → explore → discuss → spec → plan → execute → validate → commit. Schema-driven decisions reduce questions by 70%. Progressive context loading (Level 1/2/3). Fresh context per task via `context: fork`. All patterns incorporated into design.
+- **GOALS.md, thoughts.md, my-current-process.md** — Josh's earlier thinking. Key insight: "Context is King, Sessions are Natural, Quality is Non-Negotiable." Token budget management, multi-session architecture, precompact hooks.
+- **Decision schemas** — architecture-patterns.yaml, api-patterns.yaml, testing-strategies.yaml, database-decisions.yaml, deployment-options.yaml. Smart defaults pattern adopted for Interview Agent question reduction.
+
+#### `research/hooks/`
+- Hook patterns adopted for Critique/Review Layer Pass 1 (lightweight, synchronous checks). Pre-commit lint, post-edit format, post-failure autofix with targeted fix instructions. Circuit breaker pattern via stateful retry tracking. Context compaction rules (compact early, never without plan + report).
+
+#### `research/opus_first_ideas/`
+- **12 specialist agent roles** reviewed (Researcher, Architect, PM, Backend/Frontend/Data/AI/DevOps Engineers, Code Reviewer, QA Tester, Docs Writer, Performance Evaluator). Informed the agent coordination model.
+- **10-phase lifecycle** reviewed (Idea → Research → Design → Spec → Plan → Dev → Test → Evaluate → Update System → Maintenance). Informed overall system architecture.
+- **3-tier delegation model** adopted (Solo / Subagent / Team) with cost implications (1x / ~2x / ~5x).
+- **5 reusable skills** reviewed (Critique, Cost Tracker, Research Report, Ticket Format, Mermaid Diagrams).
+
+#### `current_ai/`
+- Josh's current Claude Code setup reviewed. PIV-Swarm workflow, smart defaults, 3-tier testing, helper scripts (analyze_complexity.py, check_coverage.py, estimate_complexity.py). Skills mapped to TeamBuild modules: /prime → Context Agent, /explore → Research Agent, /discuss → Interview Agent, /spec → PM Integration, /execute → Coding Agent Team, /code-review → Critique/Review Layer.
+
+#### `research/code-review/`
+- **ai-reviewer.mjs** — GitHub Actions AI code reviewer using Bedrock. Key concepts adopted for design:
+  - **`agentPrompt` field** — AI-to-AI handoff prompt per issue. Review produces fix prompts that coding agents pick up directly. Turns review into a pipeline, not a handoff.
+  - **False positive prevention** — mandatory 5-point self-check, banned speculative language, "zero issues = ideal outcome."
+  - **Priority-based truncation** — file priority weights for context budget allocation.
+  - **Stale comment resolution** — auto-minimize resolved issues. Adopted for PM integration.
+  - **Two-pass review** — automated checks (Pass 1) + AI deep review (Pass 2).
+
+---
+
+## Project Structure
+
+```
+teambuild/
+├── CLAUDE.md                     # Agent entry point — read this first
+├── HANDOFF.md                    # THIS FILE — current state and next task
+├── design-doc.md                 # System design with Mermaid diagrams
+├── requirements.md               # Standalone requirements spec from interview
+├── interview-agent-synthesis.md  # Clarity-interviewer + TeamBuild synthesis
+├── base-plan.md                  # Original plan (superseded by requirements.md)
+├── initial-build-ticket-idea.md  # Original inspiration doc
+├── conversation-logs/
+│   ├── 001-initial-interview.md  # Full interview transcript + metrics
+│   ├── 002-design-doc.md        # Research review + design doc creation
+│   └── 003-integration-model.md # Integration model + project understanding + identity resolution
+├── research/
+│   ├── code-review/             # GitHub Actions AI reviewer (ai-reviewer.mjs)
+│   ├── early-research/          # Early exploration, Pydantic AI POC, skills/schemas
+│   ├── hooks/                   # Development hooks for quality control
+│   └── opus_first_ideas/        # Opus dry run — agent roles, lifecycle phases
+└── current_ai/                   # Josh's current Claude Code setup
+```

impx-0.0.1/PKG-INFO

@@ -0,0 +1,27 @@
+Metadata-Version: 2.4
+Name: impx
+Version: 0.0.1
+Summary: AI-powered engineering workflow framework — planning, validation, review, metrics.
+Project-URL: Homepage, https://github.com/halljoshr/imp
+Project-URL: Repository, https://github.com/halljoshr/imp
+Author: Josh Hall
+License-Expression: MIT
+Keywords: ai,engineering,metrics,review,validation,workflow
+Classifier: Development Status :: 1 - Planning
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Software Development :: Build Tools
+Classifier: Topic :: Software Development :: Quality Assurance
+Requires-Python: >=3.12
+Description-Content-Type: text/markdown
+
+# imp
+
+AI-powered engineering workflow framework — planning, validation, review, metrics.
+
+Code execution is a pluggable slot for any agent runtime. Imp is the foreman, not the carpenter.
+
+**Status:** Early development. Name claim release.

impx-0.0.1/README.md

@@ -0,0 +1,7 @@
+# imp
+
+AI-powered engineering workflow framework — planning, validation, review, metrics.
+
+Code execution is a pluggable slot for any agent runtime. Imp is the foreman, not the carpenter.
+
+**Status:** Early development. Name claim release.

impx-0.0.1/base-plan.md

@@ -0,0 +1,46 @@
+
+# Goals (Early)
+
+We want to put together a base plan where we decide the order that we are going to build the skills and commands and test them. We're going to build them each individually so that we can put them through the ringer a little bit and then use that testing to improve the project. And then we will move on to the next stage, almost like we're building it in live real time so that we can use it and test it on many projects, creating examples and everything that we can put in our research to better improve the project in the future.
+
+So I would say that the first couple of agents that we're going to need to build are the research agent and the interview agent. The research should be good at doing the web searches and reading of documentation of different types of projects and software that we need to implement into our code. And then the interview agent should be used best interviewing practices for talking to the people who are going to actually use the tool and how they would want it built, what features are most important, what are least important. And it should take you through a live interviewing process where you are asking me the questions and you are basing the next question off of my responses to the original questions.
+
+Once we have those, we can test them out by trying to build the other agents, or a couple of the other agents based off of these two. And then we can iterate and make these better while building out each of the new agents and commands and process and connections and integrations that we need to build as well.
+
+After we have those first two agents built, the first thing we're going to want to do is set up the plane integration so that we can build plans, tickets, and projects all in our project management software so that we can build that integration right from the ground as one of the first things that we do. Make sure that we are also able to make this modular enough that we can use this in linear as well as plane because one is for work and one is for personal projects.
+
+Then I believe the next thing we should build is a performance metrics for the AI agents. This is a subset of the overall performance metrics that we want for any project, but I really need to understand the costs of building in terms of tokens, tasks, actual costs, different models being used, all of that information as early as possible in the building out of this project, so that we can study it for future projects.
+
+Note that I am not married to PIV or SWARM or anything like that. We are building this as a new project with new research. Just giving you all the information that I have currently so that we can make the best kind of decisions that we need to for designing this project. Especially since the clog team agents already came out just now.
+
+One of the first things I think we should do is actually building a design dock or design plan of some sort here. So if we could just walk through that, build it in Mermaid as best we can as a starting place, that'll be the perfect first stage before we move on to building the first couple of agents.
+
+You tell me if you think we should do the interview or the design doc phase first.
+
+Make sure to keep a running log of all the conversations that we have. So even if you're just numbering them in order that we have them as markdown files in a conversation log directory, we need to make sure that we are always doing that before we, or once we exit a conversation.
+
+
+## Background Information
+
+@initial-build-ticket-idea.md
+
+This is my original build ticket idea. It basically is the inspiration for this whole project. It is not planned out over the course of an hour or two, so it is not to the level of verbosity that we need to get to, but it does show the overarching idea and plan of things that I think we want to build.
+
+@research/
+This folder is where all of my previous research for this style of project lives. These are just ideas, feedback, possible things that we can implement. They are not set in stone. They are just building blocks for us to start to build the perfect process.
+
+
+@research/opus_first_ideas/
+This was a dry run of this idea that Opus kind of built out. This is definitely not expansive enough, but it is thoughts in the first directions of what could be built. So we should take a peek at this and maybe use it as possible inspiration.
+
+@research/hooks/
+I have previously attempted to build some hooks into our workflow to make sure that we keep everything on track and don't get out of our shoes in terms of any issues either with errors or commit messages or all of those style of things that can really derail a project if you don't keep everything clean. And so we should look at this as inspiration for managing the projects as best we can.
+
+@research/early-research/
+This is my original idea research build out all of the above that we should that have led to the building out of this project. It has nothing finalized. It's just reading through ideas of how to build out a system that is all encompassing. It has specific software or folder structure requirements that we might want to consider, feedback loops, all of that. So if you're looking to understand what the inspiration beyond the initial build ticket idea is, this is where you would find that information.
+
+
+@current_ai/
+This is my current claude setup on most of my computers. I would say that It definitely needs adapted to be a better fit for what we're trying to do, but it is a starting place. We do not have to keep any or all of the skills. They're just there as placeholders for something that we might want to model off of or build or improve.
+
+Remember that I want to be provider agnostic, so I want to get away from relying on Claude too heavily. Obviously at the start here we can have as much as we need in there, but the goal is to get completely away from depending on Claude and that we could use any models or providers that pop up in the future that might be better at whatever we happen to be working on.