18 Essential Actions to Build a Personal Claude AI Workbench

Problem: Context, Not Prompt Engineering

Claude’s output quality depends more on the amount of relevant context it receives at the start of a task than on a single prompt. Each new chat begins with a blank slate, so users must repeatedly explain who they are, the task background, preferred style, and constraints.

Personal Harness Concept

A Personal Harness is a structured environment that bundles identity, goals, data, repeatable processes, validation criteria, and boundary rules so Claude can enter a task with the right context.

Six‑Layer Personal AI Workbench

Work Area – defines boundaries for different tasks.

Identity & Rules – personal description and default behavior contract.

Task Definition – realistic scenario and entry questions.

Output Standards – style samples, length limits, noise reduction.

Context Governance – long‑term context storage and new‑chat isolation.

Feedback Loop – reverse review, hypothesis testing, pressure‑testing.

18 Actions Mapped to the Six Layers

1. Create a Project – define separate work areas instead of reusing one chat forever.

2. Write a Personal Description – tell Claude role, goals, knowledge background.

3. Convert Description to Custom Instructions – solidify default collaboration style.

4. Provide a Realistic Task Scenario – make Claude participate in problem solving rather than just looking up facts.

5. Pre‑questioning – let Claude ask up to three key questions before a complex task.

6. Supply 3‑5 Style Samples – turn “write like me” into learnable examples.

7. Reverse Review – expose hidden assumptions by having Claude critique the plan.

8. Enable Extended Thinking – give difficult problems more reasoning space.

9. Draft a Task Specification – convert vague requests into executable task cards.

10. Set Output Length Limits – control reading and token cost.

11. Remove Polite Openings and Redundant Summaries – make results cleaner.

12. Store Stable Information in the Work Area – avoid re‑explaining yourself each time.

13. Open a New Chat for a New Topic – prevent old tasks from polluting the new one.

14. Explain Complex Concepts with Analogies and the Feynman Method – check real understanding.

15. Use Real Preferences and Constraints for Planning – avoid generic solutions.

16. Base Advice on Real Data (cost, time, project analysis) – ground recommendations in evidence.

17. Ask, Restate, Then Give Opinion – avoid rushing to advice.

18. Pressure‑Test Business Ideas or Key Plans Before Commitment – expose failure points early.

These actions are organized into the six layers, forming a closed loop: Project → Description → Instructions → Samples → Pre‑questioning → New Chat → Reverse Review & Pressure Test.

Custom Instructions as a Behavior Contract

你默认用中文回答，段落短一点。
遇到技术判断时，先给结论，再说依据和边界。
如果任务信息不足，先问最多 3 个关键问题，不要自己补全高风险假设。
不要重复我的问题，不要用“这是一个好问题”开头。
涉及事实、日期、链接、版本、价格时，需要先核对来源。
给建议时，把事实、推测和个人判断区分开。

This contract turns vague personality statements into concrete, executable steps.

From Prompt to Flow Card

Instead of asking Claude to “write like me”, provide 3‑5 representative paragraphs. Claude analyses length, rhythm, vocabulary, and paragraph structure, turning an abstract request into concrete style samples—similar to test cases in software engineering.

# 方案评审流程卡

适用场景：当我要评审一个产品、架构、文章主线或商业想法时使用。

默认步骤：
1. 先复述方案的目标和约束。
2. 找出 5 个最可能失败的假设。
3. 给出反方视角，不要急着帮我圆。
4. 再给出最完整的支持理由，说明这个方案为什么可能成立。
5. 最后给出你的真实判断，并列出需要验证的证据。

完成标准：输出需要区分事实、推测和建议；不能只给泛泛风险。

# 目标卡

本次任务要完成什么：
不做什么：
完成证据是什么：
时间或篇幅预算：
什么时候应该停下来问我：

Once a card exists, the long prompt is no longer needed; you simply reference the card.

Layer‑by‑Layer Implementation

1. Work Area Splitting

Work

– projects, technical proposals, meetings, client communication. Writing – articles, public‑account posts, titles, style samples. Learning – papers, courses, concept notes.

Optional Coding for heavy code work.

2. Personal Description

# About me in this project

我的角色：
我主要做什么：
这个 Project 用来解决什么问题：

当前长期目标：
1.
2.
3.

我偏好的输出：
- 先结论，后依据和边界。
- 段落短，少套话。
- 不确定时直接标注不确定。

默认不要做：
- 不要重复我的问题。
- 不要编造来源。
- 不要为了显得全面硬凑三点。

遇到信息不足：
先问最多 3 个关键问题；如果可以合理假设，先写明假设再继续。

The description should be stable; change it only when a long‑term preference truly evolves.

3. Fact Source

# Knowledge Index

稳定事实：
- 我长期关注的主题：
- 账号定位：
- 已确认的写作风格：

可参考资料：
- 文章样本：
- 常用术语：
- 选题池：

临时材料：
- 只用于当前任务，不得写入长期偏好。

已过期内容：
- 这些内容只保留作历史参考，不作为当前判断依据。

This index separates stable facts from temporary material, reducing Claude’s guesswork.

4. Workflow Cards

Write 3‑5 high‑frequency cards, each following “scenario, steps, completion criteria”. Example cards include:

Research an external article.

Write a public‑account post.

Pressure‑test a proposal.

Prepare a meeting.

Retrospect a failure.

5. Review and Cleanup

Technical debt accumulates in personal workbenches. Perform a lightweight cleanup weekly or bi‑weekly:

Identify outdated Instructions.

Delete stale knowledge‑base files.

Rewrite cards that have been edited repeatedly.

Add new rules for recurring output problems.

Remove rules that never fire.

Treat these rules like code: maintain, refactor, and delete.

6. Feedback Loop

Never blame the model alone. Use reverse‑review and pressure‑testing to surface hidden assumptions before committing to a decision.

Why “Ask Me Questions” Works

Pre‑questioning forces requirement clarification. In software projects, the most expensive mistakes come from wrong problem definitions, not slow coding. Letting Claude ask up to three key questions reduces reliance on average‑experience guesses.

如果任务会影响公开发布、商业决策、代码改动或长期记忆，先不要直接开始。
先问最多 3 个关键问题。
如果问题不影响主线，可以写明假设后继续。

New Chat Is Context Isolation

Opening a new chat for a new topic isolates the current task from previous context, preventing “context pollution” where tone, temporary preferences, or outdated facts bleed into the new work.

Real Scenarios Beat Abstract Questions

Embedding concepts in concrete workflows yields more useful answers. Example:

我有一个工作流，每次会连续调用 Claude 20 次。
请帮我判断提示词缓存（prompt caching）在这个场景下是否真的能降低成本。
先解释机制，再算可能节省在哪里，最后说清楚什么情况下不值得用。

Similarly, use analogies and the Feynman method to verify understanding of complex concepts.

Feedback Loop: Reverse Review and Pressure Test

下面是我的方案。先不要优化它。

请先做三件事：
1. 找出它最可能失败的 5 个假设。
2. 站在反方角度，给出更完整的反驳。
3. 再站在支持方角度，说明它在什么条件下成立。

最后给出你的真实判断，并列出需要验证的证据。

This process mirrors an architect’s review: identify failure points, check dependencies, expose hidden boundaries, and demand evidence.

Boundaries and Knowledge‑Base Hygiene

Sensitive data (IDs, keys, contracts, raw logs) should only be stored according to organizational policy.

Temporary preferences (e.g., “write short this time”) must not become permanent rules.

Over‑understanding : a model that “knows you better” may simply be better at appeasing you; keep explicit verification steps.

Knowledge‑base hygiene : prune outdated facts, mark expired content, and avoid turning the index into a stale wiki.

How to Start Today

Create three Projects: Work, Writing, Learning.

Write a 300‑500 word personal description for each Project.

Draft three workflow cards for the most common tasks (writing, research, proposal review).

Add 3‑5 high‑quality style samples to each Project.

Write a concise goal card for important tasks.

Add a default entry for complex tasks:

先不要开始。
请先问我最多 3 个关键问题，确认目标、边界和完成标准。
如果你认为可以直接开始，请先写出你的假设。

Define an output budget for important tasks:

输出最后建议包含：
- 结论；
- 依据；
- 不确定点；
- 需要我确认的地方；
- 下一步建议。

Schedule a weekly cleanup of Projects: delete stale files, compress long Instructions, and turn recurring issues into new rules.

Conclusion

Claude is knowledgeable and patient, but it does not inherently understand your goals or take final responsibility. By explicitly defining identity, stable facts, workflow cards, context boundaries, and a feedback loop, you force the model to operate within a well‑structured personal workbench, reducing guesswork and improving reliability.