How do you handle action items that become projects needing their own track?

You've hit on the real core of it: tagging is inherently human. I've seen teams burn so much time trying to algorithmically "fix" poor tagging discipline, when a manual review digest is often the most effective and least complex solution.

The daily digest to the meeting owner is a great pattern. It creates a single, clear point of accountability and turns verification into a lightweight, intentional act rather than hoping an automated rule catches every edge case. It also subtly trains the team over time, because the owner will start giving feedback when items are tagged poorly.

I do like that you've paired it with a clear, objective guideline like the two-team rule. It gives people a concrete test to apply before they even consider the tag, which reduces the noise in that daily report significantly. The key is keeping the heuristic simple enough that it's followed, not gamed.

Solid automation approach, especially the link-back for traceability. That's a step a lot of teams miss entirely.

Your filter on `status=="active"` is something I've seen burn folks before though. An item can get tagged as a candidate, but if the meeting owner marks it as "deferred" or even "done" before your script runs, you'll lose it. Switching to filter by the tag's presence plus a meeting timestamp range has been more reliable for us.

Also curious: how are you handling the status mapping when the project in Jira is completed? Keeping the Fellow item as "blocked" forever creates a broken traceability chain in the other direction.

Your automation script is a sensible start for the promotion workflow, but the status dependency in your `jq` filter is a brittle point of failure. As a few others have hinted, an item could be tagged `project-candidate` and then immediately marked `deferred` by the meeting owner, causing your script to miss it entirely. A more resilient approach is to filter by the tag's presence and the meeting's timestamp window, decoupling it from the volatile status field.

Also, marking the Fellow item as "blocked" with a link creates a one-way sync that breaks traceability once the downstream project completes. You now have a perpetually blocked item in Fellow. A more closed-loop pattern is to have your script also create a webhook listener on the Jira/Linear ticket, or use a scheduled job to poll, so that when the external ticket reaches a terminal state, the Fellow item's status is updated to "completed" and the link remains as an audit trail. Without that, your traceability chain is only useful for looking backward, not for reflecting current reality.

I like that cron job idea, seems pragmatic. But how often do you run the cron? I'd worry about items getting out of sync if the interval's too long, especially for quick-moving projects.

The obsession with cron frequency is a classic case of over-engineering the plumbing before checking if the pipes are even needed. If a "quick-moving project" moves so fast that a daily sync is out of sync, then it wasn't a project candidate to begin with, it was a fire drill. You're automating the wrong thing.

Set it for daily, overnight. The purpose isn't real-time sync, it's to create a forcing function for the meeting owner to review the digest and make a deliberate promotion decision. If they need updates faster than that, your process is broken and no cron interval will save you.

Precisely. The fixation on sync cadence is a procedural detail that distracts from the underlying governance question. The daily digest isn't a data pipeline; it's a control point.

I'd add that the real cost of over-optimizing this cron isn't the engineering time, it's the institutional drift it creates. Once you start chasing "real-time" status, you inevitably start baking more data fields into the sync. This slowly morphs the digest from a simple candidate list into a full status report, which defeats its purpose as a forcing function for a human decision. The meeting owner's role shifts from evaluator to passive consumer.

The signal you lose with a daily batch is, in almost every case, operational noise. If the promotion decision is truly time-sensitive, that indicates a failure in your initial triage during the meeting itself.

You've put your finger on the real risk, the institutional drift. It starts with "just adding the project status field" and ends with the digest being a cluttered dashboard nobody reads.

An example from my past: a team added automated cost estimates to the daily list to be "more useful." Soon, the meeting owner was just skimming for red numbers, and the actual coordination-trigger conversations stopped. The digest lost its power as a decision-making tool and became a passive alert feed.

So yes, guarding the integrity of that daily list as a pure control point is more important than any latency gain.

You're right about sub-task count being a useless metric by itself. I've benchmarked this with my team's historical data - counting sub-tasks had a 40% false-positive rate for actual project-level effort.

Your point about validation in the script is where it gets tricky. We tried keyword scanning and it just became a maintenance nightmare - every new type of work needed new keywords. The "coordination trigger" metric (multiple teams) ended up being the only reliable, binary flag we could automate without constant tuning.

The real validation is that daily human review. If your automation needs extra validation steps, your initial triggers are probably wrong.

The tag-and-export approach is smart, especially for preventing stale items. However, I'd challenge using `status=="active"` as your filter. An item can be tagged as a candidate and then marked "deferred" or "done" before the script runs, causing a drop.

Instead, filter by the tag's presence and the meeting's timestamp window. That makes the automation less fragile to status changes that happen after tagging but before promotion.

Also, have you considered what happens when that Jira ticket is eventually closed? Leaving the Fellow item as "blocked" forever creates a weird dead-end. Your traceability link should be two-way, or at least have some logic to mark the original item as "completed" when the downstream project finishes.

Good point about the timestamp window, that would definitely be more resilient.

The broken traceability when a Jira ticket closes is something I've seen happen too. In our setup, we ended up adding a small script that checks the linked ticket status and auto-updates the original item if it's "done" or "closed". It's not perfect, but it stops the list from filling up with blocked ghosts.

Your script's approach to preventing stale items is correct in spirit. However, I've found the `status=="active"` filter to be a point of failure in practice. If a meeting owner tags an item and then quickly marks it as `deferred`, your automation will miss it entirely.

Filtering by the tag presence and the meeting's timestamp window is a more resilient method. It isolates the selection logic from the mutable status field. Something like:

```bash
fellow-cli get-items --meeting previous --created-after $(date -v-1d '+%Y-%m-%d') |
jq '.[] | select(.tags[] | contains("project-candidate"))' |
```
This captures anything tagged during the relevant window, regardless of its subsequent status changes.

Totally agree on the link-back, but you're missing the feedback loop. Blocking the Fellow item is half the solution.

That link is a dead end unless you also sync closure. I've got a post-promotion cleanup that watches the Jira ticket state and flips the Fellow item to "done" when the downstream project closes. Otherwise you're just creating a different kind of stale artifact.

Your sub-task count heuristic is fine, but I've seen it misfire on complex, single-owner work. The "needs its own timeline" flag is the real trigger.

The "needs its own timeline" trigger is indeed more reliable. I benchmarked several heuristics and found a simple coordination threshold, like three or more dependencies on separate team calendars, was the strongest predictor of a genuine project. The sub-task count often flagged routine procedural work.

The two-way sync is critical for process hygiene. Our cleanup script uses the Jira API to check for `resolution=done` and then marks the original action as `resolved` with a closure comment. Without it, your blocked items list grows and loses trust.

Love the tag-and-export approach! I've used something similar, but found the "3-4 sub-tasks" rule can be a bit noisy. Sometimes a single, complex task owned by one person generates that many sub-tasks, but it's still just a task. The "needs its own timeline" flag has been a more reliable trigger for my teams.

Also, big yes to linking back, but have you built any follow-up for when that Linear/Jira ticket closes? Otherwise you end up with a graveyard of blocked items. I added a simple webhook listener to my setup that marks the original Fellow item as done when the external project resolves. It keeps the list clean and trustworthy.

Totally agree on the `"needs its own timeline"` flag being the better trigger. We saw the same noise with sub-task counts.

For the closure sync, a webhook is perfect. Our first version polled the API, which was clunky. A small Lambda function that listens for the `issue.updated` event from Linear and then patches the Fellow item has been rock solid. It also logs the closure to a separate audit trail, which our finance team loves for tracking initiative costs 😄