Plan feature

Skill Karthick-Ramachandran/persist-os/.agents/skills/plan-feature

Local-first CLI that gives your repo durable, AI-ready memory - features, ADRs, modules, architecture, standards & tests and a deterministic doctor that validates health, evidence & drift.

Install

npx -y skills add Karthick-Ramachandran/persist-os --skill plan-feature

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.2 KB, as published. Nobody here has run it

Skill: Plan Feature

Purpose

Turn product intent into a scoped engineering plan that an implementation agent can follow safely.

Inputs

Feature PRD.
Acceptance criteria.
Relevant module or architecture docs.
Known constraints or release target.

Required Reading

docs/10-architecture/ARCHITECTURE.md
docs/10-architecture/FILE_WRITE_POLICY.md
docs/20-security/SECURITY_MODEL.md
docs/50-quality/QUALITY_GATES.md
docs/60-engineering/ENGINEERING_STANDARDS.md
Relevant feature docs under docs/40-features/
Relevant module docs under docs/30-modules/
Relevant ADRs under docs/adrs/

Output Files

docs/40-features/<feature>/PLAN.md
docs/40-features/<feature>/TASKS.md
docs/40-features/<feature>/ARCHITECTURE_IMPACT.md
docs/40-features/<feature>/TEST_PLAN.md

Process

Restate the feature objective and acceptance criteria.
Identify modules, docs, templates, and tests affected.
Document architecture impact and ADR needs.
Break work into ordered tasks with clear completion evidence.
Define tests from requirements, risk, security invariants, and regressions.
For module requests, treat the module as a mini product and create feature delivery docs before implementation tasks.

Stop Conditions

Stop and request human decision if:

Requirements are missing or contradictory.
Architecture impact cannot be determined.
The plan conflicts with engineering standards.
A task requires changing accepted non-goals.
A module request tries to start implementation before PRD, acceptance, architecture impact, test plan, and tasks exist.

Quality Bar

Tasks are ordered and independently reviewable.
Tests map to acceptance criteria and risks.
Architecture impact is explicit.
Engineering standards are accounted for in tasks and completion evidence.
The plan does not include implementation code when only planning is requested.