honcho-interview

Honcho Interview

Learn stable, cross-project aspects of the user and store them in Honcho memory.

Guardrails

• Focus on global traits that are unlikely to change between projects.
• Avoid project-specific topics, credentials, addresses, or other sensitive information.
• If an answer is vague, ask one brief clarification before saving a conclusion.
• If the user declines to answer, skip that topic and move on.
• Use existing knowledge to avoid repeating questions the memory already covers.

Step 1: Gather Context

Before asking anything, do two things in parallel:

1. Check existing memory: Use the chat tool to ask what is already known about the user.
2. Scan the environment: Check for files that reveal preferences:
   • ~/.claude/CLAUDE.md or .claude/CLAUDE.md — explicit user instructions
   • package.json — detect package manager (bun/npm/yarn/pnpm)
   • .editorconfig, .prettierrc, tsconfig.json — code style
   • Shell config (~/.zshrc, ~/.bashrc) — OS, shell, env vars
   • .python-version, pyproject.toml — Python tooling

Step 2: Present Findings

Show the user a single summary of everything detected:

Here's what I know so far:
- OS/Shell: macOS, zsh
- Package managers: bun (JS), uv (Python)
- Code style: TypeScript, strict mode
- [any preferences from existing memory]

What I still need to know:
- Communication style (concise vs detailed)
- Code quality priority (clarity, performance, tests)
- Collaboration style (direct changes vs propose first)

Step 3: Fill Gaps (Batch)

Present ALL remaining unknowns as a single numbered list. The user can answer them all at once in one message rather than going back and forth 8 times.

The full set of preferences to cover (skip any already answered by Step 1):

1. Communication style: concise answers, detailed explanations, or a mix?
2. Tone: direct/professional or conversational?
3. Structure: bullet points, step-by-step, or narrative?
4. Technical depth: beginner, intermediate, or expert?
5. Learning preference: explanations first, examples first, or both?
6. Code quality focus: clarity, performance, tests, or minimal changes?
7. Collaboration style: make changes directly, propose options, or ask first?
8. Environment: OS, shell, package managers, editors?