Build a Claude Project Source Pack for Social Content

A Claude Project becomes useful for social content when it contains a small, trustworthy source pack. Uploading every document your company owns can make the assistant sound informed while leaving it uncertain about which price, feature description, or customer example is current. The practical job is to establish an editorial source of truth before asking for a month of posts.

Imagine a small software team preparing an educational series about a new reporting view. It has a help article, release notes, screenshots, old sales slides, and interview notes. These materials have different authority. The help article describes shipped behavior; interviews describe needs; old slides may describe an abandoned plan. Treating them as interchangeable is how a draft turns an idea into a promise.

Decide what the project is allowed to answer

Start with one campaign or continuing editorial purpose. “Explain the reporting workflow to first-time users” is a useful boundary. “Know everything about our brand” is too broad to test. Write the reader, the decision the content should help them make, the product area, and the topics excluded from this project.

Claude's Projects documentation describes a way to organize related work and project knowledge. That organization does not make every uploaded statement current or correct. Your job is to make the hierarchy understandable and to maintain it as the product changes.

A source pack should answer three questions for any claim: where did it come from, what does it actually establish, and when should it be checked again? That is a more durable starting point than a long collection of tone adjectives. A separate brand voice guide can describe expression once the factual base is clear.

Give each document a job

Create a short index that names the document, its owner, its effective date, and its purpose. Use plain categories such as current product facts, approved examples, audience evidence, and background. The names need not match an application feature; they are an editorial convention your team controls.

Current facts should establish what a reader can do now. Approved examples should show the level of detail and voice you want. Audience evidence should preserve what people said without turning a few interviews into market-wide conclusions. Background can explain earlier decisions, but it should not override current documentation.

Consider a screenshot of the new reporting view. It establishes the visible labels and arrangement at the time of capture. It does not establish that every subscription includes the view, that all connected networks return the same metrics, or that the feature improves revenue. Those claims need their own evidence.

Remove duplicates where possible. If an old and new document must both remain, label the older one as historical and explain why it is retained. A pile of nearly identical filenames is an invitation for both people and assistants to use the wrong version.

Add a compact instruction page

The instruction page should tell Claude how to use the pack, not repeat the entire pack. Specify which source wins when facts conflict. Require a missing-information note when a request depends on something absent. Distinguish a quote from a paraphrase and an observation from a recommendation.

For example, tell the assistant to use current help material for feature availability, use interviews only for attributed qualitative patterns, and ask for verification before including a numerical result. Keep publishing decisions separate from drafting. The existence of an approved example does not authorize reusing the customer's identity in a different campaign.

A practical starting prompt is:

Using the source index, propose three posts that explain one real reporting task to a first-time user. For each, identify the supporting document and the exact claim it supports. List contradictions or missing information before drafting. Do not invent outcomes, customer quotes, plan access, or release dates.

Anthropic's prompt engineering overview recommends defining success criteria and ways to test them before tuning the prompt. Here, success means traceable claims and useful explanations, not a draft that merely sounds confident.

Test the pack with awkward questions

A source pack should be tested on questions likely to expose gaps. Ask whether the reporting view is included in every plan. Ask what happens when a network supplies no data. Ask whether the screenshot reflects an upcoming or released version. A good response may say the pack does not establish the answer.

Then ask a question with a deliberate false premise, such as “Explain why this feature guarantees better engagement.” The assistant should challenge the guarantee because the sources do not support it. If it writes around the premise, improve the instruction and the evidence labels before producing more content.

Use a second test that requires distinguishing audience need from feature behavior. An interviewee wanting daily summaries does not prove the product sends daily summaries. The distinction is particularly useful when building SaaS social content, where roadmap conversations often sit beside documentation of shipped features.

Keep a small record of failed tests. Save the question, what went wrong, the corrected source or instruction, and the expected behavior next time. This prevents a fresh campaign from repeating an already understood error.

Build one source-backed series before expanding

Ask for an outline before polished copy. A useful series might cover locating the report, interpreting one metric, and recognizing a missing-data condition. Each item should solve a separate reader problem and identify the evidence needed to explain it.

Review the outline for overlap. Three posts that all say “make better decisions with data” do not form a useful series. Require an action or distinction in each post. The first might identify a control, the second compare two metric definitions, and the third explain why an empty field is not necessarily zero.

After approving the outline, draft one post and inspect every factual sentence. This close review establishes the standard for later drafts. If the content becomes a visual explanation, move the verified outline into the AI carousel generator and review slide order, screenshots, and captions together.

Keep the source references in the working document even when they do not belong in the final caption. An editor should be able to reconstruct the reasoning without reopening a long conversation and guessing which attachment the assistant used.

Maintain facts without accumulating debris

A project becomes less useful if every correction is added as another file while old claims remain unmarked. When a feature changes, revise the authoritative source index and identify affected drafts. Archive superseded material with a clear status instead of leaving it beside current material under a similar name.

Use a lightweight change note: what changed, which statements are affected, and who checked the replacement. For the reporting example, a change in plan access should trigger a review of captions and calls to action that mention availability. It should not force a rewrite of an unrelated explanation of metric definitions.

A recurring content audit helps locate published material that also depends on changed facts. Project maintenance and public-content maintenance are connected, but one does not automatically update the other.

Hand off an editorial result, not a conversation

Export the approved draft with its source notes, intended destination, media requirements, and unresolved questions. Someone opening the handoff should know which text is final and which material is still background. Include a clear owner for the remaining decisions.

You can manually move approved material into Caroush's content creation workflow. Claude Projects is an editorial workspace; it is not evidence of a verified Caroush connection for Claude web or Desktop. Consult the current Caroush client documentation before planning an MCP route. A useful source pack remains valuable even when the handoff is manual, because it makes the resulting post easier to verify and maintain.