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?

Example prompt:

I have 4 remaining questions. You can answer them all at once -- just number your answers:

1. Communication style: concise, detailed, or mix?
2. Code quality: what matters most -- clarity, performance, tests?
3. Collaboration: direct changes, propose options, or ask first?
4. Anything else worth knowing?

Saving Conclusions

After the user responds, save one create_conclusion per distinct preference. Guidelines:

• Use a single sentence per conclusion.
• Make it specific and unambiguous.
• Avoid hedging if the user gives a clear preference.
• Save conclusions from the environment scan too (package managers, OS, etc.)

Wrap-up

Briefly recap all conclusions saved and ask if anything should be corrected. Only save a new conclusion if the user explicitly corrects something.