zeljkoobrenovic

Create or edit product bricks for a product domain: root groups, subgroups, bricks, their layered modules (ui/interfaces/worker/stateless-service/service/integration), brick-to-brick dependencies, data dependencies, and external-system dependencies in _config/product-domains/<domain>/product-bricks/product-bricks.json. Use when adding a brick, restructuring brick groups, adding/moving modules across layers, wiring module or brick dependencies, or linking bricks to data assets. Keeps brick and module IDs consistent across products, deployment, streams, teams, evidence, and data assets.

Create or edit product streams for a product domain: outcome-based streams, their outcomes, brick dependencies, and end-to-end flows with steps, key facts, pain points, and step-level dependencies in _config/product-domains/<domain>/product-bricks/product-stream.json. Use when adding a stream, modeling a customer/operator journey as a flow, or wiring stream and step dependencies to product bricks. Keeps stream IDs consistent with JTBD streamsNeeded.

Create or edit the competitive landscape for a product domain: competitor players, their category, HQ, regions, descriptions, sourced business stats with official URLs, and official links in _config/product-domains/<domain>/business/competition.json. Use when adding a competitor, updating market positioning, or refreshing business metrics. Every business stat must carry an official source URL and reported scope — no invented metrics.

Create or edit customer data for a product domain: customer groups, personas, jobs-to-be-done (JTBD), customer journey stories, KPI pyramids, per-customer product strategy, customer insights, and external reference links. Use when adding a customer segment, refining a persona, writing JTBD/journeys, building KPI pyramids, adding sourced insights, or curating external links in _config/product-domains/<domain>/customers/customers.json, insights.json, and links.json. Keeps customer IDs consistent across products, teams, and insights.

Validate a product domain's JSON and cross-file references, then regenerate its static docs. Use after any edit under _config/product-domains/** — adding/changing customers, bricks, products, teams, streams, data assets, competition, or evidence — to confirm JSON parses, IDs are consistent, product-brick/team/module references resolve, and docs rebuild cleanly. The gate every edit-* skill calls before reporting done.

Author a complete, balanced, realistic product domain from scratch under _config/product-domains/<domain>/ — framing, customers, strategy, products/deployment, product bricks, streams, data assets, teams, competition, and evidence — in the right dependency order, with cross-file references kept consistent and docs regenerated. Use when creating a brand-new domain end-to-end, not editing one artifact. Orchestrates the edit-* skills and the validate/audit gates.

Router and index for creating and maintaining Spec-Driven Product Architecture domain data (customers, strategy, jobs-to-be-done, product vision, insights, competition, teams, product bricks, streams, data assets, product deployments). Use when the user wants to work on a product domain but the specific artifact isn't named, when they ask what's possible, or to understand the model, ID conventions, and the validate/regenerate loop before editing _config/product-domains/**.

Create or edit the team and org model for a product domain: org design, team groups, individual teams, team types (stream-aligned/platform/enabling/complicated-subsystem/other), team descriptions, customer/stream/brick/team dependencies, and headcount in _config/product-domains/<domain>/teams/teams.json. Use when adding a team, restructuring org groups, wiring brick/customer dependencies, or sizing teams. Keeps team IDs consistent with brick ownership and data-asset ownership.

Write the checklist modality (checklist.md) of a spec-driven journal post — the operational working checklist behind the record, rendered as the Checklist tab on the post page. Use when asked to add, write, update, or extract a checklist, working checklist, or checklist tab for a post in _journals/*/posts/*/.

Add restrained bold emphasis to a post's prose (index.md or a modality file) so skim readers catch the main argument, preserving the author's wording, voice, and structure. Use when asked to highlight key phrases, make a post more skimmable, add bold emphasis, or apply a "bold highlighter" pass in _journals/*/posts/*/.

Write or revise the detailed main article (index.md) of a spec-driven journal post from its spec.md contract, following the house record style (status highlight, MADR-inspired sections, cross-links). Use when asked to write, draft, expand, or revise a post's main article, index.md, or "the article modality" in _journals/*/posts/*/.

Add inline illustrations to a post's main article (index.md) — propose 2–5 figure placeholders where a visual aids comprehension, generate Gemini/Nano-Banana images for them, and replace each placeholder with a markdown image + numbered caption. Complementary to the explainer-comics modality (this illustrates the article body; comics is its own tab). Use when asked to illustrate, add figures/diagrams/images to, or stage illustration placeholders for a post's article in _journals/*/posts/*/index.md.

Write the comics modality (comics.md) of a spec-driven journal post — an explainer comic of generated panel images derived from spec.md and index.md, rendered as the Comic tab on the post page. Use when asked to add, write, generate, or update an explainer comic, comic strip, comic panels, or comic tab for a post in _journals/*/posts/*/.

Write the dialog modality (dialog.md) of a spec-driven journal post — a two-host, podcast-style conversation derived from spec.md and index.md, rendered as the Conversation tab on the post page. Use when asked to add, write, or update a dialog, podcast script, conversation, or two-host discussion for a post in _journals/*/posts/*/.

Review a spec-driven journal post end to end — the spec, each modality (index/summary/dialog/comics), spec↔modality alignment, and cross-modality consistency — judging structure, argument quality, readability, repetition, language simplicity, grammar, and overall quality. Writes findings to REVIEW.md in the post folder. Use when asked to review, critique, audit, proofread, or quality-check a post, a spec, a modality, or the alignment between them in _journals/*/posts/*/.

Create or refine a post's spec.md — the contract that drives a spec-driven journal post — from source material (an INPUT.md, raw notes, or a described intent), using _wiring/spec-template.md. Use when asked to create, draft, write, improve, or polish a spec, spec.md, or "the contract" for a post in _journals/*/posts/*/, before the article (index.md) is written.

Add or improve Markdown bold emphasis for key phrases in behavioral interview JSON text. Use when highlighting competency briefs, prompts, prompt variants, interviewer intent, evidence, decision criteria, trade-offs, operating mechanisms, red flags, follow-up probes, or rubric signals with **key phrase** markers while preserving valid project data.

Promote a specific behavioral interview on LinkedIn from a provided interview.json URL or path. Use when drafting LinkedIn copy that explains behavioral interviews, their education and interviewing value, the project, and includes both the concrete interview anchor link and the full catalog link.

Review behavioral interview specs in this repository for realism, balance, educative value, interviewer usability, and data quality. Use when asked to critique interviews, audit the catalog, identify gaps, score interview quality, or write/update REVIEW.md with findings and recommendations.

Review behavioral interview specs in this repository for realism, balance, educative value, interviewer usability, and data quality. Use when asked to critique interviews, audit the catalog, identify gaps, score interview quality, or write/update REVIEW.md with findings and recommendations.

Create new behavioral interview specs for the spec-driven-behavioral-interviews repository. Use when adding a new interview dataset, choosing category placement, scaffolding data/book or data/examples entries, filling the JSON schema, or preparing a new interview for the static explorer.

Improve existing behavioral interview specs in this repository. Use when upgrading an interview JSON file, making generic examples more concrete, strengthening strong and weak answer patterns, deepening follow-up probes, improving evaluation rubrics, or aligning an existing interview with the project schema and quality bar.

Add or improve concrete example stories, prompt variants, weak and strong answer variants, and follow-up angles for behavioral interview specs in this repository. Use when a user asks for more concrete examples inside each interview, more variants by role or level, or better example coverage.

Plan, add, and generate visual assets for behavioral interview specs in this repository. Use when deciding where interviews should be illustrated, adding assets.icon, explainerComic, strong/weak answer pattern aiVisual, strong/weak signal visuals, or exampleStories aiVisual fields, running dry-run image generation scripts, or improving visual prompts and generated interview imagery.

Scaffold a new system-design interview dataset from a brief problem description. Use when the user asks to "add an interview", "create a new interview/dataset/case", or "design <X> as an interview" for this explorer. Produces data/<group>/<id>/interview.json, registers it in index.json, builds, and verifies.

Add or update the book-style `technologyChoices` section in Spec-Driven System Design `interview.json` datasets. Use when Codex is asked to add technology options, implementation choices, cloud/self-hosted comparisons, provider choices, tech stacks, or `technologyChoices` to an interview under `data/<group>/<id>/interview.json`, including assigning technology icons and rebuilding generated docs.

Draft engaging daily LinkedIn posts for the Spec-Driven System Design project from local interview datasets or published interview URLs. Use when Codex is asked to promote a System Design Interview of the day, write a LinkedIn/social post for an interview such as data/<group>/<id>/interview.json, turn a spec-driven system design case into marketing/educational copy, or reuse the project's public links and GitHub source link in a post.

Perform an in-depth project-specific review of Spec-Driven System Design interview datasets. Use when Codex is asked to analyze, critique, audit, or review an `interview.json` file under a `data` group and dataset directory, especially for system design soundness, production realism, pedagogical flow, how steps build toward `finalDesign`, concept introduction, schema/rendering fit, or when asked to write a dataset-local `REVIEW.md`.

Find, vet, group, and add credible external reading links for system design, architecture, ML systems, or interview walkthroughs. Use when Codex is asked to do web research for "probe further" resources, further reading, company implementation links, production case studies, official docs, papers, repositories, or to populate fields such as toProbeFurther in interview.json-style datasets.