Engineering ai-driven-dev 18 min read

Narrowing audience.primary Clarifies Sister Pillar and Spoke Design

Narrowing a pillar's audience.primary to one reveals excluded personas as cluster design gaps, clarifying sister pillar and spoke roles.

Published 2026-05-25 Takumi Morimoto

When people hear “narrowing” the audience of a pillar, most designers react with “that reduces the readers we can reach.” In practice, the opposite is true. When you narrow audience.primary to a single persona, the personas that don’t fit become visible as design gaps in the cluster, and the roles of sister pillars and spokes emerge naturally. The shift here is from “narrowing = eliminating” to “narrowing = the starting point for overall design.”

This article uses the mcluhan engine (context compression engine) pillar design as a case study to explain how narrowing audience.primary derives the article structure of the entire cluster. The target audience is content architects and senior engineers responsible for structural design of pillars and spokes.

→ For the premise of two-axis design around cluster and persona, see Cluster and Persona — Designing the Outward/Inward Axis.

The Design Decision to Narrow audience.primary to One

The roles and syntax of primary / secondary

The audience field in brief YAML has a two-level structure:

audience:
  primary: "senior-engineer"    # narrative の主軸
  secondary:
    - "architect"               # cross-link で誘導する対象
narrative_weight:
  primary: 75
  secondary: 25

primary is the sole persona that determines the narrative center of gravity in the body. narrative_weight.primary: 75 means 75% of the body is narrated from the senior-engineer perspective. The remaining 25% briefly covers the secondary persona’s concerns (trade-offs that an architect would care about, etc.).

The key point is that primary is limited to one. Listing two or more personas as primary is prohibited by the audience-tracks.json schema.

G11 handles the existence check for audience.primary (missing → fail), but the case of “primary defined multiple times” is not included in G11 (scripts/blog-gate.ts only checks for the presence of /^\s{1,4}primary:\s*\S/m). Prevention of multiple definitions is enforced by prompt conventions in the brief generation phase (the SKILL.md side).

What gets determined when you narrow to one

The moment you set audience.primary: "senior-engineer", the following are locked in:

  • H2 ordering: Arrange in order of senior engineers’ interests — implementation details → pitfalls → design core
  • Example granularity: Expand code snippets and command examples without omission. No need to explain “why that command is used”
  • Technical vocabulary threshold: Terms like grep -rn, yaml.safe_load(), narrative_weight can be used without explanation
  • Types of analogies: Draw examples from OSS libraries and system design contexts

If you change the same article to audience.primary: "architect", the H2 ordering becomes why of design decisions → trade-offs → implementation examples, and while technical vocabulary remains, the analogies lean toward system-wide consistency and future extensibility.

Excluded Personas Make Sister Pillar / Spoke Gaps Visible

When primary = architect in a tech pillar, content for business personas becomes a gap

When you narrow a tech cluster pillar to audience.primary: "architect", content for business cluster personas (executive / marketing-head / pm-product, etc.) becomes a gap. This gap is not a problem — it is a design signal.

When the gap becomes visible, two design options clarify:

  1. Design a sister pillar separately for the business cluster persona (rewrite the same topic for a different audience)
  2. Compress the content for business personas into a brief section at the end of the tech pillar body and place a cross-link to the business-facing pillar

Option 1 is used when the topic’s importance is high and appeal to both personas is necessary. In the mcluhan engine case, 2026-05-mcluhan-business-strategy (audience.primary: marketing-head / executive) was designed as a sister pillar against the tech version 2026-05-mcluhan-engine (audience.primary: senior-engineer).

The retrofit results are recorded in blog-ops/retros/2026-05-18-persona-taxonomy-drives-narrative.md. reset-timeline: executive, mcluhan: senior-engineer, bateson tech: senior-engineer, bateson business: business-owner. There are no specific recorded sections or paragraphs showing prose quality changes before and after the retrofit.

The background behind narrowing audience.primary to senior-engineer in the mcluhan pillar was a remark by the user during the 2026-05-18 session pointing out “it was supposed to be dual audience but it’s skewing tech” (trigger field in blog-ops/retros/2026-05-18-persona-taxonomy-drives-narrative.md). No specific sections or paragraphs are recorded.

The design rationale for a sister pillar that fills the gap

The rationale for designing a sister pillar is the “size” of the gap. Judge by the following criteria:

  • 3 or more personas in the gap: Worth standing up a pillar in a separate cluster (e.g., 3 of 6 business cluster personas are uncovered)
  • KPIs of gap personas differ from the main KPI: Pursuing both KPIs in the same article dilutes effectiveness (e.g., pursuing lead-gen and hiring brand in one article)
  • Gap personas are a major traffic source: If search intent diverges in SEO, splitting articles avoids keyword competition

In the mcluhan engine case, search intent differed significantly between the tech cluster (senior-engineer) and business cluster (marketing-head). The tech side focused on “pipeline design” and “persona SSOT,” while the business side focused on “owned media improvement” and “content quality.” This was sufficient rationale to design a separate sister pillar.

The sister pillar strategy for 2026-05-mcluhan-business-strategy was decided in the 2026-05-18 session. It is recorded in blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md, and the sister pillar for bateson (business-strategy) was newly created in the same-day commit 57e22ed, etc. The timing of the brief creation for mcluhan-business-strategy can be confirmed in the git log.

Rather than discarding secondary personas, the basic pattern is to direct them via cross-links. Place navigation like the following at the end of the tech pillar body:

For the mcluhan engine from a business perspective, see [Using mcluhan for Owned Media Strategy](/magazine/2026-05-mcluhan-business-strategy).

For this navigation to work, you need to compress “points that business readers find interesting” into 1-2 places within the tech pillar body. For example, briefly place a “business impact — how this design affects KPIs” section in the final H2 of the tech pillar, and direct readers to the business sister pillar for details.

Examples of natural navigation text within a pillar body

Navigation text should function as “complementary” rather than “promotional.” The following patterns work:

  • Question form: “The impact of this design on business decision-making is covered in detail at ~”
  • Prerequisite form: “This spoke targets tech cluster readers. For business perspective background, reading ~ first will deepen understanding”
  • Comparison form: “The tech implementation perspective is covered in this article; ROI and operational cost perspectives are covered in ~”

The number of cross_links a typical pillar has varies by pillar. For example, 2026-05-mcluhan-engine.yaml has 2 cross_links set (2026-05-magazine-reset-timeline and 2026-05-mcluhan-business-strategy). Around 2–5 is a rough guide depending on the number of related spokes and sister pillars.

Implementation: brief schema and pillar-relations.json

In a spoke’s brief, parentPillarSlug and cross_links declare the relationship structure:

parentPillarSlug: 2026-05-mcluhan-engine    # この spoke の親 pillar
cross_links:
  - "2026-05-mcluhan-business-strategy"     # sister pillar への cross-link
  - "2026-05-cluster-persona-outer-inner-axis"  # 同 cluster 内の関連 spoke

parentPillarSlug declares the pillar the spoke belongs to, and becomes the basis for designing “entry points to this spoke” in the pillar’s H2. cross_links declares cross-cluster links (tech → business, business → tech) and becomes the foundation for link graph generation.

Viewing the entire cluster’s gaps in pillar-relations.json

blog-ops/config/pillar-relations.json is the SSOT for surveying the overall cluster structure. You can see at a glance which pillar has which sister pillars and which spokes hang from it:

{
  "topicClusters": {
    "mcluhan-owned-media": {
      "pillar": "2026-05-mcluhan-business-strategy",
      "sisterPillars": ["2026-05-mcluhan-engine"],
      "spokes": []
    }
  }
}

Entries where spokes: [] remains empty visualize “gaps of spokes not yet designed.” After narrowing audience.primary, you can see at a glance which personas are short on content.

The blog-tech-write skill reads pillar-relations.json as an additional spoke reference (F), confirms all relationships in the same topicCluster, and then ensures completeness of cross-links.

Summary — Narrowing Becomes the Starting Point for Overall Design

Narrowing audience.primary to one is not about making excluded personas “invisible.” It is an act of making excluded personas visible as “gaps to be designed,” and clarifying the roles of sister pillars and spokes.

A summary of what narrowing determines:

  1. Narrative center of gravity toward the primary persona (H2 ordering, vocabulary, example granularity) is confirmed
  2. Design rationale for cross-link destinations toward secondary personas (sister pillars, spokes) becomes visible
  3. Gaps in pillar-relations.json (undesigned spokes) can be listed at a glance

A pillar transforms from an article “anyone can read” to one “where specific readers can take something away” — this is only possible through the design chain that starts with this narrowing.

→ For gate design that structurally prevents audience.primary omissions in the pipeline, see Designing Gates That Fail on Missing Persona.

SHARE Share on X B! Hatena Bookmark