Asana

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me task management that replaces Asana — and know what makes it ALMOST rather than YES.

Tasks in projects with dates and owners is a fortnight. What is not is **the layer above the task list**: portfolios that roll many projects into one view for people who never open a task, workload against real capacity, and the rules-and-forms machinery an operations team uses to run intake without asking a developer. That layer is the reason the subscription exists, and it is where most of your time will go.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode, with FTS5
- Caddy in front

THE DATA MODEL
- teams, projects: id, team_id, name, key, status, owner_id, start_on, due_on, is_archived
- tasks: id, project_id, section_id, number, title, description_md, assignee_id, due_at, start_at, estimate_hours, priority, position, parent_id, completed_at, created_at
- custom_fields and values, defined per project or globally, because the fields are how each team makes it theirs
- dependencies: task_id, blocks_task_id
- task_activity: id, task_id, field, old, new, actor_id, at — append-only, and the basis of every report
- portfolios: id, name, project_ids_json, owner_id; goals: id, name, target, current, source_json, owner_id, cycle_id, parent_goal_id
- capacity: user_id, hours_per_week, effective_from
- rules: id, scope, trigger_json, conditions_json, actions_json, is_active; rule_runs, append-only
- forms: id, project_id, definition_json — intake that creates a task with fields mapped

THE LAYER ABOVE
- A portfolio is a saved set of projects with a status per project, updated by its owner, plus a rolled-up progress computed from tasks. The status is written by a person; the progress is computed. Never mix them
- Goals with a measurable target and a current value, optionally pulled from a query or an endpoint, with a check-in cadence and a confidence recorded separately from the number
- Workload: assigned estimate hours per person per week against their capacity, with over-allocation visible before the week starts rather than reported after it. Without estimates this view is a task count, which is worthless — so make estimates required for anything in a workload view

RULES AND FORMS
- Triggers: a task created, a field changed, a due date approaching, a section change, a schedule
- Actions: assign, set a field, move, add a follower, post a comment, call a webhook
- Every run recorded with its result; a rule that silently does nothing is worse than none
- Forms create tasks with fields mapped, public or internal, with a honeypot and a rate limit

VIEWS
- List, board, calendar, and a timeline with dependencies drawn
- All from one query builder with five renderers, never five implementations
- Filters saved as views, shareable by URL, with permissions checked inside the query

THE REST
- Comments with mentions, attachments stored by hash, followers, and notifications batched into a digest with mentions immediate
- Search with FTS5 across titles, descriptions and comments
- Recurring tasks with the two kinds — on a schedule, and N days after completion
- Export everything as JSON and CSV in one command

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
The activity log and required estimates. Every report above the task list is derived from those two, and neither can be reconstructed later.