Develop Method for Twitter Together

My preliminary take on how I’d run such an account:

If a method is developed, it can then be shared to the community so others can reproduce it.

I will play around with your steps in a bit, and see what the output looks like.

From my experience, even properly chunking and storing the twitter algorithm in a vectorstore db for augmented retrieval, the output will not take into account the whole codebase of the algorithm. The context is just not big enough, or cheap enough.

I think we are better off finding a good summary online of best practices and crafting a prompt to follow the twitter-together syntax and twitter’s best practices for maximum reach. Then running the PRs through that.

1 Like

Curious to find out how it performs

Here’s an example of what I mean:

Look at some of the answers for yourself. Yes, it takes into account the chunks of code that are most semantically similar to the query to craft an answer, but it’s very far from a holistic view of the entire twitter algorithm. This type of query is better suited for asking about specific functions within a codebase, etc. Doing something similar with the NoM codebase could be helpful for developers and users writing documentation.

I will look for resources that sum up the key points from twitter’s algorithm as it applies to someone looking to maximize reach. Then, feed that plus the twitter together syntax with a prompt to review the PR and suggest edits.

I’ll share it when I’m done.

Here is the ChatGPT-4 output I found most useful/relevant. Following the twitter, together syntax was a total failure only feeding the model twitter-together’s repo, as you suggested. We’ll need to do some prompt engineering and craft a few-shot prompt that includes our own examples of correctly formatted .tweet files that include all use-cases.

Content of the Tweet Thread:

The PR aims to create a tweet thread commemorating the 27th of July, 2023, when Mr. Kaine airdropped the keys for Twitter/X and Github to the Zenon Community. The thread is composed entirely of quotes from community members. Here’s a breakdown:

  1. Introduction: The tweet introduces the significance of the date and sets the tone for the thread by emphasizing the community’s involvement.

  2. Zenon’s Transformation: The tweet highlights Zenon’s shift to a community-led project and introduces a thread that serves as a tribute to the community’s dedication.

  3. Leaderless Philosophy: The tweet delves into the concept of being “leaderless” and how Zenon embodies this philosophy, emphasizing trust in the shared vision.

  4. Quotes from Community Members: The thread features various quotes from community members, each offering a unique perspective on Zenon, its ethos, and its journey. These quotes range from poetic expressions and personal experiences to humorous anecdotes and profound insights.

Detailed Scrutiny:

  1. Relevance to the Twitter Algorithm: The thread is designed to be engaging, with a mix of profound insights, personal experiences, and community anecdotes. Given the algorithm’s preference for relevance, engagement, and rich media, this thread is likely to perform well. However, the inclusion of images or GIFs could further enhance its visibility.

  2. Content Quality: The content is well-curated, with a mix of profound insights and light-hearted moments. It captures the essence of the Zenon community and its journey.

  3. Engagement Potential: The thread has high engagement potential. The use of community quotes invites interactions from mentioned members and the broader community. The narrative style, combined with the significance of the event, is likely to resonate with followers, prompting retweets, likes, and replies.

  4. Optimization Suggestions:

  • Media Inclusion: Consider adding relevant images, GIFs, or videos to enhance engagement. Visual content is prioritized by the Twitter algorithm.
  • Hashtags: Incorporate relevant and specific hashtags to increase the tweet’s discoverability.
  • Engage with High-Quality Users: Engage with influential Twitter users or accounts related to Zenon to boost the tweet’s visibility.
  • Timing: Ensure the tweet is posted during peak engagement times for the target audience.
    Overall Assessment: The PR is well-crafted, capturing the essence of the Zenon community and its significant milestone. With a few optimizations, it has the potential to perform exceptionally well on Twitter, leveraging the insights from the Twitter algorithm.

Let’s address each of your questions:

  1. Images:

Should you put images? Yes. The Twitter algorithm prioritizes tweets with rich media, such as images, videos, and GIFs. Visual content tends to capture attention and can significantly boost engagement.
How many and where? Ideally, you should include a featured image with the initial tweet to set the tone and context. If you have relevant images for some of the quoted testimonials or key points, you can include them. However, ensure the images add value and are not just for the sake of having visuals. A good rule of thumb is to have an image every 3-4 tweets in a thread to maintain visual interest without overwhelming the reader.

  1. Testimonials:

Should they be posted by the authors to their own accounts? Yes. Authenticity plays a crucial role in engagement. When testimonials are posted by the original authors, they carry more weight and credibility. It also allows for organic reach and engagement as the authors’ followers might engage with the original tweet.
Should they then be quoted rather than rewritten? Absolutely. Quoting the original tweet ensures authenticity and gives credit to the original author. It also leverages the algorithm’s preference for engagement, as retweets and quote tweets are forms of engagement.

  1. Hashtags:

Should you use hashtags? Yes. Hashtags increase the discoverability of tweets, especially for users who might be following or searching for those specific hashtags.
How many and where? Twitter’s best practices suggest using no more than two hashtags per tweet to avoid looking spammy. Place them at the end of your tweet or integrate them naturally within the tweet’s text. For a thread, you can use a consistent hashtag throughout, like #ZenonNetwork, and then vary one other hashtag based on the specific tweet’s content.
Incorporating these strategies will not only make your tweet thread more engaging but also optimize it for the Twitter algorithm, increasing its reach and impact.

1 Like

This was the best resource I could find regarding the twitter algo.

1 Like

May you ask GPT if we should repost old tweets as new content, or simply retweet it (you can only retweet once, the next time you have to unretweet and then retweet again). The idea is to repurpose content in the most beneficial way.

@0x3639 do you have permissions to create a project in the zenon twitter repository called “Tweet Calendar”? Namely a “Board” type (as seen below) so that we can collaborate on a calendar of tweets? Would be awesome if we can get a way to queue tweets for auto-posting (schedule them) using twitter-together. Will propose a configuration shortly, talking to GPT about it.

Screen Shot 2023-09-14 at 11.01.30 AM

I’m currently debating between Kaban (columns) or Gannt style (Roadmap):

Both Gantt-style (Roadmap) and Kanban-style project boards have their merits, and the best choice for managing twitter-together depends on your specific needs and preferences. Here’s a comparison of both styles in the context of twitter-together:

Gantt-style (Roadmap):


  1. Visual Timeline: Provides a clear visual representation of when tweets are scheduled to be published. This is especially useful if you have a content calendar with specific dates for certain tweets.
  2. Dependencies: You can visually link items to show dependencies, which can be useful if one tweet or action is contingent upon another.
  3. Long-Term Planning: Great for visualizing a longer-term strategy or campaign, allowing you to see the bigger picture.


  1. Complexity: Might be overkill for simple workflows or if you’re only managing a few tweets at a time.
  2. Less Agile: Adjusting dates and reorganizing can be a bit more cumbersome compared to the drag-and-drop nature of Kanban boards.



  1. Simplicity: Easy to set up and understand. New team members or community contributors can quickly grasp the workflow.
  2. Agility: Easy to move items between columns, making it flexible for changes or quick decisions.
  3. Clear Workflow: The columnar structure provides a clear path from idea to publication, making it easy to see what stage each tweet is in.
  4. Automation: With GitHub Actions, you can automate certain tasks, like moving a tweet to a different column when its associated issue is closed.


  1. Lacks Timeline: Doesn’t provide a clear visual representation of when tweets are scheduled unless you integrate with other tools or manually manage due dates.
  2. Short-Term Focus: While you can certainly plan ahead with a Kanban board, it’s primarily designed for more immediate, short-term tasks.

Recommendation for twitter-together:

For a tool like twitter-together, where the primary goal is to draft, review, and publish tweets, the Kanban-style might be more intuitive and efficient. The straightforward workflow of moving a tweet from idea to draft to review to publication aligns well with the columnar nature of Kanban.

However, if you have a detailed content calendar, specific campaign dates, or need to visualize your tweeting strategy over several months, the Gantt-style Roadmap could be beneficial.

In conclusion, if you’re looking for simplicity, agility, and a clear short-term workflow, go with Kanban. If you need a visual timeline for long-term planning and want to see dependencies between tweets, choose the Gantt-style Roadmap.

A Kaban configuration can be as such:

Using GitHub’s “Roadmap” type project to create a calendar for scheduling tweets via twitter-together is a great idea. Here’s a step-by-step guide on how to configure it:

1. Create a New Project:

  1. Navigate to your GitHub repository.
  2. Click on the “Projects” tab.
  3. Click “New Project.”
  4. Name your project (e.g., “Twitter Calendar”).
  5. Choose the “Board” template.
  6. Click “Create project.”

2. Configure Columns:

The Roadmap template comes with a few default columns. You can customize these columns to better fit your needs. Here’s a suggested configuration:

  1. Backlog: Tweets or replies that are proposed but not yet scheduled.
  2. Scheduled: Tweets that have a specific date to be published.
  3. In Progress: Tweets that are currently being drafted or reviewed.
  4. Published: Tweets that have been successfully published.
  5. Archived: Old tweets or ideas that are no longer relevant.

3. Add Cards:

For each tweet or reply:

  1. Create a new card.
  2. Write a brief description or title for the tweet.
  3. Add details in the card’s description, such as the tweet’s content, relevant links, or any other notes.
  4. Assign a due date if the tweet is scheduled.
  5. Assign members if specific people are responsible for drafting, reviewing, or publishing the tweet.

4. Use Labels:

Labels can help categorize and prioritize tweets. Some suggested labels include:

  • Reply: For tweets that are replies to other tweets.
  • Announcement: For important announcements.
  • Event: For tweets related to specific events or dates.
  • Urgent: For tweets that need immediate attention.

5. Automate Workflow (Optional):

You can use GitHub Actions in conjunction with your project board to automate certain tasks. For instance:

  • Automatically move a card to “Published” when a PR (representing a tweet) is merged in the twitter-together repository.
  • Send notifications to assigned members as the scheduled date approaches.

6. Regularly Review:

Hold regular meetings (e.g., once a week) with your community or team to review the board:

  • Move tweets from “Backlog” to “Scheduled.”
  • Review “In Progress” tweets and provide feedback.
  • Archive old or irrelevant tweets.

7. Integrate with twitter-together:

Ensure that your workflow with twitter-together is integrated. For example:

  • When a tweet is ready to be published, create a PR in the twitter-together repository.
  • Once the PR is reviewed and merged, the tweet will be published, and you can move the corresponding card to the “Published” column.

8. Monitor and Adjust:

As you use the Roadmap project, you’ll get a better sense of what works for your community. Adjust columns, labels, and processes as needed.

Remember, the key is to keep things organized and transparent. This way, everyone in the community knows what’s happening, what’s coming up, and how they can contribute.

Ideally I’d probably use a Kaban tab view for “working”, and then setup an additional view (tab) with the Roadmap view so we can visualize the calendar.

Let me know if you have permissions to create a project, if yes please add me as a collaborator and I’ll configure the right workflow.


Great idea. I have the ability to create Private projects, but I need Interstellar to make them Public. I have a request in for the Roadmap.

I just created the Tweet Calendar and will ask to make it public.


Once the Project is public I can make you a collaborator.

1 Like

Thank you, will configure the views (board + roadmap tabs) when granted rights. In the meantime I checked settings and we can set custom fields, like Date, however it doesn’t include an hour / minute / timezone. So we can use Github Actions to auto-post scheduled tweets at random times between a certain window (busiest window tbd i.e. 10am-2pm). It can all be setup so that only tweets which have the necessary approvals by reviewers are queued.

Preliminary flow, we can add further Github actions for moving cards as well:

@0x3639 @sol_sanctum let me know if something like this would be possible.

GPT says:

Let’s create a comprehensive guide for setting up a workflow for twitter-together using GitHub’s Kanban board and GitHub Actions, ensuring tweets are posted between 10am to 2pm EST after receiving two approvals.

Setup Guide for twitter-together Workflow

1. Kanban Board Configuration:

Creating the Board:

  1. Navigate to your GitHub repository.
  2. Click on the “Projects” tab.
  3. Click “New Project.”
  4. Name your project (e.g., “Twitter Schedule”).
  5. Choose the “Basic kanban” template.
  6. Click “Create project.”

Configuring Columns:

  1. Ideas: Initial proposals for tweets or replies.
  2. Scheduled: Tweets with a decided posting date.
  3. In Review: Tweets awaiting approval.
  4. Approved: Tweets that have received the necessary approvals.
  5. Posted: Successfully published tweets.

Why this setup? This flow ensures a clear progression from idea to posting, allowing for review and approval stages.

2. Repository Settings for Pull Request Reviews:

  1. Navigate to your GitHub repository.
  2. Click on the “Settings” tab.
  3. In the left sidebar, click on “Branches.”
  4. Under “Branch protection rules,” click “Add rule” or edit an existing rule for the main branch.
  5. Check “Require pull request reviews before merging.”
  6. Set the required number of approving reviews to 2.
  7. Save the changes.

Why this setup? Requiring two approvals ensures that tweets are vetted by multiple team members before posting, maintaining quality and consistency.

3. GitHub Action for Auto-Posting:

Creating the GitHub Action:

  1. In your twitter-together repository, navigate to the .github directory (create it if it doesn’t exist). Inside, create another directory called workflows.
  2. Inside the workflows directory, create a new file named autopost.yml.

Configuring the GitHub Action in autopost.yml:

name: Auto-Post Tweets

      - closed

    runs-on: ubuntu-latest
    if: github.event.pull_request.merged == true
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Check current time
      id: check_time
      run: |
        CURRENT_HOUR=$(date +'%H' -d '5 hours ago') # Convert UTC to EST
        if [[ $CURRENT_HOUR -ge 10 && $CURRENT_HOUR -le 14 ]]; then
          echo "::set-output name=within_window::true"
          echo "::set-output name=within_window::false"
      shell: bash

    - name: Post the tweet
      if: steps.check_time.outputs.within_window == 'true'
      run: |
        # Random sleep duration between 0 to 3600 seconds (0 to 1 hour)
        sleep $(( RANDOM % 3600 ))
        # Your script to post the approved tweet

Why this setup?

  • The action is triggered when a pull request is closed.
  • The condition github.event.pull_request.merged == true ensures the action runs only if the PR was merged, indicating it received the necessary approvals.
  • The time check ensures tweets are posted only between 10am to 2pm EST.
  • The random sleep ensures tweets are posted at a random time within the window, making the posting pattern appear more organic.

4. Workflow with the Kanban Board:

  1. Ideas: Propose a tweet idea.
  2. Scheduled: Decide a posting date for the tweet.
  3. In Review: Create a PR in the twitter-together repository. Await reviews.
  4. Approved: After receiving two approvals, merge the PR. The GitHub Action will then check the time window and post the tweet accordingly.
  5. Posted: After the tweet is posted, move the card to this column.

By following this guide, you’ll have a structured workflow for proposing, reviewing, approving, and posting tweets using twitter-together. The combination of the Kanban board and GitHub Actions ensures a clear progression, timely postings, and quality control through required approvals.

Will we be able to manually bypass the 10-2pm window and push tweets (if approved) immediately as well?

GPT says:

Yes, you can manually bypass the 10-2pm window and push tweets immediately, even with the GitHub Action in place. Here’s how you can set it up and use it:

1. Adjusting the GitHub Action:

In the autopost.yml file, you can introduce an input that allows for manual triggering of the action. This is done using the workflow_dispatch event.

Modify the on section of your autopost.yml:

      - closed
        description: 'Bypass 10-2pm window? (yes/no)'
        required: true
        default: 'no'

Then, in the Check current time step, you can adjust the script to check for this input:

BYPASS=${{ github.event.inputs.bypass_time_window }}

if [[ "$BYPASS" == "yes" || ($CURRENT_HOUR -ge 10 && $CURRENT_HOUR -le 14) ]]; then
  echo "::set-output name=within_window::true"
  echo "::set-output name=within_window::false"

2. Manually Triggering the Action:

  1. Navigate to the “Actions” tab in your GitHub repository.
  2. Select the Auto-Post Tweets workflow from the left sidebar.
  3. Above the list of workflow runs, click “Run workflow.”
  4. You’ll be prompted to select a branch and provide input for bypass_time_window. Enter yes to bypass the time window.
  5. Click the “Run workflow” button.

The action will then run, and if the tweet PR is approved, it will post the tweet immediately, bypassing the 10-2pm window.

Why this setup?

  • The workflow_dispatch event allows for manual triggering of GitHub Actions. By introducing an input, you can decide whether to bypass certain conditions set in the action.
  • This setup provides flexibility. While the automated time window ensures tweets are posted at optimal times, the manual override allows for immediate posting when necessary.

Remember, even with the manual trigger, the tweet will only be posted if the associated PR has been merged, ensuring that the two-approval requirement is still met.

1 Like

I’ll see what I can find regarding this. However, based on my own feed experience, quote retweets that add extra commentary must be performing well because I see them very often. There might be a distinction between quote retweeting someone else vs your own account, as the latter is definitively occurring less often. It makes sense as the first one can be seen as a “conversation starter”.