| name | create-agentflow-plan |
| description | Convert approved Django AgentFlow architecture into an exact app-owned implementation and migration plan without adding unapproved scope. |
Create Django AgentFlow Plan
Use this skill only after the relevant AgentFlow proposal is explicitly approved.
Contract
The approved architecture is the complete scope boundary. The plan must cover every changed
navigation item and table, flow, or document element. It must not invent models, fields, mixins,
enums, endpoints, tasks, schedules, platform components, or product behavior.
If planning exposes a missing decision, create a new architecture proposal and wait for approval.
Read The Approved Change
Read repository instructions, memories, .agentflow/references/django-architecture.md, and current
state:
python3 .agentflow/scripts/agentflow.py status
python3 .agentflow/scripts/agentflow.py snapshot --state approved
python3 .agentflow/scripts/agentflow.py proposal list
Use the proposal that produced the latest approved revision. Inspect Django source and migrations
to place work in the correct apps and follow established patterns, but do not let existing code
expand the approved product scope.
Write The Human Plan
Create .agentflow/plans/<plan-id>.md in implementation order. Each task must state its exact
architecture references, expected apps/files/symbols, dependencies, verification, and nearby
non-goals.
Where approved architecture requires them, plan explicitly for:
- model classes, model mixins, enums, fields, relations, indexes, and constraints;
- migration dependencies, compatibility order, data migration or backfill, and eventual cleanup;
- URL registration, serializers/forms, views, permissions, scope checks, transactions, and
response/error contracts;
- Celery task registration, enqueue-after-commit behavior, queues, idempotency, retries, timeouts,
state transitions, and Beat schedules;
- admin, signals, cache invalidation, settings, integrations, and platform changes represented in
the approved pages;
- focused tests and Django checks that prove each represented path.
Do not add a service layer, repository abstraction, mixin, common utility, Celery task, signal, or
refactor merely because it seems cleaner. Use only repository conventions needed to implement the
approved architecture.
Create The Traceability Manifest
Assign every required architecture reference to exactly one task in a temporary manifest:
{
"schemaVersion": 2,
"id": "add-course-enrollment",
"title": "Implement course enrollment",
"architectureRevision": "rev-...",
"proposalId": "add-course-enrollment",
"document": ".agentflow/plans/add-course-enrollment.md",
"tasks": [
{
"id": "persist-course-user-mapping",
"title": "Persist course enrollment",
"description": "Add the approved mapping model and constraints.",
"sourceRefs": [
"page:courses.course-user-mapping",
"page:courses.course-user-mapping#row:user"
]
}
]
}
Use navigation:, page:, and the documented column, row, cell, node, edge, group, section, and
block references. Validate until missing is empty, then register:
python3 .agentflow/scripts/agentflow.py plan validate --input /tmp/plan.json
python3 .agentflow/scripts/agentflow.py plan register --input /tmp/plan.json
Registration is immutable.
Reconcile Before Finishing
- Every required architecture reference appears exactly once.
- Every task has approved source references and stays in the owning Django app or Platform scope.
- Migration and deployment ordering is explicit where schema compatibility matters.
- Every permission, branch, failure, transaction, async boundary, schedule, and outcome is covered.
- Verification includes the relevant targeted tests,
manage.py check, migration consistency, and
task or schedule checks without introducing requirements absent from the architecture.
- The Markdown plan and traceability manifest describe the same work.
Report the plan path, plan ID, proposal, approved revision, and coverage. Do not begin
implementation unless the user requested it.
