agentic-feature-framing

Solid

Frame a piece of work before any design or implementation: what is in scope, what is explicitly not, and the acceptance criteria that will judge it. Use at the very start of a new feature, when the user says "I want to build X", "we need a way to Y", or hands over a ticket or a rough idea. Produces .claude/features/<slug>/charter.md and nothing else — no code, no design decisions, no file edits. This is phase 1a of the agentic development pipeline; agentic-design-session is 1b and agentic-orchestrator is phase 2.

AI & Automation 314 stars 20 forks Updated yesterday Apache-2.0

Install

View on GitHub

Quality Score: 86/100

Stars 20%
83
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Feature framing You are settling **what** is being built. Not how. The output is one file: `.claude/features/<slug>/charter.md`, from `.claude/pipeline/charter.template.md`. ## Why this exists Two reasons, and the second is the one that gets forgotten. **Scope and criteria are the escalation ladder.** Downstream, an orchestrator dispatches cheap subagents that cannot ask you anything. When one of them hits an ambiguity, it walks an escalation ladder: does an acceptance criterion answer this, does a decision entry answer it, is it a new decision inside scope — and only if all three fail does it stop and wait for a human. **Every rung of that ladder is something you write here or in the design session.** A charter that is vague about scope does not produce a flexible pipeline; it produces one that halts constantly, or worse, one whose subagents quietly decide for themselves. **And this phase, with 1b, is how the size of the work becomes visible.** Not so that units can be planned — they never are — but so that the decision to hand this to the orchestrator in one run, or to cut it into several, is made deliberately and before anything is built. That verdict is written at the close of the design session, into the charter's `Size and sessions`. What you owe it here is a coarser read: whether this is *one* feature at all. ## Hard rules - **Write no code.** Not an example, not a sketch, not a type definition. - **Edit no file but the charter.** - **Do not design.** "We cou...

Details

Author
PackmindHub
Repository
PackmindHub/packmind
Created
1 years ago
Last Updated
yesterday
Language
TypeScript
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

agentic-orchestrator

Run the implementation loop for a framed and decided feature: pick the next unit, retrieve just enough context, write an inline spec, dispatch one subagent, gate the result, route on which gate stage failed, and record it. Use after agentic-feature-framing and agentic-design-session have produced a charter and a decision log, when the user says "start building", "implement the feature", "run the next unit", or resumes work on an existing .claude/features/<slug>/. This is phase 2 of the agentic development pipeline. It never edits code itself.

314 Updated yesterday
PackmindHub
AI & Automation Solid

agentic-design-session

Turn a framed feature into an append-only decision log: every design fork made explicit, with the reasoning and the alternatives that were rejected and why. Use after agentic-feature-framing has produced a charter, and before any implementation starts. Also use when an implementation reveals an earlier decision was wrong and needs superseding. Produces .claude/features/<slug>/decisions.md, and closes by sizing the feature into the Size and sessions section of the charter — the call on whether the orchestrator runs it in one pass or several. No code, no other file edits. This is phase 1b of the agentic development pipeline.

314 Updated yesterday
PackmindHub
AI & Automation Listed

frame-feature

Interview the user about a feature that has no ticket behind it — read the wiki via qmd before asking anything, settle the problem and who has it and why now, check the user's wording against `wiki/domain.md`, produce a mandatory out-of-scope list and one checkable success measure, and record the decisions the framing settled (optionally as approved, intent-marked writes to `wiki/domain.md`, `wiki/architecture.md` and `wiki/adr/`) — until there is a brief whose acceptance criteria `grill-task` can drill into. Use when the user says "new feature", "start a new feature", "frame this idea", "I want to build X", "what should we build". Interactive sessions only — every step is a question a human has to answer.

3 Updated 4 days ago
bibennurbani