Originally published on LinkedIn on October 3, 2025.
The main advantage of Specification Driven Development is that it helps break down a feature into a structured plan with actionable tasks. This way of working makes hidden details visible and makes instructing coding agents easier. Tools like GitHub Spec Kit guide this process through “/specify”, “/plan”, and “/tasks”, ensuring clarity before implementation.
Recently GitHub Spec Kit also introduced a few nice optional commands like “/analyze” which ensures cross-artifact consistency (alignment between spec, plan and tasks) within the feature.
Need for Non-Linear Analysis
But features rarely exist in isolation. When they interact, linear thinking alone is not enough. Contradictions, feedback loops, or emergent behaviours often appear across features. That is when we need non-linear thinking, and this is where Systems Thinking helps.
Until now, I was running ad-hoc prompts to verify multiple “spec.md” files against each other. Useful, but outside the natural Spec Kit workflow. So I started experimenting with a new command.
“/cross-feature” - An optional GitHub Spec Kit command that can be run after specifying a new feature (with “/specify”).
Here is a visual representation of how “/cross-feature” compares with “/analyze”.
Or as a metaphor, /analyze is vertical alignment; /cross-feature is horizontal alignment.
Real world example
Having worked in conversion optimisation, I have often seen cart abandonment journeys cause complexity. Let us walk through a simple progression of features.
Feature 1 - Add to Cart
/specify add to cart
- users can select several items and click on add to cart
- as part of adding to cart the inventory for the items is reduced accordingly
This would be followed by the usual “/plan”, “/tasks”, and “/implement”, and then merged back to main.
Feature 2 - Abandoned Cart
/specify abandoned cart journey
- any cart that has exceeded 15 min of inactivity is considered abandoned
- inventory that was blocked / reduced for the cart has to be restored once the cart is considered abandoned
- a notification has to be sent to the inventory manager over mail for restored inventory
Again, this goes through planning, tasking, implementation, and merging to main.
Feature 3 - Low Stock Alert
/specify low stock alert
- A mail notification has to go to the inventory manager when stock goes below 5 units for an item
- The mail has to go out within 5 min of the lower threshold being hit for the inventory
This time, let us imagine I am a new product owner introducing this feature. The key question is, will this impact existing features like Add to Cart and Abandoned Cart?
Time to check “/cross-feature”
Just as we ask coding agents to review and test our code, we can also ask them to wear the product hat and review feature specs.
When I ran “/cross-feature”, it generated a “cross-feature-analysis.md” with the following observation.
Potential Side Effects
- Notification storm: During high-traffic periods, multiple concurrent add-to-cart operations could cause cascading low stock alerts if many items drop below threshold simultaneously
This surfaced a cross-feature oscillation that is not obvious when reviewing features in isolation.
Let us “/clarify”
In addition to creating “cross-feature-analysis.md”, the “/cross-feature” command adds a reference to this file inside the feature’s “spec.md”:
[NEEDS CLARIFICATION: Review cross-feature alignment analysis in cross-feature-analysis.md - should monitoring track total inventory, available inventory (excluding cart reservations), or sold inventory?]
This ensures that when we run the optional “/clarify” command, Spec Kit will now ask targeted questions to resolve the issues flagged by “/cross-feature”.
Example status table
| Category | Status | Notes |
|---|---|---|
| Integration & External Dependencies | ⚠️ Outstanding | Cross-feature conflicts with cart system (see cross-feature-analysis.md) |
Example Clarification
> /clarify is running…
⏺ Read(specs/003-low-stock-alert/spec.md)
⎿ Read 125 lines (ctrl+o to expand)
⏺ Read(specs/003-low-stock-alert/cross-feature-analysis.md)
⎿ Read 89 lines (ctrl+o to expand)
⏺ I've analyzed the specification and cross-feature alignment. There are critical cross-feature conflicts that need resolution. I'll ask up to 5 targeted questions focusing on the high-impact alignment issues.
Question 1 of 5
Should low stock alerts monitor total inventory or only available (non-cart-reserved) inventory?
Context: Cart additions (feature 001) reduce inventory temporarily, which could trigger false alerts if carts abandon and restore stock within 15 minutes.
| Option | Description |
|---|---|
| A | Total inventory (triggers alerts even for cart-reserved stock) |
| B | Available inventory only (ignores cart reservations, alerts only on true stockouts) |
This helps prevent issues like the notification storm, which might otherwise be missed.
Recap
- “/analyze” keeps a feature consistent with itself.
- “/cross-feature” (experimental) checks how a feature plays with others, using non-linear approaches such as Systems Thinking.
This is still experimental, but it has already helped me surface issues like feedback loops, oscillations, and contradictions early, before implementation.
I have used Systems Thinking as a starting point, but analysing across features may require additional points of view and mechanisms as this evolves.
Curious to hear, how do you approach cross-feature alignment in your teams with GitHub Spec Kit? Would a command like “/cross-feature” fit into your workflow?
UPDATE: I have put together a new repo called spec-kit-extensions to test experimental commands. This will let you try “/cross-feature” while the above Pull Request is awaiting review.