consulting-pptx-skill: a rulebook-first Claude Code skill for consulting decks

The problem is not layout, it is that the AI forgets between sessions

Most slide generators sell you a template. This one sells you a text file. The README is explicit that the most valuable artefact in the repository is references/slide-rules.md, roughly 110 rules accumulated one line at a time from real document reviews: put the conclusion in the title, no rounded corners, do not draw a border around a filled box, one term per document, premises and definitions on the left with consequences on the right. The stated reason for writing them down is that an AI resets its memory every session, so verbal corrections do not stick. A file does.

The audience is narrow and specific. You need Claude Code installed, you need to produce decks that look like consulting deliverables, and you need to care about the difference between a slide that renders and a slide a reviewer would accept. The repository is the public version of a system the authors say they use weekly for proposals and reports. If your decks are internal status updates, the 110 rules will read as overhead.

How the pipeline actually runs: rules in, HTML out, checks in between

The workflow has four stages and the README states them in order. First the agent reads slide-rules.md. Then it assembles a deck one slide at a time by pulling parts out of the part libraries. Then scripts/check_deck.py runs a mechanical check against the rules. Finally references/content-review-prompt.md is handed to a different agent that has not been told how the deck was built, so it reads the output fresh and reports problems in Japanese wording, logic and internal contradiction. Only the accepted findings get applied.

The parts are plain HTML. templates/freeform_parts_16x9.html holds 27 parts (cover, overall map, table of contents, section divider, arrow chevrons, premise-to-consequence, axis tables, claim panels, evaluation tables, distribution charts) and is described as the high-frequency file. templates/freeform_parts_more_16x9.html adds 35 more (executive summary, stacked bars, bridges, scatter plots, comparison tables, matrices, issue trees, roadmaps, Gantt charts) and is described as the low-frequency fallback. Each file is 16:9 with one section per slide. scripts/new_deck.py takes part numbers, extracts only those parts into a single HTML file, scopes the CSS from both libraries so they do not collide, and renumbers the pages.

The catalogue is 62 types, and the README is careful to say that is not a ceiling. Real decks combine and break the types within the rules. The catalogue PDF is positioned as a source of layout ideas, to be discarded when it does not fit. That framing is honest, and it is also a warning: the parts library will not carry a deck on its own.

Installing it and building a first deck

Installation is a clone into the Claude Code skills directory. The README says this single step is enough to get the rules, the parts and the checker.

git clone https://github.com/carnot-tech/consulting-pptx-skill.git ~/.claude/skills/consulting-pptx-skill

Two optional steps exist. The real-rendering layout check needs Node.js, and the setup script installs playwright plus Chromium. Checking a .pptx file with check_deck.py needs python-pptx. The README notes that check_deck.py and new_deck.py run on the Python standard library alone, so neither optional step is required to start.

cd ~/.claude/skills/consulting-pptx-skill && npm run setup
pip3 install python-pptx

To see what parts exist, list them. The output is the part numbers and their type names, which is how you choose what goes into a deck.

python3 scripts/new_deck.py --list

Then generate a draft by passing part numbers in order. The README gives this exact example, and the resulting file is a single HTML deck you open in a browser.

python3 scripts/new_deck.py --parts b01,b02,m05,b06,b09,b10 --title "資料名" -o mydeck.html

Replace the placeholders with real content. The README names them: body text is Text 1, item labels are ラベル 1, headings are タイトル 1, numbers are 00, years are YYYY年, sources are 出典：Source 1. Any placeholder left behind is a FAIL in the checker. Note that each section's title field contains only the type name, with no sample claim sentence, deliberately, so that you write the title from your own storyline rather than copying a sentence pattern.

Run the mechanical check until it reports zero failures, then optionally the rendering check for footer overlap and overflow.

python3 scripts/check_deck.py mydeck.html
node scripts/check_layout.mjs mydeck.html

Export to PDF with headless Chrome. The README gives the macOS binary path; the flags suppress the header and footer.

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless --disable-gpu \
  --no-pdf-header-footer --print-to-pdf=mydeck.pdf mydeck.html

What the checker can and cannot catch

check_deck.py handles both HTML and PPTX input, and a --template flag lets you inspect the part libraries themselves. One check is worth calling out because it is unusual: a mismatch between an "N steps" claim in a title and the numbering in the body is a FAIL. That catches a specific and common error where a heading promises four items and the slide lists three.

Everything else the checker does is rule conformance and placeholder detection. It does not judge whether the argument is any good. The README is clear that the fresh-eyes review is a separate stage with a separate prompt, and that you adopt only the findings you agree with. Two limitations follow. First, the mechanical check is only as good as slide-rules.md, so a firm with different conventions gets a checker enforcing someone else's conventions until the file is edited. Second, the layout check depends on playwright and Chromium, which means the optional setup step is required if footer overlap and overflow matter to you. The README does not document what check_layout.mjs does when Chromium is missing.

The PPTX question, and why the exporter is gone

This is the constraint that decides most adoptions. The deck is HTML. The PDF is produced by Chrome. There is no automatic HTML to PPTX conversion, and the README states this plainly. If a client demands an editable .pptx file, the documented options are to hand over the PDF, or to copy slides by hand out of assets/SuperTemplate_62type.pptx, a 62-type sample deck where the README says every slide is editable. That file is described as a sample for manual copying, not as the canonical source for the parts.

A JSON-to-editable-PPTX exporter used to exist. The README says it was removed because it was rarely used, and that it survives in the repository at the git tag pipeline-archived. So a team that needs programmatic PPTX output is looking at either resurrecting that tag or building the conversion themselves. Neither is documented as supported.

The colour and type defaults live in the :root variables at the top of each part library's style block, warm palette with a cream ground, dark brown text and brown accents, Mincho for headings and Gothic for body text. The README says a navy set of values is included as a comment. Rebranding means editing both files to the same values, which is a manual step with a real failure mode: change one file and the two libraries disagree.

How it differs from template-first deck tools

The obvious comparison is a PowerPoint template pack or a template-driven generator, where you pick a theme and fill in slides. The difference here is where the constraint lives. In a template pack the constraint is visual and enforced by the file format. Here the constraint is textual and enforced by a Python script that reads your HTML, which means the rules are editable, diffable and reviewable in a pull request. You can add a line to slide-rules.md the day a reviewer corrects you, and the checker picks it up on the next run.

The cost of that approach is that nothing is enforced at the moment of authoring. A template makes an off-brand slide hard to build. A rulebook makes it easy to build and then fails it afterwards. That is a deliberate trade: the README argues that what determines a good slide is the adjustment after assembly, splitting a table in two, rewriting a right column as consequences, reading only the titles straight through to check the story holds. The catalogue and parts exist to get a rough draft out fast so that time goes into that adjustment. If your team will not do the adjustment pass, the parts library alone will produce decks that pass the checker and still read poorly.

Licence and the cost of keeping it current

The licence is MIT, and the README also asks that the final page's source line carry a note that the deck was made with consulting-pptx-skill. That is a request in the documentation rather than a licence term, so treat the two separately; this is not legal advice and the LICENSE file is the authority.

Upgrade cost is low in the mechanical sense. The checker and generator use only the Python standard library, and package.json exists solely to pull playwright for the rendering check, with node_modules gitignored. There is no release history in the repository metadata, so there are no versioned migration notes to follow and nothing to pin.

The real maintenance burden is the rulebook. The README's own advice is to append your firm's conventions and review comments to slide-rules.md one line at a time so the file grows into a house-specific asset. That means the file diverges from upstream immediately, and merging later changes becomes a manual reconciliation. The last push to the default branch was on 2026-09-10, so the repository is recent, but the README does not describe a contribution or merge process for downstream rule edits.

Editorial conclusion

Adopt it if you produce consulting-style decks in Japanese and already run Claude Code, because the value sits in slide-rules.md and the checker rather than the parts. Skip it if you need editable .pptx output from the pipeline, since the README states HTML to PPTX conversion is not included and the JSON-to-PPTX exporter was removed. Before committing, run new_deck.py on three part numbers, run check_deck.py on the result, and read slide-rules.md to see whether its 110 items match how your firm actually reviews documents.

Frequently asked questions

Official sources

1. carnot-tech/consulting-pptx-skill on GitHub
2. Issues
3. License: MIT
4. README