Beyond Code

Codeless Projects

WSD is an AI collaboration and orchestration system that happens to include deep support for coding, not a coding tool that happens to have documentation features. The workscope lifecycle, agent coordination, checkboxlists, work journals, and documentation hierarchy are all capabilities that operate independently of whether your project contains a single line of source code. This means WSD works natively for any sustained AI-assisted work: academic research, business strategy, technical writing, book projects, planning exercises, or documentation repositories.

A codeless project uses the same installation and setup process as any other WSD project. The key configuration difference is minor: the /wsd:setup command will set check_dirs = [] in a minimal pyproject.toml to indicate that there are no source directories to scan. WSD detects this and classifies your project as codeless, which means it skips the quality checks that only apply to code (linting, type checking, security scanning, test execution, build validation, etc.) while keeping everything else fully operational.

What remains is substantial. The workscope management system assigns and tracks work through your Action Plan exactly as it would for a software project. All Special Agents function normally — the Task-Master navigates your checkboxlists, the Context-Librarian surfaces relevant documents, the Project-Bootstrapper educates each session on your project’s rules. The documentation hierarchy (docs/core/, docs/features/, docs/tickets/, docs/workbench/) organizes your work the same way. Slash commands, work journals, the workbench, and session cycling all operate identically. The only difference is that the Health-Inspector’s checks show as “SKIPPED” rather than running against nonexistent source code, which is expected behavior.

The practical implications are worth illustrating. A research paper can use Feature Overviews for major sections or analytical threads, the Action Plan for phased writing milestones, and tickets for questions that arise during investigation. A business strategy project can use the same Feature Overview structure for strategic initiatives, the workbench for evolving drafts, and the checkboxlist system to track decisions and their downstream consequences. A technical documentation project can organize its content hierarchy under docs/features/, with each documentation area as a feature with its own specification and implementation plan.

The workscope lifecycle is what makes this valuable rather than just organizational. Breaking a large writing project into session-sized workscopes prevents the quality degradation that occurs when AI sessions run too long.¹²

For detailed setup instructions including the minimal pyproject.toml configuration, example project structures, and troubleshooting, see the Codeless Project Guide (dev/wsd/Codeless-Project-Guide.md) in your WSD installation.

Transitioning Between Project Types

A codeless project that grows code is one of the most natural transitions in WSD. You start with a research repository, and six weeks later you are writing a Python script to parse experimental data. Or you begin with a documentation project that eventually needs a small web application to present its content. WSD handles this transition seamlessly because it was designed for the entire spectrum from the beginning.

The mechanical steps are straightforward. Add your code to the project and re-run /wsd:setup. This will update check_dirs in pyproject.toml to include your new source directories. The setup skill detects the changes, configures the appropriate tooling, and ensures WSD commands work correctly for the updated project type.

After re-setup, the code-specific quality checks activate automatically. Running wsd health now executes linting, type checking, security scanning, and the other quality dimensions against your source directories instead of skipping them. Running wsd test executes your test suite. The QA gauntlet gains its full weight: the Test-Guardian has tests to run, the Health-Inspector has code to validate. The organizational infrastructure that was already in place — your Action Plan, your feature specifications, your tickets, your documentation hierarchy — continues working exactly as before, now augmented by the development tooling that your code requires.

The transition works in the other direction too, though this is less common. A project that removes its code and returns to a codeless state simply needs its check_dirs reset to [] and a re-run of /wsd:setup. WSD adapts to whatever your project is at any given moment.

Multi-Language Projects

Some projects contain both Python and TypeScript or JavaScript — a Python API server with a React frontend, a data pipeline with a web dashboard, or any architecture where multiple language ecosystems coexist. WSD supports these polyglot projects natively through its language detection system.

The task runner detects languages by examining your project’s configuration files and source directories. A pyproject.toml with a [project] section or Python files in the configured check directories signals Python. A package.json with TypeScript files in the check directories signals TypeScript; without TypeScript files, it signals JavaScript. TypeScript and JavaScript are mutually exclusive; any project with .ts files is classified as TypeScript — but a project can be both Python and TypeScript, or both Python and JavaScript.

In a multi-language project, commands run for all detected languages. wsd test executes both the Python test suite and the Node.js test suite sequentially. wsd lint runs both the Python linter and the JavaScript or TypeScript linter. wsd health runs the full health check for each language. If any language’s checks fail, execution stops immediately — the fail-fast behavior ensures that problems are caught regardless of which language introduced them.

This cross-language execution extends to the QA gauntlet. When the Test-Guardian runs the test suite during quality assurance, it runs tests for every detected language and must present results for all of them. When the Health-Inspector runs the health check, it produces a summary covering all language-specific quality dimensions. The unified interface means you do not need to remember different commands for different parts of your project — wsd test always does the right thing, whether your project has one language or three.

For projects transitioning from single-language to multi-language, the process mirrors the codeless-to-code transition. Add the new language’s configuration files and source code, update check_dirs to include the new directories, and re-run /wsd:setup. WSD detects the additional language and enables the appropriate tooling. The task runner’s language detection updates automatically on each invocation, so there is no manual registration step — your project’s languages are always derived from what actually exists in the repository.

For the complete command reference and detailed multi-language configuration, see the Task Runner Guide (dev/wsd/Task-Runner-Guide.md) in your WSD installation.

Footnotes

1. N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” Trans. Assoc. Comput. Linguist., vol. 12, pp. 157-173, 2024. ↩

2. Y. Du et al., “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval,” in Findings of EMNLP, 2025. [Online]. Available: https://arxiv.org/abs/2510.05381. ↩