Standardize Development with Context Artifacts
Guide for Conductor's context-driven development: structured project artifacts (product.md, tech-stack.md, workflow.md) for AI alignment.
Why it matters
Establish and maintain project context as a managed artifact alongside code. This ensures consistent AI interactions and team alignment through structured documentation, guiding development from concept to implementation.
Outcomes
What it gets done
Define product vision, technical stack, and team workflows.
Manage context artifacts for greenfield and brownfield projects.
Ensure AI alignment and team consistency through living documentation.
Facilitate onboarding and knowledge transfer for development teams.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-context-driven-development | bash Overview
Context-Driven Development
A guide for Conductor's context-driven development methodology: structured product/tech-stack/workflow/tracks artifacts kept synchronized to align teams and AI assistants across sessions. Use when setting up or maintaining Conductor project context, onboarding to a Conductor project, or handling greenfield/brownfield context setup.
What it does
Context-Driven Development treats project context as a first-class artifact managed alongside code, using the Conductor framework's structured documents instead of ad-hoc prompts. Core principles: context precedes code, documentation lives and evolves with the project, each type of information has a single source of truth, and consistent context produces consistent AI behavior. Work follows a Context → Specification → Planning → Implementation workflow, where the context phase establishes or verifies artifacts before requirements, task breakdown, and execution proceed.
When to use - and when NOT to
Use it when setting up new Conductor projects, onboarding team members to an existing one, maintaining consistency across AI-assisted sessions, deciding when to update context documents, or handling greenfield versus brownfield projects. Five artifacts each own a distinct concern: product.md (WHAT and WHY - vision, personas, features, KPIs), product-guidelines.md (HOW to communicate - brand voice, terminology, copy standards), tech-stack.md (WITH WHAT - languages, dependencies, infrastructure, tooling), workflow.md (HOW to work - methodology, git conventions, review/testing/QA gates), and tracks.md (WHAT'S HAPPENING - the work-unit registry), all organized as:
conductor/
├── index.md # Navigation hub linking all artifacts
├── product.md # Product vision and goals
├── product-guidelines.md # Communication standards
├── tech-stack.md # Technology preferences
├── workflow.md # Development practices
├── tracks.md # Work unit registry
├── setup_state.json # Resumable setup state
├── code_styleguides/ # Language-specific conventions
│ ├── python.md
│ ├── typescript.md
│ └── ...
└── tracks/
└── <track-id>/
├── spec.md
├── plan.md
├── metadata.json
└── index.md
Inputs and outputs
/conductor:setup initializes context interactively for greenfield projects (defining standards before code exists) or, for brownfield projects, analyzes the existing codebase to pre-populate artifacts from discovered patterns for review and refinement. A validation checklist covers product, technical, workflow, and track context before starting any implementation, and a defined context lifecycle (creation, validation, evolution, synchronization, archival) keeps artifacts current - cross-referenced so a completed track updates product.md, a new dependency updates tech-stack.md, and a workflow change propagates to affected track plans.
Integrations
The skill documents five anti-patterns to avoid - stale context, context sprawl across ad hoc locations, implicit undocumented knowledge, one-person context hoarding, and over-specification that becomes unmaintainable - plus integration points: pinning context files in the IDE, pre-commit hooks warning on dependency/context drift, and CI/CD checks verifying tech-stack.md matches real dependencies and tracks.md matches git branch state. Session continuity guidance covers starting a session (read index.md, check tracks.md, review the active track's plan.md), ending one (update progress, note blockers, commit with clear status), and handling interruptions (mark the task [~], commit work-in-progress, document undecided points).
Ten best practices anchor daily use: read context first, make small incremental updates rather than rewrites, link decisions back to context, version context alongside code, review it in code review, validate regularly, communicate significant changes, preserve history via git, question staleness when context feels wrong, and keep every item actionable.
Who it's for
Teams using Conductor for AI-assisted development who need a structured, synchronized context system - not scattered docs or re-explained context every session - to keep both the team and AI assistants aligned on product, tech stack, workflow, and active work. The payoff compounds as institutional memory: decisions and their rationale are preserved, context survives team turnover, and historical context informs future decisions rather than being re-litigated from scratch.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.