| name | feat-dev |
| description | End-to-end workflow for implementing a non-trivial glm-code feature. Covers requirements investigation, design, E2E test planning, baseline dry-run, implementation, verification, code review, and iteration. |
Feature Development Workflow
Use this workflow when implementing a feature in glm-code that needs design,
behavioral validation, or coordinated changes across multiple files. Each phase
produces a concrete artifact. Do not combine phases; the output of each phase
feeds the next.
Artifact Paths
Use .glm/ paths for planning artifacts:
.glm/design/<feature>.md.glm/e2e-tests/<feature>.md
Phase 1: Investigate
Understand the requested behavior and the current glm-code implementation.
Use a code exploration agent when available. Ask it to inspect the relevant
glm-code areas for:
- Existing feature definitions: tools, parameters, schemas, commands, UI, or
config.
- Runtime wiring: spawning, lifecycle, state, permissions, hooks, and cleanup.
- Edge cases and error handling.
- Integration points and limitations.
In parallel, inspect docs, issues, tests, and nearby implementations that define
or constrain the expected behavior. If no exploration agent is available, do the
same investigation locally.
Output: mental model of current behavior, desired behavior, constraints, and key
file paths with line numbers.
Phase 2: Design Doc
Write a design doc covering:
- Problem statement and current state, including the behavior gap.
- Proposed changes by layer or component.
- Key design decisions and rationale.
- Files affected.
- Scope boundaries.
- Open questions.
Use prose, tables, and bullets. Avoid code snippets unless essential for a key
data structure. JSON config examples are acceptable.
Output: design doc on disk.
Phase 3: Test Plan
Use the e2e-testing skill to choose test modes. Then write an E2E test plan
covering:
- Test groups by capability: parameter acceptance, core behavior, error
handling, cleanup, and regressions.
- Exact commands and expected behavior before and after implementation.
- Unique tmux session names and temp dirs for independent groups.
- Which groups can be run in parallel by separate
test-engineer agents.
Output: test plan on disk.
Phase 4: Dry-Run
Validate the test plan against the current baseline using the globally installed
glm CLI, not the local build.
Spawn test-engineer agents for independent test groups when the runtime
supports it. The feature is not implemented yet, so tests should either fail or
show the gap. Iterate the test plan if the dry-run reveals broken commands,
wrong filters, or false positives.
Output: confirmed-working test plan with accurate pre-implementation baseline.
Phase 5: Implement
Read the relevant source files before editing. Implement the changes described
in the design doc and follow project conventions:
- ESM and strict TypeScript.
- Prettier formatting.
- Collocated tests next to source.
- No speculative abstractions beyond the design.
After implementation:
npm run build
npm run typecheck
npm run bundle
Also run focused unit tests for changed files from the relevant package
directory.
Output: local implementation that builds and passes focused tests.
Phase 6: Verify
Run the full E2E test plan against the local build with node dist/cli.js.
Spawn independent test-engineer agents when useful and available.
If tests fail, diagnose, fix, rebuild, re-bundle, and re-test until all groups
pass.
Output: E2E results appended to the test plan.
Phase 7: Code Review
Run /review with a review task listing all changed files. Triage each comment
before acting:
- Valid: real bug or meaningful improvement. Fix it.
- False positive: reviewer missed context. Skip it.
- Overthinking: technically plausible but not worth the complexity. Skip
it.
After fixes, re-run unit tests and a quick E2E sanity check.
Output: clean implementation with valid review findings addressed.
Phase 8: Wrap Up
Skip unless the user asks. Create the branch, commit with Conventional Commits,
push, and create a draft PR using the project PR template. Post E2E results as a
separate PR comment when applicable.
Iteration Rules
- If Phase 6 fails, return to Phase 5 and then re-run Phase 6.
- If Phase 7 finds valid issues, fix them and run a quick Phase 6 sanity check.
- Do not loop more than 3 times between Phases 5-7 without asking the user.
- If the test plan is inaccurate, update it and document why.
