design-agentic-content-generation

name	design-agentic-content-generation
description	Use when designing or materially reviewing an Agentic content-generation or content-transformation project, especially when its purpose, routes, artifacts, evidence, authority, evaluation, feedback, human intervention, recovery, or adoption boundaries remain unsettled; applies an inquiry-led method and stops before implementation or production authorization.
metadata	{"short-description":"Navigate Agentic content project design decisions"}

Design Agentic Content Generation

Use this Skill to reason about an Agentic content-production system whose consequential design choices are still unsettled. Do not use it merely to write, summarize, translate, or edit content, or to implement an approved design whose control boundaries are settled.

This is a principles-driven inquiry method, not a lifecycle, maturity model, assessment checklist, or production workflow. It may begin at any live uncertainty and use only the methods that could change the decision.

Core principle:

Design the smallest project-specific system that can produce useful value and support justified correction. Add structure, automation, evaluation, and human control only where the local evidence, obligations, and consequences justify them.

This Skill may frame, compare, challenge, narrow, defer, block, or hand off a design. It must not generate production content, scaffold or operate the system, declare it ready or compliant, or grant production authorization.

Persistent Commitments

• Treat former project Profiles as optional recipe aliases, not mutually exclusive or exhaustive types.
• Use diagnostic dimensions as optional, overlapping lenses, not a required baseline, score, ontology, Schema, or global project label.
• Bind evidence, consequence, authority, intervention, validation, and recovery to the smallest unit where they differ. A project summary cannot average away a local red line.
• Preserve facts, supported interpretations, assumptions, disputes, unknowns, blockers, exclusions, and deferred decisions distinctly.
• Separate semantic production, deterministic checks, independent evaluation, binding decision, release authorization, and execution as logical responsibilities. They do not imply a fixed team or one Agent per responsibility.
• Let existing domain Schemas, policies, release systems, validators, permissions, and audit records retain their authority. A Markdown design may refer to them but cannot replace them.
• Prefer reversible and locally scoped choices while evidence is incomplete. More governance, automation, or review is not inherently more trustworthy.

Navigate from the Live Uncertainty

Start where the consequential decision is unclear, not at a prescribed first step. Identify the affected artifact, route, population, version, channel, action, or other local unit; why the uncertainty matters; and what evidence or authority could change the current position.

Possible entry points include:

• unclear purpose, audience, success, cadence, or operating boundary;
• unclear decomposition, variant behavior, inheritance, or artifact authority;
• disputed truth, provenance, freshness, semantic loss, or validation claim;
• unclear Agent agency, human contribution, decision authority, or release authority;
• plausible failure without an observable correction or recovery path;
• feedback that does not reopen an owning decision;
• repeated practice whose burden, benefit, or formalization should be reconsidered.

These entry points overlap and are not exhaustive. Move laterally when one inquiry exposes another consequential uncertainty. Do not visit unrelated entries to make the analysis look complete.

Use Inquiry Moves as Needed

The following moves are a repertoire, not stages. Use, combine, revisit, or omit them according to the decision at hand.

Clarify the intended transformation. Ask what initial condition should become what target condition, for whom, under which constraints, and what observable evidence would distinguish useful success from merely fluent output. Separate intrinsic needs from policy requirements, current technical limits, preferences, and non-goals.

Locate consequential differences. Split the design only where purpose, consumer, evidence, freshness, authority, artifact ownership, reversibility, validator, disposition, recovery, or downstream propagation changes. Avoid both one global route and unnecessary per-item machinery.

Expose epistemic status. State what is known, inferred, assumed, disputed, unavailable, blocked, or deliberately deferred. Ask what evidence would discriminate between genuinely available alternatives; do not manufacture alternatives for routine choices.

Trace authority and lineage. Determine which source, artifact, policy, person, institution, or runtime owns semantic intent, evidence, a binding decision, a projection, a release record, and action execution. Track invalidation and correction only where downstream dependence makes them consequential.

Match responsibility to the claim. Use Agents for semantic reasoning and candidate generation, deterministic tools for mechanical properties, independent evaluators for claims the producer cannot self-certify, and qualified humans for values, disputes, lived context, institutional authority, or consequential decisions. One actor may hold several non-conflicting responsibilities in a low-impact context.

Close a local trustworthy loop. Where a claim or action is consequential, connect the intended result to observable evidence and freshness, a validator and criterion, a disposition and authority, useful feedback, the earliest owning route-back, and evidence for stopping or reopening. Retry only after information gain from new evidence, constraints, capability, method, or a materially revised hypothesis.

Challenge a governing assumption. Select a credible failure, dependency change, counterexample, or baseline comparison whose result could revise, narrow, block, or reopen the design. Challenge depth follows local consequence, exposure, uncertainty, reversibility, and remedy—not a project-wide tier.

Choose a bounded disposition. When evidence or authority is insufficient, narrow scope, hold, label, defer, block, seek evidence, or hand off. Do not convert uncertainty into optimistic completion.

Optional Design Lenses

Use a lens only when its answer could change an artifact, route, validator, authority, intervention, recovery action, adoption boundary, or stop condition:

• Epistemic operation: what knowledge change is attempted?
• Artifact behavior: how is the result consumed, rendered, or executed?
• Temporal form: what changes, expires, recurs, or arrives as an event?
• Variant topology: how do sources, outputs, populations, and inherited decisions branch or merge?
• Evidence and consequence: what can be wrong, who is affected, and how reversible or remediable is it?
• Control relation: who may propose, inspect, decide, interrupt, authorize, and execute?

Values may be multiple, unknown, disputed, or different by route or action. Add a project-specific lens when it changes a real decision. Do not infer global readiness, autonomy, maturity, or risk from these prompts.

Honor Triggered Hard Boundaries

Method freedom does not make applicable obligations optional. Before advancing an affected recommendation, resolve, narrow, or explicitly block it when there is:

• a confirmed legal, policy, licensing, privacy, accessibility, security, scientific, or domain obligation;
• material effect on rights, eligibility, access, safety, livelihood, or remedy;
• an externally authoritative claim, binding decision, production release, or consequential side effect;
• version-sensitive approval, contested authority, conflict of interest, or weak evaluator independence;
• broad or repeated exposure that materially amplifies a plausible consequence, obligation, containment failure, or recovery problem;
• difficult reversal, weak containment, weak remedy, or harm that technical rollback cannot undo;
• human review whose capacity, evidence access, accessibility, or no-response behavior could invalidate the control.

The required treatment is local to the triggered boundary. It may include stronger evidence, independent evaluation, actual decision authority, a safe state, correction or appeal, scoped runtime authorization, monitoring, or reduced automation. These are obligations when applicable, not an ordered review sequence.

Preserve Continuation and Revision

Use whatever form best supports the project—prose, decision notes, a table, diagram, or an existing project artifact. Do not emit empty sections or force a stable field layout. Preserve enough meaning for another human or Agent to continue without reconstructing the decision:

• the current bounded recommendation, disposition, or blocker and its affected scope;
• material evidence, assumptions, disagreements, exclusions, and freshness limits;
• meaningful alternatives considered and why the present position is provisional or preferred;
• unresolved uncertainty, the next discriminating evidence, and who can obtain or decide it;
• actions that remain blocked or unauthorized;
• observable events that reopen the decision, its earliest owning point, and affected descendants;
• the boundary between design guidance and implementation or production authorization.

Iteration means reopening the smallest affected decision after information gain—not replaying this method. Retain the previous rationale, state what changed and what the new evidence does not prove, update affected descendants, and stop when further inquiry has no expected decision value.

Treat project cases as evidence about the method, not automatic additions to it. Keep a novel issue local unless it reveals a clear fit-boundary error; it may be retained as a counterexample without changing reusable guidance. Promote it into a scoped recipe, reusable lens revision, or deterministic helper only after structurally similar evidence recurs in enough varied cases to establish the mechanism and consumer. Change the behavioral kernel only after repeated evidence across heterogeneous projects; retire structure that changes no decisions or outcomes.

References

Load references only when they can change the live decision:

• references/routing-and-patterns.md: mixed routes, operating envelopes, legacy Profiles, variants, inheritance, continuous or batch behavior, recipe conflicts, or artifact lineage.
• references/human-intervention.md: consequential human contribution, actual authority, independent review, release decisions, stale approvals, safe states, review capacity, accessibility, correction, or appeal.
• references/systems-lenses.md: a named mechanism remains unclear and a systems lens could change the hypothesis, evidence requirement, design move, or stopping decision.
• references/validation-release-and-evolution.md: disputed validation claims, failure hypotheses, route-back, recovery, local reopening, adoption boundaries, or evidence for changing the project or the method.

How to Improve This Skill

If real use reveals a possible improvement, keep the task moving and use report-biaoo-skill-feedback. If unavailable, retain a privacy-safe Biaoo/skills issue draft rather than submitting from this session.