Configuration and Knowledge Management

Knowledge of

• A Project as a persistent workspace bundling instructions and project knowledge that every chat inside it can use
• Instructions as standing guidance for role, tone, format, and rules; project knowledge as uploaded documents/reference material Claude grounds answers on
• Why Projects are the natural home for recurring, knowledge-heavy work (a client account, a product line, a repeated report)
• Retrieval: when project knowledge is large, Claude retrieves the relevant portions rather than reading everything at once
• The risk of treating project knowledge as a dumping ground, diluting answer quality with irrelevant or outdated files
• Scoped Memory as a third Project mechanism alongside instructions and knowledge: continuity of settled facts (names, preferences, decisions) carried across sessions within a Project
• Memory's Project-level isolation -- context stored in one Project's Memory does not surface in a different Project's sessions
• Memory as something that must be actively curated over time, not a permanent, set-once record
• Diagnosing stale Memory by symptom: a specific, confidently stated fact from an earlier session (a name, an approver, a preference) that no longer matches the current situation
• What should never be stored in Memory: standing rules that must always apply (belong in instructions) and real reference material (belongs in project knowledge)

Skills in

• Setting up Project instructions once instead of re-pasting the same brief into every new chat
• Curating project knowledge to relevant, current material rather than accumulating everything available
• Recognizing when a task is recurring or knowledge-heavy enough to warrant a Project instead of a one-off chat
• Understanding that large project knowledge scales through retrieval, not by fitting everything into context at once
• Distinguishing scoped Memory (facts persisting across sessions in a Project) from context-window management (managing token budget within one long conversation)
• Structuring separate Projects for separate workstreams that must never share context, so Memory's isolation enforces the separation
• Reviewing and pruning stored Memory entries on a regular cadence rather than letting them go stale
• Recognizing the symptom of stale Memory in a scenario -- a specific outdated fact stated with confidence -- and routing the fix to Memory rather than instructions or project knowledge
• Deciding what belongs in Memory versus instructions versus project knowledge, rather than defaulting to Memory for anything that feels like it should persist

Knowledge of

• Uploads as files added directly (documents, spreadsheets, PDFs) that become Project or conversation knowledge
• Connectors as integrations to external sources (e.g., Google Drive, Gmail) that let Claude work with content where it already lives
• Connector and feature availability as plan/pricing-tier dependent, not universal
• The overlap between knowledge management and governance: sensitive or regulated data should not be added without checking policy
• Curating scope: adding sources that matter, keeping them organized, and removing or updating stale material

Skills in

• Choosing between uploading a file directly and connecting to its live external source
• Checking plan/tier availability before assuming a connector such as Google Drive or Gmail is accessible
• Screening uploaded or connected content against data-handling policy before adding it as knowledge
• Curating knowledge scope by removing stale or irrelevant sources rather than accumulating everything

Knowledge of

• The traits of effective system-level instructions: specific role and goal, explicit format and tone, clear boundaries, concise and high-signal
• System-level instructions as the workspace-level application of the same prompting discipline used in individual prompts
• Agent Skills as reusable instruction sets that package how to do a recurring task, conceptually parallel to durable system-level guidance
• The failure modes of vague instructions and of over-detailed instructions that bury the key rules
• Built-in Skills (Excel, Word, PowerPoint, PDF document handling) as account-level capabilities Claude invokes automatically, not something configured per Project
• Skills as reducing output variance without eliminating it -- the same Skill still produces different prose on each run
• Custom Skills as the right tool for a repeatable, multi-step procedure with its own internal logic, versus a system-level instruction for broad standing behavior
• The learner-facing distinction between a Skill (account-wide, works in any Project or plain chat) and project knowledge (depends on what was uploaded or configured in one specific Project)

Skills in

• Writing Project instructions that specify role, goal, format, tone, and boundaries rather than vague guidance
• Keeping instructions concise so the important rules aren't buried in excess detail
• Recognizing when a recurring task is a candidate for packaging as an Agent Skill
• Recognizing built-in Skills invoked automatically (e.g., document handling) rather than assuming every capability must be configured manually
• Not mistaking a Skill's consistency for a guarantee of identical, word-for-word output every time
• Deciding whether a recurring team workflow should become a custom Skill or stay a system-level instruction, based on whether it's a multi-step procedure or a broad behavioral rule
• Testing whether an observed capability would still work in a brand-new, empty Project to tell a Skill apart from project knowledge

Knowledge of

• Configuration as an ongoing responsibility, not a one-time setup
• The need to refresh knowledge sources when documents change and remove superseded versions
• The need to update instructions when process, tone, or rules change
• Stale configuration as a quiet source of wrong output, since Claude faithfully follows outdated instructions or cites old policy
• Keeping knowledge current as an accuracy control connected to verification practices

Skills in

• Periodically reviewing whether a Project's instructions and knowledge still reflect how the team actually works
• Replacing superseded documents rather than leaving multiple versions in a Project
• Updating instructions promptly when the underlying process or policy changes