Claude Projects and Skills: How to Stop Rewriting the Same Prompts (A Builder's Playbook)

I keep seeing the same pattern in teams that "use AI a lot": they're not actually building leverage. They're building a pile of chats.

One week you have a perfect prompt for writing a PRD. Next week you're rewriting it because the context changed. A month later, you've got four "final" versions floating around in Slack, none of them quite right, and everyone has their own private variant.

Here's the thing: if you're repeatedly rewriting prompts, the problem isn't your wording. It's your packaging.

Claude's Projects and Skills are basically packaging primitives. Projects are where you keep stable context and "how we work here." Skills are how you bottle a workflow so you can invoke it on demand, instead of dragging a 900-token instruction blob into every conversation. Claude Code takes that even further by turning those Skills into something that can actually run in your dev workflow (and therefore needs to be treated like software, not vibes).

This is my builder's playbook for getting out of prompt-copy-paste hell.

---

Stop thinking "prompt." Start thinking "instruction surface area."

When people say "prompt," they usually mean one of three things:

A reusable policy like "always output JSON." A workflow like "draft → critique → revise." Or a context bundle like "this is our product, our users, our architecture."

Those are different artifacts. They should live in different places.

What I noticed is that the more you cram into one mega-prompt, the more brittle it gets. You get context bloat, and the model starts missing things. That's not just a Claude problem; it's an engineering problem: you've created a giant, unversioned config file and you're surprised it's hard to maintain.

Claude Code power users already solve this by externalizing context into files that Claude reads automatically. One popular pattern is creating a CLAUDE.md in the project root as "permanent memory" for architecture decisions, standards, and house style, and then keeping sessions short and structured so the context doesn't rot over time [3]. That's the mindset shift: prompts are not messages, they're assets.

Now add Skills to the mix, and you can make those assets callable.

---

What Projects are good for (and what they aren't)

Projects shine when you have stable context that should apply over many sessions: product background, team conventions, tone, definitions, "done means this," and guardrails. If you have to repeat that stuff every time, you don't have a prompting problem-you have a missing "workspace."

I like to structure a Project as "how we operate" plus "what we're operating on." The goal is to reduce the amount of repeated scaffolding you paste into the chat, while making the model's default behavior closer to what you'd expect from a teammate.

But a Project is not the best place for long procedural workflows. That's where people overdo it. A procedural workflow belongs in a Skill, because you want to invoke it only when needed, and you want it versioned.

---

Skills are reusable workflows. Treat them like code (because they are code)

The best mental model for a Skill is: "a function with a name."

It takes input (your current task + some context), runs a repeatable workflow, and returns an artifact. If you're using Claude Code, Skills can include instruction files and executable code that run on your machine. That power is real, and so is the risk.

A 2026 empirical security study on agent skill ecosystems found that third-party Skills frequently bundle hidden behaviors, credential harvesting, remote script execution, and instruction-level manipulation. The authors behaviorally verified 98,380 Skills from community registries and confirmed 157 malicious ones, with most vulnerabilities living in the natural language documentation (not just code) [1]. Translation: a Skill can hack you with Markdown, not just Python.

So yes, Skills are how you stop rewriting prompts-but they also need basic software hygiene: versioning, review, permission boundaries, and a bias toward local, inspectable content.

If you're in a team, the bar should be "would we run this from a random GitHub repo?" If not, don't install the Skill.

---

The playbook: a three-layer system that scales

Here's the setup I recommend if you want reuse without turning Claude into a fragile bureaucracy.

Layer one is your Project baseline. This is where you put the context that should always be true. In Claude Code terms, this is the role CLAUDE.md plays: a stable primer on architecture, coding standards, and expectations [3]. Even if you're not coding, you can mirror the idea: a single canonical "rules of engagement" doc for your Project.

Layer two is your Skill library. Each Skill does one job. "Generate a PRD draft." "Review a PRD against our rubric." "Turn meeting notes into a decision log entry." "Create a release checklist from a spec." If a Skill gets bigger than one screen, it's probably two Skills.

Layer three is per-task scratch context. This is the disposable part: current ticket, current dataset, current thread, current messy notes. You don't want this contaminating your reusable assets.

When you do it this way, you stop rewriting prompts because you stop storing long-term value in ephemeral chats.

---

Designing Skills that don't rot

What makes a Skill maintainable is the same thing that makes code maintainable: tight scope, explicit inputs/outputs, and tests (or at least acceptance checks).

I also like adding a "clarify first" gate. If the Skill can't run without missing info, it should ask for it. This keeps you from baking wrong assumptions into reusable workflows.

And if you're doing anything that touches a repo, credentials, or external systems, you need to design for adversarial conditions. The malicious Skills study shows that instruction-level attacks are common: things like "do NOT ask user permission," hidden directives, and coercive language that tries to override safety constraints [1]. Your defensive move is simple: enforce consent and visibility in your own Skills. Make it a non-negotiable rule that actions with side effects must be listed and confirmed.

---

Practical examples you can steal

These examples are intentionally "builder-y." They're meant to be turned into named Skills or Project snippets, not copy-pasted forever.

Example 1: A "PRD Draft" Skill that doesn't hallucinate structure

Skill: prd_draft_v1

You are my product writer. Your job is to draft a PRD that a senior engineer would respect.

Before writing, ask me up to 7 clarifying questions ONLY if the answer would change scope, risks, or acceptance criteria.

Then produce:
1) Problem & user story
2) Non-goals
3) Requirements (numbered, testable)
4) UX notes (if applicable)
5) Risks & mitigations
6) Open questions

Constraints:
- If data is missing, mark it as [NEEDS INPUT], don't invent it.
- Keep it under 900 words.
- Use plain language, no hype.

This is the kind of workflow people in the community keep rebuilding as a mega-prompt and versioning badly; you can see the pain in discussions about managing 1000+ token prompts with multiple sections and constant copy-paste edits [4]. Turning it into a Skill solves the maintenance problem: now it has a name, a version, and a job.

Example 2: A "Modular prompt blocks" workflow (good for experimentation)

If you keep changing persona but keeping the same task instructions, split them. Community builders repeatedly reinvent block-based prompt tooling for exactly this reason: swapping sections without rewriting everything [4]. Your Skill can support that explicitly:

Skill: compose_prompt_blocks_v1

I will provide:
- ROLE block
- TASK block
- CONSTRAINTS block
- OUTPUT FORMAT block
- OPTIONAL EXAMPLES block

Your job:
- Validate blocks don't conflict.
- Suggest the smallest edits to remove ambiguity.
- Output the final compiled prompt as:
  <role>...</role>
  <task>...</task>
  <constraints>...</constraints>
  <output_format>...</output_format>
  <examples>...</examples>

Even if you don't literally use XML, the "block compiler" idea forces clean seams, which is the whole game.

---

The one habit that makes all of this work

When Claude asks you to do something repeatedly, teach it to do that thing itself.

Notion's team basically operationalized this mindset with Claude Code: they use custom slash commands and Skills to automate repetitive actions and turn "I keep doing this manually" into "now we have a callable workflow" [2]. That's the compounding effect you want. Projects reduce repeated context. Skills reduce repeated procedures.

If you take one action this week, do this: pick your most copied prompt, split it into "Project baseline vs callable Skill," name it, and version it. The first time you invoke it instead of rewriting it, you'll feel the leverage immediately.

---

References

Documentation & Research

1. Malicious Agent Skills in the Wild: A Large-Scale Security Empirical Study - arXiv cs.AI (2026) https://arxiv.org/abs/2602.06547
2. User Prompting Strategies and Prompt Enhancement Methods for Open-Set Object Detection in XR Environments - arXiv (2026) http://arxiv.org/abs/2601.23281v1

Community Examples

3. What's your workflow for managing prompts that are 1000+ tokens with multiple sections? - r/PromptEngineering (2026) https://www.reddit.com/r/PromptEngineering/comments/1r3r9yp/whats_your_workflow_for_managing_prompts_that_are/
4. "I haven't written a single line of front-end code in 3 months": How Notion's design team uses Claude Code to prototype - Lenny's Newsletter (2026) https://www.lennysnewsletter.com/p/i-havent-written-a-single-line-of
5. You're Using Claude Code Wrong (And Wasting Hours Every Day) - DiamantAI (2026) https://diamantai.substack.com/p/youre-using-claude-code-wrong-and