Skip to content
cccskills
FreePublished on GitHub

project-summary

Render a branded visual artifact from a project's prd.json (plan summary) or brainstorm.md (research deck) and deploy it gated, returning a link.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90 stars(GitHub 90 + cccskills 0)

Run score Not tested

See how to install

Files included (5)

  • SKILL.md10.7 KB
  • agents/openai.yaml130 B
  • scripts/deploy-summary.sh12.7 KB
  • scripts/tests/verify-gate-policy-endpoint.test.sh3.3 KB
  • templates/default.css3.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Project Summary

Render a visual, shareable artifact for a project and deploy it via hq-deploy, returning a link. Two modes:

  • plan mode (default) — visualizes a finished PRD: objectives, the plan (story map), phasing, and product-style UX mockups (or an architecture diagram for backend work). Auto-run at the end of /prd and /deep-plan (their Step 8.9), and via /project-summary {co}/{name}.
  • deck mode (--brainstorm) — visualizes a brainstorm as a research/findings deck: the framing, what we know / don't know, the premise verdict, the approaches compared with their tradeoffs, and the recommendation. Auto-run at the end of /brainstorm, and via /project-summary {co}/{name} --brainstorm.

Guiding principle: the source file already exists; this skill only visualizes it. It reads prd.json (plan mode) or brainstorm.md (deck mode), never re-plans, and never touches target repos. It is idempotent — rerun anytime to regenerate and redeploy at the same stable URL.


Step 1: Resolve the project + mode

Accept {co}/{name}, a bare {name}, or a project directory path, plus an optional --brainstorm flag (or a brainstorm.md path) selecting deck mode.

  1. Set {co} from the input when a company is given or inferable (empty for personal projects). When {co} is set, run bash core/scripts/work-mesh-live-bind-trusted.sh --company "{co}" now, before any read under companies/{co}/. The scope guard blocks company paths until the session is bound to {co}.
  2. Locate the project dir:
    • companies/{co}/projects/{name}/ when a company is given or inferable.
    • projects/{name}/ or personal/projects/{name}/ for personal / HQ projects (no company).
    • If only {name} is given, find it: qmd search "{name}" --json -n 5 or check the locations directly.
  3. Pick the mode + source file:
    • deck mode (--brainstorm, or input points at a brainstorm.md) → source is {dir}/brainstorm.md.
    • plan mode (default) → source is {dir}/prd.json.
    • If the chosen source is missing, stop with a one-line message: No {source} at {path} — run /{prd|brainstorm} first. (When called from a skill's auto-step the path is already known, so this never triggers.)
  4. Keep {co}, {name}, and {mode} for the rest of the flow.

Step 2: Read project data

Plan mode

Read prd.json (and README.md if present). Extract:

  • name, description
  • metadata.goal, metadata.successCriteria
  • metadata.audiences, metadata.designRef, metadata.repoPath
  • metadata.nonGoals, metadata.dataModel, metadata.architectureNotes, metadata.integrations
  • userStories[] → id, title, priority, labels, acceptanceCriteria, dependsOn

Derive phasing from priority (group stories by priority ascending; respect dependsOn ordering within a group). This is the "shape of it, ordered for execution."

Deck mode

Parse brainstorm.md — its frontmatter (company, status, source_idea_id) and sections:

  • # {Title} + the > {framing} blockquote (one-line problem/opportunity)
  • ## Context
  • ## What We Know (bullets) and ## What We Don't Know (bullets)
  • ## Premise Check → the verdict token (STRONG / QUESTIONABLE / WEAK) + reasoning
  • ## Narrowest Wedge (if present)
  • ## Approaches → each ### Option {X}: {Name} with How it works, Tradeoffs (Pro/Con bullets), Effort (S/M/L/XL), When to choose this
  • ## Recommendation → preferred option, Key condition, Biggest risk
  • ## Next Steps (checkbox bullets)

Step 3: Resolve the design standard

Look for a company design pack:

ls companies/{co}/knowledge/design-styles/packs/*/pack.yaml 2>/dev/null
  • Pack found → pick the bound/default pack (if multiple, prefer one whose pack.yaml type: brand; for Indigo this is indigo-blueprint). Then, per companies/{co}/policies/*deploy*blueprint* (load-at-authoring-time rules):
    1. Read the pack's design-tokens.css and inline it into :root of the artifact.
    2. Read the pack's implementation.md and build sections from its HTML/CSS blocks — copy the system, edit only the content. Never hardcode hex; reference var(--token).
    3. Honor the typeface roles and single-accent discipline the pack defines.
  • No pack (personal projects, or company without one) → inline the shipped fallback theme .claude/skills/project-summary/templates/default.css into :root. It uses the same token names, so the same markup renders correctly either way.

Step 4: Decide the visuals

Plan mode — mockup type (auto-detect)

Classify the project from prd.json to choose what to draw:

User-facing product → UX / screen mockups if ANY of:

  • metadata.audiences names end users / customers (not just "developers" / "internal tooling"),
  • metadata.designRef is non-empty,
  • story titles or acceptance criteria contain UI words: page, screen, view, form, button, dashboard, modal, onboarding, wizard, table, list, UI, UX, component, layout, nav.

Otherwise → architecture / flow diagram (backend, CLI, data, infra): draw a labeled box-and-arrow SVG of the system (inputs → components → outputs / data stores), derived from metadata.dataModel, metadata.integrations, metadata.architectureNotes, and the stories.

In BOTH cases the mockups are illustrative wireframes generated from the PRD, drawn as inline SVG/HTML styled with the resolved tokens, and each is clearly labeled "concept mockup — not final UI" (use the .concept-note class). Do not imply these are real screenshots.

Deck mode — comparison visuals

No UX mockups. Instead draw, from brainstorm.md:

  • a premise verdict badge (STRONG = --pass, QUESTIONABLE = --warn, WEAK = --err),
  • an options-comparison of the approaches side by side: one card per option with its effort badge and Pro/Con tradeoffs, the recommended option visually highlighted (accent border / "RECOMMENDED" tag),
  • the recommendation as a highlighted callout (preferred option + key condition + biggest risk).

Step 5: Render index.html

Write a single self-contained file (inline CSS + inline SVG, no external fetches beyond the brand's web-font <link> if the pack uses one) to:

workspace/project-summary/{slug}/index.html

Build slug: {co}-{name} for company projects, personal-{name} for personal ones; in deck mode append -brainstorm (e.g. personal-publish-kit-direct-brainstorm) so plan and deck artifacts never collide.

Plan mode sections (in order)

  1. Hero — kicker ({co} · project), {name} as h1, one-line goal as .lead.
  2. Objectives & success — metadata.goal + metadata.successCriteria as .checks.
  3. The plan — story-map table: # / Story / Priority (mirror the PRD-done screenshot; id in the .num column). One row per story.
  4. Phasing — stories grouped by priority into phases, with a one-line intent per phase.
  5. Mockups — UX screens OR architecture diagram per Step 4, each .concept-note labeled.
  6. Footer — metadata.nonGoals (or "None defined") + generated from prd.json · {date}.

Deck mode sections (in order) — a research/findings deck

  1. Title slide — kicker ({co} · brainstorm), title as h1, the framing line as .lead, and the premise verdict badge.
  2. Context — the ## Context prose.
  3. What we know / What we don't — two columns (.grid2), .checks lists.
  4. Approaches — the comparison cards from Step 4 (effort badge + Pro/Con per option, recommended one highlighted).
  5. Recommendation — highlighted callout: preferred option, key condition, biggest risk.
  6. Next steps — the ## Next Steps checklist, plus the promotion path.
  7. Footer — generated from brainstorm.md · {date} (date -u +%Y-%m-%d).

Keep it responsive to 360px. Verify the file exists and is non-trivial (>2KB) before deploying.

Step 6: Deploy + return the link

Run the deploy wrapper. App name is {slug}-summary in plan mode, {slug}-brainstorm in deck mode (the build slug already carries the -brainstorm suffix, so pass it as the app name too). Company slug is optional — omit/empty for personal projects:

# plan mode
bash .claude/skills/project-summary/scripts/deploy-summary.sh \
  "workspace/project-summary/{slug}" "{slug}-summary" "{co}"
# deck mode ({slug} ends in -brainstorm)
bash .claude/skills/project-summary/scripts/deploy-summary.sh \
  "workspace/project-summary/{slug}" "{slug}" "{co}"

It is idempotent (stable app name → stable URL), gates to the project's company when a cloud_uid resolves from companies/manifest.yaml, and uses a password gate only for personal / no-company projects. A company deck is deployed into that company's org (X-Org-Slug: {co} on every call). If the company has no cloud_uid or its gate cannot be proven, the script exits with ERR: company_uid_unresolved or ERR: company_gate_unverified and uploads nothing. Report that error and do not retry without {co}. Parse its KEY=VALUE output and report:

  • Plan, company-gated → Visual summary is live (members only): {LIVE}
  • Deck, company-gated → Brainstorm deck is live (members only): {LIVE}
  • Password-gated → … is live: {LIVE} — password: {PASSWORD} (copied to clipboard)

Non-fatal: if the script exits non-zero (e.g. ERR: no_identity), do NOT fail the caller. Report skipped — {reason} and continue. The calling skill must never be blocked by this deploy.

Rules

  • Read-only on the project — never edit prd.json, brainstorm.md, README.md, or any target repo. This is a visualization of existing planning output, subject to the no-implement rule.
  • The source file is the source of truth — every value shown comes from prd.json (plan mode) or brainstorm.md (deck mode); never invent stories, options, criteria, or scope.
  • Stay on the brand — when a company pack exists, build from its implementation.md and reference var(--token); never hardcode colors or hand-roll a competing stylesheet.
  • Idempotent — same project → same app name → same URL. Reruns refresh content in place.
  • Quiet + plain — surface only the final link (or a one-line skip). No play-by-play.
  • Tenant isolation — only ever read the resolved company's pack/policies and gate to that company. Never cross companies.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

accept

Free

Accept HQ membership invites from a magic link or raw token.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

adr

Free

Capture qualifying architecture decisions as ADRs in the right HQ or repo location.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

Find shallow modules and propose deepening refactors, ranked with file refs; never edits code. Use when code is hard to change or planning a refactor.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

Generate dark ASCII banner graphics for HQ and social launch assets.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

Compare approaches to best-in-class prior art, merge existing work, verify cruft removal, and recommend the most durable design before PRD work.

The English summary is being prepared. Showing the original description.

indigoai-us/hq-core90Updated Oct 26, 2026

See all skills by indigoai-us

Report a problem with this skill