GitHub Projects filter syntax: tested examples

GitHub Projects filters are typed into the filter bar at the top of a view as field:value pairs. This page lists every qualifier GitHub documents, shows how to combine them, gives ten filters you can paste into a view today, and points out the places where GitHub's own documentation is unclear. The GitHub reference and Gitsu examples are separate because their filter grammars differ.

How do I filter a GitHub Projects board view and save it?

Click the filter bar at the top of the view and type a qualifier, such as label:bug. GitHub suggests fields and values as you type. You can also press Command+K (Mac) or Ctrl+K (Windows and Linux) and type "Filter by" to pick a filter from the project command palette. In the board layout, clicking a value on a card, such as an assignee, filters to that value, and clicking it again removes the filter.

A filtered view shows a dot next to its name until you save it. Open the View menu and choose Save changes to keep the filter for everyone who opens that view.

When you add an item to a filtered view, GitHub applies the filtered values to the new item. Adding an item while status:"In progress" is active sets the new item's status to In progress.

Which qualifiers does GitHub Projects support?

GitHub documents these qualifiers for Projects. Replace the capitalised part with your own value, and quote any value that contains a space.

Text fields have their own rules. title:"Bug fix" matches titles that are exactly "Bug fix", and note:complete matches a Note field that is exactly "complete". A bare word such as API searches the title and every text field. A * inside a field value acts as a wildcard: label:*bug* matches labels containing "bug", title:API* matches titles starting with "API", and label:*support matches labels ending in "support".

The bare-word search matches the start of a word only. GitHub's example is the title "Document full-text search": Doc, full and search match it, while cument, ext and arch do not.

How do AND, OR and NOT work in a filter?

Spaces mean AND, commas mean OR within one field, and a leading hyphen means NOT.

• label:bug status:"In progress" shows items that have the bug label and are In progress.
• label:bug,support shows items with either label.
• assignee:octocat assignee:stevecat shows items assigned to both people. Repeating a qualifier is how you ask for all of several values.
• label:bug,onboarding assignee:octocat assignee:stevecat mixes the two: either label, and both assignees.
• -assignee:octocat, -status:done and -priority:1,2 hide the matching items.
• -no:assignee and -no:priority invert no:, so they show only items that have a value.

GitHub's documentation states that "Projects does not currently support logical OR filters across multiple fields." You cannot write "no milestone or no priority" as one documented filter.

How do I find issues with no label OR no assignee?

GitHub Projects cannot express no:label OR no:assignee as one documented cross-field filter; Gitsu can evaluate that query on the selected project's loaded items.

First decide whether your triage queue means either missing field or both. The difference changes which work you see:

On github.com, open a project view and use no:label, then inspect a second view filtered by no:assignee. A record can appear in both. The single query no:label no:assignee answers the narrower question, both fields missing, so it drops the first two hypothetical issues. Comma syntax does not solve this case because commas combine values inside the same field.

For one queue in Gitsu:

1. Open the GitHub project in Gitsu and check the loading notice.
2. Open the command palette with Command+K, type is:issue AND (no:label OR no:assignee), and choose Search with for that query.
3. Inspect a known issue with a label but no assignee, and one with an assignee but no label. Both should appear if they are among the loaded items.
4. Assign or label the work you intend to triage. Recheck the queue after the edits.

The example table explains the intended logic; it is not a live test of your project or an extension of the downloadable fixture. Gitsu's parser builds nested groups and its evaluator applies them to the loaded records. This is useful when the review question crosses fields. Keep GitHub's own views for collaborators who use github.com, since Gitsu's extra grammar is not a GitHub saved-view setting.

How do I filter by number, date and iteration ranges?

Use >, >=, < and <= for comparisons and .. for an inclusive range. Dates are written YYYY-MM-DD.

• priority:>1 shows priorities above 1, and points:<=10 shows 10 points or fewer.
• date:>=2022-06-01 shows items dated on or after 1 June 2022.
• priority:1..3 shows priorities 1, 2 and 3.
• date:2022-01-01..2022-12-31 shows items dated in 2022.
• points:*..10 uses * as an open end: anything up to and including 10.
• iteration:<"Iteration 5" shows items in iterations before Iteration 5.
• iteration:"Iteration 1..Iteration 4" shows Iterations 1 to 4. The whole range sits inside one pair of quotes.

What do @me, @today and @current mean?

They are keywords that GitHub resolves when the filter runs, so a saved view keeps meaning "mine" or "this sprint" next week.

• assignee:@me shows items assigned to whoever is signed in, and -reviewers:@me shows items you have not reviewed.
• date:@today shows items dated today. date:@today..@today+7 covers today and the next seven days, and date:>=@today covers today onwards.
• iteration:@current, iteration:@previous and iteration:@next select iterations relative to the one running today.
• iteration:@current..@current+3 covers the current iteration and the next three, and iteration:<@current covers every earlier iteration.

The iterations guide covers setting up the iteration field these keywords read.

Which filters work for common views?

These ten cover common views, and each uses only documented syntax. Rename status, date and iteration to the names of your own fields.

Where is GitHub's documentation ambiguous?

Four spots in the filtering docs are unclear, and it is better to test them on your own project than to trust either reading.

1. The updated comparison direction. The docs describe updated:>@today-1w as items "last updated seven or more days ago". Read as a date comparison, > a week ago means updated within the last week, which is the opposite. The docs do not say which reading GitHub applies.
2. last-updated versus updated. The docs' introduction uses last-updated:5days for "hasn't been updated in the last five days", but the qualifier table lists updated:NUMBERdays and then gives only @today examples. Neither table row shows the 5days form.
3. OR across fields. The docs say it is not supported. A capture of GitHub's filter suggestions taken on 5 August 2026 listed AND, OR and Exclude as suggested operators. If your project shows them, GitHub may be rolling this out ahead of its documentation.
4. Which fields the filter bar suggests. In that same capture, a number field and two date fields were missing from the suggestion list even though the docs say they can be compared. Typing the qualifier by hand is the safe route.

How does Gitsu handle the same filters?

Gitsu adds nested AND/OR groups to daily triage. Download the synthetic triage-board fixture for a reproducible example. It is a field map and four example issues, not an importer.

1. Create a GitHub Project with Status options Todo, In progress and Done, plus a number field named Estimate. Create bug and docs repository labels.
2. Recreate the fixture's records and field values. Its issue numbers are example identifiers; your repository assigns its own numbers, so keep a mapping.
3. Open the project in Gitsu and enter label:bug. It selects examples 101 and 103.
4. Enter no:estimate. It selects examples 101 and 104.
5. Enter label:bug AND (no:estimate OR status:Todo). It selects examples 101 and 103. This nested query is a Gitsu example, not a claim that github.com accepts that cross-field OR grammar.

These queries are tested against Gitsu's actual parser and evaluator. unknown:value and status:( are rejected. An unfinished query does not become an intentional empty-result filter; finish it before treating the current rows as its answer. Fixture tests do not establish the permissions or field names of your own project.

Gitsu reads GitHub's qualifiers in its own query box, and adds OR across fields. Open the command palette with Command+K, type a filter and choose Search with for that query. The current keymap leaves / unbound. Gitsu stores the filter in the view's ?q= link, so in the web app the same link reopens the filtered view. Gitsu can also build the same filter from chips with + Filter, and both routes produce one filter tree that a single evaluator runs. Save current view keeps the filter, grouping, sort and view mode on your device.

This existing product image shows the board interface; it does not show the cross-field OR query or certify that example on a live project.

What carries over unchanged, per Gitsu's parser code:

• field:value, commas for OR, a leading hyphen for NOT, and has: and no:.
• assignee:, label:, repo:, reviewers:, milestone:, parent-issue: and reason: resolve to the matching columns.
• is:open, is:closed, is:merged, is:issue, is:pr and is:draft.
• >, >=, <, <= and .. on number and date fields, @me, @today with an offset, and @current, @previous and @next.

Gitsu goes past GitHub in one respect: AND, OR and parentheses combine any fields, so no:milestone OR no:priority is a single filter. GitHub's docs say it cannot express that.

Where Gitsu differs today:

• A bare word matches anywhere in the title or body, so cument finds "Document". GitHub matches the start of a word only.
• @today offsets need a unit: write @today+7d, not @today+7. The form without a unit matches nothing.
• * wildcards inside a value (label:*bug*, title:API*) and * as an open range end (points:*..10) are not supported.
• Iteration ranges by name (iteration:<"Iteration 5") and ranges over the keywords (iteration:@current..@current+3, iteration:<@current) are not supported. iteration:@current on its own works.
• last-updated:5days is accepted but matches nothing. Use updated:<@today-5d for the same question.
• type: filters Gitsu's item kind (issue, pull request or draft), not GitHub's organization issue types.

The getting-started guide covers connecting a project, and the Linear vs GitHub Issues comparison sets GitHub Projects against Linear.

How do I use Gitsu for the next triage session?

Open your project in Gitsu and apply is:issue AND (no:label OR no:assignee) through the command palette's Search with action to review either missing field in one queue instead of reconciling two GitHub views. The web board is free; the macOS app, agents and MCP require a paid Seat. Check current capabilities and pricing before choosing those additional features.

Gitsu shows one active project and loads up to 2,000 items per project. A filter result covers the loaded data, so an incomplete board cannot establish that every issue has an assignee or label. Use GitHub's own interface for the remaining records and project administration.