- Published on
How I Use Claude Code and GitHub to Track My Work
- Authors
- Name
- Jeremy Garrell
I manage a personal project, learning federal, state, and local government contracting so I can win contracts as a small business, entirely through a private GitHub repo and Claude Code. A GitHub Projects board is the daily view of what's next, every task on it is a real GitHub issue, and a custom Claude Code skill acts as the operator that keeps the board, the issues, and a set of notes files in sync. Four slash commands cover the whole loop: a morning standup, turning a document into tracked work, capturing what I learned, and a weekly review.
What was this workspace built to do?
The repo's own description is direct about the goal: it's a "learning workspace for federal, state, and local government contracting" aimed at winning contracts, not landing a job at a government-contracting firm. That distinction matters for how the whole system is designed. Everything on the board is supposed to move toward getting registered, finding real opportunities, and bidding, not just accumulating reading material.
The workspace tracks that kind of work across a handful of general phases: getting eligible to sell (registrations, certifications), seeing the market (where opportunities get posted), knowing the rules (regulations that actually apply), getting on contract vehicles, building a pipeline of relationships and capability, and eventually writing and winning proposals. If you're at the point of actually registering with a state or county, I've written separately about what that registration process looks like for a small IT firm in Florida.
How does GitHub function as the system of record?
The GitHub Project board is meant to be the daily view: the rule behind the whole system is that it should always be accurate, since it's supposed to be the first thing checked before anything else. Every card on that board is a real GitHub issue in the repo, not a sticky note disconnected from anything. That matters because it means a task carries real state: comments, labels, a status, and dates, instead of living only inside a spreadsheet or a notes app.
Each issue gets exactly one topic label describing which phase of the work it belongs to (things like market research, capture and business development, or state/local government outreach), plus a label describing what kind of task it is: a study item, an action item, or something that produces an artifact like a document. The project itself has custom fields beyond the basics, including Status, Iteration, Quarter, Start date, and Target date, which is what turns a flat issue list into something with a timeline.
What does the Claude Code skill actually do?
The system runs through a Claude Code skill. In Claude Code, a skill is a SKILL.md file with two parts: YAML frontmatter that tells Claude when to use it, and markdown instructions Claude follows once it's loaded. Claude can load a relevant skill automatically, or you can invoke one directly by typing /skill-name.
My skill's frontmatter describes itself as something to use "when working the government contracting learning roadmap in this repo — asking what's next, running a daily or weekly check-in, reporting something finished or learned, handing over a PDF/email/document to turn into tracked work, or reshaping the roadmap." The skill's role, in its own words, is to run the tracking system "so he can spend his time learning instead of organizing."
That role comes with rules, not just permissions. The skill is not supposed to invent progress: something only gets marked done when I say it's done, never inferred from a note or a file. Before it creates or closes issues, or reshapes the roadmap, it has to propose the change as a numbered list first; I reply with which numbers to act on, or "all." One-line status updates I've explicitly asked for don't need that step. And every task is supposed to be sized to one 30 to 90 minute sitting, with an observable "done when" condition instead of a vague, open-ended goal.
What do the four slash commands do?
Custom commands in Claude Code are markdown files that expand into instructions when you type /command-name; the text after the command name is available inside them as $ARGUMENTS. Mine break down into four modes:
| Command | When I run it | What it does |
|---|---|---|
/standup | Every morning | Reports what's in progress, what's most worth doing next, and anything overdue or untouched for more than 14 days, then recommends one focus for the day |
/ingest [file] | I have a PDF, email, or solicitation to process | Reads the source completely, summarizes it, and proposes new issues as a numbered list before creating anything |
/learned <thing> | I learned something worth keeping | Writes or updates a note, links it to the related issue, and updates the notes index |
/review | Weekly | Summarizes what closed, flags stale items, and proposes roadmap adjustments as a list |
How does a document actually turn into tracked work?
The ingest command is the clearest example of the "propose before you write" rule in practice. I drop a document, for example a solicitation PDF or an email thread, into an inbox/ folder and run /ingest. The skill reads the source in full before proposing anything, summarizes what it is in three lines, and then extracts the work as a numbered list: a specific, small title for each item, labels for topic and kind, a "done when" condition, and which part of the source it came from. It flags any deadlines, dollar figures, clause numbers, or eligibility requirements the document states, quoted rather than paraphrased. Nothing gets created until I reply with which numbers to act on, or "all." A genericized example of what that produces is a task like "contact a local small-business office," sized to one sitting, with its own done condition, rather than an open-ended note to "look into local outreach."
How does it avoid stating facts it shouldn't know?
Government contracting runs on specific, frequently changing facts: clause numbers, dollar thresholds, size standards, certification criteria. Getting one wrong from memory is the kind of mistake that can cost a bid or a registration, so the skill has a hard rule against it: it's never supposed to state a FAR or DFARS clause number, a dollar threshold, a NAICS size standard, or a certification requirement from memory. It either cites the source document, looks the fact up, or marks it [verify: acquisition.gov] for me to confirm later.
The domain taxonomy backing the whole system draws the same line around itself: it's described as "a map of what to learn, not a source of facts," with every dollar threshold, clause number, and size standard in it deliberately omitted or marked [verify], because programs get renamed and thresholds get inflation-adjusted.
How do I see progress across everything?
GitHub's roadmap layout for Projects turns the board into a timeline: it uses the Start date and Target date fields to position issues across a configurable span, and you can drag an item to shift its dates directly on that timeline. For me, switching the board into that view is what turns a list of open issues into something I can actually plan around.
In practice, the combination of GitHub Projects and the Claude Code skill has helped with three things specifically: organizing what had been a large, unsorted list of tasks, reorganizing priorities easily as things change or new information comes in, and using the roadmap view to visualize how work is projected to land over time, instead of just seeing a flat backlog.
FAQ
Do I need a paid GitHub plan to use Projects this way? No. GitHub's pricing page lists "Issues & Projects" as part of the Free plan, available the same way on the Team and Enterprise tiers, so this setup doesn't require an upgrade.
Can a Claude Code skill work in a repo that isn't actual code? Yes. A Claude Code skill is just a SKILL.md file with frontmatter and instructions, loaded from a .claude/skills/ directory in whatever repo you're working in. My govcon repo is mostly markdown notes and GitHub issues, no application code, and the skill works the same way it would in a codebase.
Is it a problem to put business notes and tasks in a GitHub repo like this? Not if you set the repo and the project board to private, which is what I did here. Both are configured as private, so the notes, issues, and board aren't visible outside my own GitHub account.
Do the slash commands work if I just browse the repo on GitHub.com instead of using Claude Code? No. The commands and the skill only run inside a Claude Code session pointed at the repo. Browsing the repo or the Project board on GitHub.com shows you the same underlying issues and fields, but nothing there executes the skill's instructions.
What stops the assistant from marking things done that I haven't actually finished? The skill's rules explicitly forbid it: it's only supposed to mark an issue done when I say it's done, and it isn't supposed to infer completion from a note, a file, or the conversation. If something looks finished, the rule is to ask rather than assume.