// Reflect on recent large changes and check if the rest of the codebase needs to catch up. Use after adding features, installing extensions, changing services, updating schemas, or making any significant structural change.
| name | manifest-learn |
| description | Reflect on recent large changes and check if the rest of the codebase needs to catch up. Use after adding features, installing extensions, changing services, updating schemas, or making any significant structural change. |
After making significant changes to the codebase — adding features, installing extensions, creating services, modifying schemas, changing framework code — stop and reflect. The codebase is a living system. When one part changes, other parts may need to catch up.
When to use: After any change that isn't a trivial bug fix. The bigger the change, the more important this is. Especially after:
manifest/Work through each item. Not everything will need updating every time — but you must check every time.
Read AGENTS.md (the project root one, not the pi-level one). Ask yourself:
If any section is stale, update it. AGENTS.md is the first thing an agent reads — if it's wrong, every subsequent action is built on a lie.
Check each skill in .pi/skills/:
Also ask: should a new skill exist? If you've introduced a repeatable pattern (e.g., "how to add an extension", "how to write a migration"), it might deserve its own skill.
Read config/manifest.ts and any other config files:
If extensions were added or modified:
EXTENSION.md?AGENTS.md mention the extension?bun test
bunx tsc --noEmit
Does everything still compile?
If new packages were installed:
Read the recent commit history:
git log -n 10 --pretty=format:"%s"
Does the story make sense? Would an agent reading this cold understand the progression of changes? If not, the next commit should include context that ties things together.
Work through the checklist above item by item. The goal is semantic accuracy — is the documentation actually correct, not just present?
This isn't busywork. The codebase is a shared workspace between you and the next agent (or human) who touches it. When you change something significant and don't update the surrounding documentation, you're leaving a trap. The next reader will trust AGENTS.md, follow its instructions, and produce wrong code because the instructions are stale.
Think of it like a pair programming partner. When your pair changes an interface, you update the callers. When they add a new module, you update the README. This is the same thing — except your pair might be a future version of yourself that has no memory of what you did today.
Every time you finish a significant change: stop, work through the checklist, and make it right.
Write knowledge-transfer git commits for Manifest projects. Use when making git commits. Commits include a typed subject line and a detailed body explaining what changed, why, and how.
Contribute framework improvements back to the upstream Manifest repo via PR. Use when the user says "contribute back", "open a PR upstream", "send this fix upstream", or wants to share a framework improvement.
Work with Manifest's frontend system — building, serving, dev workflow, debugging, and presets. Use when creating pages, components, debugging frontend errors, or configuring the build.
Structured implementation flow for Manifest features — from investigation through execution with subagents. Follows the full chain: investigate → clarify → explore → validate → plan → todos → branch → execute → review. No shortcuts. Invoke manually when building a new feature or significant change in a Manifest project.
Resolve merge conflicts from upstream syncs or other merges. Preserves application identity while accepting framework and tooling improvements. Use when you see merge conflict markers or the user says "resolve conflicts", "fix merge", or "merge conflict".
Code review guidelines and quality rubric for Manifest projects. Covers framework conventions, feature structure, schema quality, and security. Shared by the reviewer subagent and available for manual reviews. Use when reviewing code changes.