Skill: New Project Scaffold
Evidence Produced
| Category | Artifact | Format | Example |
|---|---|---|---|
| Release evidence | Project initialisation evidence pack | Markdown plus filesystem validation | selected methodology, created paths, preserved files, validation result, rollback, and handoff |
Inputs
| Artefact | Required? | Purpose |
|---|---|---|
| Approved project profile and roadmap | yes | Drive scaffold scope |
| Repository conventions and existing files | yes | Preserve local structure |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|---|---|
| Project documentation scaffold | Project team | No destructive overwrite, links resolve, roadmap represented |
Capability contract
Read/search are required. File creation requires explicit scaffold authority. Do not install tools, initialise remote services, or publish artefacts implicitly.
Degraded mode
Fallback without write access: return the directory tree and file templates as a proposed patch.
Decision rules
| State | Action | Failure avoided |
|---|---|---|
| Empty project | Create approved minimal scaffold | Context overload |
| Existing partial documentation | Fill gaps and preserve content | Destructive replacement |
| Conflicting methodology files | Stop and reconcile with roadmap | Contradictory process |
Domain anti-patterns
- Creating empty placeholder documents. Fix: include purpose, owner, and next action.
- Copying a universal scaffold. Fix: derive files from the approved roadmap.
- Replacing existing project rules. Fix: preserve and reconcile them.
- Adding tool-specific adapters as canonical truth. Fix: keep sources model-neutral.
- Claiming setup is complete without link checks. Fix: validate the scaffold and references.
Trigger
User says any of: "start a new project", "create a new project", "scaffold a project", "new client project", "initialize project"
First Step: Shared Understanding
Start with the engine's own design gate: skills/sdlc-meta/world-class-engineering
§2 "Create Shared Understanding". Record user journeys, non-goals, scale and trust
boundaries, ranked quality attributes and hard constraints, and state the ceremony
class (spike, bounded or architectural) before scaffolding anything.
If the Superpowers plugin is present, its process skills (for example
superpowers:brainstorming) may be used; this engine's gates remain authoritative.
How to Use the Chwezi SDLC Documentation engine (PRIME Workflow)
Every skill in this engine follows the PRIME methodology (Kodukula & Vinueza, 2024):
| Step | What the Consultant Does | Chwezi SDLC Documentation Equivalent |
|---|---|---|
| P — Prepare | Gather all project data before prompting | Populate _context/ files with real stakeholder data, not placeholders |
| R — Relay | Submit the prompt with precise instructions | Invoke the SKILL.md (tell Claude: "Run the [skill name] skill") |
| I — Inspect | Critically evaluate AI output against objectives | Read the generated document; check it against _context/ source files |
| M — Modify | Refine if output diverges from expectations | Edit the output or update _context/ and re-invoke the skill |
| E — Execute | Approve and build the final artifact | Run build-doc.sh to produce the .docx |
Quality rule: Never execute (build the
.docx) without completing Inspect and Modify. The first AI output is a draft, not a deliverable.
The _context/ directory is the Project Input Folder (PIF) for this project — a living repository of project-specific context that feeds every skill. The richer the PIF, the higher the quality of every generated document (Kodukula & Vinueza, 2024).
Interview Protocol
After brainstorming, ask these questions ONE AT A TIME. Do not ask the next until the previous is answered.
Q1: What is the project name? (This becomes the directory name — use hyphens,
e.g., Livecare-Hospital-ERP)
Q2: In 2–3 sentences, what does this software do and what problem does it solve?
(This pre-populates _context/vision.md and is used to deduce the domain)
Q3: Which methodology best fits this project?
- A) Waterfall — regulated industry, fixed scope, formal IEEE 830 SRS required
- B) Agile — iterative delivery, user stories, Scrum/Kanban
- C) Hybrid — formal SRS for backend/core + agile user stories for frontend/features
Q4: Who is the project owner / primary client contact name?
Domain Deduction (NO USER INPUT REQUIRED)
After Q2, Claude analyses the project description and deduces the domain automatically using these signals:
| If description mentions... | Deduce domain |
|---|---|
| patients, hospitals, clinics, EMR, EHR, PHI, medical, healthcare, pharmacy, nursing | healthcare |
| banking, payments, ledger, transactions, trading, insurance, loans, fintech, accounting | finance |
| students, courses, LMS, grades, enrollment, university, school, e-learning | education |
| inventory, POS, e-commerce, retail, products, orders, cart, warehouse (retail context) | retail |
| fleet, shipments, tracking, logistics, freight, warehouse (supply chain), delivery, routing | logistics |
| government, citizens, public services, procurement, permits, case management, municipal | government |
| farm, crops, livestock, agriculture, harvest, planting, irrigation, cattle, poultry, FMIS | agriculture |
If ambiguous (two domains equally match): Ask the user during the brainstorming session — e.g., "This sounds like it could be healthcare OR government — which primary domain applies?"
If no domain matches: Use other — no domain defaults are injected; scaffold
only the directory structure and empty context files.
Additional Guidance
Extended project-scaffold guidance was moved to references/new-project-deep-dive.md to keep this entrypoint compact and fast to load.
Use that deep dive for:
Scaffold ActionsQuick LinksWhat We Are BuildingDocument Inventory by PhaseContext Files (_context/)Progress SummaryImmediate Next StepsProblem StatementGoalsStakeholdersSuccess CriteriaFeature Name- Additional deep-dive sections continue in the reference file.
