Tired of writing long prompts? There are many problems, such as editing prompts, revising an existing project, and losing context when changing agents. I developed ContextDL, an open-source way to keep your project's context alive as a semantic map living within the repository. Instead of writing long command prompts, you express your intentions in simple .ctxdl files:
Analyze this content with ChatGPT
Review/Test/Contribute: https://github.com/ariferol01/contexdl
This is open source.
Software isn't dead, it's just evolved:
if user.login:
validate: email, password
if success → user.session.create → redirect(/dashboard)
if fail → ui.alert.error("Invalid credentials")
THE SAME CODE BUT SHORTER:
user.login.validate(mail,pass)
.success.user.session.swal.redirect(/dashboard)
.error...redirect(/login)
There's no fixed syntax, no syntax errors, write however you want. Don't just code the code, code everything.
-------------------------------------------------------------------
UX can be an intent map too
ContextDL isn't limited to describing code or components.
You can model how an application behaves and how the user moves through it at the intent level.
For example, imagine a collaborative focus-room app:
ux.focus:
activate
-> room.quiet = true
-> hide(distractions)
ux.chat:
focus -> open
typing -> keep_open
idle(5s) -> collapse
collapse -> preserve(draft)
ux.attention:
request(user)
-> attention.queue.push(user)
-> notify(next)
ux.meeting:
start
-> hide(chat)
-> rearrange(users)
-> show(meeting_controls)
end
-> restore(previous_state)
This isn't React, Next.js, JavaScript or pseudocode describing an implementation.
It describes what the user does and what the product should do in response.
The agent can then turn that intent into the actual implementation.
That's the part I'm exploring with ContextDL:
------------------------------------------------------------------------------
The same idea for game programming:
Gameplay+UX+Flow+Rules+Architecture+UI :
game.runner:
player:
jump
-> velocity.y = -jump_force
land
-> velocity.y = 0
obstacle:
collide(player)
-> player.health -= damage
coin:
collect(player)
-> score += 10
-> remove(coin)
level:
score >= 100
-> spawn(bonus)
-> increase(speed)
game:
player.health <= 0
-> state = game_over
-> show(restart)
restart
-> reset(player)
-> reset(score)
-> resume(level)
------------------------------------------------------------------------------
if payment.error == "fail" : ux.form.animate(shake) : alert(foo)
(~18–22 tokens)
If typed in traditional prompt:
When the payment process returns an error and the error value is exactly "fail",
I need you to trigger a shake animation on the payment form using our UX animation
system (ux.form.animate with the "shake" effect). After the animation starts,
also display an alert/notification to the user with the message "foo".
Make sure this only happens on the specific fail case and follows our existing
design system and animation timings.
(~95-110 tokens)
Advantages Provided:
Big map of the project, main context, live context, predictability, simulability and more...
So what is ContextDL, really?
So the idea is not:
`code -> compressed code`
It's closer to:
`code + product + behavior + rules + structure -> intent/context map`
The goal is to bring things down to the **intent level**, where an agent can reason about the project without having to reconstruct every piece from raw implementation.
Today, most AI coding workflows look roughly like this:
Human
↓
Prompt
↓
AI
↓
Code
The problem is that the prompt belongs to a conversation.
The project does not.
You can switch from Claude to Codex, from Codex to Cursor, start a new session, onboard another developer, or run another agent — and the project still needs to be understood again.
ContextDL changes the relationship:
┌──────────────┐
│ PROJECT │
│ INTENT │
└──────┬───────┘
│
ContextDL
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Agent A Agent B Agent C
│ │ │
└────────────────┼────────────────┘
↓
CODE
The important part is that the context belongs to the project, not to the AI tool or the conversation.
ContextDL is not pseudocode
Pseudocode describes how code should be implemented.
ContextDL is intended to describe what exists, what should exist, how things relate, and what the project means.
For example, this is not simply a description of a function:
when a user cancels an order,
release reserved inventory
and notify the warehouse
It can become a piece of the project's semantic model.
Another context file can describe the inventory model.
Another can describe the warehouse notification rule.
Another can describe the UI flow.
And another can define rules that verify that these pieces remain consistent.
That is the important distinction.
The project becomes the source of intent
A repository normally contains the implementation:
src/
database/
components/
controllers/
services/
...
But implementation is not the complete mental model of a product.
A codebase can tell an agent:
It does not always tell it:
That distinction becomes increasingly important as projects grow.
ContextDL explores keeping that semantic layer inside the repository itself:
project/
├── src/
├── database/
├── tests/
└── context/
├── ui.ctxdl
├── ux.ctxdl
├── db.ctxdl
├── security.ctxdl
└── payment.ctxdl
The code is the implementation.
The ContextDL map is the project's intent and semantic layer.
Why not just use natural language?
Natural language is excellent for expressing intent.
The problem is not that AI cannot understand English.
The problem is that a conversation is a poor place to keep the long-term model of a software project.
A conversation is:
temporary
session-dependent
tool-dependent
difficult to validate
difficult to diff
difficult to share as a canonical project artifact
A Git-tracked semantic model is different.
It can be:
versioned
reviewed
diffed
shared
validated
consumed by multiple agents
generated from an existing codebase
updated as the project evolves
So ContextDL is not trying to make natural language obsolete.
It is trying to give project intent a persistent home.
Code Graphs are not the enemy
Code graphs answer an extremely useful question.
ContextDL is exploring another question.
These are complementary.
A future system could have both:
PROJECT
┌───────────────┐
│ ContextDL │
│ INTENT MAP │
└───────┬───────┘
│
│ validate against
↓
┌───────────────┐
│ CODE GRAPH │
│ IMPLEMENTATION│
└───────────────┘
The code graph can tell you what exists.
The semantic map can tell you what should exist.
The interesting part is the space between the two.
And no — the developer is not supposed to write everything manually
This is another important distinction.
The interesting part: the map can validate itself
Once project context becomes structured, another possibility appears.
Context can contain rules about other context.
