Know Today
👀 Keep an eye on
- Issue trackers can act as durable, inspectable memory when an initiative outgrows a single agent session.
- Separating research, prototype, decision, external-action, and implementation tickets makes uncertainty visible instead of burying it in chat history.
- A dependency-aware “frontier” of actionable tickets can keep parallel agent work from starting before its inputs exist.
- Generated specifications are more useful when they retain links back to the decisions and experiments that shaped them.
- Prototype checkpoints are the practical counterweight to agent-assisted planning turning into a rigid upfront plan.
🛠️ Practical workflow
| Stage | Useful output |
|---|---|
| Map the initiative | Create a parent decision map with a clear destination, open questions, evidence, and blockers. |
| Reduce uncertainty | Run bounded research, small prototypes, and human discussions as separate tickets rather than presumed implementation tasks. |
| Advance the frontier | Open a fresh agent session only for tickets whose dependencies are resolved, then write findings back to the map. |
| Implement with traceability | Generate implementation tickets from settled decisions and preserve links to the underlying rationale for review and recovery. |
💭 Opinions worth testing
- Opinion: Persistent planning state may matter more for ambitious agent work than making a single prompt or session longer; test this on work with genuine cross-cutting dependencies.
- Opinion: Specifications can be temporary destination documents once code and decision history are reliable; retain them where audit, onboarding, contracts, or operations require durable documentation.
- Opinion: Frequent prototypes keep a decision map grounded in product feedback; use them before committing to architecture that is costly to reverse.
⚠️ Caveats
- The demonstrated workflow and its tooling claims are anecdotal, with no comparative benchmarks, cost data, failure rates, or security analysis.
- Verify tracker integrations, access controls, synchronization behavior, stale-decision handling, and maintenance status before putting sensitive project state into an agent workflow.
- External actions and coordination still need explicit ownership and human review; ticket structure does not make an agent independently safe or authorized.
- For a small, well-scoped change, the planning overhead can outweigh the benefit of a durable map.
✨ Try this today
Build a decision map for one fuzzy feature
Create a parent ticket and five child tickets covering research, a prototype, a decision, a dependency, and implementation. Ask an LLM to identify blockers and expected evidence; the outcome should be a plan you can inspect and revise without reopening the original conversation.
Prototype before choosing an architecture
Pick one unresolved technical choice and make two minimal prototypes, each with a success criterion. Have an LLM summarize the observed trade-offs into the decision ticket; the outcome should be a decision supported by concrete behavior rather than preference.
Run parallel changes with isolated worktrees
Create separate Git worktrees for two unblocked prototype tickets and run local instances on different ports. Give separate LLM sessions narrowly scoped prompts and review the resulting diffs yourself; the outcome should be faster comparison without agents sharing a working directory.
Test spec traceability
Generate a short implementation spec from your decision map, then deliberately ask an LLM a question the spec does not answer. The outcome should reveal whether links to the original decision tickets provide enough context to resolve ambiguity.