feat(codegen): auto-generate skills docs with INPUT_OBJECT dot-notation, semantic types, and --no-tty#786
Open
pyramation wants to merge 1 commit intomainfrom
Open
Conversation
… TypeRegistry threading, and --no-tty docs
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
feat(codegen): auto-generate docs with INPUT_OBJECT dot-notation and --no-tty
Summary
Updates the codegen docs generators so that generated agent skills, READMEs, and MCP tool definitions automatically reflect INPUT_OBJECT dot-notation flattening and
--no-ttynon-interactive mode — no hand-editing of skill files needed.Core change: Added
flattenArgs(args, registry?)andresolveInputFields()helpers indocs-utils.tsthat resolve INPUT_OBJECT types from theTypeRegistry(sinceCleanTypeRefintentionally omitsinputFieldsto avoid circular references). All 8 docs generator functions (generateReadme,generateAgentsDocs,getCliMcpTools,generateSkills+ their multi-target variants) now accept an optionalTypeRegistryand pass it through toflattenArgs.Before:
csdk sign-in --input <value>After:
csdk sign-in --input.clientMutationId <value> --input.email <value> --input.password <value> --input.rememberMe <value> ...Also adds
--no-ttydocumentation sections to all generated READMEs and SKILL.md files.Files changed (source):
docs-utils.ts— newflattenArgs(),flattenedArgsToFlags(),resolveInputFields()helpersdocs-generator.ts— all 8 generators acceptTypeRegistry, use flattened args, add--no-ttydocsgenerate.ts— threadscustomOperations.typeRegistryto CLI docs calls; merges registries for multi-targetReview & Testing Checklist for Human
clientMutationIdnoise: Every flattened INPUT_OBJECT now shows--input.clientMutationIdas the first flag in usage/examples. This is technically correct but clutters docs since most users never pass it. Consider whetherclientMutationIdshould be filtered out inflattenArgs().generate.ts): The combined registry uses simpleMap.set()so later targets overwrite earlier ones on name collision. Verify this is safe given your schema structure (should be fine if type names are globally unique).set-and-commitwith 8 fields) produce very long single-line usage strings. Check if this is acceptable for agent consumption or if truncation/reformatting is needed.pnpm run generatein constructive-cli after merge to confirm the regenerated output matches expectations against the latest schema.Notes
--input.emailetc.) requires a running backend to verify. CI checks compile/lint only.