Industry Deep-Dive Pipeline

Take a single technology, AI, data, cloud, or enterprise-software topic from brief to approved final markdown. Uses prompt chaining plus evaluator-optimizer: a fixed main chain guarantees traceability, and a revision loop after an eight-role panel review guarantees quality.

intent

This skill transforms raw input (topic brief, event, vendor case, policy change, or research material) into a publish-ready deep-dive article through systematic fact verification, originality review, editorial planning, two human gates, deterministic red-line scanning, eight-role expert review, revision, and final evidence packaging. Use it when your topic requires judgment-led analysis, evidence-backed claims, clear boundaries, and a complete audit trail. Do not use it for news flashes, summaries, product manuals, tutorials, marketing copy, vendor conference reports (use vendor-summit-report instead), single-platform LinkedIn observations (use linkedin-industry-observation instead), or batch generation of multi-part series.

inputs

required case bundle (confirm before step 1):

• topic: single sentence; the core subject or question
• source_materials: paths or URLs; research papers, filings, releases, interviews, or proprietary data
• target_reader: job title, seniority, industry, concern; who reads this and why
• target_format: markdown with optional inline metadata; section structure expectations
• length_range: word count floor and ceiling (e.g., 3000-5000)
• writing_profile: file path or JSON ref to private tone, red-lines, no-go topics, and required expertise markers

optional inputs:

• collection or series relationship (context only; does not auto-generate cross-links)
• historical platform signals (engagement data, audience feedback)
• counter-arguments that must be addressed (user hypothesis to verify, not fact)
• new red-lines for this article (extends writing profile)
• timeliness window (publish-by date; affects fact freshness thresholds)
• user's existing assumptions (marked as hypotheses-to-verify, not conclusions)

external references (read before step 1):

• references/planning-schema.md: input validation, case-bundle fields, and planning checklist
• references/evidence-and-originality.md: source tiers (primary, official, academic, news, secondary), fact status codes, and originality judgment framework
• references/writing-profile-interface.md: profile schema, red-line syntax, and tone markers
• references/replay-evaluation.md: LLM replay standards (Fireworks, Kimi, European-AI)

no external API connections required. all processing is internal. external search is discovery only; facts return to primary/official sources for verification.

procedure

step 1: deterministic input diagnosis

inputs: case bundle, topic, source materials, target reader, format, length range, writing profile.

process:

1. Validate all paths and URLs are reachable; confirm dates are parseable; confirm target format and writing profile exist.
2. Judge article type (case study, policy analysis, market shift, product evaluation, etc.), timeliness level (breaking, quarterly, evergreen), fact risk (high = numbers/dates/policy; low = framing/narrative), and sensitivity (regulatory, competitive, brand-related).
3. Extract user's existing judgments and hypotheses; mark them as hypotheses-to-verify, not conclusions.
4. Run:

   python scripts/validate_case_bundle.py --case-dir <case-dir> --stage input --enforce
   

5. Copy templates/case-brief.template.md to 00-case-brief.md; record topic, reader, scope, and type.

outputs: 00-case-brief.md, validation pass/fail, list of missing items (if fail).

edge cases:

• missing source materials: stop, list items, do not guess content.
• invalid writing profile: stop, report path or schema error.
• dates older than 18 months without clear evergreen framing: flag for step 2 verification.

---

step 2: LLM fact table build

inputs: case brief, source materials, evidence-and-originality reference.

process:

1. Extract all numbers, dates, companies, product names, policy status, quotes, and causal claims from source materials.
2. For each fact: run search to discover sources; return to official websites, SEC filings, academic papers, regulatory text, or official press releases to confirm.
3. High-risk facts (numbers affecting judgment, policy dates, product status) require dual-source confirmation or confirmation from a single primary/official source.
4. Record for each fact: original date, verification date, status (confirmed, conditional, deprecated), source tier (primary, official, academic, news, secondary), usable phrasing, and expiry conditions (e.g., "valid until Q2 2025").
5. Copy templates/fact-table.template.md to 01-fact-table.md; populate all fields.

outputs: 01-fact-table.md with 100% traceability; list of unverifiable facts (to delete or downgrade in step 3).

edge cases:

• fact too recent to have independent confirmation: note as "emerging" with single source and confidence tier.
• conflicting sources (e.g., two official statements differ): record both, note conflict, mark status as "unresolved" and flag for step 4 planning.
• source paywalled or deleted: attempt archive.org; if unreachable, mark as "unverifiable" and plan to exclude or downgrade.
• quoted person or company no longer reachable: note date of original quote and context; does not disqualify if quote is verifiable from published record.

---

step 3: LLM originality and competition review

inputs: fact table, planning schema.

process:

1. From the case brief and source materials, extract: core judgment (the single most important claim), analytical framework (how the argument is structured), and signature expressions (unique phrasing or positioning).
2. Search Chinese and English news coverage, analysis, reports, and commentary on the same topic or closely adjacent topics. Search for same-argument different-phrasing variations.
3. Classify findings: public opinion (widely shared view), independent deepening (your framework goes further), verifiable difference (your facts or timing differ), and phrasing collision (same idea, similar words).
4. Proactively identify direct counter-arguments, historical counterexamples, and falsification variables (what data or event would disprove the core judgment).
5. Populate 02-originality-review.md with coverage map, information-gain assessment, competition level, and counter-argument list.

outputs: 02-originality-review.md.

stop conditions:

• core judgment is already well covered with no information gain: stop, suggest merge with existing piece, re-angle, or abandon.
• argument depends on unverifiable facts: stop, request new source materials or revised topic.
• topic can only stand on inflated headline (e.g., "AI will change everything"): stop, suggest narrower scope or stronger fact foundation.

edge cases:

• search returns no exact match but many adjacent topics: document information-gain clearly (what is new relative to those pieces).
• counter-argument is emotionally strong but factually weak: note it anyway; gate A decision-maker decides whether to address it in the plan.
• original research or data (interview, proprietary dataset) is the originality anchor: document source, date, and limitations clearly.

---

step 4: LLM full planning brief

inputs: case brief, fact table, originality review, writing profile.

process:

1. Copy templates/planning-brief.template.md to 03-planning-brief.md.
2. Complete all fields: topic feasibility (can it work?), competition level (crowded vs clear), reader segmentation (who is the primary vs secondary audience?), core judgment (the single claim), argument chain (supporting points in order), originality anchor (why this article, not others?), counter-arguments to address (from step 3), title candidates, section structure, save-worthy vehicle (why publish here, not elsewhere?), risk (regulatory, brand, factual), and series relationship (if any).
3. Keep only decisions that genuinely need human value judgment. Filter out routine editorial choices (section order, examples, transitions).

outputs: 03-planning-brief.md.

edge cases:

• planning brief is ambiguous about the core judgment: return to step 3 or the user, clarify, and re-run step 4.
• no clear originality anchor after step 3: flag in planning brief and pause for gate A to confirm if the article is worth pursuing.

---

gate A: human confirmation of plan

inputs: 03-planning-brief.md, writing profile.

process:

1. Pause. Present the plan to the decision-maker (user or editorial owner).
2. Confirm: core judgment direction (is this the right take?), title direction (does it set up the claim?), length and trade-offs (are we accepting a narrower scope?), controversy handling (how much counter-argument is enough?), platform goal (is this a guide, analysis, or opinion?), and series relationship (is it independent or part of a larger narrative?).
3. Record confirmation explicitly (e.g., "confirmed by [user] on [date]" in the case brief or a separate gate-record file).

outputs: gate-A confirmation record.

stop condition: if gate A is not confirmed, do not proceed to step 5. keep task in progress, do not generate body.

---

step 5: LLM draft article

inputs: confirmed planning brief, fact table, writing profile.

process:

1. Use only the confirmed plan and fact table as sources of truth.
2. Lead with the judgment; unfold evidence and counter-arguments in the order outlined in the plan.
3. Hard rules:
   • Do not introduce new numbers, dates, statuses, or strong conclusions absent from the fact table.
   • Do not include task background, internal notes, publishing metadata, or writing process into the article body.
   • Do not invent sources or secondary claims; if a supporting point is not in the fact table and you are not instructed to research it, use a softer phrasing or mark it for gate B review.
   • Follow the writing profile for tone, red-lines, and expertise markers.
4. Output 04-draft.md. Use only necessary chart or image placeholders (e.g., [CHART: XYZ trend 2020-2025]); do not generate or embed images.

outputs: 04-draft.md.

edge cases:

• writing profile forbids a word or tone that the plan requires: flag in draft as an editorial tension (note, do not attempt to resolve unilaterally).
• fact table has a conditional or unresolved fact: use softer language ("some reports suggest") and note the caveat.
• argument chain has a gap (e.g., step 3 requires a point not in the fact table): either fill it from the fact table with different phrasing, or note it as a missing link for gate B.

---

step 6: deterministic machine gate scan

inputs: 04-draft.md, 01-fact-table.md, writing profile.

process:

1. Run:

   python scripts/scan_draft_gates.py \
     --draft <case-dir>/04-draft.md \
     --facts <case-dir>/01-fact-table.md \
     --profile <writing-profile.json> \
     --output <case-dir>/05-machine-gate.json \
     --enforce
   

2. Scan checks for: unregistered numbers (numbers in draft not in fact table), unregistered dates, credentials or UUIDs in text, personal file paths, metadata or publishing notes in body, antithetical sentences (contradictions), marketing-speak (banned words), colloquial buffers ("arguably", "some say"), and profile red-lines.
3. If scan fails, return to step 5, revise the draft, and re-run. After 2 failed runs, report remaining blockers and do not proceed.

outputs: 05-machine-gate.json (pass/fail and detailed report).

edge cases:

• legitimate domain name or ID looks like a credential: record in writing profile as an exception; re-run scan.
• number appears in a direct quote from a source: if quote is in fact table, mark as exception and re-run.
• marketing word is unavoidable (product name, required jargon): document in profile as context-specific exception.

---

step 7: LLM eight-role review panel

inputs: 04-draft.md (post machine-gate), fact table, originality review, planning brief.

process:

1. Route draft to tech-content-review-panel (a pre-configured multi-role review service). The panel includes roles: G1 (generalist reader), G2 (target-reader expert), R1 (research/fact), R2 (argument logic), R3 (tone/voice), R4 (structure/clarity), G3 (final gate), T1 (technical correctness).
2. Collect all feedback. Copy templates/review-record.template.md to 06-review-record.md.
3. Classify each opinion: must-fix (factual error, breach of profile, or logic failure), should-fix (improvement with no downside), optional (style choice), or tension (reach vs professionalism, depth vs speed, expression vs risk).
4. Record all opinions and classifications in the review record.

outputs: 06-review-record.md.

edge cases:

• panel member proposes a new fact not in the fact table: do not accept it into the draft. instead, note it in the record for potential step 2 follow-up if the user decides to broaden scope.
• panel feedback contradicts the confirmed plan: classify as a tension and flag for gate B.
• panel member requests a major structural change post-gate A: classify as a tension (series-consistency vs single-article independence).

---

gate B: human resolution of genuine tensions

inputs: 06-review-record.md, 03-planning-brief.md, confirmed plan.

process:

1. Pause only when genuine tensions appear in the review record: reach vs professionalism, depth vs completion rate, risk vs expression, series consistency vs article independence, or plan vs panel feedback.
2. For each tension, present the trade-off to the decision-maker. record their preference.
3. Fact errors, missing sources, format errors, and clear red-line breaches are fixed directly by the flow (step 8) and never escalated to gate B.

outputs: gate B decision record.

stop condition: if gate B is not confirmed, do not proceed to step 8. keep task in progress with tensions noted.

---

step 8: LLM revision to final

inputs: 04-draft.md, 06-review-record.md, gate B decisions, fact table.

process:

1. Address all must-fix items from the review record.
2. Address all should-fix items unless gate B decided otherwise.
3. Handle tension items per gate B decisions.
4. Hard rules:
   • Do not accept new, unverified facts that appear in the panel review. if a new fact is critical, route it to step 2 (fact table) for verification.
   • Do not re-introduce red-line breaches from step 6.
   • Record unadopted opinions and reasons in the revision record to avoid re-raising them in step 9.
5. Output 07-final.md.

outputs: 07-final.md, revision record.

edge cases:

• revision introduces a new fact: stop, verify it in step 2, then re-run step 8.
• unadopted opinion is raised again by the machine gate or a second read: document decision and move forward.

---

step 9: deterministic plus LLM re-check

inputs: 07-final.md, fact table, originality review, planning brief.

process:

1. Re-verify all facts in the final against the fact table; flag any facts new to the final (step 8 should not have added them).
2. Re-verify timeliness: are expiry conditions in the fact table still valid? do any dates need updating?
3. Re-run machine gate:

   python scripts/scan_draft_gates.py \
     --draft <case-dir>/07-final.md \
     --facts <case-dir>/01-fact-table.md \
     --profile <writing-profile.json> \
     --output <case-dir>/05-machine-gate-final.json \
     --enforce
   

4. If scan fails, fix the issue and re-run once. do not proceed until scan passes.
5. Conduct a human full read: catch AI tone artifacts, logic jumps, posture overreach, and consistency gaps that machines miss.
6. Against the confirmed plan, verify: core judgment is clear, scope matches plan, title aligns with claim, and tables/charts match narrative.
7. Output 08-final-check.md (a brief memo documenting full-read findings).
8. Run final validation:

   python scripts/validate_case_bundle.py --case-dir <case-dir> --stage final --enforce
   

outputs: 08-final-check.md, final validation report.

stop condition: if final validation fails, do not proceed to step 10. document blockers and fix them before packaging.

edge cases:

• full read detects a logic jump the panel missed: return to step 8, revise, and re-run step 9.
• final has a different tone than the confirmed plan: return to step 8, align to profile, and re-run step 9.
• fact in final has expired (timestamp in fact table shows expiry passed): update fact or mark conditional.

---

step 10: deterministic final package assembly

inputs: 07-final.md, 01-fact-table.md, 02-originality-review.md, 03-planning-brief.md, 06-review-record.md, 08-final-check.md.

process:

1. Copy templates/final-package.template.md to FINAL-PACKAGE.md (delivery note).