Run any Skill in Manus with one click

docs-book-author

Stars8

Forks4

UpdatedJune 21, 2026 at 04:03

Assemble or extend the printable, textbook-style BigBlueBam manual (the DOCX and PDF offered from /docs). Use when asked to build the downloadable manual, add or refresh a chapter, write chapter intros/callouts/quizzes, or change the book's design. Produces a bold, colorful, per-app book from the SAME content as the web docs, then converts to PDF.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

eoffermann

eoffermann/BigBlueBam

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

screenshot-capture

eoffermann/BigBlueBam

Produce realistic, fully-populated screenshots of any view in the BigBlueBam suite from declarative YAML recipes — auth, content seeding, deterministic capture, and a manifest. Use when creating/updating docs or marketing-site assets, or refreshing captures after a UI change.

2026-06-178

github-issue-cull

eoffermann/BigBlueBam

Triage, investigate, mitigate, and (after sign-off) resolve the open GitHub issues on eoffermann/BigBlueBam. Builds a dated issue_mitigations_<YYYYMMDD>.md dossier, posts an "investigating" acknowledgement on each issue, implements least-disruptive fixes on per-issue branches, has an independent agent re-verify each fix from the code alone, reports to Eddie, and on his go-ahead merges main→stable + closes addressed PRs. Use when asked to work through / cull / clear the repo's open issues. Pairs with the github-pr-cull companion skill for the unmerged-PR pass.

2026-06-158

github-pr-cull

eoffermann/BigBlueBam

Triage the open/unmerged pull requests on eoffermann/BigBlueBam — assess each PR's approach against the code, then merge / revise / close with a documented rationale, under the same Eddie-sign-off gate as the issue cull. Invoked as the Phase 7 follow-up of github-issue-cull, or standalone when asked to clear out stale PRs. Records into the same dated dossier.

2026-06-158

suite-help-system

eoffermann/BigBlueBam

Standard for building and maintaining BigBlueBam's unified in-app help system: a "(?)" Help Center launched from every app's top bar (TOC, search, index, cross-references) sourced from docs/apps/<app>/help.md, plus right-click "Help: <element>" deep-links on UI elements that the help docs reference. Use when building, extending, or updating the help feature for any app.

2026-06-158

help-doc-authoring

eoffermann/BigBlueBam

Standard for authoring and reviewing BigBlueBam per-app help.md files. Use whenever writing, structuring, or checking a help document for any app in the suite. Defines the canonical template, the User Story format, source priority, writing conventions, and the acceptance checklist.

2026-06-148

ui-debug

eoffermann/BigBlueBam

Debug a UI feature by writing its expected-behavior user story, then walking the full stack top-down — UI control → handler → hook → API route → backend logic → data effect — and smoke-testing it live on the local dev stack with self-cleaning test data. Use when a UI element "does nothing", silently fails, or "looks wired but isn't", and before declaring ANY UI feature done. Nothing is "done" until the UI is proven to call real logic and that logic is proven to do what the story says.

2026-06-148

name	docs-book-author
description	Assemble or extend the printable, textbook-style BigBlueBam manual (the DOCX and PDF offered from /docs). Use when asked to build the downloadable manual, add or refresh a chapter, write chapter intros/callouts/quizzes, or change the book's design. Produces a bold, colorful, per-app book from the SAME content as the web docs, then converts to PDF.

docs-book-author: design and assemble the BigBlueBam textbook manual

You turn the live web docs into a book someone would happily buy on Amazon to learn the software: bold, colorful, per-app, genuinely useful. You do NOT rewrite the instructional content. You layer engagement on top and lay it out with a designer's eye.

Read first: docs/docs-book-style-guide.md. It is the design system (page, color, typography, chapter openers, the recurring graphic elements, the quiz convention, the per-app accent palette, the production pipeline). This skill is how you execute it. If the two ever disagree, the style guide wins; update it.

The pipeline at a glance

docs/apps/<app>/help.md ──(build-manual.mjs)──▶ site/src/content/manual.generated.json
                                                          │  (same text the /docs page renders)
scripts/docs-book/enhancements/<app>.json  ◀── you author this layer
                                                          ▼
node scripts/docs-book/build-book.mjs --app=<app> --pdf
                                                          ▼
site/public/downloads/BigBlueBam-*.docx  ──(LibreOffice)──▶ .pdf

The generator (scripts/docs-book/build-book.mjs) reads the chapter content verbatim, applies the per-app design system, injects the enhancement layer, and writes DOCX. With --pdf it converts via headless LibreOffice. --app=<app> builds one chapter (a sample); no flag builds the full 16-chapter book.

Your job per chapter: author the enhancement file

Each chapter's only authored layer is scripts/docs-book/enhancements/<app>.json. A chapter still renders without one (default opener, no quiz), but the file is how it gets its personality. Schema:

{
  "app": "bam",
  "tagline": "Plan it, drag it, ship it.",          // one line, white on the opener
  "intro": "2 to 4 sentences...",                    // authored chapter intro (the card)
  "atAGlance": ["3 to 5 short 'best at' bullets"],
  "pullQuotes": [                                     // lift a key line, point at a feature
    { "after": "<exact phrase from the chapter>", "text": "<the pull-quote line>" }
  ],
  "callouts": [
    { "after": "<exact phrase>", "type": "tip|important|warning|note|tryit", "text": "<one tight paragraph>" }
  ],
  "quiz": [
    { "type": "mc", "q": "...", "choices": ["...","..."], "answer": "<exact matching choice>", "where": "Section name" },
    { "type": "short", "q": "...", "answer": "...", "where": "Section name" }
  ]
}

Anchoring rules (this is where it goes wrong)

after is a substring that must appear in the chapter's source text. The generator collapses whitespace before matching, so a phrase that crosses a line wrap still matches. Even so, pick a distinctive 6 to 12 word phrase and copy it from the real text. If a callout does not appear in the output, your anchor phrase is wrong: grep the chapter for it.
Anchors match paragraph text AND list-item text. Many key facts (defaults, limits, gotchas) live in the "Key concepts" bullet list; anchor to those.
Each anchor fires once. Use distinct phrases.

Authoring rules (non-negotiable)

No em dashes anywhere. Reword. (House rule across all BigBlueBam writing.)
No invented facts. Intros, callouts, and quizzes describe only what the source chapter actually says. Tool counts and behavior come from the docs.
Quiz answers must be findable in the chapter, and every question cites the section in where. Mix a couple multiple-choice with a couple short-answer. Make them about real, useful behavior, not trivia.
The Introduction chapter (introduction) has no quiz. It is a suite overview, not an app lesson. Do not author a quiz (or answer key) for it; the generator hard-skips the quiz for introduction regardless.
Agent language is capability, never turnkey or free. "An agent can run a sprint", never "agents run your sprints" or anything implying agents ship deployed or free. (See docs/marketing-voice.md.)
Callouts: one idea each. Tip = a smarter way. Important = will bite you. Warning = destructive/irreversible. Note = clarification. Try It = a one-line exercise the reader can do right now.
Pull-quotes point at a marquee feature, at most one per major section.

Build and verify

Author enhancements/<app>.json.
Build: node scripts/docs-book/build-book.mjs --app=<app> --pdf from scripts/docs-book/.
Verify the output, do not trust that it generated. Unzip the DOCX and grep word/document.xml, or read the PDF, and confirm against the definition of done:
- The opener renders (full-color panel, CHAPTER N, app name, tagline, intro card).
- Every callout you authored appears (grep -o ">TIP<", >NOTE<, >WARNING<, >TRY IT<). A count of 0 means a broken anchor: fix the phrase.
- Both pull-quotes appear; every screenshot has a Figure N.M caption.
- The "Check yourself" quiz and "Answer key" are present (except the Introduction chapter, which has none).
- Zero em dashes: unzip -p <docx> word/document.xml | grep -c "—" is 0.
If the PDF step fails, a stale LibreOffice instance (or a self-update) may hold the single-instance lock. Kill soffice.exe/soffice.bin, wait a few seconds, and re-run. The generator already kills-and-retries once.

Full book

node scripts/docs-book/build-book.mjs --pdf builds all 16 chapters in order (Bam first, then alphabetical) with front matter (title page) and per-chapter sections. Output: site/public/downloads/BigBlueBam-Manual.{docx,pdf}, the committed artifacts the /docs download buttons serve. Run it whenever a chapter or its enhancement file changes, then commit the regenerated artifacts.

Per-app accent palette

bam #2563EB, banter #7C3AED, beacon #059669, bearing #0891B2, bench #4F46E5, bill #16A34A, blank #9333EA, blast #DC2626, blueprint #0284C7, board #4338CA, bolt #EA580C, bond #DB2777, book #0D9488, brief #D97706, bureau #6D28D9, helpdesk #E11D48. (Mirrored in the generator's ACCENT map and the style guide.)

Hard rules recap

Same content as the web docs, verbatim. No em dashes. No invented facts. Quiz answers live in the chapter. Capability agent language. Verify the output, never assume it rendered.