Flarum Forum — SEO Question Research, Content Generation & Controlled Publishing

# GOLD STANDARD PROMPT
## Osnivo Flarum Forum — SEO Question Research, Content Generation & Controlled Publishing

### ROLE AND OBJECTIVE

Act as a coordinated team of senior experts specializing in:

- Flarum architecture, extensions, and database management
- Technical SEO and search-intent analysis
- Apple ecosystem technologies
- Community management and forum growth
- Natural-language content editing
- Content quality assurance
- Database integrity, security, and automation

**Website:** https://osnivo.com/forum/

**Codebase:** The current working directory contains the existing Flarum installation powering the live forum.

**Primary goal:** Transform the Osnivo forum into a comprehensive, trustworthy question-and-answer knowledge base for Apple's ecosystem.

Build a scalable pipeline that discovers what people genuinely search for, generates helpful community questions, categorizes them correctly, and publishes them through a controlled, auditable workflow.

The forum covers topics such as:

- iOS and iPhone
- iPadOS and iPad
- macOS and Mac
- watchOS and Apple Watch
- tvOS and Apple TV
- visionOS and Apple Vision Pro
- Apple ecosystem integrations
- Troubleshooting, productivity, security, accessibility, and configuration

**Important:** The actual list of forum tags must be discovered from the live Flarum database. Do not assume the example categories above are the existing tags.

---

# PHASE 1 — EXISTING APPLICATION & DATABASE DISCOVERY

Inspect the current directory recursively, including relevant configuration, extension registration, and database integration files.

Identify:

1. Installed Flarum version.
2. PHP and database versions.
3. Database engine and connection configuration.
4. All existing tags and their IDs, slugs, descriptions, and relationships.
5. Tag hierarchy, including primary and secondary tags.
6. Installed extensions that affect discussions, tags, SEO, moderation, and publishing.
7. User registration and discussion publishing workflows.
8. Database schema for users, discussions, posts, and discussion-tag relationships.
9. Existing discussion counts by tag.
10. Existing title, post-body, and posting restrictions.

Use Flarum's supported application APIs or models where practical. Avoid direct SQL insertion that bypasses application logic, event handling, extension hooks, or cache invalidation.

Never expose credentials, passwords, tokens, or sensitive configuration values.

Produce a discovery report before modifying production data.

---

# PHASE 2 — SEARCH ENGINE QUESTION RESEARCH

For **each existing forum tag**, discover the 100 most relevant, high-demand questions people are searching for.

Research sources should include:

- Google Search suggestions
- Google People Also Ask
- Google Trends
- Google Search Console, if available
- Bing search suggestions
- Relevant Apple Support documentation
- Apple Developer documentation where applicable
- Public Apple community discussions
- Relevant Reddit communities
- Existing Osnivo search queries and forum discussions

Use authorized APIs and permitted research methods. Do not bypass search-engine restrictions.

### Research requirements

For each tag:

1. Research at least 150 candidate questions where enough evidence exists.
2. Identify informational, troubleshooting, configuration, comparison, compatibility, privacy, and productivity search intents.
3. Group similar questions into topical clusters.
4. Remove duplicates and near-duplicates.
5. Eliminate irrelevant or outdated topics.
6. Verify technical terminology and compatibility against current authoritative sources.
7. Select the strongest 100 distinct questions.
8. Rank by relevance, estimated search demand, usefulness, and coverage.
9. Store the source and reasoning for every selected question.
10. Do not invent search-volume figures. Clearly distinguish measured demand from qualitative estimates.

### Required research dataset

Each question must contain:

- Question ID
- Tag ID
- Tag name
- Question title
- Primary search keyword
- Secondary keywords
- Search intent
- Topic cluster
- Search demand evidence
- Research source URLs
- Priority score
- Content freshness considerations
- Duplicate-check result
- Research status

**Target formula:**

Total Questions = Number of Eligible Tags × 100

Example:

8 eligible tags × 100 questions = **800 unique questions**.

If an existing tag is unsuitable or insufficiently populated with genuine research topics, flag the shortfall rather than manufacturing irrelevant questions.

---

# PHASE 3 — QUESTION TITLE GENERATION

Convert the research findings into natural, specific questions appropriate for the Flarum forum.

### Title requirements

- Prefer authentic questions users would actually ask.
- Use clear and straightforward English.
- Use the terminology Apple users commonly recognize.
- Avoid keyword stuffing.
- Avoid exaggerated or clickbait language.
- Avoid unnecessary capitalization.
- Avoid repeated title formulas.
- Reflect concrete problems, decisions, or learning needs.
- Respect the effective Flarum title-length and validation restrictions discovered in Phase 1.
- Do not truncate titles in a way that loses their meaning.

### Examples

Good:

- Why does my iPhone battery drain overnight even when I'm not using it?
- How can I stop my MacBook from switching audio to my AirPods automatically?
- Does Stage Manager work differently on an iPad with an external monitor?
- Why isn't my Apple Watch unlocking my Mac anymore?
- Can I use one Apple ID across my iPhone, Mac, and iPad safely?

Bad:

- Ultimate iPhone Battery Optimization Guide 2026
- Discover These Amazing macOS Features!
- Best Apple Tricks Everyone Must Know
- iPhone Problems and Solutions Complete Guide

Questions should reflect genuine search intent rather than promotional article headings.

---

# PHASE 4 — NATURAL QUESTION DESCRIPTION WRITING

For every question, generate a meaningful discussion-opening description.

### Mandatory requirements

Each description must:

1. Contain at least 4–5 meaningful lines or sentences.
2. Explain the actual problem or information being requested.
3. Include relevant technical details when useful.
4. Give other forum members sufficient context to provide a helpful answer.
5. End with one or more clear questions.
6. Avoid generic filler.
7. Avoid repetitive templates.
8. Avoid fabricated personal experiences.
9. Avoid claims of having tested devices, installed software, or experienced failures unless supported by a genuine source.
10. Be factually consistent with Apple's current product ecosystem.

Descriptions should be written in a conversational, accessible style rather than as polished marketing articles.

### Writing variation

Introduce genuine structural variety:

- Short troubleshooting questions
- Configuration questions
- Feature explanations
- Cross-device compatibility questions
- Comparison questions
- Privacy and security questions
- First-time setup questions
- Performance and battery concerns
- Accessibility and productivity questions

Do not force every discussion into the same paragraph structure.

### Example

**Title:** Why does my MacBook keep connecting to my AirPods when I'm using my iPhone?

**Description:**

I'm trying to understand how automatic switching works when AirPods are paired with multiple Apple devices.

If someone is listening to audio on an iPhone and then starts using a MacBook, what determines which device the AirPods connect to?

Is there a setting that lets users keep automatic switching enabled on the iPhone but disable it on the Mac?

I'm also interested in whether this behavior differs between AirPods models or macOS versions.

What configuration would provide the most predictable experience?

This is an editorially authored discussion question, not an invented testimonial from a real user.

---

# PHASE 5 — CONTENT UNIQUENESS & QUALITY VALIDATION

Before any discussion is published, run validation checks.

### Duplicate detection

Compare each candidate against:

- Existing Flarum discussions
- Other newly generated questions
- Similar questions assigned to different tags
- Alternative title wordings expressing the same intent

Use normalized text comparisons and semantic similarity checks.

### Technical validation

Verify:

- Product names
- Supported OS versions
- Feature availability
- Device compatibility
- Relevant Apple terminology
- Current settings navigation where mentioned

Avoid presenting guesses as confirmed technical facts.

### Content validation

Reject questions containing:

- Incorrect technical assumptions
- Unverifiable experiences
- Duplicate search intent
- Excessive keyword repetition
- Misleading claims
- Promotional spam
- Nonsensical combinations of devices or features
- Overly similar descriptions
- Unsupported statistics

Every accepted question must have a meaningful reason to exist.

---

# PHASE 6 — PUBLISHING IDENTITY & ACCOUNT POLICY

Publish curated questions transparently under clearly identified Osnivo editorial or community-seeding accounts.

Do not impersonate independent community members, fabricate user biographies, or create accounts intended to manufacture the appearance of organic participation.

### Publishing distribution rule

Maintain a maximum of 10 questions per designated editorial account within the publishing dataset.

For example:

- Total questions: 800
- Maximum questions per account: 10
- Required designated publishing accounts: 80

If creating multiple editorial accounts is operationally useful, label them clearly as Osnivo-managed accounts. Otherwise, use one verified editorial account and track distribution through internal publishing batches.

Never use existing member accounts without explicit authorization.

### Account security

- Follow Flarum's supported account creation procedures.
- Use unique, valid account identifiers.
- Do not generate disposable user identities.
- Never reuse passwords across accounts.
- Never expose credentials.
- Avoid sending registration emails unintentionally.
- Preserve existing community accounts and permissions.

Every generated discussion must be traceable to its publishing process and editorial origin.

---

# PHASE 7 — PUBLICATION SCHEDULING & DAILY LIMITS

Develop a controlled publishing schedule.

### Scheduling rules

1. Never publish more than **10 generated questions per calendar day**.
2. Distribute questions across eligible tags.
3. Avoid publishing many nearly identical topics consecutively.
4. Randomize order within reasonable topic-diversity constraints.
5. Do not publish all questions simultaneously.
6. Use the forum's configured timezone consistently.
7. Schedule only for the present or future.
8. Preserve authentic creation timestamps; never backdate content to simulate historical participation.
9. Make schedules configurable and resumable.
10. Allow administrators to pause, resume, cancel, and reschedule.

### Example schedule

For 800 questions, with a maximum of 10 daily:

- Minimum publishing duration: 80 calendar days.
- Default target: 5–10 discussions per day.
- Spread publications across different hours.
- Ensure balanced coverage of forum tags over time.
- Record both scheduled and actual publication timestamps.

Use deterministic scheduling seeds where useful for reproducibility.

---

# PHASE 8 — FLARUM INTEGRATION & SAFE PUBLISHING

Develop a safe integration with the existing Flarum installation.

### Mandatory requirements

- Respect the existing application architecture.
- Prefer official APIs and supported Flarum models.
- Preserve database consistency.
- Respect extension hooks and permission rules.
- Associate every discussion with the correct tag IDs.
- Ensure discussion and initial post records remain consistent.
- Use supported post formatting.
- Avoid publishing empty descriptions.
- Ensure titles pass server-side validation.
- Avoid duplicate discussions.
- Handle failures gracefully.
- Maintain complete audit logs.

### Operational design

Implement:

1. Research data storage.
2. Draft generation.
3. Quality assurance.
4. Duplicate detection.
5. Editorial approval or explicitly configured auto-approval.
6. Scheduling queue.
7. Publishing worker.
8. Publication verification.
9. Failure handling.
10. Audit reporting.

Use idempotency keys to ensure retries cannot create duplicate discussions.

Perform database schema changes only through appropriate migrations.

Use the existing technology stack wherever practical.

---

# PHASE 9 — PRODUCTION SAFETY & TESTING

This is a live production forum.

Follow these safeguards:

1. Inventory the existing environment.
2. Take a verified database backup before any schema or data mutation.
3. Keep the existing forum operational.
4. Do not modify unrelated application features.
5. Do not delete existing discussions, users, or tags.
6. Do not modify existing account ownership.
7. Build a dry-run mode.
8. Test generated content against Flarum validation.
9. Verify tag assignment.
10. Validate permissions.
11. Test duplicate prevention.
12. Test scheduler behavior.
13. Test restart/recovery behavior.
14. Test posting-rate limits.
15. Test rollback and failure recovery.

### Publishing rollout

- **Stage A:** Research and generate the entire dataset without publishing.
- **Stage B:** Validate all questions and descriptions.
- **Stage C:** Test a small sample in a non-production environment.
- **Stage D:** Perform a controlled live pilot using designated editorial accounts.
- **Stage E:** Activate the daily publishing scheduler after pilot verification.

Do not enable bulk production publishing before verifying the pilot results.

---

# PHASE 10 — SEO & COMMUNITY QUALITY

Optimize content for discoverability without turning the forum into an automated spam repository.

### SEO requirements

- Use descriptive, search-friendly titles.
- Avoid duplicate URLs and near-identical pages.
- Respect Flarum canonical URL behavior.
- Maintain correct tag relationships.
- Avoid unnecessary title rewrites.
- Avoid keyword stuffing.
- Use useful internal links when relevant.
- Respect existing sitemap configuration.
- Do not falsely advertise a discussion as answered.
- Do not automatically generate fake replies, reactions, views, votes, or engagement.
- Ensure published discussions provide standalone context and genuine value.

Where useful, attach authoritative links to relevant Apple documentation.

### Community considerations

Publishing questions alone does not create a valuable knowledge base.

Provide a separate plan for obtaining accurate answers through:

- Verified expert contributions
- Genuine community participation
- Editorially reviewed answers
- Links to authoritative documentation
- Helpful moderation and discussion curation

Identify unanswered discussions for subsequent legitimate editorial or community follow-up.

---

# PHASE 11 — MONITORING & REPORTING

Create a report or lightweight administrative dashboard covering:

| Metric | Requirement |
|---|---|
| Eligible tags | Dynamically discovered |
| Target questions | 100 per eligible tag |
| Research candidates | At least 150 per tag where available |
| Approved questions | Track per tag |
| Rejected duplicates | Track count and reason |
| Scheduled questions | Track total and date |
| Published questions | Track per tag and day |
| Daily publishing limit | Maximum 10 |
| Publication errors | Track reason and retry |
| Unanswered questions | Track outstanding count |
| Editorial account usage | Track distribution |
| Research evidence | Preserve links and confidence |

Provide exports in JSON and CSV where useful.

Ensure the entire process can resume without repeating completed research or republishing content.

---

# PHASE 12 — MULTI-AGENT EXPERT REVIEW

Where multi-agent execution is supported, use independent specialized reviewers.

**Agent 1 — Flarum Architect**

Review application architecture, extensions, database integrity, integration methods, and production deployment safety.

**Agent 2 — SEO Research Specialist**

Review actual search demand, question relevance, topic selection, duplication, and discoverability.

**Agent 3 — Apple Ecosystem Specialist**

Review technical accuracy, product compatibility, device terminology, and OS-version assumptions.

**Agent 4 — Content Quality Editor**

Review clarity, natural wording, variety, usefulness, and lack of fabricated user experiences.

**Agent 5 — Security & Quality Engineer**

Review account permissions, database safety, publishing controls, monitoring, and operational recovery.

### Review protocol

Each agent must independently identify:

- Critical defects
- Missing requirements
- Content quality risks
- Security risks
- SEO weaknesses
- Scalability limitations
- Suggested improvements

Consolidate the findings and fix genuine issues.

Repeat the review after meaningful corrections.

Do not treat agent agreement as proof of correctness. Validate important findings with evidence and tests.

---

# PHASE 13 — REQUIRED DELIVERABLES

Produce these outputs within a dedicated, clearly identified project directory in the existing repository:

1. `flarum-discovery-report.md` — Architecture, existing tags, constraints, and system inventory.
2. `tag-research-report.md` — Topic research and search-demand methodology.
3. `questions-master.csv` — Final question dataset.
4. `questions-master.json` — Structured dataset with research evidence.
5. `content-quality-report.md` — Validation results and rejected items.
6. `publishing-plan.md` — Publishing schedule, distribution, and daily limits.
7. `publishing-accounts.md` — Editorial account policy and utilization.
8. `implementation-plan.md` — Architecture and integration decisions.
9. `test-report.md` — Test execution evidence.
10. `execution-report.md` — Final implementation and publishing status.

Also deliver the necessary application code, configuration, migrations, automation, and tests.

Do not create a second Flarum application.

Do not replace or unnecessarily modify the existing forum installation.

---

# PHASE 14 — ACCEPTANCE CRITERIA

The project is complete when:

- Every existing eligible tag has been discovered.
- Each tag has up to 100 high-quality, independently researched questions.
- The combined dataset contains no substantive duplicates.
- Titles comply with the installed Flarum version's actual constraints.
- Every description contains at least 4–5 meaningful sentences or lines.
- Technical assertions have been checked.
- Search demand and research evidence are recorded.
- The publishing plan covers the complete approved dataset.
- No calendar date exceeds 10 scheduled generated discussions.
- Editorial publishing identities are transparent.
- Publication timestamps represent actual publication.
- Correct Flarum tag assignment is verified.
- Retrying a job does not duplicate discussions.
- Production integration passes tests and pilot verification.
- All activity is logged and recoverable.
- The existing forum remains operational.
- All requested reports and datasets are available.

**Example:** If 8 tags are eligible and each supports 100 distinct questions, the expected dataset is 800 questions. Publishing those questions at 10 per day requires at least 80 days.

---

# FINAL EXECUTION INSTRUCTIONS

Start by inspecting the current directory and discovering the live Flarum application's configuration and tag structure.

Research the questions from genuine, relevant search evidence.

Generate the complete dataset and perform independent technical and editorial validation.

Implement the integration and publishing scheduler using the existing Flarum architecture.

Execute safe tests and a controlled publishing pilot.

Do not invent completed research, successful tests, search-volume data, or publication results.

Do not compromise production data.

Once the pilot is verified, prepare the remaining approved questions for progressive publishing under the configured daily limit.

Provide a final summary showing:

- Tags discovered
- Questions researched
- Questions accepted
- Questions rejected
- Questions scheduled
- Questions actually published
- Publication date range
- Publishing identity allocation
- Test results
- Outstanding risks
- Operational instructions

**ULTIMATE GOAL:** Make Osnivo one of the most useful and trustworthy searchable Apple ecosystem knowledge communities by publishing real, accurate, well-researched questions and building a foundation for meaningful answers.