GetDone
See Repository usage for adoption and maintainer instructions. Read the hosted GetDone documentation for installation and distribution guidance. Install the published Python package from PyPI.
An agent-neutral, Markdown-first development workflow pack with optional Python tooling.
Repository boundary
The filesystem has one authoritative product boundary:
skill/ read-only content consumed by agents and projects
Everything outside skill/ develops, validates, packages, or explains that product:
getdone/ command-line implementation
tests/ contract and safety tests
development/ maintainer-only tools, entry points, benchmarks, and rollout evidence
docs/ maintainer and user documentation
examples/ repository-development examples
.github/ CI configuration
A consuming project's mutable plans, journals, reports, decisions, and TODOs belong in
that project's .agent/ directory. They never belong in this repository.
Operating model
GetDone has two agent-facing surfaces with different responsibilities:
- Project-owned
.agent/records hold the current project context, plans, tasks, evidence, decisions, risks, and next deterministic step. Agents read and update these files during normal work. - The shared
skill/pack supplies read-only workflows, standards, acceptance gates, policies, and record contracts. Agents load only the documents selected for the current task. - The
getdoneCLI bootstraps records, selects relevant guidance, validates contracts, runs diagnostics, and generates planning prompts. It is a deterministic guardrail, not the agent's working memory.
A shell-capable coding agent may run the CLI directly. ChatGPT or another agent without
repository access can work from uploaded .agent/ records and selected skill documents;
the user then applies the proposed files and runs local validation. The repository remains
the source of truth in both cases.
Normal agent context
Agents do not read the whole pack. A normal single-language feature, bug-fix, or refactoring task loads six canonical documents:
- General deterministic workflow.
- Task-specific workflow.
- Core engineering standard.
- The language standard for each materially affected implementation surface.
- Core acceptance gate.
- Applicable change-type gate.
Investigations normally load five. Policies and references are conditional and are read only when their trigger applies. The selector supports Python, Rust, C++, Dart/Flutter, q/kdb+, and TypeScript. Single-language tasks normally select six files. Polyglot tasks add one language standard per materially affected language; standards are not loaded merely because a language exists elsewhere in the repository.
Document contracts
Canonical content is intentionally separated by purpose:
- Procedures define triggers, inputs, ordered steps, decisions, evidence, stop conditions, and completion criteria.
- Standards define rules, observable review triggers, required responses, exceptions, and evidence.
- Acceptance gates define pass, waiver, and failure conditions.
- Policies define when a cross-cutting constraint applies and the exact action and evidence it requires.
- References explain optional patterns, components, decisions, and worked examples; they are not mandatory context.
Repository validation rejects incomplete operational contracts. See
docs/content-architecture.md.
Controlled project records
Project-owned .agent/ records are governed by one semantic contract and one
machine-readable registry:
skill/contracts/project-records.mdskill/contracts/project-records.json
Draft records may retain guided comments. Ready, active, current, completed, recorded, approved, passed, or final records require controlled statuses, exact section order, stable IDs, binary criteria, evidence, and valid roadmap references. The contract is loaded only when records are created or materially updated, not during ordinary coding.
Install and start
Install the GetDone CLI from the getdone-dev PyPI distribution:
python -m pip install getdone-dev
getdone --version
The installed package contains the immutable shared skill tree, so normal usage does not
require a separate skill-pack download or --skills-root:
getdone doctor
getdone init
getdone guidance --task-class feature --changed-path src/example.py
getdone validate --project-root .
getdone guidance emits the selected Markdown content directly for coding agents. Use
--paths-only when you only want the compact logical-path selection.
Follow the golden-path tutorial for one complete iteration.
What GetDone does not do
GetDone does not write application code by itself, replace project tests or CI, replace an issue tracker, require one coding-agent vendor, approve waivers automatically, or guarantee correctness merely because structural validation passes. It supplies bounded guidance, project records, and evidence contracts; the consuming project remains authoritative for its behaviour and release decisions.
Distribution
GetDone releases three separate artefacts:
- Full source archive: product plus development infrastructure.
- Skill-pack archive: only
VERSIONandskill/. - Python wheel: tooling only; point it at a full checkout or extracted skill pack.
See docs/distribution.md and docs/package-naming.md.
Run python development/scripts/check_release.py --repository-root . for the automated local release preflight.
PyPI publication is performed by the tag-only GitHub Actions workflow documented in
docs/releasing.md. The workflow accepts credentials only through the
PYPI_API_TOKEN secret in the protected pypi GitHub Environment and rejects tags that do
not point to the current main HEAD.
Validate
python development/scripts/validate_repository.py --repository-root .
python development/scripts/validate_frontmatter.py --repository-root .
python -m development.tools.validate_skill_content --repository-root .
getdone-validate-records --project-root /path/to/project --skills-root .
python development/scripts/generate_indexes.py --repository-root .
python -m pytest
Release status
v1.0.0 is the first stable release, with the Typer umbrella CLI, diagnostics, packaging metadata, licensing, and one golden-path example.
Release setup for maintainers
Repository-level release setup can be automated from a source checkout after GitHub CLI authentication:
python development/scripts/configure_github_release.py --repository OWNER/getdone
Add --set-pypi-token and provide the token on standard input to configure the protected pypi environment secret. See docs/releasing.md. This script is not included in the user wheel.
Metadata
Release files for getdone-dev 1.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| getdone_dev-1.1.2.tar.gz | 162.7 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| getdone_dev-1.1.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 381.0 kB
Release files / getdone_dev-1.1.2.tar.gz
| Download URL | getdone_dev-1.1.2.tar.gz |
|---|---|
| Size | 162.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c77b5bd42c3407d8fbe73025245ef201e8fdb9665adc5ff6052cecc68800fe7b
|
|
BLAKE2b-256 checksum How to use checksums |
352c7b8796732212e0b4ca796e4da1f6400b5c8cd12acbbc485cbe294969c8f4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.11.15
|
Release files / getdone_dev-1.1.2-py3-none-any.whl
| Download URL | getdone_dev-1.1.2-py3-none-any.whl |
|---|---|
| Size | 218.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
99abed370ad1e137bb319f54dd401b915133635492705855f29915a41a2286a6
|
|
BLAKE2b-256 checksum How to use checksums |
92fce821339c747b4fcda90fe3b7bb9d9e77f13d8bfc471635c7c000aff10de6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.11.15
|
Security for getdone-dev 1.1.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.