architect-propose
Skill3 starsChanged 2 months agoApache-2.0View on GitHub
Propose and create a new Architect track for an initialized project, including its spec, plan, metadata, and registry entry. Use when the user asks to add, plan, or propose a new feature, bug fix, chore, refactor, docs, or test track.
In this repository5 other files it gives its agents.
- architect-discussSkill
- architect-implementSkill
- architect-reviewSkill
- architect-setupSkill
- architect-statusSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Create one proposal track from approved specification and plan artifacts.
- Distinctive: line 13
Do not create a track before both spec and plan approvals.
- Very specific: line 14
Keep writes and links under safe architect/ paths.
- Distinctive: line 15
Do not let unrelated track status block an independent proposal.
- Distinctive: line 16
Commit only when explicitly requested in the current conversation.
- Very specific: line 20
Read references/propose-track-protocol.md and core project context.
- Very specific: line 23
Ask for Task or Sub-task status granularity, default to Sub-task, then draft, present, revise, and approve plan.md from the project …
- Distinctive: line 25
Create artifacts, register the track, and report next steps without starting implementation.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Architect Propose
Create one proposal track from approved specification and plan artifacts. Follow references/propose-track-protocol.md as the source of truth.
Hard Boundaries
- Require initialized core Architect context.
- Do not create a track before both spec and plan approvals.
- Keep writes and links under safe
architect/paths. - Do not let unrelated track status block an independent proposal; only collisions may block creation.
- Commit only when explicitly requested in the current conversation.
Run
- Read
references/propose-track-protocol.mdand core project context. - Establish description and inferred track type.
- Draft, present, revise, and approve
spec.md. - Ask for Task or Sub-task status granularity, default to Sub-task, then draft, present, revise, and approve
plan.mdfrom the project workflow. - Recover management paths when needed, generate a safe ID, and run collision checks.
- Create artifacts, register the track, and report next steps without starting implementation.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

