Dn Turns Issues Into Agent Plans

dn is an Apache-2.0 TypeScript CLI from Chesapeake Dev for turning GitHub issues and local markdown specs into agent-ready implementation plans. It deals with the awkward gap between “the agent can code fast” and “the work still needs planning, review, commits, and handoff.” The useful idea is simple: keep the plan as a durable file in the repo, then let Cursor agents or another coding agent execute against that shared artifact. As of July 2026, the project is small and early, but the workflow it points at is already familiar to anyone using agents in real repositories.

Read the project as a handoff tool, not a chatbot wrapper

The interesting part of dn is not that it calls an agent. Plenty of tools do that.

The interesting part is that dn makes the plan a first-class object. A durable plan is a markdown specification that survives the chat session, can be reviewed in a pull request, and can be resumed by a different agent or human later.

The project’s README describes commands such as kickstart, meld, loop, land, sync, and fixup. The shape is easy to follow: turn an issue into a plan, route the plan to an agent, let the agent implement, then carry the work through commits, sync, review feedback, and PR cleanup.

That matters because agent work often disappears into conversation history. The agent may have made a good local decision, but the reviewer sees only a diff and a vague summary. dn tries to make the middle visible.

The trap is treating dn as magic backlog clearing. The better read is more modest: it is a CLI for making agent work less ephemeral. That is a real problem.

Why Hacker News cared about the boring middle

The Show HN pitch landed because it named a frustration developers recognize: coding got faster, but building software did not.

The slow parts are still there. Someone has to read the issue. Someone has to decide scope. Someone has to preserve constraints from AGENTS.md, README.md, or local docs. Someone has to split the work into reviewable steps and explain the final patch.

Dn’s bet is that the boring middle should be scripted and inspectable. Plans live as markdown files in the workspace, so they can move between OpenCode, Cursor, Claude Code, Codex CLI, or a human. That is a more portable unit than a chat transcript.

A concrete workflow looks like this:

dn --agent codex kickstart --awp \
  https://github.com/owner/repo/issues/123

The command in the project description reads the issue and repository instructions, then starts an agent-assisted workflow around it. In a Cursor repo, the natural companion is Cursor, Anysphere’s AI code editor, with cursor rules defining project behavior and Cursor Agent handling the implementation pass inside the IDE.

The trap is skipping the review boundary. If the generated plan is never read, it is just a longer prompt. The plan becomes useful when it is treated like design intent: small enough to inspect, specific enough to test, and durable enough to hand off.

Pair dn with Cursor rules at the repo boundary

Cursor users already have a place to put durable instructions: project rules. dn is a good reminder that rules and plans should not do the same job.

Rules should hold standing behavior. Plans should hold task-specific intent.

Here is a small .cursor/rules/agent-plan-review.mdc stub that keeps that boundary clear:

---
description: Use when implementing from a dn markdown plan or issue-derived spec.
globs:
  - "**/*.ts"
  - "**/*.tsx"
alwaysApply: false
---

Before editing code:
- Read the linked plan file and restate the intended scope in 3 bullets.
- Check AGENTS.md for local constraints before changing files.
- Do not expand scope beyond the plan without asking.

Before finishing:
- List changed files and why each changed.
- Run the smallest relevant test or explain why no test was run.
- Leave unresolved plan items as explicit follow-up notes.

This is the kind of rule that helps in Cursor agent mode because it narrows the agent’s behavior without stuffing every issue detail into permanent memory. The plan says what to build. The rule says how work should be handled in this repository.

If you use Cursor Skills, put repeatable procedures there instead: release note format, migration checklist, API compatibility review, or a standard bug reproduction script. If you use Cursor MCP, connect the external context the agent needs, such as GitHub issues or internal docs. The plan should point to context; it should not become a dumped archive of everything the agent might need.

For a deeper cluster of examples around subagents, skills, and rules, see the related training topic. A nearby story worth comparing is coding-agent-skill-library Serves Skills via MCP, because it shows the same pressure from the other direction: reusable capability wants a durable package too.

Try dn on one issue before trusting it overnight

The safest experiment is not a whole backlog. It is one boring issue with a clear expected diff.

Pick a task like “add validation to this form,” “rename this config field,” or “fix flaky parsing for empty input.” Avoid security-sensitive code, data migrations, and cross-service refactors on the first pass.

Use dn to make the plan, then run the implementation in the most reviewable environment you have. For Cursor users, that usually means keeping the plan open next to the diff while Cursor Agent works through the patch.

A small experiment plan:

• Choose one issue with fewer than five touched files expected.
• Add or confirm an AGENTS.md file for local repo rules.
• Generate a dn plan from the issue or markdown spec.
• Review the plan before any code changes.
• Let the agent implement one plan section at a time.
• Ask for a final changed-files summary.
• Review the diff against the plan, not against the agent’s confidence.
• Keep the plan file or summary in the PR so the reviewer can see intent.

Fit and not-fit cases:

The limitation is important: a durable plan does not make the plan correct. It only gives you something concrete to inspect, improve, and hand off.

Keep the review about intent, not vibes

The best reviewer question is not “did the agent seem smart?” It is “does this diff implement the plan we accepted?”

A lightweight Cursor review checklist helps:

## Agent plan review

- [ ] The plan states the user-visible behavior change.
- [ ] The diff only touches files needed for that behavior.
- [ ] Repo rules in AGENTS.md or Cursor rules were followed.
- [ ] Tests or manual checks map to the plan items.
- [ ] Any skipped item is named in the PR notes.
- [ ] The final summary explains the why, not only the files changed.

This is where dn’s markdown-first approach earns its keep. You can compare a plan, a diff, and a PR description without replaying chat history.

The trap is letting the plan become theater. If every plan is vague, enormous, or accepted unread, you have added ceremony without reducing risk. Keep the first plans small enough that a tired reviewer can actually check them.

Common questions

• Can dn work with cursor agents?

  Yes, dn’s README says it can be used with Cursor as well as OpenCode, Claude Code, and Codex CLI. The practical pattern is to let dn produce or manage the durable markdown plan, then use Cursor Agent to implement against that plan while Cursor rules and AGENTS.md provide repository boundaries.

• Is dn a replacement for Cursor rules or Cursor Skills?

  No, dn is not a replacement for Cursor rules or Cursor Skills. Use rules for standing repository behavior, skills for reusable procedures, and dn plans for task-specific intent. That separation keeps permanent instructions short while still giving the agent enough context for the current issue.

• Should I run dn from GitHub Actions overnight?

  Only after you have reviewed the same workflow on low-risk issues. The project explicitly points at GitHub Actions handoff, but unattended agent work needs tight scope, clear repo instructions, and a review gate. Start with one issue and require a human to read the plan before merge.

• What is the main risk with a markdown plan workflow?

  The main risk is false confidence. Markdown makes work reviewable, but it does not guarantee the generated plan is correct, complete, or safe. Treat the plan like a junior engineer’s design note: useful, inspectable, and worth improving before it drives code changes.

Best ways to use this research

• Best for: Developers already using Cursor Agent who want agent work to leave a durable trail before it becomes a diff.
• Best first artifact: A single dn-generated plan attached to one small PR, plus a short Cursor rule that says how agents should read and report against plans.
• Best comparison angle: Compare dn’s markdown plan to a chat transcript. The plan wins when work needs review, handoff, or resumption across sessions.
• Best caution: Do not start with cursor background agents or unattended CI runs. Prove the plan-review loop locally first, then decide whether automation is worth it.

Further reading

• Cursor — Agent
• Cursor — Rules
• dn — source

Next step

Try dn on one unglamorous issue and keep the generated plan beside the Cursor diff during review. If the plan makes the PR easier to judge, keep the pattern; if it does not, shrink the task and tighten the repo rule before trying again.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.