A Project + Skill stack for one team

Build a Project-plus-Skills bundle for a workflow that exists in your team right now — not a hypothetical. The deliverable is a bundle your teammate can adopt without asking you a single question. That constraint is the real design brief.

Choosing the workflow

Good candidates are workflows that recur weekly, involve stable criteria, and currently require a new person to spend 20-40 minutes getting context before they can do productive work. Common examples: new-hire onboarding, incident response, weekly customer support triage, sprint retrospective preparation.

A workflow is a poor candidate if the criteria change faster than you can update the Skill files, or if the work requires so much local context that no written procedure can substitute for experience. A Skill stack does not replace judgment; it removes the overhead of re-establishing context that is stable.

What the bundle contains

A complete stack has three layers. Do not skip any of them.

Layer one: a Project with a system prompt that defines the role and output standards for this workflow. The system prompt should not be a general description of the domain — it should specify the output format and the quality bar, and reference the Skills that exist for specific sub-tasks. Attach only the documents a teammate would need: a template, a style guide, a checklist. Not your personal notes. Not reference material a teammate could find themselves.

Layer two: at least two Skills that the Project invokes for discrete sub-tasks inside the workflow. The sub-tasks are the parts of the workflow that recur identically — the parts where the procedure is fixed and the judgment calls are documented. For incident response: one Skill for writing the initial incident report, one for the timeline reconstruction, one for the post-mortem template. Each Skill is a standalone file that can be installed and used independently of the Project — this is important for teams where some members only need part of the workflow.

Layer three: a README — one page, in the repository — that tells a new user: what the workflow is, which Project to open, which Skills to install, and what the first five minutes look like. The README assumes the reader is competent but unfamiliar with your specific workflow. No acronyms without expansion. No references to internal tools without naming the tool.

The test

Hand the bundle to a teammate without explaining it. Do not walk them through it. Watch what they ask.

Every question they ask is a gap in either the system prompt, a Skill, or the README. Write down each question. After the session, trace each question to its source and fix the source — not the teammate's understanding, the document. A system prompt that requires a 15-minute walkthrough to use is not a system prompt; it is an interview.

If your teammate gets through the README, installs the Skills, opens the Project, and runs the first task without asking a question, the bundle is ready.

A note on scope

It is better to ship a bundle that covers 80% of the workflow reliably than a bundle that attempts 100% and covers none of it well. The first version of the bundle should cover the most common, most structured part of the workflow. Edge cases go in the gotchas sections of the Skills. Genuinely novel situations go outside the bundle entirely — they require human judgment, and a Skill that tries to handle everything handles nothing well.

If you get stuck

The system prompt is long and the teammate still asks questions about basic procedure. The procedure does not belong in the system prompt — it belongs in a Skill. The system prompt should describe the role and the output standard. The Skill should describe the steps. Separate them.

The Skills work correctly but the teammate does not know which one to invoke for which situation. The README is missing the decision logic. Add a section to the README: "When you are doing X, invoke Skill A. When you are doing Y, invoke Skill B." This decision logic is often the most valuable part of the README.

The bundle worked well for simple cases but failed on a complex one during the handoff test. The complex case exposed an implicit assumption in one of the Skills. Add that assumption to the gotchas section. If the assumption is load-bearing enough that the Skill cannot handle its absence, add a step early in the procedure that checks for the assumption and surfaces the failure early.

Cross-reference

l2 covers Project setup. l5 covers Skill writing. l6 covers publishing Skills to a shared repository. l8 covers the maintenance cadence for keeping the bundle accurate over time.

Deliverable

A GitHub repository containing: at least two Skill files, the system prompt as a text file, and the README. The teammate install path — clone the repository, install the Skills, open the Project — must work end-to-end without your intervention.