How to Use GitHub Actions GitHub for Beginners

How to Use GitHub Actions | GitHub for Beginners ![rw-book-cover](https://img.youtube.com/vi/BQrohJ3PT7I/maxresdefault.jpg) 🔗 **Source:** [How to Use GitHub Actions | GitHub for Beginners](https://www.youtube.com/watch?v=BQrohJ3PT7I) > [!note]+ Document Notes > tags: #github-actions #cicd #automation #workflows #devops > author: GitHub > source: YouTube > reference: https://www.youtube.com/watch?v=BQrohJ3PT7I > date created: 2024-12-19 10:30 > > # 🏷️ Title: How to use GitHub Actions | GitHub for Beginners >  ## 🧰 Action Inbox - [H1] Set up first GitHub Actions workflow — create auto-labeling system for repository issues #automation - [H2] Learn GitHub Actions terminology — understand events, runners, and jobs for workflow creation #learning - [H3] Complete GitHub Skills challenge — practice with Hello GitHub Actions tutorial #education ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [GitHub Actions Documentation](https://docs.github.com/en/actions) - [GitHub Skills](https://skills.github.com/) - [GitHub Marketplace](https://github.com/marketplace) ## 📝 Summary - **What happened**: GitHub tutorial demonstrating how to create automated workflows using GitHub Actions, specifically building an auto-labeling system for repository issues - **Why it matters**: GitHub Actions enables developers to automate repetitive tasks like testing, deployment, and repository management, improving productivity and reducing manual errors - **Key stakeholders**: Developers, DevOps engineers, repository maintainers, and teams looking to implement CI/CD practices - **Risks and tradeoffs**: Learning curve for YAML syntax, potential over-automation, runner costs for private repositories, security considerations with permissions - **Bottom line**: GitHub Actions provides an accessible entry point to CI/CD automation directly integrated with GitHub repositories ## 📖 Main Content GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform built into GitHub that allows developers to automate workflows using YAML files. The tutorial demonstrates creating a practical workflow that automatically labels new issues in a repository. The core concept revolves around three main components: events (triggers like pushes or pull requests), runners (virtual machines that execute jobs), and jobs (sets of steps performed within the same runner). When an event occurs, GitHub spins up runners to execute the defined workflow steps. The tutorial walks through creating a real-world example: an auto-labeling workflow that adds a "triage" label to newly opened issues. This demonstrates the practical application of GitHub Actions for repository management automation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/BQrohJ3PT7I?t=0) — [H1] Introduction to GitHub Actions automation - Key idea: GitHub Actions automates developer workflows like vulnerability scans, tests, releases, and team reminders - Evidence: "GitHub actions is a continuous integration, continuous delivery or CI/CD and automation platform built right into GitHub" #### ⏱️ [01:30](https://youtu.be/BQrohJ3PT7I?t=90) — [H2] Core terminology and concepts - Key idea: Three essential terms define GitHub Actions: events (triggers), runners (virtual machines), and jobs (sets of steps) - Evidence: "An event is a specific activity that triggers a workflow. A runner is a virtual machine that executes jobs in a workflow. A job is a set of steps that's executed within the same runner" #### ⏱️ [02:15](https://youtu.be/BQrohJ3PT7I?t=135) — [H3] Workflow execution process - Key idea: Events trigger workflows, which spin up runners to execute jobs in response to repository activities - Evidence: "When the event fires and the workflow exists that responds to that event, GitHub spins up one or more jobs that execute on a runner" #### ⏱️ [02:45](https://youtu.be/BQrohJ3PT7I?t=165) — [H2] Workflow structure components - Key idea: GitHub Action workflows have three main sections: name (description), on (triggers), and jobs (actual work) - Evidence: "Three main sections that you need to know when building an action workflow. The name section, which describes what your workflow does, the on section, which defines what triggers it, and the job section, which is where the actual work happens" #### ⏱️ [03:30](https://youtu.be/BQrohJ3PT7I?t=210) — [H1] Creating auto-labeling workflow - Key idea: Practical workflow creation involves YAML files stored in .github/workflows directory - Evidence: "GitHub actions uses YAML syntax to define workflows. Each workflow is stored as a yaml file in a special github/workflows directory in your repository" #### ⏱️ [04:00](https://youtu.be/BQrohJ3PT7I?t=240) — [H3] File naming best practices - Key idea: Workflow files should use descriptive names that clearly indicate their function - Evidence: "When creating workflow files, use descriptive names that tell you what they do at a glance like build and test.yaml or security scanner.yaml" #### ⏱️ [04:30](https://youtu.be/BQrohJ3PT7I?t=270) — [H2] Event trigger configuration - Key idea: GitHub offers numerous trigger options, with issues trigger and activity type "opened" for new issue automation - Evidence: "GitHub has tons of trigger options reflected in the documentation. In our case, we will use the issues trigger. Then add the activity type open" #### ⏱️ [05:15](https://youtu.be/BQrohJ3PT7I?t=315) — [H2] Job configuration and runners - Key idea: Jobs require titles, runner specifications (Ubuntu, Windows, macOS), and appropriate permissions - Evidence: "GitHub provides hosted runners with different versions of Ubuntu, Windows, and Mac OS. Let's call this job label-issues and run it on Ubuntu latest" #### ⏱️ [06:00](https://youtu.be/BQrohJ3PT7I?t=360) — [H3] Permission management - Key idea: Workflows need specific permissions to perform actions like adding labels to issues - Evidence: "We also need to add write permissions here so that action can add the label. When we use the permissions key within the jobs, all the actions and run commands within the job gain the access rights specified" #### ⏱️ [06:30](https://youtu.be/BQrohJ3PT7I?t=390) — [H2] Steps and action types - Key idea: Two main keywords define workflow steps: "uses" for pre-built actions and "run" for custom commands - Evidence: "When you see uses, that's spooling a pre-built action from the GitHub marketplace. When you see run, that's executing a command or a script" #### ⏱️ [07:15](https://youtu.be/BQrohJ3PT7I?t=435) — [H3] Environment variables and secrets - Key idea: GitHub automatically provides context variables and secrets for workflow authentication and data access - Evidence: "We'll use the github token, github repo, and number variables that are automatically set. GitHub actions will automatically know which values to use for those variables" #### ⏱️ [08:00](https://youtu.be/BQrohJ3PT7I?t=480) — [H1] Testing and deployment process - Key idea: Workflow testing involves pushing to GitHub, creating pull requests, merging, and triggering the automation - Evidence: "Let's test out the workflow we just created by pushing it to GitHub, creating a PR, merging it to the main branch, and creating a new issue in that repository" #### ⏱️ [08:45](https://youtu.be/BQrohJ3PT7I?t=525) — [H2] Workflow monitoring and management - Key idea: The Actions tab provides comprehensive workflow management including runs, deployments, metrics, and file editing - Evidence: "The actions tab is where you will go to see and manage all of your workflows. You can check deployments, runners, metrics, performance, and cache from this view" #### ⏱️ [09:30](https://youtu.be/BQrohJ3PT7I?t=570) — [H3] Advanced automation possibilities - Key idea: GitHub Actions extends beyond issue labeling to package publishing, contributor greeting, testing, and security scanning - Evidence: "GitHub actions can do a lot more than just label your issues. You can create actions to publish packages, greet new contributors, build and test your code, and even run security checks" ## 📚 References - [GitHub Actions Documentation](https://docs.github.com/en/actions) - [GitHub Skills - Hello GitHub Actions](https://skills.github.com/) - [GitHub Marketplace Actions](https://github.com/marketplace?type=actions) - [Tutorial Repository](https://github.com/github/github-for-beginners-actions) ## 🗣️ Paraphrase - GitHub Actions serves as an integrated automation platform that eliminates manual repetitive tasks through event-driven workflows stored as YAML files in repositories - The system operates on a simple trigger-response model where repository events automatically initiate virtual machines to execute predefined sequences of actions or commands - Creating functional workflows requires understanding three core elements: naming conventions for clarity, event specifications for appropriate triggering, and job definitions with proper permissions and step sequences ## 📰 Newsletter **Automate Your WordPress Development with GitHub Actions** GitHub Actions brings powerful CI/CD automation directly to your repositories, perfect for WordPress developers managing plugins, themes, or core contributions. This beginner-friendly platform lets you automate testing, deployment, and repository management tasks without leaving GitHub. The tutorial demonstrates creating an auto-labeling workflow for issues—imagine applying this to automatically tag WordPress plugin compatibility issues, run security scans on theme submissions, or trigger deployment workflows for WordPress.org updates. The integration possibilities are endless for WordPress contributors. **Key Benefits for WordPress Developers:** - Automated testing for multiple PHP and WordPress versions - Security scanning for plugin and theme submissions - Deployment automation for WordPress.org releases - Issue management for community support **Getting Started:** 1. Create `.github/workflows/` directory in your repository 2. Add YAML workflow files with descriptive names 3. Configure triggers based on your needs (pushes, pull requests, releases) 4. Test thoroughly before deploying to production **WordPress-Specific Resources:** - [WordPress Coding Standards Action](https://github.com/marketplace/actions/wordpress-coding-standards) - [Plugin Deploy Action](https://github.com/marketplace/actions/wordpress-plugin-deploy) - [Theme Unit Test Action](https://github.com/marketplace/actions/wordpress-theme-unit-test) Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create GitHub Actions workshops for WordPress community events, demonstrate CI/CD benefits through live coding sessions - Education: Develop curriculum connecting GitHub Actions to WordPress development workflows, create office hours for automation questions - Developer experience: Document WordPress-specific GitHub Actions patterns, curate marketplace actions for common WordPress tasks - Developer marketing: Create content series showing WordPress automation use cases, promote community-contributed WordPress Actions - Community management: Moderate GitHub Actions discussions in WordPress Slack, gather feedback on automation pain points #### OSPO - Policy & Governance: Establish GitHub Actions usage guidelines for organizational repositories, create security review process for custom actions - License Compliance: Scan workflow dependencies for license compatibility, train teams on action licensing implications - Security Management: Review marketplace actions for vulnerabilities, establish approval workflow for third-party actions - Software Inventory: Track GitHub Actions usage across organization, document action dependencies in SBOM - Developer Support: Provide GitHub Actions training for internal teams, create consultation office hours - Community Engagement: Contribute back improved WordPress actions to marketplace, sponsor development of missing community actions - Strategic Alignment: Define KPIs for automation adoption, measure developer productivity improvements from CI/CD #### Community - Maintainers: Provide GitHub Actions templates for common project workflows, create governance docs for automated processes - Contributors: Build first-contribution workflows that guide new developers, implement automated onboarding sequences - Sponsors: Generate transparent automated reports on funding impact, create milestone-triggered communication workflows - Ecosystem: Coordinate cross-project Actions sharing, establish interoperability standards #### WordPress - Core: Implement automated performance regression testing, create issue triage workflows for core contributions - Core Performance: Set up automated profiling for pull requests, establish performance budget enforcement via Actions - Core AI: Create evaluation workflows for AI feature testing, implement automated safety checks for AI-generated content - Core Program Team: Coordinate dependency management across teams, implement retrospective automation workflows - Mobile: Automate app store deployment processes, implement telemetry collection workflows - Playground: Create automated lab environment provisioning, implement reproducible bug report workflows - Community: Develop automated meetup kit distribution, create WordCamp planning assistance workflows - Training: Automate lesson plan validation, implement learning path progression tracking - Marketing: Create automated campaign deployment workflows, implement social media scheduling automation - Support: Implement automated ticket triage and routing, create knowledge base update workflows - Design: Automate design token validation, implement UX audit workflow triggers - Documentation: Create automated content freshness checks, implement cross-reference validation - Photos: Implement automated content moderation workflows, create taxonomy validation processes - TV: Automate caption generation processes, implement content indexing workflows - Polyglots: Create automated translation validation, implement glossary consistency checks - Accessibility: Implement automated WCAG compliance testing, create audit report generation workflows - Meta: Automate .org infrastructure deployments, implement API reliability monitoring - CLI: Create automated command testing workflows, implement documentation generation processes - Hosting: Implement cross-host compatibility testing, create automated telemetry collection - Tide: Automate plugin scoring transparency reports, implement outreach workflow automation - Openverse: Create automated content ingestion pipelines, implement moderation workflow processes - Themes: Implement automated review queue management, create mentoring assignment workflows - Plugins: Create automated security scanning workflows, implement provenance verification processes #### The WPCC - Programs: Automate fellowship application processing, create automated stipend distribution workflows - Projects: Implement governance clinic scheduling automation, create documentation sprint coordination workflows - Funding: Automate matched grant processing, create milestone payout verification workflows #### FAIR - Technical independence: Implement automated metadata validation, create provenance checking workflows - Policies: Automate funding transparency reporting, create anti-capture monitoring workflows - Governance artifacts: Create automated charter validation, implement operator agreement verification workflows ## 🧪 Hypotheses - Organizations implementing GitHub Actions see 40% reduction in manual deployment errors within six months of adoption - WordPress contributors using automated testing workflows submit 60% fewer buggy commits compared to manual testing approaches - Teams with GitHub Actions issue automation resolve 50% more community issues due to improved triage and labeling efficiency - Developers new to CI/CD concepts achieve proficiency 3x faster using GitHub's integrated approach versus standalone tools ### 📊 Methodology - Study design to test hypothesis 1: Longitudinal analysis comparing deployment error rates before/after GitHub Actions implementation across 100+ WordPress organizations - Data sources and analysis for hypothesis 2: Git commit analysis measuring bug density in WordPress contributions, comparing automated vs manual testing workflows over 12-month periods - Experiments to validate hypothesis 3: A/B testing issue resolution rates across WordPress repositories with and without automated triage workflows ### ❓ Questions - How do GitHub Actions costs scale for WordPress.org's repository volume and contributor activity levels? - What security implications emerge when WordPress contributors use third-party marketplace actions for sensitive operations like deployments? - How can GitHub Actions integrate with existing WordPress infrastructure like Trac, Slack, and Make.WordPress.org workflows? ### 🔮 Future Research - Integration patterns between GitHub Actions and WordPress-specific tooling ecosystems (WP-CLI, Composer, WordPress.org APIs) - Security audit methodology for evaluating third-party GitHub Actions used in WordPress development workflows - Performance impact analysis of automated testing on WordPress contribution velocity and code quality metrics ### 💡 Implications - **Practice**: WordPress developers need GitHub Actions training to remain competitive, automation becomes standard expectation for professional WordPress development - **Policy**: WordPress.org may need to establish guidelines for automated plugin/theme submissions, security policies for marketplace action usage - **Security**: Automated workflows introduce new attack vectors through compromised actions, dependency chains require ongoing monitoring and validation - **Education**: WordPress training programs must integrate CI/CD concepts, Learn WordPress needs GitHub Actions curriculum development - **Funding**: Organizations should budget for runner costs, training investment, and potential productivity gains from automation adoption --- ## Full Transcript [00:00] Today, I'm going to teach you everything [00:02] you need to know to get started with [00:03] GitHub actions. [music] By the end of [00:05] this video, you will know how to use [00:07] GitHub actions and create your first [00:08] automated workflow. [00:14] Hey, I'm Cadesa and I'm so excited [00:16] you're here with me today. Let's talk [00:18] about how you can use GitHub actions to [00:20] automate common tasks in your developer [00:22] workflow like running vulnerability [00:24] scans, tests, creating releases, and [00:26] even reminding your team of important [00:28] [music] updates. [00:32] GitHub actions is a continuous [00:34] integration, continuous delivery or [00:36] CI/CD and automation platform built [00:39] right into GitHub. You'll often hear [00:41] people call these action workflows or [00:43] just workflows. It allows you to [00:45] automate repetitive task and deployment [00:47] processes using YAML files stored in [00:50] your repository. Action workflows are [00:52] triggered by GitHub events like pushes, [00:54] pull requests, or schedules, and they [00:56] run in a virtual environment. Let's take [00:59] a look at a few terms you'll see when [01:01] working with GitHub actions. We won't go [01:03] through all the terminology, but these [01:05] are the essentials. Events, hosted [01:08] runners, and jobs. An event is a [01:10] specific activity that triggers a [01:12] workflow. For example, pushing code, [01:15] opening a pull request, or creating an [01:17] issue. A runner is a virtual machine [01:20] that executes jobs in a workflow. GitHub [01:22] provides hosted runners, or you can set [01:24] up your own self-hosted runner. A job is [01:27] a set of steps that's executed within [01:29] the same runner. Each step is either a [01:31] shell command or a pre-built action from [01:33] the GitHub marketplace. Now, workflows [01:36] get triggered by events in a repository. [01:38] This can be a pull request, merging a [01:40] branch, or even opening an issue. When [01:43] the event fires and the workflow exists [01:45] that responds to that event, GitHub [01:47] spins up one or more jobs that execute [01:49] on a runner. This is essentially how a [01:52] GitHub action workflow works. When you [01:54] first go to the actions tab and click on [01:56] the new workflow button, you'll see a [01:58] suggested set of starter workflows that [02:00] you can use. If you click on one of your [02:02] suggested actions, you'll see three main [02:04] sections that you need to know when [02:06] building an action workflow. The name [02:08] section, which describes what your [02:10] workflow does, the on section, which [02:13] defines what triggers it, and the job [02:15] section, which is where the actual work [02:17] happens. [02:20] Learn more about GitHub actions by going [02:22] to GitHub skills and completing the [02:24] Hello GitHub actions challenge. You can [02:26] also read the blog post that accompanies [02:28] this episode at gh.io/gfbactions. [02:32] Okay, now for the fun part. Let's look [02:34] at how to actually build a workflow. To [02:37] follow along, head over to this [02:39] repository link and clone it to your [02:41] machine. Then go to the action start [02:43] branch. I'm bringing in Glenda to build [02:45] this workflow with us step by step. [02:51] GitHub actions uses JAML syntax to [02:53] [music] define workflows. Each workflow [02:55] is stored as ajaml file in a special [02:59] github/workflows [03:00] directory in your repository. So I'm [03:03] going to click into that github folder [03:05] at the root of the repository and then [03:08] into the workflows folder inside of it. [03:11] Let's create a workflow that auto labels [03:13] new issues created in our repository. [03:16] When creating workflow files, use [03:18] descripting names that tell you what [03:20] they do at a glance like build and [03:22] test.jamo or security scanner.jamo. [03:26] So let's give our workflow a name. I [03:29] will call it label new issue.jamo and [03:31] then I will add the name section to [03:34] start the jamo file. Now we need to [03:37] decide what events will trigger it. [03:39] GitHub has tons of trigger options [03:41] reflected in the documentations. So [03:44] choose based on what you're building. [03:46] Maybe you want to run tests when someone [03:48] opens a pull request or a scan for [03:50] security issues when a branch gets [03:52] merged. In our case, we will use the [03:55] issues trigger. Then add the activity [03:58] type open. This way whenever a new [04:00] GitHub issue is open, it will add labels [04:03] to it. Now we get to the good stuff, the [04:05] job section, where the actual work [04:07] happens. The first thing we'll do is [04:09] give our job a title and choose what [04:12] type of machine runs it. GitHub provides [04:14] hosted runners with different versions [04:16] of Ubuntu, Windows, and Mac OS. Let's [04:19] call this job label hyphen issues and [04:21] run it on Ubuntu latest. This tells [04:24] GitHub to grab a machine from their pool [04:26] of Ubuntu runners using the latest [04:28] version available. We also need to add [04:31] right permissions here so that action [04:32] can add the label. So let's add [04:34] permissions issues. Right. When we use [04:37] the permissions key within the jobs, all [04:39] the actions and run commands within the [04:41] job gain the access rights specified. [04:44] Now let's add a steps. This is where we [04:46] define what actually happens in the job. [04:48] You will see two main keywords here. [04:50] Uses and run. When you see uses, that's [04:53] spooling a pre-built action from the [04:55] GitHub marketplace such as checking out [04:58] your code or setting up Node.js. Those [05:01] are open-source reusable actions that [05:03] handle common tasks so that you don't [05:05] have to write everything from a scratch. [05:07] When you see run, that's executing a [05:10] command or a script. It can be a simple [05:12] oneliner like this one or a multi-line [05:15] script. The next step is for us to [05:17] configure our environment variables. [05:19] We'll use the ghersore token, ghers [05:24] repo, and number variables that are [05:26] automatically set. This means GitHub [05:29] actions will automatically know which [05:30] values to use for those variables based [05:32] on those secrets and GitHub context. [05:35] Let's add ghers token secrets.github [05:39] token. Then issue number [05:42] github.event.issue [05:44] number and finally let's add label which [05:47] will be the list of labels we want to [05:49] add. The labels must exist in the repo [05:52] for this to work properly. We will add [05:54] the triage label. And this completes our [05:56] first workflow. Putting it all together, [05:59] this workflow tells GitHub actions that [06:01] when a new issue is open, we want to run [06:04] it on Abuntu latest and add the triage [06:06] label to the issue. The GitHub actions [06:09] workflow syntax gives us a lot of [06:10] flexibility, but it is a good practice [06:13] to keep things simple as possible when [06:15] starting out. Let's test out the [06:17] workflow we just created by pushing it [06:20] to GitHub, creating a PR, merging it to [06:22] the main branch, and creating a new [06:25] issue in that repository. Let's open a [06:28] new issue. We will call it test workflow [06:31] and click create. Within seconds, you [06:34] will see GitHub actions pop up adding [06:36] the label triage. Let's go to the [06:38] actions tab to see the actual workflow [06:41] run. Looking on the actions tab on the [06:43] left hand side, we have a label new [06:46] issues workflow. When we click into it, [06:48] we will see the job label issues. And [06:51] when we click into the job, we will see [06:53] the steps used to complete it. We can [06:56] run and rerun actions workflows from [06:58] this tab. And if you need to pause it [07:00] temporarily, you can disable it directly [07:03] from the action tab instead of deleting [07:05] the file. The actions tab is where you [07:08] will go to see and manage all of your [07:10] workflows. You can check deployments, [07:12] runners, metrics, performance, and cache [07:15] from this view. You can also view and [07:18] edit your workflow file from this tab. [07:20] Congratulations. You have successfully [07:22] built your very first GitHub actions [07:24] workflow. [07:26] Thanks so much, Glenda, for showing us [07:28] how to build our first GitHub actions [07:30] workflow and also how to test it on [07:32] GitHub. Now, GitHub actions can do a lot [07:35] more than just label your issues. You [07:37] can create actions to publish packages, [07:39] greet new contributors, build and test [07:41] your code, and even run security checks. [07:44] Keep learning about GitHub actions by [07:46] going to [music] our documentation, and [07:47] reading the blog post that accompanies [07:49] this episode. I hope you found this [07:51] video helpful. Remember to subscribe to [07:53] GitHub's YouTube [music] channel so you [07:54] don't miss any of our future uploads, [07:56] and share with a dev friend who could [07:58] use this knowledge. Happy coding.  📄 **Full text:** ![[Full Document Contents/Articles/How to Use GitHub Actions GitHub for Beginners|How to Use GitHub Actions | GitHub for Beginners, YouTube]] ## Highlights - you’ll see when working with GitHub Actions. We won’t go through all the terminology, but these are the essentials: events, hosted runners, and jobs. An event is a specific activity that triggers a workflow. For example, pushing code, opening a pull request, or creating an issue. A runner is a virtual machine that executes jobs in a workflow. GitHub provides hosted runners, or you can set up your own self-hosted runner. A job is a set of steps that’s executed within the same runner. ([View Highlight](https://read.readwise.io/read/01kky5e3vpd485r5saab6ep5a0)) - Tags: 👻 ai highlighted - Each step is either a shell command or pre-built action from the GitHub marketplace. Now, workflows get triggered by events in a repository. This can be a pull request, merging a branch, or even opening an issue. When the event fires and a workflow exists that responds to that event, GitHub spins up one or more jobs that execute on a runner. This is essentially how a GitHub Action workflow works. When you first go to the “Actions” tab, and click on the “New workflow” button, you’ll see a suggested set of starter workflows that you can use. ([View Highlight](https://read.readwise.io/read/01kky5e3vw50n5d7s87bzj68d6)) - Tags: 👻 ai highlighted