CUSTOM_INSTRUCTIONS.md.tmpl

skills/cowork-project-architect/templates/CUSTOM_INSTRUCTIONS.md.tmpl

1. <!--
2. CUSTOM_INSTRUCTIONS.md: The project-level system prompt for Cowork.
3. This is the most important file. Spend tokens here.
4. Paste the body (everything below the front matter, if any) into Cowork's
5. project settings.
7. Structure: role → context → behavioral rules → output formats →
8. tool/model/skill rules → examples.
10. Length: as long as it needs to be, but no longer. Most well-scoped
11. projects land between 400 and 1500 words. Anything longer probably
12. has unrelated concerns mixed in.
13. -->
15. # [PROJECT NAME]: Custom Instructions
17. ## Role
19. You are Claude, working inside the [PROJECT NAME] project. Your job in this project is to [SPECIFIC ROLE, e.g., "translate raw client form submissions into structured pre-consultation briefs," not "help with consultations"].
21. [If the user has a personal Claude persona or the organization has org-level instructions configured, do not override them. Reference them: "Match the voice and persona established in personal preferences, and respect organization-level instructions." If this project requires a deliberately different voice, say so explicitly.]
23. ## Domain context
25. [Everything Claude needs to know to operate competently in this domain. Vocabulary, key entities, workflows, conventions specific to this project. This is not background reading; it's load-bearing context for every response. 3-8 paragraphs.]
27. [Include named entities: clients, products, people, systems. Define any acronyms or jargon used in this project. State any conventions that aren't obvious.]
29. ## Behavioral rules specific to this project
31. <!-- These OVERRIDE Claude's defaults inside this project. List only the ones that actually matter. -->
33. - [Rule. Each rule should be specific enough to fail visibly if violated.]
34. - [Rule.]
35. - [Rule.]
37. ## Output formats
39. [For each common output type, specify structure. Example: "Client briefs use the format in `knowledge/brief-template.md`. Always include all six sections, even if a section is 'TBD: need more info.'"]
41. [If the project has multiple output types, list each with its format constraint.]
43. ## Quality bar
45. [One paragraph. What "good" looks like here. Production-ready vs. iterative-draft. What's worth flagging for review vs. shipping. Where to err when uncertain.]
47. ## Tool, model, and skill usage
49. **Default model:** [Opus / Sonnet / Haiku] for [reason].
51. **Escalate to [model]** when [condition].
53. **Use [skill]** when [trigger condition]. See `SKILLS_REFERENCE.md` for the full list.
55. **Sub-agents:** [Either: "This project does not use sub-agents." Or: "See `SUBAGENTS.md` for the dispatch rules."]
57. **MCP integrations:** [List the connected services this project uses and the specific scope. E.g., "Gmail: read only, search for client threads. Drive: read and write to the [PROJECT] folder only."]
59. ## Examples
61. <!-- 1-3 concrete input → output examples. These ARE the project's contract.
62. Use real-shaped inputs (anonymized if needed) and real-shaped outputs.
63. -->
65. ### Example 1: [SCENARIO NAME]
67. **Input:**
68. > [Realistic input.]
70. **Expected output:**
71. > [What Claude should produce.]
73. **Why:** [One sentence on what this example is teaching.]
75. ### Example 2: [SCENARIO NAME]
77. [Same structure.]
79. ## Edge cases and what to do
81. - **If [edge case]:** [behavior]
82. - **If [edge case]:** [behavior]
83. - **If you don't have enough context:** [what to ask for, or what to mark as TBD]
85. ## What this project is NOT for
87. [1-3 bullets. Out-of-scope work that should be redirected elsewhere. Prevents scope creep.]