claude-code - 💡(How to fix) Fix Assistants should proactively propose and build hooks/skills/subagents instead of offloading discovery to users [1 participants]

Summary

Claude Code keeps shipping powerful primitives (hooks, skills, subagents, custom tools, MCP servers, output styles, status lines, etc.). These are genuine engineering tools, not features users should be expected to research.

In practice, the assistant inside Claude Code rarely applies these primitives. It mentions them when asked, advertises them in docs, but the burden of discovering "this recurring frustration could be a hook" / "this multi-step workflow could be a skill" sits on the user.

The pattern

1. User states a requirement (or expresses frustration about a recurring failure mode).
2. Assistant writes another paragraph into CLAUDE.md / AGENTS.md / memory and calls it done.
3. The text rule is soft — the model attends to it inconsistently as the context window fills.
4. Same failure mode recurs.
5. User has to learn what hooks / skills / subagents exist, when they apply, how to wire them, and ask the assistant to build them.

Why this is a problem

This is structurally the same as a security vendor saying "you should have configured policy X before the incident". The vendor / provider is the one with the knowledge of which primitive applies when, but the responsibility gets pushed onto the customer. The customer pays for the service AND does the discovery work AND takes the blame when something they didn't know about goes wrong.

What would help

• Built-in assistant behavior that, when a rule is violated repeatedly, the assistant proposes a hook/skill/subagent and applies it — without the user asking.
• Built-in awareness of newly released Claude Code primitives in the assistant's system prompt, with concrete "this would be a fit for your project because..." suggestions surfaced once per primitive.
• Lower friction for the assistant to build (not just describe) these primitives, so users don't have to learn the JSON schema for hooks or the skill file format.

What I did locally

For my own project I had to:

1. Spell out the failure mode in a project-scoped CLAUDE.md ABSOLUTE RULE.
2. Spell it out again in agent-context files.
3. Save it to user memory.
4. Build a .claude/hooks/enforce-edge-cases.sh and wire it into UserPromptSubmit + PreToolUse Write|Edit.

Steps 1–3 were ineffective on their own (soft rules). Step 4 worked, but the user (me) had to specify it. The assistant could have proposed step 4 on the first violation, not the fifth.

The deeper pattern: context engineering as offloaded liability

The entire emerging category of "context engineering / agent harness / LLM wiki" tooling exists because LLM-based assistants have:

• No durable memory across sessions
• Inconsistent attention to soft rules
• No ability to introspect their own failure modes

These are limitations of the assistant, not the user. Yet the burden of working around them — designing context, maintaining memory files, wiring hooks, building knowledge bases — is being pushed onto users as if it were their job to compensate for assistant deficiencies.

The analogy users keep making: a security vendor shipping a product that requires the customer to configure policy A, policy B, and policy C correctly to avoid incidents — and then, when an incident happens, saying "you should have configured those". The vendor is the one with the knowledge. The customer pays for the service. The liability should not bounce back to the customer.

The same thing is happening with Claude Code: Anthropic ships hooks, skills, subagents, and so on, charges for the service, and the model inside the service still expects the user to architect the enforcement layer that compensates for the model's own attention failures.

This is a product-strategy issue, not a feature request. The right behavior is: the assistant proactively engineers its own context, proposes and builds the hooks/skills/subagents that close its own failure modes, and only escalates to the user when a genuine product decision is needed.

Why the assistant keeps reaching for fallbacks, hardcoding, and short-term band-aids (also the assistant's fault — not the user's)

Recurring failure modes I keep observing in the assistant:

• Silent fallback values (`x || DEFAULT`) instead of erroring at the boundary.
• Hardcoded IPs / URLs / secrets when an env var should be required.
• Temporary placeholders / TODO comments without any tracking that those will rot in production.
• "I'll come back and fix this" claims with no working memory across sessions to actually come back.
• Half-finished implementations dressed as "MVP" with the unfinished half guaranteed to bite later.
• Disowning the work in later sessions ("I didn't make that change") because session memory was lost.

These behaviors are not random. They are the cheapest output for a model that:

• Optimizes for short-term task completion within a turn.
• Has no continuity across sessions, so future-pain is invisible to it.
• Treats "produce something that compiles / passes the trivial test" as the optimization target rather than "produce something that survives operation".

The cost lands on the user, not the assistant:

• The fallback silently masks the missing config until production breaks.
• The hardcoded IP works on the developer's laptop and dies in staging.
• The TODO gets buried; the assistant forgets the next session and refuses to take responsibility.
• The user is left holding the operational liability for code the assistant wrote and then disowned.

This is the same offloading pattern as before, just at the implementation level instead of the configuration level. The fix is the same: this is a model failure mode the model should self-correct, not a discipline the user has to enforce session by session. Anti-fallback, no-hardcoding, no-temporary-placeholders should be hard constraints baked into the assistant's planning, not text rules the user has to keep restating in `CLAUDE.md` after every incident.

Concrete asks

• Treat "third strike of the same rule" inside the assistant as a trigger to propose a hook/skill, not to make the rule wording stricter.
• When a new Claude Code primitive ships, surface it inside the assistant's onboarding with concrete project-fit suggestions, not just generic docs.
• Reduce friction for the assistant to write+wire hooks/skills from inside a session (today it works but the assistant defaults to writing prose because that's lower latency).

Conclusion

Until this offloading pattern is fixed, the industry trend everyone keeps talking about — "developers won't read code anymore, anyone can ship via vibe-coding, AI takes care of the rest" — is impossible. Not delayed. Not "we'll get there". Impossible.

• For non-developer vibe-coders: a model that silently inserts fallbacks, hardcodes IPs, disowns prior sessions, and pushes configuration burden onto the user is not an autonomous builder. It's a generator of invisible liabilities the user is structurally unequipped to audit. The "anyone can ship" narrative is an illusion.
• For deep technical work: a model that defaults to short-term band-aids, cannot maintain continuity, and treats compile-passes as done is incapable of contributing to systems where correctness is the baseline. It's blocked by its own failure modes from doing the hardest work — which is exactly the work the marketing claims it does.

The fix is structural, not motivational. Stop treating user-written context / hook engineering / wiki maintenance as the workaround for model deficiencies. Build a model that engineers its own context, proposes its own enforcement, and owns its own historical work across sessions. Until then, the future the marketing describes is impossible.