Intelligent Forum Answering & Sustainable Community Growth Engine
### ROLE
Act as a coordinated team of:
1. Senior Flarum Developer and Database Architect
2. Apple Ecosystem Technical Support Specialist
3. Community Growth and Engagement Strategist
4. Technical SEO and Content Quality Specialist
5. Natural Language and Editorial Quality Specialist
6. Automation, Security, and Quality Assurance Engineer
### WEBSITE AND ENVIRONMENT
**Live Forum:** https://osnivo.com/forum/
**Application:** Flarum
**Source Code:** Current working directory.
The forum contains questions covering iOS, iPadOS, macOS, watchOS, tvOS, visionOS, and related Apple ecosystem technologies.
An earlier system may have already generated and scheduled up to 100 researched questions for each forum tag.
Your responsibility is to build an intelligent, reliable answering system for these questions while supporting genuine long-term community growth.
**IMPORTANT:** This is a live production forum. Preserve existing users, discussions, replies, tags, permissions, and database integrity.
---
# PHASE 1 — DISCOVER AND ANALYZE EXISTING DISCUSSIONS
Inspect the current Flarum application and database.
Discover:
- Existing tags and categories.
- All published discussions.
- Questions with zero replies.
- Questions with incomplete or outdated answers.
- Questions already answered satisfactorily.
- Questions awaiting moderation.
- Discussions published by designated editorial accounts.
- Discussions created by actual community members.
- Existing answer and moderation workflows.
For every discussion, collect:
- Discussion ID
- Title
- Primary tag
- Secondary tags
- Creation date
- Last activity date
- Existing replies
- Existing participants
- Answer status
- Technical category
- Difficulty level
- Answering priority
Do not automatically answer every discussion without evaluating whether an additional answer would be useful.
---
# PHASE 2 — RESEARCH THE CORRECT ANSWER
For each unanswered or insufficiently answered question, conduct appropriate technical research.
### Preferred sources
1. Official Apple Support documentation
2. Apple Developer documentation
3. Apple security and release documentation
4. Apple Community discussions
5. Verified third-party technical documentation
6. Reputable technical publications
7. Relevant community troubleshooting reports
### Research rules
- Verify important technical claims.
- Check the relevant OS and device versions.
- Differentiate current features from discontinued functionality.
- Do not invent settings, commands, features, or solutions.
- Avoid outdated tutorials.
- Identify cases where the answer depends on device model or software version.
- Provide warnings for operations involving data deletion, security, or system configuration.
- When the available evidence is insufficient, mark the question for human review.
Never claim that a fix has been personally tested unless that test actually occurred.
---
# PHASE 3 — HUMAN-READABLE ANSWER GENERATION
Write practical, helpful, conversational answers.
The goal is not to imitate fake community members. The goal is to produce editorial answers that people genuinely enjoy reading.
### Writing principles
- Use clear, simple English.
- Address the actual question directly.
- Avoid excessive technical jargon.
- Explain steps naturally.
- Use paragraphs appropriate to the problem.
- Avoid unnecessary introductions.
- Avoid generic AI-sounding conclusions.
- Avoid repeating the question unnecessarily.
- Avoid excessive formatting or emojis.
- Do not use the same response template for every answer.
- Include relevant examples when useful.
- Use numbered instructions for genuine step-by-step solutions.
- Include official sources where they improve reliability.
### Answer length
Choose the length based on the complexity of the question.
| Question type | Suggested answer |
|---|---|
| Simple factual | 50–120 words |
| Basic configuration | 100–200 words |
| Troubleshooting | 150–350 words |
| Technical comparison | 150–300 words |
| Advanced technical problem | 250–500 words |
These are guidelines, not fixed quotas.
### Example
**Question:** Why does my MacBook keep connecting to my AirPods automatically?
**Answer:**
This usually happens because your AirPods support automatic switching between Apple devices using the same Apple Account.
If you'd rather control when your Mac connects, try changing the connection setting:
1. Connect your AirPods to your Mac.
2. Open System Settings.
3. Select Bluetooth.
4. Open the settings for your connected AirPods.
5. Find the option for connecting to this Mac.
6. Choose "When Last Connected to This Mac" instead of automatically.
The wording may vary depending on your macOS version and AirPods model.
This should reduce unexpected switching without requiring you to unpair your AirPods from your iPhone.
---
# PHASE 4 — ANSWER QUALITY AND NATURAL VARIATION
Avoid producing hundreds of answers with identical structure.
Use the response format that genuinely fits each question.
### Possible response styles
**Direct answers:** Short, clear explanations for straightforward questions.
**Step-by-step answers:** Numbered troubleshooting or configuration instructions.
**Technical explanations:** Explain how a particular Apple feature works.
**Comparisons:** Discuss meaningful differences between devices, OS versions, or configurations.
**Diagnostic answers:** Explain likely causes and how to isolate a problem.
**Clarifying replies:** Ask for missing device, version, error-message, or troubleshooting information before recommending a fix.
**Reference answers:** Point to reliable official documentation while adding useful context.
### Prohibited patterns
Do not repeatedly start answers with:
- "Great question!"
- "Absolutely!"
- "Certainly!"
- "I hope this helps!"
- "In today's digital world..."
- "Let's dive in..."
- "Here is a comprehensive guide..."
Do not artificially insert spelling errors, fake typos, fabricated anecdotes, or exaggerated opinions to imitate human contributors.
Answers must feel natural because they are relevant, specific, and well edited.
---
# PHASE 5 — ANSWERING PRIORITY ENGINE
Not every question should receive an immediate automated answer.
Evaluate discussions using these criteria:
- Question importance
- Available technical evidence
- Answer complexity
- Existing community responses
- Search interest
- Technical urgency
- Potential usefulness
- Age of the discussion
- Risk of providing incorrect advice
### Prioritization
**P1 — High priority**
Important unanswered technical questions with well-established, verifiable solutions.
**P2 — Medium priority**
General configuration, productivity, and educational questions.
**P3 — Low priority**
Opinion-based questions, broad comparisons, and topics that benefit from genuine community discussion.
**Human review required**
Questions involving uncertain fixes, missing diagnostic information, high-risk operations, or conflicting technical documentation.
Avoid adding an automated answer to a question that already has a sufficient community-provided solution.
---
# PHASE 6 — NATURAL AND CONTROLLED ANSWERING SCHEDULE
Implement gradual publication rather than responding to the entire forum in one batch.
### Core requirements
1. Maintain a configurable daily answer limit.
2. Begin with a conservative publishing rate.
3. Spread answers across different tags.
4. Avoid replying to many discussions at exactly the same time.
5. Give genuine members an opportunity to participate.
6. Respect existing moderation workflows.
7. Use the forum's configured timezone.
8. Publish only with authentic current timestamps.
9. Never backdate replies to fabricate historical activity.
10. Never generate fake user-to-user conversations.
### Recommended initial configuration
- New questions: maximum 10 per day, controlled by the existing system.
- Editorial answers: 3–6 per day initially.
- After quality verification: configurable up to 10 per day.
- Provide a configurable minimum unanswered period before an editorial answer is considered.
- Prioritize useful responses over reaching a daily quota.
These are starting recommendations, not claims about optimal growth rates.
### Scheduling intelligence
The scheduler should:
- Respect the current daily publication quota.
- Avoid duplicate answers.
- Check for new community replies before publishing.
- Pause answering when a human moderator has intervened.
- Respect locked discussions.
- Avoid answering spam or removed discussions.
- Retry transient failures safely.
- Track which questions have received responses.
- Allow manual intervention.
Scheduling variation should support editorial workload and topic diversity, not simulate independent human activity.
---
# PHASE 7 — PUBLISHING ACCOUNT MANAGEMENT
Use authorized, clearly identified Osnivo accounts.
Recommended account types:
**Osnivo Support**
Publishes verified troubleshooting and configuration solutions.
**Osnivo Guides**
Provides educational explanations and step-by-step instructions.
**Osnivo Editorial**
Answers comparisons, general knowledge, and product feature questions.
Clearly disclose AI assistance where applicable and follow the forum's community policies.
### Mandatory restrictions
- Never impersonate existing members.
- Never publish through accounts without authorization.
- Never create fictitious community members to respond to other fictitious members.
- Never manufacture discussions, agreements, endorsements, or testimonials.
- Never inflate engagement statistics with artificial activity.
- Never fabricate upvotes, reactions, views, or accepted answers.
Use account separation for legitimate editorial responsibilities rather than pretending multiple independent people are participating.
---
# PHASE 8 — CONTEXT-AWARE CONVERSATION MANAGEMENT
Before publishing, read the complete relevant discussion.
Determine:
1. What was originally asked?
2. What information is already available?
3. Has someone already answered?
4. Is the proposed answer still relevant?
5. Has the original poster provided additional details?
6. Does the solution require clarification?
7. Would another reply improve the discussion?
### Follow-up behavior
If a real member asks a follow-up question:
- Read the complete discussion context.
- Address their actual follow-up.
- Avoid repeating previous instructions.
- Ask for relevant diagnostic information when necessary.
- Acknowledge unresolved uncertainty.
- Escalate technically risky problems.
Do not generate fictitious follow-up replies just to extend conversations.
---
# PHASE 9 — AUTOMATED TECHNICAL VALIDATION
Before publication, validate every answer.
### Technical checks
- Accurate product names
- Correct macOS/iOS terminology
- Current settings navigation
- Device-model compatibility
- OS-version applicability
- Valid technical commands
- Appropriate warnings
- Correct explanation of limitations
### Content checks
- Answers the actual question
- No unsupported personal claims
- No unnecessary repetition
- No contradictory steps
- No irrelevant paragraphs
- No misleading certainty
- No copied copyrighted passages
- No suspicious external links
- No promotional spam
Use a quality score between 0 and 100.
Recommended thresholds:
- **90–100:** Eligible for automatic publishing if technically low-risk.
- **75–89:** Editorial review recommended.
- **Below 75:** Reject or regenerate.
- **High-risk subjects:** Require review regardless of score.
Quality scores are internal heuristics and must not replace technical verification.
---
# PHASE 10 — FLARUM INTEGRATION
Integrate with the existing installation using supported APIs or application models.
Implement:
1. Discussion discovery.
2. Answer research queue.
3. Draft generation.
4. Technical validation.
5. Approval workflow.
6. Answer publication queue.
7. Scheduling worker.
8. Publishing verification.
9. Audit logs.
10. Administrative reporting.
### Production requirements
- Follow Flarum permission rules.
- Respect application validation.
- Preserve existing post relationships.
- Maintain consistent discussion metadata.
- Avoid direct database writes that bypass Flarum business logic.
- Never alter existing member replies without authorization.
- Support idempotent retries.
- Support pause/resume.
- Implement rate limiting.
- Implement failure recovery.
- Preserve complete operational logs.
---
# PHASE 11 — COMMUNITY GROWTH WITHOUT ARTIFICIAL ENGAGEMENT
The objective is to encourage actual participation.
Implement legitimate mechanisms that make the community more useful.
### Community features to evaluate
- Unanswered questions page
- Popular troubleshooting questions
- Recently solved discussions
- Relevant related-discussion suggestions
- Contributor recognition for genuine participation
- Helpful-answer highlighting
- Expert contributor onboarding
- Community guidelines
- Topic subscriptions
- Weekly knowledge roundups
- Search-driven knowledge-base improvements
Do not automatically mark editorial answers as accepted on behalf of another user.
Where Flarum extensions support solved-status workflows, use the appropriate authorized moderation process.
### Important growth principle
A healthy forum is not measured solely by the number of discussions and replies.
Measure whether people actually find solutions and voluntarily participate.
---
# PHASE 12 — MULTI-AGENT REVIEW
Use five independent review roles where supported.
**Agent 1 — Apple Technical Expert**
Validate accuracy, device support, and troubleshooting instructions.
**Agent 2 — Flarum Architect**
Validate application integration and database integrity.
**Agent 3 — Editorial Specialist**
Assess readability, usefulness, and natural language quality.
**Agent 4 — SEO Specialist**
Assess relevance, topical coverage, duplication, and search usefulness.
**Agent 5 — Community Trust & Security Specialist**
Detect impersonation, artificial engagement, unsafe automation, and moderation risks.
Combine findings, resolve conflicts, and verify important changes with real tests.
Do not treat multiple agents agreeing as evidence that unverified technical information is correct.
---
# PHASE 13 — DASHBOARD AND REPORTS
Create an operational report containing:
| Metric | Requirement |
|---|---|
| Total questions | Existing discussions |
| Unanswered questions | Current count |
| Questions awaiting research | Current count |
| Draft answers | Current count |
| Answers approved | Current count |
| Answers published | Current count |
| Answers published today | Daily total |
| Human review queue | Pending count |
| Failed publications | Error details |
| Duplicate replies prevented | Total |
| High-risk questions | Flagged count |
| Community responses | Genuine member activity |
| Answer freshness | Review status |
Export reports as Markdown, JSON, or CSV where useful.
---
# PHASE 14 — TESTING AND DEPLOYMENT
Follow this order:
**Stage 1:** Inspect the existing application and discussions.
**Stage 2:** Design the answering workflow and publishing safeguards.
**Stage 3:** Research and generate sample answers.
**Stage 4:** Validate technical accuracy and answer quality.
**Stage 5:** Test using a development or staging environment.
**Stage 6:** Publish a small, verified live pilot under identified editorial accounts.
**Stage 7:** Review results and correct defects.
**Stage 8:** Enable controlled scheduled publication.
**Stage 9:** Monitor quality, reliability, and actual community participation.
Do not mass-publish unverified answers in production.
---
# PHASE 15 — ACCEPTANCE CRITERIA
The implementation is successful when:
- Existing forum discussions are accurately discovered.
- Unanswered questions are identified.
- Each answer is grounded in reliable technical evidence.
- Answers are clear, useful, and appropriately sized.
- Different questions receive appropriately varied answer structures.
- No fictitious community personas are introduced.
- Genuine community participation is preserved.
- Publishing accounts are clearly identified.
- Daily publication limits are respected.
- Publishing happens using authentic timestamps.
- Existing correct answers are not unnecessarily duplicated.
- High-risk questions receive human review.
- Failed jobs can be retried without duplication.
- Administrative controls allow pausing and monitoring.
- Production operations are verified.
- A complete audit trail is maintained.
---
# FINAL EXECUTION INSTRUCTIONS
Start by examining the current Flarum codebase and database.
Identify existing questions, answers, forum extensions, and account policies.
Design and implement a context-aware question-answering engine that produces reliable Apple ecosystem support content.
Use genuine technical research and varied editorial writing.
Integrate it safely with the existing Flarum architecture.
Deploy only after appropriate testing and live pilot verification.
Schedule answers gradually, with configurable limits and transparent publishing identity.
Produce:
- `answering-system-architecture.md`
- `answer-research-report.md`
- `answer-quality-report.md`
- `answer-publishing-schedule.md`
- `answering-automation-config.md`
- `community-growth-strategy.md`
- `testing-report.md`
- `execution-report.md`
**ULTIMATE OBJECTIVE**
Make Osnivo a trustworthy, comprehensive Apple ecosystem community where questions receive genuinely useful answers, visitors discover reliable solutions, and real community participation grows sustainably over time.