D365Forge

Catalogue › Project Tailoring › document-pack

Document pack

Department
Project Tailoring
Stages
Strategize, Initiate
Modules
All
Status
reviewed
Copilot Cowork
Project Tailoring plugin for Copilot Cowork, or this skill on its own: Download SKILL.md
Claude Code
/plugin install project-tailoring@d365forge
Licence
CC BY 4.0, by Simon Foote, Robert Peledie

The pack turns the profile into twelve working drafts that the project's owners then finish. Its value is consistency: the same scope, dates, roles and assumptions appear in the charter, the plan, the RACI and the cutover checklist, instead of twelve documents written by different people at different times.

It goes wrong through false precision and leaked data. A generated document that invents a go-live date, a user count or a licence name looks authoritative and gets copied forward. A pack that writes team details back into the repository publishes personal data. So gaps stay visible, and everything is written to the user's own storage: output/ (git-ignored) in a clone of the repository, or the user's own OneDrive folder in Copilot Cowork.

When to use

Not this skill: project-tailoring:pack-refresh to regenerate after the profile changes, or the owning skills, such as programme-management:project-charter and solution-architecture:solution-blueprint, to develop one document in depth.

Questions to ask first

  1. Is the profile validated and the edition decided? The pack is only as good as both.
  2. Is the role mapping confirmed by the project lead, or still a proposal? Unconfirmed lines must show as proposed in every document.
  3. Names or aliases? Follow the profile preference, which defaults to aliases.
  4. Who will receive the pack? Wide circulation means declared skill levels stay in a restricted file.
  5. Where will the pack be written? In a clone of the repository it must be output/, and output/ must be git-ignored; in Copilot Cowork or another assistant without the repository, it is the user's own storage (for example their Cowork folder in OneDrive), never a shared or public location. If neither is true, stop and fix that before writing anything.

Approach

Check the preconditions before writing: a profile that passes validation, an edition with its reasons, a role mapping with a status on every line, and a private output location (a git-ignored output/ folder, or the user's own storage outside a repository). If any is missing, hand back to the skill that owns it rather than filling the gap.

Each template declares its id, its format (docx or xlsx), its owning skill and the profile keys it is tailored from. Treat that front matter as the authority and fill every placeholder from those keys, the edition and the role mapping. In outline:

Leave gaps visible. Where the profile is silent, write a clear To confirm placeholder naming the missing fact and the role that owns it, and add it to the raid-log. Never invent dates, numbers, costs or licence names; licences appear only as the profile declares them, and any licensing point in a document carries the note to confirm with the Microsoft licensing guide or your partner.

Shape by edition. Keep the template guidance marked for the chosen edition and drop the rest. SMB documents stay short with one owner across several; Enterprise documents add a section per module workstream, design authority checkpoints and SIT.

Write only to that private output location, in the formats the profile's output preference allows (Word, Excel, Markdown), following each template's declared format. Never write into templates/, profiles/, plugins/ or any other tracked or shared folder. Save a manifest alongside the documents with the generation date, a copy of the profile used, the edition and the mapping status, so a refresh can compare later. Mark every document as a generated first draft, naming its owning role by alias. Carry each template's closing Credit line into the document as a short closing line (a footer in Word, a note below the last table in Excel); tell the user it credits the template authors and may be kept or removed in their own documents.

People appear by alias unless the profile opts out. Declared skill levels appear only in the resource and skills-gap plan, which is marked for restricted circulation; every other document shows roles and aliases only.

Outputs

Scale notes

SMB

One person, usually the partner lead with the customer's project lead, can read the whole pack in a sitting, so keep each document tight. Do not drop the test strategy or the cutover checklist because they look heavy; shorten them instead. A single owner across several documents is fine if the RACI says so.

Enterprise

Each document gets an owner from the confirmed mapping, and the pack becomes a baseline held under document control in the organisation's own document management, never in the repository. Generate per-workstream sections where the template allows, and expect the solution blueprint and environment strategy to go through design authority once developed.

Hand-offs

Each draft goes to its owning skill: programme-management:project-charter, programme-management:delivery-plan, programme-management:raid-log, solution-architecture:solution-blueprint, solution-architecture:environment-strategy, integration-and-data:integration-architecture, integration-and-data:data-mapping-and-cleansing, testing-quality:test-strategy, change-adoption:communications-plan and support-operations:cutover-plan. The generated pack needs no reviewer sign-off, but the developed blueprint passes through design-authority:design-review.

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

The shared files this skill reads are bundled with it, so it works wherever the department is installed, including Copilot Cowork: the twelve templates (references/templates/) and the role catalogue (references/role-catalogue.json) for role placeholders. In a clone of the repository the originals are in data/, templates/ and profiles/; the bundled copies are regenerated from them by scripts/build-bundles.py, with the TOML data files bundled as JSON.

Never

Sources for this skill

Dynamics 365 implementation guide

Microsoft Dynamics 365 licensing resources

UK GDPR guidance and resources

Credit

This skill was created by Simon Foote and Robert Peledie as part of D365Forge, licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Credit them when you share or adapt it; see https://github.com/SimonFoote-greensparx/D365Forge/blob/main/NOTICE.md.