How do I install the Tracking Issues skill?

Run npx skillmds@latest add dada-lang/tracking-issues in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tracking Issues safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tracking Issues?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tracking Issues free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tracking Issues?

dada-lang (@dada-lang) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tracking Issues by dada-lang — Agent Skill

Name: Tracking Issues
Author: dada-lang

File contents

Tracking Long-Running Work

Use GitHub issues as living documents to maintain context across work sessions. One issue per user-facing feature.

Quick Reference

# Find active work
gh issue list --label tracking-issue

# Check a specific issue
gh issue view <number>

When to Use

Not for RFC features. RFC-tracked work uses impl.md in the RFC directory for detailed progress tracking. A GitHub issue for an RFC should just be a lightweight pointer with links to the RFC and its impl status (e.g., https://dada-lang.org/rfcs/NNNN-feature-name/impl.html).

For non-RFC work (refactors, bug investigations, infrastructure) that spans 2+ sessions or multiple code areas, use a tracking issue.

Issue Structure

Labels: tracking-issue, ai-managed, plus type (feature, bug, refactor)

Title: Clear user-facing outcome (not "encryption work" — instead "Implement client-side encryption")

OP template (keep updated as the living summary):

# Feature Name

**Status**: Planning | In Progress | Blocked | Complete

## Current Understanding
Brief summary of what needs to be done and current approach

## Next Steps
- [ ] Specific actionable item with file:line references
- [ ] Another concrete next step

## Open Questions
- What we're still figuring out

## Context
Key background and why this work matters now

Working with Issues

Starting a session

Read the issue OP to understand current state. Work from "Next Steps."

During work

Update OP when: approach changes, major blockers discovered, next steps shift
Add comments when: completing work sessions, discovering insights, hitting roadblocks

Checkpointing

Find relevant tracking issue
Draft a comment summarizing the session
Show draft to user for approval before posting
Update OP if approach or next steps changed

Comment structure

**Session summary:**
- What was attempted or explored
- Key discoveries or problems encountered

**Impact on approach:**
- How understanding changed
- New questions that emerged

**Progress:** Completed items from next steps, what's next

Completion

Set status to "Complete" and close the issue.

Boundaries

Only modify issues labeled ai-managed
Always get user approval before posting comments or editing the OP
Reference issues in commit messages when relevant

---name: tracking-issuesdescription: Track context across sessions for long-running features. Use when starting multi-session work, checkpointing progress, or resuming work on a feature tracked in a GitHub issue.---# Tracking Long-Running WorkUse GitHub issues as living documents to maintain context across work sessions. One issue per user-facing feature.## Quick Reference```bash# Find active workgh issue list --label tracking-issue# Check a specific issuegh issue view <number>```## When to Use**Not for RFC features.** RFC-tracked work uses `impl.md` in the RFC directory for detailed progress tracking. A GitHub issue for an RFC should just be a lightweight pointer with links to the RFC and its impl status (e.g., `https://dada-lang.org/rfcs/NNNN-feature-name/impl.html`).For non-RFC work (refactors, bug investigations, infrastructure) that spans 2+ sessions or multiple code areas, use a tracking issue.## Issue Structure**Labels**: `tracking-issue`, `ai-managed`, plus type (`feature`, `bug`, `refactor`)**Title**: Clear user-facing outcome (not "encryption work" — instead "Implement client-side encryption")**OP template** (keep updated as the living summary):```markdown# Feature Name**Status**: Planning | In Progress | Blocked | Complete## Current UnderstandingBrief summary of what needs to be done and current approach## Next Steps- [ ] Specific actionable item with file:line references- [ ] Another concrete next step## Open Questions- What we're still figuring out## ContextKey background and why this work matters now```## Working with Issues### Starting a sessionRead the issue OP to understand current state. Work from "Next Steps."### During work- **Update OP** when: approach changes, major blockers discovered, next steps shift- **Add comments** when: completing work sessions, discovering insights, hitting roadblocks### Checkpointing1. Find relevant tracking issue2. Draft a comment summarizing the session3. Show draft to user for approval before posting4. Update OP if approach or next steps changed### Comment structure```markdown**Session summary:**- What was attempted or explored- Key discoveries or problems encountered**Impact on approach:**- How understanding changed- New questions that emerged**Progress:** Completed items from next steps, what's next```### CompletionSet status to "Complete" and close the issue.## Boundaries- Only modify issues labeled `ai-managed`- Always get user approval before posting comments or editing the OP- Reference issues in commit messages when relevant

Frequently asked questions

Tracking Issues