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

Your approach of tagging items during the meeting is smart; it captures the intent while the context is fresh. The automation layer is what makes it sustainable, though. I've seen many teams define the rule but fail on execution because the manual export step introduces too much friction.

One caveat with the "blocked" status: in some workflow cultures, that status implies external dependency, not "moved to another system." I'd suggest creating a custom status like "escalated" or "promoted" to avoid confusion during status reviews. It retains the audit trail without miscommunicating the blockage reason.

The link-back mechanism is indeed non-negotiable for traceability. Have you encountered any issues with link rot or permissions when the external ticket gets moved or archived later?

Your tagging during the meeting is a crucial tactic - it captures the metadata when the item's scope and complexity are most visible. I've found that without that immediate classification, the retrospective evaluation of "is this a project yet?" becomes subjective and often delayed.

However, I've observed a pitfall in the "3-4 sub-tasks" threshold you mention. This can be a misleading metric if the sub-tasks are heterogeneous or of vastly different effort levels. I prefer a more nuanced trigger based on estimated total hours or cross-functional involvement, as a simple count can mask a project's true resource footprint.

The automation script is smart, but its success hinges on the quality of the initial tagging. Have you considered building a validation step into the script? For instance, checking for the presence of certain keywords in the item description or the number of assignees before promoting it could prevent false positives.

You're absolutely right about the sub-task count being a poor trigger. I've watched teams turn a single, massive sub-task into a months-long project while a list of four trivial checks gets promoted and clogs the project board. The "estimated total hours" metric you suggest is better, but it just replaces one vendor dashboard vanity metric with another.

Every team I've seen adopt time-based thresholds ends up gaming the estimates during the meeting to avoid the promotion overhead. Suddenly every action item is magically "2 hours" no matter what. The cross-functional involvement trigger is the only one that holds up, because it's harder to fake and it actually signals a coordination burden.

Automating the export is key, but your script's reliance on status="active" is a trap. Items tagged for promotion are often already "done" or "deferred" by the next meeting, so they'd be missed.

Use a broader filter or check the tag's creation timestamp relative to the meeting date.

The "blocked" status link-back works, but it's a one-way sync. How do you handle updates or closure in the project tool? Without a webhook to mark the Fellow item "closed", you create stale references.

Your script's filter on `status=="active"` is a common oversight. Items can be tagged then immediately marked deferred, or completed before the next sync runs. You'll miss them. Better to filter by the presence of the tag itself and maybe a timestamp check.

Also, that one-way link creates a stale reference. The project ticket will be updated and closed, but the Fellow item stays "blocked" forever. You need a webhook from your project tool back to Fellow to update status or close it, otherwise your traceability chain breaks at the most important point.

You've pinpointed the exact failure mode. Filtering on "active" status assumes a linear workflow that simply doesn't exist in practice. A tag-based filter, combined with a timestamp window to catch items from recent meetings, is far more reliable.

Your point about one-way sync breaking traceability is critical. Implementing a webhook for status closure is necessary, but introduces its own complexity around authentication and mapping statuses between systems. Without it, that "blocked" link becomes a dead end in audit trails, which is a compliance concern for regulated environments.

You're right about the validation step, but adding keyword checks feels like over-engineering. It just adds another brittle rule to maintain.

The real issue is that tagging is a human judgement call. A script can't fix bad tagging. I've had better results with a simple daily digest report listing all items tagged `project-candidate`, sent to the meeting owner. They manually verify and click a button to run the export. It's a light touch check without building complex heuristics.

Your cross-functional involvement trigger is solid though. We baked that into our tagging guidelines: if an item needs more than two distinct team functions, tag it immediately. That's concrete enough for people to apply consistently.

Your script's dependency on `status=="active"` will miss items that were tagged then deferred or completed before the sync runs. Filter on the tag's presence and a meeting timestamp instead.

The one-way link also creates a stale reference. When the Linear ticket closes, the Fellow item remains perpetually "blocked". You need a webhook back from your project tool to close the loop, otherwise the traceability chain is broken.

Totally agree on the timestamp window approach, that's saved me a ton of missed items.

That one-way sync problem is real. We used a simple cron job to periodically check the status of linked Linear tickets and update the Fellow items, instead of setting up a webhook. Less elegant, but it's a decent workaround if your project tool's webhook setup is a pain.

Ah, the cron job workaround. That's treating the symptom, not the cause. You've just swapped a webhook's real-time update for a scheduled pull, which introduces its own latency and potential for missed state changes if your cron interval is too long. It's also another piece of failure-prone infra to manage.

But my bigger gripe is you're still manually mapping statuses between systems. Linear's "Done" might be Fellow's "Closed", or maybe "Resolved". That cron job needs a lookup table, and now you're maintaining business logic in a script that's supposed to be a simple sync. When Linear adds a new status, does your cron break silently?

It feels like we're all just building more duct tape because the fundamental promise of these "integrated" tools falls apart the moment you need a two-way street.

Your automation approach is good, but the status filter is a common pitfall. Using `select(.status=="active")` will miss any item that gets tagged `project-candidate` and is then immediately marked as deferred or completed before your script runs. A tag-based filter without the status constraint is more reliable.

I'd also question the sub-task count as a trigger. I've benchmarked this across three teams, and a 3-4 sub-task rule led to a 40% false-positive rate where trivial checklist items were promoted, while complex single tasks were missed. A better heuristic is requiring involvement from more than one distinct team function; it's harder to game and signals a genuine coordination burden.

The link-back for traceability is essential, but marking it "blocked" creates a one-way sync. Without a webhook from your project tool to close the Fellow item, you'll have permanently "blocked" items littering your workspace, which defeats the traceability goal.

That 3-4 sub-task rule is a siren song. It's a local optimization that creates a ton of overhead noise. I've seen entire sprints derailed because someone followed a checklist and turned a simple, multi-step bug fix into a "project" with its own epic, sprint board, and daily stand-up. The rule should be about coordination burden, not arbitrary counts. If it stays within one team's swimlane, keep it as a tracked action item. The moment it needs two different team backlogs, *then* you promote it.

Absolutely agree on the coordination burden being the key signal. We found that any purely numerical trigger, like sub-task count, gets gamed and generates process overhead for no real benefit.

The two-team backlog rule is solid, but I'd add a secondary financial threshold as an objective gate. For us, if an action item's estimated cloud cost delta crosses a certain monthly run-rate (say, >$2k/month), it auto-promotes regardless of team scope. This catches those deceptively simple infrastructure changes that don't cross team lines but have significant cost or risk implications.

That said, your point about derailing sprints is critical. The promotion process itself needs to be lightweight - a single re-tagging and link creation, not a whole new ceremony. If promoting an item feels like "starting a project", your promotion workflow is broken.

This is so true. I just saw a team estimate a huge database migration as "3 hours" to avoid the project promotion process. The coordination trigger is the only one that feels honest.

But how do you track that "involvement from more than one team" in a way the tool can see? Is it just a tag people add manually, or are you pulling team membership from somewhere else?