context-driven-development

Overview of context-driven-development skill

What the context-driven-development skill does

The context-driven-development skill helps you create and maintain a small set of project context artifacts in a conductor/ directory so AI-assisted development has stable, reusable grounding. Instead of re-explaining your project in every chat, you define core documents such as product.md, tech-stack.md, workflow.md, and tracks.md, then update them as the project evolves.

Who should install it

This skill is best for people using Conductor-style workflows, multi-session AI development, or team environments where project intent, stack choices, and work tracking need to stay consistent across prompts. It is especially useful for:

• new project setup
• onboarding an AI agent to an existing codebase
• teams that want repeatable project context
• users tired of losing context between sessions

The real job-to-be-done

Most users do not need “more documentation.” They need AI outputs that stop drifting. The practical job of context-driven-development is to turn vague, session-local project knowledge into managed artifacts that survive across implementation tasks, planning, and handoffs.

What makes it different from ordinary prompting

A normal prompt can describe your app once. The context-driven-development skill gives you a structure for keeping that description current and internally consistent over time. Its differentiator is not code generation by itself, but context scaffolding and synchronization before and during development.

What you get if it fits

If you use context-driven-development for Context Engineering, the main payoff is better continuity:

• clearer product intent
• documented stack decisions
• explicit workflow expectations
• tracked work units instead of loose TODOs
• better agent onboarding for brownfield repos

When it is not a good fit

Skip this skill if you only need a one-off code snippet, have no intention of maintaining project docs, or are not using a workflow where persistent context improves later outputs. It adds the most value when the same project will be touched repeatedly.

How to Use context-driven-development skill

Install context and where this skill lives

This skill comes from the wshobson/agents repository under plugins/conductor/skills/context-driven-development. The baseline install pattern in Skills-enabled environments is:

npx skills add https://github.com/wshobson/agents --skill context-driven-development

After installation, invoke it from your AI environment when you need to scaffold or update project context rather than jumping straight into implementation.

Read these files first before first use

For a fast, low-guesswork start, read:

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md explains when to use the skill, the artifact relationships, and the maintenance workflow. references/artifact-templates.md is the practical accelerant: it shows the expected shape of product.md, tech-stack.md, and related files so you can give the agent complete inputs faster.

What inputs the context-driven-development skill needs

The skill works best when you provide enough source material to generate or update context artifacts. Strong inputs usually include:

• project type: greenfield or brownfield
• current repository or folder structure
• product purpose and target users
• technical constraints and stack choices
• development workflow preferences
• current roadmap, milestones, or work items
• existing docs such as README.md, tickets, architecture notes, or code

If you only say “set up context for my app,” the output will be generic. If you provide product, stack, workflow, and existing repo evidence, the artifacts become much more actionable.

Greenfield usage: starting a new project

For a new project, use context-driven-development to scaffold the core artifacts before writing much code. A good request looks like this:

• what the product is
• who it serves
• core features in or out of scope
• expected stack
• deployment and testing expectations
• how work should be tracked

The skill is most valuable here because it forces decisions that otherwise remain fuzzy until implementation starts.

Brownfield usage: extracting context from an existing repo

For an existing codebase, ask the skill to infer and organize context from the repository. Point it at:

• source tree
• dependency files
• CI config
• README and issue history
• existing docs
• naming conventions and workflow clues

This is where many users get adoption value quickly: the context-driven-development guide helps turn a repo that “works but is hard to explain” into artifacts an agent can reuse later.

Core artifacts and what each one is for

The repository centers on a few persistent files in conductor/:

• product.md: problem, users, solution, features, metrics, roadmap
• tech-stack.md: languages, frameworks, dependencies, infrastructure, tools
• workflow.md: how development is expected to happen
• tracks.md: work units, status, or ongoing delivery organization

The important idea is relationship, not just file creation. Product decisions should agree with stack choices, workflow rules should match team reality, and tracked work should align with roadmap and implementation priorities.

Turn a rough goal into a strong invocation

A weak prompt:

• “Use context-driven-development for my project.”

A stronger prompt:

• “Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

Why this works better:

• it names the repo state
• it names the target artifacts
• it gives evidence sources
• it asks for separation of assumptions from facts

Suggested workflow for first-time adoption

A practical context-driven-development usage flow:

1. Gather current evidence from repo and docs.
2. Ask the skill to draft the core conductor/ artifacts.
3. Review for factual errors and missing constraints.
4. Resolve contradictions across product, stack, and workflow docs.
5. Only then start implementation or planning tasks that rely on those artifacts.
6. Re-run the skill after major scope, architecture, or workflow changes.

This sequence matters because the skill is designed to improve downstream work, not merely generate documents once.

How to use the artifact templates well

The references/artifact-templates.md file is useful when the skill has partial information. Instead of letting the agent invent missing sections, provide direct answers for template fields such as:

• target personas
• feature status
• success metrics
• dependency rationale
• hosting choice
• test and lint toolchain

The more of the template you can fill with real constraints, the less cleanup you will do later.

Practical tips that materially change output quality

For better context-driven-development usage results:

• ask the agent to mark unknowns explicitly
• separate current state from desired future state
• tell it whether decisions are fixed, tentative, or undecided
• provide examples of your team workflow if workflow.md matters
• request consistency checks before accepting the artifacts

A useful pattern is: “Draft, then validate for cross-file contradictions.” That catches mismatches like a roadmap promising mobile apps while the stack and workflow imply a web-only MVP.

context-driven-development skill FAQ

Is context-driven-development worth installing if I already write good prompts

Usually yes, if you revisit the same project often. Good prompts help in one session. The context-driven-development skill helps create durable context that later prompts can reference instead of rebuilding from scratch.

Is this beginner-friendly

Yes, but only if you are ready to answer basic project questions. The skill gives structure, not business clarity. Beginners with vague project goals may still get generic artifacts until they define users, features, and constraints more concretely.

Does it only work with Conductor

It is designed for Conductor-style context artifacts, so that is the best fit. Even so, the underlying method is portable: structured product, stack, workflow, and tracking docs can help in other AI-assisted setups too.

What is the main boundary of the skill

It does not replace implementation expertise or system design review. context-driven-development is strongest at organizing project context, surfacing relationships between artifacts, and keeping documentation aligned with work.

How is it different from just keeping a README

A README is usually audience-facing and broad. This skill pushes toward operational context for development: what the product is, how the stack is chosen, how work moves, and what should stay consistent across agent sessions.

When should I not use context-driven-development

Do not use it for tiny throwaway experiments, one-off scripts, or projects where you will not maintain the artifacts. The value comes from ongoing reuse and synchronization, not the first draft alone.

How to Improve context-driven-development skill

Give the skill evidence, not aspirations

The biggest quality jump comes from grounding the skill in actual repo evidence and decisions. Attach or reference real files, configs, and feature lists. If you only provide ambitions, the artifacts read like generic planning docs instead of working context.

Ask for confirmed facts versus inferred assumptions

One common failure mode is mixing observed repo facts with guesses. Improve context-driven-development outputs by requesting two layers:

• confirmed from files or docs
• inferred from patterns or missing information

That makes review much faster and reduces accidental drift.

Tighten each artifact around decisions

Users care most about whether the artifacts help later coding sessions. Improve that by making each file decision-oriented:

• product.md: who, problem, scope, success metrics
• tech-stack.md: chosen tools and why
• workflow.md: how changes are proposed, built, tested, reviewed
• tracks.md: what is active, blocked, next, or done

If a section cannot guide a future coding decision, trim it.

Validate consistency before trusting the output

The skill is more useful when you ask it to check for contradictions such as:

• product scope exceeding roadmap
• stack choices conflicting with deployment constraints
• workflow expectations unsupported by repo tooling
• tracks not matching current priorities

This validation step is one of the highest-value habits for context-driven-development for Context Engineering.

Improve prompts with repository-reading instructions

Instead of saying “analyze my repo,” specify where the truth lives. For example:

• “Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• “Treat issue labels and milestone names as workflow clues.”
• “Prefer explicit config over naming heuristics.”

This reduces hallucinated stack and process details.

Iterate after the first draft, not before it

A good pattern is draft -> review -> refine. First ask for complete artifacts, then issue a second pass such as:

• remove generic filler
• add missing constraints
• convert assumptions into questions
• align tracks to roadmap
• update stack rationale with exact versions where known

That iteration is usually better than trying to perfect the first prompt.

Keep artifacts alive as the project changes

The context-driven-development install decision only pays off if the docs stay current. Re-run or revisit the skill when:

• architecture changes
• priorities shift
• tooling changes
• onboarding friction appears
• agent outputs start drifting from actual project reality

Outdated context is often worse than missing context because it creates false confidence.