Prompt file imported from NascentCore/inty (.cursor/commands/plan.md). Copyright stays with the author.

Plan implementation

Name: plan
Author: NascentCore

Must be in plan mode, if not, switch to plan mode first.

Add implementation details to a high-level design provided in the plan file.

The implementation details are handed off to a less intelligent subagent.

The major work is to fill in details given a sound and clear design. So that the less intelligent subagent can focus on implementation, not to lost objective and create unmaintainable code.

Scoping

Start with core & minimal plans
Create github issues and add TODOs in code places, when the available information is not sufficient for a clear & concrete design.

For companion harness

Read companion harness design
Focus on architecture soundness, do not do duct-tape fixes

Conventions

Class & domain name: camel case like OutputQueue
mechanism process: snake case like drain_output_queue
Types/kinds and any enum-like semantic should use enum type, not str/integer or other primitive types

Use alembic cli to generate database version files

After adding new models in orm/, use alembic skill to create new version file
Never generate alembic version file

Testing

Plan should include testing.
Tests are done at the key juncture between procedures of the plan.
Complex features should have smoke tests to cover the end-to-end process.
User-facing changes should have regression tests added to repl regression tests, as repl regression tests are the only client we can reliably test. Weixin/WeChat Telegram are difficult to test in code.
Tests should not use mocks
Tests should use fakes

Limited layering

Limit the number of layers in implementing a complex feature:

When extending behaviors, prefer rewriting a new function and remove the old one, over extending the existing function and wrap them behind a new function with "more specific interface" or naming. The former sheds the unnecessary complexity, and the latter merely hides and accumulates unnecessary complexity.

Comments for data types

Add comments to describe data type and its fields semantic and designated usage scenarios, add member documentation on top of each field, not in data type docstring

# Plan implementation Must be in plan mode, if not, switch to plan mode first. Add implementation details to a high-level design provided in the plan file. The implementation details are handed off to a less intelligent subagent. The major work is to fill in details given a sound and clear design. So that the less intelligent subagent can focus on implementation, not to lost objective and create unmaintainable code. ## Scoping - Start with core & minimal plans - Create github issues and add TODOs in code places, when the available information is not sufficient for a clear & concrete design. ## For [companion harness](/app/core/companion_harness/) - Read [companion harness design](/docs/imate/companion_harness/DESIGN.md) - Focus on architecture soundness, do not do duct-tape fixes ## Conventions - Class & domain name: camel case like OutputQueue - mechanism process: snake case like drain_output_queue - Types/kinds and any enum-like semantic should use enum type, not str/integer or other primitive types ## Use alembic cli to generate database version files - After adding new models in orm/, use alembic skill to create new version file - Never generate alembic version file ## Testing - Plan should include testing. - Tests are done at the key juncture between procedures of the plan. - Complex features should have smoke tests to cover the end-to-end process. - User-facing changes should have regression tests added to repl regression tests, as repl regression tests are the only client we can reliably test. Weixin/WeChat Telegram are difficult to test in code. - Tests should not use mocks - Tests should use fakes ## Limited layering Limit the number of layers in implementing a complex feature: - When extending behaviors, prefer rewriting a new function and remove the old one, over extending the existing function and wrap them behind a new function with "more specific interface" or naming. The former sheds the unnecessary complexity, and the latter merely hides and accumulates unnecessary complexity. ## Comments for data types - Add comments to describe data type and its fields semantic and designated usage scenarios, add member documentation on top of each field, not in data type docstring

{ "prompt": "# Plan implementation\n\nMust be in plan mode, if not, switch to plan mode first.\n\nAdd implementation details to a high-level design provided in the plan file.\n\nThe implementation details are handed off to a less intelligent subagent.\n\nThe major work is to fill in details given a sound and clear design.\nSo that the less intelligent subagent can focus on implementation,\nnot to lost objective and create unmaintainable code.\n\n## Scoping\n\n- Start with core & minimal plans\n- Create github issues and add TODOs in code places, when the available information is not sufficient for a clear & concrete design.\n\n## For [companion harness](/app/core/companion_harness/)\n\n- Read [companion harness design](/docs/imate/companion_harness/DESIGN.md)\n- Focus on architecture soundness, do not do duct-tape fixes\n\n## Conventions\n\n- Class & domain name: camel case like OutputQueue\n- mechanism process: snake case like drain_output_queue\n- Types/kinds and any enum-like semantic should use enum type, not str/integer or other primitive types\n\n## Use alembic cli to generate database version files\n\n- After adding new models in orm/, use alembic skill to create new version file\n- Never generate alembic version file\n\n## Testing\n\n- Plan should include testing.\n- Tests are done at the key juncture between procedures of the plan.\n- Complex features should have smoke tests to cover the end-to-end process.\n- User-facing changes should have regression tests added to repl regression tests,\n as repl regression tests are the only client we can reliably test.\n Weixin/WeChat Telegram are difficult to test in code.\n- Tests should not use mocks\n- Tests should use fakes\n\n## Limited layering\n\nLimit the number of layers in implementing a complex feature:\n\n- When extending behaviors, prefer rewriting a new function and remove the old one, over extending the existing function and wrap them behind a new function with \"more specific interface\" or naming. The former sheds the unnecessary complexity, and the latter merely hides and accumulates unnecessary complexity.\n\n## Comments for data types\n\n- Add comments to describe data type and its fields semantic and designated usage scenarios, add member documentation on top of each field, not in data type docstring", "variables": [], "notes": "Must be in plan mode, if not, switch to plan mode first.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/NascentCore/inty", "path": ".cursor/commands/plan.md", "ref": "4f0eeb49598d04725428365158206f15739bcebb", "url": "https://github.com/NascentCore/inty/blob/4f0eeb49598d04725428365158206f15739bcebb/.cursor/commands/plan.md", "key": "NascentCore/inty/.cursor/commands/plan.md" } } }

plan

About

Plan implementation

Scoping

For companion harness

Conventions

Use alembic cli to generate database version files

Testing

Limited layering

Comments for data types

Use it

Manifest

Reviews